Subject: Re: 10 years and no ubiquitous security

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 18 Mar 2002 10:18:33 -0600

In message <[email-masked]>, William Allen Simpson writes:
>"The Purple Streak (Hilarie Orman)" wrote:
>> Mild-mannered S. Kent is in reality SuperNoSecMan.  He adds
>> the essential anti-replay counter to IPsec protocols and, ...
>> causes people to NOT adopt them? 
>
>Actually, of course, Steve Kent did not add the counter.  It was in 
>swIPe, from the beginning.  It was in my drafts, from the beginning.
>
>It was certain members of the WG who insisted we didn't need the 
>counter.  At least one has admitted he was wrong.  Are you ever going to 
>admit you were?
>
>Anyway, when we published the first set of RFCs, I carefully documented 
>the need for a Replay Protection sequence number in 1995:
>  "Internet Security Transform Enhancements"
>

Right.  The only copy I could find was from 1996, but I don't think 
that that difference is important.  
(http://www.watersprings.org/pub/id/draft-simpson-ipsec-enhancement-00.txt)
The problem with it -- and the reason I had objected to sequence numbers -- 
is that it never justified *why* they were necessary, beyond rather 
minor DoS prevention.  It simply said "replay protection provides
cryptographically secure at-most-once datagram delivery."  But there 
was no analysis of why one would want that.  The same is true of the 
swIPe paper and I-D -- there was no analysis beyond saying "replay 
protection".

When attacks on confidentiality were developed that exploited the lack 
of replay prevention, I changed my mind and strongly supported sequence 
numbers.  The difference is that there was then a reason.  For what 
it's worth, Kent applauded the restoration of the counter -- he knew it 
was necessary.

But Bill, I'm trying to understand what your point is.  We can't force 
people to use security.  IPsec is standard in most major business 
operating systems (Win2K, Solaris, *BSD, etc.) and available for for 
Linux.  There are hardware solutions -- I have a small IPsec box with 
me in Minneapolis.  But except for VPN scenarios, most people choose 
not to use it.  I think there's a lesson there, but I fail to see how 
Steve Kent or any of the other players in the history of IPsec are at 
all at fault.

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com

---

From: George Michaelson <[email-masked]>
Date: Tue, 19 Mar 2002 03:33:18 +1000

> 		--Steve Bellovin, http://www.research.att.com/~smb

I would like to comment on the other issue in this paragraph, about why
IPSEC deployment might lack vigour.

I set up VPN over IPSEC on a national academic network with 40mbit backbone
and 10/100 mbit site linkspeeds. the best end-to-end performance I could get
was 2mbit rising to 3-4 burst, and I was flooded by fragmented IP.

Stuff like pMTU end-to-end is absolutely vital to make non-aware clients
and servers cope with encapsulated protocols.

I have also played with the client side code, and found that UDP protocols
like Windows SMB do not work well on noisy/long-delay links. THis repeats
the experience of encapsulated LAT some of us ex-DECheads remember: you
can't fix bad protocol experiences by wrapping them in better protocols
if the end-to-end behaviour depends on the badness (eg timer dependencies)

Please don't get me wrong: I use IPSEC, I like IPSEC, but I have to 
recognize that off the beaten track, or for some (very useful) contexts
it turns out not to work as well as we'd like, for reasons probably not
to do with IPSEC per se, but the general state of the network.

When you factor in that most of the 'simple' things can be done equally
well in SSH, or by less clued people using non-secured tunnels, it gets
harder to do a sell on IPSEC. which is a shame, because I really like
IP layer abstracted methods, and the idea of generic infrastructure rather
than applications-level point solutions.

cheers
	-George
--
George Michaelson       |  APNIC
Email: [email-masked]    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3100  |  Australia
  Fax: +61 7 3858 3199  |  http://www.apnic.net

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 18 Mar 2002 15:16:12 -0500

> (http://www.watersprings.org/pub/id/draft-simpson-ipsec-enhancement-00.txt)

Remember, the WG chair objected to my drafts being draft-ietf-ipsec-, 
and so they were reissued in 1996 as draft-simpson-, restarting at -00.

To the middle of your message, why is it a problem that we were so 
brilliant that we prevented a threat before somebody else documented 
the attack?  We are engineers, not cryptanalysts.  It seemed obvious.

Anyway, _you_ had the integrity to admit you were wrong.  Thanks!  
(I just wasn't sure I should mention your name in a negative context.)

> ...  But except for VPN scenarios, most people choose
Because the so-called "standard" is hard to understand, hard to 
implement, hard to install, and hard to use -- and now verified to 
have security failures, some of which I documented at least 6 years ago.  
Other than that?

As you may remember, Photuris was designed to start itself 
automatically, without significant user intervention.  (Somebody else 
just noticed the ICMP Security Failures messages.)

Another of the things I used to do: have an Operational Considerations 
section in my drafts.  Anything with a lot of configuration and 
dependencies has too many points of failure.

But I'm so disgusted with Ran denying that other people did any work, 
or that he knew about it, that I'm hoping the thread will end.  Surely, 
the secretariate mistyped that string in 1992 (on page 363).  Oh well, 
it's not the first time I've caught him in a lie....

The point was made: we've been delayed and obfuscated into oblivion.  
The WG has been spinning its wheels for a decade.
-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: Dan McDonald <[email-masked]>
Date: Mon, 18 Mar 2002 13:48:22 -0500 (EST)

> was 2mbit rising to 3-4 burst, and I was flooded by fragmented IP.

You should try (again?) a more modern implementation.

> and servers cope with encapsulated protocols.

Agreed.  Many of us _do_ understand these issues.

Dan

---

From: Alex Alten <[email-masked]>
Date: Mon, 18 Mar 2002 17:26:21 -0800

>>"The Purple Streak (Hilarie Orman)" wrote:
...
>Steve Kent or any of the other players in the history of IPsec are at

At last call call several years ago I detailed my misgivings about
the design.  However since so many talented people had already put
years of work into it I also wrote that the market must decide its
fate. It seems to have decided, IPsec has settled into a fairly modest
VPN market niche ($200M/yr revenues or so?). It is not turned on by
(or not available on) at least 99% of the Internet hosts.

I guess the $64 question is whither do we go now with IPsec?
1. Do we do significant surgery on it and muddle on?
2. Do we stop working on it and start over with a fresh design?
   (Besides VPN what other pressing problem needs a solution?)
3. Do we give up? (Or at least be satisfied with a VPN only solution.)

I'm a little amazed that IPsec has had as much success as it has had
to date.  I've seen so many other secure IETF protocols die much more
quickly; SNMPSEC, PEM, SHTTP, etc.

- Alex

--

Alex Alten
[email-masked]