Re: [Seamoby] some comments to version 7 of the CARD draft

James Kempf wrote:

>Marco,
>
>Thanx for taking a detailed look at the draft. Below responses to some
>comments. Could you open an issue on the issues list with all the issues
>discussed in this email? I'll be responding to one of the issues in a
>separate email, which I'd like listed as a separate issue. Thanx.
>
>            jak
>
>  
>
>>----
>>section 4. CARD protocol operation
>>end of 3rd paragraph refers to a RESOLVER ERROR.
>>This status code is associated only with a L2-ID, not with a
>>signaling message.
>>Proposal to modify:
>>"The current AR returns replies based on its CAR table (see
>>Section 4.1), and returns a L2-ID with a status code
>>indicating RESOLVER ERROR (see Section 5.1.3.1) if this particular
>>L2-ID cannot be resolved.  (if this is meant with your new text here)
>>
>>    
>>
>
>Yes, that was the intent. I'll make the change.
>
>  
>
Ok.

>>----
>>section 4. CARD protocol operation
>>6th paragraph: "The MN can additionally request from the AR
>>a certificate chain..."
>>Same as above, the RESOLVER ERROR status code is available only in
>>a L2-ID sub-option.
>>Proposal A: Add a similar status code indication in a Trusted Anchor
>>sub-option, which could come back to the mobile and indicate that
>>no cert chain has been found for the trausted anchor.
>>Proposal B: Remove the RESOLVER ERROR indication here.
>>
>>    
>>
>
>I think both. If RESOLVER_ERROR is only intended for L2-ID resolution, then
>we'll need something to indicate if the Trusted Anchor fails to yield a
>cert.
>
>  
>
Right. That means, in case of failure, the trusted anchor comes back in 
the Reply. Otherwise it
won't. Maybe this is sufficient as indication of failure. Alternatively, 
the AR might set a "failure"
flag in the option that comes back. If we need multiple possible status 
codes as indication to
a mobile, then we need an extra field as we have it in the L2-ID 
suboption. What do you
think is the most appropriate one for this purpose?

I'll add this as issue to the issue tracker.

>>Furthermore, the trusted anchor sub-option should not have a Context-ID,
>>since this anchor is associated with a mobile terminal, not with
>>a CAR. So, here it makes no sense.
>>
>>    
>>
>
>I'll make the change. Thanx.
>  
>
Ok.

>  
>
>>last paragraph: correct typo:
>>"...The peer returns a CAR/+D+/ Reply message..."
>>
>>This paragraph breaks the two paragraphs about use of the
>>Requirements and Preferences sub-option.
>>Proposal: Move it to one paragraph later, where the examples
>>about Requirement and Preferences finish.
>>
>>    
>>
>
>I'm not sure I understand. Do you mean merge it with the previous paragraph,
>that begins "Figure 1 describes the..."? One paragraph later begins a new
>section and a new topic.
>^
>  
>
Oops, sorry, I jumped between the paragraphs. The latter comment is 
related to paragraph 5 of this
section 4. "The MN can additionally request from the AR a 
certificate...". This para separates the
3rd and the 4th para about Requirement and Preferences sub-option from 
the examples about these
sub-options, which is now in para 6 "As an example, using the optional 
Preferences message
parameter...". Only a minor editorial comment.

>  
>
>>----
>>4.3.1 Current Access Router Operation
>>end of first paragraph: "An AR uses SCTP for CARD transport..."
>>Well, there is a dedicated section (5.2.1 Protocol Transport).
>>Use of SCTP is new, maybe important, maybe too heavyweight. Since
>>there is already 5.2.1, it should not be mentioned too often...
>>Proposal: Delete this reference to SCTP here.
>>
>>    
>>
>
>OK.
>
>  
>
>>end of 2nd paragraph: "The receiving AR MUST increment the sequence
>>number of the CARD by one in the CARD Reply"
>>Isn't it better to use the same sequence number in the Reply as received
>>in the Request to allow the requesting entity to associate the Reply
>>to a previiously sent request? This was actually the case in previous
>>version.
>>
>>    
>>
>
>Yes, you are right, the seq no is to allow the host to correlate the request
>and reply (and thus quickly drop any attack replies for which there is no
>outstanding request, without having to perform crypto on the signature).
>Having them both the same is the standard way to handle this (see RFC 2408
>for an example), which is why I changed it from incrementing. I missed this
>reference.
>
>  
>
Well, as it is written now, it seems that the requested AR increments 
seq-num in the Reply, which
should not be done, right? So, maybe you can change this back to 
something like "...The
receiving AR MUST use the same sequence number in the CARD Reply as 
received in the
CARD Request. Correct?

