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

[<[e-mail]>]

Hi Randy,

Thanks for your reply

[...]
 
 > >> from the sec cons
 > >>
 > >>     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.
 > >>
 > >> call the security police!
 > >
 > > This is intended to be just stating a fact.
 > 
 > a fact which is lethal

Yet shared by all BGP attributes. Even shared by all information carried in BGP, as indicated in the quoted sentence. (which includes NLRI)

Actually that sentence is copied from https://tools.ietf.org/html/rfc4360

 > 
 > > Would you mind elaborating on your comment?
 > 
 > trust is not transitive. 

I guess that this point could be discussed. Especially in the context of inter domain routing in the Internet. (but even PSTN)
But you are free not to trust the information carried in the attribute, possibly on a per boundary basis.
 
 > the document could be assuming it is within
 > some kind of an assured trust boundary, but makes no assurance of that.

I partially disagree:
- If the BGP speaker does not understand it, the attribute is automatically removed as the attribute is non-transitive.
- If the BGP speaker understands it, this attribute is explicitly removed when the BGP Next Hop is changed, which is often the case when crossing an AS boundary, not to mention a trust boundary. Additionally, you are free to filter that information on a per boundary basis.

I'll update the text related to filtering between ASes:
OLD: For security considerations, a network operator may want to filter the BGP Next-Hop capabilities advertised to external Autonomous Systems.
NEW: For security considerations, a network operator may want to filter the BGP Next-Hop capabilities advertised from or to external Autonomous Systems.

 > for an example of how one might deal with this, see section 3 and the
 > first sec cons of draft-ymbk-sidrops-ov-signal-01.txt

Thanks for the pointer.
However I think the situation is a bit different:
- draft-ymbk-sidrops-ov-signal assumes (hence needs) that the information is trusted. So you need to filter it on the boundary
- draft-ietf-idr-next-hop-capability is a way to collect data, possibly across AS boundary for example for inter-AS MPLS LSPs. You can choose to not trust your peer, but you won't get that data. Up to you. 


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