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

From: Randy Bush <[email-masked]>
Date: Fri, 01 Apr 2011 13:22:26 +0200

i propose that i rev the doc to say
  o the transport must provide authentication and integrity
  o the current ssh description is an example
  o other transport meeting the authentication and integrity constraints
    are welcome

of course, this will leave open the mandatory-to-implement LCD issue.
sigh.

randy

---

From: Jared Mauch <[email-masked]>
Date: Fri, 1 Apr 2011 07:41:28 -0400

>  o other transport meeting the authentication and integrity constraints

This sounds acceptable to me.

- Jared

---

From: John Scudder <[email-masked]>
Date: Fri, 1 Apr 2011 06:32:48 -0700

> of course, this will leave open the mandatory-to-implement LCD issue.

I think we shouldn't punt on a mandatory transport.  I suggest TCP-MD5 for practical reasons, including the open source support issue Chris raised.

--John

---

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 1 Apr 2011 22:17:44 +0200

Hi John,

On Fri, 1 Apr 2011, John Scudder wrote:

> I think we shouldn't punt on a mandatory transport.  I suggest TCP-MD5 
> for practical reasons, including the open source support issue Chris 
> raised.
> 
  I'm confused: Do you suggest TCP-MD5 as optional or mandatory?

  Defining TCP-MD5 as mandatory seems a bit risky as it is obsoleted by 
AO. I'm not sure how the IESG would react on this. On the other hand, if 
there are no real implementations for RFC5925 it seems useless for RTR, 
as well. Thus, I would stick to SSH (or something else that is 
well-deployed and not obsoleted).

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 1 Apr 2011 23:05:07 +0200

On Fri, Apr 01, 2011 at 10:17:44PM +0200, Matthias Waehlisch wrote:
| Hi John,
| 
| On Fri, 1 Apr 2011, John Scudder wrote:
| 
| > > i propose that i rev the doc to say
| > >  o the transport must provide authentication and integrity
| > >  o the current ssh description is an example
| > >  o other transport meeting the authentication and integrity constraints
| > >    are welcome
| > > 
| > > of course, this will leave open the mandatory-to-implement LCD issue.
| > > sigh.
| > 
| > I think we shouldn't punt on a mandatory transport.  I suggest TCP-MD5 
| > for practical reasons, including the open source support issue Chris 
| > raised.
| > 
|   I'm confused: Do you suggest TCP-MD5 as optional or mandatory?
| 
|   Defining TCP-MD5 as mandatory seems a bit risky as it is obsoleted by 
| AO. I'm not sure how the IESG would react on this. On the other hand, if 
| there are no real implementations for RFC5925 it seems useless for RTR, 
| as well. Thus, I would stick to SSH (or something else that is 
| well-deployed and not obsoleted).

the practical problem i have with SSH is that it is pretty hard to
integrate into to the async/non-blocking I/O APIs that we work with typically.
  openssh is select() based which does not scale terribly well if you have
  e.g. a couple of 100ssessions open (like it happens when doing BGP on RRs).

  modern, scalable I/O stacks in router OSes are exclusively based on Kqueue or Epoll.
  for your reference libevent has some nice description for this:
    see http://monkey.org/~provos/libevent/

so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention that i
am no security guy ;-)), since those are the standard tools to protect message
integrity of the BGP session itself - its already onboard and does not cause much
userspace / userspace transport weirdness since both for linux and BSD its
implemented in the kernel.

/hannes

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 1 Apr 2011 23:21:03 +0200

>  e.g. a couple of 100ssessions open (like it happens when doing BGP on RRs).

So, if the configured limit of cache's was 5 would that make your
arguement change in any way? (5 as an example)

---

From: Hannes Gredler <[email-masked]>
Date: Sat, 2 Apr 2011 01:39:45 +0200

