Subject: [sidr] Comments on draft-ietf-sidr-roa-validation-03

From: "John G. Scudder" <[email-masked]>
Date: Wed, 11 Nov 2009 14:52:26 +0900

George and Geoff --

Some comments, questions, and nits for you (in that order).

Comment:  I think this text, from S 4.1, is not quite right:

   This approach to route object origination validation uses a model of
   "positive security" attestations, where information that cannot be
   validated within the RPKI framework is intended to interpreted by a
   RP as invalid information.

Unless you interpret "unknown" as being a flavor of "invalid" (which  
would be terribly confusing!) this conflicts with S 2.  It would have  
been right to say something to the effect of "... information that  
conflicts with validation data within the RPKI framework ...".  I  
think you could make this change without loss of generality.

Comment: I think you've already gotten feedback on the list suggesting  
that S 4.1 needs more clarity regarding the effect of maxLength.  I  
agree.

Comment: Given that you discuss BGP at some length, I think you need  
to talk about the case where the origin AS can't be determined,  
specifically where the AS_PATH starts with an AS_SET.  (The same  
criticism applies to draft-pmohapat.)  This is actually a somewhat  
vexing problem because on one hand, "unknown" seems the only  
reasonable outcome for such a route, but on the other, that would seem  
to provide an easy vector for an attacker to always be able to get his  
route to be ranked as "unknown" instead of "invalid".  Then again, as  
we know origin authentication alone is trivially easy to attack so I  
think this is not too much of a practical concern.

Comment: In S 4.3 I find this to be unclear:

      *  It is a matter of local configuration as to whether ROA
         validation is performed on a per-AS basis rather than a per-BGP
         speaker, and the appropriate mechanisms to support a de-coupled
         framework of validation of ROAs and the loading of outcomes
         into BGP speakers are not considered here.

In fact I only finally got after hearing George's presentation, that  
what you mean is whether validation is done on the router or in some  
off-box server.  I think the red herring was the "per-AS" language.

Question: S 4.2 says "... or even if the maxLength element were to be  
omitted from the ROA".  Does the definition of a ROA even allow for  
that?  I thought maxLength was a mandatory element (though I admit I  
haven't checked).  Depending on the answer you might remove the clause.

Nit: I found your use of the term "route object" confusing given  
earlier uses of the term to mean something different (e.g. in the  
IRR).  How about using the term defined in RFC 4271 Section 1.1:

   Route
      A unit of information that pairs a set of destinations with the
      attributes of a path to those destinations.  The set of
      destinations are systems whose IP addresses are contained in one
      IP address prefix carried in the Network Layer Reachability
      Information (NLRI) field of an UPDATE message.  The path is the
      information reported in the path attributes field of the same
      UPDATE message.

You could refer to this as "BGP Route" to disambiguate it from any  
other meaning of "route".

If you don't want to do this you might at least note up front that  
your use of "route object" is the same as "route" as defined in 4271  
S1.1.

Nit: S 4.1 "Routes objects that describe..." should be "Route objects  
that describe..."  Or of course, just "Routes that describe" if you  
choose to adopt my suggestion above.

Regards,

--John