Subject: Re: [Sidrops] New Version Notification for draft-sriram-sidrops-drop-invalid-policy-00.txt

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 6 Mar 2018 16:34:17 +0000

We have requested the chairs for time on the SIDROPS meeting agenda to discuss this work:
 
https://tools.ietf.org/html/draft-sriram-sidrops-drop-invalid-policy-00 

The authors would appreciate comments/discussion on the list as well.

Sriram 
________________________________________
From: [email-masked] <[email-masked]>
Sent: Monday, March 5, 2018 5:59 PM
To: Sriram, Kotikalapudi (Fed); Montgomery, Douglas (Fed); Borchert, Oliver (Fed)
Subject: New Version Notification for draft-sriram-sidrops-drop-invalid-policy-00.txt

A new version of I-D, draft-sriram-sidrops-drop-invalid-policy-00.txt
has been successfully submitted by Kotikalapudi Sriram and posted to the
IETF repository.

Name:           draft-sriram-sidrops-drop-invalid-policy
Revision:       00
Title:          Origin Validation Policy Considerations for Dropping Invalid Routes
Document date:  2018-03-05
Group:          Individual Submission
Pages:          6

https://tools.ietf.org/html/draft-sriram-sidrops-drop-invalid-policy-00 

Abstract:
   During incremental deployment of RPKI and Route Origin Authorizations
   (and possibly under some transient conditions), network operators
   would wish to have a meaningful policy for dropping Invalid routes.
   Their goal is to balance (A) dropping Invalid routes so hijacked
   routes can be eliminated, versus (B) tolerance for missing or
   erroneously created ROAs for customer prefixes.  This document
   considers a Drop Invalid if Still Routable (DISR) policy that is
   based on these considerations.  The key principle of DISR policy is
   that an Invalid route can be dropped if a Valid or NotFound route
   exists for a subsuming less specific prefix.

---

From: Job Snijders <[email-masked]>
Date: Thu, 8 Mar 2018 14:08:32 +0000

> The authors would appreciate comments/discussion on the list as well.

Dear Sriram,

I like the general idea, it would be interesting to see this
standardized in a more formal form. We think the algorithm in section 3
needs some rework.

What if the implementer creates three RIBs:

    Loc-RIB-Validation-State-Valid
    Loc-RIB-Validation-State-Unknown
    Loc-RIB-Validation-State-Invalid

A composite Loc-RIB is then created by walking the RIBs in the above
order.

I don't any role for LOCAL_PREF in this context.

Kind regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 8 Mar 2018 15:25:36 +0100

Hi Sriram,

I think this addresses a concern that blocks uptake for transit networks in particular. So I am happy to see discussion on this, and hope that actual operators will speak to this. Hey Job, glad you did :)

One remark on the content.. would it make sense to have a different treatment in case an AS0 ROA is issued? I.e. in case an announcement is invalid due to AS0 and there is no valid announcement (there can’t be) - still drop it?

Tim

> On 6 Mar 2018, at 17:34, Sriram, Kotikalapudi (Fed) <[email-masked]> wrote:
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 9 Mar 2018 04:12:47 +0000

Job:

Appreciate the comments. Agree with you. Please see my specific responses inline below.

>standardized in a more formal form. 

Sounds great.

>We think the algorithm in section 3 needs some rework.

Agree.

>A composite Loc-RIB is then created by walking the RIBs in the above

Seems to make sense. Welcome the help very much. I'll email you my slides tomorrow. 
Please feel free to insert a slide or two on the algorithm that you and Saku would like to
suggest and also make any other changes you feel appropriate.
We can together try and get this in good shape for the discussion in SIDROPS.

>I don't any role for LOCAL_PREF in this context.

I think I might have gotten carried away in plugging in LOCAL_PREF.
We discussed this at NIST today. Doug and Oliver also agree with your observation.
We agree that the algorithm does not need to involve LOCAL_PREF.
I would assume that the algorithm/flowchart that you and Saku come up with
would take care of that. Look forward to it.

Thanks again.

Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 9 Mar 2018 05:41:08 +0000

Hi Tim:

Hi Sriram,

