RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

["Les Ginsberg (ginsberg)" <ginsberg@xxxxxxxxx>]

Yoav –

 

Thanx for the suggestion. I have just posted V14 of the draft which I believe addresses your concerns – please review and confirm.

 

   Les

 

 

From: Yoav Nir <ynir.ietf@xxxxxxxxx>
Sent: Sunday, October 21, 2018 10:45 AM
To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>
Cc: Robert Raszuk <robert@xxxxxxxxxx>; kaduk@xxxxxxx; idr@xxxxxxxx; draft-ietf-idr-te-pm-bgp.all@xxxxxxxx; ietf@xxxxxxxx; secdir@xxxxxxxx
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

See inline.

On 19 Oct 2018, at 17:51, Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx> wrote:

 

Robert’s post addresses points I also want to make.

 

What is being done here is to add additional BGP-LS codepoints to advertise IGP information that was not defined at the time RFC 7752 was written. We haven’t changed the  BGP-LS transport mechanism – nor is the information being advertised here (some additional TE related link attribute information) qualitatively different than a number of existing TLVs defined in RFC 7752 (see https://tools.ietf.org/html/rfc7752#section-3.3.2 ). If this information had already been defined in the IGPs at the time RFC 7752 was written it would simply have been included as a section of RFC 7752 and no additional changes to RFC 7752 would have been required.

 

In theory, we could have simply updated RFC 7752 rather writing a separate draft, but practically this would be a poor strategy as it would incorrectly suggest that some change was being made to the existing text in RFC 7752.

 

I appreciate that from the POV of the Security Area you folks are not as intimately familiar with the routing drafts and the relationship between them. It is therefore understandable that you start looking at the new draft as a standalone document – and in that context your comments are absolutely correct. But the document you are reviewing is most accurately seen as an “addendum” to RFC 7752.

 

[YN] Right, and as such, I believe that this document should address the part that it adds to RFC 7752. IOW it should state that the new IGP information that will now be sent through BGP does not present new/different risk to the information already defined in 7752. This is information that has up until now only been sent in IS-IS and OSPF and will not be sent in BGP, so we need a statement that it’s OK to send these attributes in BGP as well. Of course, such a statement could be challenged in WGLC or IETF LC, but it should be made.

The issues you raise have already been addressed in RFC 7752 and it is therefore very appropriate that we address your concerns by including a reference to the RFC 7752 security discussion.

 

I think it is important that you note this relationship, because the nature of BGP-LS is that whenever IGP extensions are defined to advertise new information it is necessary to define corresponding BGP-LS codepoints. This is not the first such BGP-LS extension document – and it is safe to say it won’t be the last. It would be helpful to all if we reached a common understanding or this discussion will take place every time a BGP-LS extension document is being reviewed – which will cost us all time needlessly.

 

   Les