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 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" To: 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" 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" , From: Robert Moskowitz 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 To: "'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 , "'ipsec@tis.com'" From: Robert Moskowitz 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 , "'ipsec@tis.com'" From: Michael Sabin 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 cc: "'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" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: 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 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 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 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: 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 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 , "'ipsec@tis.com'" >From: Michael Sabin >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 +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 , ipsec@tis.com From: Robert Moskowitz 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 To: "'chk@border.com'" , "'Edward Russell'" Cc: "'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 To: "'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: > > > >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: X-Mailer: Novell GroupWise 4.1 Date: Thu, 06 Feb 1997 14:13:27 -0700 From: John Kennedy 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" 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 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: 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" 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 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 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: From: Greg Carter To: "'chk%border.com'" , "'erussell@ftp.com'" Cc: "'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 cc: "'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" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: 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 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: X-Mailer: Novell GroupWise 4.1 Date: Thu, 06 Feb 1997 15:22:40 -0700 From: John Kennedy 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 02/06/97 01:44pm >>> >In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: > > > >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 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: > > > >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: From: Michael Sabin 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 >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 >> 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" 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" 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 > > > >>> 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 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: 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 From: Rodney Thayer 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 02/06/97 01:44pm >>> >>In message <01BC1429.F844BBC0@localhost>, Edward Russell writes: >> >> >> >>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 >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: >> >> >> >>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 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" 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 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 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 -=-=-=-=-=-=- 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 Subject: Re: Path MTU Discovery To: "Angelos D. Keromytis" , Dan McDonald 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: 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 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. > 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 :: 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 Cc: John Kennedy , 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 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: 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 From: Stephen Kent 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 Subject: Re: Replay field size in AH To: Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: 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 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: 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 From: Rodney Thayer 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 +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: From: Roy Pereira To: "'ipsec@tis.com'" , "'Derrell Piper'" 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 Subject: RE: replay field size To: "'ipsec@tis.com'" Cc: rja@inet.org X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: 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 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 Subject: Re: Replay field size in AH To: ipsec@tis.com Cc: rja@inet.org, Rodney Thayer 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: 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 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: From: Roy Pereira To: "'ipsec@tis.com'" , "'Ran Atkinson'" 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: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Feb 1997 23:36:18 -0500 To: Roy Pereira From: Stephen Kent 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: 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 From: Stephen Kent 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" 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 :: 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 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? > > > 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 :: 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 From: Matt Thomas 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 To: Ben Rogers cc: Dan McDonald , "Angelos D. Keromytis" , ipsec@tis.com Subject: Re: Path MTU Discovery In-Reply-To: <199702081237.HAA24954@carp.morningstar.com> Message-ID: 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) 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 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 Subject: Re: Path MTU Discovery To: Ben Rogers , Dan McDonald Cc: "Angelos D. Keromytis" , 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: 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 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: 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 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 . 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 and Paul Lambert 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 Subject: Re: Path MTU Discovery To: "Angelos D. Keromytis" , Ran Atkinson Cc: Ben Rogers , Dan McDonald , 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: 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" 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 Cc: Ben Rogers , Dan McDonald , ipsec@tis.com Subject: Re: Path MTU Discovery From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message , 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 X-Sender: fit106@commsun To: ipsec@tis.com Subject: ANX IPSEC bakeoff Message-ID: 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 , ipsec@tis.com From: Robert Moskowitz 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: From: Roy Pereira To: "'ipsec@tis.com'" , "'Ran Atkinson'" 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: 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 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 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 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 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" 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" Message-Id: <9701118557.AA855712066@netx.nei.com> To: ben@ascend.com, Dan.McDonald@Eng.sun.com, Ran Atkinson 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 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" To: 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 > 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 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 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" 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 > > > 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" To: "Niels Ferguson" Cc: 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" 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 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" 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: From: John Keating To: "'ipsec@tis.com'" Cc: "'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" To: "Theodore Y. Ts'o" Cc: 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 > 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: X-Mailer: Novell GroupWise 4.1 Date: Wed, 12 Feb 1997 10:04:46 -0800 From: CJ Lee 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" Cc: "Theodore Y. Ts'o" , 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 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" To: "Niels Ferguson" Cc: "Theodore Y. Ts'o" , 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" 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 From: Naganand Doraswamy 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 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 -=-=-=-=-=-=- 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" To: 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." Date: Wed, 12 Feb 1997 14:18:07 -0800 From: Derrell Piper 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 From: Bob Monsour 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 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 Subject: Re: replay field size To: Derrell Piper , 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: 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: 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 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: 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" From: Stephen Kent 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: In-Reply-To: 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 From: Stephen Kent 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: 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 From: Stephen Kent 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: 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" From: Stephen Kent Subject: Re: replay field size Cc: 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 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" 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: From: Roy Pereira To: "'Dan.McDonald@Eng.sun.com'" , "'Daniel Harkins'" Cc: "'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 , Robert Glenn 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 Subject: Re: replay field size To: Robert Glenn , Stephen Kent Cc: ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: 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" 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 cc: Robert Glenn , Stephen Kent , ipsec@tis.com Subject: Re: replay field size Date: Thu, 13 Feb 1997 11:37:39 -0500 From: Steven Bellovin 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" 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 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 , "'ipsec@tis.com'" From: wei@tis.com Subject: Re: replay field size Cc: "'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 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" 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" To: "C. Harald Koch" 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" 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 Cc: "'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 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: From: Greg Carter To: "'ipsec@tis.com'" Cc: "'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: 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 From: Rodney Thayer 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 +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: 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 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 Subject: Re: replay field size To: Ran Atkinson , Steven Bellovin Cc: ipsec@tis.com, Robert Glenn , Stephen Kent 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: 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 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: (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 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 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 Cc: "'ipsec@tis.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." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Feb 1997 12:31:15 -0800 From: Daniel Harkins 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 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: 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 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 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 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 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: Lines: 33 X-Mailer: Gnus v5.2.37/Emacs 19.30 Sender: owner-ipsec@ex.tis.com Precedence: bulk Steven Bellovin 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" To: Derek Atkins Cc: HUGO@watson.ibm.com, IPSEC@tis.com In-Reply-To: Derek Atkins's message of 14 Feb 1997 15:35:11 -0500, 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 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 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 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 To: IPSEC@tis.com Cc: Bart Preneel Subject: Re: 32 bit counter -- 96 bit HMAC-SHA/MD5 In-Reply-To: <199702142153.QAA03394@raptor.research.att.com> Message-Id: 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 > 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" > To: Derek Atkins > 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 To: Steven Bellovin Cc: Ran Atkinson , Robert Glenn , Stephen Kent , ipsec@tis.com Subject: Re: replay field size In-Reply-To: <199702131637.LAA02391@raptor.research.att.com> Message-Id: 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 > To: Ran Atkinson > Cc: Robert Glenn , Stephen Kent , > 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 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 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 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 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 Date: Mon, 17 Feb 97 20:26:46 -0600 To: Bob Monsour 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: 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 From: Rodney Thayer 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 +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 , dharkins@cisco.com (Daniel Harkins) From: Derek Palma 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 , ipsec@tis.com From: Matt Thomas 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 cc: Germano Caronni , 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 From: Matt Thomas 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 From: Derek Palma Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Germano Caronni , 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 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 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 To: Derek Palma Cc: carrel@ipsec.org, Germano Caronni , 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 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 From: Naganand Doraswamy 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: From: Roy Pereira To: "'ipsec@tis.com'" , "'Bob Monsour'" 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 , 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 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" To: "Karl Fox" , "Derek Palma" Cc: , "Germano Caronni" , "Daniel Harkins" , 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 > 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" To: "Derek Palma" , Cc: "Germano Caronni" , "Daniel Harkins" , 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 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" Phone: +1 416 813 2054 X-uri: 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 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 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" Phone: +1 416 813 2054 X-uri: 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 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" cc: Bob Monsour , 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 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 To: "C. Harald Koch" Cc: Bob Monsour , 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 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 To: "Bob Monsour" Cc: "Derek Palma" , , "Germano Caronni" , "Daniel Harkins" , 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 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" 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: 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" From: Scott Marcus Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: "'Bob Monsour'" , "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" From: Matt Thomas 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 Cc: "'Bob Monsour'" , "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." Date: Tue, 18 Feb 1997 22:34:55 +0000 From: "Angelos D. Keromytis" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In message , 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 Date: Tue, 18 Feb 97 19:49:21 -0800 To: Bob Monsour 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: 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 From: Stephen Kent 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 From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: "Bob Monsour" , "Derek Palma" , , "Germano Caronni" , "Daniel Harkins" , 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" From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Germano Caronni , 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 From: Bob Monsour Subject: RE: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: "'ipsec@tis.com'" , "'Bob Monsour'" 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" From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Bob Monsour , 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 From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: "C. Harald Koch" , Bob Monsour , 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 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 From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Bob Monsour , 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 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" 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 Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Bob Monsour , 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 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" Phone: +1 416 813 2054 X-uri: 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 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: From: Roy Pereira To: "'Bob Monsour'" Cc: "'dharkins@cisco.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 cc: "'Bob Monsour'" , "'dharkins@cisco.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." 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" 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 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 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 From: "John W. Richardson" 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 Cc: "'Bob Monsour'" , "'dharkins@cisco.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. Date: Wed, 19 Feb 1997 13:05:17 -0500 From: Bill Sommerfeld 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 Cc: Steven Bellovin , "C. Harald Koch" , 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 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 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" X-uri: 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 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" 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 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 From: Bob Monsour Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Cc: Bob Monsour , 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 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" Cc: Bill Sommerfeld , 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" 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 Date: Wed, 19 Feb 97 12:38:52 -0800 To: EKR Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) cc: Bob Monsour , 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 , 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" 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 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 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 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 Subject: IPsec Straw Poll results To: IPsec WG X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: 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 , 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 Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Dennis" == Dennis Glatting 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 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'" , "'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" To: "'owner-ipsec@ex.tis.com'" , "'niels@DigiCash.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: 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 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 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" > 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" > 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" > 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 >> 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 > 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 > 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" > 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 > 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 > 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 > 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: 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 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: 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 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: 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 From: Stephen Kent 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 Date: Fri, 21 Feb 97 17:20:27 -0800 To: Stephen Kent 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> 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 X-Sender: fit106@commsun Reply-To: Kent Fitch To: ipsec@tis.com Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply) Message-ID: 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: From: Sanjay Anand To: "'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 > > > >>> 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" To: "'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: In-Reply-To: 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'" From: Stephen Kent 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 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 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 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 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 From: Bob Monsour 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 Date: Fri, 28 Feb 97 00:04:50 -0600 To: Phil Karn 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" 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 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: 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 From: Stephen Kent 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 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." 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" 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