Update on Mobility Services Framework Design Document Gabor Bajko, Subir Das, Nada Golmie, Telemaco Melia, JC Zuniga IETF-72, Dublin, Ireland

2 Outline Update on draft-ietf-mipshop-mstp- solution-05 Update of draft-ietf-mipshop-mos-dhcp- options-04 Update of draft-ietf-mipshop-mos-dns- discovery-01 Few words about draft-stupar-dime- mos-options-00

3 Terminology MoS – Mobility Services MIH – Media Independent Handover MIHF – Media Independent Handover Function MSTP – Mobility Services Transport Protocol MSFD – Mobility Services Framework Design MoSh – Mobility Services at Home network MoSv – Mobility Services at visited network

4 Draft-ietf-mipshop-mstp-solution: Summary ID status Most of the AD review addressed Next few slides Draft v05 already reflects these changes Few remaining issues from AD review Back-off retransmission Gorry’s comment on backoff mechanism was already included in version 05 (Ref: Gorry’s from 8/6/2008) DHCP Authentication Link layer security clarification Integrated scenario support (NAS/DHCP) Need to gather WG consensus to finalize the document Additional issue Number of Ports for MIH Services Driven by implementation experience in Rogers, Vodafone networks

5 Draft-ietf-mipshop-mstp-solution (contd..) Issue# 1: The assumption about MoS location Comment: Is there a need to state that ES/CS is more likely to be associated with a visited network than home? Modified Text: (Section 3.3) This document does not make any assumption on the location of the MoS (although there might be some preferred configurations), and aims at flexible MSFD to discover different services in different locations to optimize handover performance. MoS discovery is discussed in more detail in Section 5.

6 draft-ietf-mipshop-mstp-solution (contd..) # Issue 2: MoS configuration Comment: Text needs to be written in a much more detailed and specification-like manner Remedy: Text reworked and modified in Section 4

7 draft-ietf-mipshop-mstp-solution (contd..) Issue #3: MoS authorization Comment: Can we end up in a situation where DHCP discovery delivers a server address which refuses to talk to us, for instance? Modified text: (Section 5) In case future deployments will implement authorization policies the mobile node should fall back to other learned MoS if authorization is denied.

8 draft-ietf-mipshop-mstp-solution (contd..) Issue #4: Scenario 2 (DHCP + DNS) Comment: A lot of complexity Modified text: (Section 5.2) Text reworked and modified in Section 5.2

9 draft-ietf-mipshop-mstp-solution (contd..) Issue #5: MoS in 3 rd party networks Comment: Can this document point to specific attributes defined in IEEE that would carry such information? Modified text: (Section 5.3) IEEE defines information elements such as OPERATOR ID and SERVICE PROVIDER ID which can be a domain name. Text reworked and modified accordingly in Section 5.3

10 draft-ietf-mipshop-mstp-solution (contd..) Issue #6: MIH MoS capabilities Comment: The document does not talk about how servers know the capabilities of clients that send event/command services to. Is this a part of the IEEE definitions, and you subscribe to a particular event stream? In any case, the document should talk about this and point to the relevant other specifications where needed. Added text: (Section 6) Once the Mobility Services have been discovered, MIH peers may run a capability discovery and subscription procedures as specified in IEEE if not discovered via either DNS or DHCP.

11 draft-ietf-mipshop-mstp-solution (contd..) Issue #7: MoS message framing Comment: The document is very silent on how MIH messages are carried on a given transport protocol. At the very least the draft should indicate that no extra framing is needed because IEEE specs already contain a length field. Modified text: (Section 4) The usage of transport protocols is described in Section 6 and packing of the MIH messages does not require extra framing since the MIH protocol defined in IEEE already contains a length field.

12 draft-ietf-mipshop-mstp-solution (contd..) Issue #8: MIH message size/fragmentation Comment: be more specific about MIH message size/fragmentation Remedy: Text reworked and modified in Section 6.1

