CARD: Feedback on editorial issues

Hi Henrik,

finally, after addressing the protocol issues of your review
first, here my feedback with regard to the 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".

marco: Ok, done.


>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?

marco: I tried to make it clear in the text. I guess in 5.1.1
you refer to the description of CARD Request in the Valid Options...
I revised the text as follows:

"CARD Request: The CARD Request allows entities to request
 CARD specific information from ARs. To support processing
 the CARD Request message on the receiver side, further
 sub-options may be carried, serving as input to the reverse
 address translation function and/or capability discovery function"


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

marco: Since the A-flag is set in case the MN does NOT want its 
AR to perform reverse address translation, I think you mean
the combination "A=1" (not A=0) and C=0 is invalid, right?
If this is correct, I will add this note.


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

marco: this section has been revised anyway due to 
the decision on how we'll handle securing the
unsolicited CARD Reply multicast. Please find the
revised text here:

"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 MUST authenticate the
CARD Reply messages from the AR. IPsec ESP is the default
mechanism for CARD signaling message authentication between
an AR and a MN. Also, IPsec ESP is the default method for
message encryption. (marco:as we did in 6.2)
Authentication of unsolicited CARD Reply messages, which
are multicast from an AR towards MNs, is an open issue and
the specification of an appropriate mechanism is out of
scope of this document."


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

Only AR-AR CARD Reply is protected with IPSec. Unsolicited MN-AR Reply
protection is out of scope. Now, independent of the authentication
mechanism, overwhelming a node with CARD Replies requires the 
receiving entity to perform processing of this message. If rate
limitation is out of control, a DoS attack is possible. Hence, we need a 
rate limiting policy, which is described in section 4.


>7. Protocol constants

>What is the purpose of CARD_RETRANSMISSION_INTERVAL and CARD_MAX_RETRIES? 

marco: Clarified in previous mails. But agreement on final values is
still pending. 


Thanks
marco