[no subject]

            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.

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

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

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


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

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

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

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

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


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

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

    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?


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

            jak



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
&lt;a  href=&quot;<a  rel="nofollow" href="https://www1.ietf.org/mailman/listinfo/seamoby&quot";>https://www1.ietf.org/mailman/listinfo/seamoby&quot</a>;&gt;<a  rel="nofollow" href="https://www1.ietf.org/mailman/listinfo/seamoby";>https://www1.ietf.org/mailman/listinfo/seamoby</a>&lt;/a&gt;



&lt;/pre&gt;

&lt;!--X-Body-of-Message-End--&gt;
&lt;!--X-MsgBody-End--&gt;
&lt;!--X-Follow-Ups--&gt;
&lt;hr&gt;
&lt;ul&gt;&lt;li&gt;&lt;strong&gt;Follow-Ups&lt;/strong&gt;:
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;&lt;a name=&quot;02643&quot; href=&quot;msg02643.html&quot;&gt;Re: [Seamoby] some comments to version 7 of the CARD draft&lt;/a&gt;&lt;/strong&gt;
&lt;ul&gt;&lt;li&gt;&lt;em&gt;From:&lt;/em&gt; Marco Liebsch &amp;lt;marco.liebsch@ccrle.nec.de&amp;gt;&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;
&lt;!--X-Follow-Ups-End--&gt;
&lt;!--X-References--&gt;
&lt;ul&gt;&lt;li&gt;&lt;strong&gt;References&lt;/strong&gt;:
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;&lt;a name=&quot;02613&quot; href=&quot;msg02613.html&quot;&gt;[Seamoby] some comments to version 7 of the CARD draft&lt;/a&gt;&lt;/strong&gt;
&lt;ul&gt;&lt;li&gt;&lt;em&gt;From:&lt;/em&gt; Marco Liebsch &amp;lt;marco.liebsch@ccrle.nec.de&amp;gt;&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;
&lt;!--X-References-End--&gt;
&lt;!--X-BotPNI--&gt;
&lt;ul&gt;
&lt;li&gt;Prev by Date:
&lt;strong&gt;&lt;a href=&quot;msg02613.html&quot;&gt;[Seamoby] some comments to version 7 of the CARD draft&lt;/a&gt;&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Next by Date:
&lt;strong&gt;&lt;a href=&quot;msg02678.html&quot;&gt;Re: Get Your Prescription Drugs now online! With No Prescription. Discreet. Secure.&lt;/a&gt;&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Previous by thread:
&lt;strong&gt;&lt;a href=&quot;msg02613.html&quot;&gt;[Seamoby] some comments to version 7 of the CARD draft&lt;/a&gt;&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Next by thread:
&lt;strong&gt;&lt;a href=&quot;msg02643.html&quot;&gt;Re: [Seamoby] some comments to version 7 of the CARD draft&lt;/a&gt;&lt;/strong&gt;
&lt;/li&gt;
&lt;li&gt;Index(es):
&lt;ul&gt;
&lt;li&gt;&lt;a href=&quot;maillist.html#02614&quot;&gt;&lt;strong&gt;Date&lt;/strong&gt;&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;threads.html#02614&quot;&gt;&lt;strong&gt;Thread&lt;/strong&gt;&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;

&lt;!--X-BotPNI-End--&gt;
&lt;!--X-User-Footer--&gt;
&lt;!--X-User-Footer-End--&gt;
&lt;/body&gt;
&lt;/html&gt;
</pre>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg02598.html">[no subject]</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg02600.html">[no subject]</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg02598.html">[no subject]</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg02600.html">[no subject]</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="maillist.html#02599"><strong>Date</strong></a></li>
<li><a href="threads.html#02599"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>