Candidate Access Router Discovery Protocol draftietfseamobycardprotocol02'txt CARD Protocol Issues 1

1
Candidate Access Router Discovery
Protocolltdraft-ietf-seamoby-card-protocol-02.txtgt
CARD Protocol Issues17th July
2003Seamoby WG meeting, IETF57, 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 documents 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/s
  eamoby/index

3
Issue2 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
Issue4 Drop CARD protocol message piggybackin
g 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
Issue33 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 issue4)
• 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
  issue4. (somehow open.)

6
Issue5 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
Issue6 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-ARbroadcast 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
Issue12 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
Issue17 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 SARes 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
Issue18 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 PR
  Reserved
• ------------------------
  --------
• Sequence Number
  
• ------------------------
  --------
• Sub-Options
• -------------- - - -

11
Issue23 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
Issue25 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
Issue36 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
Issue39 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
Issue40 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
Issue1 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
Issue7 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
Issue22 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
Issue29 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
Issue19 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
Issue30 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
Issue8 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
Issue38 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 CARs 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
Issue28 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
Issue32 8n4 alignment for the (IPv6)
address sub-option

• Category Editorial
• 5.1.3.5 Address Sub-Option
• Comment by Vijay Devarapalli to mention
  alignmentrequirement of 8n4 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
Issue9 Reverse address translation - CARD
vs. FMIPv6

• Category Technical
• Comment on section 3.1 Reverse address
  translationHow 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 issue4.

28
Issue10 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
Issue24 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
Issue37 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
Issue34 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
Issue35 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, issue4 is to be resolved.
• Overlaps and depends on how issue4 will be
  resolved.