111
1 Review Session 3 Mobile IP SIP H.323

Review Session 3

  • Upload
    kimn

  • View
    24

  • Download
    0

Embed Size (px)

DESCRIPTION

Review Session 3. Mobile IP SIP H.323. Mobile IP Requirements. Transparency: Movement of Mobile host: transparent to the applications and transport-layer protocols Transparent to the routers, except those directly connected with the mobile host - PowerPoint PPT Presentation

Citation preview

Page 1: Review Session 3

1

Review Session 3

Mobile IPSIP

H.323

Page 2: Review Session 3

2

Mobile IP Requirements Transparency: Movement of Mobile host:

transparent to the applications and transport-layer protocols

Transparent to the routers, except those directly connected with the mobile host

Interoperability with IPv4 and with other mobile hosts

Handles long duration moves and not rapid motion

Scalable

Page 3: Review Session 3

3

Mobile IP Requirements …2

Secure: All messages used to update another node ( a router in the home network) as to the new location of a mobile host must be authenticated in order to protect against remote redirection attacks.

Wireless devices have lower bandwidth and have to conserve the use of energy. So the number of administrative messages and their size should be kept as small as possible.

Page 4: Review Session 3

4

Procedure: two addresses A mobile host has a permanent IP address

in its home network. A router in its home network is used as its Home Agent (HA). HA must have a network interface on the link, indicated by the mobile host’s IP address.

When it moves to another network, it acquires a temporary address, called the Care-of-Address.

Two different processes with Care-of-address:

Page 5: Review Session 3

5

Registration of Care-of-address

Care-of-address operated through a router in the new network. A router in the foreign network, which does the job, is called the Foreign Agent (FA) for the mobile host.

Co-located Care-of-address: The mobile host handles all forwarding and tunneling itself. It requires additional software to do so. Moreover the mobile host on a foreign network, must be located on a link, specified by the network prefix of the Care-of-address.

Page 6: Review Session 3

6

Registration and gratuitous ARP Registration: The mobile host: registers with HA by

informing it of its Care-of-address, -- through FA or in case of co-located Care-of-address, itself.

After registering the mobile host’s Care-of-address, the HA broadcasts a gratuitous ARP message on the home network, giving its own MAC address as a proxy for the mobile host. Since broadcast messages may not reach reliably every host on the network, the gratuitous ARP message is broadcast a few times.

Page 7: Review Session 3

7

Deregistration

Deregistration: When the mobile host comes back to its home network, it sends a gratuitous ARP message to give its own

MAC address to all the hosts on the local network.

a deregistration message to the HA and it simultaneously retransmits the

gratuitous ARP message a few times.

Page 8: Review Session 3

8

Deregistration ….. 2 After accepting the deregistration request, HA sends

a gratuitous ARP message, associating the MAC address of the mobile host with the mobile host’s IP address to the local network.

a reply to the mobile host, accepting deregistration.

The HA retransmits this gratuitous ARP message a few times.

Both the HA and the mobile host are required to send the gratuitous ARP message at deregistration, since the area of coverage of the wireless mobile host and the HA are likely to be different.

Page 9: Review Session 3

9

Data Transfer: from remote sender to mobile host: Triangle Routing The Remote Sender (RS) sends a message

to the home address of the mobile host. The Home Agent (HA)

intercepts the message, using proxy ARP method.

encapsulates the message using IP-in-IP with

Source address = the HA address Destination address = the FA address

Note: PROTOCOL in the IP Header for IP-in-IP is equal to 4.

Page 10: Review Session 3

10

Data Transfer: Foreign Agent (FA):

retrieves the packet, sent by the remote sender, consults a registry table to get the Care-of-

address and sends the packet to the Care-of-address.

From Mobile Host to the Remote Sender:The packet generally goes DIRECTLY, with

Source address = the home address of the mobile host

Destination address = the address of the remote host

Page 11: Review Session 3

11

Double Cross Routing

When The mobile host goes to the network of the Remote Sender (RS):

Remote Sender’s message follows the standard Triangulation process, though the Foreign Agent is in the RS’s network.

Message from the mobile host to RS: Direct

Causes of Inefficiencies: Triangle Routing Double Crossing

Page 12: Review Session 3

12

Solution to inefficiencies

HA may inform RS about the Care-of-address, while forwarding the packet to the FA.

All future packets from RS to mobile host can go directly.

When the mobile host returns to the home network, HA may again inform the RS.

Skip 13-16

Page 13: Review Session 3

13

IP in IP Encapsulation (RFC 2003) To encapsulate an IP datagram in

IP:

Page 14: Review Session 3

14

IP in IP Encapsulation: The Outer IP Header

Protocol: 4 Source Address = HA address Destination Address = FA address. HA and FA are the end-points of the tunnel during the

Triangle Routing. Header Length: length of the outer IP header only Type of Service (TOS): copied from the inner IP header Total Length: length of the entire encapsulated IP

