Re: CARD Review from Henrik Petander

Hi Henrik,

thanks for the review. Maybe better to discuss individual issues in
separate mails, which will follow this one.

marco

James Kempf wrote:

>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?
>
>
>
>_______________________________________________
>Seamoby mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/seamoby
>  
>