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

[Jay Borkenhagen <[e-mail]>]

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.


Job Snijders writes:
 > 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 <[e-mail]> wrote:
 > 
 > > 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.
 > >
 > >
 > >
 > > Sriram, Kotikalapudi (Fed) writes:
 > >  > 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: [e-mail] <[e-mail]>
 > >  > 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.
 > >  > _______________________________________________
 > >  > Sidrops mailing list
 > >  > [e-mail]
 > >  > https://www.ietf.org/mailman/listinfo/sidrops
 > >
 > > _______________________________________________
 > > Sidrops mailing list
 > > [e-mail]
 > > https://www.ietf.org/mailman/listinfo/sidrops
 > >
 > _______________________________________________
 > Sidrops mailing list
 > [e-mail]
 > https://www.ietf.org/mailman/listinfo/sidrops