datagram, including the outer IP header, the inner IP header, and its payload.

Time to Live: appropriate for delivery up to the tunnel exit point.

Page 15: Review Session 3

15

IP in IP Encapsulation : The Outer IP Header ….2 "Don't Fragment" bit :

If the "Don't Fragment" bit is set in the inner IP header, it MUST be set in the outer IP header.

If the "Don't Fragment" bit is not set in the inner IP header, it MAY be set in the outer IP header.

Fragmentation and reassembly: will have to be done at the ends of the tunnel. However since the two end-points are routers, reassembly

may pose a problem. An ICMP message due to a large message from a router

within a tunnel may be difficult to relay to the original sender.

Options: Any options present in the inner IP header are in general NOT copied to the outer IP header.

Page 16: Review Session 3

16

IP in IP Encapsulation : The Inner IP Header not changed by the encapsulator (HA),

except to decrement the TTL remains unchanged during its delivery up to

the tunnel exit point TTL in the inner IP header is not changed

when decapsulating. After decapsulation, when the decapsulator (FA) forwards the datagram to one of its network interfaces, it will decrement TTL as a result of doing normal IP forwarding.

Page 17: Review Session 3

17

Discovery of Agents Before a mobile host leaves the home network, it

must obtain information about its Home Agent (HA).

When a mobile host reaches a foreign network, it must discover information about its Foreign Agent (FA).

HA must be always available to serve its mobile hosts.

FA must continue to advertise so that the mobile hosts registered with it know that

they have not gone out of its range. the FA is alive.

Page 18: Review Session 3

18

Discovery of Agents ……..2 Mobility agents (FAs and HAs): advertise

their presence via Agent Advertisement messages A mobile host may optionally solicit an Agent Advertisement message from any locally attached mobility agents through an Agent Solicitation message.

On receiving the Agent Advertisements, a mobile host determines whether it is on its home network or a foreign network.

Page 19: Review Session 3

19

A mobile host: on the Home/Foreign Network:

When it detects that it is on its home network, it operates without mobility services. If returning to its home network from being registered elsewhere, the mobile node deregisters with its HA, through exchange of a Registration Request and Registration Reply message with it.

When it detects that it has moved to a foreign network, it obtains a Care-of address on the foreign network either

from a FA’s advertisements (a FA Care-of address): The preferred method because it allows many mobile nodes to share the same Care-of address and therefore does not place unnecessary demands on the already limited IPv4 address space. OR

Page 20: Review Session 3

20

A mobile host on a Foregn network: Acquiring a care-of-address ……..2

The address may be dynamically acquired as a temporary address by the mobile node through DHCP, or may be owned by the mobile node as a long-term address for its use only while visiting some foreign network. (a Co-located care-of address).

Advantage: No FA need be deployed. Disadvantages: (i) places additional burden on the

IPv4 address space because it requires a pool of addresses within the foreign network to be made available to visiting mobile nodes.

(ii) difficult to efficiently maintain pools of addresses for each subnet that may permit mobile nodes to visit.

Page 21: Review Session 3

21

Acquiring Care-of-addresses from FA advertisement

If there are more than one Care-of-addresses, advertised by a FA, the mobile host should pick up the first.

If FA rejects the Registration Request, then the mobile host should resend the request with the second Care-of-address.

Page 22: Review Session 3

22

Discovery of Agents …2 ADVERTISEMENT BY AGENTS: through

regular ICMP Router Advertisements, on which the Agent advertisements are piggy-backed.

Mobility Agent Advertisement Extension is added to the ICMP Router Advertisements for this purpose.

Page 23: Review Session 3

23

Mobility Agent Advertisement Extension

Appended to the Router Advertisement

ICMP

Router Advertisement Message

Type = 16

Length Sequence Number

Lifetime Code Reserved

Care-of-addresses of Foreign Agents

Page 24: Review Session 3

24

Mobility Agent Advertisement

Extension : Fields Length: of the extension message only Sequence Number: message number Lifetime: The longest lifetime (measured in

seconds) that this agent is willing to accept in any Registration Request.

No relation with the same named field in the ICMP Router Advertisement part.

Notes: 1.This field has no relation to the "Lifetime" field within the ICMP Router Advertisement portion of the Agent Advertisement.

2. All 1’s i.e. 0xffff infinite time

Page 25: Review Session 3

25

Mobility Agent Advertisement

Extension : Fields …. 2

Care-of-Addresses: contains the set of available care-of-addresses; the field used by a foreign agent only; At least one Care-of-address must be included in every Agent advertisement.

Code: Each of the bits is used to convey a different message - as defined in the next slide.

Page 26: Review Session 3

26

Mobility Agent Advertisement

Extension : Code Bits

Bit 7: R: registration required; Registration with this foreign agent (or another foreign agent on this link) is required even when using a co-located care-of address. Or co-location of care-of-address may not be allowed.

