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

From: Christopher Morrow <[email-masked]>
Date: Fri, 3 Jun 2011 02:06:07 -0400

Security-AD folks,
Over here in the SIDR WG we've been batting around a problem related
to secure authentication of TCP endpoints, essentially how can we
specify TODAY something to use in implementations of a (we think)
important protocol when the underlying technology we need isn't
available (TCP-AO). Some background:

Looking to close the issue of MD5/TCP-AO/SSH/etc out again, The doc:
<http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rpki-rtr/>

Seems to be stuck on this text:

(From the abstract)
" This document describes a protocol to deliver validated
   prefix origin data to routers over ssh."

or a more in depth version of that text at:
<http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-12#section-7>

Essentially there is a need to validate that a cache and a router are
talking to the right opposite entity. The authors and
test-implementors enabled this connection over SSH with a fallback
(for debugging I suppose?) over plain-text TCP originally. For a host
of reasons SSH is now considered overkill and likely detrimental to
the cause.

The WG discussed on-list (in this thread):
<http://www.ietf.org/mail-archive/web/sidr/current/msg02397.html>

and at the in-person meeting in Prague (IETF80) the fact that SSH was
probably overkill. The two endpoints want simply  to authenticate the
other endpoint, transport security isn't required here because the
content in the stream is already encypted. The 2 methods approved
today for use in IETF protocols are:
  o tcp-AO
  o ipsec AH

one deprecated method is available as well:
  o tcp-MD5

Of the two approved methods, AO has no implementations on the routers
(yet), nor server side to speak of, AH is relatively heavy weight and
isn't always available on routers today. Talking to routing equipment
implementors (two vendors) there was a feeling that AO will arrive
shortly while AH is still too complex (for router deployments) and is
not going to be available in all of the platforms which will require
this functionality.

On the server side of the equation there is no support for AO, some
for AH (which is nice actually). In short, we don't have a good
direction or belief that there is going to be one with respect to AO
in the near term.

What options are there for this problem? How can we motivate vendors
with a spec that clearly has problems in implementation (no AO, not
full reach for AH)? Are there folks who are tracking availability of
AO? Could we start with something like:

MAY support authentication of nodes with TCP-MD5
MAY support authentication of nodes with IPSEC-AH
MUST support authentication of nodes with TCP-AO

Or is mentioning TCP-MD5 verboten? Essentially it seems that the WG
has gotten wedged and is looking for some guidance from the Security
Area Directors :)

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 3 Jun 2011 12:44:44 -0400

a kind reader thunked me on the noggin'...

> today for use in IETF protocols are:

'the content in the stream is public data, so privacy isn't warranted
here.' Essentially make sure you talk to the right end point and no
one fiddled bits during transport (which AO and MD5 and AH all do just
fine, modulo the 'md5 is deprecated' discussion, of course)

apologies for the confusion, and... for not ending with:

-Chris
<wg-co-chair-utility-belt==unfastened>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 3 Jun 2011 16:23:44 -0400

> MAY support authentication of nodes with TCP-MD5 MAY support 
> authentication of nodes with IPSEC-AH MUST support authentication of 
> nodes with TCP-AO