On Fri, Apr 01, 2011 at 11:21:03PM +0200, Christopher Morrow wrote:
| On Fri, Apr 1, 2011 at 11:05 PM, Hannes Gredler <[email-masked]> wrote:
| > On Fri, Apr 01, 2011 at 10:17:44PM +0200, Matthias Waehlisch wrote:
| > | Hi John,
| > |
| > | On Fri, 1 Apr 2011, John Scudder wrote:
| > |
| > | > > i propose that i rev the doc to say
| > | > >  o the transport must provide authentication and integrity
| > | > >  o the current ssh description is an example
| > | > >  o other transport meeting the authentication and integrity constraints
| > | > >    are welcome
| > | > >
| > | > > of course, this will leave open the mandatory-to-implement LCD issue.
| > | > > sigh.
| > | >
| > | > I think we shouldn't punt on a mandatory transport.  I suggest TCP-MD5
| > | > for practical reasons, including the open source support issue Chris
| > | > raised.
| > | >
| > |   I'm confused: Do you suggest TCP-MD5 as optional or mandatory?
| > |
| > |   Defining TCP-MD5 as mandatory seems a bit risky as it is obsoleted by
| > | AO. I'm not sure how the IESG would react on this. On the other hand, if
| > | there are no real implementations for RFC5925 it seems useless for RTR,
| > | as well. Thus, I would stick to SSH (or something else that is
| > | well-deployed and not obsoleted).
| >
| > the practical problem i have with SSH is that it is pretty hard to
| > integrate into to the async/non-blocking I/O APIs that we work with typically.
| >  openssh is select() based which does not scale terribly well if you have
| >  e.g. a couple of 100ssessions open (like it happens when doing BGP on RRs).
| 
| So, if the configured limit of cache's was 5 would that make your
| arguement change in any way? (5 as an example)

no, as all my other "userspace" apps using TCP (in our case BGP, LDP, MSDP and rpki-cache)
are all using Kqueue which makes it very simple to come up with an implementation
which scale nicely under load; mixing select() with Kqueue in a daemon that has
potentially 1000s of sessions would blow FD_SET to 16384, requires changing the main
eventloop etc., all non-trivial changes.

i mean why should i take a step backward to a select() based model just to get encryption
which i do not need. - don't get me wrong SSH is great for a variety of purposes, but its
certainly not the best toolkit to build a scalable transport between a client and a server.

another alternative is to move the rpki-cache protocol into a sep. userspace daemon,
then you are right, there is no need to be worried about the select()ism of the openssh lib,
however then the performance for validating a BGP stream gets a hit by all the
IPC overhead between the daemons. i remember from one of the early discussions with
randy that he's very cautious about the validation overhead.

| >  modern, scalable I/O stacks in router OSes are exclusively based on Kqueue or Epoll.
| >  for your reference libevent has some nice description for this:
| >    see http://monkey.org/~provos/libevent/
| >
| > so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention that i
| > am no security guy ;-)), since those are the standard tools to protect message
| > integrity of the BGP session itself - its already onboard and does not cause much
| > userspace / userspace transport weirdness since both for linux and BSD its
| > implemented in the kernel.
| >
| > /hannes
| >

---

From: Stephen Kent <[email-masked]>
Date: Sat, 2 Apr 2011 04:54:50 -0400

At 6:32 AM -0700 4/1/11, John Scudder wrote:
>I think we shouldn't punt on a mandatory transport.  I suggest 
>TCP-MD5 for practical reasons, including the open source support 
>issue Chris raised.
>
>--John

I expect TCP-MD5 to be deprecated (soon?), since we have already 
deprecated MD5. I don't think the IESG would approve of a reference 
to that RFC.

Steve

---

From: John Scudder <[email-masked]>
Date: Sat, 2 Apr 2011 02:12:47 -0700

On Apr 2, 2011, at 10:54 AM, Stephen Kent wrote:
> I expect TCP-MD5 to be deprecated (soon?), since we have already deprecated MD5. I don't think the IESG would approve of a reference to that RFC.

Well it was worth a try.

I think the next-best option is TCP-AO.

--John

---

From: Matthias Waehlisch <[email-masked]>
Date: Sat, 2 Apr 2011 11:22:18 +0200

Hi Hannes,

On Fri, 1 Apr 2011, Hannes Gredler wrote:

> so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention 
> that i am no security guy ;-)), since those are the standard tools to 
> protect message integrity of the BGP session itself - its already 
> onboard and does not cause much userspace / userspace transport 
> weirdness since both for linux and BSD its implemented in the kernel.
> 
  could you give a reference to both, Linux and BSD, TCP-AO 
implementations?

Thanks
  matthias

---

From: John Scudder <[email-masked]>
Date: Sat, 2 Apr 2011 02:31:45 -0700

>  could you give a reference to both, Linux and BSD, TCP-AO 

I can't (possibly due only to my own ignorance) but I'll observe that since as both you and Steven Kent have observed TCP-MD5 is being deprecated, both Linux and BSD will need to add TCP-AO anyway.  

--John

---

