1 / 32

H. Chaskar, D. Funato, M. Liebsch, E. Shim, A. Singh

Candidate Access Router Discovery Protocol <draft-ietf-seamoby-card-protocol-02.txt> CARD Protocol Issues 17 th July 2003 Seamoby WG meeting, IETF#57, Vienna. H. Chaskar, D. Funato, M. Liebsch, E. Shim, A. Singh. Intro. The protocol draft version 2 covers …

kiona
Download Presentation

H. Chaskar, D. Funato, M. Liebsch, E. Shim, A. Singh

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. Candidate Access Router Discovery Protocol<draft-ietf-seamoby-card-protocol-02.txt> CARD Protocol Issues17th July 2003Seamoby WG meeting, IETF#57, Vienna H. Chaskar, D. Funato, M. Liebsch, E. Shim, A. Singh

  2. Intro The protocol draft version 2 covers … • … split of the protocol into a CORE and a BACKEND part • CORE part covers MN-AR and inter-AR communication • BACKEND part is optional, two proposals are described in the document’s appendix • … description of CARD protocol functions • … protocol encoding section • … application scenarios, …etc. The protocol review brought up some issues… … here they are: https://roundup.machshav.com/seamoby/index

  3. Issue#2: R-flag for CARD Request rate limiting • Category: Technical • Issue: Use a flag to indicate exceeding request rate (kind of flow-control from AR to MN - proposed in the current draft) or should a MN know in advance about the maximum allowed request rate? • Further comments: • Should not be a static value, since this could be different for individual ARs. • Henrik Petander: “Describe MN behavior after receiving a CARD Reply having the R-flag set. Why not using normal ICMP rate limiting?” • Request limitation could also be used between ARs! • Question: Is a per-MN state for DoS protection allowed? If yes, then… • …proposal is: • Keep the R-flag approach. Add clarifying text to section 4.2 (4.3?) • Or: Allow different ARs to configure different rates - specify CARD parameter for this purpose to notify MNs in advance.

  4. Issue#4: Drop CARD protocol message piggybacking with FMIPv6? • Category: Technical • Issue: Should CARD protocol message piggybacking and respective piggybacking capability indication be in scope of this CARD protocol specification? • There was early feedback from WG advocating CARD/FMIPv6 operation! • Proposal: • Keep mechanisms for CARD protocol operation with FMIPv6 • Discuss with FMIPv6-folks on application scenarios

  5. Issue#33: Inter-AR CARD protocol transport: UDP vs. ICMP • Category: Technical • 5.2.1 Protocol Transport "For the CARD protocol operation on the network side between a MN's current AR and CARs, UDP [9] is used as transport for CARD protocol messages. The associated UDP port for the CARD protocol operation is T.B.A." • Comment: “… why not ICMP between the Access Routers? Concern is when a router receives a CARD Request message, it needs separate processing in both ICMP and UDP modules.” • Clarification: ICMP not a real transport protocol, UDP is. However, ICMP has been chosen for FMIPv6 consistency (see issue#4)… • Proposal: Keep ICMP on MN-AR interface in case FMIPv6 transport is taken into account. To make it consistent, ICMP could also be used for inter-AR communication. Also discuss with issue#4. (somehow open….)

  6. Issue#5: Static vs. dynamic capability attributes • Category: Technical • Current draft proposes to drop lifetime field in the capability AVP parameter for "static" capabilities. This is to save 32 bit for each static capability and is indicated with a flag in the capability parameter header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code |S| Res | AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Lifetime (present if S = 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - • Issue is … Protocol overhead versus processing complexity (…?). • Proposal: Keep the S-bit and allow for using 32-bit Lifetime field only when really required for dynamic capabilities. Saves N x 32bit for N static capabilities!

  7. Issue#6: Unsolicited CARD Reply message broadcast/multicast • Category: Technical • Issue is… addressing scheme should be different for IPv4 and IPv6. • Comments: “More text is required on unsolicited CARD Reply message distribution from ARs. Current draft indicates "broadcast” as addressing scheme. Should "multicast" be proposed? Guidelines needed: Default inter-message time, port number (in case of UDP), ... Furthermore, why is explicit marking of unsolicited CARD Replies required?” • Proposal: MN-AR:“broadcast” address for IPv4 “all-nodes-on-this-link multicast address ” for IPv6 AR-AR: Add unsolicited CARD Reply unicast. • Furthermore: Add details, like a proposed default inter-message time for MN-AR interface.

  8. Issue#12: Link layer triggers for unsolicited CARD Reply • Category: Technical • section 3.2: Discovery of CAR Capabilities "...the current AR either periodically transmits address and capability information of CARs to the MNs over download channels, or link-layer mechanisms trigger unsolicited transmission of CARs' address and capability information." Comment: “…what is this L2 trigger which makes the AR send out unsolicited information? The way I see it, unsolicited information is typically sent using a timer or when there is a significant change in the capability information.” • Proposal: Initially intended for discussion. Delete description on link layer triggers for sending unsolicited CARD Reply messages. This is implementation specific and not required in the document.

  9. Issue#17: Preferences / Requirements sub- options. Use only one of them? • Category: Technical • Preferences sub-option for capability filtering (attribute list), and Requirements sub-option for CAR filtering (attribute-value pair list): Recommendation: Use only one of them! • Proposal 1: Either use only one of them and indicate in the capability (A-flag ?) if AV-pair (Requirements) or only the Attribute (Preferences) will follow. Capability encoding rule:  0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code |S|A|Res| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Lifetime (present if S = 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - • Proposal 2: Keep Requirements and Preferences sub-option separated (just an additional sub-options type) and avoid additional processing of flags.

  10. Issue#18: Requesting ARs to perform ONLY reverse address translation • Category: Technical • section 4: CARD protocol operation • The MN must be allowed to indicate to its current AR that only reverse address translation without capability discovery is to be performed. Supporting this is essential. • Proposal: Agree and specify a flag (R-flag) in CARD Request message, indicating to ARs that only reverse address translation is to be performed. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |P|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -

  11. Issue#23: Protection of broadcast unsolicited CARD Reply messages • Category: Technical • Comments: • A broadcast unsolicited CARD Reply message cannot beprotected with IPSec. • How are SAs to be established? • Same problem appears for other protocols (Router Advertisements) • Proposal: • Use public/private keys here for digital signatures. • Distribute keys in advance via CARD! But: …. Processing costs of digital signatures is still an issue!!! Hence, unsolicited broadcast should not be the default mechanism for CARD!

  12. Issue#25: Addressing of unicast CARD protocol messages • Category: Technical • Section 5.1.1 CARD main header format Source/Destination address type: • Are link local addresses okay? • Use global address for IPsec protection more appropriate? • Link local addresses on both the old link and the new link would be same. OTOH, if unsolicited CARD Reply messages are sent….(???) • Proposal: Since MN-AR CARD is always only single hop, link-local should be ok for IPv6, also with regard to IPsec. Agreed, that detailed description would be useful. Make this clear in the next update.

  13. Issue#36: Removal of per-session state from ARs • Category: Technical • Comment raised by Henrik: Simplify the AR by removing AR-AR retransmission scheme and restrict state maintenance in ARs to CAR table maintenance. • Number of requests at a time is not number of MNs! • Proposal: Keep signaling failure recovery on AR-AR interface, but make it optional (“MAY”). • Agreement on the mailing list. Comments?

  14. Issue#39: Further detail on signaling failure recovery required • Category: Technical • Comment raised by Henrik: “The draft should clearly specify what the MN's current AR sends to the MN in case of not being able to resolve a L2 ID. In addition, description is needed on what a CAR sends to an AR in case a queried L2 ID is not attached to it.” • Proposal: Agree and put an error code or appropriate indication flag in the L2 ID sub-option.

  15. Issue#40: 8 bit CARD options length not enough • Category: Technical • Comment raised by Henrik: “Is 8 bits enough for the CARD option length field? This translates to 255 octets, which seems limiting to me, especially since the capabilities have not been defined. Also the AVP encoding rules in 5.1.4 have a 16-bit length field, which conflicts with the fact that they still need to fit within the options with 8-bit length fields. AR - AR message format in 5.2.2 includes a length field which is redundant with UDP's length field and should be removed.” • Proposal: Agree and extend Length field in CARD Request/Reply message to 16 bit (still units of octets).

  16. Issue#1: Standards language in Experimental RFCs • Category: Editorial • Standards language (MUST/SHOULD...) appropriate for Experimental RFCs? Different opinions w.r.t this issue. Should be clarified and modified in the document in case this is a serious requirement from IESG. • Clarification: Many Experimental and Informational RFCs use this type of language. Makes the protocol clearer. • Proposal: Keep RFC 2119 standards language, since it makes even an “experimental protocol” clearer, but think about SHOULD/MUST thoroughly and take related review comments into account. • Status: Checked with IESG, agreed and closed.

  17. Issue#7: Separate appendix from the CARD protocol specification • Category: Editorial • Excessive appendix could be separated from the core protocol specification. • Pros and cons to be discussed. Compromise could be to focus on protocol specific aspects of backend protocol extension, as described in the appendix, and to separate respective discussion on security considerations etc. to a separate doc. • Proposal: Keep the optional protocol extensions in the appendix. Provides a framework to solutions for additional features and addresses further work.

  18. Issue#22: Specification of IPSec requirements (section 4.3.2) • Category: Editorial • section 4.3.2 Current AR operation "...The MN's current AR SHALL use the IPsec ESP for authenticating the AR-AR CARD Request. The IPsec ESP MAY be also used for encrypting the capability information." • Comment: Specify IPsec requirements in a different way. • Proposal: Agree and modify text. Explicitly refer to use of IPsec ESP with a non-null integrity and origin authentication (MUST). Further refer to optional use of a non-null encryption algorithm for protecting data confidentiality (SHOULD).

  19. If there is remaining time, …… some more issues need to be discussed:

  20. Issue#29: More text on use of "Context-ID" and "M-flag"required • Category: Editorial • section 5.1.3.1 L2 ID sub-option: Comment: Not clear from text how the Context-ID and M-flag are used. • Proposal: Discuss the Context-ID and M-flag first to make function clear. Add clarifying text to the document in case mechanisms are accepted.

  21. Issue#19: CAR table MUST or SHOULD maintain CARs' capabilities? • Category: Editorial • section 4.1: Conceptual data structures "...ARs SHALL also keep and maintain individual CARs’ capabilities in the local CAR table, taking the associated capability lifetime into account…”. • Comment: SHOULD is enough. There might be a system where all Access Router have the same capabilities and all needed is a L2 ID to IP address mapping. • Proposal: Agree and modify text.

  22. Issue#30: L2 type indicators to be assigned by IANA • Category: Editorial • section 5.1.3.1 L2 ID sub-option "... L2 type field: Indicates the interface type (optional) (Ethernet, IEEE802.11b, ...)." • Comment: These need to be allotted IANA types. This is not mentioned in the IANA considerations section. • Proposal: ??? (If we request IANA to assign types, we need to give a list of technologies… )

  23. Issue#8: IANA consideration section issues • Category: Editorial • Comments on guidelines to IANA on CARD protocol main header type assignment and inter-AR protocol UDP port assignment. No IETF consensus required, just let IANA assign. • Proposal: Accept. Guidelines for IANA in IANA consideration section needs to be adjusted.

  24. Issue#38: Current AR capabilities in inter-AR CARD Request • Category: Technical • Comment raised by Henrik Petander: “Don't push current AR capabilities to CARs with AR-AR CARD Request. Avoid extra complexity and overhead (load, authentication, encryption).” • Clarification: Could save time and bandwidth resources during a solicited CARD Request/Reply scenario, since the CAR’s CAR table entries have been kept up to date. • Proposal: Make it optional (“MAY”). This allows operators to choose and to enable this feature when desired. • Agreement on the mailing list. Comments?

  25. Issue#28: 4n alignment for CARD options • Category: Editorial • 5.1.2.1/5.1.2.2 CARD Request option/CARD Reply option • Comment by Vijay Devarapalli to mention alignmentrequirement of 4n. • Proposal: Agree and add appropriate text to 5.1.2.1 and 5.1.2.2.

  26. Issue#32: 8n+4 alignment for the (IPv6) address sub-option • Category: Editorial • 5.1.3.5 Address Sub-Option • Comment by Vijay Devarapalli to mention alignmentrequirement of 8n+4 in case of a present IPv6 address.. • Why n x 64 bit boundary? • Proposal: Put a general comment into “5.1.3 CARD Sub-Options format” to indicate that all sub-options MUST be aligned to 32 bit boundary.

  27. Issue#9: Reverse address translation - CARD vs. FMIPv6 • Category: Technical • Comment on section 3.1 Reverse address translation:“How does this fit in with the ProxyRtrSolicit and ProxyRtrAdvert in FMIPv6? FMIPv6 already does Reverse Address Translation through these two messages.” • Clarification: CARD provides more information (CARs’ capabilities) and allows resolution of multiple L2 IDs to CARs’ IP addresses.Thus time and scarce (radio) bandwidth will be saved. • Proposal: Discuss with issue#4.

  28. Issue#10: Performing CARD with CARs directly via available IP connectivity • Category: Technical • section 3.1: "...In cases where the MN can acquire IP connectivity with CARs prior to making handover decisions, this functionality is trivially realized, since the MN can request CARs individually for reverse address translation.” • Comment: In this case, is Router Solicitation and Router Advertisement is used for reverse address translation? What is needed for CARD messages here? • Proposal: Clarifying text proposed on the mailing list, which refers to capability discovery function to be performed with CARs directly, not reverse address translation! (Actually an editorial issue). • Hence: Accept, adjust the text and the issue should be resolved.

  29. Issue#24: Combined section for "CARD signaling failure recovery" • Category: Editorial • section 4.4: CARD signaling failure recovery • Comment: Since both MN and AR follow the same procedure, describe signaling failure recovery only once. • Proposal: Accept, if issue 36 will be rejected.

  30. Issue#37: Caching CAR information on MNs • Category: Technical • Comment raised by Henrik Petander: Caching of CAR information at MNs could accelerate the handover process, since it avoids to request same info again. • Proposal: Agree and add text to section 4.1 on Conceptual Data Structures.

  31. Issue#34: Preferences sub-option for inter-AR CARD operation • Category: Editorial • section 5.3 Overview on sub-options'/payload types' usage • Comment: Use of Preferences sub-option between ARs is indicated in the overview table, but not described in the protocol operation section. • Clarification: The Preferences sub-option can be optionally used during inter-AR capability discovery for capability pre-filtering. • Proposal: In case the filtering mechanism is accepted, make it optional and provide clarifying text in the protocol operation section 4.3, which covers the description of the inter-AR protocol operation.

  32. Issue#35: Choice of CARD message transport in general • Category: Editorial • Comment raised by Henrik Petander: "...Without piggybacking it would be simpler to run both MN-AR and AR-AR protocols over UDP and use the same message formats." • Clarification: Using the same transport for MN-AR and AR-AR has advantages. Whether to use ICMP or UDP depends on whether or not CARD message transport with FMIPv6 should be taken into consideration. This needs to be discussed and decided ASAP, hence, issue#4 is to be resolved. • Overlaps and depends on how issue#4 will be resolved.

More Related