True, privacy through SSH is overkill but strong AUTH is *critical*, I feel:
   - TCP-MD5 should not be considered (as it is any ways deprecated and it's MD5)
   - TCP-AO has only slight advantage as it has less overhead than ipsec-AH even when 
     deployed with manual keys
   - but it's better if it is "MUST support authentication of nodes with TCP-AO or ipsec-AH" because
     as both support 
           - strong auth algos
           - algo agility
           - can be deployed with manual and auto key management 
            (auto key probably required eventually, once with lot of connections at 
             cache/global RPKI/server side and for automatic key 
             changes periodically)
           - key changes for existing sessions
 
    One would get flexibility with this.
    Also Section 7 (page 16)
    "It is assumed that the router and cache have exchanged keys out of band by some reasonably secured means"
    This will be still applicable but only if TCP-AO/ipsce-AH are deployed with manual keys.

2 cents,
-Uma

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 3 Jun 2011 16:42:50 -0400 (Eastern Daylight Time)

On Fri, 3 Jun 2011, Uma Chunduri wrote:

....

>   - but it's better if it is "MUST support authentication of nodes with TCP-AO or ipsec-AH" because

Just to be sure:

Did you understand the part about implementations of TCP-AO and ipsec-AH 
not being available at present?

I.e., you recognize this forces a delay in implementation of the protocol 
(and accept the consequent impact on deployment of the RPKI)?

--Sandy, speaking as wg co-chair

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

---

From: John Scudder <[email-masked]>
Date: Fri, 3 Jun 2011 13:53:28 -0700

>   - TCP-MD5 should not be considered (as it is any ways deprecated and it's MD5)

What specifically do you mean by "should not be considered"?  

>   - but it's better if it is "MUST support authentication of nodes with TCP-AO or ipsec-AH" because

The drawback of saying "MUST support A or B" is that two implementations may be formally compliant yet not interoperable.  That would obviously be undesirable (to say the least).  IMO the spec should pick one mandatory one while leaving open the option to support others.

--John

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 3 Jun 2011 17:28:27 -0400

-----Original Message-----
From: Sandra Murphy [mailto:[email-masked]] 
Sent: Friday, June 03, 2011 1:43 PM
To: Uma Chunduri
Cc: [email-masked]; Sean Turner; [email-masked]
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

On Fri, 3 Jun 2011, Uma Chunduri wrote:

....

Just to be sure:

Did you understand the part about implementations of TCP-AO and ipsec-AH not being available at present?

I.e., you recognize this forces a delay in implementation of the protocol (and accept the consequent impact on deployment of the RPKI)?

[Uma] Yes, I did. Even though operators don't like  ipsec-AH today, it is still deployed for OSPFv3 protection as that 
(of course now there are other drafts to mitigate complexity with reasonable trade-off).

Problem with MD5 is, it can present the *weakest* link for the whole RPKI infa.
At least new infrastructure like RPKI should avoid deprecated  stuff.

-Uma

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 3 Jun 2011 17:33:01 -0400

-----Original Message-----
From: John Scudder [mailto:[email-masked]] 
Sent: Friday, June 03, 2011 1:53 PM
To: Uma Chunduri
Cc: Christopher Morrow; [email-masked]; [email-masked]; Sean Turner; [email-masked]; Rob Austein
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

[Uma] I responded in other e-mail. No protection is better than weak protection.

[Uma] True. Then probably TCP-AO. But ipsec-AH can give tough challenge as it's relatively 
     old and more readily available than AO (also understood better as it is already deployed 
     else where).
-Uma

--John

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 3 Jun 2011 21:11:29 -0400

> (of course now there are other drafts to mitigate complexity with reasonable trade-off).

So, speaking as just another guy on the bus here... it's not about
'dont like it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC"

Keep in mind that a router is not a generic CPU + intel ethernet PCI
card, and often the OS on it is optomized for a particular duty, in
large iron routers it's NOT ipsec.

> At least new infrastructure like RPKI should avoid deprecated  stuff.

exactly how is MD5 the weakest link here? some particular words about
the threat model + ability to subvert a running session which ships a
few megabytes/minute around would be in order here.

-chris
<just a guy>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 3 Jun 2011 21:12:15 -0400

> [Uma] I responded in other e-mail. No protection is better than weak protection.

to keep the thread clear: "Define Weak"

-chris
<co-chair-bangle-bracelent==on>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 3 Jun 2011 22:15:33 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: Friday, June 03, 2011 6:11 PM
To: Uma Chunduri
Cc: Sandra Murphy; [email-masked]; [email-masked]
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri <[email-masked]> wrote:
> [Uma] Yes, I did. Even though operators don't like  ipsec-AH today, it 
> is still deployed for OSPFv3 protection as that (of course now there are other drafts to mitigate complexity with reasonable trade-off).
>

So, speaking as just another guy on the bus here... it's not about 'dont like it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC"

Keep in mind that a router is not a generic CPU + intel ethernet PCI card, and often the OS on it is optomized for a particular duty, in large iron routers it's NOT ipsec.

> At least new infrastructure like RPKI should avoid deprecated  stuff.

exactly how is MD5 the weakest link here? some particular words about the threat model + ability to subvert a running session which ships a few megabytes/minute around would be in order here.

[Uma] 

1. Wang, X., H. Yu, "How to break MD5 and other hash
             functions", Proc. IACR Eurocrypt 2005, Denmark
2. RFC 4270

3. long back even OSPF, ISIS etc.. moved away from MD5
4. ...

For that matter SHA1 is getting deprecated http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation

Getting public keys from a server with a  deprecated auth mechanism to verify RSA signature? 
it's obscure..and not sure why it's not considered weak.
Well, one can still use and design systems around this if this is still seen adequate.

-Uma

-chris
<just a guy>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 3 Jun 2011 22:26:35 -0400

>             functions", Proc. IACR Eurocrypt 2005, Denmark

depends on creating 2 items to hash I believe?  shows that if you do
the right thing for 2 very large items you create you can get a
collision in some instances. not picking random bits off the wire, not
relevant, move on.

> 2. RFC 4270

talks about the above, not relevant.

> 3. long back even OSPF, ISIS etc.. moved away from MD5

fear, uncertainty, doubt.

we aren't talking about a permanent use of md5, we're talking about:
Use something that provides authentication/assurance NOW so we can
move forward, knowing full well we'll change to the better/required
solution when it's available in the right places.

There's not a single AO implementation available today... it's DOA
until there is. (frankly it's kind of a failure that there aren't
widely deployed implementations of this... given all the time to
invent it and all)

> For that matter SHA1 is getting deprecated http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation

again, not relevant.

please find something relevant that's not just fear mongering. Or,
alternately, find implementations of AO in the servers and routers
that matter. (if there are AO implementations w00t! we all win, until
then we spin)

-chris
<regular guy socks==on>

---

From: Randy Bush <[email-masked]>
Date: Sat, 04 Jun 2011 07:52:51 +0200

> not being available at present?

and not likely to be available on servers, one side of the connection,
for a looooong time.  after all, from the server stack hacker pov, where
is the customer demand?

randy

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Jun 2011 17:38:35 +0100

Hi all,

Trying to catch up with you all here.

>From reading the mail thread it seems to me that:

- tcp-md5 is available but undesirable
- tcp-ao is desirable but unavailable so far
- ssh is available and slightly undesirable for
  performance reasons but desirable in
  security terms

That would imply that an answer might be:

MUST implement SSH; SHOULD implement TCP-AO and
MUST/SHOULD prefer TCP-AO over SSH if both
available

Would that garner (rough) consensus?

We really do want to deprecate tcp-md5.

Cheers,
Stephen.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 4 Jun 2011 13:04:34 -0700

>             functions", Proc. IACR Eurocrypt 2005, Denmark

Wearing my co-author-of-4270 hat, let me state forcefully: invoking RFC 4270 or *any* current published work on MD5 does not answer the question of how MD5 is the weakest link here. Those are *unrelated* to an attack on the integrity of communication in draft-sidr-rpki-rtr. Collision attacks on MD5 and SHA-1 are, to date, unrelated to preimage attacks, and it is preimage attacks that you care about.

> Would that garner (rough) consensus?

Another proposal that might be more likely to garner rough consensus would be: MUST implement TCP-MD5 [RFC2385]; SHOULD implement TCP-AO [RFC5925] (the official successor to TCP-MD5) as soon as possible; if both parties in the protocol support TCP-AO, they SHOULD use TCP-AO and SHOULD NOT use TCP-MD5. After we believe that there is lots of TCP-AO adoption, we revise the document and remove TCP-MD5 as an option.

> We really do want to deprecate tcp-md5.

We already have: RFC 5925 obsoletes RFC 2385. The question is whether we want to prevent new protocols from using it and instead force them to use something else that doesn't work as well operationally while TCP-MD5 is still considered safe. Saying "MUST implement SSH" is tantamount to saying "many systems will run unprotected", which might be acceptable until TCP-AO is deployed. However, using TCP-MD5, but only until TCP-AO is deployed, seems like a better idea.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Sat, 4 Jun 2011 07:02:27 -0700

So basically the problem is that:

- routers don't all support IPsec for the control plane

- servers don't yet implement AO

I repeat that there's a known solution that is already being used for BGP:

Use AO if available

Use MD5 in the meantime

Yes, servers will support AO, if for no other reason than they support BGP and MD5 now. 

Joe

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 4 Jun 2011 20:56:37 -0400

> - servers don't yet implement AO

routers don't yet support AO either :( at least not in juniper 10.x
code nor cisco 12.2(S) or 15 code...
(or not that I've seen and been able to configure, though at least 1
of the 2 there say 'coming RSN!')

> I repeat that there's a known solution that is already being used for BGP:

ok, I think that's kind of where the implementors got in offline
discussions. I think people (me at least) are hoping the security AD
folks find this sort of wording/direction palatable though.

> Yes, servers will support AO, if for no other reason than they support BGP and MD5 now.

agreed, some heat is required to make this happen (heat == 'gosh I'd
love my Oracle/fbsd/linux server(s) to be able to run quagga to my new
and old IOS boxes...')

-chris

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Jun 2011 06:20:09 +0000

> Yes, servers will support AO, if for no other reason than they support

the problem is that they don't really.  check out, for example, the
freebsd md5 hack.  it is send-only, does not check on receive.  i am
told there are similar messes elsewhere.

basically this is a mess.
  o ipsec is not fully supported to the control plane, and it is
    a masters project to specify compatible parameters.  a sad ietf
    disaster.
  o md5 is not fully supported (on servers), but might be fixed more
    easily than AO.  it is weak in theory and widely deployed and
    deployable in practice.
  o ssh is not fully supported _as a library_ in routers, hacking is
    possible and is being done.
  o AO is nice paperware but does not have significant running code on
    servers or routers.  it tells us something about the ietf to have it
    push so hard on something with so little running code.

which is why we're pretty much using cleartext tcp today.  this is ok
for early deployment.  and it will definitely encourage ops to put the
cache servers close to the routers, which is good :).  but it is not a
good mid-term solution.

we'd really like to see a mandatory-to-implement so that ops have a
clear deployment scenario.  but ssh is the only strong candidate for
that at the moment, and it's not pretty.  at least one router vendor has
implemented.  and we have ssh implementation across a wide variety of
servers.

AO is the likely long term mandatory-to-implement, but could be a long
way out on servers.

sigh.

randy

---

From: Joe Touch <[email-masked]>
Date: Sun, 05 Jun 2011 15:19:55 -0700

Hi, all,

On 6/4/2011 5:56 PM, Christopher Morrow wrote:
> On Sat, Jun 4, 2011 at 10:02 AM, Joe Touch<[email-masked]>  wrote:

One other thing to keep in mind is whether this doc (and to some extent, 
the IETF as a whole) should follow or lead.

If we're followers, then the answer is clear - watch what the hackers 
implement.

If we're leaders, we should focus on the goal state, recognizing that 
all issued requirements are - at best - goals anyway.

> love my Oracle/fbsd/linux server(s) to be able to run quagga to my new

Again, follow vs. lead. If we're leading, then we should recognize that 
we're talking about a very small amount of resources need to accomplish 
this task. I'm already working with the funding agencies and a few 
companies with similar 'rfp' processes to access those resources. If 
anyone wants to help with any resources, please let me know.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 05 Jun 2011 15:28:21 -0700

Hi, all,

+1, with a caveat below...

On 6/4/2011 1:04 PM, Paul Hoffman wrote:
>> Wearing my co-author-of-4270 hat, let me state forcefully: invoking
> RFC 4270 or *any* current published work on MD5 does not answer the
> question of how MD5 is the weakest link here. Those are *unrelated* to
> an attack on the integrity of communication in draft-sidr-rpki-rtr.
> Collision attacks on MD5 and SHA-1 are, to date, unrelated to preimage
> attacks, and it is preimage attacks that you care about.
>
> Another proposal that might be more likely to garner rough consensus
> would be: MUST implement TCP-MD5 [RFC2385]; SHOULD implement TCP-AO
> [RFC5925] (the official successor to TCP-MD5) as soon as possible; if
> both parties in the protocol support TCP-AO, they SHOULD use TCP-AO and
> SHOULD NOT use TCP-MD5. After we believe that there is lots of TCP-AO
> adoption, we revise the document and remove TCP-MD5 as an option.

IMO, "MUST AO, MAY MD5 if AO is not available" achieves this *without* a 
"MUST" that overrides the existing AO/MD5 advice in the AO RFC .

The net effect is, AFAICT, identical, and more like what you state above.

FWIW, I also thing it's a lot more tractable to expect a MD5/AO use than 
an SSH/AO use; the APIs of the former two are likley to be very similar, 
but not the latter.

Joe

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 06 Jun 2011 00:29:24 +0200

Randy,

>      servers or routers.

I don't understand your line of argument. If vendor X is providing 
support of AO on his equipment what is a problem to provide downloadable 
linux kernel module to be able to establish such session end to end ?

Thx,
R.

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jun 2011 09:02:13 +0000

> all issued requirements are - at best - goals anyway.

rough consensus AND running code.  code, not powerpoint.

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jun 2011 09:03:21 +0000

> support of AO on his equipment what is a problem to provide
> downloadable linux kernel module to be able to establish such session
> end to end ?

this may come as a shock, but a linux kernel module does not work well
on unix, solaris, ...

randy

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 06 Jun 2011 12:50:04 +0200

What I am actually more shocked about is that you did not point out need 
to support this on AIX, SunOS, SCO and few others dated ones ;)

***

If indeed requirement is to support decent authentication on wide 
spectrum of operating systems why not consider application level 
approach of SSL/TLS and leave the need for TCP kernel hacking alone ? 
rfc5246 ?

Routers support it today so would any unix flavor as it will come with 
the application if not already there.

r.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 6 Jun 2011 13:00:34 +0200

On Mon, Jun 06, 2011 at 12:50:04PM +0200, Robert Raszuk wrote:
| If indeed requirement is to support decent authentication on wide
| spectrum of operating systems why not consider application level
| approach of SSL/TLS and leave the need for TCP kernel hacking alone
| ? rfc5246 ?
| 
| Routers support it today so would any unix flavor as it will come
| with the application if not already there.

hi robert,

---

quoting from rfc 5246:

   The primary goal of the TLS protocol is to provide privacy and data
                                              ^^^^^^^^^^^^^^^^^^^^^^^^
   integrity between two communicating applications.  The protocol is
   ^^^^^^^^^
   composed of two layers: the TLS Record Protocol and the TLS Handshake
   Protocol.  At the lowest level, layered on top of some reliable
   transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.
   The TLS Record Protocol provides connection security that has two
   basic properties:

---

we are just looking for a protocol which ensures data-integrity,
privacy is not of concern;

/hannes

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jun 2011 11:15:05 +0000

> to support this on AIX, SunOS, SCO and few others dated ones ;)