>One remark on the content.. would it make sense to have a different treatment in case an AS0 ROA is issued? I.e. in case an announcement is invalid due to AS0 and there is no valid announcement (the…

This is a good question. It came up also in discussions at NIST.
Let me try asking you to share your understanding of the difference 
between an AS 0 ROA versus a regular ROA for the same prefix. 

Say: 10.1.0.0/16 is owned by Org. X. Org. X creates a ROA. Consider two cases:
Case 1: ROA: {10.1.0.0/16, AS 0}   vs.   Case 2: ROA: {10.1.0.0/16, AS 111}

Questions:

1. Do you agree that in each case there can be suballocations, 
e.g., 10.1.0.0/20 is suballocated to Org. Y?

2. Do you agree that in each case Org. Y is at liberty to originate an update, e.g., Update: 10.1.0.0/20 AS 222 ?
 
3. Let us say that in each case, Org. Y did not create any ROA that would validate Update: 10.1.0.0/20 AS 222.
This happened for whatever reason. As a result, this Update is Invalid in both Cases 1 and 2.
There are no other routes announced for 10.1.0.0/20. 
What is fundamentally different about Case 1 that the Update 10.1.0.0/20 AS 222 
should be dropped and Org. Y is punished with unreachability, while in Case 2 Org. Y is not punished
but instead the Update is installed in FIB to avoid unreachability?
Org. Y is a legitimate owner 10.1.0.0/20 in both cases. 
If so, why should it get the benefit of doubt in Case 2 but not in Case 1?  

As you can see, I am struggling to see what is canonically or fundamentally different about the AS 0 ROA?
Any insight you can provide would be great.

(BTW, I have refreshed myself on RFCs 6483 and 6491 before asking these questions.)

Sriram

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Fri, 9 Mar 2018 14:23:25 +0000

Maybe another way to phrase this is, as far as we can tell (sec 4, RFC6483) the documented use of AS0 is a usage convention at best, i.e. does not have any specific normative requirements, beyond normal ROA / validation procedures.

Thus a route origination that is INVALID and has an AS 0 ROA in its set of covering ROAs, may well have other covering ROAs that are more specific, less specific, and/or the same length of the prefix in the AS 0 ROA.

While we agree that an AS 0 ROA is thought to have an explicit and different intent than typical ROA uses, if we are to consider actually treating it as a special case in the DISR algorithm, we would have to discuss the variety of situations in which they might appear.

After a 2 hour internal discussion of this yesterday, we did not come to a consensus as to how to approach this *if* one wanted to special case this scenario.

Some options we discussed include, treat AS 0 as a DISR special case if:

1. AS 0 is the only covering ROA for the route
2. AS 0 is the most specific covering ROA for the route
3. AS 0 ROA exists in the set of covering ROAs

Arguments could be made for each, but any agreement to special case AS 0 needs to consider the variety of potential usage patterns.

dougm
--
Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST

On 3/9/18, 12:41 AM, "Sriram, Kotikalapudi (Fed)" <[email-masked]> wrote:

    Hi Tim:
    
    Hi Sriram,

    
    
    Questions:

     

    
    Sriram

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 9 Mar 2018 15:27:23 +0100

Hi,

First off.. I don’t mean to complicate discussion too much with an edge case.

That said, the intent as I understand it of having an AS0 ROA *only* for a prefix is to communicate that it should never be routed. The holder does not intent to announce this space. They may have reserved, or use it internally, but whatever the case they don’t want it in the global BGP. Therefore it would make sense to me to drop the ‘if still routable’ part for prefixes that covered by (a) AS0 ROA(s) only.

Tim

> On 9 Mar 2018, at 15:23, Montgomery, Douglas (Fed) <[email-masked]> wrote:
>

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Fri, 9 Mar 2018 15:54:24 +0000

Hi Tim,

You did not complicate the discussion ... we had already discussed "what about AS0" but swept the issue under the rug at first.

So, in your case, you think option #1 below (AS 0 is the only covering ROA for the route) should get special cased in DISR?

Certainly this usage scenario seems less complicated than the others.  

I would like to mention the following so that we keep it in mind in discussing such techniques.

There are two common concerns that I hear when discussing enabling filtering based on RPKI data. (1) The fragility that might get introduced into the routing system - namely RPKI errors might impact basic reachability - DISR and similar ideas attempt address some of these concerns.  (2) Is concern for the "diagnosability" of the resulting filtering rules.  i.e., what information must one have to understand why a route was filtered/de-preffed etc.

I think there is a tension between these two concerns.  Any approach to improve resilience has to be weighed off against its complexity. 

Certainly, option #1, simplifies understanding "Why was this route dropped?". 

dougm
-- 
DougM at NIST

On 3/9/18, 9:27 AM, "Tim Bruijnzeels" <[email-masked]> wrote:

    Hi,

    
    Tim
    
    > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&data=02%7C01%7Cdougm%40nist.gov%7C95431606f01f42ad047b08d585c9e785%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636562024634679770&sdata=veU%2F%2BUTJez1QOpf1jd%2F2VpsP5IRTkzFDNBzT5Kt8p24%3D&reserved=0

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Mar 2018 11:17:14 -0500

Doug,

> Maybe another way to phrase this is, as far as we can tell (sec 4, RFC6483) the documented use of AS0 is a usage convention at best, i.e. does not have any specific normative requirements, beyond n…
Since 6483 is informational,  nothing it says is normative. However, 
RFCs 6491, 7606, and 7607 are standards track and the more relevant 
documents. Why did you not cite those RFCs and their (normative) 
statements for how AS 0 is to be treated in the RPKI context?

Steve

---

From: Jay Borkenhagen <[email-masked]>
Date: Fri, 9 Mar 2018 11:29:07 -0500

Sriram,

I can appreciate this motivation for your draft:  

Suppose Popular Site X does not know what they're doing, and they
publish a bad ROA that makes the only route announcement for their
address space be invalid.  ISP-A competes with ISP-B, and Customer-C
multihomes to both.  ISP-A implements route origin validation and
drops invalid routes -- including that route to X.  ISP-B does no
route origin validation, so they accept and propagate the route to X.
Customer-C does not know or care about origin validation -- they only
see that ISP-A cannot reach X while ISP-B can, so Customer-C thinks
ISP-A sucks and decides to give ISP-B more business.  

ISP-A should not be punished for trying to do the right thing, but
before we conclude that this situation deserves a technical
workaround, consider:

(1) Those who care about Internet routing security/sanity should
attempt to educate the folks at Popular Site X, to teach them why that
ROA is wrong.  This education can be done even before lots of
providers employ a 'drop invalid' policy -- in fact I know some
subscribers to this list have received emails from me saying "Y'know,
you're currently announcing some invalids."  Later on, that
education will happen the hard way when Popular Site X finds they
cannot be reached from many networks who by then drop invalids.

(2) Who's to say that an invalid-only route is invalid because of a
bad ROA, and not because someone other than the legit owner is
squatting on that address space?  Clearly squatting can happen on Not
Found space, too, but there could be reasons why they prefer to squat
on this space that happens to be covered by a ROA.  I think it's a
better outcome for people to realize what a ROA actually means and how
it gets used, rather than guessing that someone made a mistake.

I'll stop here for now, but I'll also note that I would not want any
of my router vendors to implement the DISR Policy.  I'll save those
reasons for later.

						Jay B.

---

From: Job Snijders <[email-masked]>
Date: Fri, 09 Mar 2018 16:32:11 +0000

Woah... not only do you not want to use it yourself, but you also want to
prevent others from using it?

I’d appreciate more elaboration!

Out of curiosity, are you doing OV today in your network and dropping
invalids?

Kind regards,

Job

On Fri, 9 Mar 2018 at 17:29, Jay Borkenhagen <[email-masked]> wrote:

>  > Subject: New Version Notification for
> draft-sriram-sidrops-drop-invalid-policy-00.txt
>  >

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Fri, 9 Mar 2018 16:48:44 +0000

Thanks Steve,

You are right that the RFCs below should be referenced also.  Having reviewed them again, nothing I said previously seems to have changed.   AS 0 is at best a suggested usage convention.

The thing I like about the 6483 text is that it makes explicit that ROAs can and will be created beneath an AS 0 ROA (one usage scenario is forcing your customers to issue ROAs before announcing their routes) and that all of this is "by convention".   So while not normative, I though 6483 painted the best picture of the issues we were discussing.

dougm
-- 
DougM at NIST
 
On 3/9/18, 11:17 AM, "Stephen Kent" <[email-masked]> wrote:

    Doug,

    Steve

---

From: Randy Bush <[email-masked]>
Date: Sat, 10 Mar 2018 16:00:01 +0900

> in case an announcement is invalid due to AS0 and there is no valid
> announcement (there can’t be)

<pedantry>

AS == 0 is just a ROA with an AS.  there may be other ROAs with other
ASs, one or more of which might validate an announcement.

randy

---

From: Job Snijders <[email-masked]>
Date: Sat, 10 Mar 2018 12:08:44 +0000

On Thu, Mar 08, 2018 at 03:25:36PM +0100, Tim Bruijnzeels wrote:
> I think this addresses a concern that blocks uptake for transit
> networks in particular. So I am happy to see discussion on this, and
> hope that actual operators will speak to this. Hey Job, glad you did
> :)
> 
> One remark on the content.. would it make sense to have a different
> treatment in case an AS0 ROA is issued? I.e. in case an announcement
> is invalid due to AS0 and there is no valid announcement (there can’t
> be) - still drop it?