Bit 6: B: Agent is busy. So FA will not accept registrations from additional mobile hosts.

Bit 5: H: Agent acts as a home agent on the link on which this Agent Advertisement message is sent.

Bit 4: F: Agent acts as a foreign agent. Bit 3: M: Agent uses minimal encapsulation. (slides 26-30) Bit 2: G: Agent uses Generic Routing Encapsulation (GRE). (RFC 1701) Bit 1: r: Unused (0) Bit 0: T: Agent supports reversed tunneling (slide 31)

Page 27: Review Session 3

27

Mobility Agent Advertisement

Extension : Code Bits …..2

In an Agent Advertisement message: 'B' bit MUST NOT be set if the 'F' bit is

not also set. (Only an FA can say that it is busy. A HA must be always available.)

at least one of the 'F' bit and the 'H' bit MUST be set.

‘R' bit MUST NOT be set if the 'F' bit is not also set. (R is set by an FA, when it requires registration from even those mobile hosts, which have co-located Care-of-addresses. R is NOT used by HAs)

Page 28: Review Session 3

28

Mobility Agent Advertisement

Extension : Minimal Encapsulation (RFC: 2004) IP-in-IP: has unnecessary duplication of

several fields between the outer and the inner IP header;

Minimal Encapsulation: attempts to save some space by reducing the size of the inner header to 12 bytes by eliminating duplication

Outer Header: PROTOCOL = 55 for IP-in-IP with minimum

encapsulation TTL: kept the same as in the original IP header

Page 29: Review Session 3

29

Mobility Agent Advertisement Extension : Minimal Encapsulation ……2

Page 30: Review Session 3

30

Mobility Agent Advertisement Extension : Minimal Encapsulation: Minimal Forwarding Header

Page 31: Review Session 3

31

Mobility Agent Advertisement Extension : Minimal Encapsulation: Fields of the Minimal Forwarding Header Protocol: same as in the original IP header. S = 1 (If S = 0, the source address in the Outer header is equal to the

source address in the original IP header. Then this address is not put in the inner header and the length of the inner header reduces to 8)

Reserved: are all zero. Header Checksum: for the minimal forwarding

header onlyNote: 1. While de-encapsulating, the original header is restoredback ( with some changes). 2. ICMP messages from within thetunnel have to be handled with care, since the movement of themobile host is transparent to the RS.

Page 32: Review Session 3

32

Mobility Agent Advertisement Extension : Need for Reversed Tunneling (RFC 3024) The message from the mobile host to

RS goes directly from the foreign network to the RS.

But it carries the source address of the home network.

Due to security considerations, some networks may not allow it.

Need for reversed tunneling from mobile host – to- HA –to- RS

Page 33: Review Session 3

33

Additional Specifications: ICMP Router Advertisement with Agent Extension

Link layer: If the Router Advertisement is in response to a Router solicitation message, it will be unicast to the MAC address of the solicitation message. (ie the MAC address and the IP home address of the mobile host)

IP fields: TTL = 1 The multicast Agent advertisement is sent to

either All systems on the link ( 224.0.0.1) or The Limited broadcast (255.255.255.255)

Page 34: Review Session 3

34

Prefix-Length extension

This extension may follow the Mobility Agent Advertisement Extension.

Page 35: Review Session 3

35

Prefix-Length extension Fields Type: 19 Length: N, where N is the value (possibly zero) of

the Num Addrs field in the ICMP Router Advertisement portion of the Agent Advertisement. Prefix Length(s): The number of leading bits that define the network number of the corresponding Router Address listed in the ICMP Router Advertisement portion of the message. The prefix length for each Router Address is encoded as a separate byte, in the order that the Router Addresses are listed in the ICMP Router Advertisement portion of the message

Page 36: Review Session 3

36

Router ADVERTISEMENT Type: 9 for Router Advertisement Code:

Code = 0 The agent routes common traffic, not related to mobile hosts – in addition to the traffic of the mobile hosts

Code = 16: The agent does not route common traffic.However every FA must forward to a default router any datagrams received from a registered mobile host.

(For a non-agent ICMP router advertisement, Code ia always equal to zero.)

The scheme calls for Periodic Retransmission (Default period=10 minutes) Soft state in that the Router information retained for the

specified lifetime (Default lifetime = 30 minute so that missing one ad message will not lead to discarding the Router )

Page 37: Review Session 3

37

ROUTER ADVERTISEMENT

An Advertisement by a Router tells about it self and all other Routers on the network about

which it is aware. Every Router address, associated with

an integer precedence value given in 2’s complement. A host chooses the route with the highest precedence value.

Page 38: Review Session 3

38

ROUTER ADVERTISEMENT

Thus if PR VAL = 0 -----> DEFUALT

ROUTER PR VAL = 8000 0000 ->should

never be selected as the default router.

