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

["Montgomery, Douglas (Fed)" <[e-mail]>]

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 <[e-mail]>
Date: Tuesday, March 13, 2018 at 8:13 PM
To: Doug Montgomery <[e-mail]>, "Sriram, Kotikalapudi (Fed)" <[e-mail]>, Tim Bruijnzeels <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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





   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" (see Section 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

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