candidate access router discovery protocol card protocol issues 17 th july 2003 seamoby wg meeting,...

Candidate Access Router Discovery Protocol<draft-ietf-seamoby-card-protocol-02.txt>

CARD Protocol Issues

17th July 2003Seamoby WG meeting, IETF#57, Vienna

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

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

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.

Issue#4: Drop CARD protocol messagepiggybacking 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

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….)

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!

Issue#6: Unsolicited CARD Reply messagebroadcast/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

IPv6AR-AR: Add unsolicited CARD Reply unicast.

• Furthermore: Add details, like a proposed default inter-message time for MN-AR interface.

Issue#12: Link layer triggers for unsolicitedCARD 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.

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.

Issue#18: Requesting ARs to perform ONLYreverse 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -

Issue#23: Protection of broadcast unsolicitedCARD Reply messages


• Comments:– A broadcast unsolicited CARD Reply message cannot be

protected 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!

Issue#25: Addressing of unicast CARD protocolmessages

• 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.

Issue#36: Removal of per-session state from ARs


• 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?

Issue#39: Further detail on signaling failure recovery required



“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.

Issue#40: 8 bit CARD options length not enough



“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).

Issue#1: Standards language inExperimental 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.

Issue#7: Separate appendix from the CARDprotocol specification


• 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.

Issue#22: Specification of IPSec requirements(section 4.3.2)


• 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).

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

Issue#29: More text on use of "Context-ID" and"M-flag"required


• 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.

Issue#19: CAR table MUST or SHOULD maintain CARs' capabilities?


• 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.

Issue#30: L2 type indicators to be assigned byIANA


• 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… )

Issue#8: IANA consideration section issues


• 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.

Issue#38: Current AR capabilities in inter-ARCARD Request


• 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?

Issue#28: 4n alignment for CARD options


• 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.

Issue#32: 8n+4 alignment for the (IPv6) addresssub-option


• 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.

Issue#9: Reverse address translation - CARD vs.FMIPv6


• 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.

Issue#10: Performing CARD with CARs directlyvia 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.

Issue#24: Combined section for "CARDsignaling failure recovery"


• 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.

Issue#37: Caching CAR information on MNs


• 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.

Issue#34: Preferences sub-option for inter-ARCARD operation


• 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.

Issue#35: Choice of CARD message transport ingeneral


• 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.

candidate access router discovery protocol card protocol issues 17 th july 2003 seamoby wg meeting,...

Documents