From: Randy Bush <[email-masked]>
Date: Sat, 02 Apr 2011 17:33:59 -0700

> deprecated MD5. I don't think the IESG would approve of a reference 

as opposed to second guessing the iesg, prehaps asking if mmd5+hmac
would be reasonable as mandatory to implement.

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Apr 2011 06:38:26 -0700

> I think the next-best option is TCP-AO.

this suffers from a lack of implementations on server platforms

randy

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 3 Apr 2011 17:45:43 +0200

> this suffers from a lack of implementations on server platforms

so ... if we need this on server platforms what's the 'cost' (free
since they are both free-unixes! <joking of course>) people-wise? I
think I hear ~6mon for the linux side, though I'm teasing out the
details a bit still.

-Chris

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 4 Apr 2011 10:32:38 +0200

On Sat, Apr 02, 2011 at 11:22:18AM +0200, Matthias Waehlisch wrote:
| Hi Hannes,
| 
| On Fri, 1 Apr 2011, Hannes Gredler wrote:
| 
| > so i'd be much more in favour of TCP-AO or even TCP-MD5 (did i mention 
| > that i am no security guy ;-)), since those are the standard tools to 
| > protect message integrity of the BGP session itself - its already 
| > onboard and does not cause much userspace / userspace transport 
| > weirdness since both for linux and BSD its implemented in the kernel.
| > 
|   could you give a reference to both, Linux and BSD, TCP-AO 
| implementations?

to my knowledge there are none up to date, however it has to be done at
some point as TCP-MD5 for securing the base BGP session seems to
be too weak as well.

so my question is: "why do we need to solve the same problem
(= protecting message integrity) 2 times in different ways" ?

/hannes

---

From: Danny McPherson <[email-masked]>
Date: Mon, 4 Apr 2011 08:22:42 -0400

> (= protecting message integrity) 2 times in different ways" ?

This new machinery simply introduces object-level integrity functions 
in the application (i.e., BGP), it does nothing to ameliorate attacks 
at lower layers - all those substrate attack vectors (e.g., transport 
connection resets, injection or replay attacks) still exist and 
require controls as well -- else things might break in even uglier ways 
at higher layers.

Viva la layered security, 

-danny

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 4 Apr 2011 14:50:16 +0200

On Mon, Apr 04, 2011 at 08:22:42AM -0400, Danny McPherson wrote:
| 
| On Apr 4, 2011, at 4:32 AM, Hannes Gredler wrote:
| 
| > 
| > so my question is: "why do we need to solve the same problem
| > (= protecting message integrity) 2 times in different ways" ?
| 
| This new machinery simply introduces object-level integrity functions 
| in the application (i.e., BGP), it does nothing to ameliorate attacks 
| at lower layers - all those substrate attack vectors (e.g., transport 
| connection resets, injection or replay attacks) still exist and 
| require controls as well -- else things might break in even uglier ways 
| at higher layers.

still that does not answer my question: why do we need to solve the problem
of transport integrity twice (or to play devils advocate:
shall we encapsulate BGP into SSH up until something better than MD5
is available ;-))

/hannes

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 4 Apr 2011 09:18:17 -0400

> shall we encapsulate BGP into SSH up until something better than MD5

some folks (not me) suggest that ipsec is the way to go here... (bgp I mean)
I think one point to keep in mind is that tcp-ao has exactly zero
implementations... while SSH implementations abound.

-chris

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Apr 2011 08:18:23 -0700

> some folks (not me) suggest that ipsec is the way to go here... (bgp I
> mean) I think one point to keep in mind is that tcp-ao has exactly
> zero implementations... while SSH implementations abound.

turns out that

  o yfv may have ssh client and server, but they do not have the library
    in a form usable by arbitrary apps, e.g. bgp

  o no ao impls on unix, slowlaris, linuxes, ...

so i would really love to hear from the security folk if we can do
something like hmac-md5 as the mandatory to implement.

randy

---

From: Brian Weis <[email-masked]>
Date: Wed, 6 Apr 2011 17:44:50 -0700

> something like hmac-md5 as the mandatory to implement.

Getting a new application (such as the rtr protocol) specifying hmac-md5 mandatory to implement through a Secdir review and then the Security ADs just won't happen. The only exception I can think of is if there were no possible alternatives, and that's obviously not the case here.

Brian

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Apr 2011 17:46:48 -0700

