Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)

Jeffrey Haas <jhaas@pfrc.org> Fri, 16 March 2018 13:50 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2741126CD8 for <idr@ietfa.amsl.com>; Fri, 16 Mar 2018 06:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 TC7wlI6b9I43 for <idr@ietfa.amsl.com>; Fri, 16 Mar 2018 06:50:21 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DF87C1241F5 for <idr@ietf.org>; Fri, 16 Mar 2018 06:50:21 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 7ED031E3FE; Fri, 16 Mar 2018 09:50:23 -0400 (EDT)
Date: Fri, 16 Mar 2018 09:50:23 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: Susan Hares <shares@ndzh.com>, 'idr wg' <idr@ietf.org>
Message-ID: <20180316135023.GH6209@pfrc.org>
References: <011201d3b633$0b5fee60$221fcb20$@ndzh.com> <20180315230734.GB6209@pfrc.org> <8acfb154b77f4ba883b3ec3445986b04@XCH-ALN-008.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8acfb154b77f4ba883b3ec3445986b04@XCH-ALN-008.cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Yfp6WyqnRtMAOeZvSvK7rYCUkHg>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2018 13:50:28 -0000

Ketan,

On Fri, Mar 16, 2018 at 02:50:43AM +0000, Ketan Talaulikar (ketant) wrote:
> > There are a number of TLV value fields that may be of variable lengths.  In many cases, those lengths are inherited from the underlying IGP documents.
> > What is not documented is the behavior when the TLV is well formed but has unexpected length values.  Two simple examples:
> > - Prefix Attribute Flag TLV; varies by IGP
> > - Preference TLV; must be 1.
> > 
> > Do we treat this as malformed?  Do we ignore the sub-tlv?
> [KT] I believe this is clarified in the base BGP-LS spec
> (https://tools.ietf.org/html/rfc7752#section-6.2.2). Do we need to
> clarify/call out anything extra in this specific document? IMHO it would
> be rather complex for BGP implementation (e.g. transit routers which do
> not understand or consume all these TLVs) to do semantic checking on these
> large set of TLVs being introduced in BGP-LS. This is something that could
> be left to the actual consumer of the information (e.g.
> controllers/applications). When a specific sub-TLV is using a wrong length
> (or have some other semantic error), it could be ignored by the consumer.
> This would apply to BGP-LS in general and not a specific
> document/extension.

My interpretation of the above citation is "the PDU is syntactically well
formed".  The issue here is when it's semantically incorrect.

I agree with you that this is likely a more general BGP-LS issue, but don't
see appropriate guidance in the base spec either.

While your point is "let the consumers decide", sometimes those consumers
are simply deserializing the data directly into structures in BGP for
external consumption.  I.e., they are not opaque.  Thus, the semantic
validation has relevance in general.

Frankly, this has the possible feel of a attack vector on BGP-LS speakers.

-- Jeff