Aside from complications related to AS 0 (it being an unroutable ASN) -
there is another type of prefixes where INVALID announcements should
never be accepted: IXP Peering LAN prefixes.

Take as example the DE-CIX Peering LAN prefix (taken from
https://www.peeringdb.com/ix/31) - it is not really globally reachable,
and that is the intention. What we see here though that some folks carry
it in their IGP http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=80.81.192.0
and seem to advertise it by accident to this collector.

These accidental announcements shouldn't be accepted, ever. This is the
ROA: http://localcert.ripe.net:8088/roas?q=80.81.192.0 - with the
current DSIR idea they _would_ be accepted if I am not mistaken.

DE-CIX is not announcing the peering lan prefix for various operational
reasons, and the ROA should help supress global visiblity, especially
the global visibility of more-specifics. More-specifics of the peering lan
are disastrous for IXPs.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Sun, 11 Mar 2018 12:50:17 +0900

> https://www.peeringdb.com/ix/31) - it is not really globally
> reachable, and that is the intention. What we see here though that
> some folks carry it in their IGP
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=80.81.192.0 and
> seem to advertise it by accident to this collector.
> 

who has the authority to issue valid roas for any possibly improper
subset of the de-cix lan?

if someone else announces a possibly improper subset of that lan,
it's a misannouncement and would be marked invalid.

if you hear that announcement and believe it, who's the fool?

randy

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sun, 11 Mar 2018 04:51:36 +0000

Job,

Tim wrote:
>>One remark on the content.. would it make sense to have 
>>a different treatment in case an AS0 ROA is issued? 
>>I.e. in case an announcement is invalid due to AS0 and 
>>there is no valid announcement (there can’t be) - still drop it?

>never be accepted: IXP Peering LAN prefixes.
-- snip --
>the global visibility of more-specifics. More-specifics of the peering lan

This seems like a nice use case for AS 0 ROA and DISR with Tim's suggested modification.
The IXP should create an AS 0 ROA for their LAN prefix.
And they should delete the ROA they currently have with their own AS.
(IXP is not announcing the LAN prefix.)
Then, any announcements of their prefix will be Invalid and dropped
by the DISR policy including Tim's suggested modification.
Also, with the AS 0 ROA, there is the added advantage that 
even forged-origin hijacks will be impossible.

Sriram

---

From: Job Snijders <[email-masked]>
Date: Sun, 11 Mar 2018 11:00:42 +0000

On Sun, Mar 11, 2018 at 12:50:17PM +0900, Randy Bush wrote:
> > These accidental announcements shouldn't be accepted, ever. This is
> > the ROA: http://localcert.ripe.net:8088/roas?q=80.81.192.0 - with
> > the current DSIR idea they _would_ be accepted if I am not mistaken.
> > 
> > DE-CIX is not announcing the peering lan prefix for various
> > operational reasons, and the ROA should help supress global
> > visiblity, especially the global visibility of more-specifics.
> > More-specifics of the peering lan are disastrous for IXPs.
> 
> if someone else announces a possibly improper subset of that lan, it's
> a misannouncement and would be marked invalid.
> 

Perhaps what is lacking in the semantics of RPKI is a "kill roa". On the
other hand, perhaps IXP Peering LAN prefixes are not a real problem. In
NTT's network this type of announcement is dropped regardless of any IRR
or RPKI information.

I feel AS 0 is being overloaded, AS0's non-routablility is being used in
a number of (too many) different ways.

Kind regards,

Job

---

From: Geoff Huston <[email-masked]>
Date: Sun, 11 Mar 2018 09:21:12 -0400

> 
> Perhaps what is lacking in the semantics of RPKI is a "kill roa”. 

https://datatracker.ietf.org/doc/draft-huston-sidr-bogons/

---

From: Job Snijders <[email-masked]>
Date: Sun, 11 Mar 2018 13:24:39 +0000

> https://datatracker.ietf.org/doc/draft-huston-sidr-bogons/

What happened to that draft?

Kind regards,

Job

---

From: Geoff Huston <[email-masked]>
Date: Sun, 11 Mar 2018 10:14:45 -0400

> On 11 Mar 2018, at 9:24 am, Job Snijders <[email-masked]> wrote:
> 

It was unceremoniously killed due to extreme distaste on the part of various folk who represented themselves as members of the crypto zealotry group. I also suspect that the authors’ efforts to use the term “boa constrictor" at least once the draft was seen as a juvenile attempt at humour. :-) I guess you just had to be there! 

More seriously, the draft encountered fatal levels of criticism over the concept of this form of validated negation.

g

---

From: Job Snijders <[email-masked]>
Date: Sun, 11 Mar 2018 14:25:00 +0000

On Sun, Mar 11, 2018 at 10:14:45AM -0400, Geoff Huston wrote:
> It was unceremoniously killed due to extreme distaste on the part of
> various folk who represented themselves as members of the crypto
> zealotry group. I also suspect that the authors’ efforts to use the
> term “boa constrictor" at least once the draft was seen as a juvenile
> attempt at humour. :-) I guess you just had to be there! 
> 
> More seriously, the draft encountered fatal levels of criticism over
> the concept of this form of validated negation.

