Subject: [sidr] rpki-rtr-25 notes

From: Wes Hardaker <[email-masked]>
Date: Sat, 04 Feb 2012 09:48:34 -0800

Just finished (finally) scanning the rpki-rtr document (-25 version) and
have a few notes about it.  Over all, though, nicely done ID.  Thanks!

A) It's too early for nit edits, but this one just jumped at me and I
   couldn't ignore it.

   5.1, 3rd paragraph(/sentence): is only -> is *the* only

B) 5.9: the 2nd and 4th paragraphs seem to contradict each other.  I
   suspect that the intent is that you can send a generic error after a
   particular PDU, but the way it's phrased is a bit odd and it jumped
   out at me too.  How about:

   If the error is generic (e.g. "Internal Error") and not associated
   with the PDU it is responding to, the Erroneous PDU field ...

   Note that with this exception rule you could still end up in some
   state where the generic error isn't fatal and you need to respond
   with a specific and a generic error, but you can't send 2 error
   reports.  Thus, hopefully generic errors will always be fatal?

C) 5.10 seems to indicate rcynic (a very fine tool) is ubiquitous
   because it's quoting it like everyone knows what it is (and
   always will).  I'd leave the example tool name out.

D) 7. Transport....  Multiple issues

D.1) "Unfortunately there is no protocol to do so on all currently used
     platforms".  

     I actually doubt the validity of that statement.  I suspect SSH is
     likely available on them all.  Or at least "nearly all" (and I
     doubt anything will ever reach "all").  I'd bet TLS is nearly
     ubiquitous as well, though probably less than SSH.

D.2) The ordering of the 5th-8th(ish) paragraphs seems weird.  I'd group
     them together by subject such that the sections that talked about
     unprotected TCP should be next to each other and the ones that
     talked about the protected ones be together.  Thus, I think just
     moving the 2 unprotected paragraphs ("Caches and routers MUST..."
     and "If unprotected TCP...") to positions 5 and 6 would solve most
     of the oddities.

D.3) I'm not sure that the whole concept of "MUST implement unprotected"
     is going to fly through a security review.  I know I'd flag it.
     Generally I'm not sure it's wise to mandate insecurity, though I do
     agree it may be a nice feature to have (did I really just say that???)

D.4) There is some confusion regarding whether routers "use" vs "can be
     configured to use".  EG: "Caches and routers SHOULD use TCP-AO..."
     IMHO, this indicates they have a choice.  "SHOULD be able to use"
     might be a better wording choice implying its subject to
     configuration by the operator.  If you want a more complete list of
     places where I think this might be a problem, I can supply one of
     course.

D.5) "If available to the operator...".  How would the router know
     what's available to the operator?  Or does this mean that if the
     device already implements protocol X, it must offer it as a
     configuration choice for rpki-rtr transport?  If so, that's not
     entirely clear.

D.6) I'd order the sub-sections to be in the same order as the list
     above it.  IE, TCP-AO is first in the list, so the TCP-AO
     sub-section should probably come first.

E) 7.1 SSH transport "Client routers SHOULD verify the public key of the
   cache".  Similar to D.4, I'd change this to "Client routers MUST
   be able to verify the public key of the cache".

F) 7.2 TLS transports: the CN field is really being deprecated and I'd
   suggest using the subject alt name instead (SAN).

G) section 8, paragraph 2 implies that the cache needs a list of names
   for the peer and I'm not sure this is true.  In fact much of that
   paragraph talks about the router/client side only, so I'd split the
   paragraph in two: one for cache requirements and one for the router
   requirements.

H) section 8: I'd change "Key" to either "TheirKey" or "ItsKey"

I) section 8: "it would be prudent for the client"...  This seems like a
   good place for the word SHOULD to sneak in there somewhere.

J) section 8: "if data from multiple caches are held, implementations
   MUST NOT distinguish between data sources when performing
   validation".

   This one confuses me.  It's unclear, after reading the entire
   document, why you have a preference ordered list if the data from
   them all must be treated equally.  Is the goal to have a preference
   order list because you want to really only have, ideally, a single
   cache and the others are fallbacks?  Or is it because you want to
   have N/M established at any point?  Either way, if they're all equal
   then what happens when popular #1 is overloaded and slower and issues
   an announcement after #2 has issued a withdrawl, or vice versa.
   Either way you end up in a race-condition based state.  This should
   probably be discussed and at least mentioned, even if you choose
   not to solve it by a preference setting somewhere.  Though I'd
   certainly want to leave room in the configuration engine to allow for
   a preference setting even if implementing it is optional.

