Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

From: Christopher Morrow <[email-masked]>
Date: Mon, 16 May 2011 14:25:53 -0400

So.. this spun along for a time, the last real bit of controversy was
"to AO or not to AO"... The author(s) I think are off looking at
alternate options. For now we'll withdraw this WGLC and start another
once the authors have updates to report.

thanks though folks!
-Chris

On Thu, Apr 28, 2011 at 1:31 PM, Joe Touch <[email-masked]> wrote:
>
>
> On 4/28/2011 6:27 AM, t.petch wrote:
>>
>> ----- Original Message -----
>> From: "Joe Touch"<[email-masked]>
>> To: "t.petch"<[email-masked]>
>> Cc: "Christopher Morrow"<[email-masked]>; "sidr wg list"
>> <[email-masked]>
>> Sent: Monday, April 25, 2011 5:26 PM
>>
>>> Hi, Tom,
>>>
>>> On 4/25/2011 1:47 AM, t.petch wrote:
>>> ....
>>>>
>>>> I think that the point is not that it is or is not a BGP connection
>>>> but that security for BGP was predicated on the assumption that
>>>> the TCP connection would be short in terms of hops, ie none,
>>>> and it was that that made a less stringent approach to security
>>>> acceptable, one that would not be acceptable for an Internet
>>>> wide access for - say - a Web site.
>>>
>>> Hopcount security, i.e., GTSM (RFC 3682) is not at all related to TCP-AO.
>>
>> Understood; I was thinking of RFC4278 which calls out the unusual nature
>> of
>> BGP sessions and the impact on security requirements.
>
> That document explains why TCP MD5 was considered appropriate for BGP, given
> the variance in the maturity level of the standards of the two docs.
>
> TCP-AO has no such assertions or qualifications. It is a general purpose
> mechanism that includes some properties useful for BGP, but that are also
> very relevant to exchanges between clients and caches as well.
>
>> I am familiar with TCP-AO from the TCPM list, but am not enough of a
>> cryptanalyst to know whether or not it is appropriate for rpki-rtr.
>>
>> By contrast, I have seen SSH and TLS discussed much more extensively
>> on their lists and have been part of the pain of adding them to syslog and
>> SNMP.
>>
>> And I do not know where these rpki-rtr sessions will go to and from but
>> suspect that they will not be BGP-like.
>
> BGP-like presumably means:
>        - long lived
>        - between known endpoints
>        - over short IP hops
>
> Of these, only "long lived" had any impact on the TCP-AO design.
>
> Of these, any can be relevant to rpki-rtr sessions, from the traffic I've
> seen on this list.
>
> Keying is another relevant issue; configuration of SSH and TLS for
> pre-shared keys is different than for TCP MD5 (and TCP-AO, which uses
> similar master keys), and not the typical case.
>
> My point is that TCP-AO wasn't designed for BGP; it was designed as a
> general purpose mechanism.
>
> Joe
>
>

---

From: "t.petch" <[email-masked]>
Date: Mon, 16 May 2011 21:25:38 +0200

Chris

Stepping back from the immediate technical question, I would be surprised
if the Security ADs would accept the Security Considerations in 2011.

I lack the knowledge of where these sessions will be from and too,
and see no guidance in any of the other I0Ds, but
suspect that they will span the Internet, ie totally different to an IDR
session.
And that suggests that anyone anywhere can attack them, so I would expect
to see a threat analysis and counters thereto.

Just my 0.02£

Tom Petch

----- Original Message -----
From: "Christopher Morrow" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "sidr wg list" <[email-masked]>
Sent: Monday, May 16, 2011 8:25 PM
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

thanks though folks!
-Chris

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 16 May 2011 20:03:42 -0400

> and see no guidance in any of the other I0Ds, but

I think the idea is that a router gets it's cache data from inside the
local ASN, there may be cases where an operator decides to use an
extra-AS cache, but that seems less than ideal (bootstrapping issues,
business issues, etc).

> to see a threat analysis and counters thereto.

interesting, Randy does this seem like something that you were
thinking of as well? or since the intent is to do this sort of thing
inside a single ASN (or single administrative domain) is this
something that's less critical?

---

From: Randy Bush <[email-masked]>
Date: Wed, 18 May 2011 07:10:51 +0200

>> suspect that they will span the Internet, ie totally different to an
>> IDR session.  And that suggests that anyone anywhere can attack them,
>> so I would expect to see a threat analysis and counters thereto.

the recommendations in draft-ietf-sidr-origin-ops would seem to be
useful here.  for example

   As RPKI-based origin validation relies on the availability of RPKI
   data, operators SHOULD locate caches close to routers that require
   these data and services.  A router can peer with one or more nearby
   caches.

randy