Re: [secdir] secdir review of draft-ietf-ospf-node-admin-tag-05

Benjamin Kaduk <kaduk@MIT.EDU> Thu, 15 October 2015 00:56 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDBA1A90F3; Wed, 14 Oct 2015 17:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFvDV7eoRguo; Wed, 14 Oct 2015 17:56:01 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556BB1A8A6A; Wed, 14 Oct 2015 17:56:01 -0700 (PDT)
X-AuditID: 1209190c-f79b76d000007c4e-97-561ef99fd31c
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 9C.FF.31822.F99FE165; Wed, 14 Oct 2015 20:55:59 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t9F0twIe013294; Wed, 14 Oct 2015 20:55:59 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9F0ttoE026254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Oct 2015 20:55:57 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t9F0ts4Q009019; Wed, 14 Oct 2015 20:55:54 -0400 (EDT)
Date: Wed, 14 Oct 2015 20:55:54 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Shraddha Hegde <shraddha@juniper.net>
In-Reply-To: <BY1PR0501MB13815C096D0BF8D4221E5600D53F0@BY1PR0501MB1381.namprd05.prod.outlook.com>
Message-ID: <alpine.GSO.1.10.1510142037140.26829@multics.mit.edu>
References: <alpine.GSO.1.10.1510091159450.26829@multics.mit.edu> <D23ED021.34690%acee@cisco.com> <BY1PR0501MB1381A8D06B804AE4508F371AD5320@BY1PR0501MB1381.namprd05.prod.outlook.com> <alpine.GSO.1.10.1510131547130.26829@multics.mit.edu> <BY1PR0501MB13815C096D0BF8D4221E5600D53F0@BY1PR0501MB1381.namprd05.prod.outlook.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT153/Uy7M4NZkc4vJb+cxW/x+tYXd YsaficwWHxY+ZLG48WgvswOrx5TfG1k9liz5yeRxvekqewBzFJdNSmpOZllqkb5dAlfGgx+L mAuWqVT8nrqMpYFxgmwXIyeHhICJxJRlZ1ghbDGJC/fWs3UxcnEICSxmkmh59osVwtnIKPHx 1UEmCOcQk8TaY23MEE4Do8SH+b/YQPpZBLQlzn5qZQKx2QRUJGa+2QgWFxHQlLg28SnYKGaB e4wS/891M4MkhAXsJY50HGMBsTkFEiXWTvzKCGLzCjhKXFi0gx1iw2Emia9bv4IViQroSKze P4UFokhQ4uTMJ2A2s4CWxPLp21gmMArOQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5q ka6hXm5miV5qSukmRlBgc0ry7GB8c1DpEKMAB6MSD2/BPbkwIdbEsuLK3EOMkhxMSqK8F74D hfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwam8AyvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJ zU5NLUgtgsnKcHAoSfAu+wHUKFiUmp5akZaZU4KQZuLgBBnOAzT8LEgNb3FBYm5xZjpE/hSj opQ47z2QhABIIqM0D64XnHh2M6m+YhQHekWY9xxIFQ8wacF1vwIazAQ0eM9/WZDBJYkIKakG xu1ea5edcE5/eqqkeXVezo1/z1+tZX/4z9xD5sKZi0o/Ty8LWrL9ToPsXbmdVkG3OmZfS/gT uv/03HuFC+P+cl12OxZvyf/a7rg9U3hhhZnF4pdLMr5MzOKq9p7L9SyRJbXe0PZCkp9tx2zD Hea9N+Ol11k8SBGUm2PWI3Dmk5bK9XjpgElLbiixFGckGmoxFxUnAgCfZxAsFwMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/B23u3XqY7KK7kT5vTgbTQuKgv5w>
Cc: "draft-ietf-ospf-node-admin-tag.all@ietf.org" <draft-ietf-ospf-node-admin-tag.all@ietf.org>, "Acee Lindem \(acee\)" <acee@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-ospf-node-admin-tag-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 15 Oct 2015 00:56:03 -0000