Given that ~ 10 years have passed, and there are now give or take 5
autonomous systems doing Origin Validation, perhaps some of the folks
involved back then would be willing to reconsider their opinion? :)

Kind regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 12 Mar 2018 09:50:31 +0100

Hi all,

I believe something like this will be needed in case a DISR policy is used. As currently written the draft leaves any unannounced space vulnerable to hijacking. The only way really to counter this would be for the address holder to issue a ROA for their AS and do the public announcement - as Job pointed out there are operational reasons why this may not be possible / very undesired.

With regards to BOAs - my memory may fail me here because part of the discussion was from before even my time on this, but I thought it was concluded that the same could be communicated with an AS0 ROA, so there was no need for an explicit object type.

That said, If I can entertain the thought of a BOA or AS0 (as the only) ROA for address space.. then the intention would certainly be that an address holder can indicate that some of their address space should not appear in the global BGP. Implementing this is not super trivial - it’s not just another ROA for an AS that happens to be one that cannot be naturally found. In particular someone could do an announcement for a large prefix (say a /16 or something) that is less specific than any ROA issued. It would get RPKI validation state ‘not found’ and any otherwise unannounced space would be routed here. For BOAs / AS0 ROAs to work here the semantics would have to be changed to something like: if *any* of the address space in a prefix is covered by a BOA / AS0 ROA *only* then consider it *invalid* — or *forbidden* even if we want to recognise this as a different flavour of invalid.

