Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt

From: [email-masked]
Date: Mon, 12 Mar 2012 16:27:02 -0700

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 13 Mar 2012 08:35:57 +0900

i have two serious disagreements with this draft.

  o a prefix against which validation has not been run (no validation at
    all or some knob turned off) should not be marked Valid.  that would
    be a lie.  it should be marked NotFound.

  o routes learned by ibgp and routes originated on this router should
    be checked and marked.  i do not want to hear from a neighboring noc
    that i am originating or propagating garbage.  the ibgp case is
    particularly egregious in partial deployment, where my ibgp peer may
    not be validating at all.

some vendor engs do not seem to realize how extensively ops apply policy
to ibgp.  the example i like is that we are driven to it by droids who
sell both local peering and global transit to the same bgp peer.  maz
also gave a nice example in a workshop we did here a few years back
<http://www.attn.jp/maz/p/c/bgpworkshop200904/>.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 12 Mar 2012 19:49:57 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Monday, March 12, 2012 4:36 PM
To: sidr wg list
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt

It isn't quite NotFound either. How about a new value: NotChecked.

--
Jakob Heitz.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 13 Mar 2012 01:49:57 +0100

>    be a lie.  it should be marked NotFound.

FWIW - the JUNOS implementation has got this 4th state, called "Unverified".

its intended use is to spot routes which haven't been properly
evaluated using BGP import policy. 

/hannes

---

From: Randy Bush <[email-masked]>
Date: Tue, 13 Mar 2012 10:27:05 +0900

>>  o a prefix against which validation has not been run (no validation
>>    at all or some knob turned off) should not be marked Valid.  that
>>    would be a lie.  it should be marked NotFound.

the only problem i see with this is that, if i do not test for it in
policy, i will fall off the end.

    policy-statement route-validation {
        term valid {
            from {
                protocol bgp;
                validation-state valid;
                }
            then {
                local-preference 110;
                validation-state valid;
                accept;
                }
            }
        term invalid {
            from {
                protocol bgp;
                validation-state invalid;
                }
            then {
                local-preference 90;
                validation-state invalid;
                deny;
                }
            }
        term unknown {
            from {                          
                protocol bgp;
                validation-state unknown;
                }
            then {
                validation-state unknown;
                accept;
                }
            }
        }

randy

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 13 Mar 2012 11:37:26 +0100

>> FWIW - the JUNOS implementation has got this 4th state, called

Unverified is the default state for all prefixes … so if you do "fall off the end"
then the system will set it to its default values.

---

From: Randy Bush <[email-masked]>
Date: Tue, 13 Mar 2012 20:16:42 +0900

> Unverified is the default state for all prefixes … so if you do "fall
> off the end" then the system will set it to its default values.

but is that an accept or reject?  and whichever you answer, some people
would have wanted the other :)

randy

---

From: "George, Wes" <[email-masked]>
Date: Tue, 13 Mar 2012 10:17:32 -0400

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, March 12, 2012 7:27 PM
> To: [email-masked]
> Cc: [email-masked]
> 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.
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> 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.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 13 Mar 2012 15:58:27 +0100

On Tue, Mar 13, 2012 at 08:16:42PM +0900, Randy Bush wrote:
| > Unverified is the default state for all prefixes … so if you do "fall
| > off the end" then the system will set it to its default values.
| >> the only problem i see with this is that, if i do not test for it in
| >> policy, i will fall off the end.
| >>        term unknown {
| >>            from {                          
| >>                protocol bgp;
| >>                validation-state unknown;
| >>                }
| >>            then {
| >>                validation-state unknown;
| >>                accept;
| >>                }
| >>            }
| >>        }
| 
| but is that an accept or reject?  and whichever you answer, some people
| would have wanted the other :)

depends on the route. consider that this is a BGP route and this
is a a BGP import policy then the system implicitly sets the
default acction to accept; this is system default (since JUNOS 3.3 ;-))

---

From: Pradosh Mohapatra <[email-masked]>
Date: Tue, 13 Mar 2012 13:07:20 -0700

Hi Wes,

> 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)

Could you suggest text with 2119 language?

> 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.

I looked around in sidr-usecases and origin-ops, but couldn't find an  
example. May be we should add one. But is there anything that you are  
specifically worried about? All that the text says is that ordering is  
not relevant. It's a classic OR operation for the match.

- Pradosh

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Mar 2012 06:03:17 +0900

> 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.

you want the inclusive or, if any one matches it's Valid.  otherwise,
you can not do a make-before-break provider switch, for example.

as to the matching rules, i have extracted a few slides from a recent
hands-on workshop, see <http://archive.psg.com/120314.roa-match.pdf>.

randy

---

From: Jay Borkenhagen <[email-masked]>
Date: Tue, 13 Mar 2012 22:18:14 -0400

I also have some problems with aspects of the
draft-ietf-sidr-pfx-validate-04.txt draft, particularly this bit from
Section 2:

   When a BGP speaker receives an UPDATE from one of its EBGP peers,
   it SHOULD perform a lookup as described above for each of the
   Routes in the UPDATE message.  [...] This procedure SHOULD NOT be
   performed for Routes learned from peers of types other than EBGP.