i know this will come as a shock to a vendor marketeer, but we want to
support what operators actually use

> approach of SSL/TLS

privacy is not the requirement

randy

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 06 Jun 2011 13:17:35 +0200

Hi Hannes,

> privacy is not of concern;

Are you really sure about that ?

One of the deployment models I have heard is the remote reception of 
prefixes/origins pairs which are found to be invalid by for example 
subscribing to CYMRU database.

If I would pay $20 per month for such feed which will relax me from even 
keeping a local RPKI cache in my network why would I not be concern that 
you will intercept my feed and use it without paying CYMRU?

Cheers,
R.

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jun 2011 11:26:52 +0000

> Are you really sure about that ?

yes

randy

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jun 2011 12:33:34 +0100

> Wearing my co-author-of-4270 hat, let me state forcefully: invoking RFC 4270 or *any* current published work on MD5 does not answer the question of how MD5 is the weakest link here. Those are *unre…

So I've been thinking a little about this. First, I do not
know of any practical md5 preimage attacks so far, however,
if we allow tcp-md5 in this spec, we're effectively betting
that that will remain the case for a few years at least and
that's not a bet with which I'd be happy when we do have
stronger options that are already specified.

Second, and perhaps more importantly, given that md5 is
broken for collisions, there may be other attacks on this
protocol using tcp-md5 that are enabled by that fact and
that do not require a preimage break for md5.