K) I didn't dive heavily into the security considerations because of
   some of the above that I suspect may affect it.  I'd be happy to if
   it's ready to be dived into though.

Again, nicely done document.  Clear and straight forward (though at
times I had to predict what was coming ahead to make sense of the
current paragraph, I think that's generally hard to avoid).

-- 
Wes Hardaker

---

From: Randy Bush <[email-masked]>
Date: Sat, 04 Feb 2012 15:43:04 -0800

> A) It's too early for nit edits

not really.  as the iesg has approved this one, changes are going to be
a process pain.  so this message pushes back on some of your suggestions
which i would otherwise have gladly taken.

perhaps the sponsoring AD will give me/us some guidance in this.

also please excuse the roughness of my response.  i just hit san diego
from a few time zones to the west.

>    5.1, 3rd paragraph(/sentence): is only -> is *the* only

done

>    with the PDU it is responding to, the Erroneous PDU field ...

sure

> C) 5.10 seems to indicate rcynic

not in -26

>      likely available on them all.

no it is not.  see voluminous discussion on list.  to save you the
search, very common router platforms provide hard coded ssh client and
server, but no ssh library which a protocol such as this can use.

>      Or at least "nearly all" (and I doubt anything will ever reach
>      "all").  I'd bet TLS is nearly ubiquitous as well, though
>      probably less than SSH.

about the same mess

>      and "If unprotected TCP...") to positions 5 and 6 would solve most

not sure this is sufficiently problematic to tempt the $dieties post
iesg approval.

>      is going to fly through a security review.

it did.  after a bit of discussion.

>      places where I think this might be a problem, I can supply one of

not sure this is sufficiently problematic to tempt the $dieties post
iesg approval.

>      configuration choice for rpki-rtr transport?  If so, that's not

i think the meaning is pretty clear, though i guess it could be better
phrased.  but it has to be available on *both* router and cache server.

>      sub-section should probably come first.

probably.  but it may be safest to let the rfced hack it.

>    be able to verify the public key of the cache".

the looser but riskier phrasing was not an accident.

>    suggest using the subject alt name instead (SAN).

see -26 for a complete rewrite of the tls section

> H) section 8: I'd change "Key" to either "TheirKey" or "ItsKey"

if so, probably should be CacheKey.  but whose key it is seems very
clear from the next few words, yes?

>    good place for the word SHOULD to sneak in there somewhere.

eenie meenie.  did not see a need to be that strongly prescriptive.

>    them all must be treated equally.

proximity and security

randy

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 05 Feb 2012 20:51:11 -0800

>>>>> On Sat, 04 Feb 2012 15:43:04 -0800, Randy Bush <[email-masked]> said:

>> A) It's too early for nit edits

RB> not really.  as the iesg has approved this one, changes are going to be
RB> a process pain.  so this message pushes back on some of your suggestions
RB> which i would otherwise have gladly taken.

As I said in a private message to you the other day: I think I probably
hold the record for "people that responded with comments about a draft
after the very last cut-off date".  I'm exceptionally good at being a
day or two late about reviewing drafts.

RB> if so, probably should be CacheKey.  but whose key it is seems very
RB> clear from the next few words, yes?

I think "CacheKey" is perfect, except that then I'd want to change
"MyKey" to "RouterKey".

>> good place for the word SHOULD to sneak in there somewhere.

RB> eenie meenie.  did not see a need to be that strongly prescriptive.

>> them all must be treated equally.

RB> proximity and security

The above two issues just made me wonder about the interchangeability of
the configuration model.  Since the text shys away from describing what
actually happens when you have multiple caches available, we'll end up
with a case where a configuration set on one machine may not act the
same way on another.  Though there is no standard configuration model at
the moment, so maybe it's all moot until someone creates a YANG follow-up.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 05 Feb 2012 20:52:29 -0800

[PPS: I don't expect a response to my just-posted-note since it's really
beyond the point of worth in keeping the discussion going]
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 06 Feb 2012 13:16:06 +0000

Randy

The process:

If they are just nits, then just tell the editor either
now or in Auth48.

If they are technical errors such as those that would be
excepted under errata - i.e. the intent of the IETF was
clear but the wrong words were put in the draft -
I will sign them off in Auth48.

If they are real technical changes, then it is too late,
a draft updating this RFC needs to be written.

... unless of course the protocol is broken and thus
we cannot proceed with publication, in which
case the draft has to be withdrawn from the RFC
Editor's queue and I need to figure out how far
back in the process I need to take the draft.

Fortunately I do not think that there are any
in the final category.

- Stewart

On 04/02/2012 23:43, Randy Bush wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html