Page 39: Review Session 3

39

ROUTER ADVERTISEMENT FORMAT

0 8 16 31

Type code checksum

Num Addr Addr Size Life time

ROUTER ADDRESS 1

PREFERENCE LEVEL 1

R A 2

P L 2

Page 40: Review Session 3

40

ROUTER ADVERTISEMENT: Fields Num ADDRS: The number of address entries

which follow (often 1) For an Agent Advertisement, Num ADDRS can be zero.

ADDR SIZE: The size of an address in 32 bit units (1 for IPv4)

LIFE TIME: The number of seconds for which the Router is

retained, if it is not refreshed (default = 30 min) (The maximum length of time that the

Advertisement is considered valid in the absence of further Advertisements.)

Page 41: Review Session 3

41

ROUTER ADVERTISEMENT Process LIFETIME: No relation with the same

named field in the Agent Advertisement part.

Routers send these messages periodically. Or immediately on receipt of a Router solicitation message.

If the Router and the network support multicast, send to all systems multicast address 224.0.0.1

Otherwise it is broadcast locally.

Page 42: Review Session 3

42

Router Solicitation Message: to find a foreign agent In a foreign network, if a mobile host does not

receive the ICMP Router Advertisement, it can use the ICMP Router Solicitation message to ask for assistance.

An Agent Solicitation message is identical to an ICMP Router Solicitation, except that its IP TTL MUST be set to 1

Rate of sending solicitation messages: Initial rate for 3 messages: one per second Back-off the rate exponentially ( and randomize the

sending instant) till you reach one message per minute.

Page 43: Review Session 3

43

Router Solicitation

Router Solicitation For the addresses of Routers connected

to the n/w.

0 8 16 31Type code checksum

Identifier 16 bits Sequence No 16 bits

Page 44: Review Session 3

44

Router Solicitation (Contd)

TYPE: 10 CODE: 0

If a host supports multicast, send the Router Solicitation message to 224.0.0.2 (address of all Routers) Or it may be broadcast to the local n/w.

(Every few minutes – default value = 10 minutes - a Router advertisement is received .

Router Solicitation used only when Router address is required immediately)

Page 45: Review Session 3

45

Registration of the mobile host The mobile host operating away from home

then registers its new Care-of address with its HA through exchange of a messages with it, possibly via a FA.

Registration on moving to a foreign network With the foreign agent With the home agent ( done by the

foreign agent on behalf of the host) Renew registration, if it has expired.

Deregistration after returning to home net

Page 46: Review Session 3

46

Process of Registration Registration Request: sent by the mobile

host to FA to inform it about The chosen Care-of address HA’s address Home address

FA: On receiving the Registration Request: relays the Request in an IP packet to HA – thus informing HA about FA’s address.

Both HA and FA must approve the Registration Request

Page 47: Review Session 3

47

Process of Registration … 2 For a co-located Care-of-address, the mobile

host sends the Registration Request directly to HA

Two new Formats: Registration Request and Registration Reply

UDP: used for Registration messages with Well-known port 434 for the Agent An ephemeral port by the mobile host

UDP checksum must be used for the Registration messages.

Page 48: Review Session 3

48

Registration Request format

Type = 1 Flag Lifetime

Home address

Home Agent address

Care-of-address

Identification

Extensions….

Page 49: Review Session 3

49

8-bit FLAG: to convey Requests from the Mobile Host and to give forwarding information Bit 7: S: Simultaneous Binding: Request for home

agent to retain its prior Care-of-address: Useful when a mobile host is within the range of two FAs; the HA can then send two copies, one to each of the

Care-of-addresses; the mobile host may then receive two copies of the message.

Bit 6: B: Request that home agent may tunnel any broadcast messages on the home network

Bit 5: D: Mobile host is using co-located care-of-address to decapsulate messages itself.

Bit 4: M: Request for home agent to use minimal encapsulation

Page 50: Review Session 3

50

8-bit FLAG:

Bit 3: G: Request for Generic Routing Encapsulation (GRE)

Bit 2: r: zero; ignored on reception Bit 1: T: Reverse Tunneling

requested Bit 0: x: zero; ignored on reception

Page 51: Review Session 3

51

Other Fields TYPE: 1 for Request and 3 for Reply Lifetime: the number of seconds, the

registration is to remain valid; a string of all zeros Deregistration; a string of all 1’s infinite lifetime

Care-of-address: temporary address of the mobile host

Identification: A 64 bit number sent in Request and repeated in Reply. Used for matching the Request and Reply.

variable length Extensions: for authentication

Page 52: Review Session 3

52

Errors in ExtensionsFor both the Agent extension to the ICMP Router

Advertisement ( slide 23) and the authentication extensions (slide 65): When an Extension with TYPE field -- numbered in the

range 0 through 127 -- is encountered but not recognized, the message containing that Extension MUST be silently discarded.