For example, if an attacker generates two colliding values
t2 and t2' and gets a value related to t2 injected into the
rpki so that at some later point a cache response message
will have the value t1|t2|t3, then our (now on-path) attacker
sees t1|t2|t3|MD5(t1|t2|t3|secret) and can substitute t2'
for t2 and have that work. I'm making many assumptions here
about encodings, lengths and the amount of work involved all
working out for an attacker who can inject values into the
rpki and be on-path, but I think those are not necessarily
unreasonable given the rapidssl attack of a few years ago. [1]

   [1] http://www.win.tue.nl/hashclash/rogue-ca/

So, unless I'm off the mark on this point, (which is
quite possible), I think that tcp-md5 is simply
unacceptable here.

Stephen.

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jun 2011 13:54:46 +0000

> stronger options that are already specified.

let me try again.

while i agree with you philosophically, packets do not move very well on
'specified.'  and unless someone throws a lot of cash at it, AO looks as
if is likely not to be available for a long on the set of platforms
operators use for services, *BSD, Linux, and Solaris.

randy

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jun 2011 06:58:28 -0700

>   The primary goal of the TLS protocol is to provide privacy and data

TLS is exactly like SSH and IPsec in this case. It is easy to configure TLS to be doing integrity-only. The overhead for encrypting, if you are doing so, is extremely low.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jun 2011 15:09:36 +0100

