Subject: Re: Next Step

From: Steve Sneddon <[email-masked]>
Date: Wed, 04 Feb 1998 12:53:07 -0800

Dan,

I agree that it would be a shame if something were to distract from IPSec
interoperability testing. However, the "peace treaty" that we agreed to,
wherein we agreed to *not* hold IPSec hostage to the compression issues,
contained an intent clause that said that we'd be open and friendly toward
IPComp testing when its time came. That time has come, and the customers
wholeheartedly want this testing, so let's be collegeable about it. The cost
of bakeoffs is too high to act otherwise.

Is that reasonable?

Cheers,
Steve

At 12:28 PM 2/4/98 -0800, Daniel Harkins wrote:
>  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.
>
>> >  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.
>
>
>

---

From: Daniel Harkins <[email-masked]>
Date: Wed, 04 Feb 1998 14:29:53 -0800

Steve,

  I wasn't aware of any treaty or any intent clauses therein. Nor am I
sure that it's enforceable. And, "What do you mean 'we', White Man?" :-)
Jeez, it sounds like there was some sort of blackmail involved! Guns 
pointed to heads, hostages, etc.

  As I said in my last post, people can test IPComp if they want. They can
just sit around talking on the telephone too. There's nothing I or anyone 
that I'm aware of can do about that. But if someone wants to spend their 
time debugging why IPComp doesn't work with company A but it does with 
company B (and company B and A can IPComp to their heart's content) to the 
detriment of the whole reason why this bake-off was organized then that's 
just a damned shame. My opinion entirely, but that's what I feel.

  Yes, bake-offs are difficult and expensive to organize. But this is the
next in line of a series of IPSec bake-offs, not the 1st IPComp bake-off.
We're all coming together because we have IPSec and ISAKMP/Oakley product
to test. The rest is, as I've said before, frosting on the cake. It might
be delicious and a fabulous shade of purple but if the cake it's swathed
on is soggy or burnt or salty or whatever then nobody's gonna eat it. 

  Do customers want product which requires them to contact the other party 
on the telephone to pre-arrange what the security parameters are going to
be? No! And having witnessed these things in the past that is exactly what
we have. Adding another feature that a customer must negotiate over the
telephone prior to the commencement of communication is not a plus no
matter how badly they want that that feature. We have to start doing real
world testing. If that includes IPComp then whoop-di-do. If we don't do real
world testing because we're trying to do IPComp then we've failed. We 
might've saved some money by failing two times for the price of one but we 
still failed.

  I'm not being un-"collegeable"(?) or un-friendly. I'm just trying to 
raise the bar for this bake-off. Merely adding IPComp to what we can already
do is not a raise of the bar. 

  Dan.