CARD Review from Henrik Petander

Below is a Last Call review from Henrik Petander. Vijay has requested more
time for his review.

            jak
----------------------------------------------------------------

1. Protocol issues
==================

The handling of sequence numbers in MN and RA for resending is not
defined. Should MN increase the sequence number on resend? Should AR
identify a CARD request similar to an old one, except for the sequence
number, as a resend and set a new timer for AR-AR resending? How does
AR identify a "new" request from MN from resends of an old one?

The timeout values in MN -AR resending and AR-AR resending make AR-AR
resending overlap: If a message is lost between AR and CAR, both MN and
AR will resend it at the same time. Based on the discussion about AR-AR
resending, I understood that its purpose was to decrease the amount
of over-the-air messages, if a message is lost in the fixed
network. Now this does not happen.

To fix this, change the values for resending, so that MN_AR_CARD_TIMEOUT >
AR_AR_CARD_TIMEOUT * MN_AR_CARD_RETRIES. This should IMO be done by
decreasing the AR_AR timeout and amount of retries to avoid problems
with MN noticing messages lost between MN and AR slowly.

Should the sequence number be stored in CAR table to enforce ordering
of CARD replies ?

Now unsolicited CARD replies are to be authenticated with signatures,
which MN can verify with the public key of the AR, that MN has learned
from somewhere. This is very vague. The description of CARD should be
sufficient for two implementations to be interoperable. IMO you should
either remove the whole unsolicited CARD reply functionality, or clarify
the use of signatures so that it will actually work between two
independent implementations.

L2 id suboption should have address length field which MUST be
used at least with with L2 type = 0x00.

2. Editorial issues
===================

4. ...CARD Reply contains one or more L2 ids and IP addresses" Isn't
   this contradictory with the use of context id of L2 IDs from CARD
   Request in CARD reply to avoid including L2 ids? Change this to
   "may contain".

5.1.1

The text in 5.1.1 on including suboptions in CARD MN-AR request is
confusing to me. Which suboptions must be present in all messages? Isn't
it valid to send just a MN-AR CARD request to get all CARs and their
capabilities from AR?

5.1.2 Should maybe have a note that flag combination A= 0 with C=0 is
invalid.

6.3 Second paragraph is repeated from 4.6. Shouldn't this section
analyze the security, whereas section 4.6 should describe the
implementation of the security mechanisms.

6.4 CARD Reply DoS: Is this really a relevant threat, since CAR is
  authenticated with IPSec ESP? It seems to require compromise of CAR,
  so IMO this is out of scope.

7. Protocol constants

What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES?