Review of draft-ietf-semoby-card-protocol-02.txt

Hello all,

Jak and Pat asked me to review the CARD protocol draft based on my
experience in implementing MIPv6. I hope this review will
help in improving the I-D.

Regards,

Henrik Petander

--------------------------------------------------------------------

Comments on the protocol
========================

Choice of transport
-------------------

MN-AR and AR-AR protocols are in the draft carried over ICMP and UDP.
The reason for the separate transports seems to be the piggybacking
defined in section 4.5. However, piggybacking appears does not appear to
be necessary (see comments on section 4.5 for details).  Without
piggybacking it would be simpler to run both MN-AR and AR-AR protocols
over UDP and use the same message formats.


Removal of per-session state from ARs
-------------------------------------

The responsiblity for resends for MN initiated sessions is both in
the MN and the current AR. Since the weakest link in the protocol from a
reliability POV is probably the air interface, the AR-AR resending in
the MN initiated sessions is probably not worth the extra complexity.

Removing it would simplify AR a lot, since it would not need to maintain
any state for CARD in addition to the CAR table. An AR without 
per-session state would be less vulnerable to DoS attacks and would also
scale better.

(The preferences and requirements should then be appended also to the
current AR - CAR messages, if the current AR lacks knowledge of the
capabilities of CARs.)

4. CARD PROTOCOL OPERATION
--------------------------

Is there a specific reason to use the rate limiting flag instead of
normal ICMP rate limiting ?

Anyways, the rate limiting mechanism, which MN uses after getting a
reply with R-bit set, should be defined. There exist a number of
already defined mechanisms for dealing with resending intervals and
rate limiting. Why not use one of them?



4.1 Data structures
-------------------

Should there be a recommendation for MN to cache the information about
CARs ?  MN needs a CAR table with cached answers from CARD
replies to avoid asking the same information repeatedly, and for being
able to react to movement as quickly as possible.


4.2.2 Current access router operation
-------------------------------------

If you use IPSec ESP for protecting CARD between MN and AR, you cannot
send multicast CARD replies. IPSec security associations are between
two hosts.

You need to protect the CARD replies in some other way (for example
with signatures as proposed in the CARD problem statement draft), or
always send them as unicast packets.

4.3.1 Current access router operation
-------------------------------------

Is it necessary to include the capabilities of current AR in
AR-AR CARD request message?

If the data in a current AR for a CAR is not up to date, it still does
not mean that the data for the current AR is not up to date in the
CAR. Including the AR-AR CARD reply automatically in the CARD request
creates unnecessary load in both routers when they authenticate /
encrypt extra data.

This optimization also adds extra complexity to the protocol, and it is
not clear to me whether it is worth it.

4.4. CARD Signaling Failure Recovery
------------------------------------

The draft does not define what an AR sends to MN, when it cannot
resolve a L2 address into an IP address. This should be specified
clearly.

4.4.2 AR-AR signaling failure
-----------------------------

What does the CAR send to current AR, if it does not have an interface
/ AP attached to it with the queried L2 id? This should be
defined.

4.5 Piggybacking
----------------

In appendix B.2, there is a note that it may not be necessary to use
FMIPv6 PRTSolPr and PrRtAdv, if MN-AR CARD messages are exchanged,
since the CARD messages convey all the necessary information. This
seems to make the piggybacking of CARD on top of the PrRt messages
irrevelant. Is there some reason to do it, which is just missing from
the text?

If not, this section should be removed and the messages should be
carried on top of UDP as in AR-AR case.


4.6 CARD protocol security
---------------------------

You should move everything about IPSec ESP here and indicate clearly
how it should be used. Now the text about its use is scattered around
section 4. Perhaps the security section should be renamed "Protection
of CARD messages" to make a clear distinction between the
implementation of the protection versus the analysis in section 6.

The section should say that IPSec ESP 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. Definition of the SPD entries
would also be nice.