On Wed, 14 Oct 2015, Shraddha Hegde wrote:

>
> I completely missed looking at editorial comments and the diff in
> previous mail. Sorry about that.
>
> Have taken your changes in the latest version and diff (-06 to -08)
> attached. Pls take a look.

The new version seems improved; I'll skip line-by-line discussion of the
grammar changes since the IESG teleconference call is fast approaching.

The diagram for the TLV format in Figure 1 still has a 15-bit type and
17-bit length; both should be 16 bits.

> Editorial comments:
>
> >
> > I also have some editorial comments unrelated to the secdir review:
> >
> > Section 3.2 reads rather like a jumbled list and could benefit from some
> > additional structure.
> <Shraddha.>Updated. Pls refer diff.
> >
> > Similarly, I would find it helpful if there was some text motivating the
> > "middle patch" mentioned above, towards the beginning of the technical
> > (non-example) portion of the document.
>
> <Shraddha> I could not get this comment. Could you pls elaborate?

This is related to Alvaro's DISCUSS.  Basically, there is conflict between
saying that the interpretation of tag values is entirely local, and
imposing restirctions on how the tags should be interpreted.  It is
helpful to the reader to discuss why the document does not pick one
extreme of completely-local interpretation and a fully specified protocol
that dictates the meaning of all tags.  Instead, the document picks
something in-between, with tag interpretation mostly a matter of local
policy, but some restrictions on their use.  Describing why this choice
was made early in the text gives the reader a better picture of what the
goals of the protocol are, to better understand the details of the
protocol itself.

> > For a construction as weakly structured as these administrative tags,
> > preventing any internal structure or dependencies between tags (as this
> > document attempts to do) seems correct.  However, this sentiment seems to
> > be expressed differently in several different places in the document, and
> > it would be good to consolidate and coordinate them.  In particular,
> > paragraph 3 of section 3.2 explicitly says that tag order has no meaning,
> > but paragraph 4 has the weaker "SHOULD be considered an unordered list".
> > (The word "set" might be appropriate here.)
>
> <shraddha>Below is the latest text. SHOULD is changed to MUST
>
> " Each tag MUST be treated as an independent
> identifier that MAY be used in policy to perform a policy
> action. Each tag carried by the administrative tag TLV SHOULD be used to
> indicate a characteristic of a node that is independent of the
> characteristics indicated by other administrative tags.
> The administrative tag list within the TLV MUST be considered
> an unordered list. Whilst policies may be implemented based on the
> presence of multiple tags (e.g., if tag A AND tag B are present),
> they MUST NOT be reliant upon the order of the tags (i.e.,
> all policies should be considered commutative operations, such that
> tag A preceding or following tag B does not change their outcome)."

This seems okay in a quick read, but again, the resolution of Alvaro's
DISCUSS will be relevant to this text.

> > Paragraph 7 of section 3.2 seems to be trying to say that the
> > administrative tags must indicate inherent or administratively configured
> > properties of a node and must not be used to convey attributes of the
> > routing topology.  (The word "tie" seems insufficiently clear.)
>
> <Shraddha>Changed to text below.
>
> "Being part of the RI LSA, the per-node administrative tag
> TLV must be reasonably small and stable. In particular,
> but not limited to, implementations supporting per-node
> administrative tags MUST NOT be used to convey attributes of the
> routing topology or associate tags with
> changes in the network topology (both within and outside
> the OSPF domain) or reachability of routes."

That's an improvement, thanks.  ("but not limited to" is still bad
grammar, but the best fix is not immediately obvious.)

> > The last paragraph of section 3.2 could probably be written more clearly.
> > In particular, "in any instance of the RI-LSA" is not entirely clear to me
> > (but then again, I don't really understand how LSAs normally work).  Is it
> > enough to just say that implementations MUST detect when the
> > administrative tags associated with a given node change, and update their
> > state accordingly?
> >
> <Shraddha> hope this issue is resolved in other mail thread.

I think so, yes.

-Ben