When an Extension numbered in the range 128 through 255 is encountered which is not recognized, that particular Extension is ignored, but the rest of the Extensions and message data MUST still be processed. The Length field of the Extension is used to skip the Data field in searching for the next Extension.

Page 53: Review Session 3

53

Extensions:1. Mobile Node Network Access Identifier (NAI)

extension 2. Mobile-Home Authentication extension 3. Mobile- Foreign Authentication extension (RFC

2794)

FORMAT of Mobile Node NAI extension

Page 54: Review Session 3

54

Mobile Node NAI extension Fields

Type (1 byte): 131 Length (1 byte): The length in

bytes of the MN-NAI field MN-NAI: A string in the NAI format

(Examples of the Format are given in the next slide.)

Page 55: Review Session 3

55

Network Access Identifiers (NAI) Examples from RFC 2486

Valid NAIs Invalid NAIs

[email protected] [email protected] [email protected] fred=?#$&*+-/^[email protected] [email protected] [email protected] [email protected] eng%[email protected]

fred@foo fred@foo_9.com @howard.edu [email protected]@smallco.com

eng:[email protected] eng;[email protected] <nancy>@bigu.edu

Page 56: Review Session 3

56

Registration Reply Home Agent: sends the Registration reply

to the Foreign Agent To confirm or To deny the registration.

Foreign Agent, then, relays it to the mobile host.

CODE: FLAG in Registration Request is replaced with CODE in Registration Reply.: shows acceptance or denial of request.

Care-of-address field not needed in Reply

Page 57: Review Session 3

57

Registration Reply Format

Type = 3 Code Lifetime

Home address

Home Agent address

Identification

Extensions…

Page 58: Review Session 3

58

Registration Reply Values of Code Registration Successful

0 registration accepted 1 registration accepted, but

simultaneous mobility bindings unsupported

Page 59: Review Session 3

59

Registration denied by HA: Values of Code

128 reason unspecified 129 administratively prohibited 130 insufficient resources 131 mobile node failed authentication 132 FA failed authentication 133 registration Identification mismatch 134 poorly formed Request 135 too many simultaneous mobility bindings

136 unknown home agent address

Page 60: Review Session 3

60

Registration denied by FA: Values of Code 64 reason unspecified 65 administratively prohibited 66 insufficient resources 67 mobile host failed authentication 68 HA failed authentication 69 requested Lifetime too long 70 poorly formed Request 71 poorly formed Reply 72 requested encapsulation unavailable 73 reserved and unavailable 77 invalid care-of address 78 registration timeout 80 home network unreachable (ICMP error received) 81 HA host unreachable (ICMP error received) 82 HA port unreachable (ICMP error received) 88 HA unreachable (other ICMP error received)

Page 61: Review Session 3

61

LifeTime: smaller of LifeTimeRequest & LifeTimeReply

LifeTimeRequest: LifeTime in the Registration Request

LifeTimeReply: LifeTime received in the Registration Reply

If LifeTimeReply > LifeTimeRequest, the LifeTimeRequest MUST be used.

If LifeTimeReply < LifeTimeRequest, the LifeTimeReply MUST be used.

Page 62: Review Session 3

62

Detecting Movement: Algorithm1: Lifetime in Agent

advertisement: If no further Agent advertisement is received and the lifetime expires, the mobile host may Attempt registration with another Agent,

whose advertisement had been earlier received and whose lifetime has not yet expired.

otherwise, attempt to discover a new FA.

Page 63: Review Session 3

63

Detecting Movement: ……. 2 Algorithm 2: It uses the Prefix-Length

extension. However this method is used only when both the current Care-of-address and the new Agent advertisement received by the mobile host have the prefix-length extension.

If the network part of the address should differ, it means that the mobile host has moved to a new foreign agent and it must re-register with a new Care-of-address.

Page 64: Review Session 3

64

Detecting Movement: ……. 2 Returning Home: when it receives the agent

advertisement from its HA. It should reconfigure its routing table and

deregister with its HA and follow the gratuitous ARP procedures if the home network uses ARP.

A mobile host MUST NOT consider reception of an ICMP Redirect from a FA that is currently providing service to it as reason to register with a new FA.

Page 65: Review Session 3

65

Mobile Home Authentication

Page 66: Review Session 3

66

Mobile Home Authentication Fields Type: 32 Length of MHA in bytes SPI Security Parameter Index (4 bytes): specifying

security context available in the Mobility Security Association; Values 0-255 reserved.

Authenticator (variable length) (default: 128 bit Message Digest over (i) UDP payload (ii) all extensions (iii) TYPE, LENGTH and SPI.

Excludes (i) Authenticator itself (ii) UDP header )Note: (i) Mobile-Foreign Authentication: TYPE = 33(ii) Foreign-Home Authentication: TYPE = 34

Page 67: Review Session 3

67

Mobility Security Association

