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

["t.petch" <[e-mail]>]

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

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.

Tom Petch


> TCP-AO provides replay protection, includes extended sequence numbers to
> account for seqno rollover, and support for changing keys during a
> connection without impact to TCP. It also uses per-connection keys
> derived from master keys.
>
> > What I am missing is not whether or not this is BGP, but
> > whether or not the connection will have the properties of
> > BGP, of being very short.   My suspicion is that the
> > data will be coming from all over the place, Internet-wide
> > (as with CRL) and so the security should be Web-like and not
> > BGP-like; ie TCP-AO will not do.
>
> I encourage you to take another look at TCP-AO; there is nothing therein
> that is focused exclusively on any property of BGP. It was intended as a
> generic mechanism to support transport authentication for TCP connections.
>
> Joe