Subject: [sidr] Expected protocols in rpki-rtr

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 10:34:07 -0700

Greetings again. Section 7 of draft-ietf-sidr-rpki-rtr-14 has a list of supported transports. However, it does not list the one that some people have said that they expect it to be run under sometimes, namely bare TCP. If we all know that this is likely to be the case, we should have it listed in the document. I propose the following for the end of section 7, just before 7.1:

   Caches and routers MAY use unprotected TCP as a transport,
   even though this provides none of the security protections of
   the other protocols listed here. Unprotected TCP MUST only be
   used when there is other forms of trusted security in place.

Of course, we can also just ignore the fact that many users want to do this, but being honest in the document might be better than pretending otherwise.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Aug 2011 10:42:52 -0700

>     used when there is other forms of trusted security in place.

Hi, all,

IMO, this last line should read:

other forms of trusted security at or below TCP

I.e., TLS is not a viable solution to "untrusted TCP" - it may address 
trust at other layers, but not at the transport.

Joe

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Tue, 2 Aug 2011 13:47:36 -0400

As a practical matter, what do you think the effect of the "MUST" in the
last sentence will be?

-- 
Doug Montgomery  Mgr. Internet & Scalable Systems Research / ITL / NIST

On 8/2/11 1:34 PM, "Paul Hoffman" <[email-masked]> wrote:

>Greetings again. Section 7 of draft-ietf-sidr-rpki-rtr-14 has a list of
>supported transports. However, it does not list the one that some people
>have said that they expect it to be run under sometimes, namely bare TCP.
>If we all know that this is likely to be the case, we should have it
>listed in the document. I propose the following for the end of section 7,
>just before 7.1:
>
>Of course, we can also just ignore the fact that many users want to do
>this, but being honest in the document might be better than pretending
>otherwise.
>
>--Paul Hoffman
>
>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 11:17:03 -0700

> As a practical matter, what do you think the effect of the "MUST" in the

That vendors cannot provide bare TCP as a transport in a system that contains no other security mechanisms. 

> other forms of trusted security at or below TCP

That seems like a good addition.

--Paul Hoffman

---

From: Randy Bush <[email-masked]>
Date: Wed, 03 Aug 2011 03:37:37 +0900

> Greetings again. Section 7 of draft-ietf-sidr-rpki-rtr-14 has a list
> of supported transports. However, it does not list the one that some
> people have said that they expect it to be run under sometimes, namely
> bare TCP.

huh?  i see the following:

   Caches and routers MUST implement unprotected transport over TCP
   using a port, RPKI-Rtr, to be assigned, see Section 12.  Operators
   SHOULD use procedural means, ACLs, ... to reduce the exposure to
   authentication issues.

> I propose the following for the end of section 7, just before 7.1:
> 

we actually can't.  to rehash (null algroithm) the discussion

  o AO, which may come for some routers late this year or the first half
    of next year, does not exist for servers.  as the market for AO in
    servers is miniscule, i am not optimistic.  side note: for example a
    number of very large operators use only solaris.

  o MD5, does not exist for many server platforms, or is half-assed.

  o SSH, fine on servers, but many router platforms do not have SSH
    APIs.  they just have client code burned into the CLI.

  o TLS, fine on servers, but many router platforms do not have SSH
    APIs.  they just have client code burned in.

> being honest in the document might be better than pretending
> otherwise.

exactly!

randy

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 12:00:14 -0700

>   SHOULD use procedural means, ACLs, ... to reduce the exposure to

Arrgh. My bad. (I read the intro, I read TCP-AO, and I skipped to the end of the list.)

Never mind, what I want is already there.

--Paul Hoffman

---

From: Randy Bush <[email-masked]>
Date: Wed, 03 Aug 2011 04:05:35 +0900

> Arrgh. My bad. (I read the intro, I read TCP-AO, and I skipped to the

it is a carefully constructed yet painful compromise with reality.

> Never mind, what I want is already there.

do i get a refund?  :)

randy