Re: [secdir] SecDir review of draft-ietf-pim-hello-intid-01

Stig Venaas <stig@venaas.com> Mon, 15 August 2011 20:07 UTC

Return-Path: <stig@venaas.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 F05B521F8C1B; Mon, 15 Aug 2011 13:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.3
X-Spam-Level:
X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 yRIv3BICpV2L; Mon, 15 Aug 2011 13:07:21 -0700 (PDT)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 232AD21F8BDE; Mon, 15 Aug 2011 13:07:20 -0700 (PDT)
Received: from [10.33.12.82] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 37266802A; Mon, 15 Aug 2011 22:08:05 +0200 (CEST)
Message-ID: <4E497CA1.9030907@venaas.com>
Date: Mon, 15 Aug 2011 13:08:01 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Chris Lonvick <clonvick@cisco.com>
References: <Pine.GSO.4.63.1108081328200.22397@sjc-cde-021.cisco.com> <Pine.GSO.4.63.1108081358020.22397@sjc-cde-021.cisco.com> <4E41A777.4030401@venaas.com> <Pine.GSO.4.63.1108151207440.2825@sjc-cde-021.cisco.com>
In-Reply-To: <Pine.GSO.4.63.1108151207440.2825@sjc-cde-021.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 16 Aug 2011 12:42:44 -0700
Cc: draft-ietf-pim-hello-intid.all@tools.ietf.org, Michael McBride <mmcbride@cisco.com>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-pim-hello-intid-01
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, 15 Aug 2011 20:07:22 -0000

On 8/15/2011 12:28 PM, Chris Lonvick wrote:
> Hi Stig,
>
> On Tue, 9 Aug 2011, Stig Venaas wrote:
> <some elided>
>>> > > While PIM is certainly not my strong suit the document is
>>> > understandable except for the following paragraph from Section 2.1:
>>> > > The Local Interface Identifier MUST be non-zero. The reason for
>>> > this, is that some protocols may want to only optionally refer to an
>>> > Interface using the Interface Identifier Hello option, and use the
>>> > value of 0 to show that it is not referred to. Note that the value
>>> > of 0 is not a valid ifIndex as defined in [RFC1213].
>>> > > This seems to be saying that the Local Interface Identifier must not
>>> > be 0, except when some protocol wants to use the Interface Identifier
>>> > Hello to not refer to any actual interface. Which leaves me confused.
>>
>> Perhaps there is a better way to explain it. To see what I'm talking
>> about, please have a look at section 3.6.2 of
>> http://tools.ietf.org/html/draft-hou-pim-ecmp-01
>>
>> The message format includes both Neighbor address and Interface ID,
>> but use of the Interface ID is optional. If the Neighbor address is
>> sufficient for uniqueness, then Interface ID 0 is sent. Basically,
>> the idea is that instead of using some TLV format, it is easier to
>> always have an Interface ID field, and use the value 0 as saying
>> not in use, or unspecified.
>>
>> I'm happy if you can think of a better way of phrasing it.
>
> How about:
>
> The Local Interface Identifier is normally non-zero. Since the value
> of 0 is not a valid ifIndex as defined in [RFC1213], it's use in

No. Maybe I should just remove the rationale and just write:

The Local Interface Identifier MUST be non-zero. Note that the value
of 0 is not a valid ifIndex as defined in [RFC1213].

Basically, this document specifies what is sent in this Hello option,
and the Local Interface Identifier MUST be non-zero. Always. The
point is that other protocols may have messages containing a value 
referring to a Local Interface Identifier, and in those messages,
they may choose to use the invalid Local Interface Identifier value
0 to have a special meaning. But it might be better not explaining
that here?

For e.g. the ECMP draft, the protocol always include a field that
may contain an Interface ID. In cases where they don't want to
reference an ID, they set this field to 0, which is known to be an
invalid ID.

Note that I don't want to talk about ECMP in this draft, if necessary
I would like to just modify the current statement:

    The reason for this, is that some protocols may want to only
    optionally refer to an Interface using the Interface Identifier
    Hello option, and use the value of 0 to show that it is not
    referred to.

into some other generic statement saying the same. Would this be
better?:

    The reason for this, is that some protocols may have messages
    that optionally reference an Interface Identifier, and they
    may use the value of 0 to show that no Interface Identifier is
    being referenced.

Stig

> this field has special meaning. A Local Interface Identifier of 0 will
> indicate that the Router Identifier is sufficiently unique for
> identification for the protocol using it. For example, this field is
> non-zero when used in IPv4 when one or more RPF neighbors in the ECMP
> bundle are unnumbered. For other IPv4 usage, this field is zero'ed
> when sent, and ignored when received. If the "Router ID" part of the
> "Interface ID" is zero, the field MUST be ignored, regardless of its
> value.
>
> Does that work?
>
> Thanks,
> Chris