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: [email protected] [mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: Monday, March 12, 2012 7:27 PM
> To: [email protected]
> Cc: [email protected]
> 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
> [email protected]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