>>Here, I cannot say to which IESG comment this kind of modification
>>is related.
>>
>>    
>>
>
> There was no comment specifically related to this, I changed it as part of
>trying to align the security design more closely with standard IETF
>practice, in accordance with Steve Bellovin and Russ Hously's comments on
>security.
>
>  
>
I thought it was aligned...

>>----
>>4.4 MN-AR Transport
>>This looks inconsistent and sections on protocol transport
>>should be covered either by chapter 4 or 5. Now it is split.
>>Proposal: Move this section to 5.1.1, similar to how it is
>>done for the AR-AR transport in 5.2.1.
>>
>>    
>>
>
>Are you sure? 5.1.1 describes the format of the various messages, not
>transport.
>
>Suppose we move this section and Section 5.2.1 into a new section called
>Transport that deals with transport on both the AR-AR and MN-AR interfaces?
>This would be consistent with the way the CT draft is written.
>
>  
>
In section 5.2.1, the first sub-section is about transport between ARs. 
Then it continues with
message formats. That's why I propose to shift details about transport 
netween MN and AR,
which is now in section 4.4, to a section 5.1.1 "Protocol Transport 
(MN-AR)", similar to how it is
done for AR-AR transport in 5.2.x. Of course, subsequent sub-sections 
will increment as well,
current 5.1.1 will be 5.1.2 "CARD main header format", etc. But I am 
also fine with alternatives.
This was only a proposal to make it consistent.

>>Why has the retransmission scheme and the assocated protocol
>>constants changed? Use of exponential bakoff is ok.
>>
>>These changes, I cannot associate with any IESG comment.
>>
>>    
>>
>
>I'll discuss this point in a separate email.
>
>  
>
Ok, I'll add an issue on this to the issue tracker where you can refer to.

>>----
>>5.1.1 CARD Main header format
>>Text about Valid Options:
>>"Router Certificate:
>>...in the chain for the AR or for a CAR from a trusted anchor to
>>the router..."
>>Shouldn't the cert be sent to the mobile?
>>
>>    
>>
>
>Yes, the cert is sent to the mobile. I guess the text isn't clear. How
>about:
>
>                     The Router Certificate sub-option carries
>                     one certificate in the chain for the AR or
>                     for a CAR. The chain includes certificates
>                    from a trusted anchor, which the router shares
>                    in common with the mobile node, to the router
>                    itself. The format of the Router Certificate Chain
>                     sub-option is described in Section 5.1.3.7.
>
>  
>
Ok.

>  
>
>>----
>>5.1.3 Sub-options format
>>Table about interfaces:
>>Why is the Trusted Anchor sub-option used on the AR-AR interface?
>>I think it's used only between a MN and its AR.
>>Propoal: Remove the X for this interface (if my assumption is
>>correct)
>>
>>    
>>
>
>The idea is to let an AR cache certs for its CARs, just like it caches
>capabilities and L2-IDs. So there needs to be some way for an AR to ask for
>the certs of the CAR, and get them. Is there some way I can make this
>clearer?
>
>  
>
Well, moving certs from a CAR to the CAR table of other ARs is done with 
the
Cert sub-option. Use of this sub-option between ARs is correctly 
indicated in the table.
But the trusted anchor sub-option, why should the trusted anchor of a 
mobile be
sent to the CAR to request its cert? The only reasonable scenario, where the
trusted anchor is to be notified from an AR to a CAR is in case the two 
routers
do not share the same Cert Authority, which is independent to a mobile's
CA. Not sure if this is meant here.

Further, I don't think that the trustend anchor sub-option should serve as
general indicator that a requesting entity is interested in certs. I 
would prefer
to use another indicator, something like a flag in the CARD request.
Comments?

