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

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 <jayb@braeburn.org> 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: internet-drafts@ietf.org <internet-drafts@ietf.org>
>  > 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
>  > Sidrops@ietf.org
>  > https://www.ietf.org/mailman/listinfo/sidrops
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>