On 06/06/11 14:54, Randy Bush wrote:
> 'specified.'  

That's a fair point and is why I said the 2nd point is more
important. The 2nd point being that it looks to me like
tcp-md5 is just broken for this use case. If I'm wrong there
I'll happily admit that.

> and unless someone throws a lot of cash at it, AO looks as

I do understand that that's a problem.

I don't however understand fully why SSH is being ruled out.
All I saw on the list were a couple of mails saying that you
can't use epoll which I'd have thought was a bit of a bummer
but not a showstopper. But maybe picking SSH has more issues
than that?

That's why I suggested "MUST implement SSH; SHOULD implement
TCP-AO; MUST prefer TCP-AO if both available"

S.

---

From: Randy Bush <[email-masked]>
Date: Mon, 06 Jun 2011 14:37:48 +0000

> I don't however understand fully why SSH is being ruled out.

it has not yet been.  for some router platforms, while they have ssh
server code, the ssh code is not a library with an api.  and the bgp
hackers are not empowered to touch that side of the code.

> That's why I suggested "MUST implement SSH; SHOULD implement TCP-AO;
> MUST prefer TCP-AO if both available"

indeed, we may have to fall back to this.  we still do not have for sure
committments that all vendors can do this.  but we're working it.

folk such as russ and sean are more tuned to timing and constraints than
i.  my job here is just to hammer on the operational realities of
delivery.

