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 protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Tuesday, November 30, 2010 4:15 PM > To: [email protected] > Cc: [email protected] > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