> Getting a new application (such as the rtr protocol) specifying
> hmac-md5 mandatory to implement through a Secdir review and then the
> Security ADs just won't happen. The only exception I can think of is
> if there were no possible alternatives, and that's obviously not the
> case here.

with AO not implemented on any servers, routers not having ssh
libraries, and this being a server to router protocol, what are the
alternatives?

randy

---

From: Brian Weis <[email-masked]>
Date: Wed, 6 Apr 2011 21:30:03 -0700

> libraries, and this being a server to router protocol, what are the

I'm surprised IPsec hasn't been mentioned in this thread ... was it previously discussed and rejected? Correct me if I'm wrong, but I believe it's common for BGP routers to support IPsec and servers definitely support IPsec. On the router side, one or two IPsec sessions to servers should not be a burden. I'm less sure of the server IPsec scaling properties, but I would expect a LINUX or BSD kernel to have the scaling issues as were discussed earlier in this thread regarding SSH but I'm no expert here.

Brian

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Apr 2011 12:28:13 -0400

On Thu, Apr 7, 2011 at 12:30 AM, Brian Weis <[email-masked]> wrote:
> I'm surprised IPsec hasn't been mentioned in this thread ... was it previously

see msgid: Message-ID: <BANLkTi=eZ=[email-masked]>
(5-6 messages back in this thread, from me)

> discussed and rejected? Correct me if I'm wrong, but I believe it's common for
> BGP routers to support IPsec and servers definitely support IPsec. On the

it's not a guarantee that all bgp speakers here will have ipsec
capable code... for some long time at least one vendor in their 'ISP'
code didn't implement ipsec, or ssh for that matter. IPSEC is pretty
heavy weight (from a config perspective) for this. Something like AO
or MD5 is 'perfect', SSH as proposed does  a fine job as well, though
has a bugaboo on at least one platform apparently.

> router side, one or two IPsec sessions to servers should not be a burden. I'm
> less sure of the server IPsec scaling properties, but I would expect a LINUX
> or BSD kernel to have the scaling issues as were discussed earlier in this
> thread regarding SSH but I'm no expert here.

lots of at-scale vpn systems are nothing but crypto-accelerators +
linux/bsd underneath... I think there's an aversion to ipsec on
routers (complexity and unused codepaths), ssh is 'used all the time'
as is tcp-md5, as will (soon?) tcp-AO.

What is a reasonable way forward for now, MUST md5 and later when AO
is more ubiquitous hammer through an update to the draft? Keeping a
MAY for ssh transport?

(in the vein of moving this forward since running code exists for both
sides of this equation today)

-chris

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Apr 2011 09:41:15 -0700

> SSH as proposed does a fine job as well, though has a bugaboo on at
> least one platform apparently.

two major platforms

> is more ubiquitous hammer through an update to the draft? Keeping a

do servers support md5/tcp?  i honestly do not know other than freebsd.

randy

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 7 Apr 2011 19:05:20 +0200

On Thu, Apr 07, 2011 at 09:41:15AM -0700, Randy Bush wrote:
| > SSH as proposed does a fine job as well, though has a bugaboo on at
| > least one platform apparently.
| 
| two major platforms
| 
| > What is a reasonable way forward for now, MUST md5 and later when AO
| > is more ubiquitous hammer through an update to the draft? Keeping a
| > MAY for ssh transport?
| 
| do servers support md5/tcp?  i honestly do not know other than freebsd.

support for this has been added somewhere around 2.6.27 ...

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cfb6eeb4c860592edd123fdea908d23c6ad1c7dc

/hannes

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Apr 2011 10:08:10 -0700

> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cfb6eeb4c860592edd123fdea908d23c6ad1c7dc

looks like penguin stuff.  what about unixes?  solaris?

randy

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 7 Apr 2011 11:16:43 -0600

Sharing: Author's permission required.
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Bush
> Sent: Thursday, April 07, 2011 10:41 AM
> To: Christopher Morrow
> Cc: sidr wg list
> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
>
Depends on what they are using for BGP but given that most will use Quagga since it supports md5 you should be able to get md5 support in most server OSes.

> randy

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 7 Apr 2011 19:29:27 +0200

On Thu, Apr 07, 2011 at 10:08:10AM -0700, Randy Bush wrote:
| >> do servers support md5/tcp?  i honestly do not know other than freebsd.
| > support for this has been added somewhere around 2.6.27 ...
| > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
| 
| looks like penguin stuff.  what about unixes?  solaris?

no idea;

---

