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

"Ketan Talaulikar (ketant)" <> Sat, 17 March 2018 05:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3FEB120726 for <>; Fri, 16 Mar 2018 22:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L6nJLuiSDRTQ for <>; Fri, 16 Mar 2018 22:59:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB2C01205D3 for <>; Fri, 16 Mar 2018 22:59:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3803; q=dns/txt; s=iport; t=1521266365; x=1522475965; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8mrfCEnICt9tJBLv08Qug2dkD5o97OFz4IB9WXEJaIA=; b=iYtfHMoTCxV1Usk13KqU1DkfwJgBpgUUVxONE3Sm/LoTgzFPIEGws7L5 y4genEjsmXUIaEdNu4y/RYR40TMQfppgDSF7YNq6RmEyU3l0cGwQFX74q juVhJUd4zk/A3hYaqr2vuSVMhqZRe4j62dalgAe6YcBp4s/8bFF7Hw0fa U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.48,319,1517875200"; d="scan'208";a="358391824"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2018 05:59:24 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2H5xOqw031048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 17 Mar 2018 05:59:24 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 17 Mar 2018 00:59:23 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Sat, 17 Mar 2018 00:59:23 -0500
From: "Ketan Talaulikar (ketant)" <>
To: Jeffrey Haas <>
CC: Susan Hares <>, "'idr wg'" <>
Thread-Topic: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)
Thread-Index: AQHTvLJwsPGlDZ7q5kWwiGwlvN25RqPSJ2PwgAEOf4CAALVoEA==
Date: Sat, 17 Mar 2018 05:59:23 +0000
Message-ID: <>
References: <011201d3b633$0b5fee60$221fcb20$> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Mar 2018 05:59:28 -0000

Hi Jeff,

You are right that RFC7752 sec 6.2.2 covers what you describe as message being "syntactically well formed". The "semantic" validation part is perhaps not explained as well (please correct if I missed this).

If the semantic error is there with respect to NLRI descriptor TLVs then likely the NLRI becomes un-usable. If it is with an attribute TLV, then likely that specific attribute may be ignored or implementations may choose to ignore the entire NLRI.

Given the ever growing amount of information which is being propagated via BGP-LS, my recommendation would be for BGP speakers to handle them as opaque data (i.e. not do semantic checking on it) to the point where this information is handed over to the consumer (internal or external). Consider scenarios where BGP-LS information is relayed via one or more RRs or eBGP sessions - these intermediate hops may not even have the ability to understand/support the NRLIs/TLVs.

Semantic checking is best left to the point where the information is actually going to be consumed since that application (it could even be BGP itself) has the smarts to do this.

I am not sure I understand your point on this becoming an attack vector. And I assume that implementations that handle the PDUs in a robust and secure way.

In any case, I would look forward to inputs/comments from you and the WG on how the semantic checking can be handled and if this needs to be covered in specific BGP-LS drafts or we come up with something general.


-----Original Message-----
From: Jeffrey Haas <> 
Sent: 16 March 2018 19:20
To: Ketan Talaulikar (ketant) <>
Cc: Susan Hares <>om>; 'idr wg' <>
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-ls-segment-routing-ext-04 (March 7 to March 21)


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