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

[Jay Borkenhagen <[e-mail]>]

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