From: Brian Weis <[email-masked]>
Date: Thu, 7 Apr 2011 15:31:23 -0700

> has a bugaboo on at least one platform apparently.

I agree AO would be a great choice, but you'd probably want to wait for implementations. Maybe mandating it would spur the implementations. :-)

> is more ubiquitous hammer through an update to the draft? Keeping a

Possibly the use of md5 would be more palatable to the security area if the protocol were Experimental rather than Standards-Track.  If the authors and chairs would be willing to make that change, it would be worth asking the Security ADs what they think. Then revision it to be standards track later when AO can be mandated.

Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Apr 2011 15:44:21 -0700

> Possibly the use of md5 would be more palatable to the security area
> if the protocol were Experimental rather than Standards-Track.  If the
> authors and chairs would be willing to make that change

not a chance in hell.  the vendors went out on a limb.  operators same.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Apr 2011 21:40:25 -0400

> not a chance in hell.  the vendors went out on a limb.  operators same.

yea, so ... without my co-chair-special-garments on I'm not sure
experimental heads us in the direction of ubiquitous secure
interdomain routing.

We seem to be in a bit of a jam :( I don't think SIDR is going to be
able to, by declaration, get opensource implementations of AO to
appear. I don't see non-open-source implementations on the server side
for tcp-md5 sadly either, but at least fbsd/obsd/linux have tcp-md5
support.

-chris

---

From: Pradosh Mohapatra <[email-masked]>
Date: Thu, 7 Apr 2011 21:20:05 -0700

> for tcp-md5 sadly either, but at least fbsd/obsd/linux have tcp-md5

We don't seem to be converging. I would suggest that we keep the status quo
and make ssh mandatory to implement. Other mechanisms may get prescribed
in future as & when they become commonly available.

- Pradosh

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 8 Apr 2011 00:38:20 -0400

> in future as & when they become commonly available.

sounds ok to me.

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 8 Apr 2011 19:04:00 +0200

On Thu, Apr 07, 2011 at 09:20:05PM -0700, Pradosh Mohapatra wrote:
| > We seem to be in a bit of a jam :( I don't think SIDR is going to be
| > able to, by declaration, get opensource implementations of AO to
| > appear. I don't see non-open-source implementations on the server side
| > for tcp-md5 sadly either, but at least fbsd/obsd/linux have tcp-md5
| > support.
| 
| We don't seem to be converging. I would suggest that we keep the status quo
| and make ssh mandatory to implement. Other mechanisms may get prescribed
| in future as & when they become commonly available.

not sure if mandating a single transport is needed at all.

since the pros and cons of the various transport protocols
(TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply
enumerating the choices and leave it to the operator's local security policy
which one to deploy ?

IMO you cannot dictate local security policy as they are different between
operators. also if the level of containment is sufficiently enough (e.g.
local-cache only reachable through vrf, not accessible through internet
it is perfectly reasonable even to load your cache records using vanilla TCP.)

---

From: Pradosh Mohapatra <[email-masked]>
Date: Fri, 8 Apr 2011 10:49:40 -0700

> it is perfectly reasonable even to load your cache records using vanilla TCP.)

I have no problem listing various transports. I thought there was a suggestion to
keep one of them mandatory to encourage better interoperability. That makes
some sense.

- Pradosh

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 8 Apr 2011 13:55:04 -0400

> keep one of them mandatory to encourage better interoperability. That makes

I believe, and Randy/authors can jump in here, the point of a MUST was
to ensure we had one (at least) transport across all parts of the
system. (interoperability, yes).

How about authors/hannes/pradosh work out their best guess and we go
from there? say by monday? :)

-Chris

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 8 Apr 2011 14:00:35 -0400 (Eastern Daylight Time)

> enumerating the choices and leave it to the operator's local security policy

Leaving it up to operator choice still leaves the question of what will be 
implemented.  If we don't have a mandatory to implement protocol, can we 
be sure that an operator will have interoperating implementations wrt 
secure transport protocols from which to choose?

--Sandy, as member only

---

From: Randy Bush <[email-masked]>
Date: Fri, 08 Apr 2011 11:01:12 -0700

> since the pros and cons of the various transport protocols (TCP,
> TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply
> enumerating the choices and leave it to the operator's local security
> policy which one to deploy ?

guaranteed inter-op would be nice.  would prefer not to have "you can
run server A with router X but not with router Y.  Y needs server B.  so
you need to fully deploy two classes of servers."

randy

---

From: Geoff Huston <[email-masked]>
Date: Sun, 10 Apr 2011 01:23:19 +1000

> in future as & when they become commonly available.

this sounds sensible to me

   Geoff

---

From: Geoff Huston <[email-masked]>
Date: Sun, 10 Apr 2011 01:29:21 +1000

> keep one of them mandatory to encourage better interoperability. That makes

Frankly the interoperability argument is a very strong one for me. Yes, at every
step and with every component of this design we could enumerate a laundry list
of possible technologies, but, frankly, it seems like a less than useful exercise
of constructing complexity and threatening interoperability of the resultant
system. If the intention is to produce robust specifications that allow cleanly
interoperable implementations then it makes sense for me to produce a 
specification that makes specific selections from the choice set.

 Geoff

---

From: Hannes Gredler <[email-masked]>
Date: Sat, 9 Apr 2011 22:43:34 +0200

On Sun, Apr 10, 2011 at 01:29:21AM +1000, Geoff Huston wrote:
| 
| On 09/04/2011, at 3:49 AM, Pradosh Mohapatra wrote:
| 
| >> not sure if mandating a single transport is needed at all.
| >> 
| >> since the pros and cons of the various transport protocols
| >> (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply
| >> enumerating the choices and leave it to the operator's local security policy
| >> which one to deploy ?
| >> 
| >> IMO you cannot dictate local security policy as they are different between
| >> operators. also if the level of containment is sufficiently enough (e.g.
| >> local-cache only reachable through vrf, not accessible through internet
| >> it is perfectly reasonable even to load your cache records using vanilla TCP.)
| > 
| > I have no problem listing various transports. I thought there was a suggestion to
| > keep one of them mandatory to encourage better interoperability. That makes
| > some sense.
| 
| Frankly the interoperability argument is a very strong one for me. Yes, at every
| step and with every component of this design we could enumerate a laundry list
| of possible technologies, but, frankly, it seems like a less than useful exercise
| of constructing complexity and threatening interoperability of the resultant
| system. If the intention is to produce robust specifications that allow cleanly
| interoperable implementations then it makes sense for me to produce a 
| specification that makes specific selections from the choice set.

the question is *what* is that we try to standardize ? - is it

1. the application level communication protocol between caches and routers
2. the application level communication protocol between caches and routers
   and the transport ?

i do not really buy the interop argument as early interop testing
has showed that there are already several transports available to carry
the rtr-cache protocol (BTW including vanilla TCP.) furthermore how should
one read the spec ? - is a rtr-cache protocol implementation doing IPSEC
*not* compliant and if so what are the technical arguments against it ?

in the spirit of good layering we should really focus on the application protocol
and not trying to crawl down the entire stack and securing each and every layer.
where does it stop ? i mean shall we include DoS mitigation schemes at L3 and L2 ?
clearly not - that is the operators choice and so is to take care of
transport level security.

---

From: Matthias Waehlisch <[email-masked]>
Date: Sat, 9 Apr 2011 23:57:01 +0200

Hi Hannes,

> 2. the application level communication protocol between caches and routers
  it's 1. However, an (inherent) requirement of the protocol is (a) to 
deliver the data such that it is authenticated and (b) the integrity of 
the data can be verified. Otherwise, at least from my perspective, the 
protocol would be useful.

  Leaving the mechanism for authentication and integrity undefined would 
result in a not well-defined protocol. From an implementation and 
deployment perspective, this is quite painful. We do not breach the 
"spirit of good layering" if we precisely define how this requirement 
can be achieved.

  Maybe, the question is if there is anything else to achieve the goals, 
which is not out-dated, implemented, and beyond the current suggestions.

Best regards
  matthias

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Apr 2011 15:49:46 -0400

At 9:30 PM -0700 4/6/11, Brian Weis wrote:
>I'm surprised IPsec hasn't been mentioned in this thread ... was it 
>previously discussed and rejected? Correct me if I'm wrong, but I 
>believe it's common for BGP routers to support IPsec and servers 
>definitely support IPsec. On the router side, one or two IPsec 
>sessions to servers should not be a burden. I'm less sure of the 
>server IPsec scaling properties, but I would expect a LINUX or BSD 
>kernel to have the scaling issues as were discussed earlier in this 

A few years ago we were told by vendors that many router 
implementations of IPsec were available only to traffic passing 
through a router, not to the
control plane terminating in a router.  Unless that has changed, IPsec is
not a good candidate here.

Steve

---

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

On 4/11/2011 12:49 PM, Stephen Kent wrote:
> A few years ago we were told by vendors that many router implementations
> of IPsec were available only to traffic passing through a router, not to
> the

FWIW, that was an artifact of the IPsec requirements for routers. 4301 
has the following requirements:

(end sec 4.1, RFC 4301):
    In summary,

    a) A host implementation of IPsec MUST support both transport and
       tunnel mode.  This is true for native, BITS, and BITW
       implementations for hosts.

    b) A security gateway MUST support tunnel mode and MAY support
       transport mode.  If it supports transport mode, that should be
       used only when the security gateway is acting as a host, e.g., for
       network management, or to provide security between two
       intermediate systems along a path.

A gateway acts as a host for all its routing protocol connections, and 
thus its control plane should have to comply with (a).

I agree, that's why IPsec isn't a good choice to protect BGP, but we 
sort of created that situation in 4301, AFAICT.

Joe

---

From: Brian Weis <[email-masked]>
Date: Wed, 20 Apr 2011 17:19:35 -0700

On Apr 20, 2011, at 1:40 PM, Joe Touch wrote:

> FWIW, that was an artifact of the IPsec requirements for routers. 4301 has the following requirements:
> 
> (end sec 4.1, RFC 4301):
>   In summary,
> 
> A gateway acts as a host for all its routing protocol connections, and thus its control plane should have to comply with (a).
> 
> I agree, that's why IPsec isn't a good choice to protect BGP, but we sort of created that situation in 4301, AFAICT.
> 
> Joe

I won't quibble with that argument as far as protecting BGP. But for the "router-to-server" protocol described by this draft is actually acting as a host for the exchange. There are more router IPsec implementations that can protect the control plane now, and meeting the requirements above would likely be doable.

Brian

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Apr 2011 17:25:16 -0700

On 4/20/2011 5:19 PM, Brian Weis wrote:
>>>>>> Getting a new application (such as the rtr protocol)
>>>>>> specifying hmac-md5 mandatory to implement through a Secdir
>>>>>> review and then the Security ADs just won't happen. The
>>>>>> only exception I can think of is if there were no possible
>>>>>> alternatives, and that's obviously not the case here.
>>>>>
>>>>> with AO not implemented on any servers, routers not having
>>>>> ssh libraries, and this being a server to router protocol,
>>>>> what are the alternatives?
>>>>>
>>>>> randy
>>>>
>>>> I'm surprised IPsec hasn't been mentioned in this thread ...
>>>> was it previously discussed and rejected? Correct me if I'm
>>>> wrong, but I believe it's common for BGP routers to support
>>>> IPsec and servers definitely support IPsec. On the router side,
>>>> one or two IPsec sessions to servers should not be a burden.
>>>> I'm less sure of the server IPsec scaling properties, but I
>>>> would expect a LINUX or BSD kernel to have the scaling issues
>>>> as were discussed earlier in this thread regarding SSH but I'm
>>>> no expert here.
>>>>
>>>> Brian
>>>
>>> through a router, not to the control plane terminating in a
>>> router. Unless that has changed, IPsec is not a good candidate
>>> here.
>>
>> (end sec 4.1, RFC 4301): In summary,
>>
>> transport mode.  If it supports transport mode, that should be used
>> only when the security gateway is acting as a host, e.g., for
>> network management, or to provide security between two intermediate
>> systems along a path.
>>
>> A gateway acts as a host for all its routing protocol connections,
>> and thus its control plane should have to comply with (a).
>>
>> I agree, that's why IPsec isn't a good choice to protect BGP, but
>> we sort of created that situation in 4301, AFAICT.
>>
>> Joe
>
> I won't quibble with that argument as far as protecting BGP. But for
> the "router-to-server" protocol described by this draft is actually
> acting as a host for the exchange.

Routers act as hosts for all routing protocol exchanges; that's not 
unique to the router-server exchange.

> There are more router IPsec implementations that can protect the
> control plane now, and meeting the requirements above would likely be
> doable.

There are other potential reasons why IPsec may or may not be the best 
choice, but I don't much care whether IPsec or TCP-AO is used; those are 
the appropriate choices if you care that the transport protocol is 
protected.

Joe

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 21 Apr 2011 22:45:10 -0400

So.. round and round the rosemary bush we go, still we have no actual
things that run actual tcp-ao, so given that can we either:

1) use md5 (as a MUST, with ssh as a MAY) and rev the doc at a later
point to say that AO is a MUST and remove md5
2) move this doc along the path
3) get implementations of the protocol today to start using md5

