Re: [secdir] secdir review of draft-ietf-6man-lineid

Suresh Krishnan <> Mon, 02 July 2012 04:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D86821F8920; Sun, 1 Jul 2012 21:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.573
X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i3P7HJ+Ehex6; Sun, 1 Jul 2012 21:27:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 63EE821F8911; Sun, 1 Jul 2012 21:27:40 -0700 (PDT)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id q624RE3p005748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Jul 2012 23:27:41 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Mon, 2 Jul 2012 00:27:25 -0400
Message-ID: <>
Date: Mon, 2 Jul 2012 00:27:16 -0400
From: Suresh Krishnan <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Dan Harkins <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-6man-lineid
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Jul 2012 04:27:41 -0000

Hi Dan,
  Thanks a lot for your comments. Please find responses inline.

On 06/30/2012 01:49 PM, Dan Harkins wrote:
>   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.

Will make these changes.

>   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 LineIDLen is actually 8 bits like you suspected and there is an
error in the ascii art. I will fix this in the next rev.

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