... and this from Section 5:

   In some cases (particularly when the selection algorithm is
   influenced by the adjustment of a route property that is not
   propagated into IBGP) it could be necessary for routing correctness
   to propagate the validation state to the IBGP peer.  [...]

Regarding the latter: What kind of route property is envisioned that
is not propagated into IBGP, but _is_ propagated via EBGP?

Regarding the former: I expect many networks to be faced with
partial-deployment of origin validation for some time: some older edge
routers will never be upgraded to be rpki-cognizant, while most newer
edges and route reflectors will be.

When a route reflector learns a route from an rpki-ignorant edge, I
would want the RR to perform its own origin validation, deciding the
validation state based on its own local cache.

But taking this further: why _wouldn't_ we want the RR to perform the
same origin validation on every prefix it learns, based again on
contents of local cache and local policy?  I think we would.  

Going still further: rpki-cognizant edge routers should themselves
perform origin validation on all BGP-learned routes, even those
learned via IBGP from RRs.

At a minimum, if the draft's authors persist in recommending that
origin validation is only for EBGP, they should describe why that is.

					 Jay B.

---

From: "George, Wes" <[email-masked]>
Date: Wed, 14 Mar 2012 09:55:39 -0400

> From: Randy Bush [mailto:[email-masked]]
> Sent: Tuesday, March 13, 2012 5:03 PM
>

[WEG] makes perfect sense, thanks. Do you think that it's worth saying this more explicitly here?
Something like -

" 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, because the match is a logical OR, which makes the order irrelevant. This enables, among other things, a make-before-break change for such things as changing providers."

Thanks
Wes George

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 14 Mar 2012 10:39:24 -0400

>not relevant. It's a classic OR operation for the match.

I agree that it is an "OR" operation in general.
Let me just note that in Section 7.2 in the sidr-usecases document, 
we talked about use cases when a cert expires or a CRL is received that affects a ROA 
and in turn affects an existing BGP update that was validated with support of that ROA.
Then the relying party should check if there is another ROA (or another entry in ROA white-list) 
for a parent (i.e., less specific) prefix that may sustain the "Valid" status for the update in question.
Perhaps the sidr-pfx-validate document should also talk about what the algorithm should do in
reaction to a cert expiry or CRL receipt or an RPKI-rtr withdraw message (for a ROA white-list entry)?

Sriram

---

From: "George, Wes" <[email-masked]>
Date: Wed, 14 Mar 2012 11:57:06 -0400

> From: Pradosh Mohapatra [mailto:[email-masked]]
> Sent: Tuesday, March 13, 2012 4:07 PM
> To: George, Wes
> Cc: [email-masked]; [email-masked]; [email-masked]

[WEG] Originally I stopped short of fully suggesting text because I didn't think that I had a complete grasp of what the authors are suggesting should happen here based on the combination of the text above.
In rereading the surrounding text to make another attempt at it, I don't think that this sentence belongs in the definition for Route Origin ASN at all, because it's not really part of the definition. This is instructional about a special case of match/cover, and should probably be moved down a few sentences to where you talk about valid/invalid/unknown. The same is also true for the following from the definition of Matched.
        "keeping in mind that a ROA ASN of zero can never be matched, nor can a route origin AS
      number of "NONE"."

So I would strike the references to ASN 0 and origin AS NONE from the definitions altogether, and then reword the next section as follows:
CURRENT TEXT

" Given these definitions, any given BGP Route will be found to have
   one of the following "validation states":

   o  NotFound: No ROA Covers the Route Prefix.

   o  Valid: At least one ROA Matches the Route Prefix.

   o  Invalid: At least one ROA Covers the Route Prefix, but no ROA
      Matches it."

NEW TEXT

"Given these definitions, any given BGP route MUST [SHOULD?] be found to have one of the following "validation states":
   o  NotFound: No ROA Covers the Route Prefix.

   o  Valid: At least one ROA Matches the Route Prefix.

   o  Invalid: At least one ROA Covers the Route Prefix, but no ROA
      Matches it.
It should be noted that a ROA ASN of zero or a route origin AS number of "NONE" MUST NOT ever be considered matches. This means that routes with a covering ROA ASN of zero MUST be declared Invalid, and routes with a route origin AS number of "NONE" and one or more covering ROAs MUST be declared Invalid."

Is that a reasonably accurate interpretation of the intent?

> not relevant. It's a classic OR operation for the match.

[WEG] I didn't get "ordering not relevant" from the current text, but now that you say it, I see how it could be interpreted that way. See my suggested change as a reply to Randy's explanation.

Thanks
Wes George

---

From: David Mandelberg <[email-masked]>
Date: Wed, 21 Mar 2012 13:21:53 -0400

The prefix-to-AS mappings used by the BGP speaker are expected to be
   updated over time.  When a mapping is added or deleted, the
   implementation MUST re-validate any affected prefixes.  An "affected
   prefix" is any prefix that was matched by a deleted or updated
   mapping, or could be matched by an added mapping.

Shouldn't the two instances of the word 'matched' above be 'covered'
instead since covering mappings also affect validation states?

-- 
David Mandelberg
Wed Mar 21 13:20:52 EDT 2012