-chris
(co-chair-toe-socks-on)

On Wed, Apr 20, 2011 at 8:25 PM, Joe Touch <[email-masked]> wrote:
> Routers act as hosts for all routing protocol exchanges; that's not unique
> to the router-server exchange.
>
> choice, but I don't much care whether IPsec or TCP-AO is used; those are the
> appropriate choices if you care that the transport protocol is protected.
>
> Joe
>
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 22 Apr 2011 13:06:46 +0900

> 3) get implementations of the protocol today to start using md5

the base problem is a conflict between having and liking running code
and that the transport coverage is not what we would want in the long
run.

we now have running code from all major players in the game (junos, ios,
and ios/xr) which use cleartext.  while this is clearly not desirable,
we wanted running code while the ietf did rinse repeat for as long as
amused it.

and we have cleartext server code on many unix and unix-wannabe
platforms.  there is also ssh server code on thos platforms.

one of the three major vendor platforms is testing ssh now.  the others
are probably hoping this ssh thing will go away. :)

in 2012, we will probably see AO on most router platforms.  this will be
driven as much or more by bgp's needs as rpki-rtr's.  unfortunately,
server implementations are likely to trickle in more slowly.

so, in the long run, we can do the 'right' thing, presuming fashions do
not change.  but, in the meantime, running code trumps.  so the doc will
probably stay as it is, most stuff will run over cleartext as ssh will
be slowly deploying.  next rev, we can go AO as mandatory.