Kind regards,

Tim

> On 11 Mar 2018, at 15:25, Job Snijders <[email-masked]> wrote:
>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 12 Mar 2018 19:06:00 +0000

Tim:

>For BOAs / AS0 ROAs to work here the semantics would have to be changed to something like: if *any* of the address space in a prefix is covered by a BOA / AS0 ROA *only* then consider it *invalid* - or *forbidden* even if we want to recognise this as a different flavour of invalid.

I agree with the spirit of your suggestion. But I feel we need to be 
careful about the meaning of "Covered by ROA."

I can think of a scenario:
ROA 1: 10.1.0.0/16   AS 0    
ROA 2: 10.1.0.0/18   ML=20   AS 64511
ROA 3: 10.1.0.0/22  AS 0
Update: 10.1.0.0/24   with some origin AS (other than AS 0)

Update for the /24 is Invalid due to any of the three ROAs.
I am pretty sure you want this Update dropped. Right?
The definition of "Covered by ROA" matters.
Especially, as I am thinking about your emphasis on *only*.
"Covered by ROA" is not defined in RFC 6811.
Instead "Covered by VRP" is defined (page 5):

   o  Covered: A Route Prefix is said to be Covered by a VRP when the
      VRP prefix length is less than or equal to the Route prefix
      length, and the VRP prefix address and the Route prefix address
      are identical for all bits specified by the VRP prefix length.
      (That is, the Route prefix is either identical to the VRP prefix
      or more specific than the VRP prefix.)

So I would suggest:

... for the Invalid route in consideration, consider the list of ROAs 
which make the route Invalid. From this list, consider 
the subset of ROAs (this may be one ROA or more)  with the *most specific prefix*.
If any of the ROAs in this subset contains an AS number that is not AS 0,
then proceed to the next step in the algorithm;
else, the Invalid route MUST be dropped.

Does this work for you? (We can discuss this further in London.)

Thank you.

Sriram

---

