for the router possessing the chain with the Context-ID field set to
a nonzero value, and with no other sub-options. Any other sub-
options included in a CARD Reply SHOULD be ignored. If the reply
spans multiple ICMP messages, the L2 ID sub-option and router Address
sub-option MUST be included in the first message sent, and the
Context-ID field in the Router Certificate sub-options in all the
messages MUST be set to the same value as that in the L2 ID and
Address sub-options. The replying AR SHOULD order the returned
certification path so that the certificate immediately after the
trust anchor in the path is the first certificate sent, in order to
allow immediate verification. The trust anchor certificate itself
SHOULD NOT be sent.
5.1.4. Capability AVP 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 | AVP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Lifetime | Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
AVP Code: Identifies the attribute uniquely. The AVP Code
0x0000 is reserved and MUST NOT be assigned to a
capability.
AVP Length: The 2 octet AVP length field indicates the number of
octets in this AVP, including the AVP Code, AVP
Length, Reserved, Lifetime, and Data fields.
Reserved: Initialized to zero, ignored on receipt.
Lifetime: Specifies the lifetime of the encoded capability in
seconds. In the case of a static capability, the
Lifetime field MUST be set to the maximum value
(0xffff), which indicates that the lifetime of this
capability parameter never expires. A lifetime value
of 0x0000 deletes a capability entry.
Data: This variable-length field has the Value of the
capability attribute encoded.
Because an AVP Code of 0x0 is reserved, it can be used by the sub-
option list parsing to determine when the end of a list of
Capabilities has been reached and where the sub-option padding
starts. AVPs themselves are not zero padded.
Note: This document provides no detailed information on how to encode
the individual capability attribute values, which is to be encoded in
the Data field. Details on the interpretation of individual
capability parameters are out of the scope of this document.
5.2. CARD Inter-Access Router Messages
5.2.1. AR-AR Transport
Because the types of access networks in which CARD might be useful
are not currently deployed or, if they have been deployed, have not
been extensively measured, it is difficult to know whether congestion
will be a problem for inter-router CARD. Part of the research task
in preparing CARD for consideration as a candidate for possible
standardization is to quantify this issue. However, in order to
avoid potential interference with production applications (should a
prototype CARD deployment involve running over the public Internet),
it seems prudent to recommend a default transport protocol that
accommodates congestion.
This suggests that implementations of CARD MUST support and that
prototype deployments of CARD SHOULD use the Stream Control Transport
Protocol (SCTP) [Stew00] as the transport protocol between routers,
especially if deployment over the public Internet is contemplated.
SCTP supports congestion control, fragmentation, and partial
retransmission based on a programmable retransmission timer. SCTP
also supports many advanced and complex features, such as multiple
streams and multiple IP addresses for failover, that are not
necessary for experimental implementation and prototype deployment of
CARD. The use of these SCTP features for CARD is not recommended at
this time.
The SCTP Payload Data Chunk carries the CARD messages. CARD messages
on the inter-router interface consist of just the CARD Request or
CARD Reply options. The User Data part of each SCTP message contains
the CARD option for the message type. For instance, a CARD Reply
message is constructed by including the CARD Reply option and all the
appropriate sub-options within the User Data part of an SCTP message.
A single stream is used for CARD with in-sequence delivery of SCTP
messages. Each message, unless fragmented, corresponds to a single
CARD query or response. Unsolicited CARD Reply messages can also be
sent to peers to notify them of changes in network configuration or
capabilities. A single stream provides simplicity. Use of multiple
streams to prevent head-of-line blocking is for future study. Since
timeliness is not an issue with inter-router CARD, and since there
being more than one CARD transaction between two routers active at
any one time is unlikely, having ordered delivery simplifies the
implementation. The Payload Protocol Identifier in the SCTP header
is ’CARD’. CARD uses the Seamoby SCTP port number [Ke04].
The format of Payload Data Chunk taken from [Stew00] is shown in the
following diagram.
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 = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
’U’ bit The Unordered bit. MUST be set to 0 (zero).
’B’ bit The Beginning fragment bit. See [Stew00].
’E’ bit The Ending fragment bit. See [Stew00].
TSN Transmission Sequence Number. See [Stew00].
Stream Identifier S
Identifies the CARD stream.
Stream Sequence Number n
Sequence number. See [Stew00].
Payload Protocol Identifier
Set to ’CARD’.
User Data Contains the CARD message.
In order to avoid generating congestion on startup, ARs MUST wait a
random amount of time between 0 and CARD_STARTUP_WAIT seconds upon
reboot before sending an AR-AR CARD Request to one of its CARs. An
AR that receives a CARD Request from another AR that is not in its
CAR table MUST NOT solicit the AR but rather MUST wait until the AR
sends an unsolicited CARD Reply advertising the AR’s information. An
AR that is starting up MUST send unsolicited CARD Replies to all its
CARs to make sure that their CAR tables are properly populated.
The frequency of unsolicited CARD Reply messages MUST be strictly
limited to CARD_MIN_UPDATE_INTERVAL, in order to avoid overwhelming
CARs with traffic. ARs are free to discard messages that arrive more
frequently.
If a CARD deployment will never run over the public Internet, and if
it is known that congestion is not a problem in the access network,
alternative transport protocols MAY be appropriate vehicles for
experimentation. Implementations of CARD MAY support UDP for such
purposes. In that case, the researcher MUST be careful to
accommodate good Internet transport protocol engineering practices,
such as using retransmits with exponential backoff. In addition,
whether SCTP is an appropriate transport protocol for all inter-
router CARD operations is an open research question. Investigation
of this issue (for example, to determine whether a lighter-weight
protocol might be more appropriate than SCTP) may be of interest to
some researchers.
5.2.2. Protocol Payload Types
The AR-AR interface MUST insert the CARD Request option and CARD
Reply option directly into the body of the SCTP User Data field. The
sequence number for the CARD Request on the AR-AR interface MUST be
initialized to zero when the AR reboots, and MUST be incremented
every time a CARD Request message is sent. The replying AR MUST
include a sequence number from the CARD Request in the CARD Reply.
If an unsolicited CARD Reply is sent, the sending AR MUST increment
the sequence number. Sequentially increasing sequence numbers allows
the receiving AR to determine whether the information has already
been received.
On the AR-AR interface, the Capability Container parameter is used to
convey capabilities between ARs. Optionally, the Preferences
parameter can be used for capability pre-filtering during the inter-
AR capability discovery procedure. Payload types and encoding rules
are the same as those described for the respective sub-option types
in Section 5.1 for the MN-AR interface. The same TLV-encoded format
is used to attach the options as payload to the protocol main header.
Additionally, an AR can set the T flag in the CARD Request header in
order to obtain the certificates for the CAR. The description of
sub-options in Section 5.1.3 includes information on what flag
settings are prohibited on the AR-AR interface.
6. Security Considerations
6.1. Veracity of CARD Information
The veracity of the CARD protocol depends on the ability of an AR to
obtain accurate information about geographically neighboring ARs, and
to provide accurate information about its own APs and capabilities to
other ARs. The CARD protocol described in the body of this document
does not contain any support for determining the AR-to-AP mapping or
capabilities, either for a specific AR or for a CAR. Therefore,
methods for determining the accuracy of the information exchanged
between ARs are out of scope for the base CARD protocol. The
appendices of this document describe procedures for discovering the
identities of the geographically adjacent ARs and APs (including
capabilities) and discuss relevant security considerations.
Alternatively, this information could be statically configured into
the AR.
6.2. Security Association between AR and AR
CARD contains support allowing ARs to exchange capability
information. If this protocol is not protected from modification, a
malicious attacker can modify the information. Also, if the
information is delivered in plain text, a third party can read it.
To prevent the information from being compromised, the CARD messages
between ARs MUST be authenticated. The messages also SHOULD be
encrypted for privacy of the information, if required.
Confidentiality might be required if the traffic between two ARs in
an operator’s network traversed the public Internet, for example.
Two ARs engaging in the CARD protocol MUST use IKE [HarCar98] to
negotiate an IPsec ESP security association for message
authentication. If confidentiality is desired, the two ARs MUST
additionally negotiate an ESP security association for encryption.
Replay protection SHOULD also be enabled with IKE. To protect CARD
protocol messages between ARs, IPsec ESP [AtKe98] MUST be used with a
non-null integrity protection and origin authentication algorithm and
SHOULD be used with a non-null encryption algorithm for protecting
the confidentiality of the CARD information.
An AR can provide the certificates for its CARs if the certificates
are available. The AR requests certificates from its CARs by setting
the T flag in the CARD Request message. All certificates are sent.
If CARD is used to exchange information between different
administrative domains, additional security policy issues may apply.
Such issues are out of the scope of this document. Use of CARD
between administrative domains is not recommended at this time, until
the policy issues involved are more thoroughly understood.
6.3. Security Association between AR and MN
A malicious node can send bogus CARD Reply messages to MNs by
masquerading as the AR. The MN MUST authenticate the CARD Reply
messages from the AR. Since establishing an IPSec security
association between the MN and AR is likely to be a performance
issue, IKE is not an appropriate mechanism for setting up the
security association. Instead, the SEND security association is used
[Arkko04]. ARs MUST include a SEND Signature Option on CARD Reply
messages. The format of the signature option is the same for both
IPv4 and IPv6 CARD, though SEND itself is only defined for IPv6. A
Mobile IPv4 ICMP Foreign Agent Advertisement option type code for the
SEND signature option [Ke04] has been allocated.
No authentication is required for CARD Requests since CARD
information is provided by the AR to optimize link access. In
contrast, CARD Reply authentication is required because a bogus AR
could provide the MN with CARD information that would lead the MN to
handover to a bogus router, which could steal traffic or propagate a
denial of service attack on the MN. The asymmetry of the
authentication requirement is the same as that involving Router
Advertisements in IPv6 router discovery [Arkko04].
Since CARD is a discovery protocol, confidentiality is not generally
necessary on the MN-AR interface. In specific cases where different
network operators share the same access network infrastructure,
network operators may want to hide information about operator-
specific capabilities for business reasons. The base CARD protocol
contains no support for such cases. However, should such a case
arise in the future, an AVP for an encrypted capability can be
defined at that time.
6.4. Router Certificate Exchange
Because SEND is only available in IPv6, the procedures for obtaining
certificates differ depending on whether CARD is used with IPv4 or
IPv6. In IPv6, when the MN receives a CARD reply with signature from
an AR for which it does not have a certificate, it SHOULD use SEND
DCS/DCA to obtain the AR’s certificate chain. ARs MUST be configured
with a certification path for this purpose, and MNs MUST be
configured with a set of certificates for shared trusted anchors to
allow verification of the AR certificates. An MN may not necessarily
need to use Cryptographically Generated Addresses (CGAs) with CARD,
so CGA support is OPTIONAL for CARD. A certificate profile for ARs
is described in the SEND specification [Arkko04].
In IPv4, there is no DCS/DCA message for obtaining the certificate.
If the MN does not have a certificate for the AR, the MN sends a CARD
Request message containing the L2 ID of its current AP and one
Trusted Anchor sub-option (Section 5.1.3.6) for each shared trusted
anchor for which the MN has a certificate, to obtain the
certification path for the current AR. The Component field of the
Trusted Anchor sub-option is set to 65535 to indicate that the entire
certification path is needed. No other options should be included in
the request. The AR replies by sending a CARD Reply containing the
L2 ID sub-option sent in the request, an Address sub-option for
itself, and a Router Certificate sub-option (Section 5.1.3.7)
containing one certificate in its certification path that matches one
of the requested trust anchors, and no other sub-options, setting the
Context-ID of all sub-options to match. The All Components field is
set to the path length, and the Component field is set to the number
of this component in the path. If the path is longer than one
certificate, the AR sends the L2 ID sub-option and the Address sub-
option in the first certificate and the other certificates in
separate ICMP messages, due to the limitation on ICMP message length,
with the same Context-ID set on each Route Certificate sub-option,
and with the Component field properly set. The router SHOULD NOT
send the trusted anchor’s certificate and SHOULD send certificates in
order from the certificate after the trusted anchor. If the trusted
anchor option does not match any certificate, the AR returns the
Trusted Anchor sub-options in the reply. The MN SHOULD immediately
conduct a Certificate Revocation List (CRL) check on any certificates
obtained through CARD certificate exchange, to make sure that the
certificates are still valid.
Certification paths for CARs may be fetched in advance of handover by
requesting them as part of the CARD protocol. In that case, the MN
includes Trusted Anchor sub-options in the CARD request along with
the L2 ID sub-option for the AP for which the CAR certificate is
desired, and the AR replies as above, except that the L2 ID, address,
and certificates are for the CAR instead of for the AR itself. This
allows the MN to skip the DCS/DCA or CARD certificate exchange when
it moves to a new router.
Because the amount of space in an ICMP message is limited, the router
certification paths SHOULD be kept short.
6.5. DoS Attack
An AR can be overwhelmed with CARD Request messages. The AR SHOULD
implement a rate-limiting policy so that it does not send or process
more than a certain number of messages per period. The following is
a suggested rate limiting policy. If the number of CARD messages
exceeds CARD_REQUEST_RATE, the AR SHOULD begin to drop messages
randomly until the rate is reduced. MNs SHOULD avoid sending
messages more frequently than CARD_REQUEST_RATE. ARs SHOULD also
avoid sending unsolicited CARD Replies or CARD Requests more
frequently than CARD_MIN_UPDATE_INTERVAL, but, in this case, the
existence of an IPsec security association ensures that messages from
unknown entities will be discarded immediately during IPsec
processing.
MNs MUST discard CARD Replies for which there is no outstanding CARD
Request, as indicated by the sequence number.
6.6. Replay Attacks
To protect against replay attacks on the AR-AR interface, ARs SHOULD
enable replay protection when negotiating the IPsec security
association using IKE.
On the MN-AR interface, the MN MUST discard any CARD Replies for
which there is no outstanding request, as determined by the sequence
number. For ARs, an attacker can replay a previous request from an
MN, but the attack is without serious consequence because the MN
ignores the reply in any case.
7. Protocol Constants
Constant Section Default Value Meaning
--------------------------------------------------------------------
CARD_REQUEST_RETRY 5.1.1 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
CARD_RETRY_MAX 5.1.1 15 seconds Give up on retry
on MN-AR interface.
CARD_STARTUP_WAIT 5.2.1 1-3 seconds Maximum startup wait
for an AR before
performing AR-AR
CARD.
CARD_MIN_UPDATE_INTERVAL 5.2.1 60 seconds Minimum AR-AR update
interval.
CARD_REQUEST_RATE 6.5 2 requests/ Maximum number of
sec. messages before
AR institutes rate
limiting.
8. IANA Considerations
See [Ke04] for instructions on IANA allocation.
9. Normative References
[Brad97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Stew00] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[AtKe98] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[Arkko04] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[Ke04] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, July 2005.
10. Informative References
[TKCK02] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J.,
"Issues in candidate access router discovery for seamless
IP-level handoffs", Work in Progress.
[MaKo03] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[Kood03] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC
4068, July 2005.
[Funa02] Funato, D., et al., "Geographically Adjacent Access Router
Discovery Protocol", Work in Progress.
[Tros03] Trossen, D., et al., "A Dynamic Protocol for Candidate
Access-Router Discovery", Work in Progress.
[ShGi00] Shim, E. and R. Gitlin, "Fast Handoff Using Neighbor
Information", Work in Progress.
[Malk03] El Malki, K., et al., "Low Latency Handoffs in Mobile
IPv4", Work in Progress.
11. Contributors
The authors would like to thank Vijay Devarapalli (Nokia) and Henrik
Petander (Helsinki University of Technology) for formally reviewing
the protocol specification document and providing valuable comments