>>----
>>5.2.1 Protocol Transport
>>UDP has been entirely replaced by SCTP. Well, I saw John's
>>mail about interoperability, but SCTP looks quite heavyweight
>>in some cases, at least if capability parameters are updated
>>very frequently.
>>Proposal: Shouldn't we add a paragraph that says:
>>Other transport protocols might perform better in some cases,
>>but appropriate failure recovery mechanisms must be specified if
>>not implicitely supported by this transport protocol...
>>
>>    
>>
>
>SCTP is proposed as an interoperability option (hence the MUST as John
>mentioned) for people who don't care about transport, or who want to explore
>the new transport paradigm implented by SCTP, since CARD is an experimental
>protocol. For people who want to determine whether SCTP is right or not, for
>example, to determine if SCTP is too heavyweight as you say, the last
>paragraph in Section 5.2.1 beginning "If a CARD deployment will never
>run..." is intended to give guidance. How about if I add this to the end of
>the last paragraph in that section:
>
>  
>
Ok, I think this paragraph is fine, it also refers to UDP as 
alternative. But could you
change "CT" to "CARD" in this section of the CARD draft :-)

>    In addition, it is an open research question whether SCTP is an
>appropriate transport protocol for all inter-router CARD operations.
>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.
>
>  
>
>>Use of SCTP has been proposed on the list, but cannot be associated
>>with any IESG comment.
>>
>>    
>>
>
>Ted Hardie and Thomas Narten filed a Discuss comment regarding the
>utilization of scarce port resources by IANA for Seamoby protocols, since
>they are experimental. By utilizing SCTP for both CARD and CTP, we only need
>one port, and we can utilize the SCTP PPI to distinguish the two protocols,
>addressing their comment. Plus, as Randy Stewart mentioned, the PPI is a
>part of the new SCTP transport paradigm, and therefore another area where
>some interesting experimental work can be done with CARD.
>
>  
>
>>----
>>5.1.3.6 Trusted anchor sub-option
>>As said above, use of a Context-ID is not required here.
>>Proposal: Remove Context-ID
>>
>>    
>>
>
>OK.
>
>  
>
>>----
>>5.1.3.7 Router Certificate Sub-option
>>This is probably the most critical issue:
>>The TLV-encoding of this option indicates length as units of
>>octets. Maybe 254 bytes are not really sufficient for a certificate.
>>Proposal: Difficult, if we change length unit to "units of
>>8 octets", this might conflict with the overall length indicator
>>of the CARD Request/Reply, which is also in units of 8 octets.
>>
>>    
>>
>
>You are right, it is not. Typically, the length of X.509 certs runs upwards
>of 1K bytes. I think we will have to make it units of 8 octets, or change
>the size to two bytes. Why do you think this would conflict?
>
>  
>
Well, the CARD Request/Reply option gives the length in units of 8 
octets. I the sub-option does as well,
max length of the sub-option is the same as the max length of the 
option... This is even worse when
having 16 bit as length indicator for the sub-option.

I'll add this as an issue to the issue tracker.

>  
>
>>----
>>6.3
>>General question w.r.t the protection of MN-AR CARD messages:
>>If CARD Reply messages are authenticated using the SEND
>>signature, how are CARD Requests authenticated by the ARs?
>>
>>
>>    
>>
>
>In a discovery scenerio, the ARs reply to whatever request is given to them,
>only protecting themselves against DoS by rate limiting. If there is a
>requirement to only hand out information to authorized nodes, it's the job
>of AAA to make sure that only authorized nodes get on the link in the first
>place. Once they are on, they can get the information, just like a router
>advertisement. For the mobile node, however, it must be sure it can
>distingush whether the AR is trusted or not. Should I say something about
>this in Section 6?
>
>  
>
The previously proposed use of IPsec ESP ensured mutual authentcation. 
Here, we assumed
that AAA will take care about establishment of the required SA. Now, we 
make the SEND
procedure as integral part of the CARD protocol and ensure downlink 
authentication without
being dependent on IKE etc. Here, we implicitely assume and trust AAA to 
take care about
uplink authentication. Looks like just moving issues around. But if we 
don't need
uplink security, then you are right. Maybe a statement about this helps. 
And if IESG
is fine with this solution, why not.

Thanks,
marco

 jak

>
>  
>

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby