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

[Christopher Morrow <[e-mail]>]

On Mon, May 16, 2011 at 3:25 PM, t.petch <[e-mail]> wrote:
> 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

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

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

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?

>
> Just my 0.02£
>
> Tom Petch
>
> ----- Original Message -----
> From: "Christopher Morrow" <[e-mail]>
> To: "Joe Touch" <[e-mail]>
> Cc: "t.petch" <[e-mail]>; "sidr wg list" <[e-mail]>
> Sent: Monday, May 16, 2011 8:25 PM
> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
>
>
> 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 <[e-mail]> wrote:
>>
>>
>> On 4/28/2011 6:27 AM, t.petch wrote:
>>>
>>> ----- Original Message -----
>>> From: "Joe Touch"<[e-mail]>
>>> To: "t.petch"<[e-mail]>
>>> Cc: "Christopher Morrow"<[e-mail]>; "sidr wg list"
>>> <[e-mail]>
>>> 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
>>
>>
>
>