Re: [sidr] rpki-rtr-25 notes

[Randy Bush <[e-mail]>]

> 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

> 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 ...

sure

> C) 5.10 seems to indicate rcynic

not in -26

> 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.

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

> 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.

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

> D.3) I'm not sure that the whole concept of "MUST implement unprotected"
>      is going to fly through a security review.

it did.  after a bit of discussion.

> 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.

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

> 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.

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.

> 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.

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

> 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".

the looser but riskier phrasing was not an accident.

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

see -26 for a complete rewrite of the tls section

> 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"

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

> 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.

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

> 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.

proximity and security

randy