but anything that folk can do to move AO from the powerpoint platform to
the *BSD, Linux, and Solaris platforms will have long-term pay-off for
both BGP and RPKI-Rtr.

randy

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jun 2011 07:42:26 -0700

And, just to close the loop: do the TLS libraries have the same limitations that the SSH libraries do that prevent them from being used with kqueue/epoll? If not, specifying TLS would then solve the problem here.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jun 2011 15:57:51 +0100

> committments that all vendors can do this.  but we're working it.

Cool. I'm happy to help with that to the extent that I can.

> i.  my job here is just to hammer on the operational realities of

I fully agree that delivery is very important in this case.

> the *BSD, Linux, and Solaris platforms will have long-term pay-off for

Agreed again.

S.

---

From: John Scudder <[email-masked]>
Date: Wed, 8 Jun 2011 11:30:16 -0700

On Jun 6, 2011, at 10:09 AM, Stephen Farrell wrote:
...
> TCP-AO; MUST prefer TCP-AO if both available"

The penny finally dropped and I realized there is a better reason why SSH isn't desirable, and neither is TLS or any other solution layered on top of TCP: they don't protect the transport.  Recall why TCP-MD5 was introduced (from RFC 2385):

   The primary motivation for this option is to allow BGP to protect
   itself against the introduction of spoofed TCP segments into the
   connection stream.  Of particular concern are TCP resets.

Any protocol layered over TCP can't address this concern.  

While authentication of peer identity and integrity of the transported data are even more important than transport protection per se for RPKI-RTR, it would seem prudent to assume that any threats that affect BGP may also affect RPKI-RTR.  That means protecting the transport from reset attacks, and that means AO, IPSec or MD5.  

--John

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jun 2011 08:56:54 +0000

> The penny finally dropped and I realized there is a better reason why
> SSH isn't desirable, and neither is TLS or any other solution layered
> on top of TCP: they don't protect the transport.  Recall why TCP-MD5
> was introduced (from RFC 2385):
> 
> While authentication of peer identity and integrity of the transported
> data are even more important than transport protection per se for
> RPKI-RTR, it would seem prudent to assume that any threats that affect
> BGP may also affect RPKI-RTR.  That means protecting the transport
> from reset attacks, and that means AO, IPSec or MD5.

rpki-rtr != bgp

the purpose of the wrap in rpki-rtr is authentication of the
end-points.  am i talking to the cache which i think i am?

tcp session restart is actually doable in rpki-rtr.  that is why the
nonce is there.

randy