Subject: Re: [sidr] I-D ACTION:draft-ietf-sidr-origin-validation-signaling-00.txt

From: "George, Wes E [NTK]" <[email-masked]>
Date: Wed, 1 Dec 2010 20:49:05 +0000

I note that this is still listing the requested IANA extended community as
non-transitive, but has removed the explicit prohibition to sending this
community to an eBGP peer based on my prior feedback. Is that going to work,
or does the community need to be redefined as transitive as well?

Also, if we're going to allow it to be used in eBGP in even a limited
fashion, I think that we do need some text that covers this transitive vs
intransitive distinction in a bit more detail. For example, when I
recommended that we not explicitly prohibit sending this community on an
eBGP session, I also said that it should default to non-transitive for eBGP
in order to prevent misconfigurations from causing validation info of
questionable origin from moving between ASNs. In other words, it should be a
configurable option, but we want to express that the preference is to have
people do their own RPKI validation at their ASBR rather than relying on an
upstream and to limit propagation of this information since it's of
questionable accuracy and trust. We may also want to say that the receiving
peer must be explicitly configured to accept the extended community, and by
default it should drop any instance of the validation community on eBGP. Not
sure if we need to explicitly state that peers that don't understand/support
the community should silently ignore it, since I'm pretty sure that's
default behavior.

Updating the deleted text from the original document might give us something
like this:
Since the extended community is primarily intended to provide a method to
carry prefix validation information within an ASN, it SHOULD be a
non-transitive attribute, but there are some applications where it may be
necessary for it to transit between ASNs. In order to limit the propagation
of this information outside of the originating ASN, it MUST NOT be attached
by default while advertising routes to EBGP peers, even if the session is
configured to send other communities. It MAY be explicitly configured to be
sent between eBGP peers. Additionally, if it is present in an UPDATE message
received from an EBGP peer, by default the router MUST remove the origin
validation state extended community before parsing rest of the message. The
router MAY be explicitly configured to allow the origin validation state
from an eBGP peer to be accepted, but this is not recommended unless there
is an existing trust relationship between the ASNs (such as upstream ISP and
customer). Any ASN that learns validation information from an eBGP peer via
this community MUST NOT pass that community beyond routers in its own ASN.

Background info if you're not sure where this discussion is coming from:
http://www.ietf.org/mail-archive/web/sidr/current/msg01567.html

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, November 30, 2010 4:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [sidr] I-D ACTION:draft-ietf-sidr-origin-validation-signaling-
> 00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Secure Inter-Domain Routing Working
> Group of the IETF.
> 
> 	Title		: BGP Prefix Origin Validation State Extended
> Community
> 	Author(s)	: P. Mohapatra, K. Patel, J. Scudder, D. Ward, R.
> Bush
> 	Filename	: draft-ietf-sidr-origin-validation-signaling-00.txt
> 	Pages		: 7
> 	Date		: 2010-11-30
> 
> As part of the origination AS validation process, it can be desirable
>    to automatically consider the validation state of routes in the BGP
>    decision process.  The purpose of this document is to provide a
>    specification for doing so.  The document also defines a new BGP
>    opaque extended community to carry the validation state inside an
>    autonomous system to influence the decision process of the IBGP
>    speakers.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-validation-
> signaling-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: Pradosh Mohapatra <[email-masked]>
Date: Sun, 5 Dec 2010 07:21:34 +0530

Hi Wes,

> the community should silently ignore it, since I'm pretty sure that's

Yes, making the extended community non-transitive, but allowing it to be
exchanged across ebgp sessions helps this.

> this community MUST NOT pass that community beyond routers in its own ASN.

Thanks! I am fine with adding this text. Will wait for a few if others want to
chime in...

- Pradosh