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

Suresh Krishnan <suresh.krishnan@ericsson.com> Mon, 02 July 2012 04:27 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D86821F8920; Sun, 1 Jul 2012 21:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.573
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3P7HJ+Ehex6; Sun, 1 Jul 2012 21:27:40 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 63EE821F8911; Sun, 1 Jul 2012 21:27:40 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (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 [164.48.125.24] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 2 Jul 2012 00:27:25 -0400
Message-ID: <4FF12324.200@ericsson.com>
Date: Mon, 2 Jul 2012 00:27:16 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
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 <dharkins@lounge.org>
References: <3f40470e03a3da0a21dcf09e26f1a723.squirrel@www.trepanning.net>
In-Reply-To: <3f40470e03a3da0a21dcf09e26f1a723.squirrel@www.trepanning.net>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-6man-lineid.all@tools.ietf.org" <draft-ietf-6man-lineid.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-6man-lineid
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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.

Great.

Thanks
Suresh