From: Jay Borkenhagen <[email-masked]>
Date: Tue, 13 Mar 2018 11:25:16 -0400

Job,

Whoa yourself.  :-)  That was a pretty extreme mis-reading of a very
small part of my message.

My reasons for preferring that my vendors do not implement DISR are:

 - implementing DISR would require changes to some very key parts of
   router code.  You might be right that there is a straightforward
   way to do it -- but it's still a change to some critical code, and
   any bugs introduced there could affect even those not using DISR.

 - the long-term goal should still be dropping all invalids, including
   those that DISR would permit.  So at best DISR should be only a
   short-term policy.

I don't think DISR is the right policy for anyone to use, for the
reasons I cited: (a) it's better to attempt to educate those
publishing what appear to be bad ROAs rather than making any
assumptions about them, and (b) the invalid-only route could be
announced by address squatters -- why assist the squatters?

I know of no significant ISP networks that are dropping invalids
today.  (I am not discussing IXPs here.)  I also know of no one saying
they would be dropping some invalids today if only DISR were
available.

Before we get hung up on how DISR would be implemented in router code,
let's discuss whether it's a policy ISPs should actually deploy.  For
the reasons I have explained, I say it's not.

Out of curiousity, are you attempting to educate those announcing
invalids today?

Thanks.

						Jay B.

---

From: Job Snijders <[email-masked]>
Date: Tue, 13 Mar 2018 16:05:17 +0000

Hi Jay,

On Tue, Mar 13, 2018 at 11:25:16AM -0400, Jay Borkenhagen wrote:
>  router code.  You might be right that there is a straightforward way
>  to do it -- but it's still a change to some critical code, and any
>  bugs introduced there could affect even those not using DISR.

Eh.... yes... so don't write bugs? Your reasoning applies to any change,
in any aspect of a codebase. While your fear may be justified, this type
of argument is hard to take into consideration from an IETF perspective.

>  those that DISR would permit. So at best DISR should be only a

Yes.

> they would be dropping some invalids today if only DISR were

I'm certainly struggling to find some kind of pathway towards dropping
invalids, and would seriously consider deploying DISR-style filters if
they were available to me.

> the reasons I have explained, I say it's not.

Yes - this is the big question.

We agree on the observation that nobody is dropping invalids, so we have
to ask ourselves: what is the resaon for this? Is there a way to
overcome whatever obstacles ISPs see?

A problem I see at this point in time is that if there are three
networks: A, B & C - and A does origin validation but B does not, then
B will be rewarded for mistakes that happen in the administrative domain
of C. This makes origin validation a really tough sell.

I appreciate that DISR attempts to mitigate some of these concerns - but
obviously DISR (in its _current_ form) introduces some problems as well,
namely opening up the option to more easily squat on unannounced space.

One could consider it a trade-off: does attempting to level the playing
field between network A & network B from an incentive perspective,
justify a weakening of protection of (perhaps purposefully) unannounced
space?

> Out of curiousity, are you attempting to educate those announcing

Yes.

kind regards,

Job

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Tue, 13 Mar 2018 16:15:01 +0000

I believe, the end goal in mind should be "drop invalid". 
Said that, I also don’t believe we are there yet. In my opinion, during the deployment
stage, DISR allows a safe “drop invalid” as long as it is still routable. 

And yes, DISR clearly does poke holes into the draconian “drop invalid policy”. I also 
believe that address owners should have to capability to specify their address space as a 
“DISR free zone”. 

For this I look at AS-0 in a somewhat more simplistic way:

What if regarding to DISR, AS 0 is defined the following way:
- “Any prefix with the validation state ‘invalid’ and covered by an AS-0 ROA 
    must be dropped or ignored!”

And if DISR gets extended by:
- “Drop or ignore routes with validation state ‘invalid’ if still routable and 
    NOT covered by an AS 0 ROA!”

Another simpler definition for both above in one could be:
- “DISR will not be employed for address space covered by an AS-0 ROA”

In the later one, an AS-0 ROA disables DISR for the specific address space and if DISR is not
deployed at all, AS-0 ROA ROV just does the same as it already does today!

This is simple, to the point and not really difficult to implement. 

Thanks,
Oliver

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Mar 2018 20:13:28 -0400

Doug,