Mobility Security Association: A collection of security contexts, between a pair of nodes. Each context indicates

an authentication algorithm and mode (default: 128 bit key HMAC-MD5),

a secret (a shared key, or appropriate public/private key pair), and

a style of replay protection in use (nonce/time stamp).

Page 68: Review Session 3

68

SIP

Page 69: Review Session 3

69

Session Initiation Protocol (SIP) Application layer signalling protocol used for

establishing sessions in an IP network. A session:

initiated, modified and terminated

by it. But it does not know about the details of a session.

Used for 2-party, multi-party or multicast sessions; or for a simple 2-way telephone call or a collaborative multi-media conference

Page 70: Review Session 3

70

SIP ……2 SIP, like HTTP (RFC 2068), is a

Text-based protocol Uses messages

It is a Request/Response protocol like HTTP and SMTP

SIP "plays nicely" with protocols that are often viewed as overlapping in function. For the near term, SIP will have to coexist with overlapping protocols such as H.323, MGCP, and MEGACO.

Page 71: Review Session 3

71

TCP/IP

STACK+

Page 72: Review Session 3

72

H.323 (ITU standard to allow telephones, on the public telephone network, to talk to computers, connected to Internet) used for local area networks (LANs), but

was not capable of scaling to larger public networks.

Earlier Standard: Media Gateway Control Protocol (MGCP): Converts PTSN audio signals to IP data

packets. is a closed, voice-only standard.

H.248 also called MEGACO: Media Gateway Control Protocol (Megaco) ---

the name used by IETF

Page 73: Review Session 3

73

MEGACO/ H.248 – the name used by ITU-T Study Group 16 MEGACO: a standard protocol for handling

the signaling and session management needed during a multimedia conference.

defines a means of communication between a media gateway, which converts data from the format required for a circuit-switched network to that required for a packet-switched network, and the media gateway controller.

References: 1.RFC 3015 2. http:// searchnetworking.techtarget.com

/ sDefinition/0,,sid7_ gci817224,00.html as of 12th Oct 2006

Page 74: Review Session 3

74

Stream Control Transmission Protocol (SCTP) SCTP: a reliable transport protocol operating on top of

IP. It offers acknowledged error-free non-duplicated

transfer of datagrams (messages). Detection of

data corruption, loss of data and duplication of data

is achieved by using checksums and sequence numbers. A selective retransmission mechanism is applied to correct loss or corruption of data.

Page 75: Review Session 3

75

Difference between SCTP and TCP difference with to TCP: multihoming and

the concept of several streams within a connection. Whereas in TCP a stream is referred to as a sequence of bytes, an SCTP stream represents a sequence of messages (and these may be very short or long).

References: 1. SCTP for beginners http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/index.html as of Oct 12/2006

2. http://www.sctp.org/ 3. RFC2960

Page 76: Review Session 3

76

Uses of SIP enables disparate computers, phones,

televisions and software to communicate. Through SIP, Users can locate and contact one

another regardless of media content and numbers of participants. SIP negotiates sessions so that all participants can agree on and modify session features. It can even add, drop or transfer users.

VoIP telephony voice-enriched e-commerce web page click-to-dial Instant Messaging with buddy lists Rich media conferencing

Page 77: Review Session 3

77

Session Initiation ProtocolSIP does not provide Conference Control. For VoIP,

besides SIP, the following standards and protocols are used:

to ensure transport (RTP), to authenticate users (RADIUS, DIAMETER), to provide directories (LDAP) for location, to be able to guarantee voice quality (RSVP,

YESSIR) to describe the payload of message content and

characteristics: Session Description Protocol (SDP) to describe the characteristics of the end devices.

to inter-work with today's telephone network, many ITU standards

Page 78: Review Session 3

78

A Brief HistoryReference: Understanding SIP: An Ubiquity White paper http://www.sipcenter.com/sip.nsf/html/WEBB5YNVK8/$FILE/Ubiquity_SIP_Overview.pdf

mid-1990s: Henning Schulzrinne, Dept of CS at Columbia University: Research in Multiparty Multimedia Session Control (MMUSIC).

Henning Schulzrinne: A co-author of the Real-Time Transport Protocol (RTP) for

transmitting real time data via the Internet, Real Time Streaming Protocol (RTSP) – a

proposed standard for controlling streaming audio-visual content over the Web.

1996: He submitted the first draft of SIP to IETF

Page 79: Review Session 3

79

A Brief History …..2 1999: Henning Schulzrinne removed

extraneous components regarding media content in a new submission and IETF issued the first SIP specification, RFC 2543.

2001: Updated SIP specification RFC 3261 RFC 3262: governs Reliability of Provisional

Responses; RFC 3263: establishes rules to locate SIP Proxy Servers; RFC 3264: provides an offer/answer model; RFC 3265: determines specific event notification.

Page 80: Review Session 3

80

