Subject: RE: [Cfrg] Re: [saag] Algorithm upgrades

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 6 Nov 2004 09:42:34 -0800

I agree with Paul's analysis of the problem, if not the solution.

IPSEC is a miserable, miserable protocol to use. It only works in many cases
because of ad hoc infrastructure allowances that are outside the
specification.

It is certainly no occasion for a victory dance. If I was going to design a
VPN from scratch I would simply tunnel over SSL and completely ignore the
IPSEC stack. IPSEC is useless to me unless it works in the hotel I am
staying in. SSL works through NAT reliably. IPSEC does not.

People need to decide whether the purpose of the protocol design is to meet
the real needs of users or to amuse ourselves. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Hoffman / IMC
> Sent: Saturday, November 06, 2004 10:48 AM
> To: D. J. Bernstein; [email-masked]; [email-masked]
> Subject: Re: [Cfrg] Re: [saag] Algorithm upgrades
> 
> 
> At 8:55 AM +0000 11/6/04, D. J. Bernstein wrote:
> >Was it impossible to encode a DES-vs.-AES
> >bit for IPSec into one of those numbers?
> 
> No, it was not. And we arguably should have done so. At the risk of 
> causing my brain to explode, I will agree with Dan and disagree with 
> Bill and Ran here.
> 
> Statements like "not really noticeable" and "work well operationally" 
> are absurdly out of touch with typical IPsec VPN users. Even the best 
> UIs for gateways force low-ability admins and lower-ability end users 
> to make multiple selections of things that they don't (and shouldn't 
> need to!) understand.
> 
> The IPsec WG has recently agreed to two "UI suites" for sets of 
> algorithms that we think make sense for the vast majority of users. 
> These UI suites don't prevent fine-grained negotiation of crypto 
> details, but they allow vendors to have one or two buttons, plus an 
> optional third that says "advanced users: get lots more choices here".
> 
> If we knew we would come this this point when IKEv1 was developed, it 
> would make imminent sense to allocate three port numbers to it: one 
> for button A, one for button B, and one for fine-grained 
> negotiations. It is arguable that we should have done that for IKEv2; 
> no one suggested it, but in hindsight it seems quite reasonable.
> 
> Pre-defined suites *are* TCP port-level choices. A responding system 
> that can only do Suite A can announce that simply by listening on 
> that port, and the initiator knows their capability. Systems that 
> also want negotiation can.
> 
> The scarcity of port numbers is over-rated relative to having simpler 
> and more robust security protocols.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://jis.mit.edu/mailman/listinfo/saag
> 

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

---

From: Jeff Williams <[email-masked]>
Date: Sat, 06 Nov 2004 21:15:25 -0800

Phillip and all,

  I agree entirely with Phil here. However there are some whom
still wish to push IPsec such as Vint Cerf, for reasons that defy
good operational reason.  IPsec as it currently stands, is not
effective in any real world sense...

> > --Internet Mail Consortium

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 08 Nov 2004 14:24:00 +1300

"Hallam-Baker, Phillip" <[email-masked]> writes:

>IPSEC stack. IPSEC is useless to me unless it works in the hotel I am staying
>in. SSL works through NAT reliably. IPSEC does not.

One of the most practical designs I've seen uses TLS for the initial
negotiation (completely sidestepping the IKE quagmire) and then ESP for
transport. The best-known implementation of this is OpenVPN, which is more or
less the SSH of VPNs, it's easily available, runs on everything, and works out
of the box without any need for endless fiddling and configuration problems.
Just like SSH did years ago, it seems to be slipping in everywhere for more or
less the same reasons that SSH was adopted.

(There was a plan to do an RFC on this a while back but it kinda fizzled out,
 mostly because everyone just grabs OpenVPN and uses it rather than bothering
 to read/write about it.  Again, it's a strong parallel to the original SSH).

Peter.