Not replying to a specific message, since I'm replying to several issues simultaneously.
In section 2: "No ROA can match an origin AS number of "NONE". No Route can match a ROA whose origin AS number is zero." I'm wondering if there should be a 2119 normative or two in there? This sounds like a validation instruction. (eg MUST/SHOULD declare prefixes covered by an origin AS number of none/zero invalid) "If validation is not performed on a Route, the implementation SHOULD initialize the validation state of such a route to "Valid"." No. Absolutely not. I agree with Randy that default for unchecked != valid. I can manage the handling of unknwon routes via route policy such that during incremental deployment I don't make a decision to prefer valid over unknown if that's what you're trying to prevent with this choice. Valid needs to have an explicit "permit" such that I know categorically that everything with the status of valid was in fact validated. We already have a status for the ones that we don't know, whether it's because they weren't validated or aren't participating/no covering ROA exists -- unknown. I don't understand the suggestion of a 4th value NotChecked. What additional information is that providing? I saw Hannes's response regarding JunOS, but I think that's implementation-specific enough that it's not necessary to codify in the standard. What am I missing? Lastly: "We observe that a Route can be Matched or Covered by more than one ROA. This procedure does not mandate an order in which ROAs must be visited; however, the "validation state" output is fully determined." Is there guidance on this in one of the other documents? If so, please reference it here. Does longest-match still apply? This seems a fairly big question to simply leave open to implementation. Please apply cluebrick liberally if I'm being thick. Thanks Wes George > -----Original Message----- > From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of > internet-dra...@ietf.org > Sent: Monday, March 12, 2012 7:27 PM > To: i-d-annou...@ietf.org > Cc: sidr@ietf.org > Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.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 > Author(s) : Pradosh Mohapatra > John Scudder > David Ward > Randy Bush > Rob Austein > Filename : draft-ietf-sidr-pfx-validate-04.txt > Pages : 11 > Date : 2012-03-12 > > To help reduce well-known threats against BGP including prefix mis- > announcing and monkey-in-the-middle attacks, one of the security > requirements is the ability to validate the origination AS of BGP > routes. More specifically, one needs to validate that the AS number > claiming to originate an address prefix (as derived from the AS_PATH > attribute of the BGP route) is in fact authorized by the prefix > holder to do so. This document describes a simple validation > mechanism to partially satisfy this requirement. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-04.txt > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr