Subject: Re: Next Step

From: Naganand Doraswamy <[email-masked]>
Date: Wed, 04 Feb 1998 09:20:53 -0500

Dan,

>  Just to keep the record straight. The 3/98 meeting is an IPSec bake-off.
>Vendors may want to test other protocols in conjunction with IPSec (L2TP 
>and IPComp come immediately to mind) but that should be a sidebar to the
>main activity. We're baking IPSec and ISAKMP/Oakley. If you have frosting 
>or sprinkles to add on top that's great.
>
I would change the wording a little bit. Instead of saying it is a sidebar,
I would like to see it mandatory but to be tested after IPsec and ISAKMP.
It is difficult to organize a bakeoff just for IPCOMP and I would like to
piggybank on the IPsec workshop in the interest of pushing the IPCOMP for
draft standard.

Thanks,
--Naganand

-----------------------------------------------------------------
Naganand Doraswamy				(978)916-1323 (O)
Bay Architecture Lab				(978)670-0620 (Fax)
3 Federal St, Mail Stop BL3-03
Billerica, MA 01821

---

From: Daniel Harkins <[email-masked]>
Date: Wed, 04 Feb 1998 12:28:41 -0800

Naganand,

  I don't believe any of the RFC-bound IPSec documents mandate IPComp so
I don't see how it can be mandatory. I understand the motivation and the
desire though. People can work on IPComp after everything else, as you say,
or in conjunction with everything else but this is an IPSec bakeoff and
anything (IPComp or L2TP or too much beer) that distracts from the
issues we have would be a shame. And we do still have issues.

  Yesterday I exchanged unicast email with someone on this list about this
very subject and I'd like to repeat the gist of it.

  The past bakeoffs have been completely unrealistic. People run around
the room(s) saying, "Do you want to negotiate? How about ESP-DES with
HMAC-SHA? Great! Wait a second and I'll initiate." Or 3 people initiating
with a single person who starts screaming, "Wait! Stop! Not all at once!"

  At the last bakeoff we had quite a bit of real world set-ups with tunnels 
through gateways, SAs timing out and being reestablished, certificates being 
revoked, to show that subsequent ISAKMP negotiations fail, etc. That's all 
hunky-dory but it still contained a significant amount of live, verbal, 
pre-negotiation.

  I'd like to see vendors set up their hosts and gateways with some defined
policy (e.g. all tcp traffic to 132.239.4.1/255.255.255.0 gets one shared SA 
and in addition telnet traffic to 132.239.4.86 uses one unique SA) then
hands off and let's start beating on stuff. I can set up an httpd behind
my router and let people try to securely browse. People can put gifs of
whatever in some ftp directory on their IPSec-speaking host and let people 
try to securely get them. Multiple, simultaneous, negotiations with
multiple peers. Mulitple, simultaneous, negotiations with the same peer!
(One to browse the webpage on 132.239.4.44, one to telnet to 132.239.4.86).
Etc etc etc. Stuff that's a bit closer to The Real World (tm). 

  Now if people do IPComp in addition that's wonderful but I think it would
be a shame if we added IPComp to the things with which we've sucessfully 
demonstrated interoperability if we continue to have to verbally pre-negotiate.

  Of course, being a cutthroat vendor I wouldn't mind seeing a competitor
doing Triple-Cast-128 with HMAC-Tiger and IPComp and wiz-bang whatever
if it requires a hokey and unrealistic setup. That's just more clubs to give 
our marketing department. But I think it would be a failure of the bake-off.

  IPComp is great and it makes sense to do in conjunction with IPSec but
if your product isn't ready for prime-time and you do IPComp you're still
not ready for prime-time. I'm not saying my product is ready for prime-time
but I'd like to find out and the bake-off is a fantastic opportunity to
do so. 

  I'm just a single, opinionated, individual here. I don't speak for my
company and I can't enforce my wishes on the bake-off (people can test IPComp
or sit around and argue about US Gov't export policy and there's nothing I
can do about it). I just would like to use this opportunity to build on the 
demonstrated IPSec successes of past bake-offs. 

  Dan.