Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle.

From: "Michel Py" <[email-masked]>
Date: Thu, 25 Jul 2002 22:52:59 -0700

Charlie,

> Charles Lynn wrote:
> Hi Michel,
> Can you explain why the current IPsec protocols are not able to
> satisfy your needs, or why their use would make the protocol you
> are designing not work well?
> E.g., "needs too much bandwidth for the low bit rate radio links",
> or "the protocol operates at the link-layer and IPsec is in the IP
> layer".

It's a matter of extra latency. Long story made short, the concerned
part of MHAP is a three-way (client, rendezvous point, endpoint),
connectionless, UDP based animal. Note that authentication / signing
(vs. data encryption) is what I am looking for, and it does require some
crypto magic.

My feeble understanding is that IPSEC, as I know it, and specifically
the establishment of the SA, will require several back-and-forth packets
that will introduce an unacceptable latency (I'm happy to provide any
detail you wish about it, but I think they would be o/t for here).

Also, there have been extensive concerns on the ipv6mh mailing list
about "crypto DoS", which is that it is easier to DoS a router that uses
crypto by feeding it encrypted packets full of foo (the rationale being
that most routers can't handle decrypting packets at line speed), vs. a
brute-force bandwidth based DoS.

To push it to the extreme, what I need is a one-way,
connectionless IPSEC ;-) 

Hopes this makes sense; if it does not please state it.
Michel.

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jul 2002 17:56:15 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Michel" == Michel Py <[email-masked]> writes:
    Michel> It's a matter of extra latency. Long story made short, the concerned
    Michel> part of MHAP is a three-way (client, rendezvous point, endpoint),
    Michel> connectionless, UDP based animal. Note that authentication / signing
    Michel> (vs. data encryption) is what I am looking for, and it does require some
    Michel> crypto magic.

  Sorry, Michel, you are asking for faerie dust. Stop dreaming.

  The fastest that you can get key agreement is with 1 1/2 round trips. 

  IKEv1, proposed IKEv2 and JFK do it no faster than 2 round trips, sometimes
3 round trips. They also provide protection against passive eavesdropping of
identities, protection against passive DoS, and some flexibility in
negotiation of protocols.

  You can do a bit better than them, but in my opinion, not enough to justify
any additional lines of code in a border router.

  As I have said several times on the ipv6mh list. 

  The bits-on-the-wire problem is SOLVED. The key agreement problem is also
solved. The problem is the trust model.   

  Securing routing means that at some level every network needs to have a
statement about what are acceptable routes to reach it. That means signed
statements. That means a delegation of trust along the same paths that the
allocations of address spaces flows. 

    Michel> To push it to the extreme, what I need is a one-way,
    Michel> connectionless IPSEC ;-) 

  See HIP.
  But it likely is DOS'able, you just may have to pay for public key
cryptography rather than symmetric cryptography. It still requires that the
trust problem be solved.

]    Internet Security. Have encryption, will travel           |1 Fish/2 Fish [
]  Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F [
][email-masked] http://www.sandelman.ottawa.on.ca/ |strong crypto [
]    At the far end of some dark fiber - wait that's dirt!     |for everyone  [