Subject: [sidr] discussion about mandatory-to-implement connection security (was WGLC draft-sidr-rpki-rtr - take 2?)

From: Joe Touch <[email-masked]>
Date: Wed, 20 Apr 2011 13:29:14 -0700

Hi, all,

I've reviewed the discussion about mandatory-to-implement connection 
security that dates back to Morrow's post of 1 Apr:
http://www.ietf.org/mail-archive/web/sidr/current/msg02623.html

I'd like to note a few things:

1) ssh does not protect the transport connection
ssh is an application protocol, not a transport protocol

It provides privacy and authentication at the application layer, of the 
data over the TCP connection, but that connection can be interrupted by 
an attacker. This may not have the same impact as for vanilla BGP (where 
the connection disappearing causes routes to be removed), but should be 
a consideration in a "mandatory to implement" component, IMO.

2) TCP-AO was designed for BGP
TCP-AO was designed to get around concerns with the use of IPsec for BGP 
protection, and to correct for weaknesses in TCP MD5.

Any platform that is intended to use BGP in a protected way will need to 
implement TCP-AO anyway. Using that mechanism to protect other parts of 
BGP seems appropriate.

3) TCP-AO obsoletes TCP MD5
We did not deprecate TCP MD5 for legacy reasons only. It should not be 
recommended in any new cases.

4) a SIDR solution assuming TCP-AO isn't available on servers is an 
interim only

RFCs ought not focus on short term solutions, especially ones that are 
so easily corrected.

If the issue is the lack of a TCP-AO implementation in Linux and 
FreeBSD, it would be more productive to find the resources (6 man-months 
approx.) to just write this than even to discuss it on this list at 
length further.

If you do insist on including other alternatives, I would strongly 
suggest listing only IPsec; if you do include ssh (or, AFAICT, if you 
really want to get to servers, why not tls? surely servers are as likely 
if not more so to have HTTPS support) then you should note the lack of 
protection to the transport layer, and any implications that result.

Joe

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 24 Apr 2011 01:17:34 -0400

first, thanks! :)

On Wed, Apr 20, 2011 at 4:29 PM, Joe Touch <[email-masked]> wrote:
> It provides privacy and authentication at the application layer, of the data
> over the TCP connection, but that connection can be interrupted by an
> attacker. This may not have the same impact as for vanilla BGP (where the
> connection disappearing causes routes to be removed), but should be a
> consideration in a "mandatory to implement" component, IMO.
>
> implement TCP-AO anyway. Using that mechanism to protect other parts of BGP
> seems appropriate.
>
> 4) a SIDR solution assuming TCP-AO isn't available on servers is an interim
> only
>
> RFCs ought not focus on short term solutions, especially ones that are so
> easily corrected.
>
> If the issue is the lack of a TCP-AO implementation in Linux and FreeBSD, it
> would be more productive to find the resources (6 man-months approx.) to
> just write this than even to discuss it on this list at length further.

I don't think we've got folks yet volunteering to do this... though
it'd be nice :)

> If you do insist on including other alternatives, I would strongly suggest
> listing only IPsec; if you do include ssh (or, AFAICT, if you really want to
> get to servers, why not tls? surely servers are as likely if not more so to
> have HTTPS support) then you should note the lack of protection to the
> transport layer, and any implications that result.

it's not clear to me that https client support exists in routers,
there are also some issues with cert validation to think about (I
think, though maybe that's a simple problem where the cert only
validates up a chain for your as-level-cert? no other CA's
accepted...).

In any case, this should provide some thoughts to crunch on as well...
Can we spiral into an answer soon folks?

-Chris

>
> Joe
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Randy Bush <[email-masked]>
Date: Sun, 24 Apr 2011 14:47:47 +0900

> validates up a chain for your as-level-cert? no other CA's

wrong trust relationship.  e.g. i don't think you want the upstream to
issue a router cert to a downstream who wants to use upstream's server.

