Subject: [sidr] #7: nits for roa-validation

From: "sidr issue tracker" <[email-masked]>
Date: Wed, 11 Nov 2009 11:28:46 -0000

#7: nits for roa-validation
--------------------------------+-------------------------------------------
 Reporter:  gih@…               |       Owner:            
     Type:  defect              |      Status:  new       
 Priority:  major               |   Milestone:  milestone1
Component:  roa-validation      |     Version:            
 Severity:  Active WG Document  |    Keywords:            
--------------------------------+-------------------------------------------
 reported by John Scudder:

 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

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sidr/trac/ticket/7>
sidr <http://tools.ietf.org/sidr/>