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

From: Marco Liebsch <[email-masked]>
Date: Fri, 30 Apr 2004 20:36:35 +0200

James,
thanks for editing the latest CARD draft to address IESG comments.

Please find below some comments.

marco

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

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

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. 

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.

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

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.

Here, I cannot say to which IESG comment this kind of modification
is related.

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

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. 

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

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

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

Use of SCTP has been proposed on the list, but cannot be associated 
with any IESG comment. 

----
5.1.3.6 Trusted anchor sub-option
As said above, use of a Context-ID is not required here.
Proposal: Remove Context-ID

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

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

 

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Fri, 30 Apr 2004 15:27:31 -0700

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

> L2-ID cannot be resolved.  (if this is meant with your new text here)

Yes, that was the intent. I'll make the change.

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

> a CAR. So, here it makes no sense.

I'll make the change. Thanx.

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

> Proposal: Delete this reference to SCTP here.

OK.

> to a previiously sent request? This was actually the case in previous

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.

> Here, I cannot say to which IESG comment this kind of modification

 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.

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

> These changes, I cannot associate with any IESG comment.

I'll discuss this point in a separate email.

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

> Propoal: Remove the X for this interface (if my assumption is

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?

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

    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

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.

> Proposal: Remove Context-ID

OK.

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

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

            jak