Addresses: Examples of SIP FormatsSIP: addresses in multiple formats: E-mail address: sip:[email protected] IPv4 address: sip:[email protected] Tel Number: sip:john@519-253-3000SIP uses Session Description Protocol

for details like media encoding, port numbers and multicast addresses etc.

Page 81: Review Session 3

81

Finding the IP address of a Callee

If IP address of a Callee is not known: The Callee not at her/his terminal The Callee connects to Internet

through DHCP and does not have a permanent IP address,

SIP uses a DNS-like mechanism to find it.

Page 82: Review Session 3

82

User Agents (UAs) and Registrar Servers (RS):

UA: end-user device, used to initiate and manage a session. UA Client initiates the session request and UA Server responds to it.

RS: a database containing the location of all user agents within a domain. Every user must be registered with at least one RS at any time. RS knows the IP address of the user.

Page 83: Review Session 3

83

Proxy Servers (PS) and Redirect Servers PS: accepts the request from UAs and

query RS to obtain the addressing information. It then sends the information

to the UA, if it is lying in the same domain. Or to another PS, if the UA is in some other

domain.

Redirect Servers: allow PS to send the session information to external domains.

Page 84: Review Session 3

84

Finding the IP address of the Callee: Using Proxy server and RS

ASSUME: The Caller does not know the IP address of the Callee. But e-mail address of the Callee is known.

Caller sends an INVITE message with e-mail address to the Proxy Server (PS).

PS sends a look-up message to RS. RS responds with the IP address of the

Callee. PS inserts the IP address in INVITE and

sends it to Callee.

Page 85: Review Session 3

85

Messages of SIP SIP MESSAGES: The Caller uses INVITE to

initialize a session.) The Callee answers the call The Caller sends an ACK as a confirmation. BYE: used for termination. OPTIONS: This message queries a machine

about its capabilities. CANCEL: cancels an initialization process,

which had been started. REGISTER: makes a connection, when the

Callee is not available.

Page 86: Review Session 3

86

A SIP SessionEstablishing a connection: (directly or through PS) Caller send INVITE: address + options to

Callee. Callee responds with OK: address. Caller sends ACK message to Callee

Data Transfer: between Caller and Callee through ephemeral ports

Termination: Caller or Callee can send a BYE message to terminate the session.

Page 87: Review Session 3

87

SIP session in the same domain

Page 88: Review Session 3

88

SIP session in the same domain ……2

Page 89: Review Session 3

89

SIP session in dissimilar domains

Page 90: Review Session 3

90

SIP session in dissimilar domains ……2

Page 91: Review Session 3

91

SAP Session: Ref: RFC 3261

Page 92: Review Session 3

92

SIP

SIP may use UDP/TCP/SCTP (Stream Control Transmission Protocol)

References: SIP RFC 3261 http://www.sipcenter.com/sip.nsf/html/What+Is+SIP+Introduction

Page 93: Review Session 3

93

H.323: an ITU standard

Gateway

InternetTelephone Network

Gatekeeper

Page 94: Review Session 3

94

H.323: Definitions

Terminals: computers connected to Internet

Gateway: 5 layer-device, which converts from one type of protocol to another

Gatekeeper: plays the role of Registrar Server

Page 95: Review Session 3

95

H.323uses G.71 and G.723.1 for compression.

Audio Control and Signaling

Compression Code

RTCP

H.225For registration with Gatekeeper

Q.931To set up and to terminate connection

H.245For negotiating about compression protocol

RTP

UDP TCP

IP

Page 96: Review Session 3

96

H.323: Operation Terminal (T) sends a broadcast message

to Gatekeeper (G) G responds with an IP address.

T and G use H.225 to negotiate BW. T,G, gateway and telephone use Q.931 to

set up a connection. T,G, gateway and telephone use H.245 to

negotiate the compression method. T, G and telephone exchange audio using

RTP, under management of RTCP. T,G, gateway and telephone use Q.931 to

terminate the communication.

Page 97: Review Session 3

97

Authentication, Authorization & Accounting (AAA) servicesReference:http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci514491,00.html

An AAA server: a server program that handles user requests for access to computer

resources and provides AAA services for an enterprise.

The AAA server: interacts with ‘network access and gateway servers’ and with ‘databases and directories’ containing user

information. The current standard by which devices or

applications communicate with an AAA server: Remote Authentication Dial-In User Service (RADIUS).

Page 98: Review Session 3

98

RADIUSRef:http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci214249,00.html and RFC 2865

a client/server protocol and software that enables remote access servers to communicate with a central server

to authenticate dial-in users and to authorize their access to the requested system or service.

permits setting up a policy that can be applied at a single administered network point.

Makes it easier to track usage for billing and for keeping network statistics.

Created by Livingston (now owned by Lucent). User profiles for RADIUS: in a central database that

all remote servers can share. Uses UDP port 1812

