Subject: [apps-discuss] APPSDIR review of draft-ietf-sidr-rpki-rtr-25

From: Lisa Dusseault <[email-masked]>
Date: Mon, 30 Jan 2012 10:03:32 -0800

Document: draft-ietf-sidr-rpki-rtr-25

Title: The RPKI/Router Protocol
Reviewer: Lisa Dusseault
Review Date: Jan 30
IETF Last Call Date: Nov 29 2011
IESG Telechat Date: Feb 2 2012?
Summary: Ready for publication on the standards track.

I reviewed draft-ietf-sidr-rpki-rtr-25 for the Apps Area group.

I noted that this draft is clear and mature for a v0 protocol.  It
describes a protocol that has been implemented at least in part in five
different implementations.  It has undergone lively discussion in an active
WG and in IETF Last Call.  The latest document iterations show a great deal
of stability.  This all suggests to me that if any flaws in architecture or
suitability exist, I am not going to be good at identifying them, as I am
not a routing domain expert.  Thus, I reviewed this document mostly from
the point of view of an outsider (can a reader with general Internet
expertise understand the document?) and I looked for general issues such as
IANA registry issues.

Section 7 (Transport)

I'm not qualified to judge the tradeoffs between supporting unprotected
TCP, waiting for TCP-AO, or doing something else, but I did note this had
been extensively discussed during IETF last call.

I read this section and then made some inferences:

 - Only a human administrator can tell if a collection of routers and
caches using RPKI are "on the same trusted and controlled network"
 - A human administrator would configure the routers and caches to use TCP,
based on their trust of the local network.
 - A router would not attempt to use the RPKI-rtr port with unprotected TCP
unless it was configured by the human administrator to do so
 - Thus, there is not a downgrade attack unless a human is involved in the
decision to downgrade the security configuration

I also infer that while a cache implementation MUST generically implement
unprotected TCP as a transport, that an instance of a cache may well be
configured simply not to respond to TCP requests on the RPKI-rtr port.

If these inferences are wrong, then I do have concerns about the
possibility of a downgrade attack.  However, I believe these inferences are
correct (and supported by text in section 11, e.g. "must rely on network
design and operational controls to provide protection") and are probably
the inferences any reasonably informed reader would make.  I did read the
architecture draft referenced in the introduction, but did not read all the
other WG drafts relating to RPKI.

Section 7.2 (TLS transport)

It's not clear to me why routers would need to provide a client certificate
to caches, because I had not assumed that the data transported in RPKI-RTR
was sensitive, only that it needed to be valid and authorized. I'm guessing
it has something to do with being able to manage load on very central
caches by dropping requests from unauthorized routers, which would be
either maliciously or unintentionally configured to use a cache that was
not set up to handle the load of those unauthorized routers.  If this is a
correct guess, I wonder if it would be helpful to be a bit more explicit
about this possibility?  Will there need to be an error code added, to be
used when a cache has to reject an unauthorized router request?

Section 11 (security considerations)

Except for my confusion around why routers need to identify themselves to
caches (what's the threat model for needing that), I appreciate the clarity
of this section.

Lisa D.

---

From: Randy Bush <[email-masked]>
Date: Tue, 31 Jan 2012 08:27:54 +0900

< irrelevant soapbox >

hi lisa,

will respond in general when both i and rob can sync across ten time
zones.

but i am gonna put my foot in it here, because you pushed a religious
button of mine.  it is not particularly relevant to the document, but
i am not one to ignore an offered soapbox :)

> decision to downgrade the security configuration

there exist automated configuration generation systems where no human
configures the router at all.  this is a very good practice and has been
deployed in some large isps for a decade or more.  

the security folk have recently (the last three or four years or so)
taken an interest and are using this to build the theory and tool
framework to generate network (yes, network, not router!) configurations
with known security properties.  this is downright delicious.  i have
found the work of geoffrey xie and sanjai narain to be among the more
interesting.  but the field is becoming popular.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 01 Feb 2012 06:28:11 +0900

hi lisa,

> I noted that this draft is clear and mature for a v0 protocol.

thanks

> decision to downgrade the security configuration

you are basically correct.

> configured simply not to respond to TCP requests on the RPKI-rtr port.

definitely

> not set up to handle the load of those unauthorized routers.

exactly.

> If this is a correct guess, I wonder if it would be helpful to be a
> bit more explicit about this possibility?  Will there need to be an
> error code added, to be used when a cache has to reject an
> unauthorized router request?

no error code as no session to transport it.  but explaining why the
defense would be good.  thanks.

but, truth be told, no implementors are playing tls.  given peter's
concerns about tls, we would consider just dropping it if it is not too
much of a change at this late date.

randy