Telechat Review of draft-ietf-6man-lineid-
review-ietf-6man-lineid-secdir-telechat-harkins-2012-07-05-00

  Hello,

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  This draft defines a new destination option for IPv6 datagrams that
tunnel router solicitation and router advertisement messages. The
purpose of the option is to allow an edge router in a broadband
subscriber network to identify a particular subscriber that comes up.

  I found the draft a bit confusing. Terms are referred to before they
are defined and once defined are not consistently used. There were
several paragraphs that I had to re-read a couple times to figure out
what was being intended. I would suggest the following editorial
changes:
  - in section 1.1, move definition of GPON and RG up before they
    are referred to (AN, and Edge Router, respectively)
  - in section 5.3, pick either AN or "access node" and stick to it.
     By sometimes referring to the entity by acronym and sometimes
     by full name, the casual reader (me) does not immediately
     tie them together and creates 2 entities in his mind as he's
     putting the described behavior together.
  - in section 6.2 it talks about creating a new IPv6 datagram, then
     about adding the option to it and how to determine the contents
     of this datagram, and then it says a new IPv6 datagram is created.
     Wait, so there's 2 IPv6 datagrams or is this the same one? I had to
     read this a few times to figure out what's going on.

  There is an apparent technical problem in section 7 where the new
option is laid out. The option type is an octet and the option length
is also an octet (whose length does not include the option type or
itself). Then follows the a field for the length of the lineID and the
lineID itself. But the length of the lineID is 2 octets implying that
a lineID can be more than 255 octets long. How does this work? If
the lineID itself is greater than 253 octets then the length required
to be encoded in the option length would be greater than 255
which cannot be described with a single octet.

  Either there is the possibility of a valid but unparsable option
that would likely make the rest of the packet unparsable too
(which is bad) or the lineID can never be greater than 253 octets
which then makes me ask why the field to encode its length has to
be 2 octets?

  The other option is, of course, that I'm completely missing something.
If that's the case, forgive my ignorance but please do enlighten me.

  I found no security issues with the draft that require the attention
of the ADs. The Security Considerations mention that this is all
unauthenticated and should only be used on a network where the
communicating entities are already trusted, which seems reasonable
for the way this will be deployed.

  regards,

  Dan.