Page 99: Review Session 3

99

“The use of encrypted passwords appears reasonably secure, in the

absence of serious attention of experts in the field.”

---Morris and Thompson, ‘Password Security: A Case History’ (1979)

Page 100: Review Session 3

100

Procedures

1. USER AUTHENTICATION: PASSWORDS Problem: Password Guessing: Made easier

by the following practices: joe accounts. Accounts that use the account name as the

password. Guest or demonstration accounts that require no

password, or use a well-publicized password. System accounts with default passwords. User who tell their passwords to others.

Page 101: Review Session 3

101

Procedures (continued) Intruder’s method: dictionary guessing: uses a

program that encrypts each word in a dictionary (e.g., /usr/dict/words) and compares each encrypted word to the encrypted password in the /etc/passwd file. Besides the words from a dictionary things known about the target (his name, initials, telephone number, etc.) are also run through the guessing program.

Solution: a password : 6 characters, a random mix of

numbers and letters, that can be remembered easily

Protect the /etc/passwd file. Or use the shadow password file for hiding the

encrypted passwords.

Page 102: Review Session 3

102

Procedures (continued)

The Shadow Password File The encrypted password is stored only in the

shadow password file, /etc/shadow, and not in the /etc/passwd file. Every password field in the /etc/passwd file contains an x, which tells the system to look in the shadow file for the real password. The passwd file is maintained as a world-readable file because it contains information that various programs use.

The shadow file can only be read by root. It only contains passwords and the information needed to manage them.

Page 103: Review Session 3

103

Procedures (continued)

Example:The format of a shadow file entry on a Solaris system is:

username:password: lastchg:min:max:warn:inactive:expire:flag

username: login username password: the encrypted password or NP ( NP: no password because this is

not a login account. System accounts, such as daemon or uucp, are not login accounts, so they have NP in the password field.)

or *LK* for locked accounts that have been disabled from any further use.

Page 104: Review Session 3

104

Password Aging

The following four fields are used for PASSWORD AGING:

Lastchg: the date that the password was last changed, written as the number of days from January 1, 1970 to the date of the change

Min: the minimum number of days that must elapse before the password can be changed

Max: the maximum number of days the user can keep the password before it must be changed

Warn: the number of days before the password expires that the user is warned

Page 105: Review Session 3

105

Password Aging (continued) inactive: the number of days the account

can be inactive before it is locked; Inactivity measured in terms of the number of days the account continues with an expired password

Expire: the date on which the account will be closed; for creating accounts with a specified life-time

Flag: unused.

Page 106: Review Session 3

106

Password Authentication Protocol (PAP) Point-to-Point Protocol (PPP): supports two

authentication protocols: PAP and Challenge Handshake

Authentication Protocol (CHAP). PAP requires clear text PW. If the authentication is at the local host, OK. Otherwise a listener on the line may be able

to find the PW. So the idea of one-time PW, which have to

be used only once.

Page 107: Review Session 3

107

One-time Passwords In

Everything (OPIE) Procedure: With OPIE software loaded on your

machine, supply the old password. The user is asked to select a new secret 10 character password.

Then the system comes out with the following:

1. A one-time PW consisting of a group of six short, uppercase character strings

2. An initial sequence number and the seed

Page 108: Review Session 3

108

OPIE Procedure (continued)

The secret PW, the ISN and the seed can be used on your desktop to generate the next one-time PW.

If one has to go out, one can generate a number of one time passwords.

One time passwords can also be generated with a smart card.

Page 109: Review Session 3

109

Challenge Handshake

Authentication Protocol (CHAP) an advanced authentication system that

can repeatedly re-authenticate a remote system: The procedure:    (i)  The user is sent a randomly generated

string.    (ii)  The user uses a secret PIN and his pass

word to generate a response-string. The authenticator checks the response-

string and authenticates the user.

Page 110: Review Session 3

110

Procedures (continued) 2. APPLICATION SECURITY:

(i) Remove unnecessary software. Any software that allows a remote site to log in

to your system, can be exploited by an intruder.

(ii) Keep the software up-to-date. 3. ACCESS CONTROL: It adds a check to validate the source of a

service request, and retains all of the normal checks to validate the user.TCP wrapper: a software that

logs requests for Internet services, and provides an access control mechanism

Page 111: Review Session 3

111

References1. PPP Authentication Protocols:

http://www.tcpipguide.com/free/t_PPPAuthenticationProtocolsPasswordAuthenticationPr.htm as of 22 Oct 06

2. “PPP Authentication Using the ppp chap hostname and ppp authentication chap callin Commands”: http://www.cisco.com/en/US/tech/tk713/tk507/technologies_configuration_example09186a0080094333.shtml as of 22 Oct 06

3. “Understanding and Configuring PPP CHAP Authentication”: http://www.cisco.com/warp/public/471/understanding_ppp_chap.html as of 22 Oct 06