Re: [Idr] I-D Action: draft-ietf-idr-next-hop-capability-03.txt

[<[e-mail]>]

Randy,

Thanks for taking the time for the suggestion.
More inline

> From: Randy Bush [mailto:[e-mail]]
 > Sent: Friday, June 29, 2018 5:11 PM
> 
 > mornin' bruno,
 > 
 > > I generally agree that there are cases where you don't trust the
 > > source of the information. In such case, you can filter it a priori or
 > > a posteriori.  That doesn't mean that the ability to share an
 > > information is bad.
 > 
 > then make clear what the boundaries are and how to ameliorate this
 > exposure.  the example from ov-signal's sec cons specifically mandates
 > the defense.

Thanks for the useful example. I've also looked at a recent RFC which has passed security review: BGP Large Community.
https://tools.ietf.org/html/rfc8092#section-7

Based on this, as of today, I'd propose the following text:

This document does not introduce new security vulnerabilities in BGP. Specifically, an operator who is relying on the information carried
   in BGP must have a transitive trust relationship back to the source of the information. Specifying the mechanism(s) to provide such a
   relationship is beyond the scope of this document. Please refer to the Security Considerations section of <xref target="RFC4271"></xref> for security mechanisms applicable to BGP.
As this attribute is removed when the BGP Next-Hop is changed, the source of the information is the router which IP address is indicated in the BGP Next-Hop. Such Next-Hop is typically either within the AS when a BGP Next-Hop Self policy is configured, or in the neighboring AS with which an interconnection and an EBGP has been established. If this neighboring AS is not trusted with regards to information carried in the BGP attribute, or carried in a specific capability, this attribute or specific capability should be removed when received. Note that in some cases, this Next-Hop may advertise information based on information it has received from its own downstream BGP Next-Hop, hence the transitive trust relationship. If the underlying transport between both ASes is not trusted, BGP transport should be protected for integrity and authentification
The advertisement of BGP Next-Hop capabilities to EBGP peers may disclose, to the peer AS, some capabilities of the BGP node and may help fingerprinting its hardware model and software version. This may be mitigated by filtering the capability advertised to EBGP peers.
Security of the Entropy Label capability advertisement is unchanged compared to  <xref target="RFC6790"></xref> which originally defined this signaling.




Also, as per the IDR requirement for 2 implementations, I don't expect this document to be sent to the IESG in the short term. Since then, I would expect improvement in term of BGP security consideration. e.g. improved transport security, guidance on BGP security considerations. 

Thanks,
--Bruno
 
 > randy

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.