Subject: IESG comments on ndopt draft

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Jun 2004 10:08:56 +0300

There are two DISCUSS comments, see

   https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1340&filename=draft-ietf-send-ndopt

I have sent in a response, see below. The IESG is
meeting today, so a quick response was needed. Further
discussion may be needed however, so WG comments on
the issues & better responses are very welcome.

--Jari

> Executive summary: 1) I agree with the authorization model
> comments, but I thought this was what we were doing. Maybe
> its a text issue, if this was not apparent from the spec.
> 2) There were a number of specific suggestions and corrections,
> most of which seem like something we should adopt. 3) In
> some cases I have presented a reason, such as DoS-avoidance,
> for the behaviour that was asked about. 4) I think our
> deployment model is suitable for mobile situations, and it
> has been considered in the design; there is not much text
> explaining about it however.
> 
>>> [2004-06-09] I'm very concerned that the authorization model used by the authors is incorrect.  Several of the following comments, including the most serious ones, are based on that belief.
>>>
>>> Section 4 says "A host and a router must have at least one common trust anchor before the host can adopt the router as its default router."  I don't know what it means to "have ... a common trust anchor", but the relationships are different.  The host must believe that the chain of authorizations, from the anchor to the router, identifies a node that is *authorized* to route packets for this link. 
> 
> 
> But this is my understanding as well! Is there a text problem
> if this was not made clear in the spec? Note: some of the authors
> of the spec have been extremely focused on authorization in
> their work, so it could be that some text has been missed as
> "obvious".
> 
>>>  That has nothing to do with whether or not the host in some way trusts the anchor for other purposes.  To give a concrete example,
> 
> 
> Agree 100%!
> 
>>> since router certificates are tied to the addressing structure they're presumably rooted at an RIR.  That will be true of virutally all 
> 
> 
> They could be rooted at an RIR, but while waiting for that to
> happen, they could also be rooted at your home/company/ISP that
> you trust.
> 
>>> router certificates describing public address space, including the routers belonging to EvilHackerDudes.example.org.  The fact that I'll trust the certificates from routers for MyCompany.example.com doesn't mean that I'll trust the evil ones. While trust anchors may suffice, the spec must mandate some sort of user (or configuration) interface to describe a full chain of authorized certificates.  In some situations, these may not be address certificates.  A user sitting in a public hot spot may be willing to trust the owner of the hotspot -- say, via a standard commercial identity certificate, of the type used today on the Web -- without regard to the particular addresses being advertised or assigned.
> 
> 
> If I understand the above correctly, I believe this is close to
> what we have already specified. We would like the addresses for
> the routers to appear in the certificates, but we actually do
> allow (per configuration) that plain certificates be used as well.
> See Section 7.3 and "Unconstrained" certificates.
> 
> Summarizing, I believe the intent -- maybe not the text? --
> of the specification was that whatever trust roots are
> configured, they are strictly for SEND purposes only. That
> is, we do realize that there's a difference in authorizing
> for different tasks.  That does not preclude the possibility
> of a user trusting the same certificate for different purposes,
> however. We also allow for a configuration of a multiple
> certificates, and address-less certificates. In conclusion,
> I think I agree with the comments that were made, but it is
> unclear to what, if anything, in the specification needs
> to be changed.
> 
>>> 5.2.2: Clarify that options after the signature option MUST always be ignored (or the packet dropped); in this context, it's ambiguous if such options are only dropped for purposes of signature verification.
> 
> 
> Ok.
> 
>>> 5.2.4 says that the IPv6 header is covered by the signature.  5.2.1 says that the ICMPv6 header is covered, as well as the source and destination addresses.  Which is it?
> 
> 
> Seems like a discrepancy. I think both headers should be covered.
> 
>>> 5.3.4.2: A 1-hour DELTA value seems amazingly high.  Kerberos uses 5 minutes.
> 
> 
> We could lower it to the Kerberos value.
> 
>>> 6.2.1: Per my comments on Section 4, I'm not convinced that a trust anchor is useful.
> 
> 
> See my reply above.
> 
>>> 6.2.6: Why does it say that "hosts SHOULD NOT store certificates" under certain conditions?  Certificates are self-validating.  Ones that aren't part of a chain may be useless, and it may be advantageous under certain conditions to discard them, but strongly advising their discard seems wrong -- if you have the storage (and a good search algorithm), possessing them is useful because it can avoid the need to solicit or receive them later.
> 
> 
> The reason relates to the specific order we have required the
> certificates be sent, and guarding against denial-of-service
> attacks relating to memory usage. At the point where we say
> "SHOULD NOT store", we know that the other side either did
> not follow the spec or has a root we can't verify to.
> 
> But we could have missed something.
> 
>>> 8: The spec says that nodes SHOULD have an option to restrict them to secure NDP messages only.  What is the default value for this option?
> 
> 
> The default value is accepting both secure and non-secure NDP.
> There's a specific (and quite secure) way to deal with both. See
> Section 8.
> 
>>> Comment:
>>> [2004-06-09] Given that there are implementations of this spec, it would be nice to include an appendix giving typical packet lengths, especially for messages with certificates.
> 
> 
> I think we could do that.
> 
>>> Ted Hardie:
>>> Discuss:
>>> [2004-06-08] I guess I have a fundamental design question.  The draft describes part of the
>>> underlying logic in section 6.1 as:
>>>
>>>
>>>   The certificate chain of a router terminates in a Router
>>>   Authorization Certificate that authorizes a specific IPv6 node to act
>>>   as a router.  Because authorization chains are not a common practice
>>>   in the Internet at the time this specification was written, the chain
>>>   MUST consist of standard Public Key Certificates (PKC, in the sense
>>>   of [19]).  The certificate chain MUST start from the identity of a
>>>   trust anchor that is shared by the host and the router.  This allows
>>>   the host to anchor trust for the router's public key in the trust
>>>   anchor.  Note that there MAY be multiple certificates issued by a
>>>   single trust anchor.
>>>
>>> One of the common use cases for V6 is in mobile networks, where it
>>> may be common for a terminal to operate in a network operated
>>> by a provider to whom the user has no direct relationship.  Managing
>>> the trust anchors in this instance looks to be a fairly hard problem.
>>> The draft doesn't seem to address this part of the problem
>>> directly, though there is a bit of text on how fast hand-off may enable
>>> one router to pass data on the next router along.
>>>
>>> Have I missed something here in the way of context or text?
> 
> 
> I don't think you missed any text, but this has certainly been
> considered in the design. First, there are two parts in the
> authorization problem related to ND: address ownership for
> nodes and the authorization of some nodes to be routers. We
> have solved the address part using CGAs, a zero-config scheme
> which works well in any type of roaming situation. The other
> part, routers, can not, as far as we know, be solved completely
> without some amount of configuration or infrastructure. However,
> the deployment model we are thinking of seems to work well even
> in a roaming scenario. Or so we think at least.
> 
> Here's the idea: a node that moves around probably has a
> subscription with one or several operators that provides service in
> several locations. Either by themselves or through roaming
> relationships. Now, what is needed is that the mobile node
> gets a SEND root certificate from his operator(s). This
> certificate is not the one that is needed for access in
> a specific location X, but rather the root of such certificates.
> Then if you go to location X, the mobile node will get the
> local router's certificate and verify that it can be traced
> back to the root certificate.
> 
> We also realize that deploying certificates can be troublesome.
> However, in the case of SEND the problem is not quite as
> bad as creating a global infrastructure. In particular,
> 
>   o  SEND can operate (securely) from the start, even
>      when, say, just your personal home network supports
>      it but not other locations.
> 
>   o  SEND requires certificates only for routers, not
>      for all nodes (see CGA above).
> 
>   o  SEND certificate hierarchies can be specific to
>      your home/company/ISP/ISP roaming group, and
>      do not need to be global. 

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------