1 / 31

Update on Mobility Services Framework Design Document

Update on Mobility Services Framework Design Document. Gabor Bajko, Subir Das, Nada Golmie, Telemaco Melia, JC Zuniga. IETF-72, Dublin, Ireland. Outline. Update on draft-ietf-mipshop-mstp-solution-05 Update of draft-ietf-mipshop-mos-dhcp-options-04

taryn
Télécharger la présentation

Update on Mobility Services Framework Design Document

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 email 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 3rd party networks • Comment: Can this document point to specific attributes defined in IEEE that would carry such information? • Modified text: (Section 5.3) • IEEE 802.21 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 802.21 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 802.21 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: http://tools.ietf.org/html/draft-ietf-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 IEEE802.21 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 3118. 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 http://tools.ietf.org/html/draft-ietf-mipshop-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

More Related