the way i figure it is that the docco can stay as it is regarding
transport, and we can use cleartext or ssh while running a betting pool
on which is slower, AO code in routers and servers or endless ietf
discussions.  we have running code, no other doc depends on this one, so
ietf process can remain a source of amusement.

a couple of changes are actually in a yet-to-be-published rev

  o 5.5 the router is no longer expected to keep a ref count

      The cache server is responsible for assuring that it has told the
      router client to have one and only one IPvX PDU for a unique
      {prefix, len, max-len, asn} at any one point in time.  Should the
      router client receive an IPvX PDU with a {prefix, len, max-len,
      asn} identical to one it already has active, it SHOULD raise a
      Duplicate Announcement Received error.

  o Brian Weis's comment on BGPsec also has some relevance here.  so i
    added a bit to sec 4

      As a cache server must evaluate certificates and ROAs which are
      time dependent, servers' clocks MUST be correct to a tolerance of
      approximately an hour.

    or maybe there is some nice text elsewhere which covers this?

randy

---

From: "Borchert, Oliver" <[email-masked]>
Date: Mon, 25 Apr 2011 11:29:56 -0400

>       Duplicate Announcement Received error.

Randy,
Do I understand you correctly that you move away from your position that the prefix cache sends a 1:1 image to the server as you mentioned in an earlier post?

Therefore with the given ROAs (below):
 ROA1(p1 maxlen m1 valid from t0-t5) and
 ROA2(p1 maxlen m1 valid from t3-t9) 

Can I expect the following behavior?

The router will receive only one Whitelist announcement for (p1 m1) at or shortly after t0 followed by one Whitelist withdrawal for (p1 m1) at or shortly after t9?

Also the router will not see anything that indicates a change in ROAs (ROA1 - ROA2) where the content is the same. Therefore from the routers point of view only one ROA was existent during the time from t0-t9.

When do you plan to publish this change?

Oliver

----------------------------------------------------------------------------
Oliver Borchert - Computer Scientist
National Institute of Standards and Technology
United States Department of Commerce
phone: 301-975-4856, fax: 301-975-6238

---

From: "Borchert, Oliver" <[email-masked]>
Date: Mon, 25 Apr 2011 18:08:40 -0400

> 
> > Do I understand you correctly that you move away from your position
> > that the prefix cache sends a 1:1 image to the server as you mentioned
> > in an earlier post?
> 
> s/move away/was shoved/  :)
> 

This simplifies the implementation on the routers side. I like that ;-)

> > The router will receive only one Whitelist announcement for (p1 m1) at
> > or shortly after t0 followed by one Whitelist withdrawal for (p1 m1)
> > at or shortly after t9?
> >
> > Also the router will not see anything that indicates a change in ROAs
> > (ROA1 - ROA2) where the content is the same. Therefore from the
> > routers point of view only one ROA was existent during the time from
> > t0-t9.
> 
> yes, presuming t0 <= t3 <= t5 <= t9

Yes 

> and presuming the as-num is the same in both

Yes

> and presuming the prefix length is the same in both

and yes

> i could do it any time.  i guess i should.  lemme finish some big makes
> first

Sounds great

Oliver

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 06:58:49 +0900

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Apr 2011 07:12:53 +0900

>>> that the prefix cache sends a 1:1 image to the server as you
>>> mentioned in an earlier post?
> This simplifies the implementation on the routers side. 

and you can guess who shoved.  though, actually, i got it from both
sides, routers and server.  running code is a strong incentive.

randy

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Apr 2011 15:36:29 -0700

Hi, all,

On 4/23/2011 10:17 PM, Christopher Morrow wrote:
...
> I don't think we've got folks yet volunteering to do this... though

FWIW, I'm working on arranging this now.

> validates up a chain for your as-level-cert? no other CA's

This brings up a useful question - what is the security model? CAs, 
self-signed certs, or just preshared keys?

The latter is very easy to support in TCP MD5 and will be similarly 
simple in TCP-AO, but doesn't seem to be the common mode for SSH (you'd 
need preshared keys without passwords, and that's not as commonly used, 
AFAICT).

Joe