From owner-ipsec Sun Feb 2 21:21:00 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA12782 for ipsec-outgoing; Sun, 2 Feb 1997 21:13:21 -0500 (EST)
Message-Id: <3.0.32.19970202153751.009b8540@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 02 Feb 1997 20:15:33 -0500
To: ji@hol.gr, linux-ipsec@clinet.fi, ipsec@tis.com, ietf-sectest@toad.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Reminder: Release 0.4 of my Linux IPSEC code is out.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 09:29 AM 1/29/97 +0200, John Ioannidis wrote:
>
>Please note that in some countries such as the USA, it is unlawful for a
>citizen of that country to provide technical assistance "with the intent to
>aid a foreign person in the development or manufacture outside the United
>States" of
>"Encryption Items".
I think there is a partial 'out'. If a US company is attempting to
interoperate with your code and fails, they can point to the part of a
public specification related to the failure. Such as our implementations
failed to interoperate related to section n.m.o of rfc wxyz.
But I am not a lawyer, only heard this explaination 3rd hand from a lawyer.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Mon Feb 3 10:24:44 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17586 for ipsec-outgoing; Mon, 3 Feb 1997 10:22:36 -0500 (EST)
Message-Id: <199702031526.QAA13659@digicash.com>
From: "Niels Ferguson" <niels@DigiCash.com>
To: <ipsec@tis.com>
Subject: Q: test vectors for HMAC-SHA-1
Date: Mon, 3 Feb 1997 16:27:22 +0100
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I have implemented HMAC using SHA-1 as hash function. I have found test
vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test
vectors? If not, I would be happy to help create them.
Niels
----------------------------------------------------------------------------
---
Niels Ferguson, email: niels@DigiCash.com. (usual disclaimer applies)
...Of shoes, and ships, and sealing-wax, of cabbages, and kings,
And why the sea is boiling hot, and whether pigs have wings...
[Carroll]
From owner-ipsec Thu Feb 6 07:56:38 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10784 for ipsec-outgoing; Thu, 6 Feb 1997 07:41:50 -0500 (EST)
Message-Id: <9702060420.AA79343@aurora.cis.upenn.edu>
To: ipsec@tis.com
Subject: Path MTU Discovery
Date: Wed, 05 Feb 1997 23:20:02 -0500
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
I originally sent this message to Steve Kent, who asked me to forward
to the list for comments, corrections etc.
Path-mtu discovery breaks in the presence of multiple IPsec
encapsulation(*) (it might even break in the presence of ONE
intermediate encapsulating entity). We could make a requirement of
IPsec that it shouldn't; here's a suggested algorithm:
a) a host that does encapsulation and cannot forward the packet due to
DF bit set, should send back to the source of the packet (original
source or previous encapsulating entity) a normal ICMP, with enough
payload length to include the SPI of the packet received. This can be
done by copying the first XXX bytes of the packet in a separate
buffer/mbuf-chain if the DF bit is set, process it normally, and if it
fails send back the ICMP based on the copy kept (so no decapsulation
is necessary).
b) uppon receipt of an ICMP Unreachable-need fragmentation, if the
protocol on the internal header is AH or ESP, validate the
destination/SPI pair and keep the value of next_mtu as reported. If a
packet arrives that would use this SPI and the size is larger than the
mtu value, subtract the overhead this host imposed on the packet and
send back an ICMP (as per bullet -a-).
c) Alternatively, an IPsec implementation could keep a table with
ip_id|SPI sent (a circular buffer of fixed size, preferably dependent
on the total speed of the network interfaces) where each time an IPsec
packet is sent out, the ip_id and the SPI is kept. Uppon receipt of an
ICMP fragneeded, check the ip_id in the internal IP header against the
table, and find the relevant SPI. Proceed as per bullet -b-.
It might seem complicated, but all it really needs is a little more
book-keeping on behalf of an implementation.
This still doesn't address the problem of the original TCP mtu (the
mtu of the outgoing interface could be less than that reported on the
kernel structure, depending on whether a packet will be IPsec'ed or
not). But i doubt we can mandate a solution for that.
Also, there's the case of whether we accept as valid ICMPs from anyone
in between (which means anyone) or just two encapsulating entities
(e.g. two tunneling firewalls). The network-correct approach is
anyone; the security correct is next enc entity.
- -Angelos
(*) Steve Kent replied that it shouldn't break for an end host;
however, the 4.4BSD TCP code checks the outgoing interface MTU
directly to determine the size of the packets, if the route entry does not
have an mtu (check tcp_input.c, tcp_mss()). This means that either TCP
is patched, or fragmentation will happen.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMvlb8b0pBjh2h1kFAQH4VgP/c6m7K8UqUPbzZImhsUjZj6wRmphKsldP
0TcbhC9Rf7CrZcrG7spjCecM2I+c3hxG04G8r6XeXR9ajY7KqtphUxz+5xDH+B/N
/8U44zoNEyVQZbxvzeXSe/U93AIq+sgDcsy1BmGDXMq2MxYTefYIU1QOgTGIv7JT
aSG04Yy2vS8=
=l0al
-----END PGP SIGNATURE-----
From owner-ipsec Thu Feb 6 10:56:53 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11964 for ipsec-outgoing; Thu, 6 Feb 1997 10:53:12 -0500 (EST)
Message-Id: <3.0.32.19970206095433.00b2f100@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 06 Feb 1997 09:54:38 -0500
To: "Niels Ferguson" <niels@DigiCash.com>, <ipsec@tis.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Q: test vectors for HMAC-SHA-1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote:
>I have implemented HMAC using SHA-1 as hash function. I have found test
>vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test
>vectors? If not, I would be happy to help create them.
>
No one has actual tests.. But what a lot of us have done is run our HMAC SHA
routines over the same data that was included in the HMAC MD5 draft.
We've compared our results and most seem to match.
I'll post the results when I get back to my office.
-Rob Adams
Cisco Systems
Santa Cruz, CA 95060
From owner-ipsec Thu Feb 6 12:26:18 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA12471 for ipsec-outgoing; Thu, 6 Feb 1997 12:25:14 -0500 (EST)
Message-Id: <01BC1429.F844BBC0@localhost>
From: Edward Russell <erussell@ftp.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
Date: Thu, 6 Feb 1997 12:33:16 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote:
>I have implemented HMAC using SHA-1 as hash function. I have found test
>vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test
>vectors? If not, I would be happy to help create them.
>
At the interoperability event in Dallas, it appears that
the BSAFE SHA is incompatible with the CYLINK SHA.
In addition it appears that
BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman
We compiled our (FTP Software) implementation of ISAKMP with either
BSAFE or CYLINK libraries and tested against different vendors and
got compatiblity or incompatibility based on which library we compiled
with.
That being said, I wrote a test program for both SHA and HMAC SHA
and compiled it with CYLINK and then with BSAFE. The results are
posted below.
HMAC KEY =
0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b
HMAC KEY LENGTH = 16
DATA "Hi There"
DATA LENGTH = 8
DIGESTs:
BSAFE HMAC SHA:
67 5B 0B 3A 1B 4D DF 4E 12 48 72 DA 6C 2F 63 2B FE D9 57 E9
CYLINK HMAC SHA:
BC F6 85 57 4C B8 AA B1 B6 42 CE CB F3 89 A0 79 F6 48 84 F3
BSAFE SHA:
4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
CYLINK SHA:
4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
Edward Russell
FTP Software
erussell@ftp.com
From owner-ipsec Thu Feb 6 13:18:22 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA12807 for ipsec-outgoing; Thu, 6 Feb 1997 13:17:42 -0500 (EST)
Message-Id: <3.0.32.19970206121837.00b2ad80@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 06 Feb 1997 12:18:48 -0500
To: Edward Russell <erussell@ftp.com>, "'ipsec@tis.com'" <ipsec@tis.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 12:33 PM 2/6/97 -0500, Edward Russell wrote:
>
>At the interoperability event in Dallas, it appears that
>the BSAFE SHA is incompatible with the CYLINK SHA.
BTW, I will be working hard to get the results out from this week late next
week or early the following week.
But based on what we accomplished this week, and the AIAG's need for IPsec
with Oakley/ISAKMP, we are working on setting up a larger interoperability
March 24-27. I am working on facilities (larger than these) and expect to
have the information by the end of next week.
March 24th was chosen to allow time to recover and then attend IETF (plus
me to get the report done to present at IETF).
Tentatively there will be one more week, most likely the 1st week in May
(before INTEROP).
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Thu Feb 6 13:22:48 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA12870 for ipsec-outgoing; Thu, 6 Feb 1997 13:22:45 -0500 (EST)
X-Sender: mike.sabin@postoffice.worldnet.att.net
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Edward Russell <erussell@ftp.com>, "'ipsec@tis.com'" <ipsec@tis.com>
From: Michael Sabin <mike.sabin@worldnet.att.net>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
Date: Thu, 6 Feb 1997 18:26:36 +0000
Message-ID: <19970206182634.AAA26435@LOCALNAME>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 05:33 PM 2/6/97 +0000, Edward Russell wrote:
>
>At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote:
>>I have implemented HMAC using SHA-1 as hash function. I have found test
>>vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test
>>vectors? If not, I would be happy to help create them.
>>
>
>At the interoperability event in Dallas, it appears that
>the BSAFE SHA is incompatible with the CYLINK SHA.
>
>In addition it appears that
>BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman
>
>We compiled our (FTP Software) implementation of ISAKMP with either
>BSAFE or CYLINK libraries and tested against different vendors and
>got compatiblity or incompatibility based on which library we compiled
>with.
>
>That being said, I wrote a test program for both SHA and HMAC SHA
>and compiled it with CYLINK and then with BSAFE. The results are
>posted below.
>
>HMAC KEY =
>0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b,
0x0b, 0x0b, 0x0b, 0x0b
>
>HMAC KEY LENGTH = 16
>DATA "Hi There"
>DATA LENGTH = 8
>
>DIGESTs:
>
>BSAFE HMAC SHA:
>67 5B 0B 3A 1B 4D DF 4E 12 48 72 DA 6C 2F 63 2B FE D9 57 E9
>
>CYLINK HMAC SHA:
>BC F6 85 57 4C B8 AA B1 B6 42 CE CB F3 89 A0 79 F6 48 84 F3
>
>
>BSAFE SHA:
>4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
>
>CYLINK SHA:
>4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
I ran this data through my own implementation of SHA and SHA-HMAC, based on
my own interpretation of the standards. Here are my results:
SHA
4b 3a ed 5f 9f e4 01 59 b4 99 53 6f b8 a1 0c df 3b c6 2b 4c
HMAC-SHA
67 5b 0b 3a 1b 4d df 4e 12 48 72 da 6c 2f 63 2b fe d9 57 e9
My results agree with the BSAFE results. I have also tested my SHA
implementation against the AH-SHA implementation in the NRL IPSEC code and
gotten agreement.
mike
From owner-ipsec Thu Feb 6 13:50:16 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13010 for ipsec-outgoing; Thu, 6 Feb 1997 13:49:13 -0500 (EST)
Message-Id: <97Feb6.135047est.30800-3@janus.border.com>
To: Edward Russell <erussell@ftp.com>
cc: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News
References: <01BC1429.F844BBC0@localhost>
In-reply-to: Your message of "Thu, 06 Feb 1997 12:33:16 -0500".
<01BC1429.F844BBC0@localhost>
From: "C. Harald Koch" <chk@border.com>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 813 2054
X-uri: <URL:http://www.eng.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Date: Thu, 6 Feb 1997 13:53:02 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <01BC1429.F844BBC0@localhost>, Edward Russell writes:
>
> BSAFE SHA:
> 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
>
> CYLINK SHA:
> 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
I've seen this before. There are two different representations of hash codes
floating around; "big endian" and "little endian". Note that the above
hashes are identical with the *bytes* listed in the opposite order.
I couldn't tell you which one is 'correct' though :-)
--
C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd.
chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6
+1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change."
+1 416 813 2001 (fax) | -Karen Murphy <karenm@descartes.com>
From owner-ipsec Thu Feb 6 14:21:02 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13207 for ipsec-outgoing; Thu, 6 Feb 1997 14:20:44 -0500 (EST)
From: Robert Glenn <glenn@snad.ncsl.nist.gov>
Date: Thu, 6 Feb 1997 14:24:13 -0500 (EST)
Message-Id: <199702061924.OAA03287@sloth.ncsl.nist.gov>
To: erussell@ftp.com
Subject: RE: test vectors for HMAC-SHA-1 - Test Data
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I just ran the exact same tests you described below against the NIST
reference implementation of SHA-1. The results match the BSAFE SHA
and BSAFE HMAC-SHA results.
NIST SHA-1 Alg. Results:
HMAC-SHA 67 5b 0b 3a 1b 4d df 4e 12 48 72 da 6c 2f 63 2b fe d9 57 e9
SHA 4b 3a ed 5f 9f e4 01 59 b4 99 53 6f b8 a1 0c df 3b c6 2b 4c
Rob G.
In article <01BC1429.F844BBC0@localhost>, Edward Russell <erussell@ftp.com> writes:
>
>At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote:
>>I have implemented HMAC using SHA-1 as hash function. I have found test
>>vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test
>>vectors? If not, I would be happy to help create them.
>>
>
>At the interoperability event in Dallas, it appears that
>the BSAFE SHA is incompatible with the CYLINK SHA.
>
>In addition it appears that
>BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman
>
>We compiled our (FTP Software) implementation of ISAKMP with either
>BSAFE or CYLINK libraries and tested against different vendors and
>got compatiblity or incompatibility based on which library we compiled
>with.
>
>That being said, I wrote a test program for both SHA and HMAC SHA
>and compiled it with CYLINK and then with BSAFE. The results are
>posted below.
>
>HMAC KEY =
>0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b
>
>HMAC KEY LENGTH = 16
>DATA "Hi There"
>DATA LENGTH = 8
>
>DIGESTs:
>
>BSAFE HMAC SHA:
>67 5B 0B 3A 1B 4D DF 4E 12 48 72 DA 6C 2F 63 2B FE D9 57 E9
>
>CYLINK HMAC SHA:
>BC F6 85 57 4C B8 AA B1 B6 42 CE CB F3 89 A0 79 F6 48 84 F3
>
>
>BSAFE SHA:
>4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
>
>CYLINK SHA:
>4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
>
>
>Edward Russell
>FTP Software
>erussell@ftp.com
>
From owner-ipsec Thu Feb 6 14:37:20 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA13303 for ipsec-outgoing; Thu, 6 Feb 1997 14:37:14 -0500 (EST)
Message-Id: <3.0.16.19970206142958.1e4fcd3a@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Thu, 06 Feb 1997 14:39:06 -0500
To: ipsec@tis.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Excuse me but in fairness I would like to point out that I believe Cylink
has been made aware of this issue -- I for one don't want to grumble, I
want to interoperate...
If anyone from Cylink sees this and doesn't think they have been contacted,
consider yourself pinged...
>X-Sender: mike.sabin@postoffice.worldnet.att.net
>To: Edward Russell <erussell@ftp.com>, "'ipsec@tis.com'" <ipsec@tis.com>
>From: Michael Sabin <mike.sabin@worldnet.att.net>
>Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
>Date: Thu, 6 Feb 1997 18:26:36 +0000
>Sender: owner-ipsec@ex.tis.com
>
>At 05:33 PM 2/6/97 +0000, Edward Russell wrote:
>>
>>At 04:27 PM 2/3/97 +0100, Niels Ferguson wrote:
>>>I have implemented HMAC using SHA-1 as hash function. I have found test
>>>vectors for HMAC based on MD5, but not for SHA-1. Does anybody have test
>>>vectors? If not, I would be happy to help create them.
>>>
>>
>>At the interoperability event in Dallas, it appears that
>>the BSAFE SHA is incompatible with the CYLINK SHA.
>>
>>In addition it appears that
>>BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman
>>
>>We compiled our (FTP Software) implementation of ISAKMP with either
>>BSAFE or CYLINK libraries and tested against different vendors and
>>got compatiblity or incompatibility based on which library we compiled
>>with.
>>
>>That being said, I wrote a test program for both SHA and HMAC SHA
>>and compiled it with CYLINK and then with BSAFE. The results are
>>posted below.
>>
>>HMAC KEY =
>>0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b,
>0x0b, 0x0b, 0x0b, 0x0b
>>
>>HMAC KEY LENGTH = 16
>>DATA "Hi There"
>>DATA LENGTH = 8
>>
>>DIGESTs:
>>
>>BSAFE HMAC SHA:
>>67 5B 0B 3A 1B 4D DF 4E 12 48 72 DA 6C 2F 63 2B FE D9 57 E9
>>
>>CYLINK HMAC SHA:
>>BC F6 85 57 4C B8 AA B1 B6 42 CE CB F3 89 A0 79 F6 48 84 F3
>>
>>
>>BSAFE SHA:
>>4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
>>
>>CYLINK SHA:
>>4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
>
>I ran this data through my own implementation of SHA and SHA-HMAC, based on
>my own interpretation of the standards. Here are my results:
>
>SHA
>4b 3a ed 5f 9f e4 01 59 b4 99 53 6f b8 a1 0c df 3b c6 2b 4c
>
>HMAC-SHA
>67 5b 0b 3a 1b 4d df 4e 12 48 72 da 6c 2f 63 2b fe d9 57 e9
>
>My results agree with the BSAFE results. I have also tested my SHA
>implementation against the AH-SHA implementation in the NRL IPSEC code and
>gotten agreement.
>
>mike
>
>
>
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
From owner-ipsec Thu Feb 6 15:17:27 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13624 for ipsec-outgoing; Thu, 6 Feb 1997 15:17:13 -0500 (EST)
Message-Id: <3.0.32.19970206141123.00b0e840@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 06 Feb 1997 14:18:51 -0500
To: Rodney Thayer <rodney@sabletech.com>, ipsec@tis.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 02:39 PM 2/6/97 -0500, Rodney Thayer wrote:
>I for one don't want to grumble, I
>want to interoperate...
Which is one of the reasons for running interoperablity sessions in person.
More can be done in a reasonable time frame.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Thu Feb 6 15:17:27 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13618 for ipsec-outgoing; Thu, 6 Feb 1997 15:16:44 -0500 (EST)
Message-Id: <01BC1441.F2502660@localhost>
From: Edward Russell <erussell@ftp.com>
To: "'chk@border.com'" <chk@border.com>,
"'Edward Russell'"
<erussell@ftp.com>
Cc: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
Date: Thu, 6 Feb 1997 15:03:26 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>C. Harald Koch (chk@border.com) said on 2/6/97 at 1:53 PM
>In message <01BC1429.F844BBC0@localhost>, Edward Russell writes:
>>
>> BSAFE SHA:
>> 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
>>
>> CYLINK SHA:
>> 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
>
>I've seen this before. There are two different representations of hash codes
>floating around; "big endian" and "little endian". Note that the above
>hashes are identical with the *bytes* listed in the opposite order.
>
>I couldn't tell you which one is 'correct' though :-)
>
>--
O.K., O.K., C. Harald Koch gets the "Mirror Image" award for spotting what
should have been obvious to us. But understand, we're running on only a
handful of hours of sleep trying to get us all to interoperate. :-) I don't think
I would characterize this as an "endian" problem though as that as more
to do with byte arrangement within shorts and longs - I doubt the problem
is caused by one platform compiled with the wrong byte order defined.
This is good news in that we won't need cryptographers and mathematicians
to analyze or hand perform the correct results. We just need a decision on
which way is to be deemed the "correct" way. I have a coin...
We'll try to establish if the same is true at the end of a Diffie Hellman exchange,
but that will be a little trickier.
From owner-ipsec Thu Feb 6 15:36:07 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13761 for ipsec-outgoing; Thu, 6 Feb 1997 15:35:43 -0500 (EST)
Message-Id: <01BC1444.9CEF6E80@localhost>
From: Edward Russell <erussell@ftp.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
Date: Thu, 6 Feb 1997 15:44:02 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>In message <01BC1429.F844BBC0@localhost>, Edward Russell writes:
>
> <Reversed SHA Bytes discussion deleted...>
>
>We'll try to establish if the same is true at the end of a Diffie Hellman exchange,
>but that will be a little trickier.
>
It would appear the Diffie Hellman discrepancy between Cylink and Bsafe is
not just a simple reversal. The cryptographers will have to tackle that one.
From owner-ipsec Thu Feb 6 15:49:47 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13876 for ipsec-outgoing; Thu, 6 Feb 1997 15:49:42 -0500 (EST)
From: pau@watson.ibm.com
Date: Thu, 6 Feb 1997 15:40:06 -0500
Message-Id: <9702062040.AA22906@secpwr.watson.ibm.com>
To: ipsec@tis.com
Subject: HMAC-SHA test results
Cc: niels@DigiCash.com, glenn@snad.ncsl.nist.gov, hugo@watson.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Md5: PzrXJjenso3/eEQWKlwM6g==
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Hellow,
I and Neils Anderson used the following 3 test vectors to test HMAC-SHA
(SHA1) and get the same results. Hugo and I would like to put them in the
upcoming HMAC RFC. Though it may be late for RFC, please check the results
any way because it is always nice to have common test vectors.
The test vectors are the same as those in HMAC-MD5 draft; except that
the key lengths in vectors 1 and 3 are expanded to 20 bytes.
My code uses big-endian conversion as specified in FIPS 180-1.
Thank you.
Pau-Chen
-----------------------------------------------------------------------------
Set 1 :
key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
key_len = 20 bytes
data = "Hi There" (Trailing '\0' not included in test)
data_len = 8 bytes
digest = 0xb617318655057264e28bc0b6fb378c8ef146be00
Set 2:
key = "Jefe" (Trailing '\0' not included in test)
data = "what do ya want for nothing?"
data_len = 28 bytes
digest = 0xeffcdf6ae5eb2fa2d27416d5f184df9c259a7c79
Set 3 :
key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
key_len 20 bytes
data = 0xDDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD
data_len = 50 bytes
digest = 0x125d7342b9ac11cd91a39af48aa17b4f63f175d3
-------------------------------------------------------------------------------
From owner-ipsec Thu Feb 6 15:50:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13893 for ipsec-outgoing; Thu, 6 Feb 1997 15:50:42 -0500 (EST)
From: owner-ipsec@ex.tis.com
Date: Thu, 6 Feb 1997 15:55:29 -0500
Message-Id: <9702062055.AA23448@secpwr.watson.ibm.com>
To: ipsec@tis.com, niels@DigiCash.com
Subject: Re: HMAC-SHA test results
Cc: glenn@snad.ncsl.nist.gov, hugo@watson.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Md5: DkvKuCCbEH1zBC/r1t9HiA==
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> From pau@secpwr.watson.ibm.com Thu Feb 6 15:40:07 1997
> From: pau@secpwr.watson.ibm.com
> Date: Thu, 6 Feb 1997 15:40:06 -0500
> Message-Id: <9702062040.AA22906@secpwr.watson.ibm.com>
> To: ipsec@tis.com
> Subject: HMAC-SHA test results
> Cc: niels@DigiCash.com, glenn@snad.ncsl.nist.gov, hugo@watson.ibm.com
> Mime-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> Content-Md5: PzrXJjenso3/eEQWKlwM6g==
> Content-Length: 1640
> Status: RO
>
> Hellow,
>
> I and Neils Anderson used the following 3 test vectors to test HMAC-SHA
Oops! I meant Niels Ferguson. Sorry, Niels.
Pau-Chen
> (SHA1) and get the same results. Hugo and I would like to put them in the
> upcoming HMAC RFC. Though it may be late for RFC, please check the results
> any way because it is always nice to have common test vectors.
>
>
>
>
From owner-ipsec Thu Feb 6 15:54:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13942 for ipsec-outgoing; Thu, 6 Feb 1997 15:54:42 -0500 (EST)
From: Dan.McDonald@eng.sun.com (Dan McDonald)
Message-Id: <199702062058.MAA22972@kebe.eng.sun.com>
Subject: Re: Path MTU Discovery
To: angelos@aurora.cis.upenn.edu (Angelos D. Keromytis)
Date: Thu, 6 Feb 1997 12:58:32 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <9702060420.AA79343@aurora.cis.upenn.edu> from "Angelos D. Keromytis" at Feb 5, 97 11:20:02 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Path-mtu discovery breaks in the presence of multiple IPsec
> encapsulation(*) (it might even break in the presence of ONE
> intermediate encapsulating entity).
Are you sure it totally breaks? It doesn't work as well, for sure, but I
don't see total breakage.
An encrypting router often has a "tunnel interface" that'll have properties
like:
tun0: 10.69.0.0/16 --> 10.9.1.25
Interfaces have MTU associated with them. A combination of PathMTU discovery
from the router to the tunnel endpoint, and knowledge of the algorithms used,
etc. can give this tunnel interface a reasonable MTU estimate. Reasonable
enough that an MTU too large message for datagrams bound for 10.69.0.0/16 can
be sent.
BTW, by PathMTU discovery to the endpoint, I mean that the router (because it
is originating packets now, from its address to the tunnel endpoint) has a
cache-entry/host-route/whatever for the tunnel endpoint. That entry can be a
repository for intermediate Path MTU information.
Incoming IP data Outgoing forward result
-- src 10.8.20.69 --> ROUTER (ifaddr) -> src 10.10.20.20
dst 10.69.21.12 <-(10.8.20.2) dst 10.9.1.25
proto=TCP (10.10.20.20)-> proto=ESP (with IP inside)
Figure 1: Demonstration of "originating packets".
Now let's say there's ANOTHER layer of encryption between the router above
and its tunnel endpoint of 10.9.1.25. THAT router may send an ICMP toobig to
OUR router (10.10.20.20), saying the path to 10.9.1.25 has a smaller MTU than
what I think. Now, because of the multiple nestings of IP, I can't percolate
that ICMP toobig all the way back to the originator, but it will eventually
percolate back.
It will take N dropped messages for N layers of tunelling. So if there's an
intermediate node's worth of encapsulation, the first message will be
dropped, then when the first subsequent message hits the cranked-down tunnel
endpoint, THEN a toobig can be sent back.
Using the above figure 1 as an example, if a router says the path MTU to
10.9.1.25 is less, then the router's tunnel interface will ratchet down its
mtu. The original packet from the source host 10.8.20.69 will just be
dropped, because the router doesn't really want to go digging deep for the
originator.
The next IP datagram from 10.8.20.69 will generate an ICMP toobig from the
router, because it now has the ratcheted-down MTU on its tunneling interface,
and so with one dropped datagram, the node 10.8.20.69 knows the whole path
MTU.
If messages drop occasionally, that's fine. This is IP. Sure it's a
performance hit, but security and performance are sometimes (note my choice
of words) opposites in a tradeoff.
I don't think your solution about keeping SPIs helps a whole lot here. It
seems to be unnecessary implementation cruft. If there's any flaws in what
I've said, however, I'd certainly like to know.
> This still doesn't address the problem of the original TCP mtu (the
> mtu of the outgoing interface could be less than that reported on the
> kernel structure, depending on whether a packet will be IPsec'ed or
> not). But i doubt we can mandate a solution for that.
As for original TCP MSS, which needs to be set, IP must be able to send a
hint to the particular TCP session indicating that IP security will lower the
effective MSS for this TCP connection. I say it must only alter a single TCP
session because IP security should use per-endpoint security properties where
possible. See Bellovin's USENIX Security '96 conference paper for details on
why. See draft-mcdonald-simple-ipsec-api-00.txt for how an application may
exploit this.
> Also, there's the case of whether we accept as valid ICMPs from anyone
> in between (which means anyone) or just two encapsulating entities
> (e.g. two tunneling firewalls). The network-correct approach is
> anyone; the security correct is next enc entity.
Good point, and it applies to ICMP messages of all shapes, sizes, and
flavors. It's possible an intermediate router could send an ICMP with AH on
it, that way I have reasonable assurance it came from a router with that IP
address.
> (*) Steve Kent replied that it shouldn't break for an end host;
He is right.
> however, the 4.4BSD TCP code checks the outgoing interface MTU
> directly to determine the size of the packets, if the route entry does not
> have an mtu (check tcp_input.c, tcp_mss()). This means that either TCP
> is patched, or fragmentation will happen.
Stock 4.4 is broken w.r.t. trying to perform Path MTU discovery. FreeBSD has
one solution for doing this with IPv4. The NRL IPv6 code has another
solution that it implements on the IPv6 side of things.
Dan
From owner-ipsec Thu Feb 6 16:11:13 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14039 for ipsec-outgoing; Thu, 6 Feb 1997 16:10:59 -0500 (EST)
Message-Id: <s2f9e721.084@novell.com>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 06 Feb 1997 14:13:27 -0700
From: John Kennedy <JKENNEDY@novell.com>
To: chk@border.com, erussell@ftp.com
Cc: ipsec@tis.com
Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News
-Reply
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I also ran the "Hi There" message through a SHA-1 utility I developed
independently and got the same answer that BSAFE gives. As far as
the "endian-ness" convention goes, the BSAFE answer is compliant with
the test vectors given in the FIPS standard. Thus, I would contend that
the BSAFE answer is the "correct" one.
I also suspect this representation issue has something to do with the
Diffie-Hellman compatibility problem.
-John Kennedy
NOVELL, Inc.
>>> "C. Harald Koch" <chk@border.com> 02/06/97 11:53am >>>
In message <01BC1429.F844BBC0@localhost>, Edward Russell writes:
>
> BSAFE SHA:
> 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
>
> CYLINK SHA:
> 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
I've seen this before. There are two different representations of hash
codes
floating around; "big endian" and "little endian". Note that the above
hashes are identical with the *bytes* listed in the opposite order.
I couldn't tell you which one is 'correct' though :-)
--
C. Harald Koch | Senior System Developer, Secure Computing
Canada Ltd.
chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J
1V6
+1 416 813 2054 (voice) | "Madness takes its toll. Please have exact
change."
+1 416 813 2001 (fax) | -Karen Murphy
<karenm@descartes.com>
Received: by provo.mx.relay
with Novell_GroupWise; Thu, 06 Feb 1997 13:03:22 -0700
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13010 for ipsec-outgoing; Thu, 6 Feb 1997 13:49:13 -0500 (EST)
Message-Id: <97Feb6.135047est.30800-3@janus.border.com>
References: <01BC1429.F844BBC0@localhost>
In-reply-to: Your message of "Thu, 06 Feb 1997 12:33:16 -0500".
<01BC1429.F844BBC0@localhost>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 813 2054
X-uri: <URL:http://www.eng.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Date: Thu, 06 Feb 1997 11:53:02 -0700
From: "C. Harald Koch" <chk@border.com>
To: erussell@ftp.com
Cc: ipsec@tis.com
Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News
In message <01BC1429.F844BBC0@localhost>, Edward Russell writes:
>
> BSAFE SHA:
> 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
>
> CYLINK SHA:
> 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
I've seen this before. There are two different representations of hash codes
floating around; "big endian" and "little endian". Note that the above
hashes are identical with the *bytes* listed in the opposite order.
I couldn't tell you which one is 'correct' though :-)
--
C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd.
chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6
+1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change."
+1 416 813 2001 (fax) | -Karen Murphy <karenm@descartes.com>
From owner-ipsec Thu Feb 6 16:22:35 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14110 for ipsec-outgoing; Thu, 6 Feb 1997 16:21:46 -0500 (EST)
Date: Thu, 6 Feb 1997 15:17:55 -0600 (CST)
From: Tom Markham <markham@sctc.com>
Message-Id: <199702062117.PAA23596@jasmin.sctc.com>
To: ipsec@tis.com
Subject: RE: test vectors for HMAC-SHA-1
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> O.K., O.K., C. Harald Koch gets the "Mirror Image" award for spotting what
> should have been obvious to us.
I would suggest that keys be picked which will identify problems with
byte ordering in the keys. The key below is the same for big endian
and little endian. Thus, the Cylink results are correct if you reverse the
byte ordering of the key and results.
>HMAC KEY =
>0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b,
0x0b, 0x0b, 0x0b, 0x0b
I suggest using a key such as
0x00 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c,
0x0d, 0x0e, 0x0f
I've been bit by this dog before,
Tom Markham
From owner-ipsec Thu Feb 6 16:37:39 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14181 for ipsec-outgoing; Thu, 6 Feb 1997 16:35:45 -0500 (EST)
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970206212941Z-9596@bwdldb.ott.bnr.ca>
From: Greg Carter <carterg@entrust.com>
To: "'chk%border.com'" <chk@border.com>,
"'erussell@ftp.com'"
<erussell@ftp.com>
Cc: "'ipsec%tis.com'" <ipsec@tis.com>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
Date: Thu, 6 Feb 1997 16:29:41 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
The string and digest are taken from FIPS PUB 180-1.
Our code comes up with same as BSAFE... and conforms to the test vectors
give here...
// Test vectors
static const char k_testString[] = // Must be declared char for UNIX
compiler
"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq";
static const BYTE k_correctDigest[SHA_DIGEST_SIZE] = {
0x84, 0x98, 0x3E, 0x44, 0x1C, 0x3B, 0xD2, 0x6E, 0xBA, 0xAE,
0x4A, 0xA1, 0xF9, 0x51, 0x29, 0xE5, 0xE5, 0x46, 0x70, 0xF1
};
----
Greg Carter
Entrust Technologies
carterg@entrust.com
>
>O.K., O.K., C. Harald Koch gets the "Mirror Image" award for spotting what
>should have been obvious to us. But understand, we're running on only a
>handful of hours of sleep trying to get us all to interoperate. :-) I don't
>think
>I would characterize this as an "endian" problem though as that as more
>to do with byte arrangement within shorts and longs - I doubt the problem
>is caused by one platform compiled with the wrong byte order defined.
>
>This is good news in that we won't need cryptographers and mathematicians
>to analyze or hand perform the correct results. We just need a decision on
>which way is to be deemed the "correct" way. I have a coin...
>
>We'll try to establish if the same is true at the end of a Diffie Hellman
>exchange,
>but that will be a little trickier.
>
>
>
From owner-ipsec Thu Feb 6 17:05:58 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14325 for ipsec-outgoing; Thu, 6 Feb 1997 17:05:45 -0500 (EST)
Message-Id: <97Feb6.170648est.30818-3@janus.border.com>
To: Edward Russell <erussell@ftp.com>
cc: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News
References: <01BC1441.F2502660@localhost>
In-reply-to: erussell's message of "Thu, 06 Feb 1997 15:03:26 -0500".
<01BC1441.F2502660@localhost>
From: "C. Harald Koch" <chk@border.com>
Organization: Secure Computing Canada Ltd.
Phone: +1 416 813 2054
X-uri: <URL:http://www.eng.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Date: Thu, 6 Feb 1997 17:08:58 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <01BC1441.F2502660@localhost>, Edward Russell writes:
>
> O.K., O.K., C. Harald Koch gets the "Mirror Image" award for spotting what
> should have been obvious to us. But understand, we're running on only a
> handful of hours of sleep trying to get us all to interoperate. :-) I don't think
> I would characterize this as an "endian" problem though as that as more
> to do with byte arrangement within shorts and longs - I doubt the problem
> is caused by one platform compiled with the wrong byte order defined.
Thanks for the award :-)
I agree that it's not strictly an endian problem. I first discovered it when
comparing the results for some public-domain MD5 code between a SPARC
machine (big-endian) and an Intel machine (little-endian), and so the
problem has been tagged "endian" in my brain ever since.
> We'll try to establish if the same is true at the end of a Diffie Hellman exchange,
> but that will be a little trickier.
I'm crossing my fingers...
--
C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd.
chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6
+1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change."
+1 416 813 2001 (fax) | -Karen Murphy <karenm@descartes.com>
From owner-ipsec Thu Feb 6 17:19:24 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA14487 for ipsec-outgoing; Thu, 6 Feb 1997 17:19:15 -0500 (EST)
Message-Id: <s2f9f753.068@novell.com>
X-Mailer: Novell GroupWise 4.1
Date: Thu, 06 Feb 1997 15:22:40 -0700
From: John Kennedy <JKENNEDY@novell.com>
To: erussell@ftp.com, ipsec@tis.com
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
-Reply
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Oh, I don't think we need to call out the cryptographic "Big Guns" yet. I'm
willing to bet the problem is with the output, transfer, and subsequent
input at the receiving end of the public numbers. I doubt it is a
fundamental problem with the underlying big integer arithmetic libraries.
More like one library interpreting the numbers LSByte first and the other
one MSByte first. If each library was not consistent in its interpretation
of the data, the math wouldn't work for two implementations using the
same library.
-John Kennedy
NOVELL, Inc.
>>> Edward Russell <erussell@ftp.com> 02/06/97 01:44pm >>>
>In message <01BC1429.F844BBC0@localhost>, Edward Russell writes:
>
> <Reversed SHA Bytes discussion deleted...>
>
>We'll try to establish if the same is true at the end of a Diffie Hellman
exchange,
>but that will be a little trickier.
>
It would appear the Diffie Hellman discrepancy between Cylink and
Bsafe is
not just a simple reversal. The cryptographers will have to tackle that
one.
Received: by provo.mx.relay
with Novell_GroupWise; Thu, 06 Feb 1997 14:39:19 -0700
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13761 for ipsec-outgoing; Thu, 6 Feb 1997 15:35:43 -0500 (EST)
Message-Id: <01BC1444.9CEF6E80@localhost>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Date: Thu, 06 Feb 1997 13:44:02 -0700
From: Edward Russell <erussell@ftp.com>
To: ipsec@tis.com
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
>In message <01BC1429.F844BBC0@localhost>, Edward Russell writes:
>
> <Reversed SHA Bytes discussion deleted...>
>
>We'll try to establish if the same is true at the end of a Diffie Hellman exchange,
>but that will be a little trickier.
>
It would appear the Diffie Hellman discrepancy between Cylink and Bsafe is
not just a simple reversal. The cryptographers will have to tackle that one.
From owner-ipsec Thu Feb 6 18:46:40 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14985 for ipsec-outgoing; Thu, 6 Feb 1997 18:46:17 -0500 (EST)
X-Sender: mike.sabin@postoffice.worldnet.att.net
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: <ipsec@tis.com>
From: Michael Sabin <mike.sabin@worldnet.att.net>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
Date: Thu, 6 Feb 1997 23:50:04 +0000
Message-ID: <19970206235002.AAA26138@LOCALNAME>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I figured this thread was a good chance to weigh in once again with the
suggestion that every ESP and AH draft include an example datagram that
nails down these pesky details about byte ordering, etc. That'll go a long
way to ensuring that a spec is unambiguously interpreted.
Below is a copy of a previous posting. Jim Hughes responded that the
upcoming draft of the combined DES-CBC-HMAC-replay draft would include such
an example.
mike
>Date: Fri, 20 Dec 1996 20:44:23
>To: hughes@nsco.network.com
>From: Michael Sabin <mike.sabin@worldnet.att.net>
>Subject: Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention
Security Transform to Proposed Standard
>Cc: iesg@ietf.org, ipsec@tis.com
>
>I went through the exercise of coding up an example datagram as per the
>draft. My goal was to chase down details about byte/bit orderings in and
>out of the DES, MD5, HMAC, and replay-count operations. I felt that
>most of the details were resolvable using the description in the draft
>and the cited references. However, in a few cases I felt I was
>guessing.
>
>One suggestion I have is that the draft include an example datagram,
>before and after encryption. This will unambiguously nail down all
>details about bit/byte ordering. Note that the individual specs for DES
>[FIPS-41], MD5 [RFC-1321], and HMAC [Krawczyk] include such examples.
>
>Below is the example I came up with. (If anybody is inclined to verify
>the example, I'd sure appreciate it. :-) ) Items marked with (*) are
>places where I felt I was guessing about byte/bit orderings; some
>clarification about these may be desirable.
>
>mike
>---------------------------------
>
>EXAMPLE
>
>Suppose the "master key" K from the key managment layer is:
>
> K =
> 01 23 45 67 89 ab cd ef 23 45 67 89 ab cd ef 01
> 45 67 89 ab cd ef 01 23 67 89 ab cd ef 01 23 45
> 89 ab cd ef 01 23 45 67 ab cd ef 01 23 45 67 89
> cd ef 01 23 45 67 89 ab ef 01 23 45 67 89 ab cd
>
>K consists of 512 octets. Octet 0 is 0x01, octet 1 is 0x23, octet 511
>is 0xcd.
>
>K is used to compute the following quantities:
>
> DES_Key_I = a4 34 41 46 f6 dc 8b 1d
> IV_Key_I = c8 44 86 79 51 a6 83 cc
> HMAC_Key_I = 98 b8 d1 f7 64 f1 e9 72 0c 0c e7 c6 dd 4f 1c 8d
> RP_Key_I = d3 1f e3 42
>
>Each of these quantities is a sequence of octets numbered 0, 1, 2, ...,
>with octet 0 listed first.
>
>Here is an example datagram prior to encryption, including the HMAC:
>
> 1f 2e 3d 4c // SPI
> d3 1f e3 42 // replay count
> 4e 6f 77 20 // payload
> 69 73 20 74 // payload
> 68 65 20 74 // payload
> 69 6d 65 20 // payload
> 66 6f 72 20 // payload
> 61 6c 6c 20 // payload
> f6 0f 02 06 // padding, pad length, payload type
> 8a 85 2a 16 // HMAC
> 2a 6a 0d de // HMAC
> 30 b1 e5 fa // HMAC
> a6 e1 fc c1 // HMAC
>
>(*) The initial value of the replay count, from RP_Key_I, is:
>
> initial replay count = 0xd31fe342 = 3,542,082,370
>
>(*) When computing the HMAC, the octets of the datagram are digested in
>network order: 0x1f, 0x2e, 0x3d, ..., 0x0f, 0x02, 0x06.
>
>The HMAC key, from HMAC_Key_I, is [98 b8 d1 f7 64 f1 e9 72 0c 0c e7 c6
>dd 4f 1c 8d]; 0x98 is octet 0, and 0x8d is octet 15.
>
>(*) The output of the HMAC calculation is inserted into the datagram in
>network order: 0x8a is octet 0, and 0xc1 is octet 15.
>
>
>Here is the datagram after encryption:
>
> 1f 2e 3d 4c // SPI
> ff 30 bf 0a // replay count
> 46 bd b7 94 // payload
> 33 ff 84 0e // payload
> d9 aa 76 7a // payload
> cb 20 da d8 // payload
> 87 8e bf 0f // payload
> 27 70 2c 99 // payload
> 2f e3 ce a2 // padding, pad length, payload type
> b1 cc 9a 6e // HMAC
> 34 b8 50 3a // HMAC
> 51 92 be 7f // HMAC
> e0 cb ba 05 // HMAC
>
>(*) The DES encryption key, prior to parity correction, is [a4 34 41
>46 f6 dc 8b 1d], from DES_Key_I.
>
>(*) The IV is [c8 44 86 79 51 a6 83 cc], from IV_Key_I.
>
>(*) The first input block to the DES-CBC encryption is [d3 1f e3 42 4e
>6f 77 20].
>
From owner-ipsec Fri Feb 7 02:24:50 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA17154 for ipsec-outgoing; Fri, 7 Feb 1997 02:23:17 -0500 (EST)
From: Dan.McDonald@eng.sun.com (Dan McDonald)
Message-Id: <199702070727.XAA24969@kebe.eng.sun.com>
Subject: Re: Path MTU Discovery
To: angelos@aurora.cis.upenn.edu (Angelos D. Keromytis)
Date: Thu, 6 Feb 1997 23:27:27 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <9702070346.AA07074@aurora.cis.upenn.edu> from "Angelos D. Keromytis" at Feb 6, 97 10:46:01 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> >
> >An encrypting router often has a "tunnel interface" that'll have properties
> >like:
> >
> > tun0: 10.69.0.0/16 --> 10.9.1.25
>
> Not necessarilly. Virtual interfaces might not be used, or you might
> have more than one SPIs using the same interface. Per SPI(-chain) MTUs
> need to be kept. If you have a router that behaves as you describe,
> then you don't need any other provision.
Hmmm. In a router-to-host tunneling case, you MIGHT be right.
Let's consider one other property about router-to-* tunneling. Since the
router is the _originator_ of the outermost packet, it does not need to obey
the inner packet's "Don't fragment" bit. Remember, I'm originating the
packet.
There's one faulty assumption you make below. I'll point it out in a bit.
This may explain why we aren't agreeing here.
> Which is the same as keeping that information on a per-SPI(-chain)
> basis, if you don't use ViFs.
Could you illustrate a non-VIF case? Granted, in the NRL code, there's an
"encrypting route," but even there, I just don't see any of the MTU
problems.
> Another point is that fragmentation checking should be done before any
> IPsec handling takes place (easier and faster).
WRONG FOR OUTBOUND PACKETS!!! This is in clear violation of RFC 1825. Lemme
quote:
>> 3.1 AUTHENTICATION HEADER
<SNIP!>
>> Fragmentation occurs after the Authentication Header processing for
>> outbound packets and prior to Authentication Header processing for
>> inbound packets. The receiver verifies the correctness of the
There actually isn't text in the ESP section, but I'll bet small sums that
either Ran A. or Steve K. will back me up on this one.
If you meant inbound packets, my bad.
> Only if you can associate a packet "flow" with the ICMP message; easy
> to do if you use a ViF for each tunnel.
Any implementors out there not doing this? I can only see this in the
router-to-host tunnel.
> So TCP has to "forsee" whether a packet will go through IPsec, and if
> so what will be the size overhead.
It'll know. Before that SYN or SYN/ACK gets sent, it can consult endpoint
state (socket, pcb, whatever) and make an appropriate guess.
Dan
From owner-ipsec Fri Feb 7 07:27:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA18505 for ipsec-outgoing; Fri, 7 Feb 1997 07:24:50 -0500 (EST)
Message-Id: <9702070347.AA07084@aurora.cis.upenn.edu>
To: Dan.McDonald@eng.sun.com (Dan McDonald)
Cc: ipsec@tis.com
Subject: Re: Path MTU Discovery
Date: Thu, 06 Feb 1997 22:47:21 -0500
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
In message <199702062058.MAA22972@kebe.eng.sun.com>, Dan McDonald writes:
>
>An encrypting router often has a "tunnel interface" that'll have properties
>like:
>
> tun0: 10.69.0.0/16 --> 10.9.1.25
Not necessarilly. Virtual interfaces might not be used, or you might
have more than one SPIs using the same interface. Per SPI(-chain) MTUs
need to be kept. If you have a router that behaves as you describe,
then you don't need any other provision.
>BTW, by PathMTU discovery to the endpoint, I mean that the router (because it
>is originating packets now, from its address to the tunnel endpoint) has a
>cache-entry/host-route/whatever for the tunnel endpoint. That entry can be a
>repository for intermediate Path MTU information.
Which is the same as keeping that information on a per-SPI(-chain)
basis, if you don't use ViFs.
Another point is that fragmentation checking should be done before any
IPsec handling takes place (easier and faster).
>Now let's say there's ANOTHER layer of encryption between the router above
>and its tunnel endpoint of 10.9.1.25. THAT router may send an ICMP toobig to
>OUR router (10.10.20.20), saying the path to 10.9.1.25 has a smaller MTU than
>what I think. Now, because of the multiple nestings of IP, I can't percolate
>that ICMP toobig all the way back to the originator, but it will eventually
>percolate back.
Only if you can associate a packet "flow" with the ICMP message; easy
to do if you use a ViF for each tunnel.
>As for original TCP MSS, which needs to be set, IP must be able to send a
>hint to the particular TCP session indicating that IP security will lower the
>effective MSS for this TCP connection. I say it must only alter a single TCP
>session because IP security should use per-endpoint security properties where
>possible. See Bellovin's USENIX Security '96 conference paper for details on
>why. See draft-mcdonald-simple-ipsec-api-00.txt for how an application may
>exploit this.
Agreed. I just raised this because i'm not sure how many
implementations actually do this.
>Good point, and it applies to ICMP messages of all shapes, sizes, and
>flavors. It's possible an intermediate router could send an ICMP with AH on
>it, that way I have reasonable assurance it came from a router with that IP
>address.
That would mean establishing SPIs with all intermediate routers in
advance (on the fly might be too slow an approach). An then there's
the issue of verifying that the router is actually in the path (and
not some random "router" that established an SPI with us).
>Stock 4.4 is broken w.r.t. trying to perform Path MTU discovery. FreeBSD has
>one solution for doing this with IPv4. The NRL IPv6 code has another
>solution that it implements on the IPv6 side of things.
I was actually refering to initial mss (although i guess the interface
MTU is also used for PathMTU discovery - have to check the code).
So TCP has to "forsee" whether a packet will go through IPsec, and if
so what will be the size overhead.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMvqlyL0pBjh2h1kFAQHsaQP+KIPs/A05ehCPeYAnsy+VcCZCWqSnJSNI
RV7xkSb8parnQ5AyUybzWRB6bfubcqZ4qXEoOLdW8ErfUes0ei6eIgvW08Hs+uBQ
b3VsB0k1isVVzpQG+zxTjP8Jgd7GaqU76zon2OGcXOvoyXu6Fnx5gyJnvanlxu4B
qmAV4ltrPH4=
=Cx6g
-----END PGP SIGNATURE-----
From owner-ipsec Fri Feb 7 07:29:54 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA18596 for ipsec-outgoing; Fri, 7 Feb 1997 07:29:51 -0500 (EST)
Message-Id: <9702070842.AA79320@aurora.cis.upenn.edu>
To: Dan.McDonald@eng.sun.com (Dan McDonald)
Cc: ipsec@tis.com
Subject: Re: Path MTU Discovery
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <5711.855304913.1@dsl.cis.upenn.edu>
Date: Fri, 07 Feb 1997 03:41:53 -0500
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <199702070727.XAA24969@kebe.eng.sun.com>, Dan McDonald writes:
>Let's consider one other property about router-to-* tunneling. Since the
>router is the _originator_ of the outermost packet, it does not need to obey
>the inner packet's "Don't fragment" bit. Remember, I'm originating the
>packet.
Well, wouldn't ignoring the DF bit defeat the original endpoint's
PathMTU ?
>WRONG FOR OUTBOUND PACKETS!!! This is in clear violation of RFC 1825. Lemme
>quote:
>
>>> 3.1 AUTHENTICATION HEADER
>
><SNIP!>
>
>>> Fragmentation occurs after the Authentication Header processing for
>>> outbound packets and prior to Authentication Header processing for
>>> inbound packets. The receiver verifies the correctness of the
>
>There actually isn't text in the ESP section, but I'll bet small sums that
>either Ran A. or Steve K. will back me up on this one.
>
>If you meant inbound packets, my bad.
My phrasing was "fragmentation checking", not fragmentation; what i
mean is that one should check whether a packet, after the overhead
imposed by IPsec, would be fragmented. If so, don't apply the
transforms but drop it and send back an ICMP toobig. Sorry if i was
not clear enough.
>Any implementors out there not doing this? I can only see this in the
>router-to-host tunnel.
JI and me have an implementation that does not use multiple ViFs. SOS
Corp. as well, last i checked. Don't know about others. So, the way
our implementation works is that a ViF is really used as a way
to force packets to go into the IPsec engine uppon receiving
(actually, just the IP-in-IP packets - the rest is handled by
ip_input()) Changing the ip_input() a bit would make those unnecessary
too. So one can establish multiple tunnels to different (or
the same) hosts and use the same ViF. In this case, if you receive an
ICMP toobig, you don't know who if "belongs" to until you parse the
internal packet a bit and check the destination/SPI of the original
packet. And then of course you can't (shouldn't) change the "MTU" of
the ViF.
Q: does the NRL implementation create ViFs dynamically (as needed) ?
I have a fairly old copy of it (1 year+) - available at
idea.dsi.unimi.it:/pub/security/crypt/code/IPv6-domestic.tar.gz for
those wondering how i got a copy of it :-)
>It'll know. Before that SYN or SYN/ACK gets sent, it can consult endpoint
>state (socket, pcb, whatever) and make an appropriate guess.
Well, that's what i'm saying too. That we should make it a
requirement. In fact, even what you've been saying about ViFs is
non-standard; keeping track of ICMP toobigs and back-propagating that
value is not standard behaviour and not specified anywhere.
-Angelos
From owner-ipsec Fri Feb 7 09:19:53 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19402 for ipsec-outgoing; Fri, 7 Feb 1997 09:16:02 -0500 (EST)
Date: Fri, 7 Feb 1997 09:20:08 -0500
Message-Id: <9702071420.AA27311@ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ipsec@tis.com
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Replay field size in AH
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
The replay field size in AH is 64 bits. It is 32 bits in ESP drafts. We can
change the AH draft to use only 32 bits for replay and make the other 4
bytes reserved if we are concerned about the 64bit boundary alignment?
Naganand
From owner-ipsec Fri Feb 7 09:52:26 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA19648 for ipsec-outgoing; Fri, 7 Feb 1997 09:52:08 -0500 (EST)
Message-Id: <3.0.16.19970207094329.1c2fbda4@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Fri, 07 Feb 1997 09:54:05 -0500
To: John Kennedy <JKENNEDY@novell.com>
From: Rodney Thayer <rodney@sabletech.com>
Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News -Reply
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In thinking about this I believe the problem has crossed "endian" boundries
already so I don't think this is it. I'm going to rerun the DH tests on a
non-intel box to see if that changes things. I know the code Ed and I were
originally discussing was running on an Intel machine. I don't know for
sure if the Cylink code was running on an Intel box.
At 03:22 PM 2/6/97 -0700, you wrote:
>Oh, I don't think we need to call out the cryptographic "Big Guns" yet. I'm
>willing to bet the problem is with the output, transfer, and subsequent
>input at the receiving end of the public numbers. I doubt it is a
>fundamental problem with the underlying big integer arithmetic libraries.
>More like one library interpreting the numbers LSByte first and the other
>one MSByte first. If each library was not consistent in its interpretation
>of the data, the math wouldn't work for two implementations using the
>same library.
>
>-John Kennedy
> NOVELL, Inc.
>
>>>> Edward Russell <erussell@ftp.com> 02/06/97 01:44pm >>>
>>In message <01BC1429.F844BBC0@localhost>, Edward Russell writes:
>>
>> <Reversed SHA Bytes discussion deleted...>
>>
>>We'll try to establish if the same is true at the end of a Diffie Hellman
>exchange,
>>but that will be a little trickier.
>>
>
>It would appear the Diffie Hellman discrepancy between Cylink and
>Bsafe is
>not just a simple reversal. The cryptographers will have to tackle that
>one.
>
>
>
>
>
>
>
>Received: by provo.mx.relay
> with Novell_GroupWise; Thu, 06 Feb 1997 14:39:19 -0700
>Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id
PAA13761 for ipsec-outgoing; Thu, 6 Feb 1997 15:35:43 -0500 (EST)
>Message-Id: <01BC1444.9CEF6E80@localhost>
>Sender: owner-ipsec@ex.tis.com
>Precedence: bulk
>Date: Thu, 06 Feb 1997 13:44:02 -0700
>From: Edward Russell <erussell@ftp.com>
>To: ipsec@tis.com
>Subject: RE: test vectors for HMAC-SHA-1 - Test Data and Bad News
>
>>In message <01BC1429.F844BBC0@localhost>, Edward Russell writes:
>>
>> <Reversed SHA Bytes discussion deleted...>
>>
>>We'll try to establish if the same is true at the end of a Diffie Hellman
exchange,
>>but that will be a little trickier.
>>
>
>It would appear the Diffie Hellman discrepancy between Cylink and Bsafe is
>not just a simple reversal. The cryptographers will have to tackle that one.
>
>
>
>
>
>
>
>
--------
Rodney Thayer <rodney@sabletech.com>
PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Sat Feb 8 04:11:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24709 for ipsec-outgoing; Sat, 8 Feb 1997 04:09:09 -0500 (EST)
Message-Id: <199702071930.TAA01491@inner.net>
To: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
cc: ipsec@tis.com
Subject: Re: Path MTU Discovery
In-reply-to: Your message of "Thu, 06 Feb 1997 22:47:21 EST."
<9702070347.AA07084@aurora.cis.upenn.edu>
X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved.
X-Reposting: With explicit permission only
Date: Fri, 07 Feb 1997 14:30:42 -0500
From: Craig Metz <cmetz@inner.net>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <9702070347.AA07084@aurora.cis.upenn.edu>, you write:
>Another point is that fragmentation checking should be done before any
>IPsec handling takes place (easier and faster).
All IPsec processing must be done above fragmentation.
-Craig
From owner-ipsec Sat Feb 8 04:11:54 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24779 for ipsec-outgoing; Sat, 8 Feb 1997 04:09:30 -0500 (EST)
From: Uri Blumenthal <uri@watson.ibm.com>
Message-Id: <9702071637.AA38491@hawpub.watson.ibm.com>
Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News
To: chk@border.com (C. Harald Koch)
Date: Fri, 7 Feb 1997 11:37:21 -0500 (EST)
Cc: erussell@ftp.com, ipsec@tis.com
In-Reply-To: <97Feb6.135047est.30800-3@janus.border.com> from "C. Harald Koch" at Feb 6, 97 01:53:02 pm
Reply-To: uri@watson.ibm.com
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
C. Harald Koch says:
> > BSAFE SHA:
> > 4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
> > CYLINK SHA:
> > 4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
>
> I've seen this before. There are two different representations of hash codes
> floating around; "big endian" and "little endian". Note that the above
> hashes are identical with the *bytes* listed in the opposite order.
> I couldn't tell you which one is 'correct' though :-)
Well, by the spirit of SHA document (even though it would have been
better for the designers to explicitely say such things) BIG endian
is the correct one.
--
Regards,
Uri uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>
From owner-ipsec Sat Feb 8 04:11:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24570 for ipsec-outgoing; Sat, 8 Feb 1997 04:06:20 -0500 (EST)
Date: Sat, 8 Feb 97 02:56:12 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: Path MTU Discovery
To: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>,
Dan McDonald <Dan.McDonald@Eng.sun.com>
Cc: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199702070727.XAA24969@kebe.eng.sun.com>
Message-ID: <Chameleon.855370677.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan McD is correct (and the RFC-1827 ESP spec has a bug).
Fragmentation processing occurs _after_ all outbound IPsec processing
and _before_ all inbound IPsec processing. This should be for ESP
as well as for AH.
Ideally this will get corrected in the new ESP spec.
Mea Culpa.
Ran
rja@inet.org
From owner-ipsec Sat Feb 8 04:11:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA24724 for ipsec-outgoing; Sat, 8 Feb 1997 04:09:14 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199702071815.KAA01378@kebe.eng.sun.com>
Subject: Re: Path MTU Discovery
To: angelos@aurora.cis.upenn.edu (Angelos D. Keromytis)
Date: Fri, 7 Feb 1997 10:15:13 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <9702070842.AA79320@aurora.cis.upenn.edu> from "Angelos D. Keromytis" at Feb 7, 97 03:41:53 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Well, wouldn't ignoring the DF bit defeat the original endpoint's
> PathMTU ?
DF applies to the IP datagram on which it is set. DF is not inherited by any
encapsulating IP headers.
A packet arrives looking like:
src 10.8.20.69
dst 10.69.51.50
proto = tcp
bits = DF
The router then encapsulates:
src 10.20.20.20
dst 10.9.1.25
proto = ip
<Above IP datagram is in here>
This outer packet is now a datagram originating from the router. It can
fragment as it sees fit. Yes, it may violate the spirit of no intermediate
fragmentation, but it certainly is legal. This is legal in IPv6 too, where
there is an implicit DF bit on all packets.
> My phrasing was "fragmentation checking", not fragmentation; what i
> mean is that one should check whether a packet, after the overhead
> imposed by IPsec, would be fragmented. If so, don't apply the
> transforms but drop it and send back an ICMP toobig. Sorry if i was
> not clear enough.
That explains things a little better, thanks.
<SNIP!>
> So one can establish multiple tunnels to different (or the same) hosts and
> use the same ViF. In this case, if you receive an ICMP toobig, you don't
> know who if "belongs" to until you parse the internal packet a bit and
> check the destination/SPI of the original packet. And then of course you
> can't (shouldn't) change the "MTU" of the ViF.
I question your choice of abstraction. How do you configure these multiple
tunnels? Or are they automatic tunnels ala. IPv6's ::<v4-address> syntax?
Since you probably have to configure the tunnels, you might as well provide a
halfway decent abstraction to take into account Path MTU ratcheting down.
> Q: does the NRL implementation create ViFs dynamically (as needed) ?
> I have a fairly old copy of it (1 year+) - available at
> idea.dsi.unimi.it:/pub/security/crypt/code/IPv6-domestic.tar.gz for
> those wondering how i got a copy of it :-)
Glad to see the code has slipped out elsewhere. Funny thing is, last time I
touched the code was about 1 year+ ago. It does not do automatic tunneling,
IIRC.
> Well, that's what i'm saying too. That we should make it a
> requirement. In fact, even what you've been saying about ViFs is
> non-standard; keeping track of ICMP toobigs and back-propagating that
> value is not standard behaviour and not specified anywhere.
OTOH it uses defined behavior and available underspecifications to make
implementations (IMHO) less complex. Security holes come out of complexity,
just ask any sendmail user.
Dan
From owner-ipsec Sat Feb 8 13:40:06 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27339 for ipsec-outgoing; Sat, 8 Feb 1997 13:32:08 -0500 (EST)
Message-Id: <199702081836.KAA15585@dharkins-ss20.cisco.com>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Rodney Thayer <rodney@sabletech.com>
Cc: John Kennedy <JKENNEDY@novell.com>, ipsec@tis.com
Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News -Reply
In-Reply-To: Your message of "Fri, 07 Feb 1997 09:54:05 EST."
<3.0.16.19970207094329.1c2fbda4@pop3.pn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 08 Feb 1997 10:36:06 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Rodney Thayer wrote:
> In thinking about this I believe the problem has crossed "endian" boundries
> already so I don't think this is it. I'm going to rerun the DH tests on a
> non-intel box to see if that changes things. I know the code Ed and I were
> originally discussing was running on an Intel machine. I don't know for
> sure if the Cylink code was running on an Intel box.
It was running on both. The laptop we were using was little-endian and the
router was big-endian. Both could interoperate with other implementations
which shared the same crypto lib pedigree (i.e. the cylink one).
Dan.
From owner-ipsec Sat Feb 8 14:12:09 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA27495 for ipsec-outgoing; Sat, 8 Feb 1997 14:08:40 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v0300780aaf22800e1314@[128.33.229.242]>
In-Reply-To: <9702071420.AA27311@ftp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 8 Feb 1997 14:13:47 -0500
To: Naganand Doraswamy <naganand@ftp.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Replay field size in AH
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I'd like to hear from Jeff Schiller and the WG chairs re this still open
issue. My recollection is that there was supposed to be a small meetng to
reolve this after the last IPSEC WG meeting in San Jose. I observed that
we had two variables affecting aligmment: sequence number size and HMAC
size. Hugo made a suggestion to truncate the SHA-1 value to 128 bits, to
reduce the number of variables affecting alignment, but I don't recall a
decision on this, nor on the 32 vs. 64 bit sequence number. We do eed to
nail this down so that the grand unified AH and ESP specs can proceed.
Steve
From owner-ipsec Sat Feb 8 16:22:21 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA28030 for ipsec-outgoing; Sat, 8 Feb 1997 16:18:40 -0500 (EST)
Message-ID: <01BC15D4.23743680@Tastid.Cisco.COM>
From: adams@cisco.com (Rob Adams)
To: naganand@ftp.com (Naganand Doraswamy), kent@bbn.com ('Stephen Kent')
cc: ipsec@tis.com (ipsec@tis.com)
Subject: RE: Replay field size in AH
Date: Sat, 8 Feb 1997 15:23:55 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Regarless of what we do about alignment, a 64 bit replay field seems simply wrong.
2^64 packets before you wrap? 2^32 seems more than sufficient. The choice of replay
field length should not be linked to any alignment issues. If we need to align the packet
differently, we should add reserved or mbz fields. The size of the replay counter should
be useful and correct for replay alone, and not be sized based on any other issues.
-Rob
----------
From: Stephen Kent[SMTP:kent@bbn.com]
Sent: Saturday, February 08, 1997 11:13 AM
To: Naganand Doraswamy
Cc: ipsec@tis.com
Subject: Re: Replay field size in AH
I'd like to hear from Jeff Schiller and the WG chairs re this still open
issue. My recollection is that there was supposed to be a small meetng to
reolve this after the last IPSEC WG meeting in San Jose. I observed that
we had two variables affecting aligmment: sequence number size and HMAC
size. Hugo made a suggestion to truncate the SHA-1 value to 128 bits, to
reduce the number of variables affecting alignment, but I don't recall a
decision on this, nor on the 32 vs. 64 bit sequence number. We do eed to
nail this down so that the grand unified AH and ESP specs can proceed.
Steve
From owner-ipsec Sat Feb 8 18:05:32 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA28532 for ipsec-outgoing; Sat, 8 Feb 1997 18:02:12 -0500 (EST)
Date: Sat, 8 Feb 97 22:59:38 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: Replay field size in AH
To: Stephen Kent <kent@bbn.com>
Cc: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <v0300780aaf22800e1314@[128.33.229.242]>
Message-ID: <Chameleon.855442956.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
I was not informed about any small meeting that did occur or should have
occurred. Perhaps the Security AD can provide more data. I'll ask him
for instructions.
Ran
rja@inet.org
From owner-ipsec Sat Feb 8 19:44:11 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA28943 for ipsec-outgoing; Sat, 8 Feb 1997 19:40:41 -0500 (EST)
Message-Id: <199702090044.QAA04984@fluffy.cisco.com>
To: ipsec@tis.com
Subject: replay field size
Date: Sat, 08 Feb 1997 16:44:44 -0800
From: Derrell Piper <piper@tgv.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
There was clear consensus at the ANX IPSEC bakeoff last week to make the
size of the replay field 32-bits for both AH and ESP. If we _must_ have
alignment for IPv4 IPSEC then the additional bits should be specified as
alignment. No one wants to do 64-bit math for replay computation. It's
silly. In my opinion, IPv4 is misaligned for 64-bit hardware anyway and I
don't see the point of aligning the fields just to keep the protocol
consistent with IPv6.
I don't think this issue needs the Security AD to resolve. I think we
already have consensus. Let's hear now from anyone who absolutely must
have 64 bits or else move to revise AH and ESP to reflect consensus. We
have much more interesting things to argue about.
Derrell
From owner-ipsec Sun Feb 9 11:14:18 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA02596 for ipsec-outgoing; Sun, 9 Feb 1997 11:05:19 -0500 (EST)
Message-Id: <3.0.16.19970209105421.3847cd10@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Sun, 09 Feb 1997 11:07:14 -0500
To: Stephen Kent <kent@bbn.com>
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: Replay field size in AH
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
And what is the state of the Grand Unified ESP spec? (Is there ANY AH spec
anymore? I thought there wasn't.)
At 02:13 PM 2/8/97 -0500, you wrote:
>I'd like to hear from Jeff Schiller and the WG chairs re this still open
>issue. My recollection is that there was supposed to be a small meetng to
>reolve this after the last IPSEC WG meeting in San Jose. I observed that
>we had two variables affecting aligmment: sequence number size and HMAC
>size. Hugo made a suggestion to truncate the SHA-1 value to 128 bits, to
>reduce the number of variables affecting alignment, but I don't recall a
>decision on this, nor on the 32 vs. 64 bit sequence number. We do eed to
>nail this down so that the grand unified AH and ESP specs can proceed.
>
>Steve
>
>
>
>
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
From owner-ipsec Sun Feb 9 15:45:27 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA03674 for ipsec-outgoing; Sun, 9 Feb 1997 15:36:57 -0500 (EST)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970209204207Z-1699@tsntsrv2.timestep.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>, "'Derrell Piper'" <piper@tgv.com>
Subject: RE: replay field size
Date: Sun, 9 Feb 1997 15:42:07 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
ESP ad AH _should_ be very similar and thus utilize the same features.
Having one use a 32-bit replay counter and the other use a 64-bit one
is silly as Derrell stated. If 64-bit alignment is required, as in
IPv6, then padding should be appended to the end of the header if it
is needed due to the size of the digest algorithm used.
Why was RFC2085 (HMAC-MD5 IP Authentication with Replay Prevention)
released with a 64-bit replay counter if so many of us objected?
Furthermore, why wasn't a generic digest algorithm RFC released
(HMAC-x Authentication) instead? We must standardize the common
elements of our IPSEC protocols. Things like Replay Counter, HMAC,
Digest Algorithms, Cipher Algorithms, generation of Keys from keying
material. All of these common elements should be the same for all
'transforms' and not have to be re-defined/re-invented in every
transform RFC. Can you imagine every cipher algorithm defining a
different way to generate its keys and IV from the keying material?
We should be able to just plug in a new cipher algorithm and a new
digest algorithm without having to re-invent the wheel. Just plug in
their identifiers and go...The common RFCs (ESP, AH, IPSEC-DOI) should
define how to this without having to write a new transform RFC. This
way we do not need to create a new transform RFC for every combination
of parameters. For example, 3DES-Replay-HMAC-SHA1-LZS, has five
parameters; cipher algorithm, replay, keyed function, digest
algorithm, and compression algorithm. With five parameters we can
have quite a lot of transform RFCs.
Cipher Algorithm: None, DES, 3DES, RC5, Blowfish, IDEA
Replay Protection: No Replay, Replay
Keyed Function: None, Keyed, HMAC
Digest Algorithm: None, MD5, SHA1, Tiger
Compression Algorithm: None, LZS, GZIP
6 * 2 * 3 * 4 * 3 = 432 different transform RFC combinations!!!
----------
From: Derrell Piper[SMTP:piper@tgv.com]
Sent: Saturday, February 08, 1997 7:45 PM
To: ipsec@tis.com
Subject: replay field size
There was clear consensus at the ANX IPSEC bakeoff last week to make
the
size of the replay field 32-bits for both AH and ESP. If we _must_
have
alignment for IPv4 IPSEC then the additional bits should be specified
as
alignment. No one wants to do 64-bit math for replay computation.
It's
silly. In my opinion, IPv4 is misaligned for 64-bit hardware anyway
and I
don't see the point of aligning the fields just to keep the protocol
consistent with IPv6.
I don't think this issue needs the Security AD to resolve. I think
we
already have consensus. Let's hear now from anyone who absolutely
must
have 64 bits or else move to revise AH and ESP to reflect consensus.
We
have much more interesting things to argue about.
Derrell
From owner-ipsec Sun Feb 9 18:27:57 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04393 for ipsec-outgoing; Sun, 9 Feb 1997 18:22:25 -0500 (EST)
Date: Sun, 9 Feb 97 22:57:21 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: RE: replay field size
To: "'ipsec@tis.com'" <ipsec@tis.com>
Cc: rja@inet.org
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970209204207Z-1699@tsntsrv2.timestep.com>
Message-ID: <Chameleon.855530582.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Sun, 9 Feb 1997 15:42:07 -0500 Roy Pereira <rpereira@TimeStep.com> wrote:
> Why was RFC2085 (HMAC-MD5 IP Authentication with Replay Prevention)
> released with a 64-bit replay counter if so many of us objected?
Because contrary to your assertions, there were NOT (repeat NOT)
many objections to the 64-bit counter _during WG Last Call_. A very small
number of people do NOT constitute "many".
Process aside, the technical merit is slight. The amount of code
needed for 2 replay sizes is clearly small (evidence some of the
conforming implementations that existed prior to Last Call).
The reason last call exists is to provide a "last" opportunity to
object before things move forward to standards-track status. Input
needs to arrive during the Last Call period, not afterwards.
Participants are expected to remain current with the drafts all the
time, last calls live at least a week so that folks can have a chance
to re-read the draft before it proceeeds. If folks do not take the
time to make their specific issues known to the WG chairs during last
call, that is the choice of those individuals not the fault of the
chair(s).
> Furthermore, why wasn't a generic digest algorithm RFC released
> (HMAC-x Authentication) instead ?
The WG chose to proceed in the way it has. The changes Steve Kent
has proposed would increase the fixed structure to both AH and ESP.
If the WG decides to accept his edited drafts for Draft Standard,
then a different approach can be employed down the road. At this point,
a crucial consideration is avoiding making existing conforming
implementations suddenly non-conforming by issuance of new RFCs.
My understanding has always been that Steve's changes don't make
existing conforming implementations suddenly non-conforming.
> We should be able to just plug in a new cipher algorithm and a new
> digest algorithm without having to re-invent the wheel. Just plug in
> their identifiers and go...
There _is_ more to it than just identifiers. Different algorithms have
different modes and different resulting data sizes and IVs and so forth.
With AH HMAC SHA-1 there was the question raised of using the standard
160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output.
If one truncates, then the method/process of truncation needs to
be openly and clearly specified. Just assigning identifiers will
tend NOT lead to interoperable implementations. Additional structure
to the base specifications will help, but is probably not a panacea.
Ran
rja@Inet.org
From owner-ipsec Sun Feb 9 18:28:32 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA04401 for ipsec-outgoing; Sun, 9 Feb 1997 18:24:55 -0500 (EST)
Date: Sun, 9 Feb 97 23:23:24 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: Replay field size in AH
To: ipsec@tis.com
Cc: rja@inet.org, Rodney Thayer <rodney@sabletech.com>
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <3.0.16.19970209105421.3847cd10@pop3.pn.com>
Message-ID: <Chameleon.855530725.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Rodney,
My understanding has never been that AH would go away. AH and
the proposed "ESP without encryption" do not have identical semantics.
My understanding has always been that existing conforming implementations
of AH/ESP would not be made non-conforming by any of the changes that
Steve Kent is proposing.
Ran
rja@Inet.org
From owner-ipsec Sun Feb 9 20:36:30 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA04949 for ipsec-outgoing; Sun, 9 Feb 1997 20:31:59 -0500 (EST)
Message-Id: <3.0.32.19970209202505.00688254@netrix.lkg.dec.com>
X-Sender: mthomas@netrix.lkg.dec.com
X-Mailer: Windows Eudora Pro Version 3.0 Demo (32)
Date: Sun, 09 Feb 1997 20:25:34 -0500
To: ipsec@tis.com
From: Matt Thomas <matt@lkg.dec.com>
Subject: Re: replay field size
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 04:44 PM 2/8/97 -0800, Derrell Piper wrote:
>There was clear consensus at the ANX IPSEC bakeoff last week to make the
>size of the replay field 32-bits for both AH and ESP. If we _must_ have
>alignment for IPv4 IPSEC then the additional bits should be specified as
>alignment. No one wants to do 64-bit math for replay computation. It's
>silly. In my opinion, IPv4 is misaligned for 64-bit hardware anyway and I
>don't see the point of aligning the fields just to keep the protocol
>consistent with IPv6.
IPv6 headers need to be 8-byte aligned. Thus AH header must be a multiple
of 8-bytes in length. For IPv4, a multiple of 4-bytes is fine. The AH
data doesn't have to be 8-byte aligned. [The destination option header
comes after the AH and can contain options that require 8-byte alignment].
>I don't think this issue needs the Security AD to resolve. I think we
>already have consensus. Let's hear now from anyone who absolutely must
>have 64 bits or else move to revise AH and ESP to reflect consensus. We
>have much more interesting things to argue about.
All I want is that the AH header in IPv6 packets to be a multiple of 8-bytes
in length. A 32-bit replay field is fine. I don't even care where the
padding is (it would be nice if it were in a standard place), just that
it exists.
--
Matt Thomas Internet: matt@lkg.dec.com
UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/
Digital Equipment Corporation Disclaimer: This message reflects my own
Littleton, MA warped views, etc.
From owner-ipsec Sun Feb 9 21:28:44 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA05177 for ipsec-outgoing; Sun, 9 Feb 1997 21:25:00 -0500 (EST)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970210023005Z-1718@tsntsrv2.timestep.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>, "'Ran Atkinson'" <rja@inet.org>
Subject: RE: replay field size
Date: Sun, 9 Feb 1997 21:30:05 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>> We should be able to just plug in a new cipher algorithm and a new
>> digest algorithm without having to re-invent the wheel. Just plug
in
>> their identifiers and go...
>There _is_ more to it than just identifiers. Different algorithms
have
>different modes and different resulting data sizes and IVs and so
forth.
>With AH HMAC SHA-1 there was the question raised of using the
standard
>160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output.
>If one truncates, then the method/process of truncation needs to
>be openly and clearly specified. Just assigning identifiers will
>tend NOT lead to interoperable implementations. Additional
structure
>to the base specifications will help, but is probably not a panacea.
Ran, my point was that a very large portion of the existing transform
drafts contain the exact same words and definitions. Yes, more than
an identifier would be required for some algorithms, but again there
exists quite a lot of the specification wording that overlap. Rules
for such things as truncating a digest (or padding it) would be better
defined in a common draft (ESP and/or AH).
If there was a common method to obtain a variable length IV and
variable length keys from keying material, then this information would
not have to be in every transform draft.
Why should all ESP transform drafts list the ESP structure, define
replay protection, and define how to obtain keying? These common
specification sections only need to be specified once.
From owner-ipsec Sun Feb 9 23:43:12 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05776 for ipsec-outgoing; Sun, 9 Feb 1997 23:37:04 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007802af2455afeb15@[128.33.229.241]>
In-Reply-To:
<c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970210023005Z-1718@tsntsrv2.timest
ep.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 9 Feb 1997 23:36:18 -0500
To: Roy Pereira <rpereira@TimeStep.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: replay field size
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Roy,
The goal of producing the new AH and ESP specs is to avoid the need
for each transform to include all of the repetitive text that you
identified as redundant. To that end, I endorse the notion of adopting
uniform counter sizes, padding, IV specification options, etc. We are
trying to do that in the new specs and that's why I wanted to get a
definitive answer re the replay counter size.
Steve
From owner-ipsec Sun Feb 9 23:43:13 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05775 for ipsec-outgoing; Sun, 9 Feb 1997 23:37:03 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007801af2454f8c03c@[128.33.229.241]>
In-Reply-To: <3.0.16.19970209105421.3847cd10@pop3.pn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 9 Feb 1997 23:33:32 -0500
To: Rodney Thayer <rodney@sabletech.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Replay field size in AH
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Rodney,
The AH and ESP specs have been redone, but need another pass to
deal with some outstanding issues, e.g., the counter size issue that is
still being debated in messages from this weekend. The IPSEC architecture
document needs considerably more work.
As for AH, no, it is not going away, since, as Ran pointed out, it
still offers slightly different features as compared to ESP without
encryption. However, the motivations for using AH re more narrow than
before, due to the changes in ESP.
Steve
From owner-ipsec Mon Feb 10 08:29:22 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08436 for ipsec-outgoing; Mon, 10 Feb 1997 08:23:38 -0500 (EST)
Message-Id: <9702072051.AA79389@aurora.cis.upenn.edu>
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
Cc: ipsec@tis.com
Subject: Re: Path MTU Discovery
Date: Fri, 07 Feb 1997 15:50:42 -0500
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
In message <199702071815.KAA01378@kebe.eng.sun.com>, Dan McDonald writes:
>
>This outer packet is now a datagram originating from the router. It can
>fragment as it sees fit. Yes, it may violate the spirit of no intermediate
>fragmentation, but it certainly is legal. This is legal in IPv6 too, where
>there is an implicit DF bit on all packets.
I didn't question its legality. If the endpoint is trying to do
PathMTU discovery and we care to respect this and we must copy the DF
bit. If we don't, we can just ignore it and none will be the wiser;
however, i can see (pathological maybe) situations where fragmentation
happens between every tunnel endpoint because noone respects the DF bit.
>I question your choice of abstraction. How do you configure these multiple
>tunnels? Or are they automatic tunnels ala. IPv6's ::<v4-address> syntax?
>Since you probably have to configure the tunnels, you might as well provide a
>halfway decent abstraction to take into account Path MTU ratcheting down.
Extended routing entries. All the relevant information (for IP
encapsulation, the IP addresses; for AH/ESP the SPIs) is contained in
the routing table. Or you mean something different
>OTOH it uses defined behavior and available underspecifications to make
>implementations (IMHO) less complex. Security holes come out of complexity,
>just ask any sendmail user.
I doubt either approach (ViF-MTU or "my" way) is overly complex. And i
would argue that it is necessary for good network behaviour.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMvuVor0pBjh2h1kFAQG4BAP/cGxO5qo+0SVgnNJGCFc/2UUEX8oikPup
jusn2O6EcX2tOwWXom50sqbM9iVaACU1QvXdJPnxafhXsxUkrqG9P8fJrtVc5y/W
EZHz/4Udr36gZgwK98VoU3BIX6TkgwDZbmch/OfKAG/+zDwB1rV8ZelPHxuYNGTk
zy0Gv06+b/Q=
=Rt2u
-----END PGP SIGNATURE-----
From owner-ipsec Mon Feb 10 08:34:10 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08504 for ipsec-outgoing; Mon, 10 Feb 1997 08:31:36 -0500 (EST)
Date: Sat, 8 Feb 1997 07:37:08 -0500 (EST)
Message-Id: <199702081237.HAA24954@carp.morningstar.com>
From: Ben Rogers <ben@ascend.com>
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
Cc: angelos@aurora.cis.upenn.edu (Angelos D. Keromytis), ipsec@tis.com
Subject: Re: Path MTU Discovery
Reply-To: ben@ascend.com (Ben Rogers)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan McDonald writes:
> > Well, wouldn't ignoring the DF bit defeat the original endpoint's
> > PathMTU ?
>
> DF applies to the IP datagram on which it is set. DF is not inherited by any
> encapsulating IP headers.
Hate to be picky, but RFC1853 states:
Don't Fragment copied from the inner IP header. This allows the
originator to control the level of performance
tradeoffs. See "Tunnel MTU Discovery".
So, in fact, the IP-in-IP header requires that DF bit be set, and
neither AH, nor ESP will touch this part of the header.
Of course, if you would like to tunnel using a protocol other than IP in
IP, that is your prerogative... Are there people who do this?
> <SNIP!>
> > So one can establish multiple tunnels to different (or the same) hosts and
> > use the same ViF. In this case, if you receive an ICMP toobig, you don't
> > know who if "belongs" to until you parse the internal packet a bit and
> > check the destination/SPI of the original packet. And then of course you
> > can't (shouldn't) change the "MTU" of the ViF.
>
> I question your choice of abstraction. How do you configure these multiple
> tunnels? Or are they automatic tunnels ala. IPv6's ::<v4-address> syntax?
> Since you probably have to configure the tunnels, you might as well provide a
> halfway decent abstraction to take into account Path MTU ratcheting down.
Hopefully, if each tunnel properly supports Path MTU and "soft state",
the MTU should propagate upwards. Personally I wonder what the point is
in requiring Path MTU be done, while only recommending that soft state
be kept. (Perhaps RFC1853 should be updated to require the keeping of
soft state?)
Then, we would see everything perform nicely, a la:
Host -> Tunnelling Router 1 -> Tunneling Router 2 --A--> ...
Where each router is doing rfc1828 MD5 tunneling (20 byte IP header + 24
bytes of AH = 44 bytes total), and path A has an MTU of 500 bytes.
Packet 1: 1500 bytes, DF set
Tunneled by R1 (1544 bytes) (Dropped)
Packet 2: 1500 bytes, DF set
R1 sends ICMP too big with size limit 1456 to host
Tunneled by R1 (1544 bytes) (Dropped) (An effort to rediscover a
"growing" MTU)
Packet 3: 1456 bytes, DF set
Tunneled by R1 (1500 bytes)
Tunneled by R2 (1544 bytes) (Dropped)
Packet 4: 1456 bytes, DF set
Tunneled by R1 (1500 bytes)
R2 sends ICMP too big with size limit 456 to R1
Tunneled by R2 (1544 bytes) (Dropped)
Packet 4: 1456 bytes, DF set
R1 sends ICMP too big with size limit 412 to host
Tunneled by R1 (1500 bytes)
R2 sends ICMP too big with size limit 456 to R1
Tunneled by R2 (1544 bytes) (Dropped)
Packet 5: 412 bytes, DF set
Tunneled by R1 (456 bytes)
Tunneled by R2 (500 bytes)
Received.
ben
From owner-ipsec Mon Feb 10 08:58:16 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08699 for ipsec-outgoing; Mon, 10 Feb 1997 08:55:42 -0500 (EST)
Message-Id: <3.0.32.19970208220940.00695cc8@netrix.lkg.dec.com>
X-Sender: mthomas@netrix.lkg.dec.com
X-Mailer: Windows Eudora Pro Version 3.0 Demo (32)
Date: Sat, 08 Feb 1997 22:10:27 -0500
To: Derrell Piper <piper@tgv.com>
From: Matt Thomas <thomas@lkg.dec.com>
Subject: Re: replay field size
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 04:44 PM 2/8/97 -0800, Derrell Piper wrote:
>There was clear consensus at the ANX IPSEC bakeoff last week to make the
>size of the replay field 32-bits for both AH and ESP. If we _must_ have
>alignment for IPv4 IPSEC then the additional bits should be specified as
>alignment. No one wants to do 64-bit math for replay computation. It's
>silly. In my opinion, IPv4 is misaligned for 64-bit hardware anyway and I
>don't see the point of aligning the fields just to keep the protocol
>consistent with IPv6.
IPv6 headers need to be 8-byte aligned. Thus AH header must be a multiple
of 8-bytes in length. For IPv4, a multiple of 4-bytes is fine. The AH
data doesn't have to be 8-byte aligned. [The destination option header
comes after the AH and can contain options that require 8-byte alignment].
>I don't think this issue needs the Security AD to resolve. I think we
>already have consensus. Let's hear now from anyone who absolutely must
>have 64 bits or else move to revise AH and ESP to reflect consensus. We
>have much more interesting things to argue about.
All I want is that the AH header in IPv6 packets to be a multiple of 8-bytes
in length. A 32-bit replay field is fine. I don't even care where the
padding is (it would be nice if it were in a standard place), just that
it exists.
Matt Thomas Internet: matt@lkg.dec.com
UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/
Digital Equipment Corporation Disclaimer: This message reflects my own
Littleton, MA warped views, etc.
From owner-ipsec Mon Feb 10 11:07:12 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09945 for ipsec-outgoing; Mon, 10 Feb 1997 11:05:32 -0500 (EST)
X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs
Date: Mon, 10 Feb 1997 09:01:08 -0700 (MST)
From: Oliver Spatscheck <spatsch@cs.arizona.edu>
To: Ben Rogers <ben@ascend.com>
cc: Dan McDonald <Dan.McDonald@Eng.sun.com>,
"Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>, ipsec@tis.com
Subject: Re: Path MTU Discovery
In-Reply-To: <199702081237.HAA24954@carp.morningstar.com>
Message-ID: <Pine.LNX.3.94.970210085430.2648A-100000@P-spatsch.cs.arizona.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
On Sat, 8 Feb 1997, Ben Rogers wrote:
>
>Then, we would see everything perform nicely, a la:
>
>Host -> Tunnelling Router 1 -> Tunneling Router 2 --A--> ...
>
>Where each router is doing rfc1828 MD5 tunneling (20 byte IP header + 24
>bytes of AH = 44 bytes total), and path A has an MTU of 500 bytes.
This example only works for IPv4. IPv6 requires a MINIMUM MTU
of 576 Octets. Which requieres your second router to do link
specific fragmentation.
This schouldn't be a problem in your scenario since r2 has to do link
specific fragmentation anyway (MTU 500 Byte) . However if you assume a
tunneling router with a link MTU of 580 byte and you add IP in IP the
router suddenly has to do link specific fragmentation. Something he
didn't do before.
Oliver
>
>Packet 1: 1500 bytes, DF set
> Tunneled by R1 (1544 bytes) (Dropped)
>
>Packet 2: 1500 bytes, DF set
> R1 sends ICMP too big with size limit 1456 to host
> Tunneled by R1 (1544 bytes) (Dropped) (An effort to rediscover a
> "growing" MTU)
>
>Packet 3: 1456 bytes, DF set
> Tunneled by R1 (1500 bytes)
> Tunneled by R2 (1544 bytes) (Dropped)
>
>Packet 4: 1456 bytes, DF set
> Tunneled by R1 (1500 bytes)
> R2 sends ICMP too big with size limit 456 to R1
> Tunneled by R2 (1544 bytes) (Dropped)
>
>Packet 4: 1456 bytes, DF set
> R1 sends ICMP too big with size limit 412 to host
> Tunneled by R1 (1500 bytes)
> R2 sends ICMP too big with size limit 456 to R1
> Tunneled by R2 (1544 bytes) (Dropped)
>
>Packet 5: 412 bytes, DF set
> Tunneled by R1 (456 bytes)
> Tunneled by R2 (500 bytes)
> Received.
>
>
>
>ben
>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBMv9GRjnVPgUZ7uZJAQGDWwP/aFlUYlzPN0AqyknfCEF4jKK/TWtGPn9H
PU12zESdKmmzA2pRyZMo7EEFLU30Z2256WeuZsVVlbbJD4zZ4vJvNhIl31WCDFPX
o6WBv+jLFemTSQOKfF8dlUtJRhQr4erh73pPL4IFxy2Xw5g4gyRXQuqG0mJvvdR/
8U3NDPUFHdE=
=j/qJ
-----END PGP SIGNATURE-----
From owner-ipsec Mon Feb 10 11:32:26 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA10166 for ipsec-outgoing; Mon, 10 Feb 1997 11:31:06 -0500 (EST)
From: Tim Bass (IETF) <ietf@linux.silkroad.com>
Message-Id: <199702101632.LAA00253@linux.silkroad.com>
Subject: Re: replay field size
To: ipsec@tis.com
Date: Mon, 10 Feb 1997 11:32:50 -0500 (EST)
X-Mailer: ELM [version 2.4 PL24 PGP2]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>From the RFCs:
For IPv6, options (with padding) must be on 64 bit (8 byte boundaries).
For IPv4, multibyte options are not required to adhere to an alignment
specification.
Tim
From owner-ipsec Mon Feb 10 20:08:12 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13246 for ipsec-outgoing; Mon, 10 Feb 1997 20:02:39 -0500 (EST)
Message-ID: <01BC1774.B4080180@Tastid.Cisco.COM>
From: adams@cisco.com (Rob Adams)
To: ipsec@tis.com ('ipsec@tis.com'), rja@inet.org ('Ran Atkinson')
Subject: RE: replay field size
Date: Mon, 10 Feb 1997 17:05:26 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I agree with Roy here..
I first objected to this in a post to the list on September 26th 1996. Derrell Piper complained in a post on
October 3rd. C. J. Lee posted on 27 Nov. saying, "To me, different replay counter size for different AH/ESP
transforms would definitely complicated an IPsec implementation in terms of storing and using the per session
(SA) replay checking state ..." Ran, you made some argument about alignment (which is irrelevant to replay)
on the 9th of December. You claimed then that you explained your objection on the list, but I couldn't find it in
the digest. Then Roy complained again on the 15th of January. Now Naganand is questioning it.
And I argued with you, Ran, in private mail about this and the need for negotiating replay window size. I also
recall most people implementing it, at least that I knew, questioning a 64 bit replay field.
The only defense of this I found in the digest was by Ran. I don't know of anyone else actually
implementing this who ever thought a 64 bit replay field was a good idea.... Granted my exposure
is limited, but not that limited.
>>Process aside, the technical merit is slight. The amount of code
>>needed for 2 replay sizes is clearly small
This is a matter of opinion and is also irrelevant. Any amount of code added to support a "feature"
that a majority of implementers think is wrong is too much code.
>>Process aside, the technical merit is slight.
The technical merit for doing a 64 bit replay field? Sorry I couldn't resist, but it does lead me to my next point.
It seems to me that the process here is broken, and I don't know what to do about it. When people
complain about an annoyance that has no valid merit that anyone can think of, and the annoyance
goes through anyway, then we have a broken process. And I know I'm going to get flamed for saying
that it is an annoyance, but it is. If you're not implementing this on a 64 bit architecture and you're trying
to share your replay code with ESP, then it is a real pain, plain and simple. It think that a lot of
people implementing the transforms will be in this boat. This shouldn't have made it to last call.
In fact, I have a process question. I found the last call announcement in the archives on for the AH
documents and it was on 7 Aug 96. The document that went to last call was draft-ietf-ipsec-ah-hmac-md5-01.
I happen to have a copy of that document and it has a 32 bit replay field... hmmmm... Then an update
was posted on the 30th of August. This contained the 64 bit replay field. The update said the -02 documents
were based on comments received during last call. A 64 bit replay field was not discussed on the list, and
of course no one complained because it was a 32 bit field as far as we knew.
What do you do if a document goes through revisions like this after last call?
I bet if we took a vote by people implementing the transforms of a 64 bit vs. a 32 bit replay field,
we'd find results different than what is in the documents.
-Rob Adams
Cisco Systems
----------
From: Ran Atkinson[SMTP:rja@inet.org]
Sent: Sunday, February 09, 1997 2:57 PM
To: 'ipsec@tis.com'
Cc: rja@inet.org
Subject: RE: replay field size
--- On Sun, 9 Feb 1997 15:42:07 -0500 Roy Pereira <rpereira@TimeStep.com> wrote:
> Why was RFC2085 (HMAC-MD5 IP Authentication with Replay Prevention)
> released with a 64-bit replay counter if so many of us objected?
Because contrary to your assertions, there were NOT (repeat NOT)
many objections to the 64-bit counter _during WG Last Call_. A very small
number of people do NOT constitute "many".
Process aside, the technical merit is slight. The amount of code
needed for 2 replay sizes is clearly small (evidence some of the
conforming implementations that existed prior to Last Call).
The reason last call exists is to provide a "last" opportunity to
object before things move forward to standards-track status. Input
needs to arrive during the Last Call period, not afterwards.
Participants are expected to remain current with the drafts all the
time, last calls live at least a week so that folks can have a chance
to re-read the draft before it proceeeds. If folks do not take the
time to make their specific issues known to the WG chairs during last
call, that is the choice of those individuals not the fault of the
chair(s).
> Furthermore, why wasn't a generic digest algorithm RFC released
> (HMAC-x Authentication) instead ?
The WG chose to proceed in the way it has. The changes Steve Kent
has proposed would increase the fixed structure to both AH and ESP.
If the WG decides to accept his edited drafts for Draft Standard,
then a different approach can be employed down the road. At this point,
a crucial consideration is avoiding making existing conforming
implementations suddenly non-conforming by issuance of new RFCs.
My understanding has always been that Steve's changes don't make
existing conforming implementations suddenly non-conforming.
> We should be able to just plug in a new cipher algorithm and a new
> digest algorithm without having to re-invent the wheel. Just plug in
> their identifiers and go...
There _is_ more to it than just identifiers. Different algorithms have
different modes and different resulting data sizes and IVs and so forth.
With AH HMAC SHA-1 there was the question raised of using the standard
160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output.
If one truncates, then the method/process of truncation needs to
be openly and clearly specified. Just assigning identifiers will
tend NOT lead to interoperable implementations. Additional structure
to the base specifications will help, but is probably not a panacea.
Ran
rja@Inet.org
From owner-ipsec Mon Feb 10 21:01:02 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA13472 for ipsec-outgoing; Mon, 10 Feb 1997 20:55:39 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199702110156.RAA06362@kebe.eng.sun.com>
Subject: Re: replay field size
To: ipsec@tis.com
Date: Mon, 10 Feb 1997 17:56:28 -0800 (PST)
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I came in on this one late, folks. Apparently I was shoved on the TIS
"bounce" list. P*sses me off when I miss things. If I rehash anything here,
I apologize.
Anyway, w.r.t. replay counters, and what have you. Please keep in mind a
couple of things:
1.) Rememember that when a replay counter wraps, you must rekey.
I dunno how fast 2^32 packets happens, but is that enough
for a given key lifetime?
2.) IPv6 options MUST, I repeat MUST be 8-byte aligned. A 32-bit
SPI + a 32-bit replay + a 160-bit SHA output is NOT 32-bit
aligned. OTOH if you change the replay to 64-bits, you're
64-bit aligned.
3.) I'm assuming replay counter size is a property of the Security
Association being used. Since I have to parse the rest of the
AH based on SA information, why is the bit of code to handle
replay counters any different than the code handling the
authentication data, or whether there's replay protection in the
first place?
I'll admit replay protection isn't where my attention is currently, but I
just don't see it as that hard of a problem. Just bang together the rocks
together, guys!
Dan
From owner-ipsec Mon Feb 10 22:52:57 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA14089 for ipsec-outgoing; Mon, 10 Feb 1997 22:52:16 -0500 (EST)
Date: Tue, 11 Feb 97 03:46:02 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: Path MTU Discovery
To: Ben Rogers <ben@ascend.com>, Dan McDonald <Dan.McDonald@Eng.sun.com>
Cc: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>, ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199702081237.HAA24954@carp.morningstar.com>
Message-ID: <Chameleon.855633160.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Ben,
It is worth noting that none of the IPsec RFCs cite any of the IP-in-IP
RFCs. This is not an accident. With IPsec, one is not performing IP-in-IP.
Rather, one is performing IP-in-AH or IP-in-ESP. The IP-in-IP RFCs don't
include IPsec within their scope.
It was quite intentional that this was done. It is equally intentional
that the IPsec RFCs haven't been citing the IP-in-IP RFCs.
In effect, ESP tunnel mode uses the outer IP as a link-layer. Copying
DF bit is not prohibited for IPsec tunneling, but neither is it required
for IPsec tunneling.
Ran
rja@inet.org
who wrote the relevant IPsec RFCs...
From owner-ipsec Mon Feb 10 23:59:52 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA14341 for ipsec-outgoing; Mon, 10 Feb 1997 23:57:47 -0500 (EST)
Date: Tue, 11 Feb 97 03:53:56 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: RE: replay field size
To: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <01BC1774.B4080180@Tastid.Cisco.COM>
Message-ID: <Chameleon.855637101.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Mon, 10 Feb 1997 17:05:26 -0800 Rob Adams <adams@cisco.com> wrote:
> I first objected to this in a post to the list on September 26th 1996.
> Derrell Piper complained in a post on October 3rd. C. J. Lee posted on
> 27 Nov. saying, "To me, different replay counter size for different AH/ESP
> transforms would definitely complicated an IPsec implementation in terms of
> storing and using the per session (SA) replay checking state ..."
The document was gone from the WG and into the IESG's hands
prior to any of the comments that you cite.
> Then Roy complained again
> on the 15th of January. Now Naganand is questioning it.
> And I argued with you, Ran, in private mail about this and
> the need for negotiating replay window size. I also
> recall most people implementing it, at least that I knew,
> questioning a 64 bit replay field.
The notes from you, CJ Lee, and more recently Naganand
and Roy were all _after_ the IESG had already
approved the draft for Proposed Standard RFC.
At that point, the document was in the hands of the IESG,
not within the jurisdiction of the co-chair(s).
The reason for the delayed publication is that the
RFC Editor has a very long latency between approval
and publication just now (which I'm told is being fixed
so that the latency will diminish in future).
> The technical merit for doing a 64 bit replay field?
A 64-bit replay field permits longer times between rekey
intervals. This can be useful if one has a strong algorithm.
If one has a weak algorithm, a shorter time between rekey
intervals might be preferable. Replay size and rekey intervals
are not entirely unrelated. It is up to the WG to
decide whether the benefit/cost ratio makes sense.
Let me also specifically disclaim that the 64-bit replay
or the variable-size replay was my idea. Neither was my
idea or my proposal It was proposed by someone else.
> It seems to me that the process here is broken,
> and I don't know what to do about it.
Talk with either of the co-chairs and/or
the Security AD, Jeff Schiller <jis@mit.edu>.
Within reason, I'm happy to telephone people within
the US/Canada if provided with a time and phone number
to telephone and a topic.
Alternately, one could raise this as a matter for the
POISED WG to take up in revising the process documents.
> When people complain about an annoyance that has
> no valid merit that anyone can think of, and the
> annoyance goes through anyway, then we have a
> broken process.
By your count, there were 4 complaints to the list
in a working group having something like 70 participants.
This is not a large percentage. This is one reason why
it IS important for people to speak up on the list so
that the consensus is readily clear right away. When
few people comment either way on any issue, it can
be very difficult to evaluate where consensus lies.
> It think that a lot of people implementing the
> transforms will be in this boat. This shouldn't
> have made it to last call.
Last Call is a mechanism for people to raise objections
to documents moving forward. Not all Last Calls go
forward; some fail, including some in this WG. It
is very very important that people speak up during
the Last Call period, not afterwards. One voice
of complaint to the WG list during a Last Call
does not represent a clear consensus. It is also
important to note that Last Call comments aren't
required to be sent to the list. Unicast comments
to the Chairs during WG Last Call do get considered
as well. I don't recall many comments during either
of the AH HMAC WG Last Calls.
There are 2 separate Last Calls before a standards-track
document goes out as RFC from a Working Group. The first
is done by the WG Chair(s) at the point the chair(s)
believe there is probably rough consensus within
WG members that a document should advance to standards-
track RFC.
If that proves to be true, then the chair(s) pass the
document (I-D) on to the appropriate IESG Area
Director for their review and for the review of
the IESG as a whole. The IESG holds a formal
IETF Last Call before they vote (yes, the IESG
formally votes on each I-D).
Based on input received by the IESG (often privately,
not necessarily from any mailing list), a draft
can change after IESG Last Call and prior to
publication. In many cases, changes happen --
usually for editorial reasons.
> In fact, I have a process question. I found the last call announcement
> in the archives on for the AH documents and it was on 7 Aug 96.
> The document that went to last call was draft-ietf-ipsec-ah-hmac-md5-01.
> I happen to have a copy of that document and it has a 32 bit replay field...
> hmmmm... Then an update was posted on the 30th of August. This
> contained the 64 bit replay field. The update said the -02 documents
> were based on comments received during last call. A 64 bit replay field
> was not discussed on the list, and of course no one complained because
> it was a 32 bit field as far as we knew.
>
> What do you do if a document goes through revisions like this after last call?
Talk with the IESG, it was their Last Call that
was announced on 7 August 1996.
By the way, another revision that happened is that
AH HMAC SHA-1 became elective-to-implement because
the IESG objected to having both AH HMAC MD5 and
AH HMAC SHA-1 as mandatory-to-implement. This
fact was also reflected in the revised I-Ds that
went out last Fall and hasn't been a secret of any
sort.
In some cases, documents change as a result of WG
Last Call before proceeding to IETF Last Call.
In those cases, new I-Ds are issued online and
announced to the IETF list and normally to the
WG list as well so that people know the drafts
have changed. Once a document is in the IESG's
hands, it is out of the hands of the WG chair(s).
Just a guess, but if this was bothersome, the closed
room process by which the IPv6 spec came out of thin air
(IPv6 being not exactly any of the IPng proposals on
the table at the time) must have also been fairly
annoying to you.
> I bet if we took a vote by people implementing the
> transforms of a 64 bit vs. a 32 bit replay field,
> we'd find results different than what is in the documents.
Well, the IETF doesn't officially "vote", but it does
seems constructive to have a Straw Poll on this to try
to put it to bed.
If people would please send email to me <rja@inet.org> and
Paul Lambert <palamber@us.oracle.com> on this, we'll try
to settle it now.
It is not a requirement that one be an implementer to
participate in the straw poll, but it is a requirement
that one be an active member of the IPsec WG. Attendance
at IETF meetings is not required, though that certainly
does indicate activity.
While we're at it, it also seems like a good time to measure
the consensus on the matter of SHA-1 truncation. Hugo
has proposed trucating the SHA-1 output to 128 bits from
160 bits for use with AH. There wasn't much discussion on
this on the list, thought Hugo raised the question at
the last IETF meeting.
The questions are:
Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
If they have a fixed size counter, what size should it be? (32 bits/64 bits)
Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care)
Please send your response within the next week. Please DO send
a response so that consensus is crystal clear. We need to
resolve this issue so that Steve Kent's documents can be
edited accordingly. Paul or I will post a summary about a
week from now.
Note that if changes are made, it could easily take another
4-6 months for a revised RFC to appear online after IESG approval.
Also, the revised drafts will need to go through WG Last Call
again. I don't think any of these are problems, but I don't
want people to be surprised and feel like they need to send
out heated email. :-)
Best wishes,
Ran
rja@inet.org
From owner-ipsec Tue Feb 11 00:03:37 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA14384 for ipsec-outgoing; Tue, 11 Feb 1997 00:02:19 -0500 (EST)
Date: Tue, 11 Feb 97 04:58:44 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: Path MTU Discovery
To: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>,
Ran Atkinson <rja@inner.net>
Cc: Ben Rogers <ben@ascend.com>, Dan McDonald <Dan.McDonald@Eng.sun.com>,
ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <9702110403.AA85679@aurora.cis.upenn.edu>
Message-ID: <Chameleon.855637367.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--- On Mon, 10 Feb 1997 23:02:35 -0500 "Angelos D. Keromytis" <angelos@AURORA.CIS.UPENN.EDU> wrote:
> I think that, if not mandate copying the DF bit, the new drafts should
> at least present the benefits of doing so and provide guidelines to
> anyone who wants to have his implementation allow PathMTU. Or it could
> be a separate document altogether.
If one treats the outer IP/ESP as a link-layer, then not copying the DF bit
does not break Path MTU Discovery. The MTU of the IPsec tunnel is defined
by the IPsec implementation at present.
In any event, I think it would be useful for the next set of drafts to
be clear on this matter. I'm personally indifferent about what the final
result is.
Ran
rja@inet.org
speaking only for himself
From owner-ipsec Tue Feb 11 07:46:29 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16786 for ipsec-outgoing; Tue, 11 Feb 1997 07:44:54 -0500 (EST)
Date: Tue, 11 Feb 1997 07:44:54 -0500 (EST)
Message-Id: <9702110403.AA85679@aurora.cis.upenn.edu>
To: Ran Atkinson <rja@inet.org>
Cc: Ben Rogers <ben@ascend.com>, Dan McDonald <Dan.McDonald@Eng.sun.com>,
ipsec@tis.com
Subject: Re: Path MTU Discovery
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
In message <Chameleon.855633160.rja@c8-a.snvl1.sfba.home.com>, Ran Atkinson wri
tes:
>
> In effect, ESP tunnel mode uses the outer IP as a link-layer. Copying
>DF bit is not prohibited for IPsec tunneling, but neither is it required
>for IPsec tunneling.
I think that, if not mandate copying the DF bit, the new drafts should
at least present the benefits of doing so and provide guidelines to
anyone who wants to have his implementation allow PathMTU. Or it could
be a separate document altogether.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMv/vWr0pBjh2h1kFAQGX4gQAqWztVD0sSQ5Mn12W3Vq1IWg94XhA29Eo
X424Vc0se7CMe8SKaHoMlH6KekOazcI6wK/UPj3xnGPCJCNXf8jSf9/JjlONchTo
1jKch48MWPRC2NaeHpc05Zay9lIR7Ett7S22ZhrPHU1tOKCRlEWs+zxGdKo2T5QA
+rCt1gpl5NY=
=0AT2
-----END PGP SIGNATURE-----
From owner-ipsec Tue Feb 11 07:46:34 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16800 for ipsec-outgoing; Tue, 11 Feb 1997 07:46:23 -0500 (EST)
Date: Tue, 11 Feb 1997 17:17:48 +1100 (EST)
From: Kent Fitch <Kent.Fitch@its.csiro.au>
X-Sender: fit106@commsun
To: ipsec@tis.com
Subject: ANX IPSEC bakeoff
Message-ID: <Pine.GSO.3.93.970211171600.28376Q-100000@commsun>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> At 04:44 PM 2/8/97 -0800, Derrell Piper wrote:
> >There was clear consensus at the ANX IPSEC bakeoff last week to ...
Are there any details available of what happened at this bakeoff?
Kent Fitch Ph: +61 6 276 6711
ITS CSIRO Canberra Australia kent.fitch@its.csiro.au
From owner-ipsec Tue Feb 11 09:16:32 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17389 for ipsec-outgoing; Tue, 11 Feb 1997 09:14:02 -0500 (EST)
Date: Tue, 11 Feb 1997 09:17:01 -0500
From: dpkemp@missi.ncsc.mil (David P. Kemp)
Message-Id: <199702111417.JAA10584@argon.ncsc.mil>
To: rja@inet.org, palamber@us.oracle.com
Subject: RE: replay field size straw poll
Cc: ipsec@tis.com
X-Sun-Charset: US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>
> The questions are:
>
> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
> If they have a fixed size counter, what size should it be? (32 bits/64 bits)
> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care)
>
1) AH and ESP should have a fixed size replay counter (Yes).
Rationale: I don't see any incremental benefit in being able to negotiate
a replay counter size online, or in allowing different transform documents
to specify different sizes. The KISS principle says make it fixed.
1a) AH and ESP should have the same fixed size.
Rationale: no benefit in different sizes.
64 bit alignment can be achieved by MBZ pad fields.
2) The fixed size should be 32 bits.
Rationale: is there any incremental benefit in replay protection beyond
4G packets? (4K seconds, or over an hour, at 1M packets/second). Is it
too big a burden to refresh keys every 4G packets, even if you believe
the crypto algorithm is strong enough to use for longer?
3) SHA should be truncated to 128 bits. (Yes)
Rationale: I'm not a cryptographer, but I am persuaded by Hugo's
arguments that truncating HMAC-SHA to 128 bits is beneficial to
security robustness. At worst, I don't believe truncating SHA
could possibly result in a less secure HMAC than using MD5.
From owner-ipsec Tue Feb 11 09:51:35 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17590 for ipsec-outgoing; Tue, 11 Feb 1997 09:51:13 -0500 (EST)
Message-Id: <3.0.32.19970211084836.009117e0@dilbert.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Feb 1997 08:54:20 -0500
To: Kent Fitch <Kent.Fitch@its.csiro.au>, ipsec@tis.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: ANX IPSEC bakeoff
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 05:17 PM 2/11/97 +1100, you wrote:
>> At 04:44 PM 2/8/97 -0800, Derrell Piper wrote:
>> >There was clear consensus at the ANX IPSEC bakeoff last week to ...
>
>Are there any details available of what happened at this bakeoff?
>
They will be posted early next week. We first want a group review of our
report and consensus signoff by all parties on what we learned.
Our lawyers tell us this is the way of business ;)
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
From owner-ipsec Tue Feb 11 15:39:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19770 for ipsec-outgoing; Tue, 11 Feb 1997 15:34:13 -0500 (EST)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970211193250Z-2594@tsntsrv2.timestep.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>, "'Ran Atkinson'" <rja@inet.org>
Subject: RE: replay field size
Date: Tue, 11 Feb 1997 14:32:50 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>
>>Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't
>>Care)
Yes.
>>If they have a fixed size counter, what size should it be? (32 bits/64 bits)
Don't Care. Although, a 32-bit replay field might be easier to code on
a 32-bit CPU than a 64-bit replay. I'm not sure since I haven't seen
any sample code for 64-bit replay protection.
>>Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't
>>Care)
No, I don't think that the digest size should be truncated to fit a
64-bit alignment. That is not what the digest is intended to provide.
Padding would be preferable.
From owner-ipsec Tue Feb 11 15:39:56 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19741 for ipsec-outgoing; Tue, 11 Feb 1997 15:34:01 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007801af267ca0d15a@[128.33.229.235]>
In-Reply-To: <199702111417.JAA10584@argon.ncsc.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 11 Feb 1997 14:50:39 -0500
To: dpkemp@missi.ncsc.mil (David P. Kemp)
From: Stephen Kent <kent@bbn.com>
Subject: RE: replay field size straw poll
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
David,
I concurr with all three of your points re anti-replay field size
and hash size. I'd also like to add the observation that I think we will
have errors in implementations of the anti-replay windows, because of the
need for the modular arithmetic (since we are not starting the counters at
0 or 1). So, having a single size counter for both AH and ESP may further
minimize the time it will take to get the bugs out of this code.
As editor for the AH and ESP specs, based on the traffic I've seen
this last 2 weeks, I'm planing to go with 32-bit counters for both and to
assume that the HMAC value will be 128 bits, to help resolve the alignment
problem. If there are strong objections to this tact, I'd like to hear by
2/14.
Steve
From owner-ipsec Tue Feb 11 15:39:57 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19797 for ipsec-outgoing; Tue, 11 Feb 1997 15:34:18 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199702111926.LAA13021@kebe.eng.sun.com>
Subject: RE: replay field size
To: ipsec@tis.com
Date: Tue, 11 Feb 1997 11:26:45 -0800 (PST)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't
> Care)
No.
Listen folks, it ain't that hard to build. Replay counter size is a function
of what is negotiated in the SA. You have all the data right there. Use the
information in the association and set your pointers accordingly. The
annoyance of checking for variable-sized replay counters is lost in the noise
of a CPU-hungry HMAC calculation. Even if you have hardware-assist on the
HMAC, the memory access time will at least be dominant, if not overwhelming.
Let's not forget IPv6 alignment requirements, too! Though admittedly,
creative padding can fix this problem.
> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't
> Care)
Yes, simply because I trust Hugo's opinion on this.
Dan
From owner-ipsec Tue Feb 11 15:41:52 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19968 for ipsec-outgoing; Tue, 11 Feb 1997 15:39:02 -0500 (EST)
From: Robert Glenn <glenn@snad.ncsl.nist.gov>
Date: Tue, 11 Feb 1997 15:43:11 -0500 (EST)
Message-Id: <199702112043.PAA00838@sloth.ncsl.nist.gov>
To: ipsec@tis.com
Subject: Re: replay field size
Cc: rob.glenn@nist.gov
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
1. Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
I'm in favor of making replay prevention optional. I realize
that this isn't keeping with KISS, but I remained unconvinced
of the utility of replay prevention within IP and I'm concerned
about the added complexity this field adds to the IPSEC
process.
Making this field optional can be done by making the field a
fixed size and simply ignoring it when not in use instead of
excluding it (non-fixed size=0). So for now, ...Don't Care
with an inclination toward Yes.
2. If they have a fixed size counter, what size should it be? (32 bits/64 bits)
I'd rather have 64 bits with the ability to negotiate the
number of bits out of the 64 to use for re-keying purposes.
Along these lines, 0 would be an allowable value. This could
even be worded that you MUST support 0-32 bits and SHOULD
support 33-64 bits.
3. Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care)
Actually, I don't care, but I'm inclined to go with truncation.
Rob G.
From owner-ipsec Tue Feb 11 16:32:24 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA20578 for ipsec-outgoing; Tue, 11 Feb 1997 16:29:38 -0500 (EST)
Date: Tue, 11 Feb 97 16:27:43 EST
From: mjo@tycho.ncsc.mil (Michael J. Oehler)
Message-Id: <9702112127.AA27443@tarius.tycho.ncsc.mil>
To: ipsec@tis.com
Subject: RE: replay field size
Cc: rja@inet.org, palamber@us.oracle.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>From: Ran Atkinson <rja@inet.org> Date: Tue, 11 Feb 97 03:53:56
>
> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
> If they have a fixed size counter, what size should it be? (32 bits/64 bits)
> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care)
>
1. Permit optional replay counter.
2. 64 bit Replay Counter.
A 64 bit replay field does not preclude an implementation from preforming
a re-key sooner. The AH header will be 64 bit aligned without adding a
reserved field which wastes bandwidth and in that spirit
(in addition to Hugo's technical input).
3. Truncate the SHA-1 to 128 bits
The format for MD5 and SHA will then be identical.
Another conundrum
-Mike
From owner-ipsec Tue Feb 11 17:16:59 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA20867 for ipsec-outgoing; Tue, 11 Feb 1997 17:13:43 -0500 (EST)
Message-Id: <199702112214.RAA09176@smb.research.att.com>
X-Authentication-Warning: smb.research.att.com: smb owned process doing -bs
To: Stephen Kent <kent@bbn.com>
cc: dpkemp@missi.ncsc.mil (David P. Kemp), ipsec@tis.com
Subject: Re: replay field size straw poll
Date: Tue, 11 Feb 1997 14:14:20 -0800
From: "Steven M. Bellovin" <smb@research.att.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I concurr with all three of your points re anti-replay
field size and hash size. I'd also like to add
the observation that I think we will have errors in
implementations of the anti-replay windows, because of the
need for the modular arithmetic (since we are not starting
the counters at 0 or 1). So, having a single size counter
for both AH and ESP may further minimize the time it will
take to get the bugs out of this code.
Since this isn't a sliding window counter (as the TCP sequence number
is), I suspect that the two's-complement arithmetic that is now
universally used will make most implementations just work. It wouldn't
hurt to include a sample two lines of code showing the right way to
do the comparison, however...
From owner-ipsec Tue Feb 11 17:50:39 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21049 for ipsec-outgoing; Tue, 11 Feb 1997 17:47:16 -0500 (EST)
Date: Tue, 11 Feb 97 17:48:33 EST
From: "Whelan, Bill" <bwhelan@nei.com>
Message-Id: <9701118557.AA855712066@netx.nei.com>
To: ben@ascend.com, Dan.McDonald@Eng.sun.com, Ran Atkinson <rja@inet.org>
Cc: angelos@aurora.cis.upenn.edu, ipsec@tis.com
Subject: Re[2]: Path MTU Discovery
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Ran,
>Ben,
>
> It is worth noting that none of the IPsec RFCs cite any of the IP-in-IP
>RFCs. This is not an accident. With IPsec, one is not performing IP-in-IP.
>Rather, one is performing IP-in-AH or IP-in-ESP. The IP-in-IP RFCs don't
>include IPsec within their scope.
>
>It was quite intentional that this was done. It is equally intentional
>that the IPsec RFCs haven't been citing the IP-in-IP RFCs.
Funny, but a couple of months back when I started a mailing list discussion
due to my confusion about how to implement AH on a secure gateway, someone
pointed me to IP-in-IP. Then it all made sense to me.
The model I've been using is to compare the source and destination
addresses to the tunnel end points. If they are not equal, use IP-in-IP
then apply ESP/AH transport mode.
You're right that the IPSec RFCs do not cite RFC 1853 specifically, but the
text surrounding tunnel mode IPSec (as well as a lot of the mailing list
discussion) sure looks like IP-in-IP to me!
Bill Whelan
From owner-ipsec Wed Feb 12 01:06:48 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA23069 for ipsec-outgoing; Wed, 12 Feb 1997 01:01:22 -0500 (EST)
Date: Tue, 11 Feb 1997 22:04:54 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199702120604.WAA21035@servo.qualcomm.com>
To: mjo@tycho.ncsc.mil
CC: ipsec@tis.com, rja@inet.org, palamber@us.oracle.com
In-reply-to: <9702112127.AA27443@tarius.tycho.ncsc.mil> (mjo@tycho.ncsc.mil)
Subject: RE: replay field size
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
My opinions:
Make the replay counters 32 bits for both AH and ESP. Should be plenty
for any rational key lifetime, and the arithmetic is easier on
compilers without "long long" data types...
Shorten the SHA-1 hash to 128 bits. Probably won't be any worse than
MD-5...
Phil
From owner-ipsec Wed Feb 12 08:18:16 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25623 for ipsec-outgoing; Wed, 12 Feb 1997 08:15:32 -0500 (EST)
Message-Id: <199702121320.OAA09687@digicash.com>
From: "Niels Ferguson" <niels@DigiCash.com>
To: <ipsec@tis.com>
Subject: Re: replay field size
Date: Wed, 12 Feb 1997 14:21:00 +0100
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> From: Michael J. Oehler <mjo@tycho.ncsc.mil>
> 3. Truncate the SHA-1 to 128 bits
> The format for MD5 and SHA will then be identical.
I'm a bit concerned with all the people that are happy to truncate hash
values to shorter sizes. This should only be done if there is a thorough
understanding of the threats and desired security level. In particular, SHA
has a 160 bit output _because_ a 128-bit output was deemed too short. If
you truncate SHA to 128 bits, the work effort to create a collision goes
down from 2^80 to 2^64.
Depending on the design lifetime of this stuff, 2^64 probably isn't enough,
and one could question the wisdom of limiting the future security to 2^80
operations. Is there really such a shortage of bits that we have to reduce
bitcounts everywhere?
In general, 128-bit hash values are safe enough at the moment, but will
probably be insecure in the forseeable future. MAC codes, which are
computed with a shared secret key, can generally be truncated to half the
length of the hash; but this all depends on a detailed analysis of the
protocols.
One other note: complexity is one of the major enemies of security. Most
security systems fail because of bugs, and the number of bugs grows with
some high order of the complexity. So let us try to avoid complexity
wherever possible. In particular, negotiated field length add complexity to
save a few bits. Is this worth it?
Niels
--------------------------------------------------------------------------
Niels Ferguson, email: niels@DigiCash.com. (usual disclaimer applies)
...Of shoes, and ships, and sealing-wax, of cabbages, and kings,
And why the sea is boiling hot, and whether pigs have wings... [Carroll]
From owner-ipsec Wed Feb 12 08:58:25 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25887 for ipsec-outgoing; Wed, 12 Feb 1997 08:56:34 -0500 (EST)
Date: Wed, 12 Feb 1997 15:59:41 +0200
From: roy@CheckPoint.COM (Roy Shamir)
Message-Id: <9702121359.AA02547@dana.checkpoint.com>
To: ipsec@tis.com
Subject: RE: replay field size
X-Sun-Charset: US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
Yes.
> If they have a fixed size counter, what size should it be? (32 bits/64 bits)
32 bits.
> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care)
Yes, trucate to 128.
***************************************************************************
Roy Shamir
roy@checkpoint.com
Tel: + 972 3 6131833 extension 178
---------------------------------------------------------------------------
Check Point Software Technologies Ltd.
3A Jabotinsky St. | Tel: + 972 3 6131833
Ramat-Gan 52511 Israel | Fax: + 972 3 5759256
http://www.checkpoint.com
From owner-ipsec Wed Feb 12 09:55:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA26237 for ipsec-outgoing; Wed, 12 Feb 1997 09:54:40 -0500 (EST)
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Message-Id: <199702121457.PAA18846@kom30.ethz.ch>
Subject: Re: replay field size
To: ipsec@tis.com
Date: Wed, 12 Feb 1997 15:57:57 +0100 (MET)
In-Reply-To: <9702121359.AA02547@dana.checkpoint.com> from "Roy Shamir" at Feb 12, 97 03:59:41 pm
X-Mailer: ELM [version 2.4 PL25 PGP7]
Content-Type: text
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
straw poll
> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
>
Yes.
> If they have a fixed size counter, what size should it be? (32 bits/64 bits)
32 bits.
> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care)
>
Yes, truncate to 128.
Germano Caronni
From owner-ipsec Wed Feb 12 10:10:20 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26350 for ipsec-outgoing; Wed, 12 Feb 1997 10:10:11 -0500 (EST)
From: Robert Glenn <glenn@snad.ncsl.nist.gov>
Date: Wed, 12 Feb 1997 10:14:14 -0500 (EST)
Message-Id: <199702121514.KAA01123@sloth.ncsl.nist.gov>
To: kent@bbn.com
Subject: RE: replay field size straw poll
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
> As editor for the AH and ESP specs, based on the traffic I've seen
>this last 2 weeks, I'm planing to go with 32-bit counters for both and to
>assume that the HMAC value will be 128 bits, to help resolve the alignment
>problem. If there are strong objections to this tact, I'd like to hear by
>2/14.
Unless there is a significant change to the AH header, a 32 bit non-optional
counter and a 128 bit HMAC value will not resolve the alignment problem.
01234567012345670123456701234567
+------+-------+-------+-------+
| NH | Len | Reserved | 32 bits
+------+-------+-------+-------+
| SPI | 32 bits
+------+-------+-------+-------+
| Replay Prev. Counter | 32 bits
+------+-------+-------+-------+
| |
| HMAC |
| Value | 128 bits
| |
+------+-------+-------+-------+
total: 224 bits --- not multiple of 64
Possible solutions would be 1) 64 bit counter, 2) a 64 bit alignment pad
trailer, or 3) a 160 bit HMAC Value.
Rob G.
From owner-ipsec Wed Feb 12 10:51:19 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA26634 for ipsec-outgoing; Wed, 12 Feb 1997 10:50:57 -0500 (EST)
Date: Wed, 12 Feb 1997 16:51:54 +0100
From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO")
Message-Id: <199702121551.AA01751@orfeo.gc.ssr.upm.es>
To: ipsec@tis.com
Subject: Truncation (was Re: replay field size)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I think many of us must re-read the archives before to talk about the convenience/danger of truncation. I include the relevant mails of Hugo to this list, and the reference in RFC-2104:
-------------------------------
Begin Include message:
From ipsec-request@neptune.tis.com Sat Aug 10 00:46:39 1996
Date: Fri, 9 Aug 1996 16:16:53 -0400
From: "H.Krawczyk" <hugo@watson.ibm.com>
To: iesg@ietf.org
Subject: Re: Last Call: HMAC-IP (Truncated HMAC-SHA)
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Content-Length: 4040
>
> 2. HMAC-SHA IP Authentication with Replay Prevention
> <draft-ietf-ipsec-ah-hmac-sha-01.txt>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by August 20, 1996.
I propose the following change to the above draft (page 6).
Replace:
> (7) apply SHA to the stream generated in step (6)
> (8) The sender then zero pads the resulting hash to a 64-bit boundary
> for word alignment. The receiver compares the generated 160-bit hash
> to the first 160-bits of authentication data contained in the AH.
With:
(7) apply SHA to the stream generated in step (6) and output the first
(leftmost) 128 bits of the result.
--------
Thus, I am proposing that instead of padding the 160 bits of SHA output
to 192 bits, truncate the result to 128 bits.
Beyond the advantage for bandwidth, this truncation is plausible to
add to the security.
In general, it is an old practice to truncate MACs. In the context
of keyed-hash this has been explicitely proposed by Preneel and van
Oorschot (Crypto'95). I do not know of any *proof* that
truncating adds to the security. However, there are examples of attacks where
this is the case. And as long as you do not truncate "too much"
then everything indicates that it helps. In particular, I know of no
reason how or why truncating HMAC-SHA to 128 bits would hurt in any scenario.
Note: Be careful not to get confused with the unkeyed uses of SHA.
There, collision resistance is usually the sacred goal and truncating the
output HURTS HURTS HURTS (because of birthday attacks).
For keyed-hash for message authentication the story is very different.
Actually, the justification for truncation in [PV] is *exactly*
because it helps *against* birthday attacks.
(Yes, I know it sounds confusing but that's the way it is...)
Still in the application of HMAC the 160 bits in the definition of SHA help
as the length of the *intermediate* results of the compression function,
but not as the final result.
ANyway, truncation as a general method has an advantage (less information
available to the adversary) and a disadvantage (less bits to predict for the
attacker). When truncating 160 to 128 the advatage is far more significant
than the disadvantage (It would be different if we truncated to 64 bits;
that would make me uncomfortable -- 80 bits for SHA or even for MD5 are my
"personal minimum".)
BTW, in the RFC on HMAC that I am submitting to the IETF there is a section
on truncation of HMAC output.
----------
The patent issue:
..(deleted)
...
Date: Thu, 31 Oct 96 19:52:21 EST
To: IPSEC@TIS.COM
Cc: rob.glenn@nist.gov, shu-jen.chang@nist.gov
Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt
Sender: ipsec-approval@neptune.tis.com
Content-Length: 3592
Ref: Your note of Thu, 31 Oct 1996 19:06:38 -0500
I insist with my previous recommendation.
Define hmac-sha to output 128 bits (out of the final 160 bits result).
It most probably help security and saves up to 64 bits
in 64-bit alignments.
Hugo
PS: I am appending a message that I sent to the list a couple of months
ago on this issue. If anyone has a good reason against this recommendation
please send it to the list.
-------------
Krawczyk, et. al. Informational [Page 4]
RFC 2104 HMAC February 1997
5. Truncated output
A well-known practice with message authentication codes is to
truncate the output of the MAC and output only part of the bits
(e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some
analytical advantages of truncating the output of hash-based MAC
functions. The results in this area are not absolute as for the
overall security advantages of truncation. It has advantages (less
information on the hash result available to an attacker) and
disadvantages (less bits to predict for the attacker). Applications
of HMAC can choose to truncate the output of HMAC by outputting the t
leftmost bits of the HMAC computation for some parameter t (namely,
the computation is carried in the normal way as defined in section 2
above but the end result is truncated to t bits). We recommend that
the output length t be not less than half the length of the hash
output (to match the birthday attack bound) and not less than 80 bits
(a suitable lower bound on the number of bits that need to be
predicted by an attacker). We propose denoting a realization of HMAC
that uses a hash function H with t bits of output as HMAC-H-t. For
example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
and with the output truncated to 80 bits. (If the parameter t is not
specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
hash are output.)
...
References
[ANSI] ANSI X9.9, "American National Standard for Financial
Institution Message Authentication (Wholesale)," American
Bankers Association, 1981. Revised 1986.
[MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
1982.
[PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash
functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
Lecture Notes in Computer Science, Springer-Verlag Vol.963,
1995, pp. 1-14.
End of include message
----------------------------------
Hope this helps to understand the question.
Luis Saiz
---------------------------------------------------------------------
Protocol cryptanalysis is essentially formalized paranoia.
G. Simmons.
---------------------------------------------------------------------
From owner-ipsec Wed Feb 12 11:33:49 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27070 for ipsec-outgoing; Wed, 12 Feb 1997 11:32:53 -0500 (EST)
Date: Wed, 12 Feb 1997 11:07:35 -0500
Message-Id: <9702121607.AA10794@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Niels Ferguson" <niels@DigiCash.com>
Cc: <ipsec@tis.com>
In-Reply-To: Niels Ferguson's message of Wed, 12 Feb 1997 14:21:00 +0100,
<199702121320.OAA09687@digicash.com>
Subject: Re: replay field size
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
From: "Niels Ferguson" <niels@DigiCash.com>
Date: Wed, 12 Feb 1997 14:21:00 +0100
I'm a bit concerned with all the people that are happy to truncate hash
values to shorter sizes. This should only be done if there is a thorough
understanding of the threats and desired security level. In particular, SHA
has a 160 bit output _because_ a 128-bit output was deemed too short. If
you truncate SHA to 128 bits, the work effort to create a collision goes
down from 2^80 to 2^64.
Fundamentally, there's a design tradeoff going on here. If MD4, MD5 and
SHA are truly random functions, then the only way to attack the hash
function would be via a brute-force attack.
However, those cryptoanalysis who have been working on breaking MD5 or
MD4 are *not* making this assumption, and it's likely that if they do
"break" either crypto hash function, it will be because they have found
a way to find dependencies in the output bits. (Much like differential
crypto exploited very small, probablistic dependencies in the output of
DES.)
So, the argument goes that with SHA-1, we can give up some amount of its
protection against brute-force attacks by shortening it from 160 to 128
bits (assuming that 128 bits in length is "good enough"), and hopefully
gaining some protection against the analytic attacks that cryptographers
might later bring to bear on SHA-1. So this is an engineering tradeoff,
trading off protection against one attack with protection against
another. Furthermore, like most engineering tradeoffs, we're working
with only partial knowledge of how helpful it will really be, versus how
dangerous it is to allow brute force attacks against the shortened SHA-1
hash.
Also note that if someone performs a brute-force attack against one off
these hashes, they will only be able to break the integrity protection
for one packet, not for an entire document (as in the case in more uses
of this technology for digital signatures). In general, the
requirements for integrity protecting an IP stream aren't quite the same
as those required for digital signature in commerce.
- Ted
From owner-ipsec Wed Feb 12 11:38:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27099 for ipsec-outgoing; Wed, 12 Feb 1997 11:38:51 -0500 (EST)
Message-Id: <199702121642.LAA00795@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: Phil Karn <karn@qualcomm.com>
cc: mjo@tycho.ncsc.mil, ipsec@tis.com, rja@inet.org, palamber@us.oracle.com
Subject: Re: replay field size
In-reply-to: Your message of "Tue, 11 Feb 1997 22:04:54 PST."
<199702120604.WAA21035@servo.qualcomm.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 12 Feb 1997 11:42:36 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Phil Karn writes:
> My opinions:
>
> Make the replay counters 32 bits for both AH and ESP. Should be plenty
> for any rational key lifetime, and the arithmetic is easier on
> compilers without "long long" data types...
>
> Shorten the SHA-1 hash to 128 bits. Probably won't be any worse than
> MD-5...
Phil;
Actually, if you've been following the MAC debates, the cryptographers
say taking part of a hash makes a better MAC than taking the full one.
Perry
From owner-ipsec Wed Feb 12 11:52:16 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA27327 for ipsec-outgoing; Wed, 12 Feb 1997 11:51:52 -0500 (EST)
Message-ID: <c=US%a=_%p=IRE%l=WHO-970212170136Z-1759@who.ire.com>
From: John Keating <jkeating@ire.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>
Cc: "'keating@jagunet.com'" <keating@jagunet.com>
Subject: Re: replay field size
Date: Wed, 12 Feb 1997 12:01:36 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't
Care)
I would tend to look towards the future, and ask for negotiation. ("640K
is more than anyone would ever need!") Why hardwire something that may
need to be changed at some future date? Perhaps default to a minimum
value, but don't lock it in.
> If they have a fixed size counter, what size should it be? (32 bits/64 bits)
See above, and default to 32 bits.
> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't
Care)
I tend to lean towards leaving it at 160 bits. As some have mentioned,
it was designed at that, why weaken it by truncating it?
John W. Keating, III
jkeating@ire.com
These words are my own, and may not reflect the views of IRE, Inc.
From owner-ipsec Wed Feb 12 12:25:40 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA27524 for ipsec-outgoing; Wed, 12 Feb 1997 12:25:23 -0500 (EST)
Message-Id: <199702121729.SAA18933@digicash.com>
From: "Niels Ferguson" <niels@DigiCash.com>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: <ipsec@tis.com>
Subject: Re: replay field size
Date: Wed, 12 Feb 1997 18:30:37 +0100
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> From: Theodore Y. Ts'o <tytso@MIT.EDU>
> So, the argument goes that with SHA-1, we can give up some amount of its
> protection against brute-force attacks by shortening it from 160 to 128
> bits (assuming that 128 bits in length is "good enough"), and hopefully
> gaining some protection against the analytic attacks that cryptographers
> might later bring to bear on SHA-1. So this is an engineering tradeoff,
> trading off protection against one attack with protection against
> another. Furthermore, like most engineering tradeoffs, we're working
> with only partial knowledge of how helpful it will really be, versus how
> dangerous it is to allow brute force attacks against the shortened SHA-1
> hash.
Sorry, but this is not an engineering tradeoff. Note that the
cryptographers could just as well have truncated SHA to 128 bits to achieve
this `higher' security. What you are doing is _modifying_ the hash
function. Strictly speaking, this invalidates all earlier analytical work,
and you would have to re-do the entire security analysis of SHA. Note that
a analitical attack that gives collision on only the first 128 bits of SHA
might be possible, in which case the shortening has been very harmfull. My
main argument against shortening is that 128 bits doesn't provide enough
security against brute force attacks in 10 or 20 years time, and I am
assuming that the design life of the protocols is at least 20 years.
> Also note that if someone performs a brute-force attack against one off
> these hashes, they will only be able to break the integrity protection
> for one packet, not for an entire document (as in the case in more uses
> of this technology for digital signatures). In general, the
> requirements for integrity protecting an IP stream aren't quite the same
> as those required for digital signature in commerce.
What are the requirements? I havn't been part of the IPsec discussion, and
I don't have very much time to spend on it, but this seems to be fairly
fundamental. If integrity of a single IP packet isn't so important, then
why bother at all? Of course there are levels of security, but you might
end up doing 99% of all the work, and only getting 50% of the benefits.
BTW, if the hash is used to ensure message integrity, and there is a
separate MAC to ensure authenticity, then you could eliminate the hash. A
MAC provides integrity verification as well, but it doesn't help you
distinguish between a integrity violation and a key-mismatch. Unless
precise error reporting is very important, you could leave the hash out.
Furthermore, the MAC is more efficient, as it requires half as many bits to
provide the same security level (assuming the key is secret of course).
Niels
--------------------------------------------------------------------------
Niels Ferguson, email: niels@DigiCash.com. (usual disclaimer applies)
...Of shoes, and ships, and sealing-wax, of cabbages, and kings,
And why the sea is boiling hot, and whether pigs have wings... [Carroll]
From owner-ipsec Wed Feb 12 13:02:21 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA27837 for ipsec-outgoing; Wed, 12 Feb 1997 13:01:28 -0500 (EST)
Message-Id: <s30195f1.094@novell.com>
X-Mailer: Novell GroupWise 4.1
Date: Wed, 12 Feb 1997 10:04:46 -0800
From: CJ Lee <CJ_LEE@novell.com>
To: ipsec@tis.com
Subject: RE: replay field size -Reply
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Should AH and ESP both have a fixed size replay
counter ? (Yes/No/Don't Care)
Yes.
> If they have a fixed size counter, what size should it
be? (32 bits/64 bits)
32 bits.
> Should SHA-1 output be truncated to 128 bits from
160 bits ? (Yes/No/Don't Care)
Don't care (don't have enough knowledge to judge). In
the case of 64-bits header alignment, whether it's
necessitated by the optional RP counter or the length
of the MAC digest, trailing pad bytes can be used.
From owner-ipsec Wed Feb 12 13:33:50 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28068 for ipsec-outgoing; Wed, 12 Feb 1997 13:32:04 -0500 (EST)
Message-Id: <199702121835.AA053382556@relay.hp.com>
To: "Niels Ferguson" <niels@DigiCash.com>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, ipsec@tis.com
Subject: Re: replay field size
In-Reply-To: niels's message of Wed, 12 Feb 1997 18:30:37 +0100.
<199702121729.SAA18933@digicash.com>
Date: Wed, 12 Feb 1997 13:35:54 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> BTW, if the hash is used to ensure message integrity, and there is a
> separate MAC to ensure authenticity, then you could eliminate the hash. A
> MAC provides integrity verification as well, but it doesn't help you
> distinguish between a integrity violation and a key-mismatch.
We are discussing HMAC-SHA1, which is a MAC built out of SHA1, not
pure SHA1, which is an unkeyed hash.
See: http://www.ietf.org/html.charters/ipsec-charter.html
and, in particular, the following documents referenced from it:
RFC's:
IP Authentication Header (RFC 1826)
HMAC: Keyed-Hashing for Message Authentication (RFC 2104)
I-D's:
HMAC-SHA IP Authentication with Replay Prevention
Your time may be limited, but please read these three documents at a
minimum before commenting further on this proposal; they are
small... less than 70k of text.
- Bill
From owner-ipsec Wed Feb 12 13:35:13 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28075 for ipsec-outgoing; Wed, 12 Feb 1997 13:32:33 -0500 (EST)
Date: Wed, 12 Feb 1997 13:36:39 -0500
Message-Id: <9702121836.AA10900@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Niels Ferguson" <niels@DigiCash.com>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, <ipsec@tis.com>
In-Reply-To: Niels Ferguson's message of Wed, 12 Feb 1997 18:30:37 +0100,
<199702121729.SAA18933@digicash.com>
Subject: Re: replay field size
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
From: "Niels Ferguson" <niels@digicash.com>
Date: Wed, 12 Feb 1997 18:30:37 +0100
What are the requirements? I havn't been part of the IPsec discussion, and
I don't have very much time to spend on it, but this seems to be fairly
fundamental.....
BTW, if the hash is used to ensure message integrity, and there is a
separate MAC to ensure authenticity, then you could eliminate the hash. A
MAC provides integrity verification as well, but it doesn't help you
distinguish between a integrity violation and a key-mismatch. Unless
precise error reporting is very important, you could leave the hash out.
Furthermore, the MAC is more efficient, as it requires half as many bits to
provide the same security level (assuming the key is secret of
course).
The fact that you haven't been following the IPsec discussion is pretty
obvious now. (Although I apologize for the loose use of terminology
which has obviously confused you.)
Note that what we're talking about is HMAC SHA --- so we *are* talking
about a MAC, not just a hash. See draft-ietf-ipsec-ah-hmac-sha-04.txt
for more details. It is computed by as follows:
HMAC-SHA(K, text) = SHA (K XOR opad, SHA (K XOR ipad, text))
where ipad is the byte 0x36 repeated 64 times, and opad is the byte 0x5C
repeated 64 times.
The question is whether or not we should truncate the value returned by
the SHA in the above question to 128 bits or not. Hugo Krawczyk, a
cryptographer from IBM, has made the claim that in this case, truncating
the hash result is a *good* thing, because (a) since it is a MAC,
birthday attacks aren't an issue (as you commented because it only
requires half as many bits), and (b) it denies information to an
attacker who is trying to perform an analytic attack on the MAC.
- Ted
From owner-ipsec Wed Feb 12 13:36:12 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28082 for ipsec-outgoing; Wed, 12 Feb 1997 13:33:34 -0500 (EST)
Message-Id: <2.2.32.19970212184415.009b47dc@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Feb 1997 13:44:15 -0500
To: Robert Glenn <glenn@snad.ncsl.nist.gov>
From: Naganand Doraswamy <naganand@ftp.com>
Subject: RE: replay field size straw poll
Cc: kent@bbn.com, ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>Unless there is a significant change to the AH header, a 32 bit non-optional
>counter and a 128 bit HMAC value will not resolve the alignment problem.
>
>01234567012345670123456701234567
>+------+-------+-------+-------+
>| NH | Len | Reserved | 32 bits
>+------+-------+-------+-------+
>| SPI | 32 bits
>+------+-------+-------+-------+
>| Replay Prev. Counter | 32 bits
>+------+-------+-------+-------+
>| |
>| HMAC |
>| Value | 128 bits
>| |
>+------+-------+-------+-------+
>
> total: 224 bits --- not multiple of 64
>
>Possible solutions would be 1) 64 bit counter, 2) a 64 bit alignment pad
>trailer, or 3) a 160 bit HMAC Value.
>
I suggest that we provide a reserved field of 32 bits, either before or
after the replay counter if replay is used and also say that the transform's
output should either be padded or truncated to a multiple of 64 bits. This
will solve the 64 bit alignment problem for V6 and also make sure that the
transforms dont have to worry about the basic AH header length to decide
about 64 bit alignment.
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
From owner-ipsec Wed Feb 12 14:02:16 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA28313 for ipsec-outgoing; Wed, 12 Feb 1997 14:01:39 -0500 (EST)
From: Uri Blumenthal <uri@watson.ibm.com>
Message-Id: <9702121905.AA39146@hawpub.watson.ibm.com>
Subject: Re: replay field size
To: karn@qualcomm.com (Phil Karn)
Date: Wed, 12 Feb 1997 14:05:43 -0500 (EST)
Cc: ipsec@tis.com
In-Reply-To: <199702120604.WAA21035@servo.qualcomm.com> from "Phil Karn" at Feb 11, 97 10:04:54 pm
Reply-To: uri@watson.ibm.com
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Phil Karn says:
> Make the replay counters 32 bits for both AH and ESP. Should be plenty
> for any rational key lifetime, and the arithmetic is easier on
> compilers without "long long" data types...
Probably.
> Shorten the SHA-1 hash to 128 bits. Probably won't be any worse than
> MD-5...
Actually, 128 bits of SHA-1 will be much better than 128 bits of MD5,
as it's more resistant to Preneel and van Orschott attack.
--
Regards,
Uri uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>
From owner-ipsec Wed Feb 12 15:17:58 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA28909 for ipsec-outgoing; Wed, 12 Feb 1997 15:14:57 -0500 (EST)
Message-Id: <199702122019.VAA20459@digicash.com>
From: "Niels Ferguson" <niels@DigiCash.com>
To: <ipsec@tis.com>
Subject: Re: Truncation (was Re: replay field size)
Date: Wed, 12 Feb 1997 21:20:00 +0100
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Several people have pointed out that the discussion was about truncating
the MAC value produces by HMAC, not truncating the hash value produced by
SHA-1.
Truncating the MAC value is, as far as I know, a very good idea.
It might be worth to concider truncating the MAC to 96 bits, if this helps
reducing the total overhead. This would be big enough from a security point
of view. (See remark 4.8 in the HMAC paper "Keying Hash Functions for
Message Authentication" by Bellare, Canetti and Krawczyk, and the resently
re-posted remarks of Hugo.)
My apologies for the misunderstanding, I should have checked in the archive
what the discussion was about and not naively taken the messages at face
value.
Niels
--------------------------------------------------------------------------
Niels Ferguson, email: niels@DigiCash.com. (usual disclaimer applies)
...Of shoes, and ships, and sealing-wax, of cabbages, and kings,
And why the sea is boiling hot, and whether pigs have wings... [Carroll]
From owner-ipsec Wed Feb 12 17:15:24 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00226 for ipsec-outgoing; Wed, 12 Feb 1997 17:12:40 -0500 (EST)
Message-ID: <01BC18EF.57BA2A80@Tastid.Cisco.COM>
From: adams@cisco.com (Rob Adams)
To: rja@inet.org (rja@inet.org),
palamber@us.oracle.com (palamber@us.oracle.com)
cc: ipsec@tis.com (ipsec@tis.com)
Subject: RE: replay field size straw poll
Date: Wed, 12 Feb 1997 14:13:03 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
1) AH and ESP should have a fixed size replay counter (Yes).
It should NOT be negotiable what size the replay field is. It should
be optional whether you use the space or not.
For all the talk about padding, which I still claim is irrelevant to the issue of replay, if we
allow the field to come and go, alignment issues become even crazier.
Why don't we always leave the field there but make it optional if you use it.
If your negotiated SA indicates no replay, leave garbage in it and don't check it.
If your negotiated SA indicates use replay, then use the space accordingly.
Whatever we decide, the DOI needs to be updated to reflect the decision.
2) The fixed size should be 32 bits.
32.
3) SHA should be truncated to 128 bits?
I don't know about this one. I'm not qualified to answer this question. I'm inclined
to believe Hugo so..... I leave it to the experts and implement as directed, but I'm
inclined to say, chop it short.
Now, are we going to argue about the separate issue of padding?
-Rob Adams
Cisco Systems
From owner-ipsec Wed Feb 12 17:15:26 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00233 for ipsec-outgoing; Wed, 12 Feb 1997 17:14:06 -0500 (EST)
Message-Id: <199702122218.OAA07059@fluffy.cisco.com>
To: ipsec@tis.com
Subject: Re: replay field size
In-reply-to: Your message of "Tue, 11 Feb 1997 03:53:56 EST."
<Chameleon.855637101.rja@c8-a.snvl1.sfba.home.com>
Date: Wed, 12 Feb 1997 14:18:07 -0800
From: Derrell Piper <piper@tgv.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
Yes.
I just don't see the need for a replay field that spans 4GB of packets. We
can always add a negotiated option within the IPSEC DOI, should we decide
that the need is there for much stronger encryption algorithms. That's the
nice thing about having a negotiated key management protocol. However I do
not believe that replay warrants a negotiated option. Any option, no
matter how small, increases the risk of non-interoperability.
ISAKMP/Oakley and IPSEC are complicated enough as it is.
>If they have a fixed size counter, what size should it be? (32 bits/64 bits)
32-bits.
Add a separate padding field if you want 64-bit alignment in IPv4. You
have to ask yourself though what effect aligning just these particular
headers is going to have on overall processing of IPv4 IP... I think it's
lost in the noise.
>Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care)
A much harder question. Like many, I tend to want to accept Hugo's
recommendation, but I'm not qualified to judge. Obviously this question
should be decided on the merit of the strength of the HMAC though, and not
on an alignment issue. If we decide that 128-bits probably increases the
strength of the HMAC _and_ this happens to fix the alignment, great. If
not, adding padding to fix the alignment is no big deal. I personally
don't care about the size of the packet.
It seems we really don't have concensus on whether or not 64-bit alignment
is important for IPv4. My belief is that IPv4 is not inherently 64-bit
aligned and forcing the IPSEC transforms to be 64-bit aligned will not fix
this. I don't underestimate the importance of alignment for 64-bit RISC
processors; I worked in the VMS group at DEC when we were porting to Alpha.
However folks like Phil Karn have, in the past, been quite vocal about
keeping the number of bytes to a minimum and 32-bits _is_ the natural
alignment for the rest of IPv4.
I'd like to see us come to consensus on the 64-bit alignment issue now too.
What are other working groups doing with respect to IPv6/IPv4 alignment?
Derrell
From owner-ipsec Wed Feb 12 17:32:33 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA00371 for ipsec-outgoing; Wed, 12 Feb 1997 17:31:09 -0500 (EST)
Message-Id: <3.0.32.19970212143101.0094cb40@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 12 Feb 1997 14:31:04 -0800
To: Ran Atkinson <rja@inet.org>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: RE: replay field size
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
Yes.
>If they have a fixed size counter, what size should it be? (32 bits/64 bits)
32-bits, using whatever padding is necessary to achieve the required
alignment for IPv6
>Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't
Care)
Don't care (don't know enough about the underlying merits).
From owner-ipsec Wed Feb 12 19:07:59 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00767 for ipsec-outgoing; Wed, 12 Feb 1997 19:03:10 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199702130007.QAA28204@kebe.eng.sun.com>
Subject: "Transforms" per se going away?
To: ipsec@tis.com
Date: Wed, 12 Feb 1997 16:07:09 -0800 (PST)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
While I hate to interrupt the replay-field size discussion, I have something
else that needs to be brought to the attention of the general IPsec mailing
list.
While discussing the next round of PF_KEY tweaks, something I thought was
common knowledge apparently is not. This may also explain why we haven't
seen updates on ISAKMP, IPsec DOI, and other goodies yet.
Anyway, lemme quote the text
> By the way, if transforms are going away somebody should alert the ISAKMP
> folks and Derrell Piper (IPsec DOI author). The transform payload has a
> "transform id" entry (using a transform number from the DOI doc) and
> attributes of that transform. The way the documents are now, ISAKMP
> negotiates a transform (DES-CBC-HMAC-MD5-REPLAY) and approriate attributes
> (e.g. lifetime), not a jumble of attributes (DES-CBC, lifetime, HMAC-MD5,
> etc).
*I* was under the impression that with the next round of base document
updates, the IPsec headers would move away from the "transform" concept, and
into a "pick an item off the checklist" concept. For example:
For ESP Pick One from each category:
Encryption: (DES/3DES/IDEA/RSA/rot13/...)
Authentication: (HMAC-MD5/HMAC-SHA/none/HMAC-CRC8/...)
Replay? (Yes/No)
Replay size (May be a moot point...)
[NOTE: There is no "none" for Encryption in ESP. This
is why we have AH. Remember, some of us have
to deal with export control bullsh*t.]
For AH Pick One from each category:
Authentication: (HMAC-MD5/HMAC-SHA/HMAC-CRC8/...)
Replay? (Yes/No)
Replay size (May be a moot point)
Pad to 8bytes? (Yes/No)
PLEASE NOTE RIGHT NOW THAT THIS WILL NOT CHANGE THE BITS ON THE WIRE WHICH
ARE ALREADY WELL-DEFINED, AND WORKING IN MANY PEOPLE'S CODE! (Pardon my
shouting, that's a very important property though.)
So if this is the direction we're indeed heading, we should make this clear
sooner rather than later, because certain docs (ISAKMP, IPsec DOI, PF_KEY,
and any Advanced BSD API work) will need to take this into account.
Speaking as an implementor of IPsec in my kernel, I like the concept of the
checklist, as I can make kernel-loadable _authentication_ modules and
kernel-loadable _encryption_ modules. The former I can actually just attach
to AH and ESP w/o tweaking separate ESP and AH versions.
Any comments folks? Sorry to ruin your week with something like this. I'd
much rather be writing more code myself, but this seemed important.
--
Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 <*> +
Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** |
Solaris Internet | "rising falling at force ten |
Engineering| we twist the world and ride the wind" - Rush +
From owner-ipsec Wed Feb 12 20:46:00 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA01229 for ipsec-outgoing; Wed, 12 Feb 1997 20:42:12 -0500 (EST)
Message-Id: <199702130146.RAA17392@dharkins-ss20.cisco.com>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
Cc: ipsec@tis.com
Subject: Re: "Transforms" per se going away?
In-Reply-To: Your message of "Wed, 12 Feb 1997 16:07:09 PST."
<199702130007.QAA28204@kebe.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Feb 1997 17:46:36 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan McDonald wrote:
> *I* was under the impression that with the next round of base document
> updates, the IPsec headers would move away from the "transform" concept, and
> into a "pick an item off the checklist" concept.
[example snipped]
> PLEASE NOTE RIGHT NOW THAT THIS WILL NOT CHANGE THE BITS ON THE WIRE WHICH
> ARE ALREADY WELL-DEFINED, AND WORKING IN MANY PEOPLE'S CODE! (Pardon my
> shouting, that's a very important property though.)
It will change many working ISAKMP implementations which also put bits on
the wire in a well-defined manner. Doing away with the transform and making
everything an attribute will change existing payloads and the way payloads
are constructed and processed. Not that this is necessarily a bad thing,
just that these changes are not completely editorial and everyone needs to
understand that.
Dan.
-------------------------------------------------------------------------------
Dan Harkins | E-mail: dharkins@cisco.com
Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905
170 W. Tasman Drive | fax: +1 (408) 526-4952
San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W
-------------------------------------------------------------------------------
For your safety and the safety of others: concealed carry, and strong crypto
-------------------------------------------------------------------------------
From owner-ipsec Wed Feb 12 22:52:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01768 for ipsec-outgoing; Wed, 12 Feb 1997 22:47:44 -0500 (EST)
Date: Thu, 13 Feb 97 03:45:21 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: replay field size
To: Derrell Piper <piper@tgv.com>, ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199702122218.OAA07059@fluffy.cisco.com>
Message-ID: <Chameleon.855805681.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Derrell,
The IPng Working Group decided a long while back that all headers used
with IPv6 MUST be 64-bit aligned. If the IPsec WG wants to not support
64-bit alignment, that matter would have to be also raised for discussion
with the IPng Working Group for their approval (in addition to normal
IESG approvals). In short, the topic of alignment is broader than just
the IPsec WG and will need broader review and consensus before it changes.
This is just to clarify the process, not to argue pro or con.
Ran
rja@inet.org
From owner-ipsec Wed Feb 12 23:03:35 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01843 for ipsec-outgoing; Wed, 12 Feb 1997 22:59:45 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007800af27a710f224@[128.33.229.246]>
In-Reply-To: <199702111926.LAA13021@kebe.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Feb 1997 12:09:22 -0500
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
From: Stephen Kent <kent@bbn.com>
Subject: RE: replay field size
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan,
I agree that one can negotiate the counter size during SA
negotiation, so the issues is not one of steady state overhead. The issue
is one of added complexity in the implementation, which is greater if we
support two counter sizes vs. a single counter size. We can debate just how
much complexity is involved, but first I suggest that we explore what
motivates any added complexity.
Steve
From owner-ipsec Wed Feb 12 23:03:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01852 for ipsec-outgoing; Wed, 12 Feb 1997 22:59:49 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007801af283b28266e@[128.33.229.246]>
In-Reply-To: <199702112214.RAA09176@smb.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Feb 1997 22:31:58 -0500
To: "Steven M. Bellovin" <smb@research.att.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: replay field size straw poll
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
This is a sort of sliding window counter, in that one accepts
potentially old messages within a negotiated window and matches the
sequence number against the log of received messages within that window. I
agree that this is different from TCP window arithmetic, but it still
strikes me as sufficiently complex as to be a likely source of bugs, at
least initially.
Steve
From owner-ipsec Wed Feb 12 23:03:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01851 for ipsec-outgoing; Wed, 12 Feb 1997 22:59:50 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007802af27ed566718@[128.33.229.246]>
In-Reply-To: <Chameleon.855637101.rja@c8-a.snvl1.sfba.home.com>
References: <01BC1774.B4080180@Tastid.Cisco.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Feb 1997 23:01:10 -0500
To: Ran Atkinson <rja@inet.org>
From: Stephen Kent <kent@bbn.com>
Subject: RE: replay field size
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Whoops!
I didn't read all the way to the end of Ran's message from Tuesday, so when
I responded to David Kemp's straw poll message, I didn't realize that I was
proposing to make editorial decisions prior to the deadline for the straw
poll (and without the benefit of the private responses to the poll).
Please ignore the deadline from my message. I'll await the outcome of the
straw poll, as reported by Ran and Paul, before making the necessary edits
to AH and ESP.
Steve
From owner-ipsec Wed Feb 12 23:03:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA01850 for ipsec-outgoing; Wed, 12 Feb 1997 22:59:50 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007800af283a1fe847@[128.33.229.246]>
In-Reply-To: <199702112043.PAA00838@sloth.ncsl.nist.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Feb 1997 22:29:20 -0500
To: Robert Glenn <glenn@snad.ncsl.nist.gov>
From: Stephen Kent <kent@bbn.com>
Subject: Re: replay field size
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Rob,
The field has been proposed as an option, not a requirement (though
compliant implementations would be required to support generation and
processing of the option. As you observe, to simplify the alignment issue,
one could always include the field even if it were not processed, at the
expense of 4 or 8 bytes.
The question of when to rekey really is independent of the counter
size, except in so far as it not being larger than the counter space. So,
I'd tend to keep these concepts separate as much as possible.
Steve
From owner-ipsec Wed Feb 12 23:04:03 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA01858 for ipsec-outgoing; Wed, 12 Feb 1997 23:00:14 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007802af283be65307@[128.33.229.246]>
In-Reply-To: <199702121320.OAA09687@digicash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Feb 1997 22:37:19 -0500
To: "Niels Ferguson" <niels@DigiCash.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: replay field size
Cc: <ipsec@tis.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Niels,
It's true that a shorter hash makes it easier to find a collision,
for a given packet, assuming a brute force search. However, Hugo's
argument suggests that because of the way we are using the hash, truncation
may make it even harder to work backwards to find the key, which poses the
really significant concern in this environment. I agree with your
observation that spending another 4 bytes is not so bad in the grand scheme
of things, but we have made similar tradeoffs in IPSEC (look at the
shortened IV techniques) before, so we have to decide why to draw the line
here.
Steve
From owner-ipsec Thu Feb 13 08:07:38 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04524 for ipsec-outgoing; Thu, 13 Feb 1997 07:45:50 -0500 (EST)
From: yael@radguard.com
Message-Id: <9702131150.AA22479@elgamal.radguard.com>
Comments: Authenticated sender is <yael@radguard.com>
To: ipsec@tis.com
Date: Thu, 13 Feb 1997 13:54:21 +0000
Subject: Re: replay field size, straw poll
X-Mailer: Pegasus Mail for Windows (v2.23)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
straw poll
> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
Yes
> If they have a fixed size counter, what size should it be? (32 bits/64 bits)
32 bits
> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't
Care)
Yes
Yael Dayan
RADGUARD Ltd.
From owner-ipsec Thu Feb 13 09:32:43 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05061 for ipsec-outgoing; Thu, 13 Feb 1997 09:12:22 -0500 (EST)
Message-Id: <2.2.32.19970213140714.006bea60@bullwinkle.bbn.com>
X-Sender: lsanchez@bullwinkle.bbn.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Feb 1997 09:07:14 -0500
To: rja@inet.org, palamber@us.oracle.com
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Subject: RE: replay field size straw poll
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
> If they have a fixed size counter, what size should it be? (32 bits/64 bits)
-Fixed size, 32 bits.
> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't
Care)
- Yes.
Luis
From owner-ipsec Thu Feb 13 09:45:02 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05252 for ipsec-outgoing; Thu, 13 Feb 1997 09:35:59 -0500 (EST)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970213144042Z-3427@tsntsrv2.timestep.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: "'Dan.McDonald@Eng.sun.com'" <Dan.McDonald@Eng.sun.com>,
"'Daniel Harkins'" <dharkins@cisco.com>
Cc: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: RE: "Transforms" per se going away?
Date: Thu, 13 Feb 1997 09:40:42 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Daniel Harkins wrote:
>
>>Dan McDonald wrote:
>>> *I* was under the impression that with the next round of base document
>>> updates, the IPsec headers would move away from the "transform" concept,
>>>and
>>> into a "pick an item off the checklist" concept.
>
>>[example snipped]
>
>>> PLEASE NOTE RIGHT NOW THAT THIS WILL NOT CHANGE THE BITS ON THE WIRE WHICH
>>> ARE ALREADY WELL-DEFINED, AND WORKING IN MANY PEOPLE'S CODE! (Pardon my
>>> shouting, that's a very important property though.)
>
>>It will change many working ISAKMP implementations which also put bits on
>>the wire in a well-defined manner. Doing away with the transform and making
>>everything an attribute will change existing payloads and the way payloads
>>are constructed and processed. Not that this is necessarily a bad thing,
>>just that these changes are not completely editorial and everyone needs to
>>understand that.
We shuold make every effort to maintain backwards compatibility with the
current transforms, but in the future we should be looking at moving
away from the "Transform" concept. For IPSEC-DOI, we could create a
TRANSFORM ID that allows us to define the transform's parameters (cipher
alg, hash alg, replay, ...) all in attributes instead of having the
transform identifier specify which parameters. This way we do not have
to write hundreds of transform RFCs for every possible combination of
parameters.
Example:
ISAKMP Transform Payload:
Transform ID: TRANSFORM-ALA-CARTE
Attribute 1: Cipher Alg: 3DES
Attribute 2: Hash Alg: SHA1
Attribute 3: Keyed Alg: HMAC
Attribute 4: Replay Protection: 32-bit
From owner-ipsec Thu Feb 13 10:24:53 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05652 for ipsec-outgoing; Thu, 13 Feb 1997 10:23:00 -0500 (EST)
Message-Id: <3.0.32.19970213103115.007179ac@pop.rv.tis.com>
X-Sender: wei@pop.rv.tis.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 13 Feb 1997 10:31:15 -0800
To: Naganand Doraswamy <naganand@ftp.com>,
Robert Glenn <glenn@snad.ncsl.nist.gov>
From: wei@tis.com
Subject: RE: replay field size straw poll
Cc: kent@bbn.com, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 01:44 PM 2/12/97 -0500, Naganand Doraswamy wrote:
>
>>Unless there is a significant change to the AH header, a 32 bit non-optional
>>counter and a 128 bit HMAC value will not resolve the alignment problem.
>>
>>01234567012345670123456701234567
>>+------+-------+-------+-------+
>>| NH | Len | Reserved | 32 bits
>>+------+-------+-------+-------+
>>| SPI | 32 bits
>>+------+-------+-------+-------+
>>| Replay Prev. Counter | 32 bits
>>+------+-------+-------+-------+
>>| |
>>| HMAC |
>>| Value | 128 bits
>>| |
>>+------+-------+-------+-------+
>>
>> total: 224 bits --- not multiple of 64
>>
>>Possible solutions would be 1) 64 bit counter, 2) a 64 bit alignment pad
>>trailer, or 3) a 160 bit HMAC Value.
>>
>
>I suggest that we provide a reserved field of 32 bits, either before or
>after the replay counter if replay is used and also say that the transform's
>output should either be padded or truncated to a multiple of 64 bits. This
>will solve the 64 bit alignment problem for V6 and also make sure that the
>transforms dont have to worry about the basic AH header length to decide
>about 64 bit alignment.
I think the reserved field should be used as the flag field to allow the
flexible configuration of AH. The reserved field is just wasted since both
the length and the flag will make the AH header for any future use and ease
the inter-operatability of any AHs.
From owner-ipsec Thu Feb 13 10:29:31 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA05668 for ipsec-outgoing; Thu, 13 Feb 1997 10:27:28 -0500 (EST)
Date: Thu, 13 Feb 97 15:21:16 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: replay field size
To: Robert Glenn <glenn@snad.ncsl.nist.gov>, Stephen Kent <kent@bbn.com>
Cc: ipsec@tis.com
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <v03007800af283a1fe847@[128.33.229.246]>
Message-ID: <Chameleon.855847666.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
As you note, one can rekey more frequently than when the counter runs
out. However, the counter size does present an upper bound to the rekey
interval. In this way, they are related. This relationship does need
to be carefully considered by the working group, IMHO.
For example, I am aware of commercial encrypting router products
(not cisco) that can handle a full IP stream at OC-3c rates (155 Mbps).
Based on the relatively small size of a large percentage of IP datagrams
(as measured on a well-known OC-3 trans-Atlantic IP link), this is not
a particularly long time interval between rekeys forced by a 32-bit
replay counter.
By contrast, a 64-bit replay counter would not increase the size
of the overall packet because it would just eliminate 32-bits of
padding (that would be needed otherwise for IPv6 compliance). However,
a 64-bit replay counter would very significantly increase the upper
bound and make premature forced rekeying a non-issue for the overwhelming
majority of cases.
This argues that a 64-bit replay counter would best further the WG's
goal of maintaining a set of specifications that work equally well with
any cryptographic algorithm.
Ran
rja@inet.org
From owner-ipsec Thu Feb 13 11:36:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06187 for ipsec-outgoing; Thu, 13 Feb 1997 11:35:30 -0500 (EST)
Message-Id: <199702131634.IAA15027@mailsun3-fddi.us.oracle.com>
Date: 13 Feb 97 00:20:56 -0800
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@tis.com
Subject: Re: IPsec hardware accelerators (Rainbow warning)
Cc: gnu@toad.com
MIME-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.0.4.0.25)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
An old message (Jan.) that seems to have been stuck in one of my out boxes ...
Paul
------------------
John, please be fair about "compatibility":
>The Clipper Chip and its follow-on
>products are not compatible with the IPSEC protocols,
>because they use an undocumented encryption algorithm
>and because they are designed to
>undermine rather than provide secure operation.
Undocumented cryptographic algorithms are very compatible with IPSEC.
Cryptographic flexibility is one of the main design features of this set of
protocols. It is true that our IPSEC set of mandatory to implement algorithms
will never contain a undocumented encryption algorithm.
There is no reason that the "encapsulating" protocol (ESP) could not use
anyones favorite algorithm (documented or not). The ISAKMP negotiation should
allow selection of a common algorithm between two IPSEC systems. It just so
happens that the "favorite" algorithms of the US Government are available in
the Fortezza card.
I also believe that cryptographic algorithms are "stronger" when they are not
published. So, Fortezza is compatible with IPsec, it just is not the
recommended IETF set of algorithms :-)
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 633-2963
Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Secure Jobs" -> send resumes to: palamber@us.oracle.com
Security Architect - Hands on lead with strong design skills
Sr. Development Manager - 6+ experience with 3+ leading teams
Security Product Manager(s) - Excellent verbal and written skills
with background in security.
Senior SW Dev. - 6+ experience in SW development
SW Developer(s) - Strong coding skills and abilities
or interest in: (C++, Java, CORBA, security,
X.500, etc.)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From owner-ipsec Thu Feb 13 11:36:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06180 for ipsec-outgoing; Thu, 13 Feb 1997 11:35:00 -0500 (EST)
Message-Id: <199702131637.LAA02391@raptor.research.att.com>
To: Ran Atkinson <rja@inet.org>
cc: Robert Glenn <glenn@snad.ncsl.nist.gov>, Stephen Kent <kent@bbn.com>,
ipsec@tis.com
Subject: Re: replay field size
Date: Thu, 13 Feb 1997 11:37:39 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> As you note, one can rekey more frequently than when the counter runs
> out. However, the counter size does present an upper bound to the rekey
> interval. In this way, they are related. This relationship does need
> to be carefully considered by the working group, IMHO.
>
> For example, I am aware of commercial encrypting router products
> (not cisco) that can handle a full IP stream at OC-3c rates (155 Mbps).
> Based on the relatively small size of a large percentage of IP datagrams
> (as measured on a well-known OC-3 trans-Atlantic IP link), this is not
> a particularly long time interval between rekeys forced by a 32-bit
> replay counter.
If all packets were 40 bytes, 155Mbps is about 500K packets/second.
At 2^32 packets before rekey, the interval is over 2 hours if the link
were running flat-out. That's not onerous. Even at 1Gbps -- the
fastest I've heard anyone discuss -- it's still 20 minutes. A router
that can switch packets at that rate will likely have a moderately serious
CPU for doing new key exchanges.
But not all packets are that small; in fact, the mean packet size is
about 250 bytes (see http://www.nlanr.net/NA/Learn/packetsizes.html) --
while tinygrams are a large percentage of the packet count, they don't
account for very much of the volume by byte; what fills up OC-3 lines
is the bulk tranfers. At that rate, the rekey interval is over 15 hours
at OC-3 speeds.
But it's worse than that. At 250 bytes/packet, there are about 2^5 DES
blocks/packet, which means there are 2^37 blocks per ``full'' 32-bit
security association. That's getting unpleasantly close to the point
where linear cryptanalysis is feasbible. (Matsui's CRYPTO '94 paper
says that with 2^38 known plaintexts, the success rate is 10% with
complexity 2^50. The new ``Handbook of Applied Cryptography'' notes
that ``linear cryptanalysis is possible in a ciphertext-only
environment if some underlying plaintext redundancy is known (e.g.,
parity bits or high-order 0-bits in ASCII characters.)) I submit that
we really don't want to encrypt that much plaintext with any single key
-- ever. And of course, we don't know that linear cryptanalysis is the
ultimate attack.
Furthermore, the 2^32 packet limit is the limit for a single association.
To my mind, that makes it highly improbable that it's a real limit
in any event -- and if we get near it, we should rekey.
> By contrast, a 64-bit replay counter would not increase the size
> of the overall packet because it would just eliminate 32-bits of
> padding (that would be needed otherwise for IPv6 compliance). However,
> a 64-bit replay counter would very significantly increase the upper
> bound and make premature forced rekeying a non-issue for the overwhelming
> majority of cases.
It would also mandate an 64-bit subtraction that's unpleasant on most
of today's hosts.
> This argues that a 64-bit replay counter would best further the WG's
> goal of maintaining a set of specifications that work equally well with
> any cryptographic algorithm.
>
> Ran
> rja@inet.org
From owner-ipsec Thu Feb 13 13:12:42 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07031 for ipsec-outgoing; Thu, 13 Feb 1997 13:11:38 -0500 (EST)
Date: Thu, 13 Feb 1997 13:11:38 -0500 (EST)
Message-Id: <199702131811.NAA07031@portal.ex.tis.com>
To: ipsec@tis.com
Subject: Straw Poll and Alignment
Cc: rja@inet.org
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
Phone: +1 418 813 2054
)@F: jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Date: Thu, 13 Feb 1997 13:06:08 -0500
Sender: chk@rafael.rnd.border.com
Everyone seems to be 'voting' for a 32-bit counter *and* truncating the
SHA-1 output to 128 bits. However:
THIS BREAKS 64 BIT ALIGNMENT!!!!!
The diagram, again (thanks, Robert Glenn!):
01234567012345670123456701234567
+------+-------+-------+-------+
| NH | Len | Reserved | 32 bits
+------+-------+-------+-------+
| SPI | 32 bits
+------+-------+-------+-------+
| Replay Prev. Counter | 32 bits
+------+-------+-------+-------+
| |
| HMAC |
| Value | 128 bits
| |
+------+-------+-------+-------+
total: 224 bits --- not multiple of 64
We can *either* have a 32-bit counter, *or* a truncated SHA-1 hash. Using
both breaks alignment. (Remember, AH is required for IPv6, and IPv6 requires
64-bit alignment on all options.)
I postulate that the current straw poll is meaningless, because we're
ignoring the fundamental alignment problem. The options, as I see them, are:
AH + SPI + 32-bit replay + 32-bit pad + HMAC-MD5 256 bits
AH + SPI + 32-bit replay + HMAC-SHA-1 256 bits
or
AH + SPI + 64-bit replay + HMAC-MD5 256 bits
AH + SPI + 64-bit replay + truncated HMAC-SHA1 256 bits
All other combinations of replay and hashes break alignment, or require
additional padding.
If I remember correctly, the truncated SHA-1 discussion started from the
fact that AH + SPI + SHA-1 == 224 bits, which is also not 64-bit aligned.
The proposed solution was to truncate the SHA-1 output to 128 bits, giving a
192 bit packet (which is aligned). And that, in turn, led to the AH 64-bit
replay counter; it preserves the alignment!
Can we *please* start over on this straw poll now?
--
C. Harald Koch chk@utcc.utoronto.ca +1 416 813 2054 (voice)
"I don't suffer from insanity; I revel in it!"
-Karen Murphy <karenm@descartes.com>
From owner-ipsec Thu Feb 13 13:12:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA07004 for ipsec-outgoing; Thu, 13 Feb 1997 13:10:36 -0500 (EST)
Message-Id: <199702131810.NAA07004@portal.ex.tis.com>
Date: Thu, 13 Feb 1997 10:15:34 -0800
To: John Keating <jkeating@ire.com>, "'ipsec@tis.com'" <ipsec@tis.com>
From: wei@tis.com
Subject: Re: replay field size
Cc: "'keating@jagunet.com'" <keating@jagunet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 12:01 PM 2/12/97 -0500, John Keating wrote:
>> Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't
>Care)
>
>I would tend to look towards the future, and ask for negotiation. ("640K
>is more than anyone would ever need!") Why hardwire something that may
>need to be changed at some future date? Perhaps default to a minimum
>value, but don't lock it in.
Agree.
I don't see why ESP need the replay counter? The IV along with ESP header
is also functioning as a replay preventor.
For AH, however, it should have the replay counter. There should be a flag
field in the AH header to indicate if the parket include the replay or not
and other values in the future. I think the reserve field are wasted. It
should be removed and used as the flag (16 bits) in stead. In this way, one
can flexibly add/change any fields in the future or live along with
variable AH.
I strongly disagree any FIXED agreement without flexibility fields.
>
>> If they have a fixed size counter, what size should it be? (32 bits/64
bits)
>
>See above, and default to 32 bits.
>
>> Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't
>Care)
With the AH flag, one can use whatever they like.
>
>I tend to lean towards leaving it at 160 bits. As some have mentioned,
>it was designed at that, why weaken it by truncating it?
Same as above.
Wei Xu
Trusted Information Systems, Inc
From owner-ipsec Thu Feb 13 16:23:05 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08344 for ipsec-outgoing; Thu, 13 Feb 1997 16:20:36 -0500 (EST)
Message-ID: <01BC19B1.72DCA5A0@Tastid.Cisco.COM>
From: adams@cisco.com (Rob Adams)
To: ipsec@tis.com (ipsec@tis.com), chk@utcc.utoronto.ca ('C. Harald Koch')
cc: rja@inet.org (rja@inet.org)
Subject: RE: Straw Poll and Alignment
Date: Thu, 13 Feb 1997 13:25:46 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
No need to start the straw poll over. I don't understand our insistance on linking the size of the
fields with alignment of the header. If we need to align the header, then add padding. Period.
The size of a field should be appropriate for the field's use and the field's use alone.
Mr. Bellovin's post this morning about a 64 vs. 32 bit replay counter should be convincing enough
about an rekeying issues. Hugo et al. believe that it is more secure to truncate SHA.
So, 32 bit replay makes sense for replay's sake.
Truncating SHA is more secure.
Therefore, 32 bit replay field, 128 bit Digest field.
Now, let's talk about alignment.
(also, please let us not forget that having the *existance* of the replay field be optional
only further complicates alignment issues.)
-Rob
----------
From: C. Harald Koch[SMTP:chk@utcc.utoronto.ca]
Sent: Thursday, February 13, 1997 10:11 AM
To: ipsec@tis.com
Cc: rja@inet.org
Subject: Straw Poll and Alignment
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Date: Thu, 13 Feb 1997 13:06:08 -0500
Sender: chk@rafael.rnd.border.com
Everyone seems to be 'voting' for a 32-bit counter *and* truncating the
SHA-1 output to 128 bits. However:
THIS BREAKS 64 BIT ALIGNMENT!!!!!
The diagram, again (thanks, Robert Glenn!):
01234567012345670123456701234567
+------+-------+-------+-------+
| NH | Len | Reserved | 32 bits
+------+-------+-------+-------+
| SPI | 32 bits
+------+-------+-------+-------+
| Replay Prev. Counter | 32 bits
+------+-------+-------+-------+
| |
| HMAC |
| Value | 128 bits
| |
+------+-------+-------+-------+
total: 224 bits --- not multiple of 64
We can *either* have a 32-bit counter, *or* a truncated SHA-1 hash. Using
both breaks alignment. (Remember, AH is required for IPv6, and IPv6 requires
64-bit alignment on all options.)
I postulate that the current straw poll is meaningless, because we're
ignoring the fundamental alignment problem. The options, as I see them, are:
AH + SPI + 32-bit replay + 32-bit pad + HMAC-MD5 256 bits
AH + SPI + 32-bit replay + HMAC-SHA-1 256 bits
or
AH + SPI + 64-bit replay + HMAC-MD5 256 bits
AH + SPI + 64-bit replay + truncated HMAC-SHA1 256 bits
All other combinations of replay and hashes break alignment, or require
additional padding.
If I remember correctly, the truncated SHA-1 discussion started from the
fact that AH + SPI + SHA-1 == 224 bits, which is also not 64-bit aligned.
The proposed solution was to truncate the SHA-1 output to 128 bits, giving a
192 bit packet (which is aligned). And that, in turn, led to the AH 64-bit
replay counter; it preserves the alignment!
Can we *please* start over on this straw poll now?
--
C. Harald Koch chk@utcc.utoronto.ca +1 416 813 2054 (voice)
"I don't suffer from insanity; I revel in it!"
-Karen Murphy <karenm@descartes.com>
From owner-ipsec Thu Feb 13 16:35:17 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA08546 for ipsec-outgoing; Thu, 13 Feb 1997 16:35:08 -0500 (EST)
Message-Id: <199702132139.QAA28429@rafael.rnd.border.com>
To: adams@cisco.com (Rob Adams)
cc: ipsec@tis.com (ipsec@tis.com), rja@inet.org (rja@inet.org)
Subject: Re: Straw Poll and Alignment
References: <01BC19B1.72DCA5A0@Tastid.Cisco.COM>
In-reply-to: adams's message of "Thu, 13 Feb 1997 16:25:46 -0500".
<01BC19B1.72DCA5A0@Tastid.Cisco.COM>
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
Date: Thu, 13 Feb 1997 16:39:06 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <01BC19B1.72DCA5A0@Tastid.Cisco.COM>, Rob Adams writes:
>
> I don't understand our insistance on linking the size of the
> fields with alignment of the header.
Ok, maybe I'm over-reacting. I just think it's foolish to throw away
information (the extra 32-bits of MAC) only to replace it with padding.
OTOH, I admit that doing so does make MD5 and SHA-1 processing identical,
which again simplifies code, which is the object of this whole process...
(I'll calm down now...)
>
> Mr. Bellovin's post this morning about a 64 vs. 32 bit replay counter should be convincing enough
> about an rekeying issues.
Agreed.
> Hugo et al. believe that it is more secure to truncate SHA.
I think that's a bit strong. I read their messages as "it doesn't detract
from the security, and it *may* increase the security".
--
Harald Koch
chk@utcc.utoronto.ca
From owner-ipsec Thu Feb 13 17:29:09 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA08880 for ipsec-outgoing; Thu, 13 Feb 1997 17:26:40 -0500 (EST)
Date: Thu, 13 Feb 1997 17:30:43 -0500
Message-Id: <9702132230.AA11781@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
Cc: adams@cisco.com, ipsec@tis.com, rja@inet.org
In-Reply-To: C. Harald Koch's message of Thu, 13 Feb 1997 16:39:06 -0500,
<199702132139.QAA28429@rafael.rnd.border.com>
Subject: Re: Straw Poll and Alignment
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
Date: Thu, 13 Feb 1997 16:39:06 -0500
In message <01BC19B1.72DCA5A0@Tastid.Cisco.COM>, Rob Adams writes:
>
> I don't understand our insistance on linking the size of the
> fields with alignment of the header.
Ok, maybe I'm over-reacting. I just think it's foolish to throw away
information (the extra 32-bits of MAC) only to replace it with padding.
OTOH, I admit that doing so does make MD5 and SHA-1 processing identical,
which again simplifies code, which is the object of this whole process...
> Hugo et al. believe that it is more secure to truncate SHA.
I think that's a bit strong. I read their messages as "it doesn't detract
from the security, and it *may* increase the security".
No, what Hugo said is that for MAC's it's *good* to truncate the hash,
because by throwing away information, you are *denying* that information
to an attacker, who might use that information against you. There are
more ways to attack a crypto algorythms than just brute force attacks!
- Ted
From owner-ipsec Thu Feb 13 18:43:41 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09261 for ipsec-outgoing; Thu, 13 Feb 1997 18:37:18 -0500 (EST)
Message-Id: <199702132341.PAA18521@dharkins-ss20.cisco.com>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Edward Russell <erussell@ftp.com>
Cc: "'ipsec@tis.com'" <ipsec@tis.com>, rlfs@cisco.com, bruceg@cylink.com
Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News
In-Reply-To: Your message of "Thu, 06 Feb 1997 12:33:16 EST."
<01BC1429.F844BBC0@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Feb 1997 15:41:36 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Edward Russell wrote:
> At the interoperability event in Dallas, it appears that
> the BSAFE SHA is incompatible with the CYLINK SHA.
>
> In addition it appears that
> BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman
Both these problems are related to the underlying representation of numbers
in the Cylink library as LSB first as opposed to MSB first. All numbers on
the wire should be MSB first, they were not.
These problems will be taken care of in the next release of Cylink's crypto
library and will be in the next release of cisco's free ISAKMP reference
implementation.
Dan
-------------------------------------------------------------------------------
Dan Harkins | E-mail: dharkins@cisco.com
Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905
170 W. Tasman Drive | fax: +1 (408) 526-4952
San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W
-------------------------------------------------------------------------------
For your safety and the safety of others: concealed carry, and strong crypto
-------------------------------------------------------------------------------
From owner-ipsec Fri Feb 14 09:22:43 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA14166 for ipsec-outgoing; Fri, 14 Feb 1997 09:18:30 -0500 (EST)
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970214140746Z-15250@bwdldb.ott.bnr.ca>
From: Greg Carter <carterg@entrust.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>
Cc: "'isakmp-oakley@cisco.com'" <isakmp-oakley@cisco.com>
Subject: Quick Mode and KE payloads
Date: Fri, 14 Feb 1997 09:07:46 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Referring to section 5.4 and Appendix A of ISAKMP\Oakley draft and
Section 4.5 of DOI draft.
ISAKMP\Oakley states that the group description attribute must be sent
for PFS in the SA being negotiated. The appendix then states that
..."Phase two attributes are defined in the applicable DOI
specification, with the exception of a group description when Quick Mode
includes an ephemeral DH exchange...."
The above wording has me a little confused.
Attribute Classes
ISAKMP\Oakley Draft
Group Description 4
DOI Draft
Enc Key Life Duration 4
Is it intended that a Quick Mode which is doing PFS would include a
proposal payload with protocol ID of ISAKMP and that the proposal would
be AND with the non-ISAKMP proposals being negotiated, in order to
specify the group. Or was it intended for the Group Description
attribute class to be unique across ISAKMP\Oakley and all DOIs so that
it maybe included in transform payloads in non-ISAKMP SAs during Quick
Mode exchanges.
I prefer the latter myself.
Thanks
Bye.
----
Greg Carter
Entrust Technologies
carterg@entrust.com
From owner-ipsec Fri Feb 14 10:20:36 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14656 for ipsec-outgoing; Fri, 14 Feb 1997 10:16:14 -0500 (EST)
Message-Id: <3.0.16.19970214100530.34cf2fc4@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Fri, 14 Feb 1997 10:19:59 -0500
To: Daniel Harkins <dharkins@cisco.com>
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
what version of cylink's code are you using NOW and do you know of a
reference (like a URL) from Cylink on this?
At 03:41 PM 2/13/97 -0800, you wrote:
>Edward Russell wrote:
>> At the interoperability event in Dallas, it appears that
>> the BSAFE SHA is incompatible with the CYLINK SHA.
>>
>> In addition it appears that
>> BSAFE Diffie-Hellman is incompatible with the CYLINK Diffie-Hellman
>
>Both these problems are related to the underlying representation of numbers
>in the Cylink library as LSB first as opposed to MSB first. All numbers on
>the wire should be MSB first, they were not.
>
>These problems will be taken care of in the next release of Cylink's crypto
>library and will be in the next release of cisco's free ISAKMP reference
>implementation.
>
> Dan
>
>---------------------------------------------------------------------------
----
>Dan Harkins | E-mail: dharkins@cisco.com
>Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905
>170 W. Tasman Drive | fax: +1 (408) 526-4952
>San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W
>---------------------------------------------------------------------------
----
>For your safety and the safety of others: concealed carry, and strong crypto
>---------------------------------------------------------------------------
----
>
>
>
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
From owner-ipsec Fri Feb 14 10:53:58 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14987 for ipsec-outgoing; Fri, 14 Feb 1997 10:53:27 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007800af29100a43d7@[128.33.229.242]>
In-Reply-To: <199702130007.QAA28204@kebe.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Feb 1997 13:45:49 -0500
To: Dan.McDonald@Eng.sun.com (Dan McDonald)
From: Stephen Kent <kent@bbn.com>
Subject: Re: "Transforms" per se going away?
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan,
I don't think my intent has been to move to exactly the "list"
approach you describe in your message. For example, not all combinations
of encryption algorithms, modes, and IV options make sense. I was
assuming that we would have a regsitered set (with the IANA) of
combinations of encryption, authentication, and anti-replay options, each
set of which defines a "transform" (using the curent terminology). This
makes clear to implementors what combinations must be supported and allows
for elimination of combinations that the community (WG?) thinks are
inappropriate, i.e., don't allocate a transform ID for a combination that
is considered "bad." The real goals of the new AH and ESP specs are to
eliminate the need to issue a combinatorial number of transform RFCs, to
centralize common definitions, etc. One can still have a fairly modular
implementation as you describe, but by grouping the attributes of
transforms, one also can accommodate less modular implementations as well.
Steve
From owner-ipsec Fri Feb 14 11:16:50 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA15161 for ipsec-outgoing; Fri, 14 Feb 1997 11:16:35 -0500 (EST)
Date: Fri, 14 Feb 97 16:13:10 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: Re: replay field size
To: Ran Atkinson <rja@inner.net>, Steven Bellovin <smb@research.att.com>
Cc: ipsec@tis.com, Robert Glenn <glenn@snad.ncsl.nist.gov>,
Stephen Kent <kent@bbn.com>
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
References: <199702131637.LAA02391@raptor.research.att.com>
Message-ID: <Chameleon.855937008.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steve,
For the case where the algorithm is DES, I have no problems with
your analysis.
For the case where the algorithm is something new that appears in
future that might be significantly stronger, then the limit of 2^^32
might well be a significant issue. With negotiable counter sizes or
per-algorithm counter sizes, this would not be an issue. With a fixed
size counter, using 2^^32 for all time is an issue IMHO. However,
a 2^^64 counter space would not have that issue and would still be
a fixed size counter.
As to the 64-bit math, I'm not very concerned -- based on my work on
several different IPv6 implementations and the currently 128-bit
addresses (and the routing calculations that go along with that address
size). This was NOT a problem on an Intel Pentium.
Ran
rja@inet.org
From owner-ipsec Fri Feb 14 13:17:14 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA16099 for ipsec-outgoing; Fri, 14 Feb 1997 13:14:10 -0500 (EST)
Date: Fri, 14 Feb 1997 12:17:39 -0600
Message-Id: <199702141817.MAA25779@hosaka>
From: Jim Thompson <jim@hosaka.smallworks.com>
To: rja@inet.org
CC: rja@inner.net, smb@research.att.com, ipsec@tis.com,
glenn@snad.ncsl.nist.gov, kent@bbn.com
In-reply-to: <Chameleon.855937008.rja@c8-a.snvl1.sfba.home.com> (message from
Ran Atkinson on Fri, 14 Feb 97 16:13:10 GMT Standard Time)
Subject: Re: replay field size
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> For the case where the algorithm is something new that appears in
> future that might be significantly stronger, then the limit of 2^^32
> might well be a significant issue. With negotiable counter sizes or
> per-algorithm counter sizes, this would not be an issue. With a fixed
> size counter, using 2^^32 for all time is an issue IMHO. However,
> a 2^^64 counter space would not have that issue and would still be
> a fixed size counter.
If the application is (bulk) data xfer, then I most of the packets
will be MTU-sized (or PMTU, anyway, but for high-speed, these had
better match), and that for non data-xfer applications, (which
generate the majority of 'small' packets, it will take quite some time
to consume a 32 bit counter, when the count is packets. (e.g. 2G of
these 'smaller' packets.)
Since most applications of ipsec will care enough about security to
re-key every couple hours as a matter of course, the 'smaller packets'
shouldn't present a problem. Consider how long it would take to
consume 2^32 packets with 'telnet' or a chat client.
For bulk data, even at ethernet MTUs, the issue becomes: is
2^32 * 1500 bytes enough data to expose almost any algorithm?
32 bits should suffice.
> As to the 64-bit math, [...] This was NOT a problem on an Intel Pentium.
Not all the world is Intel. In addition, a large percentage of the
world will run IPv4 for a long time to come.
--
Jim Thompson / Smallworks, Inc. / jim@smallworks.com
512 338 0619 phone / 512 338 0625 fax
HTML: The 3270 of the 90s
From owner-ipsec Fri Feb 14 15:05:23 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16863 for ipsec-outgoing; Fri, 14 Feb 1997 15:02:40 -0500 (EST)
From: HUGO@watson.ibm.com
Message-Id: <199702142006.PAA35800@mailhub1.watson.ibm.com>
Date: Fri, 14 Feb 97 14:45:23 EST
To: IPSEC@tis.com
Subject: 32 bit counter -- 96 bit HMAC-SHA/MD5
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I haven't followed in detail all the votes but it seems
that there is signifcant support for truncated HMAC-SHA
and 32 bit counter.
Even if we allow for variable/negotiable/per-algorithm
counter size it seems that 32 bit will be prevalent for
the near future. Therefore, for the sake of easy alignment
I recommend considering going to 96-bit truncated HMAC-SHA1 and
96-bit truncated HMAC-MD5
(this is what we'd call HMAC-SHA1-96 and HMAC-MD5-96
following the terminology in RFC2104)
I personally would NOT pay with security to save 32-bit
padding. However, as already explained in the past, all the current
evidence that we have seems to suggest that some truncation
in the MAC is good. I would never go below 80 bit truncation.
However, 96 bits sounds as a perfectly wise choice.
We do NOT have PROOFS as for the effect of truncation.
We DO have some evidence to support it.
Moreover, if truncation is discovered in the future to
be bad for the combination of HMAC with some specific hash function
then that hash function will have to be dropped for its use even
without truncation. Our analysis suggests that it will be just too weak
to use with HMAC.
Bottom line: today's cryptography justifies going to 96 bits
(both MD5 and SHA1) and it helps alignment (with a typical 32-bit counter)
Hugo
PS: sorry for adding an option not covered in the straw poll...
From owner-ipsec Fri Feb 14 15:24:05 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16971 for ipsec-outgoing; Fri, 14 Feb 1997 15:22:17 -0500 (EST)
Message-Id: <199702142026.MAA19497@dharkins-ss20.cisco.com>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Rodney Thayer <rodney@sabletech.com>
Cc: ipsec@tis.com
Subject: Re: test vectors for HMAC-SHA-1 - Test Data and Bad News
In-Reply-To: Your message of "Fri, 14 Feb 1997 10:19:59 EST."
<3.0.16.19970214100530.34cf2fc4@pop3.pn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 14 Feb 1997 12:26:26 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> what version of cylink's code are you using NOW and do you know of a
> reference (like a URL) from Cylink on this?
right NOW I'm using version 2.1 and you'll have to contact Cylink
yourself for any references or URLs (besides the obvious www.cylink.com).
From owner-ipsec Fri Feb 14 15:28:42 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16996 for ipsec-outgoing; Fri, 14 Feb 1997 15:27:20 -0500 (EST)
Message-Id: <199702142031.MAA19509@dharkins-ss20.cisco.com>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Greg Carter <carterg@entrust.com>
Cc: "'ipsec@tis.com'" <ipsec@tis.com>,
"'isakmp-oakley@cisco.com'" <isakmp-oakley@cisco.com>
Subject: Re: Quick Mode and KE payloads
In-Reply-To: Your message of "Fri, 14 Feb 1997 09:07:46 EST."
<c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970214140746Z-15250@bwdldb.ott.bnr.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 14 Feb 1997 12:31:15 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Greg,
> ISAKMP\Oakley states that the group description attribute must be sent
> for PFS in the SA being negotiated. The appendix then states that
> ..."Phase two attributes are defined in the applicable DOI
> specification, with the exception of a group description when Quick Mode
> includes an ephemeral DH exchange...."
>
> The above wording has me a little confused.
Yes, it is confusing and has been changed. The "with the exeption of..."
has been stricken. All phase 2 attributes are specified by the applicable
DOI document.
> Attribute Classes
>
> ISAKMP\Oakley Draft
> Group Description 4
>
> DOI Draft
> Enc Key Life Duration 4
and:
DOI Draft
Group Description 8
Quick Mode with PFS specifies the group using this attribute.
Dan.
From owner-ipsec Fri Feb 14 15:32:11 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17033 for ipsec-outgoing; Fri, 14 Feb 1997 15:30:52 -0500 (EST)
To: HUGO@watson.ibm.com
Cc: IPSEC@tis.com
Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5
References: <199702142006.PAA35800@mailhub1.watson.ibm.com>
From: Derek Atkins <warlord@MIT.EDU>
Date: 14 Feb 1997 15:35:11 -0500
In-Reply-To: HUGO@watson.ibm.com's message of Fri, 14 Feb 97 14:45:23 EST
Message-Id: <sjmk9ob2kjk.fsf@portnoy.mit.edu>
Lines: 51
X-Mailer: Gnus v5.2.37/Emacs 19.30
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I'd be afraid that truncating to 96 bits would make brute-force
attacks too easy. We've already seen 48 bit RC5 keys falling in very
short amounts of time (hours) using brute-force methods. Today.
These MACs need to be secure for YEARS! I don't think that a 96-bit
MAC is long-enough to survive brute-force attacks for very long.
I'd be much happier with the extra 32-bits, keeping the MAC at 128.
-derek
HUGO@watson.ibm.com writes:
>
> I haven't followed in detail all the votes but it seems
> that there is signifcant support for truncated HMAC-SHA
> and 32 bit counter.
>
> Even if we allow for variable/negotiable/per-algorithm
> counter size it seems that 32 bit will be prevalent for
> the near future. Therefore, for the sake of easy alignment
> I recommend considering going to 96-bit truncated HMAC-SHA1 and
> 96-bit truncated HMAC-MD5
> (this is what we'd call HMAC-SHA1-96 and HMAC-MD5-96
> following the terminology in RFC2104)
>
> I personally would NOT pay with security to save 32-bit
> padding. However, as already explained in the past, all the current
> evidence that we have seems to suggest that some truncation
> in the MAC is good. I would never go below 80 bit truncation.
> However, 96 bits sounds as a perfectly wise choice.
>
> We do NOT have PROOFS as for the effect of truncation.
> We DO have some evidence to support it.
> Moreover, if truncation is discovered in the future to
> be bad for the combination of HMAC with some specific hash function
> then that hash function will have to be dropped for its use even
> without truncation. Our analysis suggests that it will be just too weak
> to use with HMAC.
>
> Bottom line: today's cryptography justifies going to 96 bits
> (both MD5 and SHA1) and it helps alignment (with a typical 32-bit counter)
>
> Hugo
>
> PS: sorry for adding an option not covered in the straw poll...
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec Fri Feb 14 16:19:37 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17354 for ipsec-outgoing; Fri, 14 Feb 1997 16:16:42 -0500 (EST)
Message-Id: <199702142119.QAA27941@raptor.research.att.com>
To: Derek Atkins <warlord@MIT.EDU>
cc: HUGO@watson.ibm.com, IPSEC@tis.com
Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5
Date: Fri, 14 Feb 1997 16:19:13 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I'd be afraid that truncating to 96 bits would make brute-force
attacks too easy. We've already seen 48 bit RC5 keys falling in very
short amounts of time (hours) using brute-force methods. Today.
These MACs need to be secure for YEARS! I don't think that a 96-bit
MAC is long-enough to survive brute-force attacks for very long.
No, they have to be secure for hours at best. This is for per-packet
authentication; when you rekey, old packets are useless to the adversary.
And there are no secrecy implications here -- my attacks assumed that
the key was still live.
From owner-ipsec Fri Feb 14 16:23:05 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17388 for ipsec-outgoing; Fri, 14 Feb 1997 16:21:46 -0500 (EST)
To: Steven Bellovin <smb@research.att.com>
Cc: HUGO@watson.ibm.com, IPSEC@tis.com
Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5
References: <199702142119.QAA27941@raptor.research.att.com>
From: Derek Atkins <warlord@MIT.EDU>
Date: 14 Feb 1997 16:25:43 -0500
In-Reply-To: Steven Bellovin's message of Fri, 14 Feb 1997 16:19:13 -0500
Message-Id: <sjmhgjf2i7c.fsf@portnoy.mit.edu>
Lines: 33
X-Mailer: Gnus v5.2.37/Emacs 19.30
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Steven Bellovin <smb@research.att.com> writes:
>
> I'd be afraid that truncating to 96 bits would make brute-force
> attacks too easy. We've already seen 48 bit RC5 keys falling in very
> short amounts of time (hours) using brute-force methods. Today.
> These MACs need to be secure for YEARS! I don't think that a 96-bit
> MAC is long-enough to survive brute-force attacks for very long.
>
> No, they have to be secure for hours at best. This is for per-packet
> authentication; when you rekey, old packets are useless to the adversary.
> And there are no secrecy implications here -- my attacks assumed that
> the key was still live.
Let me rephrase what I meant.. These *algorithms* need to be secure
for years (not the actual MAC values, of course those change
relatively quickly). The problem is that as computer speed increases
the amount of time required to brute-force these values will decrease.
Just look at how the time to break 40-bit keys has decreased over the
last year or two.
I'm just afraid that a 96-bit MAC might come down into this breakable
range before the algorithms get replaced. And if we limit them to 96
bits completely, eventually the brute-force mechanisms will catch up
with us.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec Fri Feb 14 16:32:43 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17432 for ipsec-outgoing; Fri, 14 Feb 1997 16:31:19 -0500 (EST)
Date: Fri, 14 Feb 1997 16:35:35 -0500
Message-Id: <9702142135.AA13130@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Derek Atkins <warlord@MIT.EDU>
Cc: HUGO@watson.ibm.com, IPSEC@tis.com
In-Reply-To: Derek Atkins's message of 14 Feb 1997 15:35:11 -0500,
<sjmk9ob2kjk.fsf@portnoy.mit.edu>
Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
From: Derek Atkins <warlord@MIT.EDU>
Date: 14 Feb 1997 15:35:11 -0500
I'd be afraid that truncating to 96 bits would make brute-force
attacks too easy. We've already seen 48 bit RC5 keys falling in very
short amounts of time (hours) using brute-force methods. Today.
These MACs need to be secure for YEARS! I don't think that a 96-bit
MAC is long-enough to survive brute-force attacks for very long.
Derek,
I'm not a cryptographer, so take my comments with a grain of
salt, but my understanding is that MAC's, unlike cryptographic
checksums, aren't subject to birthday attacks, since key used to
generate the MAC is secret. Hence, HMAC truncated to 64 bits has an
attack difficulty of O(2**64), and HMAC truncated to 96 bits has an
attack difficulty of O(2**98), NOT O(2**48).
- Ted
From owner-ipsec Fri Feb 14 16:54:31 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17588 for ipsec-outgoing; Fri, 14 Feb 1997 16:53:00 -0500 (EST)
Message-Id: <199702142153.QAA03394@raptor.research.att.com>
To: Derek Atkins <warlord@MIT.EDU>
cc: HUGO@watson.ibm.com, IPSEC@tis.com
Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5
Date: Fri, 14 Feb 1997 16:53:30 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> No, they have to be secure for hours at best. This is for per-packet
> authentication; when you rekey, old packets are useless to the adversary.
> And there are no secrecy implications here -- my attacks assumed that
> the key was still live.
Let me rephrase what I meant.. These *algorithms* need to be secure
for years (not the actual MAC values, of course those change
relatively quickly). The problem is that as computer speed increases
the amount of time required to brute-force these values will decrease.
Just look at how the time to break 40-bit keys has decreased over the
last year or two.
I'm just afraid that a 96-bit MAC might come down into this breakable
range before the algorithms get replaced. And if we limit them to 96
bits completely, eventually the brute-force mechanisms will catch up
with us.
Ah -- this makes more sense -- but I'm still not worried.
Let's consider a brute-force attack. You take a known packet, crunch
at possible keys, and find something where the first 96 bits of the
HMAC-SHA output match the observed value. But there are many possible
keys that will yield that result for this packet; most won't work for
the second packet. When you find a key that works for the first two
packets, will it work for the third? The fourth? I'm not certain what
the exact complexity of this process is, but I'm sure that it's quite
high. (I have some guesses, but I'd embarrass myself if I stated
them...) Nor does the traditional collision attack apply here; you
can't find two matching hash values offline per the van Oorschot/Wiener
'94 paper, since the key is unknown.
It would be an interesting exercise, I think, to come up with a paper
design for an HMAC cracker, with the hash length, the truncation length,
and the key length as input parameters.
One more point -- the defense has another advantage here. As the
apparent threat increases, we can cut the rekey time down. That's
just a parameter of the key exchange mechanism, not code.
From owner-ipsec Sun Feb 16 13:00:33 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28364 for ipsec-outgoing; Sun, 16 Feb 1997 12:49:52 -0500 (EST)
Date: Sun, 16 Feb 1997 18:54:04 +0100 (MET)
From: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be>
To: IPSEC@tis.com
Cc: Bart Preneel <preneel@esat.kuleuven.ac.be>
Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5
In-Reply-To: <199702142153.QAA03394@raptor.research.att.com>
Message-Id: <Pine.HPP.3.95.970216185027.19163q-100000@domein.esat.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Charset: ISO_8859-1
X-Char-Esc: 29
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
TRUNCATION of HMAC output: I support Hugo's suggestion
to go for 96 bits, but would suggest myself to even go
to 64 bits (MD5) or 80 bits (SHA-1).
parameters:
- size of key: k bits
- size of result: m bits
- size of internal memory: n bits
128 for MD5, 160 bits for SHA-1 and RIPEMD-160)
[what is RIPEMD-160? a European alternative for SHA-1
see http://www.esat.kuleuven.ac.be/~bosselae ]
We know of the following three attacks against HMAC
(there might be others, but that makes life interesting):
1. Guess the value of the MAC
Probability of success 2^{-m}.
Even for messages of high value, 64 bits is more than sufficient
for the next 10 to 15 years. 80 or 96 bits gives an ample safety
margin.
2. Brute force exhaustive key search
Needs about k/m known text-MAC pairs.
Work factor 2^{k-1}.
The work factor is essentially independent of m.
(this should answer Steve's question of Fri, 14 Feb 1997 16:53:30 -0500)
(same story as for exhaustive key search for encryption --
the difference is that the life time of a key is almost irrelevant -
only the lifetime of the system itself is relevant).
80 bits is ok for midterm, 128 bits is ok for 20 years or more.
3. Shortcut forgery attack
Needs 2^{n/2} known text-MAC pairs and 2^{n-m}$ chosen texts.
This attack becomes even more unrealistic if shortening is
applied (m < n), because then the number of chosen text increases.
The main problem is: other attacks.
If algorithm dependent attacks are ever found (extending Dobbertin's
results to MACs), they are affected by m as follows:
a. shortcut forgery attacks (IMHO not very probable):
reducing m might make the scheme weaker
b. shortcut key recovery attacks will become more difficult if
less information is given away -- fewer bits of the MAC
(I believe that this is a more likely scenario).
Also note that key recovery attacks are more serious than forgery attacks
anyway.
> Date: 14 Feb 1997 15:35:11 -0500
> From: Derek Atkins <warlord@MIT.EDU>
> To: HUGO@watson.ibm.com
> Cc: IPSEC@tis.com
> Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5
> I'd be afraid that truncating to 96 bits would make brute-force
> attacks too easy. We've already seen 48 bit RC5 keys falling in very
> short amounts of time (hours) using brute-force methods. Today.
> These MACs need to be secure for YEARS! I don't think that a 96-bit
> MAC is long-enough to survive brute-force attacks for very long.
> I'd be much happier with the extra 32-bits, keeping the MAC at 128.
> -derek
I am not aware of any brute force attack on a MAC which runs
in time 2^{m/2} (a MAC is not an unkeyed hash function).
If you know of such an attack, let me know asap.
> Date: Fri, 14 Feb 1997 16:35:35 -0500
> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
> To: Derek Atkins <warlord@MIT.EDU>
> Cc: HUGO@watson.ibm.com, IPSEC@tis.com
> Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5
>
> Derek,
> I'm not a cryptographer, so take my comments with a grain of
> salt, but my understanding is that MAC's, unlike cryptographic
> checksums, aren't subject to birthday attacks, since key used to
> generate the MAC is secret. Hence, HMAC truncated to 64 bits has an
> attack difficulty of O(2**64), and HMAC truncated to 96 bits has an
> attack difficulty of O(2**98), NOT O(2**48).
>
> - Ted
I try to be a cryptographer, and I would say
MD5 (with 128-bit key)
64 bits: 2^{128} off-line for key recovery
2^{64} known and 2^{64} chosen texts for forgery
2^{64} for guessing a MAC
96 bits: 2^{128} off-line for key recovery
2^{64} known and 2^{32} chosen texts for forgery
2^{96} for guessing a MAC
SHA-1 (with 128-bit key)
64 bits: 2^{128} off-line for key recovery
2^{80} known and 2^{96} chosen texts for forgery
2^{64} for guessing a MAC
96 bits: 2^{128} off-line for key recovery
2^{80} known and 2^{64} chosen texts for forgery
2^{96} for guessing a MAC
These are the best attacks we know of today.
Given the collision attacks on the compression function of MD5,
it seems realistic to expect that a key recovery is probably
easier than 2^{128} on the MD5 version (I have no attack yet).
But decreasing m would only help against such an attack.
Bart Preneel
-------------------------------------------------------------------------------
Katholieke Universiteit Leuven tel. +32 16 32 11 48
Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86
K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be
-------------------------------------------------------------------------------
From owner-ipsec Sun Feb 16 13:12:04 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA28472 for ipsec-outgoing; Sun, 16 Feb 1997 13:09:25 -0500 (EST)
Date: Sun, 16 Feb 1997 19:13:22 +0100 (MET)
From: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be>
To: Steven Bellovin <smb@research.att.com>
Cc: Ran Atkinson <rja@inet.org>, Robert Glenn <glenn@snad.ncsl.nist.gov>,
Stephen Kent <kent@bbn.com>, ipsec@tis.com
Subject: Re: replay field size
In-Reply-To: <199702131637.LAA02391@raptor.research.att.com>
Message-Id: <Pine.HPP.3.95.970216191232.19163r-100000@domein.esat.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Charset: ISO_8859-1
X-Char-Esc: 29
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Linear cryptanalysis of DES:
> Date: Thu, 13 Feb 1997 11:37:39 -0500
> From: Steven Bellovin <smb@research.att.com>
> To: Ran Atkinson <rja@inet.org>
> Cc: Robert Glenn <glenn@snad.ncsl.nist.gov>, Stephen Kent <kent@bbn.com>,
> ipsec@tis.com
> Subject: Re: replay field size
>
> [...]
>
> But it's worse than that. At 250 bytes/packet, there are about 2^5 DES
> blocks/packet, which means there are 2^37 blocks per ``full'' 32-bit
> security association. That's getting unpleasantly close to the point
> where linear cryptanalysis is feasible. (Matsui's CRYPTO '94 paper
> says that with 2^38 known plaintexts, the success rate is 10% with
> complexity 2^50. The new ``Handbook of Applied Cryptography'' notes
> that ``linear cryptanalysis is possible in a ciphertext-only
> environment if some underlying plaintext redundancy is known (e.g.,
> parity bits or high-order 0-bits in ASCII characters.)) I submit that
> we really don't want to encrypt that much plaintext with any single key
> -- ever. And of course, we don't know that linear cryptanalysis is the
> ultimate attack.
As far as I know, the extension of Matsui's attack to ciphertext only
(given ASCII plaintext) requires at least 2^{10} times more ciphertext
(see Matsui's Eurocrypt'93 paper). So 2^{38} known plaintexts will become
something like 2^{48} ciphertext only. This can probably be still
improved, but it is not very serious as threat.
Given the complexity of 2^{50}, it is probably much easier to build
the DES key search machine -- success probability of 1.6%), which needs
only 1 plaintext/ciphertext pair, rather than to collect all the data
on 2^{48} ciphertexts. A complexity of 2^{40} seems more realistic to me,
which implies that about 10 times more ciphertexts are required.
I would be much more concerned about the `matching ciphertext' problem of
the CBC-mode: information on the plaintext starts to leak after 2^{33}
blocks (for 2^{38} there will be already 2000 matches).
A very good reason to never encrypt more than 2^{33} plaintexts with a single key.
Bart Preneel
-------------------------------------------------------------------------------
Katholieke Universiteit Leuven tel. +32 16 32 11 48
Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86
K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be
-------------------------------------------------------------------------------
From owner-ipsec Mon Feb 17 19:16:51 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA08684 for ipsec-outgoing; Mon, 17 Feb 1997 19:10:58 -0500 (EST)
Message-Id: <3.0.32.19970217161428.009493c0@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 17 Feb 1997 16:14:33 -0800
To: ipsec@tis.com
From: Bob Monsour <rmonsour@earthlink.net>
Subject: TO COMPRESS OR NOT TO CMPRS (please reply)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Since my last posting about adding compression in the form of an "optional
feature of ESP", I have received several offline inputs from wg members.
Specifically, two issues arose:
1. What is the status of adding compression to ESP?
I know that there are some wg members who support the use of compression,
some who don't and some who haven't expressed an interest either way. Well,
the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
Be sure to copy the wg list in your reply.
2. Placement of the "packet compressed/not-compressed" byte/bit
Several people have suggested that rather than using a whole byte for this
purpose, simply "steal" the uppermost bit of the pad length field. This is
a simple solution. It was suggested to me that a maximum of 128 bytes of
padding is sufficient. Note that the preferred ESP transform for the IPSEC
DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of
padding. There are two ways to approach this issue:
(a) alter the transform draft to specify a max of 128 bytes of padding, or
(b) for implementations which do not negotiate the use of compression (for
a particular SA, or never), they can continue to use up to 255 bytes
of padding; for those that *do* support compression, the maximum
padding
would be 128 bytes.
INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to
proceed
with compression, the decision on this issue will affect the ESP draft,
the
latest of which has yet to be issued. So, please respond.
Regards,
Bob
From owner-ipsec Mon Feb 17 21:27:31 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA09533 for ipsec-outgoing; Mon, 17 Feb 1997 21:25:53 -0500 (EST)
Message-Id: <199702180230.SAA21924@dharkins-ss20.cisco.com>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Bob Monsour <rmonsour@earthlink.net>
Cc: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: Your message of "Mon, 17 Feb 1997 16:14:33 PST."
<3.0.32.19970217161428.009493c0@earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 17 Feb 1997 18:30:12 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> I know that there are some wg members who support the use of compression,
> some who don't and some who haven't expressed an interest either way. Well,
> the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
> Be sure to copy the wg list in your reply.
I support the use of compression but not in IPsec. It should be done up
higher, perhaps the transport level. It's better to compress the stream
of data before it's divided into packets than to wait and compress each
packet. I'd rather see 50 packets then 100 smaller ones.
Dan.
-------------------------------------------------------------------------------
Dan Harkins | E-mail: dharkins@cisco.com
Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905
170 W. Tasman Drive | fax: +1 (408) 526-4952
San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W
-------------------------------------------------------------------------------
For your safety and the safety of others: concealed carry, and strong crypto
-------------------------------------------------------------------------------
From owner-ipsec Tue Feb 18 05:12:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA11840 for ipsec-outgoing; Tue, 18 Feb 1997 05:10:38 -0500 (EST)
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Message-Id: <199702181014.LAA01115@kom30.ethz.ch>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
To: dharkins@cisco.com (Daniel Harkins)
Date: Tue, 18 Feb 1997 11:14:41 +0100 (MET)
Cc: rmonsour@earthlink.net, ipsec@tis.com
In-Reply-To: <199702180230.SAA21924@dharkins-ss20.cisco.com> from "Daniel Harkins" at Feb 17, 97 06:30:12 pm
X-Mailer: ELM [version 2.4 PL25 PGP7]
Content-Type: text
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Daniel Harkins wrote:
> > I know that there are some wg members who support the use of compression,
> > some who don't and some who haven't expressed an interest either way. Well,
> > the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
> > Be sure to copy the wg list in your reply.
>
> I support the use of compression but not in IPsec. It should be done up
> higher, perhaps the transport level. It's better to compress the stream
> of data before it's divided into packets than to wait and compress each
> packet. I'd rather see 50 packets then 100 smaller ones.
Compression allows for saving a valuable ressource. This might be done on
intermediate systems (e.g. firewalls) which also care about enterprise
security and to encryption. Usually in those systems no upper layer is
available.
I support compression as an optional (and important) function in ESP.
Germano
From owner-ipsec Tue Feb 18 07:49:21 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12832 for ipsec-outgoing; Tue, 18 Feb 1997 07:47:49 -0500 (EST)
Message-Id: <9702180229.AA00348@ebony.arl.wustl.edu>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 4.0 v146.2)
X-Image-Url: http://www.tik.ee.ethz.ch/~mwa/mwa.mail.tiff
In-Reply-To: <3.0.32.19970217161428.009493c0@earthlink.net>
X-Nextstep-Mailer: Mail 4.0 (Enhance 2.0b5)
From: Marcel Waldvogel <mwa@ebony.ccrc.wustl.edu>
Date: Mon, 17 Feb 97 20:26:46 -0600
To: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
References: <3.0.32.19970217161428.009493c0@earthlink.net>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, 17 Feb 1997, Bob Monsour wrote:
> 1. What is the status of adding compression to ESP?
Bob,
I think compression should officially be made an optional feature
of ESP, so that there is a defined way to negotiate the use of
compression. I think that otherwise (since compression is a Good
Thing, IMHO), several incompatible approaches will arise.
> 2. Placement of the "packet compressed/not-compressed" byte/bit
> (a) alter the transform draft to specify a max of 128 bytes of padding
I think it would be unwise to start introducing downward compatibility
features at this early stage, where no "final" commercial (or
other publicly available) versions are out yet, so it should be
very easy to change them. Those not supporting compression will
most likely not need a single byte of source change.
- -Marcel
-----BEGIN PGP SIGNATURE-----
Version: 2.6
Charset: next
iQCVAwUBMwkT7cqBByDTF1SlAQEV0QQA0HPJThF2eQ761N4hdeCnbo6i0W5HV034
MKVydLnlGttpk300xJypx0l0k1KF7/ZzlOZmyoMoKLNZBHwPzE0xGFvKKUPrf9kE
npEHbFbHP0FviBMXqAuMwyxlLu973ZEQ8DWEUazAs0W/dTJ1JcJQRknrxNyjlP4L
/l4k1Z6eYDc=
=/1zz
-----END PGP SIGNATURE-----
From owner-ipsec Tue Feb 18 10:36:36 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14320 for ipsec-outgoing; Tue, 18 Feb 1997 10:35:17 -0500 (EST)
Message-Id: <3.0.16.19970218102824.1e8ff476@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Tue, 18 Feb 1997 10:39:40 -0500
To: Bob Monsour <rmonsour@earthlink.net>
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I think there should be compression. I think stealing a bit sounds like an
acceptable scheme. I think this should be a negotiated option in a key
management context (see the DOI) to specify this. I think it should be a
bit rather than a byte in deference to the 64-bit alignment issue. I
believe the combination of using a bit and using negotiation allows
implementations to address or ignore compression in an interoperable
manner. I believe the 128-byte padding limit has no known problems, as I
recall the conversations.
At 04:14 PM 2/17/97 -0800, you wrote:
>Since my last posting about adding compression in the form of an "optional
>feature of ESP", I have received several offline inputs from wg members.
>Specifically, two issues arose:
>
>1. What is the status of adding compression to ESP?
>
> I know that there are some wg members who support the use of compression,
> some who don't and some who haven't expressed an interest either way.
Well,
> the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
> Be sure to copy the wg list in your reply.
>
>2. Placement of the "packet compressed/not-compressed" byte/bit
>
> Several people have suggested that rather than using a whole byte for this
> purpose, simply "steal" the uppermost bit of the pad length field. This is
> a simple solution. It was suggested to me that a maximum of 128 bytes of
> padding is sufficient. Note that the preferred ESP transform for the IPSEC
> DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of
> padding. There are two ways to approach this issue:
>
> (a) alter the transform draft to specify a max of 128 bytes of
padding, or
>
> (b) for implementations which do not negotiate the use of compression
(for
> a particular SA, or never), they can continue to use up to 255 bytes
> of padding; for those that *do* support compression, the maximum
>padding
> would be 128 bytes.
>
> INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to
>proceed
> with compression, the decision on this issue will affect the ESP draft,
>the
> latest of which has yet to be issued. So, please respond.
>
>Regards,
>Bob
>
>
>
>
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
From owner-ipsec Tue Feb 18 11:36:39 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14863 for ipsec-outgoing; Tue, 18 Feb 1997 11:35:38 -0500 (EST)
Message-Id: <3.0.32.19970218082333.00e166c8@netcom.com>
X-Sender: dpalma@netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 08:39:09 -0800
To: Germano Caronni <caronni@tik.ee.ethz.ch>,
dharkins@cisco.com (Daniel Harkins)
From: Derek Palma <dpalma@netcom.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: rmonsour@earthlink.net, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 11:14 AM 2/18/97 +0100, Germano Caronni wrote:
>Daniel Harkins wrote:
>> > I know that there are some wg members who support the use of
compression,
>> > some who don't and some who haven't expressed an interest either way.
Well,
>> > the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
>> > Be sure to copy the wg list in your reply.
>>
>> I support the use of compression but not in IPsec. It should be done up
>> higher, perhaps the transport level. It's better to compress the stream
>> of data before it's divided into packets than to wait and compress each
>> packet. I'd rather see 50 packets then 100 smaller ones.
>
>Compression allows for saving a valuable ressource. This might be done on
>intermediate systems (e.g. firewalls) which also care about enterprise
>security and to encryption. Usually in those systems no upper layer is
>available.
>
>I support compression as an optional (and important) function in ESP.
>
>Germano
>
>
I agree. Compression is beneficial. At the very least it is able to
compensate for IPSEC overhead which is nice in both end systems and
intermediate
systems.
Derek Palma
Net Research, Inc.
From owner-ipsec Tue Feb 18 12:05:07 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15091 for ipsec-outgoing; Tue, 18 Feb 1997 12:04:54 -0500 (EST)
Message-Id: <3.0.32.19970218114537.006fdd90@netrix.lkg.dec.com>
X-Sender: popmatt@netrix.lkg.dec.com
X-Mailer: Windows Eudora Pro Version 3.0 Demo (32)
Date: Tue, 18 Feb 1997 11:51:40 -0500
To: Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
From: Matt Thomas <matt@lkg.dec.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I want to see compression included. I don't see the new for cross-packet
compression. There is a need to negotiation compression algorithms. I
wonder if we can handle that like we handle negotiation of transforms?
(ie. if both parties agree to the same algorithm, then compression will
be used. If not, it won't.)
I also want to steal the top bit of the pad byte to use as the compression
indication. I don't, however, care if the pad is always limited to 127 bytes.
--
Matt Thomas Internet: matt@lkg.dec.com
UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/
Digital Equipment Corporation Disclaimer: This message reflects my own
Littleton, MA warped views, etc.
From owner-ipsec Tue Feb 18 12:24:24 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15295 for ipsec-outgoing; Tue, 18 Feb 1997 12:24:03 -0500 (EST)
Message-Id: <199702181700.JAA25178@stilton.cisco.com>
To: Derek Palma <dpalma@netcom.com>
cc: Germano Caronni <caronni@tik.ee.ethz.ch>,
dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net,
ipsec@tis.com
From: carrel@ipsec.org
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-reply-to: Your message of "Tue, 18 Feb 1997 08:39:09 PST."
<3.0.32.19970218082333.00e166c8@netcom.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25176.856285219.1@cisco.com>
Date: Tue, 18 Feb 1997 09:00:20 -0800
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> I agree. Compression is beneficial. At the very least it is able to
> compensate for IPSEC overhead which is nice in both end systems and
> intermediate
> systems.
Er, no. "At the very least" compression provides no benefit in packet size
and increases computational load. (I'm not sure if I'm correcting your
colloquial english or your understanding of compression.) There is no
guaranteed compression. In the case of interactive traffic like telnet,
compression will have very little benefit. In the case of ftp data traffic
(large MTU sized packets), compression _may_ save you from having to
fragment when encrypting. But only if the data is not already compressed.
In the case of ftp, data IS quite often already compressed.
Now don't get me wrong. I'd like to see the ability to support
compression. (Life is more than telnet and ftp.) But don't assume its a
panacea.
Dave
From owner-ipsec Tue Feb 18 12:26:39 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15331 for ipsec-outgoing; Tue, 18 Feb 1997 12:26:35 -0500 (EST)
Message-Id: <3.0.32.19970218121355.006fd66c@netrix.lkg.dec.com>
X-Sender: popmatt@netrix.lkg.dec.com
X-Mailer: Windows Eudora Pro Version 3.0 Demo (32)
Date: Tue, 18 Feb 1997 12:14:38 -0500
To: Daniel Harkins <dharkins@cisco.com>
From: Matt Thomas <matt@lkg.dec.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 06:30 PM 2/17/97 -0800, Daniel Harkins wrote:
>> I know that there are some wg members who support the use of compression,
>> some who don't and some who haven't expressed an interest either way.
Well,
>> the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
>> Be sure to copy the wg list in your reply.
>
>I support the use of compression but not in IPsec. It should be done up
>higher, perhaps the transport level. It's better to compress the stream
>of data before it's divided into packets than to wait and compress each
>packet. I'd rather see 50 packets then 100 smaller ones.
In a perfect world, that would be the case. But not everything will be
compressed. (telnet, IP tunnels, ftp, smtp, nntp, etc). But if you
can compress the data, you have less to encrypt and you end up sending
less bits and using less cpu to encrypt those bits.
--
Matt Thomas Internet: matt@lkg.dec.com
UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/
Digital Equipment Corporation Disclaimer: This message reflects my own
Littleton, MA warped views, etc.
From owner-ipsec Tue Feb 18 12:51:28 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15448 for ipsec-outgoing; Tue, 18 Feb 1997 12:48:10 -0500 (EST)
Message-Id: <3.0.32.19970218094734.00e13d34@netcom.com>
X-Sender: dpalma@netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 09:48:26 -0800
To: carrel@ipsec.org, Derek Palma <dpalma@netcom.com>
From: Derek Palma <dpalma@netcom.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: Germano Caronni <caronni@tik.ee.ethz.ch>,
dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net,
ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dave,
At 09:00 AM 2/18/97 -0800, carrel@ipsec.org wrote:
>> I agree. Compression is beneficial. At the very least it is able to
>> compensate for IPSEC overhead which is nice in both end systems and
>> intermediate
>> systems.
>
>Er, no. "At the very least" compression provides no benefit in packet size
>and increases computational load. (I'm not sure if I'm correcting your
>colloquial english or your understanding of compression.) There is no
>guaranteed compression. In the case of interactive traffic like telnet,
>compression will have very little benefit. In the case of ftp data traffic
>(large MTU sized packets), compression _may_ save you from having to
>fragment when encrypting. But only if the data is not already compressed.
>In the case of ftp, data IS quite often already compressed.
I should not use colloquial English!
You are correct. Actually, compression can cause expansion which would
be "the very least". When IP all traffic traffic is considered compression
can have some benefits assuming that compression can negate IPSEC overhead
on larger packets. Small packets do not compress well. There is no advantage
to compressing a packet which does not compress well. My point was that
if you find one that does, there may be some advantage to sending it
compressed.
>
>Now don't get me wrong. I'd like to see the ability to support
>compression. (Life is more than telnet and ftp.) But don't assume its a
>panacea.
I agree.
Derek
From owner-ipsec Tue Feb 18 12:52:54 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA15508 for ipsec-outgoing; Tue, 18 Feb 1997 12:52:41 -0500 (EST)
Message-Id: <199702181756.JAA22636@dharkins-ss20.cisco.com>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Matt Thomas <matt@lkg.dec.com>
Cc: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: Your message of "Tue, 18 Feb 1997 12:14:38 EST."
<3.0.32.19970218121355.006fd66c@netrix.lkg.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Feb 1997 09:56:40 -0800
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Matt Thomas wrote:
>At 06:30 PM 2/17/97 -0800, Daniel Harkins wrote:
>>> I know that there are some wg members who support the use of compression,
>>> some who don't and some who haven't expressed an interest either way.
>Well,
>>> the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
>>> Be sure to copy the wg list in your reply.
>>
>>I support the use of compression but not in IPsec. It should be done up
>>higher, perhaps the transport level. It's better to compress the stream
>>of data before it's divided into packets than to wait and compress each
>>packet. I'd rather see 50 packets then 100 smaller ones.
>>
>In a perfect world, that would be the case. But not everything will be
>compressed. (telnet, IP tunnels, ftp, smtp, nntp, etc). But if you
>can compress the data, you have less to encrypt and you end up sending
>less bits and using less cpu to encrypt those bits.
In a perfect world, that would be the case. But not everything will compress.
(Sorry, I couldn't resist). And I don't buy the cpu saving argument since I
have to compress the packets first and that's not free.
I understand what compression does, I just think it would be *more* beneficial
to be done somewhere else. There's a certain amount of overhead that has to
be spent per packet (regardless of size). Compression can make a given data
stream either occupy fewer packets, or it can make it occupy the same number
of packets as an uncompressed stream (albeit in smaller packets). I prefer
the former.
Dan.
From owner-ipsec Tue Feb 18 13:05:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15590 for ipsec-outgoing; Tue, 18 Feb 1997 13:04:46 -0500 (EST)
Date: Tue, 18 Feb 1997 10:09:01 -0800
Message-Id: <199702181809.KAA23603@gump.eng.ascend.com>
From: Karl Fox <karl@ascend.com>
To: Derek Palma <dpalma@netcom.com>
Cc: carrel@ipsec.org, Germano Caronni <caronni@tik.ee.ethz.ch>,
dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net,
ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: <3.0.32.19970218094734.00e13d34@netcom.com>
References: <3.0.32.19970218094734.00e13d34@netcom.com>
Reply-To: Karl Fox <karl@ascend.com>
Organization: Ascend Communications
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Derek Palma writes:
> When IP all traffic traffic is considered compression can have some
> benefits assuming that compression can negate IPSEC overhead on
> larger packets. Small packets do not compress well.
This is not universally true; it depends on the compression algorithm.
Consider, for example, Van Jacobson TCP/IP header compression, an
algorithm which should definitely be one of those available for use
within ESP.
--
Karl Fox, servant of God, employee of Ascend Communications
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841
From owner-ipsec Tue Feb 18 13:31:34 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA15892 for ipsec-outgoing; Tue, 18 Feb 1997 13:31:04 -0500 (EST)
Message-Id: <2.2.32.19970218184217.00b0cb6c@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Feb 1997 13:42:17 -0500
To: Bob Monsour <rmonsour@earthlink.net>
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bob,
>1. What is the status of adding compression to ESP?
>
> I know that there are some wg members who support the use of compression,
> some who don't and some who haven't expressed an interest either way. Well,
> the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
> Be sure to copy the wg list in your reply.
>
I am open to optional compression support being added to IPsec.
>2. Placement of the "packet compressed/not-compressed" byte/bit
>
> Several people have suggested that rather than using a whole byte for this
> purpose, simply "steal" the uppermost bit of the pad length field. This is
> a simple solution. It was suggested to me that a maximum of 128 bytes of
> padding is sufficient. Note that the preferred ESP transform for the IPSEC
> DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of
> padding. There are two ways to approach this issue:
>
> (a) alter the transform draft to specify a max of 128 bytes of padding, or
>
> (b) for implementations which do not negotiate the use of compression (for
> a particular SA, or never), they can continue to use up to 255 bytes
> of padding; for those that *do* support compression, the maximum
>padding
> would be 128 bytes.
>
I DONT like option b. We already have too many options and I feel this will
complicate it even more! From security point of view, is there any need to
pad more than 127 bytes? If the answer is no from cryptographers, we should
use the MSB of the pad. If the answer is yes, we should think of a better
solution.
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
From owner-ipsec Tue Feb 18 14:38:59 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16423 for ipsec-outgoing; Tue, 18 Feb 1997 14:37:14 -0500 (EST)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970218175816Z-126@tsntsrv2.timestep.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>,
"'Bob Monsour'"
<rmonsour@earthlink.net>
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Tue, 18 Feb 1997 12:58:16 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
While compression make some sense at a transport layer, it also make
sense to implement it with IPSec as well.
Certain situations do not have access to transport layer compression
(ie. firewalls) and IPSec compression would greatly affect performance,
expecially when you consider that in certain situations where a lot of
large packets are being sent accross, adding the ESP header would cause
fragmentation. When compression is used, fragmentation would not
normally be required.
I don't like the idea of adding it to the pad length field. Although
255 bytes of padding is more than enough, changing that fields role
might break some current implementations.
I like the idea presented in <draft-sabin-lzs-payload-00.txt>, whereas
the compression byte field is placed as the first byte of the ESP data.
After this byte, is the compressed data.
We might also wish to expand this compression byte field to a small
header for future growth;
Eg:
compression_header :==
{
word compression_header_length;
byte flags; // 0x01 = compressed
}
>----------
>From: Bob Monsour[SMTP:rmonsour@earthlink.net]
>Sent: Monday, February 17, 1997 7:14 PM
>To: ipsec@tis.com
>Subject: TO COMPRESS OR NOT TO CMPRS (please reply)
>
>Since my last posting about adding compression in the form of an "optional
>feature of ESP", I have received several offline inputs from wg members.
>Specifically, two issues arose:
>
>1. What is the status of adding compression to ESP?
>
> I know that there are some wg members who support the use of compression,
> some who don't and some who haven't expressed an interest either way.
>Well,
> the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
> Be sure to copy the wg list in your reply.
>
>2. Placement of the "packet compressed/not-compressed" byte/bit
>
> Several people have suggested that rather than using a whole byte for this
> purpose, simply "steal" the uppermost bit of the pad length field. This is
> a simple solution. It was suggested to me that a maximum of 128 bytes of
> padding is sufficient. Note that the preferred ESP transform for the IPSEC
> DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of
> padding. There are two ways to approach this issue:
>
> (a) alter the transform draft to specify a max of 128 bytes of padding,
>or
>
> (b) for implementations which do not negotiate the use of compression
>(for
> a particular SA, or never), they can continue to use up to 255 bytes
> of padding; for those that *do* support compression, the maximum
>padding
> would be 128 bytes.
>
> INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to
>proceed
> with compression, the decision on this issue will affect the ESP draft,
>the
> latest of which has yet to be issued. So, please respond.
>
>Regards,
>Bob
>
>
>
From owner-ipsec Tue Feb 18 14:54:36 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA16574 for ipsec-outgoing; Tue, 18 Feb 1997 14:54:26 -0500 (EST)
Message-Id: <3.0.32.19970218115542.0069571c@pop.rv.tis.com>
X-Sender: jmcwilliams@pop.rv.tis.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 11:55:43 -0500
To: paul_lambert@email.mot.com, jis@MIT.EDU, ipsec@ans.net
From: John McWilliams <jmcwilliams@tis.com>
Subject: IP SEC update query
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I am consulting on behalf of Trusted Information Systems in support of
major companies who are receiving mixed messages relative to IP SEC
delivery. Are you aware of any commercially avaiable, or soon to be
available, IP SEC product? If you could point me in the right direction it
would be deeply appreciated.
Sincerely,
John McWilliams
Trusted Information Systems, Inc.
15204 Omega Drive, Rockville, MD 20850
Phone: (301) 527-9500 x272
Fax: (301) 527-0482
Email: jmcwilliams@tis.com
From owner-ipsec Tue Feb 18 15:32:17 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16899 for ipsec-outgoing; Tue, 18 Feb 1997 15:32:02 -0500 (EST)
Message-Id: <199702182035.MAA24381@andorra.it.earthlink.net>
From: "Bob Monsour" <rmonsour@earthlink.net>
To: "Karl Fox" <karl@ascend.com>, "Derek Palma" <dpalma@netcom.com>
Cc: <carrel@ipsec.org>, "Germano Caronni" <caronni@tik.ee.ethz.ch>,
"Daniel Harkins" <dharkins@cisco.com>, <ipsec@tis.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Tue, 18 Feb 1997 13:33:33 -0800
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
----------
> From: Karl Fox <karl@ascend.com>
> Date: Tuesday, February 18, 1997 10:09 AM
...snip...
> This is not universally true; it depends on the compression algorithm.
> Consider, for example, Van Jacobson TCP/IP header compression, an
> algorithm which should definitely be one of those available for use
> within ESP.
Karl,
The proposed compression mechanism is aimed at the ESP payload data field
and (from my limited understanding) VJ header compression operates on the
segment/packet headers only. So, I don't see them as alternatives as much
as complements to each other. There would certainlyh have to be agreement
(perhaps KMP negotiation) between the communicating parties to perform VJ
header compression. If I recall correctly, I believe that there is a draft
somewhere that proposes VJ compression on IPv6 headers.
-Bob
From owner-ipsec Tue Feb 18 15:32:38 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16900 for ipsec-outgoing; Tue, 18 Feb 1997 15:32:03 -0500 (EST)
Message-Id: <199702182035.MAA24359@andorra.it.earthlink.net>
From: "Bob Monsour" <rmonsour@earthlink.net>
To: "Derek Palma" <dpalma@netcom.com>, <carrel@ipsec.org>
Cc: "Germano Caronni" <caronni@tik.ee.ethz.ch>,
"Daniel Harkins" <dharkins@cisco.com>, <ipsec@tis.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Tue, 18 Feb 1997 13:28:38 -0800
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Er, no. "At the very least" compression provides no benefit in packet
size
> and increases computational load. (I'm not sure if I'm correcting your
> colloquial english or your understanding of compression.) There is no
> guaranteed compression. In the case of interactive traffic like telnet,
> compression will have very little benefit. In the case of ftp data
traffic
> (large MTU sized packets), compression _may_ save you from having to
> fragment when encrypting. But only if the data is not already
compressed.
> In the case of ftp, data IS quite often already compressed.
What I would imagine occuring at the implementation level is that you would
set a threshhold packet size and any packets below the threshhold would not
be compressed (due to the lack of expected benefit). Larger packets would
get compressed and in the event of no compression being achieved, or worst
case some expansion occuring, the implementation would send the
uncompressed form of the data. These are implementation issues however and
do not affect the interoperability of the proposed mechanism since there is
the bit to say that the packet is compressed or not and the fact that the
use of compression is negotiated between the communicating parties.
-Bob
From owner-ipsec Tue Feb 18 15:36:07 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16927 for ipsec-outgoing; Tue, 18 Feb 1997 15:36:03 -0500 (EST)
Message-Id: <97Feb18.153743est.29581-2@janus.border.com>
To: Germano Caronni <caronni@tik.ee.ethz.ch>
cc: dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net, ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
References: <199702181014.LAA01115@kom30.ethz.ch>
In-reply-to: caronni's message of "Tue, 18 Feb 1997 05:14:41 -0500".
<199702181014.LAA01115@kom30.ethz.ch>
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
Phone: +1 416 813 2054
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Date: Tue, 18 Feb 1997 15:39:52 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <199702181014.LAA01115@kom30.ethz.ch>, Germano Caronni writes:
>
> Compression allows for saving a valuable ressource.
Which valuable resource is that? In my books, compression is a time-time
tradeoff; the amount of time spent compressing v.s. the amount of time spent
transmitting. As network bandwidths get higher and higher, compression gets
more and more expensive.
--
Harald Koch <chk@utcc.utoronto.ca>
From owner-ipsec Tue Feb 18 15:42:19 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17041 for ipsec-outgoing; Tue, 18 Feb 1997 15:41:38 -0500 (EST)
Message-Id: <97Feb18.154303est.29572-2@janus.border.com>
To: Bob Monsour <rmonsour@earthlink.net>
cc: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
References: <3.0.32.19970217161428.009493c0@earthlink.net>
In-reply-to: Your message of "Mon, 17 Feb 1997 19:14:33 -0500".
<3.0.32.19970217161428.009493c0@earthlink.net>
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
Phone: +1 416 813 2054
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Date: Tue, 18 Feb 1997 15:45:24 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <3.0.32.19970217161428.009493c0@earthlink.net>, Bob Monsour writes:
>
> I know that there are some wg members who support the use of compression,
> some who don't and some who haven't expressed an interest either way. Well,
> the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
> Be sure to copy the wg list in your reply.
Does anyone (perhaps PPP people?) have statistics on whether compression at
the packet layer is actually effective? What percentage of packets on a real
network are compressible? What compression ratios do you get? What's the
extra latency of the compression?
What's the tradeoff between compressing the data stream (above TCP) v.s.
individual packets? (The latter transmits the same number of packets with or
without compression, and some would argue that the modern internet is *not*
bandwidth limited but is limited by packet-switching rates).
WAGs are fun, but we're designing a Protocol Standard here, not tinkering in
the basement...
--
Harald Koch <chk@utcc.utoronto.ca>
From owner-ipsec Tue Feb 18 16:05:02 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17259 for ipsec-outgoing; Tue, 18 Feb 1997 16:04:56 -0500 (EST)
Message-Id: <199702182105.QAA01449@raptor.research.att.com>
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
cc: Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Tue, 18 Feb 1997 16:05:55 -0500
From: Steven Bellovin <smb@research.att.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Does anyone (perhaps PPP people?) have statistics on whether
compression at the packet layer is actually effective? What
percentage of packets on a real network are compressible? What
compression ratios do you get? What's the extra latency of the
compression?
What's the tradeoff between compressing the data stream (above
TCP) v. s. individual packets? (The latter transmits the same
number of packets with or without compression, and some would
argue that the modern internet is *not* bandwidth limited but
is limited by packet-switching rates).
WAGs are fun, but we're designing a Protocol Standard here,
not tinkering in the basement...
Compression is useful for the ``last mile'' -- the local connection,
which is often dial-up, and hence limited to ~28.8Kbps. It might
be interesting to look at the packet size and type distributions,
to see just what it would buy us. After all, GIF files are not
compressible, and I suspect that by volume they make up a large
percentage of traffic over dial-up links. (N.B. I'm not trying
to be snide about people's viewing habits; I'm alluding to the cute
little pictures that seem to infest most Web pages...)
From owner-ipsec Tue Feb 18 17:34:02 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17856 for ipsec-outgoing; Tue, 18 Feb 1997 17:33:10 -0500 (EST)
Date: Tue, 18 Feb 1997 14:37:11 -0800
Message-Id: <199702182237.OAA25508@gump.eng.ascend.com>
From: Karl Fox <karl@ascend.com>
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
Cc: Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: <97Feb18.154303est.29572-2@janus.border.com>
References: <3.0.32.19970217161428.009493c0@earthlink.net>
<97Feb18.154303est.29572-2@janus.border.com>
Reply-To: Karl Fox <karl@ascend.com>
Organization: Ascend Communications
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
C. Harald Koch writes:
> Does anyone (perhaps PPP people?) have statistics on whether compression at
> the packet layer is actually effective? What percentage of packets on a real
> network are compressible? What compression ratios do you get? What's the
> extra latency of the compression?
I don't have the percentage figure, but using STAC, you can generally
get 2:1 compression on average. Small GIFs in web pages don't seem to
matter, but the big ones do. With a properly designed system, you
actually get better latency with compression, due to the shortened
packets.
> What's the tradeoff between compressing the data stream (above TCP) v.s.
> individual packets?
Compressing at the TCP level is better, but if it doesn't exist, then
it is worse. :-)
--
Karl Fox, servant of God, employee of Ascend Communications
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841
From owner-ipsec Tue Feb 18 17:40:20 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA17893 for ipsec-outgoing; Tue, 18 Feb 1997 17:39:40 -0500 (EST)
Date: Tue, 18 Feb 1997 14:43:59 -0800
Message-Id: <199702182243.OAA25521@gump.eng.ascend.com>
From: Karl Fox <karl@ascend.com>
To: "Bob Monsour" <rmonsour@earthlink.net>
Cc: "Derek Palma" <dpalma@netcom.com>, <carrel@ipsec.org>,
"Germano Caronni" <caronni@tik.ee.ethz.ch>,
"Daniel Harkins" <dharkins@cisco.com>, <ipsec@tis.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: <199702182035.MAA24381@andorra.it.earthlink.net>
References: <199702182035.MAA24381@andorra.it.earthlink.net>
Reply-To: Karl Fox <karl@ascend.com>
Organization: Ascend Communications
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bob Monsour writes:
> The proposed compression mechanism is aimed at the ESP payload data field
> and (from my limited understanding) VJ header compression operates on the
> segment/packet headers only. So, I don't see them as alternatives as much
> as complements to each other. There would certainlyh have to be agreement
> (perhaps KMP negotiation) between the communicating parties to perform VJ
> header compression.
I guess I don't understand what you're getting at. If VJ header
compression, used either by itself or in conjunction with another
compression algorithm, reduces the average size of the resulting
packets, isn't it a net benefit? Keep in mind that VJ compression is
very low overhead, which might be very important for upgrading
underpowered systems. It would also help offset the huge cost of
running IPSEC over dialup links, where TELNET packets go from a few
bytes (with VJ and no AH/ESP) to more like a hundred (with AH/ESP and
no VJ).
--
Karl Fox, servant of God, employee of Ascend Communications
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841
From owner-ipsec Tue Feb 18 18:35:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA18276 for ipsec-outgoing; Tue, 18 Feb 1997 18:34:35 -0500 (EST)
Message-ID: <01BC1DB2.0678DE60@Tastid.Cisco.COM>
From: adams@cisco.com (Rob Adams)
To: ipsec@tis.com (ipsec@tis.com), rmonsour@earthlink.net ('Bob Monsour')
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Tue, 18 Feb 1997 15:39:48 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I think that linking compression to a specific set of transforms isn't a good idea.
I would much rather see compression negotiated as part of the ISAKMP exchange
and used for all traffic associated with an SA. I don't think adding any bits is necessary.
As Naganand said, we already have enough bits and options. Besides, in the future,
some may want to use compression with other types of transforms than just ESP. Why for
instance, wouldn't I want to compress an AH packet? Granted, you won't gain very
much but someone is going to argue that running a hash algorithm over less data is good!
I prefer ISAKMP negotiation because it will allow me to implement it up higher in my stack
than the IP layer. I think that compressing at the IP layer isn't going to buy you a whole
lot in speed since you're going to be sending out the same number of packets.
If I have a confirmed negotiated compression algorithm/state, my implementation
can do compression in the appropriate place, above the fragmentation done by
TCP. Firewalls can do compression before they encrypt or whatever, but then
I'll just get a lot of small encrypted packets from a firewall. A firewall will get
fully packed, compressed and encrypted packets from me. That's better than nothing.
The choice of what layer to process compression at should be an implementation detail
as long as it is done before encryption and decompressed after decryption. In this way,
compression may be useful to things other than IPsec and ESP in particular. Lumping
compression on ESP doesn't allow us a general compression solution.
I'm not sure compression is that good an idea anyway, and I am not sure that we will gain
very much from its use. However, if we are going to do compression, I think linking it
specifically to ESP isn't very wise. Negotiating it and using it on all packets per
association seems to be the only real solution to me. Adding a bit to say if a packet is
compressed or not seems like overkill. Granted I don't know a ton about compression
but it seems that a small minority of packets will be expanded by compression
and why check every packet to see if it is compressed or not to save the processing
of one decompression per n packets of compressed data.
Okay, I've babbled long enough. Direct answers are in order.
>>1. What is the status of adding compression to ESP?
Adding compression to a transform is not good. Adding compression to the architecture
may or may not be good. So don't let's add compression to ESP. Add it, if at all,
to the architecture.
>>2. Placement of the "packet compressed/not-compressed" byte/bit
See answer to 1. No bit, no byte.
I'd like to see more investigation of how useful compression is before we commit to anything though.
I have a lot of questions about how much we'll gain for what kinds of traffic and over links that do
hardware compression like some modems and routers. Am I the only one that feels like we're rushing
this without enough information?
-Rob Adams
Cisco Systems.
----------
From: Bob Monsour[SMTP:rmonsour@earthlink.net]
Sent: Monday, February 17, 1997 4:14 PM
To: ipsec@tis.com
Subject: TO COMPRESS OR NOT TO CMPRS (please reply)
Since my last posting about adding compression in the form of an "optional
feature of ESP", I have received several offline inputs from wg members.
Specifically, two issues arose:
1. What is the status of adding compression to ESP?
I know that there are some wg members who support the use of compression,
some who don't and some who haven't expressed an interest either way. Well,
the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
Be sure to copy the wg list in your reply.
2. Placement of the "packet compressed/not-compressed" byte/bit
Several people have suggested that rather than using a whole byte for this
purpose, simply "steal" the uppermost bit of the pad length field. This is
a simple solution. It was suggested to me that a maximum of 128 bytes of
padding is sufficient. Note that the preferred ESP transform for the IPSEC
DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of
padding. There are two ways to approach this issue:
(a) alter the transform draft to specify a max of 128 bytes of padding, or
(b) for implementations which do not negotiate the use of compression (for
a particular SA, or never), they can continue to use up to 255 bytes
of padding; for those that *do* support compression, the maximum
padding
would be 128 bytes.
INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to
proceed
with compression, the decision on this issue will affect the ESP draft,
the
latest of which has yet to be issued. So, please respond.
Regards,
Bob
From owner-ipsec Tue Feb 18 20:36:04 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA18896 for ipsec-outgoing; Tue, 18 Feb 1997 20:32:33 -0500 (EST)
Posted-Date: Tue, 18 Feb 1997 20:33:56 +0000
Message-Id: <9702190136.AA99357@aurora.cis.upenn.edu>
To: rmonsour@earthlink.net ('Bob Monsour')
Cc: ipsec@tis.com (ipsec@tis.com)
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Tue, 18 Feb 1997 20:33:56 +0000
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>1. What is the status of adding compression to ESP?
I'm against adding compression to a particular transform. Someone
mentioned having compression as an attribute to a SAID as a whole; if
we want compression (and i'm not sure it'll buy us much), i think
that's how it should be done. It should certainly be optional.
I should add that i'm against compression at the network layer; i feel
it should be moved higher up.
>2. Placement of the "packet compressed/not-compressed" byte/bit
No need for this if we do (1). Otherwise, i'd rather see a different
ESP transform (and don't tell me we're wasting bytes; if compression
gains us about the same number of bytes as the extra ESP header or
less, then clearly we shouldn't even be considering it as an option).
However, just what is the model in mind ? I doubt firewalls need to
perform compression; most companies have decent speed links to the
Internet, so compression there wouldn't buy much.
A couple more points:
a) i think the only place compression would buy anything, especially
networks become faster, is the "last mile" (as Steve Bellovin
said); the 28.8 (or so) PPP link. Now, PPP already has compression
for that link (or so i remember). Additionally, forcing compression
in an ESP transform will make the two endpoints also perform encryption;
i don't know about you, but i feel that there's higher chance of
my data being snooped as they travel over the Internet than on the phone
line from my place to the ISP.
b) assuming the end user does use encryption all the way to the server
somewhere on the net; forcing the server to do compression is "bad
manners" IMO, since the server has probably more need of the CPU
cycles than the (few ?) bytes compression will give save from the
link. Establishing yet another SAID with the PPP remote endpoint
to do additional compression just at the final step falls under
(a), unless compression is a separate ESP transform (but again,
doesn't PPP already do compression ?).
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMwpYhL0pBjh2h1kFAQHYsgP/atGT5lcBVx8l+OOvbXLvIbRbiguFjM+v
iqrnAKzL3rpRbhknzQkse55HxrTL6M1xy1XOdpswgZG/0ExJUSBsdmX8Iy3FXdvN
yZKev/WAEzFt8IFcO1Wa1rAfBPMSnE/vKlICoh2+asbW0/Imb3Ve+si0r/s5j9S+
SsjUGzxMjyg=
=YZFq
-----END PGP SIGNATURE-----
From owner-ipsec Tue Feb 18 22:15:42 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19457 for ipsec-outgoing; Tue, 18 Feb 1997 22:14:26 -0500 (EST)
X-Sender: smarcus@mail.bbnplanet.com
Message-Id: <v0213051caf3018edd1c4@[199.94.220.18]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Organization: BBN Corporation
USMail: 150 CambridgePark Drive, Cambridge, MA 02140, U.S.A.
Phone: +1 617.873.3075
Date: Tue, 18 Feb 1997 22:18:15 -0500
To: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
From: Scott Marcus <smarcus@bbnplanet.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: "'Bob Monsour'" <rmonsour@earthlink.net>, "ipsec@tis.com" <ipsec@tis.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dear Angelos:
>... However, just what is the model in mind ? I doubt firewalls need to
>perform compression; most companies have decent speed links to the
>Internet, so compression there wouldn't buy much.
One of the most likely scenarios for the use of IPSEC, I think, is between
an organization's firewall and a dispersed community of users communicating
over public dial-up Internet access services, with physical connectivity
via phone lines or similar. Where the organization runs its servers,
support would tend to be deployed in the firewall, at least initially,
because the firewall represents a single point through which all external
traffic passes.
If compression were done at the Network Layer, then this firewall would
need to "wrap" or "unwrap" the compressed data. If compression were done
at the Link Layer (e.g. PPP), however, then this firewall would never see
it. It compression were done in upper layers, it would pass transparently
through this firewall.
>A couple more points:
>a) i think the only place compression would buy anything, especially
> networks become faster, is the "last mile" (as Steve Bellovin
> said); the 28.8 (or so) PPP link. Now, PPP already has compression
> for that link (or so i remember)...
If the dial-up 28.8 users are doing IPSEC, then the PPP compression will be
ineffective. Not so?
Cheers,
-- Scott
From owner-ipsec Tue Feb 18 22:32:52 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19570 for ipsec-outgoing; Tue, 18 Feb 1997 22:32:30 -0500 (EST)
Message-Id: <3.0.32.19970218222803.006b4908@netrix.lkg.dec.com>
X-Sender: popmatt@netrix.lkg.dec.com
X-Mailer: Windows Eudora Pro Version 3.0 Demo (32)
Date: Tue, 18 Feb 1997 22:28:13 -0500
To: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
From: Matt Thomas <matt@lkg.dec.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 08:33 PM 2/18/97 +0000, Angelos D. Keromytis wrote:
>>1. What is the status of adding compression to ESP?
>
>I'm against adding compression to a particular transform. Someone
>mentioned having compression as an attribute to a SAID as a whole; if
>we want compression (and i'm not sure it'll buy us much), i think
>that's how it should be done. It should certainly be optional.
Compression is something that should be included in the proposal and
would be "independent" of any underlying transform.
>>2. Placement of the "packet compressed/not-compressed" byte/bit
>
>No need for this if we do (1). Otherwise, i'd rather see a different
>ESP transform (and don't tell me we're wasting bytes; if compression
>gains us about the same number of bytes as the extra ESP header or
>less, then clearly we shouldn't even be considering it as an option).
If you are compressing on the fly, sometimes the compress will
actually generate more data; in this case you want a flag to show
even though compression is enabled it was not used on this packet.
>However, just what is the model in mind ? I doubt firewalls need to
>perform compression; most companies have decent speed links to the
>Internet, so compression there wouldn't buy much.
>
>A couple more points:
>a) i think the only place compression would buy anything, especially
> networks become faster, is the "last mile" (as Steve Bellovin
> said); the 28.8 (or so) PPP link. Now, PPP already has compression
> for that link (or so i remember). Additionally, forcing compression
> in an ESP transform will make the two endpoints also perform encryption;
> i don't know about you, but i feel that there's higher chance of
> my data being snooped as they travel over the Internet than on the phone
> line from my place to the ISP.
If you are using encryption, the encrypted data is going to be uncompressable
so PPP level compression is not going to be useful.
>b) assuming the end user does use encryption all the way to the server
> somewhere on the net; forcing the server to do compression is "bad
> manners" IMO, since the server has probably more need of the CPU
> cycles than the (few ?) bytes compression will give save from the
> link. Establishing yet another SAID with the PPP remote endpoint
> to do additional compression just at the final step falls under
> (a), unless compression is a separate ESP transform (but again,
> doesn't PPP already do compression ?).
Buy lots of Alphas as your servers. :-)
--
Matt Thomas Internet: matt@lkg.dec.com
UNIX Networking WWW URL: http://ftp.digital.com/%7Ethomas/
Digital Equipment Corporation Disclaimer: This message reflects my own
Littleton, MA warped views, etc.
From owner-ipsec Tue Feb 18 22:33:36 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19585 for ipsec-outgoing; Tue, 18 Feb 1997 22:33:32 -0500 (EST)
Posted-Date: Tue, 18 Feb 1997 22:34:55 +0000
Message-Id: <9702190337.AA105869@aurora.cis.upenn.edu>
To: Scott Marcus <smarcus@bbnplanet.com>
Cc: "'Bob Monsour'" <rmonsour@earthlink.net>, "ipsec@tis.com" <ipsec@tis.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: Your message of "Tue, 18 Feb 1997 22:18:15 EST."
<v0213051caf3018edd1c4@[199.94.220.18]>
Date: Tue, 18 Feb 1997 22:34:55 +0000
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
In message <v0213051caf3018edd1c4@[199.94.220.18]>, Scott Marcus writes:
>
>>A couple more points:
>>a) i think the only place compression would buy anything, especially
>> networks become faster, is the "last mile" (as Steve Bellovin
>> said); the 28.8 (or so) PPP link. Now, PPP already has compression
>> for that link (or so i remember)...
>
>If the dial-up 28.8 users are doing IPSEC, then the PPP compression will be
>ineffective. Not so?
Touche'.
I still think that forcing compression inside another ESP transform is
unnecessary complexity; a different (ESP ?) transform for compression
would be better (and more widely used).
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMwp0370pBjh2h1kFAQG7lQP+Kk4qDNfQ0fWthnrOzopPtZ+9BqKduPQR
0WcATneYp48R4J3xHbe7Huf80S9T8kwKHRC4liVaC569gnm8yzfwX70Z9pH5Y5y8
oU0nCZnMwuGBagIWgMHNf9lABDfaTyd5LcjAxzHmW2moIWBUJ81A/dG5s9LoIx8O
6VxJ2YIIttw=
=SSz/
-----END PGP SIGNATURE-----
From owner-ipsec Tue Feb 18 22:45:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA19626 for ipsec-outgoing; Tue, 18 Feb 1997 22:45:04 -0500 (EST)
Message-Id: <199702190349.TAA00303@imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Date: Tue, 18 Feb 97 19:49:21 -0800
To: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
cc: ipsec@tis.com
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
References: <3.0.32.19970217161428.009493c0@earthlink.net>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Does anyone have any empirical data to support or refute
compression within ESP? What is a fair mix of binary/text?
I keep reading how the Internet is data swamped. If compression
offers a reasonable reduction in packet size against a
fair binary/text mix, perhaps it is worth doing.
-dpg
From owner-ipsec Tue Feb 18 23:40:14 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA19868 for ipsec-outgoing; Tue, 18 Feb 1997 23:39:12 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007803af2fd04a59a3@[128.33.229.235]>
In-Reply-To: <3.0.32.19970217161428.009493c0@earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Feb 1997 16:38:30 -0500
To: Bob Monsour <rmonsour@earthlink.net>
From: Stephen Kent <kent@bbn.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bob,
I'm in favor of including a compression option in ESP. As I
mentioned at the last IPSEC WG meeting, I think this will be especially
helpful for folks using dialup or low-speed wireless links. While I agree
that this could be viewed as a separate protocol layer, and might be
beneficial in non-ESP contexts, I worry that if we wait for form a new WG
for this, debate the right protocol layer for providing this service, etc.,
that it will be a long time before we have the feature and ESP users in the
contexts noted above will suffer during that time. So, I vote (oops, I
just used a four letter word in the IETF context; I meat to say "I cast my
straw ballot for") the inclusion of a compression option in ESP.
As for your second question, I also favor stealing a bit out of the
padding field for this purpose. As I recall, the motivation here is to
negotiate the use of compression, and the specific algorithm, on a per SA
basis. So the per-packet bit is needed to allow some packets to not be
compressed, e.g., because the packets were sufficiently small that
compression would not be attractive. If we add a byte for this bit of
info, we will further complicate the alignment issues that are currenty
consuming a lot of WG bandwidth. Since I don't think highly of using
padding for trafiic flow confidentiality purposes, I'm in favor of donating
the high order bit of the padding field to this compression indication
purpose.
Steve
From owner-ipsec Wed Feb 19 00:03:55 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20034 for ipsec-outgoing; Wed, 19 Feb 1997 00:03:17 -0500 (EST)
Message-Id: <3.0.32.19970218210258.00947440@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 21:03:06 -0800
To: Karl Fox <karl@ascend.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: "Bob Monsour" <rmonsour@earthlink.net>, "Derek Palma" <dpalma@netcom.com>,
<carrel@ipsec.org>, "Germano Caronni" <caronni@tik.ee.ethz.ch>,
"Daniel Harkins" <dharkins@cisco.com>, <ipsec@tis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 02:43 PM 2/18/97 -0800, Karl Fox wrote:
>Bob Monsour writes:
>> The proposed compression mechanism is aimed at the ESP payload data field
>> and (from my limited understanding) VJ header compression operates on the
>> segment/packet headers only. So, I don't see them as alternatives as much
>> as complements to each other. There would certainlyh have to be agreement
>> (perhaps KMP negotiation) between the communicating parties to perform VJ
>> header compression.
>
>I guess I don't understand what you're getting at. If VJ header
>compression, used either by itself or in conjunction with another
>compression algorithm, reduces the average size of the resulting
>packets, isn't it a net benefit? Keep in mind that VJ compression is
>very low overhead, which might be very important for upgrading
>underpowered systems. It would also help offset the huge cost of
>running IPSEC over dialup links, where TELNET packets go from a few
>bytes (with VJ and no AH/ESP) to more like a hundred (with AH/ESP and
>no VJ).
After reading my response, I think we're in violent agreement (I was just
being needlessly unclear). I agree that using VJ header compression *does*
provide a net benefit, both in conjunction with a payload compression
scheme as well as by itself. There's no reason you can't do both. I was
just getting at the fact that the two sides would have to agree to do VJ,
just as they have to agree to do everything else they do in IPSec.
-Bob
From owner-ipsec Wed Feb 19 00:05:17 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20040 for ipsec-outgoing; Wed, 19 Feb 1997 00:03:49 -0500 (EST)
Message-Id: <3.0.32.19970218210712.0094cd00@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 21:07:14 -0800
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: Germano Caronni <caronni@tik.ee.ethz.ch>,
dharkins@cisco.com (Daniel Harkins), rmonsour@earthlink.net,
ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 03:39 PM 2/18/97 -0500, C. Harald Koch wrote:
>In message <199702181014.LAA01115@kom30.ethz.ch>, Germano Caronni writes:
>>
>> Compression allows for saving a valuable ressource.
>
>Which valuable resource is that? In my books, compression is a time-time
>tradeoff; the amount of time spent compressing v.s. the amount of time spent
>transmitting. As network bandwidths get higher and higher, compression gets
>more and more expensive.
The valuable resource is indeed bandwith. Clearly, to get the gain, you
have to be able to do the compression at a rate which lets you keep the
network pipe full. I would argue that as network bandwidths get higher and
higher, while the cost of compression gets more expensive (in terms of CPU
or dedicated coprocessors), the economic gain of the additional bandwidth
provided gets larger. In today's private T1/E1 leased lines, adding
compression at the PPP level provides anywhere from 2:1 to 4:1 (and some
even claim more) compression, providing substantial dollar savings over an
uncompressed leased line. Note that for these higher speeds, you're
typically talking about a router interface or some other dedicated WAN
interface box.
-Bob
From owner-ipsec Wed Feb 19 00:08:06 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20060 for ipsec-outgoing; Wed, 19 Feb 1997 00:06:47 -0500 (EST)
Message-Id: <3.0.32.19970218211007.009481f0@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 21:10:09 -0800
To: Roy Pereira <rpereira@TimeStep.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: "'ipsec@tis.com'" <ipsec@tis.com>,
"'Bob Monsour'" <rmonsour@earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 12:58 PM 2/18/97 -0500, Roy Pereira wrote:
>I don't like the idea of adding it to the pad length field. Although
>255 bytes of padding is more than enough, changing that fields role
>might break some current implementations.
Current implementations would never negotiate to turn on compression, so
they "should" never receive packets with the bit turned on and if they do,
they are probably talking to another "current implementation" where that
bit means another 128 bytes of padding are present. I don't think this is a
problem (other than the fact that I used the word "never" in the context of
software and protocols...probably a mistake I never should have made).
-Bob
From owner-ipsec Wed Feb 19 00:28:08 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20156 for ipsec-outgoing; Wed, 19 Feb 1997 00:27:49 -0500 (EST)
Message-Id: <3.0.32.19970218213122.00923b40@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 21:31:24 -0800
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 03:45 PM 2/18/97 -0500, C. Harald Koch wrote:
>Does anyone (perhaps PPP people?) have statistics on whether compression at
>the packet layer is actually effective? What percentage of packets on a real
>network are compressible? What compression ratios do you get? What's the
>extra latency of the compression?
Harold,
Below I have copied the appendix from draft-sabin-lzs-payload-00.txt, one
of the proposed compression drafts. It contains some results from analyzing
compression ratio vs. packet size with a known set of data. Note that
"your're mileage may vary" as with any compression algorithm; results vary
by data type. If you look at the entry for 256 byte packets, the test data
shows a ratio of 1.43:1 (i.e., packet was reduced to 70% of its original
size). While the data set is not "real network" data, it is a publically
available dataset used commonly for analyzing compression ratios for
various algorithms. The extra latency really depends on the processor
you're using. We have seen results where, in a compress/encrypt/mac
scenario, achieving a 2:1 compression ratio reduces the CPU cycles required
for encrypt/mac functions to the point of a net benefit (note that this
includes accounting for the cost of compression). I presented some numbers
relating to this at the Dec wg meeting in San Jose.
8. Appendix: Compression Efficiency versus Datagram Size
The following table offers some guidance on the compression
efficiency that can be achieved as a function of datagram size. Each
entry in the table shows the compression ratio that was achieved when
the proposed transform was applied to a test file using datagrams of
a specified size.
The test file was the University of Calgary Text Compression Corpus
[Calgary]. The length of the file prior to compression was 3,278,000
bytes. When the entire file was compressed as a single payload, a
compression ratio of 2.34 resulted.
Datagram size,| 64 128 256 512 1024 2048 4096 8192 16384
bytes |
--------------|----------------------------------------------------
Compression |1.18 1.28 1.43 1.58 1.74 1.91 2.04 2.11 2.14
ratio |
[Calgary] Text Compression Corpus, University of Calgary, available at
ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus
>What's the tradeoff between compressing the data stream (above TCP) v.s.
>individual packets? (The latter transmits the same number of packets with or
>without compression, and some would argue that the modern internet is *not*
>bandwidth limited but is limited by packet-switching rates).
If you could compress the data stream (as is done in PPP), you could
achieve higher compression ratios since you would be retaining the
compression history across each segment of a particular "session". The
dilemma, however, is that once you are above IP, you cannot predictably
rely on the presence of a particular protocol. Also, the presence of
encryption in IP(Sec) is one element of what is driving the need for
compression. In the absence of IPSec encryption, the lower-layer PPP
compression will work and provide the desired result.
-Bob
From owner-ipsec Wed Feb 19 00:33:26 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA20201 for ipsec-outgoing; Wed, 19 Feb 1997 00:33:22 -0500 (EST)
Message-Id: <3.0.32.19970218213641.0092cc60@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 21:36:44 -0800
To: Steven Bellovin <smb@research.att.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: "C. Harald Koch" <chk@utcc.utoronto.ca>,
Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 04:05 PM 2/18/97 -0500, Steven Bellovin wrote:
...snip
>Compression is useful for the ``last mile'' -- the local connection,
>which is often dial-up, and hence limited to ~28.8Kbps. It might
>be interesting to look at the packet size and type distributions,
>to see just what it would buy us. After all, GIF files are not
>compressible, and I suspect that by volume they make up a large
>percentage of traffic over dial-up links. (N.B. I'm not trying
>to be snide about people's viewing habits; I'm alluding to the cute
>little pictures that seem to infest most Web pages...)
Steve,
While GIF files do likely make up a large percentage of traffic over
dial-up links, I don't imagine that security functionality will be
enabled/negotiated while viewing web pages. I would expect that security
functionality would be engaged when tunneling into the corporate network
over the internet. If you get your web access after establishing this
tunnel and thus using the corporate net connection, then indeed the web
pages would be encrypted (and optionally compressed), but I would think
that once you're connected to your local ISP and have established the
tunnel, you would just use the ISP to get your web access, thus only
encrypting the "corporate" data traveling between the client and the
corporate network. Corrections to my thinking?
-Bob
From owner-ipsec Wed Feb 19 01:27:09 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA20461 for ipsec-outgoing; Wed, 19 Feb 1997 01:26:27 -0500 (EST)
Date: Wed, 19 Feb 1997 00:30:34 -0600
From: jim@hosaka.smallworks.com (Jim Thompson)
Message-Id: <199702190630.AAA15148@hosaka>
To: kent@bbn.com, rmonsour@earthlink.net
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Consider the issues surrounding compression patents.
From owner-ipsec Wed Feb 19 01:37:01 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA20510 for ipsec-outgoing; Wed, 19 Feb 1997 01:36:57 -0500 (EST)
Message-Id: <3.0.32.19970218224038.00952df0@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Feb 1997 22:40:41 -0800
To: adams@cisco.com (Rob Adams)
From: Bob Monsour <rmonsour@earthlink.net>
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com (ipsec@tis.com), rmonsour@earthlink.net ('Bob Monsour')
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 03:39 PM 2/18/97 -0800, Rob Adams wrote:
>I would much rather see compression negotiated as part of the ISAKMP exchange
>and used for all traffic associated with an SA. I don't think adding any
bits is necessary.
>As Naganand said, we already have enough bits and options.
Rob,
Compression would indeed be negotiated as partof the ISAKMP exchange.
Allowing selective compression on a packet by packet basis provides
implementation flexibility. For example, you may want to avoid compressing
packets less than 100 bytes; or want to send uncompressed data because the
data expanded (was precompressed or pre-encrypted at the application
layer). You could easily do this using the compressed/not-compressed bit as
proposed. To avoid using the bit, you would have to have two SA's for each
direction of the connection: one to use for compressed data and one to use
for uncompressed data. Are system resources (SA's) that free that a
potential doubling of their use is acceptable? I would argue that use of a
single bit per packet (an existing bit, not an additional one) is
preferable to managing two SA's per direction on each connection. Seems
like comparable complexity at best.
...snip...
>I prefer ISAKMP negotiation because it will allow me to implement it up
higher in my stack
>than the IP layer. I think that compressing at the IP layer isn't going
to buy you a whole
>lot in speed since you're going to be sending out the same number of
packets.
>If I have a confirmed negotiated compression algorithm/state, my
implementation
>can do compression in the appropriate place, above the fragmentation done
by
>TCP. Firewalls can do compression before they encrypt or whatever, but then
>I'll just get a lot of small encrypted packets from a firewall. A
firewall will get
>fully packed, compressed and encrypted packets from me. That's better
than nothing.
>
>The choice of what layer to process compression at should be an
implementation detail
>as long as it is done before encryption and decompressed after decryption.
In this way,
>compression may be useful to things other than IPsec and ESP in
particular. Lumping
>compression on ESP doesn't allow us a general compression solution.
The problem, as I've stated in other responses, is that there is not a
universal "higher layer" in which to do compression. It is more than an
implementation detail. All parties wanting to compress would have to
support it at this "higher layer" which may or may not be present. IP is
the common denominator and the need for compression at the IP layer is
partly because of the encryption. In the absence of encryption, for systems
using PPP, the PPP compression will be effective.
...snip...
>I'd like to see more investigation of how useful compression is before we
commit to anything though.
>I have a lot of questions about how much we'll gain for what kinds of
traffic and over links that do
>hardware compression like some modems and routers. Am I the only one that
feels like we're rushing
>this without enough information?
In a response to another message in this thread, I provided a table of
compression ratios for text data, analyzed on the basis of packet size. I
will work on providing similar results on other types of data, but this is
publically available data used for comparing compression ratios for
different compression algorithms (see draft-sabin-lzs-payload-00.txt).
For links that do hardware compression (modems & routers), once you encrypt
at a the IP layer, those compressors are no longer effective (encrypted
data doesn't/shouldn't compress).
Your questions are useful in the debate and are appreciated.
-Bob
From owner-ipsec Wed Feb 19 08:52:07 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA23155 for ipsec-outgoing; Wed, 19 Feb 1997 08:48:56 -0500 (EST)
Message-Id: <199702191348.IAA23155@portal.ex.tis.com>
Date: Tue, 18 Feb 1997 22:16:52 -0800
To: Daniel Harkins <dharkins@cisco.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 06:30 PM 2/17/97 -0800, Daniel Harkins wrote:
>I support the use of compression but not in IPsec. It should be done up
>higher, perhaps the transport level. It's better to compress the stream
>of data before it's divided into packets than to wait and compress each
>packet. I'd rather see 50 packets then 100 smaller ones.
Dan,
The problem that seems unsolvable when considering moving compression to a
higher layer is "what higher layer?". There is not necessarily a
universally used "higher layer" in all envrironments. IP is the common
denominator and that's where the encryption is being done, which in turn,
leads to the need for compressing. As I've said before, if there's no
encryption and PPP exists at the data link layer, then there's no need to
put compression at a higher layer.
-Bob
From owner-ipsec Wed Feb 19 09:21:17 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA23399 for ipsec-outgoing; Wed, 19 Feb 1997 09:20:03 -0500 (EST)
Message-Id: <199702191422.JAA02189@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: Bob Monsour <rmonsour@earthlink.net>
cc: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-reply-to: Your message of "Tue, 18 Feb 1997 21:36:44 PST."
<3.0.32.19970218213641.0092cc60@earthlink.net>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 19 Feb 1997 09:22:48 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bob Monsour writes:
> While GIF files do likely make up a large percentage of traffic over
> dial-up links, I don't imagine that security functionality will be
> enabled/negotiated while viewing web pages.
I see you haven't heard of SSL, eh?
Security is very big on the web. People -- and I mean ordinary
consumers -- want to conduct transactions over it. With a reasonable
IPSec in place, SSL wouldn't have been necessary. SSL is used every
day by millions of people to keep their credit card data away from
prying eyes.
> I would expect that security functionality would be engaged wnnhen
> tunneling into the corporate network over the internet.
Security is useful most of the time, actually. I suspect that someday,
almost all traffic will be secure.
Certainly at 28.8kbps the added CPU burden is unnoticeable, so why
*not* encrypt everything?
Perry
From owner-ipsec Wed Feb 19 10:20:18 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA23799 for ipsec-outgoing; Wed, 19 Feb 1997 10:14:26 -0500 (EST)
Message-Id: <3.0.32.19970219071752.0094a7e0@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 19 Feb 1997 07:17:54 -0800
To: perry@piermont.com
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: Bob Monsour <rmonsour@earthlink.net>, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote:
>I see you haven't heard of SSL, eh?
I am very aware of SSL (and it provides support for compressing prior to
encrypting).
>Certainly at 28.8kbps the added CPU burden is unnoticeable, so why
>*not* encrypt everything?
The issue for doing the work is less a burden for the client than it is for
the server. I completely agree that at the client end, the overhead is
unnoticeable. However, at the server/aggregation points for all these
clients, the workload would be substantial, if not overwhelming (i.e.,
without hardware assist). This is true in the case for compression today.
In some routers that support PPP compression today, if the load on the
router becomes too great so that the network pipe can't be kept saturated,
the compression is turned off.
-Bob
From owner-ipsec Wed Feb 19 11:32:23 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24569 for ipsec-outgoing; Wed, 19 Feb 1997 11:31:33 -0500 (EST)
Message-Id: <97Feb19.113700est.11652@elgreco.rnd.border.com>
To: Bob Monsour <rmonsour@earthlink.net>
cc: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
References: <3.0.32.19970218213122.00923b40@earthlink.net>
In-reply-to: rmonsour's message of "Wed, 19 Feb 1997 00:31:24 -0500".
<3.0.32.19970218213122.00923b40@earthlink.net>
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
Phone: +1 416 813 2054
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Date: Wed, 19 Feb 1997 11:35:48 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <3.0.32.19970218213122.00923b40@earthlink.net>, Bob Monsour writes:
>
> Below I have copied the appendix from draft-sabin-lzs-payload-00.txt, one
> of the proposed compression drafts. It contains some results from analyzing
> compression ratio vs. packet size with a known set of data. Note that
> "your're mileage may vary" as with any compression algorithm; results vary
> by data type.
Exactly why I asked for real-world data. The Internet is notorious for
discovering that "test data" and "theoretical models" do not resemble "real
world data".
[ P.S.: To clarify, I have no opinion on the compression issue, exactly
because I have no information on which to base an opinion... ]
--
Harald Koch <chk@utcc.utoronto.ca>
From owner-ipsec Wed Feb 19 11:55:54 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24826 for ipsec-outgoing; Wed, 19 Feb 1997 11:54:41 -0500 (EST)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970219165930Z-641@tsntsrv2.timestep.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: "'Bob Monsour'" <rmonsour@earthlink.net>
Cc: "'dharkins@cisco.com'" <dharkins@cisco.com>,
"'ipsec@tis.com'"
<ipsec@tis.com>
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Wed, 19 Feb 1997 11:59:30 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
To me the biggest benefit of using compression within ESP is the fact
that I wont have to FRAGMENT as many packets as I would normally due to
the addition of ESP's 40+ byte overhead.
Fragmentation can slow down links considerably, especially when they are
low-speed (28.8k), thus anything that helps prevent fragmentation is a
"good thing".
>
From owner-ipsec Wed Feb 19 12:09:24 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25008 for ipsec-outgoing; Wed, 19 Feb 1997 12:09:19 -0500 (EST)
Message-Id: <199702191713.MAA02610@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: Roy Pereira <rpereira@TimeStep.com>
cc: "'Bob Monsour'" <rmonsour@earthlink.net>,
"'dharkins@cisco.com'" <dharkins@cisco.com>,
"'ipsec@tis.com'" <ipsec@tis.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-reply-to: Your message of "Wed, 19 Feb 1997 11:59:30 EST."
<c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970219165930Z-641@tsntsrv2.timestep.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 19 Feb 1997 12:13:03 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Roy Pereira writes:
> To me the biggest benefit of using compression within ESP is the fact
> that I wont have to FRAGMENT as many packets as I would normally due to
> the addition of ESP's 40+ byte overhead.
>
> Fragmentation can slow down links considerably, especially when they are
> low-speed (28.8k), thus anything that helps prevent fragmentation is a
> "good thing".
I don't understand this at all.
If you have path MTU discovery, why would you ever fragment?
Perry
From owner-ipsec Wed Feb 19 12:44:44 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25293 for ipsec-outgoing; Wed, 19 Feb 1997 12:42:01 -0500 (EST)
Message-Id: <199702191743.JAA14968@itech.terisa.com>
X-Authentication-Warning: itech.terisa.com: Host kmac.terisa.COM didn't use HELO protocol
To: Bob Monsour <rmonsour@earthlink.net>
cc: perry@piermont.com, ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-reply-to: Your message of "Wed, 19 Feb 1997 07:17:54 PST."
<3.0.32.19970219071752.0094a7e0@earthlink.net>
Date: Wed, 19 Feb 1997 09:47:37 -0800
From: EKR <ekr@terisa.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> At 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote:
> >I see you haven't heard of SSL, eh?
>
> I am very aware of SSL (and it provides support for compressing prior to
> encrypting).
Well, sort of:
There is a socket for compression to be plugged into. There are
no defined compression plugs (other than null) and I don't expect
there to be any for some time.
-Ekr
From owner-ipsec Wed Feb 19 12:44:47 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA25321 for ipsec-outgoing; Wed, 19 Feb 1997 12:43:29 -0500 (EST)
Message-Id: <3.0.1.32.19970219084908.02706ca8@ibeam.intel.com>
X-Sender: jwr@ibeam.intel.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 19 Feb 1997 08:49:08 -0800
To: Bob Monsour <rmonsour@earthlink.net>
From: "John W. Richardson" <jwr@ibeam.jf.intel.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
In-Reply-To: <3.0.32.19970217161428.009493c0@earthlink.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 04:14 PM 2/17/97 -0800, you wrote:
>1. What is the status of adding compression to ESP?
> PLEASE RESPOND BY INDICATING YOUR POSITION.
I don't support compression at the network layer. It adds significant
complexity for minimal, and short-lived savings. With the exponentially
increasing volume of pre-compressed traffic (graphics, multimedia,
compressed archives, etc.), compression is actually happening at the (dare
I say it?) presentation layer. The only way to make a rational decision
about whether to compress a connection is to know whether or not the data
is already compressed, and this seems to break layering.
For the record, I agree with Perry and his "encrypt everything" position.
Our internal IT organization is pushing for this to be the case as soon as
possible, since most of our problems seem to be from internal people with
legitimate access to the network doing illegitimate things.
-JR
------------------------------------------------------------------------
John W. Richardson (Please note that my opinions are my own and
jwr@ibeam.intel.com not necessarily shared by Intel)
+1 503 264 9425
19 57 B1 04 1F 5D F9 F0 7C 2C 5E D2 DD 7A 19 A5
From owner-ipsec Wed Feb 19 13:01:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA25559 for ipsec-outgoing; Wed, 19 Feb 1997 13:01:19 -0500 (EST)
Message-Id: <199702191805.AA011615518@relay.hp.com>
To: Roy Pereira <rpereira@TimeStep.com>
Cc: "'Bob Monsour'" <rmonsour@earthlink.net>,
"'dharkins@cisco.com'" <dharkins@cisco.com>,
"'ipsec@tis.com'" <ipsec@tis.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: rpereira's message of Wed, 19 Feb 1997 11:59:30 -0500.
<c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970219165930Z-641@tsntsrv2.timestep.com>
Date: Wed, 19 Feb 1997 13:05:17 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> To me the biggest benefit of using compression within ESP is the fact
> that I wont have to FRAGMENT as many packets as I would normally due to
> the addition of ESP's 40+ byte overhead.
Hmm. Wouldn't correct handling of MTU discovery/DF through the ipsec
`tunnel' also handle this problem?
> Fragmentation can slow down links considerably, especially when they are
> low-speed (28.8k), thus anything that helps prevent fragmentation is a
> "good thing".
Agreed. Any time you fragment, you've begun to start losing...
- Bill
From owner-ipsec Wed Feb 19 13:55:16 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA25861 for ipsec-outgoing; Wed, 19 Feb 1997 13:53:53 -0500 (EST)
Message-Id: <199702191858.AA074158687@relay.hp.com>
To: Bob Monsour <rmonsour@earthlink.net>
Cc: Steven Bellovin <smb@research.att.com>,
"C. Harald Koch" <chk@utcc.utoronto.ca>, ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: rmonsour's message of Tue, 18 Feb 1997 21:36:44 -0800.
<3.0.32.19970218213641.0092cc60@earthlink.net>
Date: Wed, 19 Feb 1997 13:58:06 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> While GIF files do likely make up a large percentage of traffic over
> dial-up links, I don't imagine that security functionality will be
> enabled/negotiated while viewing web pages. ....
> Corrections to my thinking?
"web access" includes access to company-internal websites, which (like
all other web sites) are frequently decorated by inane little GIF's.
For one, my employer is already doing a large amount of internal
administrative "paperwork" and publishing over the web, saving many
trees as a result...
- Bill
From owner-ipsec Wed Feb 19 14:06:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25948 for ipsec-outgoing; Wed, 19 Feb 1997 14:06:29 -0500 (EST)
Message-Id: <97Feb19.141142est.11653@elgreco.rnd.border.com>
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
cc: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
References: <199702191805.AA011615518@relay.hp.com>
In-reply-to: sommerfeld's message of "Wed, 19 Feb 1997 13:05:17 -0500".
<199702191805.AA011615518@relay.hp.com>
From: "C. Harald Koch" <chk@utcc.utoronto.ca>
X-uri: <URL:http://chk.home.ml.org/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
did@Pr9
Date: Wed, 19 Feb 1997 14:10:33 -0500
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In message <199702191805.AA011615518@relay.hp.com>, Bill Sommerfeld writes:
>
> Hmm. Wouldn't correct handling of MTU discovery/DF through the ipsec
> `tunnel' also handle this problem?
Yes, but isn't that a Hard Problem (tm) unless you keep state (either
"virtual interfaces" or individual packets) at the tunnel endpoints? How
else do you convert an ICMP Fragmentation Required message for a tunneled
(and auth'd and 'crypted) packet back into an ICMP Fragmentation Required
for the original, untunnelled packet?
--
Harald Koch <chk@utcc.utoronto.ca>
From owner-ipsec Wed Feb 19 14:22:13 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26072 for ipsec-outgoing; Wed, 19 Feb 1997 14:22:07 -0500 (EST)
Message-Id: <199702191926.AA116680384@relay.hp.com>
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
Cc: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: chk's message of Wed, 19 Feb 1997 14:10:33 -0500.
<97Feb19.141142est.11653@elgreco.rnd.border.com>
Date: Wed, 19 Feb 1997 14:26:22 -0500
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> Yes, but isn't that a Hard Problem (tm) unless you keep state (either
> "virtual interfaces" or individual packets) at the tunnel endpoints?
Well, given that you already need per-outbound-SA state (for the
session key and replay detection) this doesn't seem to be a major
burden. A per-outbound-SA MTU would seem to be the Right Answer..
> How else do you convert an ICMP Fragmentation Required message for a
> tunneled (and auth'd and 'crypted) packet back into an ICMP
> Fragmentation Required for the original, untunnelled packet?
well, one "cheat" occurs to me: don't send a "FR" when you receive a
FR; instead, just record the MTU and let the packet fall on the floor;
if it was important, the sender will retransmit it; when this happens,
and (assuming it's too large), generate a new "fragmentation required"
ICMP message. One drawback is that it takes two packets (instead of
one) for a new tunnel to learn the MTU..
- Bill
From owner-ipsec Wed Feb 19 14:25:43 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26090 for ipsec-outgoing; Wed, 19 Feb 1997 14:25:40 -0500 (EST)
Message-Id: <3.0.32.19970219112532.00957950@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 19 Feb 1997 11:25:35 -0800
To: EKR <ekr@terisa.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: Bob Monsour <rmonsour@earthlink.net>, perry@piermont.com, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 09:47 AM 2/19/97 -0800, EKR wrote:
>> At 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote:
>> >I see you haven't heard of SSL, eh?
>>
>> I am very aware of SSL (and it provides support for compressing prior to
>> encrypting).
>Well, sort of:
>
>There is a socket for compression to be plugged into. There are
>no defined compression plugs (other than null) and I don't expect
>there to be any for some time.
That's funny. When I made a presentation at the TLS (SSL) wg meeting at the
San Jose meeting in December, the first question I asked the group (200+ in
attendance) was how many thought support for compression was important for
TLS. I distinctly recall that well over half of the room raised their
hands. While no one is using a compression "plug" today, I wouldn't go as
far as predicting that there won't "be any for some time". TLS is a case
where it is above the IP layer and where the "packets" are generally larger
and compression can indeed provide a bandwidth benefit. It is also the case
where compression can be done across multiple packets, providing
compression benefits similar to those found in the PPP environment.
Again, in the TLS case, it is the use of encryption in the protocol itself
which will drive the need to compress the data first, providing the
benefits of security without sacrificing performance.
-Bob
From owner-ipsec Wed Feb 19 14:31:17 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26127 for ipsec-outgoing; Wed, 19 Feb 1997 14:31:13 -0500 (EST)
Message-ID: <01BC1E59.0BFEC5A0@Tastid.Cisco.COM>
From: adams@cisco.com (Rob Adams)
To: rmonsour@earthlink.net ('Bob Monsour'),
rpereira@TimeStep.com ('Roy Pereira')
cc: dharkins@cisco.com ('dharkins@cisco.com'), ipsec@tis.com ('ipsec@tis.com')
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Wed, 19 Feb 1997 11:17:06 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
This gets us back into the MTU issue. Shouldn't we be cranking down the MTU
for a route so that we can slide in our extra 40 bytes anyway?
-Rob
----------
From: Roy Pereira[SMTP:rpereira@TimeStep.com]
Sent: Wednesday, February 19, 1997 8:59 AM
To: 'Bob Monsour'
Cc: 'dharkins@cisco.com'; 'ipsec@tis.com'
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
To me the biggest benefit of using compression within ESP is the fact
that I wont have to FRAGMENT as many packets as I would normally due to
the addition of ESP's 40+ byte overhead.
Fragmentation can slow down links considerably, especially when they are
low-speed (28.8k), thus anything that helps prevent fragmentation is a
"good thing".
>
From owner-ipsec Wed Feb 19 14:57:59 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26312 for ipsec-outgoing; Wed, 19 Feb 1997 14:55:27 -0500 (EST)
Message-Id: <199702191959.LAA10030@fluffy.cisco.com>
To: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Wed, 19 Feb 1997 11:59:42 -0800
From: Derrell Piper <piper@tgv.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I'm against coupling compression with IPSEC. I don't believe that this is
the correct place to put it and I am not convinced that putting it there
will actually improve overall performance. The burden of proof should be
on those proposing this to show that there is a reasonable degree of
certainty that this makes good engineering sense. I am not yet convinced.
A few thoughts on the issues...
Compression must be negotiated or else it cannot be deployed. This leads
to want to do it as a TCP option or as an ISAKMP attribute.
Doing it in IPSEC before ESP does not help with the fragmentation issue.
The fragmentation issue is solved by having IPSEC manage the routing layer
when it creates an association. We have implemented this in our Windows 95
IPSEC stack for both Tunnel and Transport modes of AH and ESP and it seems
to work.
You want to compress before TCP has fragmented the packet, not after it.
>From a performance perspective, you'd much rather deal with less packets
than with smaller ones. That's true both for encryption (as Dan Harkins
pointed out) and TCP in general (as Bill Sommerfield observed). This is
very important and implies pushing compression up into TCP.
It is not clear that compressing protocols other than TCP will be a win.
And with TCP, it is certain that there is a fair amount of traffic that
will not benefit from compression either because it's relatively small
(single-character TELNET) or because it has already been compressed at the
application (graphics/video/audio). Doing compression on these packets is
a waste of time.
A compression algorithm might be able to tell that it's losing, but it's
already wasted the cycles at that point. Whether or not compression will
help is an attribute of the data that only the sending application really
has a chance to assert a priori.
Compression is useful indepedent of IPSEC, though in the absense of IPSEC,
it's probably better handled by underlying hardware.
This is leading me to believe that if we are to add this, this should be
added as a negotiated TCP option along with a strong suggestion to stack
vendors to implement a per-socket option to allow applications to enable or
disable compression on the fly.
However, I remain unconvinced that simply adding compression will be the
big win some folks seem to think it will be. Just because encryption makes
in infeasible to do compression afterward doesn't necessarily mean that you
want to do compression beforhand.
Derrell
From owner-ipsec Wed Feb 19 14:59:33 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA26331 for ipsec-outgoing; Wed, 19 Feb 1997 14:59:30 -0500 (EST)
Posted-Date: Wed, 19 Feb 1997 15:00:56 +0000
Message-Id: <9702192003.AA92184@aurora.cis.upenn.edu>
To: "C. Harald Koch" <chk@utcc.utoronto.ca>
Cc: Bill Sommerfeld <sommerfeld@apollo.hp.com>, ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: Your message of "Wed, 19 Feb 1997 14:10:33 EST."
<97Feb19.141142est.11653@elgreco.rnd.border.com>
Date: Wed, 19 Feb 1997 15:00:56 +0000
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
In message <97Feb19.141142est.11653@elgreco.rnd.border.com>, "C. Harald Koch" w
rites:
>
>Yes, but isn't that a Hard Problem (tm) unless you keep state (either
>"virtual interfaces" or individual packets) at the tunnel endpoints? How
>else do you convert an ICMP Fragmentation Required message for a tunneled
>(and auth'd and 'crypted) packet back into an ICMP Fragmentation Required
>for the original, untunnelled packet?
Check the archives for a discussion on this about 2 weeks ago.
I don't think this is a hard problem.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMwtb970pBjh2h1kFAQHougQAhRiBb2pCqrE1SRIt9PNvtQM+kc2QPzDZ
g6+GG6DSZQpwhC2LYN54r17yPo0L26dpk+ZXmNrbLY9xcmQADZyatbXdgJGp3YOX
2wGSvFdd/4dOMqCzFr+SDvKduBThQC/CUXDDJM7EOKVgB4O/8zxwJNfQ+i1k0nSy
VXdh98vYysg=
=41Nw
-----END PGP SIGNATURE-----
From owner-ipsec Wed Feb 19 15:35:06 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26565 for ipsec-outgoing; Wed, 19 Feb 1997 15:34:43 -0500 (EST)
Message-Id: <199702192038.MAA00732@imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Date: Wed, 19 Feb 97 12:38:52 -0800
To: EKR <ekr@terisa.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
cc: Bob Monsour <rmonsour@earthlink.net>, perry@piermont.com, ipsec@tis.com
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
References: <199702191743.JAA14968@itech.terisa.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> > At 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote:
> > >I see you haven't heard of SSL, eh?
> >
> > I am very aware of SSL (and it provides support for compressing prior to
> > encrypting).
>
> Well, sort of:
>
> There is a socket for compression to be plugged into. There are
> no defined compression plugs (other than null) and I don't
> expect there to be any for some time.
>
There is a proposed compression scheme for TLS:
draft-sabin-lzs-tls-00.txt
-dpg
From owner-ipsec Wed Feb 19 15:37:46 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26580 for ipsec-outgoing; Wed, 19 Feb 1997 15:37:42 -0500 (EST)
Message-Id: <9702192042.AA30402@commanche.ca.boeing.com>
To: ipsec@tis.com
Cc: Bob Monsour <rmonsour@earthlink.net>, perry@piermont.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-Reply-To: (Your message of Wed, 19 Feb 97 09:22:48 -0500.)
<199702191422.JAA02189@jekyll.piermont.com>
Date: Wed, 19 Feb 97 12:42:09 -0800
From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" <tld5032@commanche.ca.boeing.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Perry wrote:
> I see you haven't heard of SSL, eh?
>
> Security is very big on the web. People -- and I mean ordinary
> consumers -- want to conduct transactions over it. With a reasonable
> IPSec in place, SSL wouldn't have been necessary. SSL is used every
> day by millions of people to keep their credit card data away from
> prying eyes.
>
Perry is right here, it is our intention to move toward full encryption
on all sessions across public networks first and later toward the same
on internal communications.
Bob wrote:
> The issue for doing the work is less a burden for the client than it is for
> the server. I completely agree that at the client end, the overhead is
> unnoticeable. However, at the server/aggregation points for all these
> clients, the workload would be substantial, if not overwhelming (i.e.,
> without hardware assist). This is true in the case for compression today.
> In some routers that support PPP compression today, if the load on the
> router becomes too great so that the network pipe can't be kept saturated,
> the compression is turned off.
>
Bob is right on this point. We are expecting to see lots of encryption
engine products turn up allow support of encryption at the servers.
Maxing a server with a single 20 megabit DES stream won't cut it if we
intend to do much deployment of IPSEC. We also expect to be looking at
light-weight encryption solutions for non-critical sessions. Encrypting
only critical sessions is just asking for attention you don't want.
>From this point, it is conceivable that some of these light-weight solutions
could be not much more than compressed sessions with light topping of
of hash or cypher.
The solution seems to be which of these combinations has the smallest cost
in cycles for the users particular session:
A) Total overhead cycles = "encryption only"
B) Total overhead cycles = "compression and then encryption"
If I'm sending CAD, GIFs, or other barely compressable objects, it would
seem likely A is the answer. On the other hand, if it is email or a
few thousand pages of maintenance manual, B is probably the cheapest.
(Assuming of coarse equal heavy weight encryptions for both cases)
>From this perspective, being able to negotiate both the encryption and
compression seem to give the end user the best ability to secure their
session and manage the cost of their security.
Answer in our case seems to be "optional compression".
Just as another thought, someone (forgot who) in the bulk of mail on this
subject, stated or implied that saving "network bandwidth" was the most
important goal. I suspect that savings "server CPU cycles" will far
outweight "network bandwidth" concerns in at least our case.
Take care
| Terry L. Davis, P.E. | Boeing Information & Support Services |
| Phone: 206-957-5325 | Bellevue, Washington, USA |
| Email: terry.l.davis@boeing.com. |
--------------- Wednesday February 19,1997 12:32 PM PST -------------
PS: Can we manage that much flexibility on day one; probably not. But
on the other hand a CAD server has a certain basic profile and a
manual server has another so perhaps we may do better than one
would expect at first glance.
From owner-ipsec Wed Feb 19 15:50:02 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA26644 for ipsec-outgoing; Wed, 19 Feb 1997 15:49:47 -0500 (EST)
Message-Id: <199702192051.MAA16577@itech.terisa.com>
X-Authentication-Warning: itech.terisa.com: Host kmac.terisa.COM didn't use HELO protocol
To: Bob Monsour <rmonsour@earthlink.net>
cc: perry@piermont.com, ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-reply-to: Your message of "Wed, 19 Feb 1997 11:25:35 PST."
<3.0.32.19970219112532.00957950@earthlink.net>
Date: Wed, 19 Feb 1997 12:55:34 -0800
From: EKR <ekr@terisa.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> At 09:47 AM 2/19/97 -0800, EKR wrote:
> >> At 09:22 AM 2/19/97 -0500, Perry E. Metzger wrote:
> >> >I see you haven't heard of SSL, eh?
> >>
> >> I am very aware of SSL (and it provides support for compressing prior to
> >> encrypting).
> >Well, sort of:
> >
> >There is a socket for compression to be plugged into. There are
> >no defined compression plugs (other than null) and I don't expect
> >there to be any for some time.
>
> That's funny. When I made a presentation at the TLS (SSL) wg meeting at the
> San Jose meeting in December, the first question I asked the group (200+ in
> attendance) was how many thought support for compression was important for
> TLS. I distinctly recall that well over half of the room raised their
> hands. While no one is using a compression "plug" today, I wouldn't go as
> far as predicting that there won't "be any for some time".
Here's a brief summary of the situation:
TLS is in the process of preparing a document that describes
TLS-1.0 (3.0?). That document will not have compression in it.
After that, the floor is open for TLS 1.1 (3.1?) which might
or might not have compression and N other things in it, but
essentially none of the details of that protocol have been
hashed out, which means it won't be out for 'some time', IMHO.
That's what I based my comments on.
-Ekr
From owner-ipsec Wed Feb 19 16:25:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA26974 for ipsec-outgoing; Wed, 19 Feb 1997 16:24:05 -0500 (EST)
Message-Id: <199702192113.NAA00756@imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Date: Wed, 19 Feb 97 13:12:59 -0800
To: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
References: <199702191959.LAA10030@fluffy.cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
The yes-compress/no-compression discussion is akin to
comparing Pepsi and Coke. Let's put a framework in place and
make it optional and negotiated. Let empirical data determine
its usefulness.
-dpg
From owner-ipsec Wed Feb 19 17:30:45 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA27412 for ipsec-outgoing; Wed, 19 Feb 1997 17:30:06 -0500 (EST)
Message-ID: <01BC1E72.3119A300@Tastid.Cisco.COM>
From: adams@cisco.com (Rob Adams)
To: ipsec@tis.com (ipsec@tis.com)
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Date: Wed, 19 Feb 1997 14:35:14 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I concur with Derrell. Whether compression is a good thing remains to be seen.
However, if we are going to do compression we should determine the appropriate
way to implement it. I don't think this issue has been thought through enough
byall of us to flatly say that IPsec is the right vehicle for delivering compression.
I'm not against compression, I'm against doing it more than once and at all sorts of
layers throughout a stack. We already have compression at the hardware link layer.
We have compression of certain data by applications such as voice/video/image etc.
TLS may end up with compression of its own. Now we're contemplating adding
compression at a low enough level that the application won't have any control over
what gets compressed. And the layer we're thinking of is low enough that we won't
be able to use stateful compression algorithms because we're adding compression
to a stateless protocol.
We're also talking about linking compression with a specific set of IPsec transforms.
This seems limiting and binding to me. Everytime we have a new set of transforms
we'll have to go through this discussion again. "Where are we going to stick the
bit or byte this time that indicates this packet...... " Wouldn't a framework for
including compression in all transforms make more sense if we are to link compression
to IPsec at all?
TCP seems to be a much better place to do compression than at the IP layer
for many reasons.
From owner-ipsec Wed Feb 19 23:23:49 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA29251 for ipsec-outgoing; Wed, 19 Feb 1997 23:19:05 -0500 (EST)
Date: Thu, 20 Feb 97 04:13:36 GMT Standard Time
From: Ran Atkinson <rja@inet.org>
Subject: IPsec Straw Poll results
To: IPsec WG <ipsec@tis.com>
X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc.
X-Priority: 3 (Normal)
Message-ID: <Chameleon.856412371.rja@c8-a.snvl1.sfba.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
All,
The email I've seen, both privately and on the list, indicates that
there is rough (but not smooth) consensus within the IPsec WG that:
ESP/AH should use a fixed size 32 bit counter for replay detection.
The IETF requirement is for rough consensus, which has been met.
On the truncation question, the overwhelming response was of the form
"Hugo is the expert, go with whatever Hugo recommends."
So I'd like to ask Hugo to post a note with his formal recommendation
with regards to truncation in AH HMAC SHA-1/MD5 so that the documents
can be edited accordingly. Then perhaps the AH HMAC document editors
can create new I-Ds, put them online, and perhaps present them at
the Memphis IETF.
I spoke on the telephone with Paul Lambert <palamber@us.oracle.com>,
IPsec Co-Chair, on Tuesday and he verbally concurred with the above.
Ran
rja@inet.org
The other IPsec Co-Chair
From owner-ipsec Thu Feb 20 05:54:51 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA01462 for ipsec-outgoing; Thu, 20 Feb 1997 05:52:58 -0500 (EST)
Message-Id: <199702192303.BAA00169@morden.sandelman.ottawa.on.ca>
To: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-reply-to: Your message of "Wed, 19 Feb 1997 13:12:59 PST."
<199702192113.NAA00756@imo.plaintalk.bellevue.wa.us>
Date: Thu, 20 Feb 1997 01:01:55 +0200
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>>>>> "Dennis" == Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us> writes:
Dennis> The yes-compress/no-compression discussion is akin to
Dennis> comparing Pepsi and Coke. Let's put a framework in place
Dennis> and make it optional and negotiated. Let empirical data
Dennis> determine its usefulness.
As long as it is negotiated, I see no reason why one needs
a flag to indicate compression. One simply negotiates two SPIs. One
SPI is compressed, the other is not. If the data doesn't compress (or
is too short to even bother trying: a TCP ACK, or telnet keystroke
data) then you use the SPI that didn't have compression negotiated.
My reading of the literature on high performance (parallelizing)
networking says that the sooner you can categorize the packets the
better you do. For TCP/UDP this means sorting by port number and
*then* worrying those other things like options, fragments, etc..
For IPsec, the SPI is what I'd sort by.
] Temporarily located in balmy Helsinki, Finland | one quark [
] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
From owner-ipsec Thu Feb 20 08:57:38 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA02605 for ipsec-outgoing; Thu, 20 Feb 1997 08:53:53 -0500 (EST)
From: Robert Glenn <glenn@snad.ncsl.nist.gov>
Date: Thu, 20 Feb 1997 08:57:57 -0500 (EST)
Message-Id: <199702201357.IAA03886@sloth.ncsl.nist.gov>
To: ipsec@tis.com
Subject: Re: IPsec Straw Poll results
Cc: hugo@watson.ibm.com, mjo@tycho.ncsc.mil, rob.glenn@nist.gov,
sjchang@snad.ncsl.nist.gov
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Great! As one of the editors, I'm very happy that this has been resolved
and we can start moving forward.
There are 2 small issues that I'm still not quite clear on but here is
the direction I'm moving towards (and will probably be in the first cut of the
new drafts). 1) The fixed size 32 bit counter will be optional such that
if replay prevention is not supported the field will be zeroed and ignored
upon receipt - but *WILL* still be included in the HMAC calculation. 2) To
resolve the alignment problem, the HMAC Authentication data will be truncated
to 96 bits as suggested earlier by both Hugo Krawczyk and Bart Preneel.
Rob G.
rob.glenn@nist.gov
From owner-ipsec Thu Feb 20 11:03:43 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA03796 for ipsec-outgoing; Thu, 20 Feb 1997 11:01:08 -0500 (EST)
From: HUGO@watson.ibm.com
Message-Id: <199702201605.LAA37530@mailhub1.watson.ibm.com>
Date: Thu, 20 Feb 97 10:58:15 EST
To: glenn@snad.ncsl.nist.gov, ipsec@tis.com
cc: mjo@tycho.ncsc.mil, rob.glenn@nist.gov, sjchang@snad.ncsl.nist.gov,
pau@watson.ibm.com
Subject: IPsec Straw Poll results
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Ref: Your note of Thu, 20 Feb 1997 08:57:57 -0500 (EST) (attached)
> Great! As one of the editors, I'm very happy that this has been resolved
> and we can start moving forward.
>
> There are 2 small issues that I'm still not quite clear on but here is
> the direction I'm moving towards (and will probably be in the first cut of the
> new drafts). 1) The fixed size 32 bit counter will be optional such that
> if replay prevention is not supported the field will be zeroed and ignored
> upon receipt - but *WILL* still be included in the HMAC calculation. 2) To
> resolve the alignment problem, the HMAC Authentication data will be truncated
> to 96 bits as suggested earlier by both Hugo Krawczyk and Bart Preneel.
>
> Rob G.
> rob.glenn@nist.gov
I definitely support the above approach. In particular, truncation to 96
bits for both HMAC-MD5 and HMAC-SHA1 (in the language of rfc2104 this will
be HMAC-MD5-96 and HMAC-SHA1-96).
Rob: since the test vectors for HMAC-SHA1 did not make it into rfc2104
I recommend you'll have them in the HMAC-SHA1 document.
Please talk to Pau-Chen about our (tested) results.
Hugo
From owner-ipsec Thu Feb 20 11:50:25 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA04207 for ipsec-outgoing; Thu, 20 Feb 1997 11:47:33 -0500 (EST)
From: owner-ipsec@ex.tis.com
Message-Id: <199702201647.LAA04207@portal.ex.tis.com>
To: "'niels@DigiCash.com'" <niels@DigiCash.com>,
"'ipsec@TIS.COM'"
<ipsec@tis.com>
Subject: HMAC with SHS
Date: Thu, 20 Feb 1997 11:25:02 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id
LAA04087
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
Hi,
I'm currently implementing an HMAC authentication algorithm using
SHS as the primitive (based on RFC-2104). I was wondering if anyone
else had done so and
if there are test vectors available for SHS (the RFC only provides one
test vector for MD5). Not that I think I could have gotten it wrong,
but just to be on the safe side.
Thanks in advance.
Xavier Lévèque
Nova Expertise Solutions
Tél.: (514) 397-5400 (ext.: 5555)
Fax: (514) 288-0486
mailto:levequex@novanet.ca
mailto:levequex@videotron.ca
From owner-ipsec Thu Feb 20 14:28:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05317 for ipsec-outgoing; Thu, 20 Feb 1997 14:23:50 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199702201928.LAA15017@kebe.eng.sun.com>
Subject: Just to be clear on truncation...
To: ipsec@tis.com
Date: Thu, 20 Feb 1997 11:28:18 -0800 (PST)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
I asked Hugo which bits I should chop off for a truncation. Here's his
reply:
Forwarded message:
> From HUGO@watson.ibm.com Thu Feb 20 11:16:02 1997
> From: HUGO@watson.ibm.com
> Message-Id: <199702201915.OAA23526@mailhub1.watson.ibm.com>
> Date: Thu, 20 Feb 97 14:12:39 EST
> To: Dan.McDonald@Eng
> Subject: IPsec Straw Poll results
> content-length: 2071
>
> Ref: Your note of Thu, 20 Feb 1997 11:00:10 -0800 (PST) (attached)
>
> rfc2104 says to leave the leftmost bits, ie. chop off the low bits.
>
> Hugo
>
> PS: you're welcome to post this to ipsec (with your example)
Since Hugo said to post this to IPsec, I figured I would, with my example.
Let's say I start off with the following 128-bit HMAC-MD5 computation:
> 0901 2504 2112 5150 1984 0311 dead beef
The right thing to do is to chop off the low bits, so the above would become:
> 0901 2504 2112 5150 1984 0311 (chop off low bits)
Dan
From owner-ipsec Thu Feb 20 15:28:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA05800 for ipsec-outgoing; Thu, 20 Feb 1997 15:25:50 -0500 (EST)
Message-Id: <01BC1F40.2083AE40@erussell-2.ftp.com>
From: "Edward A. Russell" <erussell@ftp.com>
To: "'owner-ipsec@ex.tis.com'" <owner-ipsec@ex.tis.com>,
"'niels@DigiCash.com'" <niels@DigiCash.com>,
"'ipsec@tis.com'" <ipsec@tis.com>,
"'(LevequeX@novanet.ca'" <"'(LevequeX@novanet.ca'"@tis.com (LevequeX@novanet.ca"'(LevequeX@novanet.ca'"<>>)>)>
Subject: re: HMAC with SHS
Date: Thu, 20 Feb 1997 15:09:52 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA05692
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>>Lévèque, Xavier (LevequeX@novanet.ca) said on 2/20/97 1:27 PM about RE: HMAC with SHS
:
: I'm currently implementing an HMAC authentication algorithm using
: SHS as the primitive (based on RFC-2104). I was wondering if anyone
: else had done so and
: if there are test vectors available for SHS (the RFC only provides one
: test vector for MD5). Not that I think I could have gotten it wrong,
: but just to be on the safe side.
Here are Test Vectors for SHA and HMAC SHA with both the CYLINK and BSAFE Libraries.
The different results are accounted for by an LSB/MSB ordering issue.
Latest word is that CYLINK will repair their code to match the BSAFE version.
HMAC KEY =
0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0b
HMAC KEY LENGTH = 16
DATA "Hi There"
DATA LENGTH = 8
DIGESTs:
BSAFE HMAC SHA:
67 5B 0B 3A 1B 4D DF 4E 12 48 72 DA 6C 2F 63 2B FE D9 57 E9
CYLINK HMAC SHA:
BC F6 85 57 4C B8 AA B1 B6 42 CE CB F3 89 A0 79 F6 48 84 F3
BSAFE SHA:
4B 3A ED 5F 9F E4 01 59 B4 99 53 6F B8 A1 0C DF 3B C6 2B 4C
CYLINK SHA:
4C 2B C6 3B DF 0C A1 B8 6F 53 99 B4 59 01 E4 9F 5F ED 3A 4B
Edward Russell
erussell@ftp.com
From owner-ipsec Thu Feb 20 16:39:11 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA06254 for ipsec-outgoing; Thu, 20 Feb 1997 16:35:13 -0500 (EST)
Message-Id: <3.0.16.19970220163456.217f7682@pop3.pn.com>
X-Pgp-Key: <http://www.shore.net/~sable/info/rltkey.htm>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 3.0 (16)
Date: Thu, 20 Feb 1997 16:39:21 -0500
To: perry@piermont.com
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
In my experience path MTU discovery is not always present. I think it
should be, but since we're considering the real world here (right?) I think
you can't rely on that.
At 12:13 PM 2/19/97 -0500, you wrote:
>
>Roy Pereira writes:
>> To me the biggest benefit of using compression within ESP is the fact
>> that I wont have to FRAGMENT as many packets as I would normally due to
>> the addition of ESP's 40+ byte overhead.
>>
>> Fragmentation can slow down links considerably, especially when they are
>> low-speed (28.8k), thus anything that helps prevent fragmentation is a
>> "good thing".
>
>I don't understand this at all.
>
>If you have path MTU discovery, why would you ever fragment?
>
>Perry
>
>
--------
Rodney Thayer <rodney@sabletech.com>
PGP Fingerprint: BB1B6428 409129AC 076B9DE1 4C250DD8
From owner-ipsec Fri Feb 21 13:56:28 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13580 for ipsec-outgoing; Fri, 21 Feb 1997 13:46:15 -0500 (EST)
Date: Fri, 21 Feb 1997 16:43:53 -0300
From: ormonde@trem.cnt.org.br (Rodrigo Ormonde)
Message-Id: <9702211943.AA12998@trem.cnt.org.br>
Apparently-To: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
From owner-ipsec Fri Feb 21 16:28:17 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14619 for ipsec-outgoing; Fri, 21 Feb 1997 16:23:57 -0500 (EST)
Date: Fri, 21 Feb 97 16:36:01 EST
From: wdm@epoch.ncsc.mil (W. Douglas Maughan)
Message-Id: <9702212136.AA04856@dolphin.ncsc.mil>
To: ipsec@tis.com
Subject: ISAKMP - New Version
Content-Type: X-sun-attachment
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 18
All,
A new version of the ISAKMP Internet Draft has been sent to press. It
should be available in the near future. In the meantime, the attached
document explains the changes made from version 6. Most of these
changes were made based on comments received during WG Last Call.
Special thanks to:
Greg Carter Nortel
Richard Waterhouse GTE
Dennis Glatting plaintalk.bellevue.wa.us
John Burke Cylink
for their detailed review of version 6 of the protocol specification
and the comments they provided.
Doug Maughan
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: isakmp_v6_comms
X-Sun-Content-Lines: 323
ISAKMP - Summary and rationale of changes based on comments received
during IPSEC Working Group Last Call
There were several additional minor editorial changes made that are not
included in this summary.
*****************************************************************************
> From carterg@nortel.ca Mon Dec 16 15:13:37 1996
> From: "Greg Carter" <carterg@nortel.ca>
> I heard CRL\ARL types made it into the draft. Great!
ACTION: Accepted
RATIONALE: Based on agreement at December IETF
LOCATION: Section 3.9
*****************************************************************************
> From Waterhouse@nt1-ndhm.chnt.gtegsc.com Tue Dec 10 08:42:16 1996
> From: "Waterhouse, Richard" <Waterhouse@nt1-ndhm.chnt.gtegsc.com>
> I'm confused, in Section 3.5 length of the SPI is always 8 in a Proposal
> Payload. Everywhere else the length of the SPI appears to be variable
> length and a function of the Protocol-Id. Why is it handled differently
> in the Proposal Payload ?
ACTION: Changed Proposal Payload to include a SPI Size field of 1 octet and
downsized the # of Transforms field from 2 octets to 1 octet.
RATIONALE: To be similar (conceptually) to the Delete and Notify Payloads
and provide the ability to support multiple protocols with no
restriction on SPI length.
LOCATION: Section 3.5
*****************************************************************************
>From Waterhouse@nt1-ndhm.chnt.gtegsc.com Wed Dec 11 08:31:57 1996
> From: "Waterhouse, Richard" <Waterhouse@nt1-ndhm.chnt.gtegsc.com>
> Two questions/comments on version
> 1. The distinction of Major Version and Minor Version is not clear from
> the document. Why isn't there just a Version ? (In particular how should
> the future processing of minor version differ from the future processing
> of major version when there are multiple versions? I usually like to
> provide for future probable evolution paths and the fact that you have
> made this distinction seems to imply you have something in mind that
> isn't explicitly stated.)
> 2. If versioning is useful in ISAKMP itself it would appear to be at
> least as useful at the DOI level (which I would guess would be subject
> to more frequent change than is ISAKMP itself). Certainly our
> application envisions an evolving DOI with provision for some level of
> backward compatibility.
Response from:
>> From: David Carrel <carrel@cisco.com>
>> 1. The distinction of Major Version and Minor Version is not clear from the
>> document. Why isn't there just a Version ? (In particular how should the
>> future processing of minor version differ from the future processing of
>> major version when there are multiple versions? I usually like to provide
>> for future probable evolution paths and the fact that you have made this
>> distinction seems to imply you have something in mind that isn't explicitly
>> stated.)
> There is no pre-planned use for the minor version numbers. They can be
> useful, they can also go unused. Future use of them will be determined
> when we come up with an incompatible change to make.
> Nonetheless, your point is valid that their use is ambiguous. We should
> define for now that an implementation should never accept packets with a
> major OR minor number that is larger than it's own. As for accepting ones
> that are smaller, that will be defined as those changes are made.
> One motivation for the distinction between major and minor version is that
> the old 4 bit version number just happens to occupy the same four bits as
> the current major version number. So if previous implementations of ISAKMP
> receive the current packets, they can easily tell they are the wrong
> version. Same thing when going the other way as well.
>> 2. If versioning is useful in ISAKMP itself it would appear to be at least
>> as useful at the DOI level (which I would guess would be subject to more
>> frequent change than is ISAKMP itself). Certainly our application
>> envisions an evolving DOI with provision for some level of backward
>> compatibility.
> Good thought. I'll have to ponder this a bit more...
ACTION: Accepted - Additional text added
Response to #2 left for editor of the DOI document
RATIONALE: Clarify use of Major and Minor version fields
LOCATION: Section 3.1
*****************************************************************************
> From: mamros@ftp.com (Shawn Mamros)
> Date: Tue, 17 Dec 1996 14:41:59 -0500
> In the isakmp-06 draft, the Notify and Delete payloads both contain
> a Protocol-Id field, so that the SPI(s) contained in those payloads
> can be associated with the proper protocol SA(s) in question.
> However, Protocol-Id values (other than value 1, which is always used
> for the ISAKMP protocol itself) are defined in the DOI document, and
> there is no field in the Notify and Delete payloads which specify which
> DOI is being used. (The only place the DOI is specified is in the
> Security Association payload.)
> I suppose that, as long as any new Protocol-Id values for any yet-to-
> be-defined DOIs do not conflict with those already assigned for
> IPSEC AH and IPSEC ESP, then this isn't a problem. But, if there is
> a possibility of conflict, then there will have to be some way to
> associate the Protocol-Id with the proper DOI. Adding a DOI field
> to the Notify and Delete payloads might be one way to do this, if it's
> needed.
> So, I guess what I'm wondering is: Is there a possibility of conflicting
> Protocol-Ids between different DOIs? And, if so, what should be done
> about it for the Notify and Delete payloads? If, on the other hand,
> there will be no conflicts - if all future Protocol-Ids will be unique,
> regardless of DOI - then this should be stated somewhere.
ACTION: Accepted - DOI field added to the Notify and Delete Payload
RATIONALE: It is feasible that a user could be communicating in more than
one DOI simultaneously. Therefore, deletions and notifications
need to be differentiated based not only on the Protocol-ID,
but on the combination of DOI and Protocol-ID.
LOCATION: Sections 3.14 and 3.15
*****************************************************************************
> From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
> Date: Tue, 24 Dec 96 16:12:44 -0800
>> >From Appendix A of draft-ietf-ipsec-isakmp-06.txt:
>>
>> > Security protocol values 2-1024 are reserved for IANA use. Values 1025-
>> > 15360 are reserved for future use. Values 15360-16384 are reserved for
>> > private use.
>> >
>>
>> The future and private use protocol values overlap. Should
>> private use be 15361-16384?
>>
> Also, if protocol values start at 0, the last possible value is
> 16383, not 16384.
ACTION: Accepted - Values changed accordingly
RATIONALE: Correctness
LOCATION: Appendix A
*****************************************************************************`
> From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
> Date: Wed, 25 Dec 96 20:40:18 -0800
> I believe draft-ietf-ipsec-isakmp-06.txt does not specify
> byte ordering of integral quantities. Is the ordering network
> order?
ACTION: Accepted - Text added
RATIONALE: Clarification
LOCATION: Section 3
*****************************************************************************`
> From: "Waterhouse, Richard" <Waterhouse@nt1-ndhm.chnt.gtegsc.com>
> Date: Fri, 3 Jan 1997 09:54:37 -0500
> I need to confirm my understanding of your intent.
> If the examples in Section 4.1.1 occurred within an Aggressive Exchange,
> it would be the NP field of the last Proposal Payload, not the NP field
> of the last Transform Payload, which would identify the following KE
> Payload Type.
> Is this correct ?
Additionally ....
> From: Greg Carter <carterg@entrust.com>
> Date: Wed, 15 Jan 1997 18:46:22 -0500
> Could those in the know please clarify the next payload for SA
> payloads. In the examples it is always set to PROPOSAL, but from the
> wording of the ISAKMP doc it suggests otherwise and my opinion is that
> it should be otherwise, the next NON SA related payload ( ie in
> aggresive mode it would be KE, NONE for Main Mode).
> Section 4.1 SA Establishment (Page 41 first paragraph)
> ..."An SA establishment message consists of a single SA payload followed
> by AT LEAST one and possible many proposal and transform payloads."
> so there isn't a need to look to the next payload of the SA header to
> know that the data in the SA payload is in fact a proposal. Since this
> is in the ISAKMP doc I would assume that this would have to hold up
> across any DOI.
> Section 4.1 SA Establishment (Page 42 first paragraph)
> ..."Note that the Next Payload field of the proposal payload points to
> another Proposal (if it exists)."
> same section last paragraph
> ..."Note that the Next Payload field of the Transform payload points to
> another Transform payload or 0."
> So if we can't get it from the proposal or transform(which I don't think
> would be a good idea anyways) then we have to get it from the SA header.
Response from:
From: wdm@epoch.ncsc.mil (W. Douglas Maughan)
Date: Thu, 16 Jan 97 08:29:52 EST
>> Could those in the know please clarify the next payload for SA
>> payloads. In the examples it is always set to PROPOSAL, but from the
>> wording of the ISAKMP doc it suggests otherwise and my opinion is that
>> it should be otherwise, the next NON SA related payload ( ie in
>> aggresive mode it would be KE, NONE for Main Mode).
> The Next Payload field of an SA payload will point to the next payload
> of the message (if one exists) and not to the Proposal payload as
> version 6 of the draft specifies.
>> Section 4.1 SA Establishment (Page 41 first paragraph)
>> ..."An SA establishment message consists of a single SA payload followed
>> by AT LEAST one and possible many proposal and transform payloads."
>>
>> so there isn't a need to look to the next payload of the SA header to
>> know that the data in the SA payload is in fact a proposal. Since this
>> is in the ISAKMP doc I would assume that this would have to hold up
>> across any DOI.
> Correct.
>> Section 4.1 SA Establishment (Page 42 first paragraph)
>> ..."Note that the Next Payload field of the proposal payload points to
>> another Proposal (if it exists)."
>>
>> same section last paragraph
>> ..."Note that the Next Payload field of the Transform payload points to
>> another Transform payload or 0."
>>
>> So if we can't get it from the proposal or transform(which I don't think
>> would be a good idea anyways) then we have to get it from the SA header.
> Correct.
ACTION: Accepted - Text changed and clarifications added
RATIONALE: Next Payload fields of SA, Proposal, and Transform fields
modified to simplify processing.
LOCATION: Sections 3.4, 3.5, 3.6, 4.1.1
*****************************************************************************`
> From: John Burke <jburke@cylink.com>
> Date: Thu, 09 Jan 1997 10:41:34 -0500
> TLV Attributes:
> The discussion of TLV Attribute format specifies "word alignment";
> "word" is not a precise term. Two-octet? Four? And the wording
> of this section does not actually say alignment is required, but
> it sounds like it wants to.
>
> It unequivocally says any padding must be by leading zeroes; this
> gives no guidance to someone who invents a character attribute.
ACTION: Accepted - Text changed and clarifications added
RATIONALE: Clarify use of the Data Attributes
LOCATION: Section 3.3
*****************************************************************************`
> From: John Burke <jburke@cylink.com>
> Date: Thu, 09 Jan 1997 10:41:34 -0500
> o General:
> It appears clear to me that all payloads in messages may appear
> unaligned, since some can have a size of odd bytes. The text
> should state this, since the pictures show several things as
> being four bytes wide though this is not required by the text.
>
> If we do want alignment it has to be stated explictly, and as
> "aligned at 4-byte multiples" or "2-byte".
ACTION: Accepted - Text added
RATIONALE: Clarification
LOCATION: Section 3
*****************************************************************************`
ACTION: Added an additional Certificate Encoding type to diferentiate
between the use of X.509 certificates for signatures and key
exchange.
RATIONALE: X.509 Certificates can be used for both signatures and key
exchange purposes.
LOCATION: Section 3.9
*****************************************************************************`
ACTION: Added text to the description of the Payload Length field for
the Proposal Payload.
RATIONALE: In the event there are multiple proposals with the same
proposal number, the length field only applies to the specific
proposal payload and not to multiple proposal payloads.
LOCATION: Section 3.5
*****************************************************************************`
ACTION: Added text to clarify the processing of the Proposal and
Transform payloads.
RATIONALE: The initiator may propose multiple proposals, each with
multiple transforms. THe responder chooses one of these
proposal and responds to the initiator. The format of this
returned information can help the protocol processing of the
initiator.
LOCATION: Section 4.1
*****************************************************************************`
From owner-ipsec Fri Feb 21 18:36:59 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15333 for ipsec-outgoing; Fri, 21 Feb 1997 18:36:08 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v03007804af33ade1e770@[128.33.229.242]>
In-Reply-To: <01BC1E72.3119A300@Tastid.Cisco.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Feb 1997 15:13:32 -0500
To: adams@cisco.com (Rob Adams)
From: Stephen Kent <kent@bbn.com>
Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com (ipsec@tis.com)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Rob,
As you noted, compression, like encryption, can be provided at
various layers. We have to make smart choices as to where to offer the
function, but that doesn't mean that there is a single, right answer, no
more than there is a single, right layer at which to offer encryption.
Compression can be optimized at the application layer where there
is knowledge of the data types being compressed, and for static, stored
data (e.g., GIFs) this is great. But, not all of our traffic is of this
sort, and so we cannot rely on this later of compression in all cases.
Encryption at the application layer has many of the same benefits, but it
also has drawbacks, e.g., the need to develop and/or integrate the
mechanisms for each application (hence the motivation for GSSAPI).
At the other end of the stack, we do link layer compression
whereever it seems useful, at a point where we have no knowldege at all
about the data types. This has proved quite useful for dialup and wireless
transmission systems. It often is done in hardware and is applied
selectovely, where the processing/bandwidth tradeoff analysis suggests it
is useful. However, use of encrytion at any higher layer negates the
effectiveness of link layer encryption, and that is one motivation for
inclusion of compression at a higher layer.
The IP layer is a good candidate primarily because that's where we
are adding encryption (in the context of this WG) and thus we have the
opportunity to help offset the effects of the encryption that we are
imposing. Of course, we don't have access to data type info, so we won't
be able to do as good a job as at the application layer, but we do have the
benefit of being able to apply (or consider applying) compression to all
the traffic we encrypt, without modifying any other protocols, i.e., by
keeping within the subl-layer where we are introducing new protocols anyway.
If we move up to the transport layer, there isn't any better data
type knowledge, and we now are looking at making changes to each transport
protocol (if we want to offer as broad a service), plus having to change a
protocol that was not being modified otherwise (or adding a new sub-layer).
Also, if we choose to compress because we are encrypting, compressing at
the tranport layer is not consistent with the use of ESP, since ESP is a
lower layer and knowledge of its use should not be visible at the transport
layer.
SSL, in optionally offering compression, is taking the same tact
that we are exploring for ESP, and I think that is consistent.
From a pragmatic perspective, if we don't offer compression in ESP,
then we ought not expect it to be available anytime soon, to help counter
the packet size expension effects of ESP and to help alleviate the link
layer compression loss problems.
Steve
From owner-ipsec Fri Feb 21 18:36:58 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15334 for ipsec-outgoing; Fri, 21 Feb 1997 18:36:11 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v03007803af33acd6a8df@[128.33.229.242]>
In-Reply-To: <199702192113.NAA00756@imo.plaintalk.bellevue.wa.us>
References: <199702191959.LAA10030@fluffy.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Feb 1997 14:53:02 -0500
To: dennis.glatting@plaintalk.bellevue.wa.us
From: Stephen Kent <kent@bbn.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dennis,
This discussion has been taking place entirely in the context of an
optional transformation, negotiated during SA establishment. There is no
intent to make use of compression mandatory. If we decide to include it as
an option, one would negotiate a specific compression algorithm in
conjunction with a sp[ecific encryption algorithm. There is a separate
issue of whether it would be mandatory to inplement this option as part of
a compliant ESP implementation, but we have not yet had that debate.
Steve
From owner-ipsec Fri Feb 21 18:36:58 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15340 for ipsec-outgoing; Fri, 21 Feb 1997 18:36:37 -0500 (EST)
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v03007806af33b2be0bf8@[128.33.229.242]>
In-Reply-To: <199702192303.BAA00169@morden.sandelman.ottawa.on.ca>
References: Your message of "Wed, 19 Feb 1997 13:12:59 PST."
<199702192113.NAA00756@imo.plaintalk.bellevue.wa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Feb 1997 15:19:18 -0500
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
From: Stephen Kent <kent@bbn.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Mike,
One could use two SPIs to distinguish compressed vs. uncompressed
data, but since one needs to decrypt prior to decompressing, I don't know
that this different approach to demuxing is beneficial. Aloso, if we also
are using anti-replay facilities, I now worry about the fact that these two
portions of the same data stream have been split apart and are not
synchronized. I cannot (off the top of my head) gove a good argument why
this may be a problem, but it's bothersome.
Steve
From owner-ipsec Fri Feb 21 20:17:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15811 for ipsec-outgoing; Fri, 21 Feb 1997 20:16:08 -0500 (EST)
Message-Id: <199702220120.RAA01941@imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting@plaintalk.bellevue.wa.us>
Date: Fri, 21 Feb 97 17:20:27 -0800
To: Stephen Kent <kent@bbn.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
cc: ipsec@tis.com
Reply-To: dennis.glatting@plaintalk.bellevue.wa.us
References: <199702191959.LAA10030@fluffy.cisco.com>
<v03007803af33acd6a8df@[128.33.229.242]>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
It was (is?) my impression the question was whether
compression is optional or not at all, though at times I was
confused because the discussion appeared to boarder
mandatory inclusion. Thanks for clarifying.
I am not in a position to say where compression does and does not
belong. I find all of the points for and against compression
interesting, enlightening (for me), and with merit. However,
I believe a facility should be provided within the spec so the
value of compression can be evaluated and empirical data
gathered for future analysis and protocol development. My
vote, for what it is worth, is inclusion.
If you folks will indulge me, perhaps off-line, many on this
list spoke of wasting CPU cycles compressing the
uncompressible. I have seen only a brief discussion on wasting
CPU cycles encrypting the encrypted. An example is encrypting
SSL traffic that may or may not be strongly encrypted, or not
encrypted at all. Certainly there is reason to insure via IPsec
that traffic as well as other secured application traffic
(e.g., snews, klogin) is strongly encrypted; however,
encrypting the encrypted, I believe, not only wastes CPU
cycles but (if I understand things correctly) can weaken
overall data confidentiality. Comments? How is compressing
the uncompressible a worse waste of time?
-dpg
From owner-ipsec Fri Feb 21 20:42:26 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15941 for ipsec-outgoing; Fri, 21 Feb 1997 20:41:36 -0500 (EST)
Date: Sat, 22 Feb 1997 12:45:42 +1100 (EST)
From: Kent Fitch <Kent.Fitch@its.csiro.au>
X-Sender: fit106@commsun
Reply-To: Kent Fitch <Kent.Fitch@its.csiro.au>
To: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Message-ID: <Pine.GSO.3.93.970222122545.2059A-100000@commsun>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
The W3C recently published an interesting note on the Network Performance
Effects of HTTP/1.1, Cascading Style Sheets and PNG image formats which
may provide more information for this debate:
http://www.w3.org/pub/WWW/Protocols/HTTP/Performance/Pipeline.html
HTTP is a major component of my organization's WAN traffic, although maybe
it is not signficant for everyone. Their study of HTTP/1.0 -v- HTTP/1.1
shows that signficiant reductions in packets, bytes and response time can
be expected using a persistent connection, pipelining requests on that
connection. Compressing HTML in the application using zlib yielded a
further small improvement. Using PNG rather than GIF was estimated as
reducing payloads only slightly, but the ability to replace many images
with style sheet markup provided much bigger benefits.
Kent Fitch Ph: +61 6 276 6711
ITS CSIRO Canberra Australia kent.fitch@its.csiro.au
From owner-ipsec Fri Feb 21 21:53:03 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA16293 for ipsec-outgoing; Fri, 21 Feb 1997 21:52:13 -0500 (EST)
Message-ID: <c=US%a=_%p=msft%l=RED-74-MSG-970222011832Z-4004@INET-05-IMC.microsoft.com>
From: Sanjay Anand <sanjayan@microsoft.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: RE: Path MTU Discovery
Date: Fri, 21 Feb 1997 17:18:32 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>
>> Another point is that fragmentation checking should be done before any
>> IPsec handling takes place (easier and faster).
>
>WRONG FOR OUTBOUND PACKETS!!! This is in clear violation of RFC 1825. Lemme
>quote:
>
>>> 3.1 AUTHENTICATION HEADER
>
><SNIP!>
>
>>> Fragmentation occurs after the Authentication Header processing for
>>> outbound packets and prior to Authentication Header processing for
>>> inbound packets. The receiver verifies the correctness of the
>
>There actually isn't text in the ESP section, but I'll bet small sums that
>either Ran A. or Steve K. will back me up on this one.
>
>If you meant inbound packets, my bad.
>
>on the inbound side, what does this mean: "fragmentation occurs prior to AH
>processing"
>does this mean reassembly occurs prior to AH processing ?
From owner-ipsec Mon Feb 24 10:18:54 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA01913 for ipsec-outgoing; Mon, 24 Feb 1997 10:08:44 -0500 (EST)
To: IETF-Announce:;;;;@tis.com@tis.com;;;
cc: ipsec@tis.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-isakmp-07.txt, .ps
Date: Mon, 24 Feb 1997 09:51:32 -0500
Message-ID: <9702240951.aa13026@ietf.org>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : Internet Security Association and Key Management
Protocol (ISAKMP)
Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner
Filename : draft-ietf-ipsec-isakmp-07.txt, .ps
Pages : 79
Date : 02/20/1997
This memo describes a protocol utilizing security concepts necessary for
establishing Security Associations (SA) and cryptographic keys in an
Internet environment. A Security Association protocol that negotiates,
establishes, modifies and deletes Security Associations and their
attributes is required for an evolving Internet, where there will be
numerous security mechanisms and several options for each security
mechanism. The key management protocol must be robust in order to handle
public key generation for the Internet community at large and private key
requirements for those private networks with that requirement.
The Internet Security Association and Key Management Protocol (ISAKMP)
defines the procedures for authenticating a communicating peer, creation and
management of Security Associations, key generation techniques, and threat
mitigation (e.g. denial of service and replay attacks). All of these are
necessary to establish and maintain secure communications (via IP Security
Service or any other security protocol) in an Internet environment.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-isakmp-07.txt".
Or
"get draft-ietf-ipsec-isakmp-07.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-isakmp-07.txt".
Or
"FILE /internet-drafts/draft-ietf-ipsec-isakmp-07.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19970221180031.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-isakmp-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-isakmp-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970221180031.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec Tue Feb 25 09:17:44 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA09470 for ipsec-outgoing; Tue, 25 Feb 1997 09:10:59 -0500 (EST)
Message-Id: <01BC22FC.791D5640@erussell-2.ftp.com>
From: "Edward A. Russell" <erussell@ftp.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>
Subject: V7 - Clarification of Alignment
Date: Tue, 25 Feb 1997 09:15:40 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Section 3 of the ISAKMP Version 7 draft states:
Additionally all ISAKMP payloads MUST be aligned at 4-byte multiples
Is this alignment reflected in the payload length?
If it is, then it is a small amount of work on the sender but V6/V7 interoperablity is assured.
If it is not, then it is slightly trickier/painful for the receiver, and V6/V7 interoperability is lost.
Edward Russell
erussell@ftp.com
From owner-ipsec Wed Feb 26 09:45:12 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17461 for ipsec-outgoing; Wed, 26 Feb 1997 09:31:19 -0500 (EST)
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
cc: ipsec@tis.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-03.txt
Date: Wed, 26 Feb 1997 09:18:45 -0500
Message-ID: <9702260918.aa14331@ietf.org>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
--NextPart
Note: This revision includes changes as a result of WG Last Call
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : The resolution of ISAKMP with Oakley
Author(s) : D. Harkins, D. Carrel
Filename : draft-ietf-ipsec-isakmp-oakley-03.txt
Pages : 32
Date : 02/25/1997
[MSST96] (ISAKMP) provides a framework for authentication and key exchange
but does not define them. ISAKMP is designed to be key exchange
independant; that is, it is designed to support many different key
exchanges.
[Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and
details the services provided by each (e.g. perfect forward secrecy for
keys, identity protection, and authentication).
This document describes a proposal for using the Oakley Key Exchange
Protocol in conjunction with ISAKMP to obtain authenticated keying
material for use with ISAKMP, and for other security associations
such as AH and ESP for the IETF IPsec DOI.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-isakmp-oakley-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19970225104523.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-isakmp-oakley-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970225104523.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec Wed Feb 26 19:12:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21066 for ipsec-outgoing; Wed, 26 Feb 1997 19:05:14 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007814af3a7e0b8e75@[128.89.0.110]>
In-Reply-To:
<c=US%a=_%p=msft%l=RED-74-MSG-970222011832Z-4004@INET-05-IMC.microsoft.com
>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 26 Feb 1997 18:57:41 -0500
To: S"'ipsec@tis.com'" <ipsec@tis.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Path MTU Discovery
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Folks,
The working with me on the AH, ESP, and IPSEC Architecture
documentshave been meeting this week to work on PMTU issues. We will have
an analysis of the issues available soon, addressing the questions raised
on the list over the last few weeks, and providing some rationales for
preferred approaches to dealing with this potentially tricky problem in
both hosts and gateways. Stay tuned.
Steve
From owner-ipsec Thu Feb 27 20:59:57 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA01940 for ipsec-outgoing; Thu, 27 Feb 1997 20:53:07 -0500 (EST)
Date: Thu, 27 Feb 1997 17:57:20 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199702280157.RAA14365@servo.qualcomm.com>
To: dharkins@cisco.com
CC: rmonsour@earthlink.net, ipsec@tis.com
In-reply-to: <199702180230.SAA21924@dharkins-ss20.cisco.com> (message from Daniel Harkins on Mon, 17 Feb 1997 18:30:12 -0800)
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>I support the use of compression but not in IPsec. It should be done up
>higher, perhaps the transport level. It's better to compress the stream
>of data before it's divided into packets than to wait and compress each
>packet. I'd rather see 50 packets then 100 smaller ones.
I feel exactly the same way. I've seen nothing that can beat the
performance of gzip-style compress up above TCP, e.g., in SSH with the
-C option. The fact that gzip is widely distributed GNUware, free of
patent concerns, is just icing on the cake.
Phil
From owner-ipsec Thu Feb 27 23:33:39 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA03048 for ipsec-outgoing; Thu, 27 Feb 1997 23:31:35 -0500 (EST)
Date: Thu, 27 Feb 1997 20:35:29 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199702280435.UAA14767@servo.qualcomm.com>
To: rmonsour@earthlink.net
CC: karl@ascend.com, rmonsour@earthlink.net, dpalma@netcom.com,
carrel@ipsec.org, caronni@tik.ee.ethz.ch, dharkins@cisco.com,
ipsec@tis.com
In-reply-to: <3.0.32.19970218210258.00947440@earthlink.net> (message from Bob Monsour on Tue, 18 Feb 1997 21:03:06 -0800)
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>After reading my response, I think we're in violent agreement (I was just
>being needlessly unclear). I agree that using VJ header compression *does*
>provide a net benefit, both in conjunction with a payload compression
I point out that VJ TCP/IP header compression assumes in-order
delivery of the compressed packets. This is true over a point-to-point
link, but it is not necessarily true over the Internet as a whole. So
unless you're proposing that the IPSEC reorder packets, VJ header
compression is not an option there.
Phil
From owner-ipsec Fri Feb 28 00:03:11 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA03278 for ipsec-outgoing; Fri, 28 Feb 1997 00:01:31 -0500 (EST)
Date: Thu, 27 Feb 1997 21:05:42 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199702280505.VAA14844@servo.qualcomm.com>
To: rmonsour@earthlink.net
CC: chk@utcc.utoronto.ca, rmonsour@earthlink.net, ipsec@tis.com
In-reply-to: <3.0.32.19970218213122.00923b40@earthlink.net> (message from Bob Monsour on Tue, 18 Feb 1997 21:31:24 -0800)
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> The test file was the University of Calgary Text Compression Corpus
> [Calgary]. The length of the file prior to compression was 3,278,000
> bytes. When the entire file was compressed as a single payload, a
> compression ratio of 2.34 resulted.
>
> Datagram size,| 64 128 256 512 1024 2048 4096 8192 16384
> bytes |
> --------------|----------------------------------------------------
> Compression |1.18 1.28 1.43 1.58 1.74 1.91 2.04 2.11 2.14
> ratio |
>
> [Calgary] Text Compression Corpus, University of Calgary, available at
> ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus
I dug up this file, specifically the archive
text.compression.corpus.tar.Z
and tried a few quick experiments. As compressed with "compress" the
ratio was 2.4:1. When I decompressed the file and recompressed it
with gzip, the ratio improved to 3.05:1. Using the strongest (most
CPU intensive) gzip level, 9, the ratio improved slightly more to
3.077:1. By default, the ssh compression option uses gzip level 6.
Interesting that a university group interested in compression wouldn't
use the most popular and effective compression algorithm to distribute
their work! :-)
I think this discussion shows that compression at the packet layer is
better than nothing, but the best performance is attained by using a
really good stream compression algorithm above the transport layer.
Phil
From owner-ipsec Fri Feb 28 00:42:11 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA03521 for ipsec-outgoing; Fri, 28 Feb 1997 00:40:03 -0500 (EST)
Date: Thu, 27 Feb 1997 21:44:29 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199702280544.VAA15002@servo.qualcomm.com>
To: perry@piermont.com
CC: rmonsour@earthlink.net, ipsec@tis.com
In-reply-to: <199702191422.JAA02189@jekyll.piermont.com> (perry@piermont.com)
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
>consumers -- want to conduct transactions over it. With a reasonable
>IPSec in place, SSL wouldn't have been necessary. SSL is used every
I used to say this too, but not any more. I now believe it's desirable
to have multiple, complementary architectural approaches to
security. SSL represents a transport layer approach while IPSEC
represents the network layer approach. Each has its advantages and
disadvantages, and I suspect that each will find their niches.
Advantages of transport layer security (e.g., SSL, SSH):
1. Can operate on an end-to-end basis with existing TCP/IP stacks with
existing APIs (winsock, BSD sockets, streams, etc). This is a VERY
important issue with turnkey object-only systems like Windows 95.
2. More efficient over slow speed links. VJ header compression still
works, and various congestion-control schemes that peek at TCP/IP
headers (e.g., my TCP ack-dropping scheme) still work.
3. No special problems with fragmentation, path MTU discovery, etc.
4. Compression combined with encryption at this layer is much more
effective than compression at the packet layer.
Advantages of network layer security (e.g., IPSEC)
1. Can support completely unmodified end systems, though in this case
encryption is no longer strictly end-to-end.
2. Particularly suitable for building virtual private networks across
untrusted networks.
3. Can support transport protocols other than TCP (e.g., UDP).
4. Hides the transport layer headers from eavesdropping, providing
somewhat greater protection against traffic analysis.
5. With AH and replay detection, protects against certain
denial-of-service attacks based on swamping (e.g., TCP SYN attacks).
I think it likely that IPSEC will find its niche in building virtual
private networks, while SSL and SSH (though they may merge) will
continue to be used for many end-to-end applications such as web
commerce, remote login, file transfer, etc.
Phil
From owner-ipsec Fri Feb 28 00:44:25 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA03568 for ipsec-outgoing; Fri, 28 Feb 1997 00:43:03 -0500 (EST)
Message-Id: <3.0.32.19970227214259.0095cce0@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 27 Feb 1997 21:43:04 -0800
To: Phil Karn <karn@qualcomm.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: rmonsour@earthlink.net, karl@ascend.com, rmonsour@earthlink.net,
dpalma@netcom.com, carrel@ipsec.org, caronni@tik.ee.ethz.ch,
dharkins@cisco.com, ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At 08:35 PM 2/27/97 -0800, Phil Karn wrote:
>>After reading my response, I think we're in violent agreement (I was just
>>being needlessly unclear). I agree that using VJ header compression *does*
>>provide a net benefit, both in conjunction with a payload compression
>
>I point out that VJ TCP/IP header compression assumes in-order
>delivery of the compressed packets. This is true over a point-to-point
>link, but it is not necessarily true over the Internet as a whole. So
>unless you're proposing that the IPSEC reorder packets, VJ header
>compression is not an option there.
Agreed. In fact there is a draft titled "Header Compression for IPv6" which
is specifically to do VJ header compression over point-to-point links. FYI,
it is at ftp://ds.internic.net/internet-drafts/draft-degermark-ipv6-hc-02.txt.
-Bob
From owner-ipsec Fri Feb 28 01:02:01 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id BAA03685 for ipsec-outgoing; Fri, 28 Feb 1997 01:00:35 -0500 (EST)
Message-Id: <199702280605.AAA03433@ebony.arl.wustl.edu>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 4.0 v146.2)
X-Image-URL: http://www.tik.ee.ethz.ch/~mwa/mwa.mail.tiff
In-Reply-To: <199702280157.RAA14365@servo.qualcomm.com>
X-Nextstep-Mailer: Mail 4.0 (Enhance 2.0b5)
From: Marcel Waldvogel <mwa@ebony.ccrc.wustl.edu>
Date: Fri, 28 Feb 97 00:04:50 -0600
To: Phil Karn <karn@qualcomm.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
cc: dharkins@cisco.com, rmonsour@earthlink.net, ipsec@tis.com
References: <199702280157.RAA14365@servo.qualcomm.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 27 Feb 1997, Phil Karn wrote:
> >I support the use of compression but not in IPsec. It should be done up
> >higher, perhaps the transport level. It's better to compress the stream
> >of data before it's divided into packets than to wait and compress each
> >packet. I'd rather see 50 packets then 100 smaller ones.
>
> I feel exactly the same way. I've seen nothing that can beat the
> performance of gzip-style compress up above TCP, e.g., in SSH with the
> -C option. The fact that gzip is widely distributed GNUware, free of
> patent concerns, is just icing on the cake.
Phil, Daniel,
undoubtedly, knowledge about the data to be compressed, be it format
or the fact that it will be received reliably e.g. over TCP, can
result in impressive improvements.
On the other hand, the goal we're all working for --wide deployment
of IPsec-- will render most currently employed Link Layer compression
schemes useless. Yet many Intranets and dial-up users rely on these
resulting bandwidth improvements, making IPsec deployment very hard
or impossible in many places.
Application Layer compression provides a viable solution. But it
requires all applications to be rewritten to maintain the throughput
as currently achieved using LL compression, so only applications
made "IPsec-aware" using AL compression will perform well.
IPsec network performance and thus acceptance will be much better
if we start off with provisions for NL compression, which can be
disabled on a per connection/per SA basis when applications start
doing their own AL compression or know they're transmitting
incompressible data.
By providing NL compression, no additional burden is placed on the
software developers, because many applications will want to become
IPsec-aware (specifying their security requirements). For other
applications that do not need full IPsec-awareness, but are just
adding AL compression, the changes needed to tell IPsec to disable
NL compression will be minimal.
So I think NL compression will vital to IPsec. Of course, it should
be configurable on a per-machine/per-connection basis by the
sysadmin/application, like all other IPsec parameters. The effort
of adding it once at the NL will be much less than adding compression
to all applications.
- -Marcel
-----BEGIN PGP SIGNATURE-----
Version: 2.6
Charset: next
iQCVAwUBMxZ1h8qBByDTF1SlAQFbFQQAiU9OmEnnD9maOr37ErBgjmcmPcP/HvnA
0KKgoZg7Dh8rsBrS9I3HrAQ8Hl5OqOUiSaM5+Zgyj/mILJrYW7MuqYic4aiBZf84
Jk9kLTsnUl2K2lgL791+4Gg9MH7tWfpX4nngjffBuFdaNvabnVQdSYdiR98Dv8HN
0AJdekCOXDk=
=kdEM
-----END PGP SIGNATURE-----
From owner-ipsec Fri Feb 28 13:16:09 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA09051 for ipsec-outgoing; Fri, 28 Feb 1997 13:10:49 -0500 (EST)
Date: Fri, 28 Feb 97 13:15:23 EST
From: "Arthur Parkos" <parkosar@pb.com>
Message-Id: <9701288571.AA857165346@smtppc.ct.pb.com>
To: ipsec@tis.com
Subject: transport vs network and ipsec syn
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Subject: Re[2]: TO COMPRESS OR NOT TO CMPRS (please reply)
Author: Arthur Parkos at renpo
Date: 2/28/97 12:13 PM
i agree with your transport vs network security comments. i also agree that we
will see both forms of implementation for the particular situations that fit
them best.
one question (multipart), i was not sure how ipsec addresses the syn attack:
- it's not guaranteed that all connections will be attempted with ipsec
authentication instantiated. therefore a host will still need to respond to the
request for a connection. or will a host refuse all connect attempts from
non-ipsec host.
- if ipsec is implemented, the host will still need to perform an authentication
on the potential partner which would eat cpu cycles.
- if ipsec is there, the host receives the connect attempt and retrieves the
address, so what if it was signed. couldn't a bad entity sign fake ip addresses
and then send them on to a potential host to be attacked?
- when will the infrastructure be in place so that a host can authenticate a
connection attempt from the myriad potential connectees where certificates may
have been issued by different certificate authorities
______________________________ Reply Separator _________________________________
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Author: Phil Karn <karn@qualcomm.com> at SMTPGWY
Date: 2/28/97 2:36 AM
>consumers -- want to conduct transactions over it. With a reasonable
>IPSec in place, SSL wouldn't have been necessary. SSL is used every
I used to say this too, but not any more. I now believe it's desirable
to have multiple, complementary architectural approaches to
security. SSL represents a transport layer approach while IPSEC
represents the network layer approach. Each has its advantages and
disadvantages, and I suspect that each will find their niches.
Advantages of transport layer security (e.g., SSL, SSH):
1. Can operate on an end-to-end basis with existing TCP/IP stacks with
existing APIs (winsock, BSD sockets, streams, etc). This is a VERY
important issue with turnkey object-only systems like Windows 95.
2. More efficient over slow speed links. VJ header compression still
works, and various congestion-control schemes that peek at TCP/IP
headers (e.g., my TCP ack-dropping scheme) still work.
3. No special problems with fragmentation, path MTU discovery, etc.
4. Compression combined with encryption at this layer is much more
effective than compression at the packet layer.
Advantages of network layer security (e.g., IPSEC)
1. Can support completely unmodified end systems, though in this case
encryption is no longer strictly end-to-end.
2. Particularly suitable for building virtual private networks across
untrusted networks.
3. Can support transport protocols other than TCP (e.g., UDP).
4. Hides the transport layer headers from eavesdropping, providing
somewhat greater protection against traffic analysis.
5. With AH and replay detection, protects against certain
denial-of-service attacks based on swamping (e.g., TCP SYN attacks).
I think it likely that IPSEC will find its niche in building virtual
private networks, while SSL and SSH (though they may merge) will
continue to be used for many end-to-end applications such as web
commerce, remote login, file transfer, etc.
Phil
From owner-ipsec Fri Feb 28 17:10:29 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10855 for ipsec-outgoing; Fri, 28 Feb 1997 17:06:08 -0500 (EST)
From: Dan.McDonald@Eng.sun.com (Dan McDonald)
Message-Id: <199702282210.OAA07972@kebe.eng.sun.com>
Subject: Re: transport vs network and ipsec syn
To: parkosar@pb.com (Arthur Parkos)
Date: Fri, 28 Feb 1997 14:10:34 -0800 (PST)
Cc: ipsec@tis.com
In-Reply-To: <9701288571.AA857165346@smtppc.ct.pb.com> from "Arthur Parkos" at Feb 28, 97 01:15:23 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> one question (multipart), i was not sure how ipsec addresses the syn attack:
Phil's right in that AH with replay protection, when it's turned on, will
stop SYN attacks dead.
And even without replay protection, you have assurances that only the SYN for
the particular connection id will be flooded if some miscreant replays a
particular SYN.
> - it's not guaranteed that all connections will be attempted with ipsec
> authentication instantiated. therefore a host will still need to respond to
> the request for a connection. or will a host refuse all connect attempts
> from non-ipsec host.
You are right. What you aren't clear on is that I _can_ be selective on
which listening endpoints I have IPsec turned on. An example I see my
customers using is:
* Port 80/TCP (WWW) has no IPsec on it
* Maybe port 20-21/TCP (FTP) has no IPsec on it
* All other ports (telnet, etc.) have a minimum requirement of
AH with replay protection.
And anyone who tells you you can't implement per-endpoint IPsec policy is on
drugs. I suggest you read the NRL IPsec code for a working counterexample.
> - if ipsec is implemented, the host will still need to perform an
> authentication on the potential partner which would eat cpu cycles.
Yes, but memory isn't being slopped.
BTW, in my forthcoming Simple IPsec API draft, I detail a potential
denial-of-service attack that is similar to what is described above. There
is a fix, BTW.
> - if ipsec is there, the host receives the connect attempt and retrieves
> the address, so what if it was signed. couldn't a bad entity sign fake ip
> addresses and then send them on to a potential host to be attacked?
In that case you're problems are probably a lot worse than a simple
denial-of-service attack.
> - when will the infrastructure be in place so that a host can authenticate
> a connection attempt from the myriad potential connectees where
> certificates may have been issued by different certificate authorities
Good question. That's partially a key mgmt. question too, as the ISAKMP,
Photuris, etc. have to decide if the certificate used for the key exchange is
trustworthy.
Thanks for the questions, I hope I answered them.
--
Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S!
Phone: (415) 786-6815 |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush
From owner-ipsec Fri Feb 28 18:32:33 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11367 for ipsec-outgoing; Fri, 28 Feb 1997 18:30:32 -0500 (EST)
X-Sender: kent@po1.bbn.com
Message-Id: <v03007800af3c9ddf5ce9@[128.89.0.110]>
In-Reply-To: <199702280544.VAA15002@servo.qualcomm.com>
References: <199702191422.JAA02189@jekyll.piermont.com>
(perry@piermont.com)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Feb 1997 18:35:51 -0500
To: Phil Karn <karn@qualcomm.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Cc: perry@piermont.com, rmonsour@earthlink.net, ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Phil,
Just a minor correction: let's not refer to SSL or SSH as
"transport layer" security protocols. These protocols operate above the
transport layer. I'd call SSL a session layer security protocol, if I had
to attach a label. TLSP is an example of a transport layer security
protocol, i.e., it is integrated into the transport layer, not layered on
top. Also, one additional downside of session layer security protocols is
the possible dependence on the ordering provided by the transport layer
protocol. In the case of SSL, this means that an attack on TCP can quickly
kill the SSL session, requiring a new SSL session to be created, while TCP
thinks that everything is just fine...
Steve
From owner-ipsec Fri Feb 28 18:57:15 1997
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA11536 for ipsec-outgoing; Fri, 28 Feb 1997 18:55:37 -0500 (EST)
Message-Id: <199703010000.TAA12788@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: Stephen Kent <kent@bbn.com>
cc: ipsec@tis.com
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
In-reply-to: Your message of "Fri, 28 Feb 1997 18:35:51 EST."
<v03007800af3c9ddf5ce9@[128.89.0.110]>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 28 Feb 1997 18:59:59 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Stephen Kent writes:
> Just a minor correction: let's not refer to SSL or SSH as
> "transport layer" security protocols. These protocols operate above the
> transport layer.
Indeed -- thank you for pointing this out. The misdesignation has
occassionally grated when I've heard it.
Perry