5. Protocol messages
--------------------

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

7. Protocol constants
----------------------

Where are their values defined?


Editorial comments
==================

General
--------

The term SHALL was used in the section 4 for use of IPSec
ESP. However, in sections 5 and 6 the word SHOULD was used
instead. The use of "SHALL" was new to me so I checked its meaning
from RFC 2119. According to the RFC its use is: "MUST   This word, or
the terms "REQUIRED" or "SHALL", mean that the definition is an
absolute requirement of the specification."

This should be fixed.  If capabilities such as pricing information are
transferred between ARs and MNs, I would opt for use of SHALL/MUST for
the authentication requirement. Also the card requirements draft uses
the word MUST for authentication and SHOULD for encryption.

4.3.2 Candidate Access Router Operation
---------------------------------------

Last sentence: "The CAR SHALL use IPsec ESP for authentication _or_
optionally encryption of the AR-AR CARD Reply message."

Shouldn't the "or" be "and" instead? The encryption algorithms for ESP
do not provide integrity protection and should not be used without
an authentication & integrity protection algorithm.

4.4.1 MN-AR Signaling Failure
-----------------------------

"The _AR_ SHALL start a timer (MN_AR_CARD_TIMER) after sending a MN-AR
  CARD Request message with the given sequence number."

Shouldn't it be the MN, which starts the timer instead of AR?


5.1.1 CARD Main Header Format
-----------------------------

"Encapsulating Security Payload (ESP) Header:
	The sender SHOULD include the Encapsulating
	Security Payload (ESP) Header, based on the
         previously established Security Association
         between the sender and the receiver."

Shouldn't this SHOULD be MUST intead?

5.2.1 Protocol Transport
------------------------

"To authenticate protocol messages between ARs, the IPsec ESP SHOULD
    be used [10]."

Again, SHOULD vs. MUST/SHALL.

6.1 Assumptions
---------------
Second paragraph, last sentence:

"The appendices of this draft describe procedures for discovering the
identities of the geographically ARs and APs and relevant security
considerations."

There seems to be a word missing after "geographically". Adjacent?

6.2 Security Association between AR and AR
-------------------------------------------

"To prevent the information from being compromised, the CARD REPLY
  messages between ARs SHOULD be authenticated. The messages also MAY
  be encrypted for privacy of the information."

Again SHOULD vs. MUST/SHALL.

6.3 Security Association between AR and MN

"A malicious node can send bogus CARD REPLY messages to MNs by
masquerading the AR. So the MN SHOULD authenticate the CARD REPLY
messages from the AR."

Again SHOULD vs. MUST/SHALL.

6.4 DoS Attack
--------------

Should it be mentioned here that authenticating CARD requests is
needed to allow ARs to protect themselves against CARD request
flooding with spoofed addresses?

(Authenticating the requests makes DoS less likely as the attacker's
identity is revealed and her account can be disabled, etc.)

The meaning of the second paragraph is not clear to me. How can an
attacker masquerade as an AR, if all entities in the protocol are
authenticated? It seems to me that this would be possible only if an
AR is compromised. Should the protocol be secure also against
compromised routers?  This should be specified in the assumptions
section.


Appendix A.
----------

The appendixes form quite a large part of the draft. A.1 and A.2
should be either integrated into the main draft as optional parts or
be separated into their own drafts.

A.1.4.1 Security Associations

More details are needed on how IPSec ESP is used.

A.2

What does pAR send to current AR to verify that it had or did not have
state for MN?


A.2.4

"should" vs MUST be protected with IPSec ESP.

Appendix B.
----------

B.1 should be removed, since it is not needed for implementation of the
protocol. The draft is self explanatory enough to be used with
IEEE 802.11 WLANs without this appendix.

B.2 raises the question, whether there is a need for an "architecture"
draft instead, which describes how CARD and FMIPv6 or CARD and CTP can
be used together.