RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

> We really need an elegant, simple, system solution that
> preserves the huge
> legacy infrastructure that rides on top of IPv4.  Design goal
> #1 should be
> no new bytes added into or inserted after the IPv4 header.

Blah, blah, blah. If there's one common thread to your posts, it seems to be
that you would have done a much better job of designing IPsec than anyone
else on this list. You might want to consider the fact that the biggest
incompatibility between IPsec and NAT is that ESP runs on its own IP
protocol instead of an assigned UDP port. That decision was no doubt
motivated by the desire to avoid adding any new bytes into or after the IPv4
header. Your rants have the superficial appeal of an opinion that has never
really been thought through.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten
> Sent: Tuesday, July 30, 2002 3:33 PM
> To: Dilkie, Lee; 'David R. Oran'; ipsec@lists.tislabs.com
> Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt
>
>
> Dilkie,
>
> Every since last call many years ago I have made it clear to
> this WG that
> I felt IPsec was too complex.  It needs to go everywhere that
> IPv4 goes.
> Shimming in another protocol header makes that ideal goal impossible.
> IPsec will never be able to support in a practice many types of
> transport, application or routing/error/discovery protocols.
>
> It is time that we sit back and re-examine it.  Instead of putting the
> extraordinary efforts into a new key exchange protocol,
> adding new ciphers,
> co-existing with NATs, etc., let us seriously consider a
> complete redesign.
> My understanding of the two arts is such that I am certain we
> could retrofit
> IPv4 in such a manner as to satisfy your needs as well as many others.
>
> We really need an elegant, simple, system solution that
> preserves the huge
> legacy infrastructure that rides on top of IPv4.  Design goal
> #1 should be
> no new bytes added into or inserted after the IPv4 header.
>
> There I've said it.  The emperor has no clothes.
>
> - Alex
>
>
> At 11:28 AM 7/30/2002 -0400, Dilkie, Lee wrote:
> >> Which is one reason some of us went off and designed SRTP...
> >
> >Thank goodness someone said it. I've been biting my tongue
> since this
> >thread started. Yes, the 8 bytes of IV *are* significient.
> SRTPs solution
> >to use existing information in the packet to generate an
> implicit IV (and
> >you avoid IV reuse too) and avoid *any* packet expansion is
> key to not
> >wasting bandwidth and is absolutely necessary if you want to
> encourage(push)
> >encryption of media streams (VoIP especially).
> >
> >Is it important that IPsec use implicit IVs? It would help
> but IPsec has
> >other overheads that expands the packet already and you
> could well argue
> >that it wouldn't make much of a difference (and therby justify SRTPs
> >original reason for existance... that IPsec is just too big
> to use for VoIP).
> >
> >Do some math.
> >
> >One T1 (24 voice channels if configured for PSTN, 32 for
> european T1),
> >1536000 bps (more for our european friends). I'm ignoring
> media transport
> >overhead, these numbers are better than they would be in real life.
> >
> >(assuming 20ms (50 fps) RTP packets, no header compression)
> >
> >G.729, 60 byte TU , 64 voice "channels"
> >G.729, 68 byte TU (explicit IV), 56 voice "channels" (dunno
> 'bout you, but
> >that 13 percent overhead seems significient to me)
> >
> >G.711(uncompressed), 210 byte TU, 18 "channels" (unhappy
> customer, gets
> >less than PSTN T1)
> >
> >Things get better with header compression.
> >
> >Now try the same math with IPsec encrypted packets...
> >
> >
> >-lee
> >
> --
>
> Alex Alten
> Alten@ATTBI.com
>