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

From: [email-masked]
Date: Wed, 27 Jun 2018 01:07:29 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : BGP Next-Hop dependent capabilities
        Authors         : Bruno Decraene
                          Kireeti Kompella
                          Wim Henderickx
	Filename        : draft-ietf-idr-next-hop-capability-03.txt
	Pages           : 12
	Date            : 2018-06-27

Abstract:
   RFC 5492 advertises the capabilities of the BGP peer.  When the BGP
   peer is not the same as the BGP Next-Hop, it is useful to also be
   able to advertise the capability of the BGP Next-Hop, in particular
   to advertise forwarding plane features.  This document defines a
   mechanism to advertise such BGP Next Hop dependent Capabilities.

   This document defines a new BGP non-transitive attribute to carry
   Next-Hop Capabilities.  This attribute is guaranteed to be deleted or
   updated when the BGP Next Hop is changed, in order to reflect the
   capabilities of the new BGP Next-Hop.

   This document also defines a Next-Hop capability to advertise the
   ability to process the MPLS Entropy Label as an egress LSR for all
   NLRI advertised in the BGP UPDATE.  It updates RFC 6790 with regard
   to this BGP signaling.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-next-hop-capability/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-next-hop-capability-03
https://datatracker.ietf.org/doc/html/draft-ietf-idr-next-hop-capability-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-next-hop-capability-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Wed, 27 Jun 2018 08:21:21 +0000

Hi all,

Version 03 posted with the following update(s):
- no change on the BGP Next-Hop dependent Capabilities Attribute
- no change on the Entropy Label Next-Hop dependent Capability
- re-addition of the optional advertisement of the Readable Label Depth along the path.

> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-next-hop-capability-03

Draft is now mostly waiting for 2 implementations.

Regards,
--Bruno

 > -----Original Message-----
 > From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
 > Sent: Wednesday, June 27, 2018 10:07 AM
 > To: [email-masked]
 > Cc: [email-masked]
 > Subject: I-D Action: draft-ietf-idr-next-hop-capability-03.txt
 > 
 > 
 > _______________________________________________
 > I-D-Announce mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/i-d-announce
 > Internet-Draft directories: http://www.ietf.org/shadow.html
 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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.

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Jun 2018 18:47:06 -0700

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!

randy

---

From: <[email-masked]>
Date: Thu, 28 Jun 2018 08:12:35 +0000

Hi Randy,

[Trimming the list to IDR]

 > From: Idr [mailto:[email-masked]] On Behalf Of Randy Bush
 > Sent: Thursday, June 28, 2018 3:47 AM
 > To: [email-masked]
 > Cc: [email-masked]; [email-masked]
 > Subject: Re: [Idr] I-D Action: draft-ietf-idr-next-hop-capability-03.txt
 > 
 > from the sec cons
 > 
 
This is intended to be just stating a fact.
Would you mind elaborating on your comment?

Coming back to this document, the attribute is related to node indicated in the BGP NEXT_HOP which is usually not far away from you, including from a trust perspective. Also this attribute is explicitly removed when the NEXT_HOP is changed, and the attribute is non-transitive.
Finally, the first application is for labelled (MPLS) routes which typically imply a trust boundary.

Thanks,
Regards,
--Bruno
 
 > Idr mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/idr

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 28 Jun 2018 11:02:15 +0000

The notion of a group of AS domains that "trust" each other has been a discussion we have had over the last number of years.. For a hypothetical world-wide network which uses different AS numbers based on geography it is desirable to craft a trusted set, as a given tunneled service i.e 2547, EVPN, Kompella etc.. is deployed across all of these AS domains. One could imagine a migration to a single AS but this is not realistic..

Thanks,
	Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 28, 2018 4:13 AM
To: Randy Bush <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-next-hop-capability-03.txt

Hi Randy,

 

Thanks,
Regards,
--Bruno
 
 > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=_yVHR5jfVKriNt5TSyrS0fbO7NCbb_HNLvFDgBQmZOM&s=K4MrEL731u51vk6hDqYAC8trBc8vHYmM1TOcqnatGWc&e=

_______________________________________________
Idr mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=_yVHR5jfVKriNt5TSyrS0fbO7NCbb_HNLvFDgBQmZOM&s=K4MrEL731u51vk6hDqYAC8trBc8vHYmM1TOcqnatGWc&e=

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Jun 2018 09:01:34 -0700

hi bruno,

> [Trimming the list to IDR]

sorry about that.  yesterday was almost as rushed as today.

> This is intended to be just stating a fact.

a fact which is lethal

> Would you mind elaborating on your comment?

trust is not transitive.  the document could be assuming it is within
some kind of an assured trust boundary, but makes no assurance of that.
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

randy

---

From: <[email-masked]>
Date: Thu, 28 Jun 2018 16:52:34 +0000

Hi Randy,

Thanks for your reply

[...]
 
 > > This is intended to be just stating a fact.

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

 > 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

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.

 > 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

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Jun 2018 16:44:23 -0700

hey bruno,

an example

the new next hop may not be in a shared trust domain

at an exchange point, A tells B to to use C as the next hop, thereby
avoiding carrying B's outbound traffic

randy

---

From: <[email-masked]>
Date: Fri, 29 Jun 2018 07:31:37 +0000

Hi Randy,

> From: Randy Bush [mailto:[email-masked]]
> 
 > hey bruno,
 > 
 > an example
 > 

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.
 
 > avoiding carrying B's outbound traffic

Another point related to transitive trust.
If I trust A, and A tells me he can provide me a car for next WE, I trust him. Regardless of whether he owns the car, or rent/borrow it from some else (who I may not trust/know).
That's also applicable to a company which may outsource some part of the job, although with companies trust tend to be replaced by legal contract and penalty.
But it's also fine to have partial trust, including refusing any transitivity.

Note that your example is not specific to this attribute/information.  You may not trust the route itself i.e. the ability of C to adequately forward your traffic.

--Bruno

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Jun 2018 08:11:00 -0700

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.

randy