13 draft-ietf-mipshop-mstp-solution (contd..) Issue #9: TCP and fragmentation of MIH messages Comment: True, TCP can split the message, but is this really the cause of delay. If one uses the PUSH bit, then the records should be sent, even when no more data follows? Added text: (Section 6.1) The use of the PUSH bit can alleviate this problem by triggering transmission of a segment less than the SMSS.

14 draft-ietf-mipshop-mstp-solution (contd..) Issue #10: Token bucket parameters Comment: I think this commentary effectively says very little, and so leaves it for operators to choose to do what they like. I'd suggest this is not good practice. It seems to recognize a problem, but be unwilling to address it. Modified text: (Section 6.2) Recommendations for token bucket parameter settings are as follow: If MIHF knows the RTT, the rate can be based upon this If not, then on average it SHOULD NOT send more than one UDP message every 3 seconds.

15 draft-ietf-mipshop-mstp-solution (contd..) Issue #11: Back-off retransmissions Comment: So, is the UDP retransmission backed-off at all, as recommended in: tsvwg-udp-guidelines-07 - If the number of retransmissions is limited, what specifies this limit? Modified text: (Section 6.3) The default number of retransmissions is set to 2 and retransmissions are controlled by a timer with a default value of 10s. No backoff mechanism is specified.

16 draft-ietf-mipshop-mstp-solution (cnt’ed) Issue #12: Keep alive messages Comment: This is too vague. Added text: (Section 6.4) Re-registration or Event indication messages as defined in IEEE MAY be used for this purpose.

17 draft-ietf-mipshop-mstp-solution (cnt’ed) Issue #13: Security recommendation on IPsec Comment: I do not see a particular requirement for IPsec here, why do we need to include it? Suggested Remedy: Removed recommendation for IPsec from the document

18 draft-ietf-mipshop-mstp-solution (cnt’ed) Issue #14: Security recommendation on TLS/DTLS Comment: The explanation on how to use TLS and DTLS seems thin. Is there something to be said about what type of certificates or infrastructure is needed, what modes of operation are allowed, etc? Remedy: Text reworked and modified in Section 8

19 Draft-ietf-mipshop-mstp-solution: Remaining Issues from AD review Issue #1: Back-off retransmissions Comment: In Gorry's review he pointed out that the UDP usage guidelines document recommends an exponential back-off mechanism. The mstp draft deviates from this, and I'm not sure its appropriate to do so. Note that the guidelines had only a recommendation, not a requirement. But its not clear that you actually want to avoid an exponential back-off. Its easy to think of situations (such as the base station going down) where there would be a significant amount of retransmission traffic from a large number of hosts. Suggested Remedy: Already addressed (Issue #: 11) Gorry’s comment: “Sounds fine (10 seconds seems large enough to me). I suggest you add your text.”

20 Draft-ietf-mipshop-mstp-solution: Remaining Issues Contd.. Issue #2: DHCP authentication Comment: I think the overall recommendation is good, but practically no one is going to deploy RFC With this in mind, I would like to see the above paragraph explain in more detail the security implications of relying on link layer security. Suggested text (colored): In the case where DHCP is used for node discovery and authentication of the source and content of DHCP messages is required, network administrators SHOULD use DHCP authentication option described in [RFC3118], where available or rely upon link layer security. This will also protect the DHCP server against denial of service attacks since [RFC3118] provides mechanisms for both entity authentication and message authentication. In case where DHCP authentication mechanism is not available administrators may need to rely upon underlying link layer security. In such cases the link between DHCP client and server may be protected but the source and DHCP messages can not be authenticated unless there exits a security binding between link layer and DHCP layer.

21 Draft-ietf-mipshop-mstp-solution: Remaining Issues Contd.. Issue #3: Roaming MoS scenario Comment: But the big question for me was whether it is appropriate to employ DHCP-AAA binding so that per-MN information can be provided. I realize that we have done it once in the context of the Mobile IP bootstrapping work. But frankly, that sets a very high bar for deployment in a given access network and introduces dependencies and complexity that is undesirable. In general, if every application that wants to avoid configuration needs to have special support in DHCP relays, it becomes very hard to deploy anything new. Suggested Remedy: See next few slides and let’s discuss

