Subject: DT's review of draft-ietf-send-ipsec-01.txt

From: "Dave Thaler" <[email-masked]>
Date: Thu, 19 Jun 2003 15:45:32 -0700

The biggest problem with this document is that the coexistence mechanism
appears to be fundamentally flawed (see comments on section 10).

Comments on substance follow.  There's an even longer list of typos and
grammatical errors which I'll send in a separate message.

1) Section 6 states:
   > Similarly, the router, which is already connected to the network,
can
   > if necessary communicate off-link and construct the certificate
   > chain.

   This should be clarified with "in some cases".  If the router is
   not connected to the Internet, this may not be possible.

2) Sections 6.1 and 6.2 describe an Identifier field, but does not
specify how
   it is set in a solicitation or in an unsolicited advertisement.  E.g.

   if it is always set to 1, it doesn't seem very useful.  Likewise, if 
   each host starts with 1 and increments, it's also less useful 
   since hosts can collide.  I think it should be randomly generated if 
   possible.

3) Sections 6.3 and 6.4 both specify options with a variable-length
   field followed by padding.  However, they use two different encodings
   for no good reason.  One specifies the length of the field, and the
   other specifies the length of the padding.  Instead, both options
   should be consistent.

4) Section 6.4 says:
   >  When the Name Type field is set to 1, the Name field contains the
   >  Fully Qualified Domain Name of the trusted root, for example
   >  "trustroot.operator.com".

   More guidance is needed to prevent interoperability problems.
   Is the string null-terminated (I assume no)?
   Are internationalized domain names legal?  What is the encoding?
   (UTF-8?  Unicode? ...)

5) Section 6.5 says:
   > RFC 3281.  If the GeneralName attribute is a dNSName, it MUST be
   > resolvable to a global unicast address assigned to the router.  If
   > the GeneralName attribute is an iPAddress, it MUST be a global
   > unicast address assigned to the router.  For purposes of
facilitating

   For people not familiar with X.509, is it easy to explain in 1-2
   sentences what it is used for?  (That is, why is it a MUST above?) 
   As is, it sounds suspiciously like a security hole.

6) Section 6.5.1 says:
   >  This field MUST contain a list of prefixes that the router is
   >  authorized to route, or the  unspecified  prefix  if  the  router

   This wording is particularly problematic.  Routers route packets
   not prefixes.  They _advertise_ prefixes in RA's and in routing
protocols.
   It's similarly unclear whether the prefix list is what remote
   prefixes it's allowed to advertise as off-link routes in RA's (e.g.
   ::/0 if it can be a default router on the link), or whether the
prefix
   list is what local prefixes it's allowed to advertise as on-link
routes
   in RA's.  I'm guessing the latter, but I can think of arguments for
   restricting both.

7) Sections 6.6 and 6.7 appear to contradict each other.
   6.6 says:
   > SHOULD send an advertisement without any certificates.  In this
case
   > the router SHOULD include the Trusted Root options which were
   > solicited.
   Hence the Trusted Root option is legal in an advertisement.

   6.7 says:
   > packet processed in the normal manner.  The only defined option
that
   > may appear is the Certificate option.  An advertisement that passes
   Hence the Trusted Root option is not legal in an advertisement.

8) Section 7.1.2 and reference [27] contradict each other.
   7.1.2 says:
   >    CGAParameters ::= SEQUENCE {
   >      publicKey      SubjectPublicKeyInfo,
   >      auxParameters  CGAAuxParameters OPTIONAL }
   whereas [27] now has the opposite order.
   It would be better to not copy the definition here at all, and just 
   refer to [27] for the definition.

9) Section 7.1.3 talks about a minbits parameter.  It doesn't really
   say how the value should be determined.  Some guidance would be
   helpful.

10) 7.1.4 says:
   >  source address.  A packet that has already been seen from the same
   >  source with the same Timestamp field value MUST be silently
   >  discard.

   Since the granularity of the field is in milliseconds, you need to
   specify that a node must not send two SEND messages during the same
   millisecond.  However, this restriction may be problematic in some 
   scenarios.

11) Section 10:
   > operate as two separate logical links, and packets between a secure
   > and insecure node always go through the router.

   This is actually false (at least as currently specified), and I'm 
   worried that this whole section (and perhaps others) may be
completely 
   broken as a result.  Specifically, multicast packets sent from a node

   will not go through the router.  The model is especially broken when 
   there are applications/protocols using link-scoped groups (e.g.,
LLMNR).
   Nodes may exchange link-local addresses which then cannot be used in 
   unicast communication.  Put another way, nodes can send packets which
   appear to leave the scope of the unicast address, since a packet
received
   can have a link-local source address from a separate logical link.
   This violates the Addressing Architecture RFC.

   If there is some way of fixing this, ensuring that even link-scoped
   multicast groups are disjoint, then I believe the reason to have
   a separate solicited-node range completely goes away, and the
protocol
   becomes much simpler.

12) Section 10.1:
   > One effect of this is that secure hosts can not communicate with
   > insecure hosts using link-local addresses, and vice versa.

   Another false statement (as currently specified).  See above.

   > The above rules require secure nodes to ignore all insecure
Neighbor
   > and Router Discovery messages, and all insecure nodes to ignore all

   This statement contradicts section 10.1 that describes how to respond
to
   (not ignore) insecure solicitations.

-Dave

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Jun 2003 08:48:57 +0300

Thank you Dave very much for your review! I'll have to

>    This violates the Addressing Architecture RFC.

I think I see the problem. Yes, this is serious for the
co-existence functionality. Thanks for noting this.

>    a separate solicited-node range completely goes away, and the

Hmm... to me, it seems rather hard to invent a way to have disjoint
multicast groups. Sending to a multicast destination does not appear
to require any ND operations, so its hard to see how SEND could intervene
and assign different addresses. But I'm not a multicast expert, so
perhaps you have some ideas? Maybe a new link-local multicast address
range? But what would be the impacts of that.

In any case, if you look at draft-arkko-send-ndopt-00.txt (to appear, see
http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndopt.txt)
there's a very different co-existence mode. Basically, I gave up with
the two-logical link approach and simply added application-level policies
for deciding when SEND-nodes can accept plain ND, and plain ND nodes
always accept all SEND messages. I think this would solve your
problem as well.

--Jari