no, i do not like this.  but i am running the validation stuff and am
not writing code, so i ain't complainin' too much.

randy

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Apr 2011 21:14:57 -0700

> 3) get implementations of the protocol today to start using md5

You could instead do what the TCP-AO rfc recommends for apps like BGP:

- MUST support TCP-AO
- MAY also support TCP MD5 for backward compatibility

This avoids reinventing an answer for BGP caches and just applies the *current* advice for BGP in general. 

Joe

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Apr 2011 01:10:16 -0400

> This avoids reinventing an answer for BGP caches and just applies the *current* advice for BGP in general.

bgp cache is not bgp... it's really just a random tcp session from a
router to a thing some where else.

(does that change your proposed above?)

-Chris

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Apr 2011 22:27:04 -0700

> (does that change your proposed above?)

Nope. (and I was aware it isn't a BGP protocol connection)

Joe

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Apr 2011 01:31:06 -0400

> Nope. (and I was aware it isn't a BGP protocol connection)

awesome, was a tad worried your quote was specific to bgp... a
loophole so to speak.

---

From: Randy Bush <[email-masked]>
Date: Fri, 22 Apr 2011 15:28:26 +0900

> - MUST support TCP-AO

send code

---

From: "t.petch" <[email-masked]>
Date: Mon, 25 Apr 2011 10:47:33 +0200

----- Original Message -----
From: "Joe Touch" <[email-masked]>
To: "Christopher Morrow" <[email-masked]>
Cc: "sidr wg list" <[email-masked]>
Sent: Friday, April 22, 2011 7:27 AM

Joe

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.

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.

Tom Petch

> >>>> Routers act as hosts for all routing protocol exchanges; that's not
unique
the

---

From: Randy Bush <[email-masked]>
Date: Mon, 25 Apr 2011 19:11:37 +0900

> BGP-like; ie TCP-AO will not do.

perhaps long-hop will be a rare case, and you will want your routers
to have nearby caches.  see draft-ymbk-rpki-origin-ops.

remember, the caches talk to each other using object, not transport,
security.  it's just the final hop to the router that we're talking
about here.

randy

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Apr 2011 08:26:43 -0700

Hi, Tom,

On 4/25/2011 1:47 AM, t.petch wrote:
....
> wide access for - say - a Web site.

Hopcount security, i.e., GTSM (RFC 3682) is not at all related to TCP-AO.

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.

> 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

---

From: "t.petch" <[email-masked]>
Date: Thu, 28 Apr 2011 15:27:31 +0200

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

> 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

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2011 10:31:02 -0700

On 4/28/2011 6:27 AM, t.petch wrote:
> From: "Joe Touch"<[email-masked]>
> To: "t.petch"<[email-masked]>
> Cc: "Christopher Morrow"<[email-masked]>; "sidr wg list"
> <[email-masked]>

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.

> 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