22 Integrated Scenario: Current State Visited | Home | | | | | | | |AAAV | | |AAAH | | | | | | | | | | | | | | | | | | MoSh | | | | |DHCP | | | MN |------| NAS/|----|Server| | | DHCP| | | | |Relay| | | | | | AAAv -- Visited AAA AAAH -- Home AAA NAS -- Network Access Server Very similar to the MIP6 integrated scenario Convey MoS information to the NAS during network authentication Store the information into the DHCP relay Provide the MN with the assigned MoS (network based) during IP address Configuration Do we want a method to configure MNs in visited networks with (MoS) services provided in the home network?

23 Integrated Scenario: Approach I Visited | Home | | | | | | | |AAAV | | |AAAH | | | | | | | | | | | | | | | | | | MoSh | | | | | MN |------| NAS | | | | | | AAAv -- Visited AAA AAAH -- Home AAA NAS -- Network Access Server Convey MoS information to the NAS during network authentication NAS delivers the MoS information via link layer or other mechanisms that are out of scope of this document Note: It does not provide a complete solution since there will be no IETF specific solution to deliver the MoS information from the NAS to the MN

24 Integrated Scenario: Approach II Visited | Home | | | | | | | |AAAV | | |AAAH | | | | | | | | | | | | | | | | | | MoSh | | | | |DHCP | | | MN |------| NAS/|----|Server| | | DHCP| | | | |Relay| | | | | | AAAv -- Visited AAA AAAH -- Home AAA NAS -- Network Access Server - This option is currently in the Annex of v05 and can co-exist as an option in addition to solution I - Conveys MoS information to the NAS during network authentication - Store the information into the DHCP relay - Provide the MN with the assigned MoS (network based) during IP address Configuration Note: This is not specific to MSTP and MoS discovery, seems to be a general issue within IETF

25 Draft-ietf-mipshop-mstp-solution: Remaining Issues Contd.. Additional Issue: Number of Ports Problem: Current specification mandates the use of three different ports, keep-alive messages for NAT traversal on three different ports are an issue. Too many messages to send. Suggested Remedy: Update the ID and register one default port number with IANA for all services

26 Update of draft-ietf-mipshop-mos-dhcp- options-04 Version -04 is available at mos-dhcp-options-04 mos-dhcp-options-04 Changed from multiple DHCPv4 options to one DHCPv4 option and added several sub-options Encoding types are kept unchanged ‘enc’ byte ‘0’  Domain name list ‘enc’ byte ‘1’  IPv4 address list

27 Update of draft-ietf-mipshop-mos-dhcp- options-04 DHCPv6 has two Options IPv6 MoS Identifier Option IPv6 MoS information Option MoS Information Option has several sub-options Moved all Relay Agent options to Appendix May be removed depending upon the outcome of the discussion of Integrated scenario

28 Update of draft-ietf-mipshop-mos-dns- discovery-01 Defines new application tags to discover MIH services (IS, CS, ES) accessible using certain transport protocols (e.g., UDP, TCP, SCTP) Currently the draft says that new services and new transports may be registered with IANA on an FCFS basis

29 Comment # 1 Yoshihiro Ohba: New transports may be registered on an FCFS basis, but new services should be defined by standards track RFCs Clarify that messages belonging to ‘Service Management’ type are considered ES or CS types when L3 transport is used The new version will incorporate the proposed changes

30 Comment # 2 Review received from Thomas Narten on 7/24 Comments mainly on the exceptions to the rule defined in the doc, some of them being added as a result of previous comments The comments are going to be discussed on the mailing list and the draft will be updated accordingly No additional comments were received

31 Draft-stupar-dime-mos-options Addresses AAA extensions required for Integrated Scenario defined in the solution draft Defines AVP extensions to convey Mobility Services information and its capability ID presented in DIME, to be considered for DIME charter, if required by MIPSHOP