I'm puzzled by your interpretation of RFC 7607. Specifically, Section 2 
of 7607 says:

    2. Behavior

    A BGP speaker MUST NOT originate or propagate a route with an AS
    number of zero in the AS_PATH, AS4_PATH, AGGREGATOR, or
    AS4_AGGREGATOR attributes.

    An UPDATE message that contains the AS number of zero in the AS_PATH
    or AGGREGATOR attribute MUST be considered as malformed and be
    handled by the procedures specified in [RFC7606].

    An UPDATE message that contains the AS number of zero in the AS4_PATH
    or AS4_AGGREGATOR attribute MUST be considered as malformed and be
    handled by the procedures specified in [RFC6793].

    If a BGP speaker receives zero as the peer AS in an OPEN message, it
    MUST abort the connection and send a NOTIFICATION with Error Code
    "OPEN Message Error" and subcode "Bad Peer AS" (seeSection 6 of [RFC4271]).  A router MUST NOT initiate a connection claiming to be
    AS 0.

This seems pretty definitive, and normative, not just a "usage convention" for AS 0,
as you suggest.

Steve

---

From: Job Snijders <[email-masked]>
Date: Wed, 14 Mar 2018 00:20:53 +0000

On Tue, Mar 13, 2018 at 08:13:28PM -0400, Stephen Kent wrote:
> I'm puzzled by your interpretation of RFC 7607. Specifically, Section
> 2 of 7607 says:
> 
> [...] 
> 
> This seems pretty definitive, and normative, not just a "usage
> convention" for AS 0, as you suggest.

The use of AS 0 in ROAs is not the same as the use of AS 0 in BGP UPDATE
messages. The former is allowed, the latter is not.

Kind regards,

Job

---

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Wed, 14 Mar 2018 02:54:12 +0000

Steve,

Sorry, yes I agree that 7607 updates 4271 to make it clear that AS0 should not appear in a PATH.   So implementations that comply with both 7607 and 4271 should handle AS0 in BGP as expected.

But that was not my point.  My point was what “the meaning” of a ROA with AS0 is.  As far as I can tell one could encounter an AS0 for an address block with:

  1.  Valid (non AS0) ROAs above it (less specific block)
  2.  Valid (non AS0) ROAs below it (more specific block)
  3.  Valid (non AS0) ROAs with the same prefix as in the AS0 ROA.

So, for example, in case #2 above the use case might be to prevent squatting on unannounced address space by creating an AS0 ROA for an entire allocation, then creating non-AS0 ROAs for the specific sub-prefixes that are routed.  So clearly intent of the AS0 ROA in this case is not “you should never see these addresses announced in routing”.  One would have to examine the full collection of covering ROAs to understand the intended use case.

As far as I know there are no special cases in the X.509 validation of RPKI objects associated with AS0, nor are there special cases in the BGP prefix validation algorithm associated with AS0. I am not sure if hosted RPKI services special case AS0 in any way in their ROA creation logic.

So, what we have is an AS value that we have updated 4271 to make clear should never appear in an AS_PATH.   We leverage that fact to note that we can now create ROAs with AS0 that can result in an “INVALID” result in origin validation as long as there are no other covering & matching ROAs that would result in a “VALID”.

Thus the net effect of a covering AS0 ROA can’t be determined in isolation.  One has to consider the overall usage scenario to understand the ramifications.

I found that RFC6483 explained this nicely, noting that it is “by convention” that AS0 can result in INVALID in some usage scenarios and noting some of the scenarios where this is not the case.

I will say that I have seen a few comments in this thread where I think some folks have lost track of the fact that:

(a)    A covering AS0 ROA alone does not guarantee an INVALID result, and,

(b)    An INVALID result does not guarantee that the update with be ignored in the decision process. That will always be subject to local policy.

Comments along the lines of “… an AS0 implies must drop …” would be a change to both of these facts, and would require updates to existing base specs to make it so.

It should also be noted that the DISR idea was not proposing any changes to normative behavior of RPKI or Origin Validation.  Instead it was proposed as a form of local policy mechanism aimed at reducing operator’s concerns about potential network unreachability triggered by RPKI errors or omissions.  I do think if DISR-like ideas have merit, then the idea of special casing AS0 in the local policy might have value, but we need to work through the three cases above to be clear what that special case logic might be.

While I am rambling, I should also say that I agree with Jay and points that Tim made some time ago that one wants to be careful with the tradeoffs of lessening the potential impact of errors in the data, as it is typically only the tension caused by a negative impact that inspires people to update and correct the data in the first place.

dougm
--
DougM at NIST

