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

["Ketan Talaulikar (ketant)" <[e-mail]>]

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.

Thanks,
Ketan

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

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