From: Stephen Kent <[email-masked]>
Date: Tuesday, March 13, 2018 at 8:13 PM
To: Doug Montgomery <[email-masked]>, "Sriram, Kotikalapudi (Fed)" <[email-masked]>, Tim Bruijnzeels <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Sidrops] New Version Notification for draft-sriram-sidrops-drop-invalid-policy-00.txt

Doug,

I'm puzzled by your interpretation of RFC 7607. Specifically, Section 2 of 7607 says:

2. Behavior

   "OPEN Message Error" and subcode "Bad Peer AS" (see Section 6 of

   [RFC4271]).  A router MUST NOT initiate a connection claiming to be

   AS 0.

as you suggest.

Steve

Thanks Steve,

dougm

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Mar 2018 13:13:35 +0900

> DISR allows a safe “drop invalid” as long as it is still routable.

read that again with the goal of rpki-based origin validation, stopping
accidental mis-originations, in mind.

randy

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Mar 2018 15:02:44 -0400

Doug, Bob,

Whoops, you're right. 7607 is not applicable to this discussion, as it 
is describing Updates not ROAs. My bad.

Also, Doug, I reluctantly agree that 6483, as an informational RFC, does 
not mandate any behavior. The phrase "by convention" describes the 
suggested ROA length for IPv4 and v6, and suggests that it be used 
exclusively for an address block, with no more specifics. But, as you 
noted, there may be a range of cases in which an INR holder might  use 
an AS 0 ROA and that might cause confusion, absent additional guidance.

RFC 6491 (which is standards track) specifies how IANA planned to use AS 
0 ROAs to mark all reserved and un-allocated  resources as well as some 
types of special purpose resources managed by IANA. It seems to imply 
the processing that it expects of relying parties when these ROAs are 
encountered, but it fails to provide explicit guidance in this respect.

No, I don't recall that the RPKI specifies unique processing for AS 0 ROAs.

Steve

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Thu, 15 Mar 2018 20:15:36 +0000

Sure, if the "accidental mis-origination" is the only origination made, DISR will not drop the invalid
and ROV did not help at all in preventing the particular "accidental mis-origination".
If on the other hand the "accidental mis-origination" is covered by another route, it will be dropped
and in this case ROV did prevent the " accidental mis-origination" from being propagated.

What DISR does, it allows to deploy a softer "drop invalid" without the danger of losing connectivity 
until the operator decides to turn off DISR and "drop invalid". 

At the end, it is all local policy what to do with invalid. DISR just provides a defined
algorithm on how to act upon ROV results during the deployment stage by reducing 
loss of reachability due to "mis-configuration" lack of ROA's etc.

Oliver

    
    
    randy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 15 Mar 2018 19:36:12 -0400

Sriram,

> The authors would appreciate comments/discussion on the list as well.

I have a concern with one of the terms of your procedure.  From section 3:

:    4.  If selected route is Valid/NotFound, then add the route to Loc-
:        RIB; Else, if Invalid, then add the route to Loc-RIB only if
:        there is no existing route in the Loc-RIB for a subsuming Less
:        Specific prefix.

This sort of thing tries to get periodically added to BGP specs.  In
general, BGP tries *VERY* hard to avoid any sort of cascading dependency
between routes due to the ripple effects.  Enough so that the following is
enshrined in the core spec:

RFC 4271, Section 9.1:

:    The function that calculates the degree of preference for a given
:    route SHALL NOT use any of the following as its inputs: the existence
:    of other routes, the non-existence of other routes, or the path
:    attributes of other routes.

I appreciate what you're trying to do here.  However, my strong advice is
DON'T.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Fri, 16 Mar 2018 00:01:57 +0000

Dear Jeff,

On Thu, Mar 15, 2018 at 07:36:12PM -0400, Jeffrey Haas wrote:
> general, BGP tries *VERY* hard to avoid any sort of cascading
> dependency between routes due to the ripple effects.  Enough so that
> the following is enshrined in the core spec:
> 
> RFC 4271, Section 9.1:
> 
> I appreciate what you're trying to do here.  However, my strong advice
> is DON'T.

I'd appreciate if you can elaborate more on your advice (perhaps from a
protocol architecture perspective). In quite some BGP implementations
the concept of "Conditional advertisements" is considered a feature,
which is seemingly at odds with RFC 4271 section 9.1.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 16 Mar 2018 09:41:03 -0400

> which is seemingly at odds with RFC 4271 section 9.1.

Conditional advertisement (insertion into the adj-ribs-out) is very
different than impacting the route selection of loc-rib itself.  Hopefully
this clarifies the issue.

-- Jeff