RE: Reasons for AH & ESP

From owner-ipsec@lists.tislabs.com Thu Jun 1 07:14:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26823; Thu, 1 Jun 2000 07:14:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02196 Thu, 1 Jun 2000 08:34:06 -0400 (EDT) Message-ID: From: Paul Lambert To: ipsec@lists.tislabs.com Cc: KokMing Subject: RE: Reasons for AH & ESP Date: Tue, 30 May 2000 22:17:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFCABF.96089F58" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFCABF.96089F58 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCABF.96089F58" ------_=_NextPart_001_01BFCABF.96089F58 Content-Type: text/plain >>At 11:39 AM 5/28/2000 +1000, KokMing wrote: >>Does anyone know, or is able to explain the reasons for AH & ESP? >>As Neil Ferguson and Bruce Schneier wrote in 'Cryptographic Evaluation of >>IPsec', I too, find no reasons for two protocols in the RFCs. > >Part of it is Historical: > >1) Review RFCs 1825 - 1829. Then ESP did not do packet >authentication. For privacy and authentication, yoiu needed both AH + ESP. No ... not exactly. Going back even further in history there was no AH. The IPsec working group was originally chartered and started the definition of a single encapsulation protocol. The flurry of IPv6 activity at the same time introduced requirements and proposals for the AH protocol. The requirements for AH are solely for the support of IPv6. IPv4 does not need AH. IMHO AH should never be used with IPv4. It adds extra complexity, protocol overhead, processing delays and general system design confusion. For IPv4, the AH protocol adds no tangible security benefits. Paul Paul A. Lambert Director of Security Applications CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065 PGP: E9A4 022D FB0E 7352 17E5 7D46 C0CF 6BF5 DE64 621E ------_=_NextPart_001_01BFCABF.96089F58 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Reasons for AH & ESP

>>At 11:39 AM 5/28/2000 +1000, KokMing = wrote:
>>Does anyone know, or is able to explain the = reasons for AH & ESP?
>>As Neil Ferguson and Bruce Schneier wrote in = 'Cryptographic Evaluation of
>>IPsec', I too, find no reasons for two = protocols in the RFCs.
>
>Part of it is Historical:
>
>1) Review RFCs = 1825 - 1829. Then ESP did not do packet
>authentication. For privacy and = authentication, yoiu needed both AH + ESP.

No ... not exactly. Going back even further in = history there was no AH. The IPsec working group was originally = chartered and started the definition of a single encapsulation = protocol. The flurry of IPv6 activity at the same time introduced = requirements and proposals for the AH protocol.

The requirements for AH are solely for the support of = IPv6. IPv4 does not need AH.

IMHO AH should never be used with IPv4. It adds = extra complexity, protocol overhead, processing delays and general = system design confusion. For IPv4, the AH protocol adds no tangible = security benefits.

Paul

Paul A. Lambert
Director of Security Applications
CoSine Communications
1200 Bridge Parkway
Redwood City, CA 94065

PGP: E9A4 022D FB0E 7352 17E5
= 7D46 C0CF 6BF5 DE64 621E

------_=_NextPart_001_01BFCABF.96089F58-- ------_=_NextPart_000_01BFCABF.96089F58 Content-Type: application/octet-stream; name="Paul A. Lambert (E-mail).vcf" Content-Disposition: attachment; filename="Paul A. Lambert (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Lambert;Paul;;;(E-mail) FN:Paul A. Lambert (E-mail) (E-mail) ORG:Cosine Communications TITLE:Director of Security TEL;WORK;VOICE:650-628-4837 TEL;CELL;VOICE:650-787-9141 ADR;WORK:;;1200 Bridge Parkway;Redwood City;CA;94065;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1200 Bridge Parkway=0D=0ARedwood City, CA 94065=0D=0AUSA EMAIL;PREF;INTERNET:PLambert@cosinecom.com REV:20000323T004623Z END:VCARD ------_=_NextPart_000_01BFCABF.96089F58-- From owner-ipsec@lists.tislabs.com Thu Jun 1 07:15:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26839; Thu, 1 Jun 2000 07:15:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02300 Thu, 1 Jun 2000 09:01:49 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Paul Lambert Cc: ipsec@lists.tislabs.com, KokMing Subject: Re: Reasons for AH & ESP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Jun 2000 09:09:50 -0400 Message-Id: <20000601130951.AD95E35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Pau l Lambert writes: > >IMHO AH should never be used with IPv4. It adds extra complexity, protocol >overhead, processing delays and general system design confusion. For IPv4, >the AH protocol adds no tangible security benefits. Some of us are far from convinced that AH adds any tangible security benefits to v6. In particular, I have yet to see an option header that benefits from the protection. Some people have cited the routing header, but of course the intermediate routers can't verify the protection, so you can't use it to assure a certain routing. And if you have cryptographic authentication of the real source address, there's no anti-spoof protection from a known-valid source route. To my way of thinking, AH is useful for exactly one thing, compared with null authentication-ESP: an outboard monitoring program can tell, in a reliable, context-independent fashion, that a packet is not encrypted, and that the next header can be examined and interpreted. The real answer to the original question, I suspect, is that we have both AH and null authentication-ESP for historical reasons. That is, it "just grew that way", with little architectural consensus. (How could there have been one? The ESP option wasn't even discussed until very late in the game.) Some of us have argued against AH for years -- I still have a note I sent in 1995 detailing its uselessness. But I see no consensus to re-open the question; I certainly don't intend to lead any charge to delete it from the spec as we move towards Draft Standard. (Admittedly, I have considered such an effort, but I don't think enough people or views have changed to make it worthwhile, and I'd rather not stir up pointless controversy.) --Steve Bellovin From owner-ipsec@lists.tislabs.com Fri Jun 2 04:51:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10106; Fri, 2 Jun 2000 04:51:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08198 Fri, 2 Jun 2000 06:34:32 -0400 (EDT) Message-Id: <200006021042.GAA27459@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-ecc-groups-02.txt Date: Fri, 02 Jun 2000 06:42:34 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New 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 : Additional ECC Groups For IKE Author(s) : P. Panjwani, Y. Poeluev Filename : draft-ietf-ipsec-ike-ecc-groups-02.txt Pages : 10 Date : 01-Jun-00 This document describes new ECC groups for use in IKE [IKE] in addition to the Oakley groups included therein. These groups are defined to align IKE with other ECC implementations and standards, and in addition, some of them provide higher strength than the Oakley groups. It should be noted that this document is not self-contained. It uses the notations and definitions of [IKE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-02.txt Internet-Drafts are also 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-ike-ecc-groups-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-ecc-groups-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <20000601103542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ecc-groups-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ecc-groups-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000601103542.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jun 2 06:22:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13269; Fri, 2 Jun 2000 06:22:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08471 Fri, 2 Jun 2000 08:22:34 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E3749E@eseis06nok> To: ipsec@lists.tislabs.com Subject: Commit Bit Date: Fri, 2 Jun 2000 15:30:34 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could someone give me an example of the usefulness of the Commit Bit in IKE? I've read the RFC 2408 explaining how it works but I can't understand completely its use. A small example would clarify me a lot how it works. Just need to know exactly when it's set and reset and when to send the CONNECT informational message. I understand the bit must be set when The ISAKMP SA is established and reset afetr the phase I as it says in the RFC, but I can't see exactly what do we win using it. I know the subject was discussed some time ago but I haven't been able to find a clear answer to my doubts. Thnaks and sorry for the inconvenience. Toni Barrera From owner-ipsec@lists.tislabs.com Fri Jun 2 07:20:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14038; Fri, 2 Jun 2000 07:20:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08613 Fri, 2 Jun 2000 09:14:50 -0400 (EDT) Message-ID: <3937B54F.CFBE028B@loria.fr> Date: Fri, 02 Jun 2000 15:23:27 +0200 From: Ghassan Chaddoud Organization: LORIA X-Mailer: Mozilla 4.72 [fr] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: IPsec Subject: Performance Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Could you please tell me if there is any available information about the performance of RSA, DES, ..., on different machines (PC, work stations, ...) Best Regards -- Ghassan CHADDOUD LORIA/INRIA-Lorraine, From owner-ipsec@lists.tislabs.com Fri Jun 2 08:18:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16686; Fri, 2 Jun 2000 08:18:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08744 Fri, 2 Jun 2000 10:04:43 -0400 (EDT) Message-ID: <03e801bfcc9c$bae7c860$cbd62ca1@cisco.com> From: "Stephane Beaulieu" To: , References: <0B3F42CA1FB6D2118FE50008C7894B0A02E3749E@eseis06nok> Subject: Re: Commit Bit Date: Fri, 2 Jun 2000 10:13:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Toni, The commit bit is used because the initiator of QM has an IPsec SA set up before the responder does. The initiator has the IPsec SA set up as soon as he sends QM3, whereas the responder doesn't have his IPsec SA set up until he processes QM3. If the responder is a slow machine, or is overloaded, it could take a while to process QM3, and therefore could take a while to set up the IPsec SA. If the initiator sends an ESP packet to the responder right after sending QM3, the responder may not be ready to process it (or it could arive out of order). So, the commit bit was introduced to give the responder a method of telling the intiator "OK, my SA is set up now", so that no packets were dropped due to the timing issues described above. Stephane. ----- Original Message ----- From: To: Sent: Friday, June 02, 2000 8:30 AM Subject: Commit Bit > Could someone give me an example of the usefulness of the Commit Bit > in IKE? > I've read the RFC 2408 explaining how it works but I can't understand > completely its use. > A small example would clarify me a lot how it works. Just need to know > exactly when it's set and reset and when to send the CONNECT informational > message. > I understand the bit must be set when The ISAKMP SA is established > and reset afetr the phase I as it says in the RFC, but I can't see exactly > what do we win using it. > I know the subject was discussed some time ago but I haven't been > able to find a clear answer to my doubts. > Thnaks and sorry for the inconvenience. > > Toni Barrera > > From owner-ipsec@lists.tislabs.com Fri Jun 2 08:43:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19061; Fri, 2 Jun 2000 08:43:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08845 Fri, 2 Jun 2000 10:32:51 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E374A6@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: Commit Bit Date: Fri, 2 Jun 2000 17:41:00 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks, now I understand much better What I find strange is that it says it can be used in both phases. But it doesn't make much sense for phase I in my opinion. In the case you describe I can really see a good use for this bit. So maybe I'll only use it for phase II unless someone gives me a good reason for phase I. Or I'm missing something else. Toni -----Original Message----- From: EXT Stephane Beaulieu [mailto:stephane@cisco.com] Sent: 02. June 2000 17:14 To: antonio.barrera@nokia.com; ipsec@lists.tislabs.com Subject: Re: Commit Bit Hi Toni, The commit bit is used because the initiator of QM has an IPsec SA set up before the responder does. The initiator has the IPsec SA set up as soon as he sends QM3, whereas the responder doesn't have his IPsec SA set up until he processes QM3. If the responder is a slow machine, or is overloaded, it could take a while to process QM3, and therefore could take a while to set up the IPsec SA. If the initiator sends an ESP packet to the responder right after sending QM3, the responder may not be ready to process it (or it could arive out of order). So, the commit bit was introduced to give the responder a method of telling the intiator "OK, my SA is set up now", so that no packets were dropped due to the timing issues described above. Stephane. ----- Original Message ----- From: To: Sent: Friday, June 02, 2000 8:30 AM Subject: Commit Bit > Could someone give me an example of the usefulness of the Commit Bit > in IKE? > I've read the RFC 2408 explaining how it works but I can't understand > completely its use. > A small example would clarify me a lot how it works. Just need to know > exactly when it's set and reset and when to send the CONNECT informational > message. > I understand the bit must be set when The ISAKMP SA is established > and reset afetr the phase I as it says in the RFC, but I can't see exactly > what do we win using it. > I know the subject was discussed some time ago but I haven't been > able to find a clear answer to my doubts. > Thnaks and sorry for the inconvenience. > > Toni Barrera > > From owner-ipsec@lists.tislabs.com Fri Jun 2 10:56:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22914; Fri, 2 Jun 2000 10:56:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09221 Fri, 2 Jun 2000 12:33:27 -0400 (EDT) Date: Fri, 2 Jun 2000 11:41:36 -0500 From: Will Fiveash To: ipsec@lists.tislabs.com Subject: Re: Commit Bit Message-ID: <20000602114136.A43088@austin.ibm.com> Mail-Followup-To: ipsec@lists.tislabs.com References: <0B3F42CA1FB6D2118FE50008C7894B0A02E374A6@eseis06nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A02E374A6@eseis06nok>; from antonio.barrera@nokia.com on Fri, Jun 02, 2000 at 05:41:00PM +0300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Jun 02, 2000 at 05:41:00PM +0300, antonio.barrera@nokia.com wrote: > What I find strange is that it says it can be used in both phases. But it > doesn't make much sense for phase I in my opinion. > In the case you describe I can really see a good use for this bit. > So maybe I'll only use it for phase II unless someone gives me a good reason > for phase I. Or I'm missing something else. I believe the general concensus is that it is useful only in phase II. IKE on AIX only uses the CB in phase II. -- Will Fiveash IBM AIX System Development (IPsec/IKE) From owner-ipsec@lists.tislabs.com Fri Jun 2 12:30:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24186; Fri, 2 Jun 2000 12:30:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09625 Fri, 2 Jun 2000 14:24:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20000602141843.045af6b0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 14:28:44 -0400 To: "Steven M. Bellovin" , Paul Lambert From: Robert Moskowitz Subject: Death to AH? (was: Reasons for AH & ESP ) Cc: ipsec@lists.tislabs.com, KokMing In-Reply-To: <20000601130951.AD95E35DC2@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:09 AM 6/1/2000 -0400, Steven M. Bellovin wrote: >Some of us have argued against AH for years -- >I still have a note I sent in 1995 detailing its uselessness. But I >see no consensus to re-open the question; I certainly don't intend to >lead any charge to delete it from the spec as we move towards Draft >Standard. (Admittedly, I have considered such an effort, but I don't >think enough people or views have changed to make it worthwhile, and >I'd rather not stir up pointless controversy.) I might think the first step toward that is to poll this diverse group to see if anyone is deploying AH and could not use ESP NULL instead. I am all for a rough concensus that will change the IPsec/IKE standards to list AH as a Historical protocol that should not be implemented anymore. I suspect that a number of vendors only have it in their product for the 'check box' syndrome. I would also be interested in a lively debate by IPv6 knowedgeable engineers that can couner Steve B's concerns on the real value of AH to v6. However, I might point out that some vendors have had their ICSA certification delayed while they hustled to add the NULL encryption to their ESP implementation. Like they never read our criteria before product submission. Speaking on NULL, it is also sad on the number of vendors that implemented it with a key length of ZERO. That is in IKE they explicitely specified the key length as ZERO. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Fri Jun 2 13:05:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24643; Fri, 2 Jun 2000 13:05:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09775 Fri, 2 Jun 2000 15:09:29 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE9744@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Robert Moskowitz'" Cc: ipsec@lists.tislabs.com Subject: RE: Death to AH? (was: Reasons for AH & ESP ) Date: Fri, 2 Jun 2000 12:17:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bob: We (Intel) support AH in both our NIC and our VPN products, but only for checkbox purposes. We advise our customers that ESP authentication is almost always the preferred mechanism, at least in our analysis of the tradeoffs. For the vast overwhelming majority of deployments, AH is needless cost to consumers of IPsec technology. AH should not be mandatory moving forward. Jesse Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 -----Original Message----- From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com] Sent: Friday, June 02, 2000 11:29 AM To: Steven M. Bellovin; Paul Lambert Cc: ipsec@lists.tislabs.com; KokMing Subject: Death to AH? (was: Reasons for AH & ESP ) At 09:09 AM 6/1/2000 -0400, Steven M. Bellovin wrote: >Some of us have argued against AH for years -- >I still have a note I sent in 1995 detailing its uselessness. But I >see no consensus to re-open the question; I certainly don't intend to >lead any charge to delete it from the spec as we move towards Draft >Standard. (Admittedly, I have considered such an effort, but I don't >think enough people or views have changed to make it worthwhile, and >I'd rather not stir up pointless controversy.) I might think the first step toward that is to poll this diverse group to see if anyone is deploying AH and could not use ESP NULL instead. I am all for a rough concensus that will change the IPsec/IKE standards to list AH as a Historical protocol that should not be implemented anymore. I suspect that a number of vendors only have it in their product for the 'check box' syndrome. I would also be interested in a lively debate by IPv6 knowedgeable engineers that can couner Steve B's concerns on the real value of AH to v6. However, I might point out that some vendors have had their ICSA certification delayed while they hustled to add the NULL encryption to their ESP implementation. Like they never read our criteria before product submission. Speaking on NULL, it is also sad on the number of vendors that implemented it with a key length of ZERO. That is in IKE they explicitely specified the key length as ZERO. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Fri Jun 2 13:05:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24662; Fri, 2 Jun 2000 13:05:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09754 Fri, 2 Jun 2000 15:04:37 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14648.1838.26880.207474@xedia.com> Date: Fri, 2 Jun 2000 15:12:46 -0400 (EDT) To: rgm-sec@htt-consult.com Cc: ipsec@lists.tislabs.com Subject: Re: Death to AH? (was: Reasons for AH & ESP ) References: <20000601130951.AD95E35DC2@smb.research.att.com> <4.3.2.7.2.20000602141843.045af6b0@homebase.htt-consult.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Robert" == Robert Moskowitz writes: Robert> At 09:09 AM 6/1/2000 -0400, Steven M. Bellovin wrote: >> Some of us have argued against AH for years -- I still have a note >> I sent in 1995 detailing its uselessness. But I see no consensus >> to re-open the question; I certainly don't intend to lead any >> charge to delete it from the spec as we move towards Draft >> Standard. (Admittedly, I have considered such an effort, but I >> don't think enough people or views have changed to make it >> worthwhile, and I'd rather not stir up pointless controversy.) Robert> I might think the first step toward that is to poll this Robert> diverse group to see if anyone is deploying AH and could not Robert> use ESP NULL instead. Ok, here's one data point. The Lucent (formerly Xedia) Access Point IPsec implementation uses ESP Null; it does not support AH. (One reason is the extreme pain encounted when doing AH with IPcomp using a hardware accelerator, btw.) Robert> I am all for a rough concensus that will change the IPsec/IKE Robert> standards to list AH as a Historical protocol that should not Robert> be implemented anymore. I know this was attempted about 2 years ago at a Chicago IETF meeting and failed there (on something vaguely resembling a tie vote). Perhaps in the light of more widespread implementation experience we can have a different outcome. Robert> I would also be interested in a lively debate by IPv6 Robert> knowedgeable engineers that can couner Steve B's concerns on Robert> the real value of AH to v6. I would too, because I share Steve B's doubts. It would be good if anyone who feels differently could specifically address the issues Steve raised. Robert> However, I might point out that some vendors have had their Robert> ICSA certification delayed while they hustled to add the NULL Robert> encryption to their ESP implementation. Fortunately it is easy, except for the somewhat confusing pad rules... Robert> .... Speaking on NULL, it Robert> is also sad on the number of vendors that implemented it with Robert> a key length of ZERO. That is in IKE they explicitely Robert> specified the key length as ZERO. Or rather, it is sad that IKE insists this is illegal. The "be strict on transmit, tolerant on receive" principle would say that for a cipher with a fixed length key you could either omit the length or include it, but if you include it, it has to be the single permitted value. paul From owner-ipsec@lists.tislabs.com Fri Jun 2 14:00:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25480; Fri, 2 Jun 2000 14:00:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09967 Fri, 2 Jun 2000 15:58:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20000602160158.045ac5b0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 16:05:43 -0400 To: "Derrell D. Piper" , Paul Koning From: Robert Moskowitz Subject: Re: Death to AH? (was: Reasons for AH & ESP ) Cc: ipsec@lists.tislabs.com In-Reply-To: <200006021959.MAA19564@gallium.network-alchemy.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:59 PM 6/2/2000 -0700, Derrell D. Piper wrote: >I fully support a IPSecond effort to clean up this and several other problems >in the overall architecture. We now have three years of implementation and >operational experience with IPSec and IKE and this is one of the things that >should be cleaned up. However, I still would not support this if this were >the sole reason we were to be contemplating opening up the RFC's... I will bow to the chair, but I seem to recall that pruning is something that can be done and still progress to draft. So though removing AH might seem to be rather major surgery ( :), it might be acceptable to the IESG. You mention several other problems. Perhaps you could start your own thread on them :)' Gee I don't liek the way IKE doesn't really define approaches for lifetimes for the ISAKMP SA. Results in interop challenges...... Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Fri Jun 2 14:34:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25879; Fri, 2 Jun 2000 14:34:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10132 Fri, 2 Jun 2000 16:42:24 -0400 (EDT) Message-Id: <200006022050.QAA17398@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Death to AH? (was: Reasons for AH & ESP ) In-Reply-To: Your message of "Fri, 02 Jun 2000 12:17:36 PDT." <392A357CE6FFD111AC3E00A0C99848B002FE9744@hdsmsx31.hd.intel.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 02 Jun 2000 16:50:30 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bob> From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com] Bob> I am all for a rough concensus that will change the IPsec/IKE standards to Bob> list AH as a Historical protocol that should not be implemented anymore. I concur that the value of AH is dubious at present. But the present consists of people deploying VPNs. I believe that the value of AH has yet to appear. The simplest value of it over ESP-NULL is that one knows that the packet isn't encrypted, and therefore it can be audited. I am therefore strongly opposed to it moving to historical status. I believe that having it as MAY is reasonable for IPv4. I believe that the decision as to MAY/SHOULD/MUST for IPv6 should be left to ipngwg. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Fri Jun 2 15:15:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26275; Fri, 2 Jun 2000 15:15:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10363 Fri, 2 Jun 2000 17:29:02 -0400 (EDT) From: Sankar Ramamoorthi Reply-To: sankar@nexsi.com To: KokMing , ipsec@lists.tislabs.com Subject: Re: Reasons for AH & ESP Date: Fri, 2 Jun 2000 14:30:56 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00060214380700.00924@odin> Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 27 May 2000, KokMing wrote: > Hi, > > Does anyone know, or is able to explain the reasons for AH & ESP? > As Neil Ferguson and Bruce Schneier wrote in 'Cryptographic Evaluation of > IPsec', I too, find no reasons for two protocols in the RFCs. > > The reasons I think of is.. > > 1. Cryptography is not exportable > Well, it's more or less exportable now, and does the use of MD5 as a HMAC > count as cryptography? I think not. Wouldn't it be better to have an ESP > with compulsory AH authentication, and optional encryption? > > 2. It's more flexible > IMHO, the flexibility of IPsec is killing it, the configurations are > simply too numerous and complex for a layman (like me) to make head and > tail, much less use it properly. > > 3. Finer grain of control > As said, is it necessary? Will it make IPsec more secure against > cracking? or spoofing? or nothing? > > I'm sorry if this has been dwelt on long ago, but I simply couldn't stand > the mess IPsec is in, while I'm writing a paper about it, and I'll like > some comments on my views. I am not sure if any one is using AH and ESP this way, but this is one reasoning I was given some time back. RFC 2401 section 4.3 talks about combining security associations (iterated tunneling). It talks of a case (case 2) where an end-point could apply ESP with the outer gateway and AH with a host behind the gateway. Thus the packet could be authenticated and encrypted over the internet and just authenticated inside the network behind the gateway allowing for any traffic analysis. > > Regards, > Kokming Ang > > ISRC > Queensland University of Technology > Brisbane, Australia -- sankar ramamoorthi email: sankar@nexsi.com phone: 408-579-5718 (w) From owner-ipsec@lists.tislabs.com Fri Jun 2 15:16:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26288; Fri, 2 Jun 2000 15:16:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10345 Fri, 2 Jun 2000 17:25:18 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14648.10274.77357.584679@xedia.com> Date: Fri, 2 Jun 2000 17:33:22 -0400 (EDT) To: dharkins@cips.nokia.com Cc: ipsec@lists.tislabs.com Subject: Re: Interoperability (was: Death to AH?) References: <4.3.2.7.2.20000602160158.045ac5b0@homebase.htt-consult.com> <200006022124.OAA22376@potassium.network-alchemy.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> On Fri, 02 Jun 2000 16:05:43 EDT you wrote >> You mention several other problems. Perhaps you could start your >> own thread on them :)' >> >> Gee I don't liek the way IKE doesn't really define approaches for >> lifetimes for the ISAKMP SA. Results in interop challenges...... Dan> Here we go again Bob.... Dan> Quite a while ago I attempted to define an approach to deal with Dan> things like lifetimes and key lengths and other attributes that Dan> do not have a simple boolean acceptance criteria and Dan> failed. There was no consensus. But I'm willing to try again: Dan> If someone offers you a keylength for a variable-keylenght Dan> cipher which is greater than or equal to what you have Dan> configured, accept it. If it's less reject it. I'd support that. Dan> If someone offers you a lifetime which is less than or equal to Dan> what you have configured, accept it. If it's more reject it. I'd support that too. Dan> The hardest one though is the Diffie-Hellman group. I know of Dan> quite a few people that will accept group 5 (and reject group 1) Dan> if they're configured for group 2 but even saying that an Dan> implementation SHOULD do that seemed to be too much for enough Dan> people to kill it. Hm. Weird. Could we try that one again and see why this is? Dan> And where in the scale do you add new groups Dan> or groups of different types-- elliptic curve vs. prime modulus? I think you have to leave that one out. The reason is that, unlike all the other examples, there is no clear order among these. That indeed is the problem with the group number: it only has a partial order. paul From owner-ipsec@lists.tislabs.com Fri Jun 2 15:16:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26302; Fri, 2 Jun 2000 15:16:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10292 Fri, 2 Jun 2000 17:16:37 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: Death to AH? (was: Reasons for AH & ESP ) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Jun 2000 17:24:40 -0400 Message-Id: <20000602212440.C060E35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200006022050.QAA17398@solidum.com>, Michael Richardson writes: > > I believe that the decision as to MAY/SHOULD/MUST for IPv6 should be left to > ipngwg. No -- they're not security folks, for the most part. (There are certainly exceptions, including Ran Atkinson.) The decision needs to be made jointly, based on headers devised by ipngwg and analyzed for security properties by ipsecwg. --Steve Bellovin From owner-ipsec@lists.tislabs.com Fri Jun 2 15:49:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26654; Fri, 2 Jun 2000 15:49:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10801 Fri, 2 Jun 2000 17:56:45 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14648.12166.453671.954064@xedia.com> Date: Fri, 2 Jun 2000 18:04:54 -0400 (EDT) To: sankar@nexsi.com Cc: ipsec@lists.tislabs.com Subject: Re: Reasons for AH & ESP References: <00060214380700.00924@odin> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sankar" == Sankar Ramamoorthi writes: Sankar> I am not sure if any one is using AH and ESP this way, but Sankar> this is one reasoning I was given some time back. Sankar> RFC 2401 section 4.3 talks about combining security Sankar> associations (iterated tunneling). It talks of a case (case Sankar> 2) where an end-point could apply ESP with the outer gateway Sankar> and AH with a host behind the gateway. Thus the packet could Sankar> be authenticated and encrypted over the internet and just Sankar> authenticated inside the network behind the gateway allowing Sankar> for any traffic analysis. I think you lose confidentiality doing this, because it leaves the packets vulnerable to Steve Bellovin's splicing attack on ESP. To defeat that attack, you have to do authentication in the same box that does the decryption. paul From owner-ipsec@lists.tislabs.com Fri Jun 2 16:19:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26908; Fri, 2 Jun 2000 16:19:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11098 Fri, 2 Jun 2000 18:20:59 -0400 (EDT) From: Sankar Ramamoorthi Reply-To: sankar@nexsi.com To: Paul Koning , sankar@nexsi.com Subject: Re: Reasons for AH & ESP Date: Fri, 2 Jun 2000 15:17:40 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: ipsec@lists.tislabs.com References: <00060214380700.00924@odin> <14648.12166.453671.954064@xedia.com> In-Reply-To: <14648.12166.453671.954064@xedia.com> MIME-Version: 1.0 Message-Id: <00060215304003.00924@odin> Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 02 Jun 2000, Paul Koning wrote: > >>>>> "Sankar" == Sankar Ramamoorthi writes: > > Sankar> I am not sure if any one is using AH and ESP this way, but > Sankar> this is one reasoning I was given some time back. > > Sankar> RFC 2401 section 4.3 talks about combining security > Sankar> associations (iterated tunneling). It talks of a case (case > Sankar> 2) where an end-point could apply ESP with the outer gateway > Sankar> and AH with a host behind the gateway. Thus the packet could > Sankar> be authenticated and encrypted over the internet and just > Sankar> authenticated inside the network behind the gateway allowing > Sankar> for any traffic analysis. > > I think you lose confidentiality doing this, because it leaves the > packets vulnerable to Steve Bellovin's splicing attack on ESP. To > defeat that attack, you have to do authentication in the same box that > does the decryption. > Yes, ESP trailer based authentication could be done on the box that does the decryption (the outer gateway) - though it will be reduntant to do both AH and ESP authentication. However it still will be useful if one wants encryption and authentication for traffic on the internet and just authentication on the inside (though it looks too fancy to me - that seems to be potential use one can infer from reading 2401). > paul -- sankar ramamoorthi email: sankar@nexsi.com phone: 408-579-5718 (w) From owner-ipsec@lists.tislabs.com Fri Jun 2 20:58:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22997; Fri, 2 Jun 2000 20:58:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11625 Fri, 2 Jun 2000 22:55:10 -0400 (EDT) Message-Id: <200006030303.XAA19949@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Death to AH? (was: Reasons for AH & ESP ) In-Reply-To: Your message of "Fri, 02 Jun 2000 17:24:40 EDT." <20000602212440.C060E35DC2@smb.research.att.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 02 Jun 2000 23:03:21 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Steven" == Steven M Bellovin writes: Steven> In message <200006022050.QAA17398@solidum.com>, Michael Richardson writes: >> I believe that the decision as to MAY/SHOULD/MUST for IPv6 should be left to >> ipngwg. Steven> No -- they're not security folks, for the most part. (There are Steven> certainly exceptions, including Ran Atkinson.) The decision needs to Steven> be made jointly, based on headers devised by ipngwg and analyzed for Steven> security properties by ipsecwg. That's not the point. A new header may require AH. That we can decide in a number of ways. Right now, it is my understanding that all IPv6 implementations must implement AH to be compliant, independantly of what headers they use. If your analysis is correct, that there aren't any headers that benefit from AH (and I believe it to be) then it seems to me that the decision as to whether the AH feature (alone) is *essential* for IPv6 should be up to ipngwg. It seems that you are hedging your bets here Steven: if you believe that there may be headers devised by ipngwg that would require AH, then we have found a use for AH in IPv6. If not, then AH stands as a feature by itself. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Sat Jun 3 00:14:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA01979; Sat, 3 Jun 2000 00:14:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12025 Sat, 3 Jun 2000 02:13:24 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: Paul Koning cc: dharkins@cips.nokia.com, ipsec@lists.tislabs.com Message-ID: <852568F3.00226195.00@smtpmail.certicom.com> Date: Fri, 2 Jun 2000 22:32:15 -0700 Subject: Re: Interoperability (was: Death to AH?) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is no order, but there is a well documented strength even between differnent crypto systems. If you accept Dan's approach to variable key-length ciphers, why wouldn't you accpet it for variable key length public-key algorithms? cheers - john Paul Koning on 02.06.2000 14:33:22 To: dharkins@cips.nokia.com cc: ipsec@lists.tislabs.com (bcc: John Harleman/Certicom) Subject: Re: Interoperability (was: Death to AH?) >>>>> "Dan" == Dan Harkins writes: Dan> On Fri, 02 Jun 2000 16:05:43 EDT you wrote >> You mention several other problems. Perhaps you could start your >> own thread on them :)' >> >> Gee I don't liek the way IKE doesn't really define approaches for >> lifetimes for the ISAKMP SA. Results in interop challenges...... Dan> Here we go again Bob.... Dan> Quite a while ago I attempted to define an approach to deal with Dan> things like lifetimes and key lengths and other attributes that Dan> do not have a simple boolean acceptance criteria and Dan> failed. There was no consensus. But I'm willing to try again: Dan> If someone offers you a keylength for a variable-keylenght Dan> cipher which is greater than or equal to what you have Dan> configured, accept it. If it's less reject it. I'd support that. Dan> If someone offers you a lifetime which is less than or equal to Dan> what you have configured, accept it. If it's more reject it. I'd support that too. Dan> The hardest one though is the Diffie-Hellman group. I know of Dan> quite a few people that will accept group 5 (and reject group 1) Dan> if they're configured for group 2 but even saying that an Dan> implementation SHOULD do that seemed to be too much for enough Dan> people to kill it. Hm. Weird. Could we try that one again and see why this is? Dan> And where in the scale do you add new groups Dan> or groups of different types-- elliptic curve vs. prime modulus? I think you have to leave that one out. The reason is that, unlike all the other examples, there is no clear order among these. That indeed is the problem with the group number: it only has a partial order. paul From owner-ipsec@lists.tislabs.com Sat Jun 3 11:23:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29030; Sat, 3 Jun 2000 11:23:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12895 Sat, 3 Jun 2000 12:51:21 -0400 (EDT) From: Mohan Parthasarathy Message-Id: <200006031658.e53Gwhw10064@locked.eng.sun.com> Subject: Re: Death to AH? (was: Reasons for AH & ESP ) In-Reply-To: <20000602212440.C060E35DC2@smb.research.att.com> from "Steven M. Bellovin" at "Jun 2, 2000 05:24:40 pm" To: "Steven M. Bellovin" Date: Sat, 3 Jun 2000 09:58:43 -0700 (PDT) CC: Michael Richardson , ipsec@lists.tislabs.com X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In message <200006022050.QAA17398@solidum.com>, Michael Richardson writes: > > > > > I believe that the decision as to MAY/SHOULD/MUST for IPv6 should be left to > > ipngwg. > > No -- they're not security folks, for the most part. (There are > certainly exceptions, including Ran Atkinson.) The decision needs to > be made jointly, based on headers devised by ipngwg and analyzed for > security properties by ipsecwg. > Mobile IPv6 has introduced new IPv6 destination options which requires the use of AH. Section 4.4 of draft-ietf-mobileip-ipv6-12.txt explains the IPsec requirements. (June 8th is the deadline for any comments. It is to become a proposed standard). It specifically says ESP can't be used. When a mobile node is away from home, it sends binding updates (destination option) to Home agents/correspondent nodes indicating its new location. Binding updates MUST be accompanied by the Home address option (another destination option). In this case AH covers both the care of address (current location of the mobile node) pointed by the IPv6 header's source address and the home address present in the home address option. How do we protect this using ESP-NULL-AH ? How do you protect both the care of address and the Home address ? -mohan From owner-ipsec@lists.tislabs.com Sat Jun 3 13:11:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00313; Sat, 3 Jun 2000 13:11:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13228 Sat, 3 Jun 2000 15:17:17 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14649.23433.986059.833174@thomasm-u1.cisco.com> Date: Sat, 3 Jun 2000 12:24:57 -0700 (PDT) To: Mohan Parthasarathy Cc: "Steven M. Bellovin" , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Death to AH? (was: Reasons for AH & ESP ) In-Reply-To: <200006031658.e53Gwhw10064@locked.eng.sun.com> References: <20000602212440.C060E35DC2@smb.research.att.com> <200006031658.e53Gwhw10064@locked.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mohan Parthasarathy writes: > Mobile IPv6 has introduced new IPv6 destination options which requires > the use of AH. Section 4.4 of draft-ietf-mobileip-ipv6-12.txt > explains the IPsec requirements. (June 8th is the deadline for > any comments. It is to become a proposed standard). It specifically > says ESP can't be used. Is there any particular reason why the binding cache update messages in the destination options cannot follow rather than precede an ESP header? It doesn't look to me like there is any reason to keep destination options in the clear, in which case ESP would work fine. Mike From owner-ipsec@lists.tislabs.com Mon Jun 5 02:39:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA05456; Mon, 5 Jun 2000 02:39:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17829 Mon, 5 Jun 2000 03:55:51 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E374B0@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: Commit Bit Date: Mon, 5 Jun 2000 11:02:47 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So the Commit bit is set in the last message of the initiator QM3 only. If the other side doesn't support the Commit bit, then we can begin sending packets after a certain timer, can't we? I mean because we won't receive any CONNECT message in return. Toni -----Original Message----- From: EXT Stephane Beaulieu [mailto:stephane@cisco.com] Sent: 02. June 2000 17:14 To: antonio.barrera@nokia.com; ipsec@lists.tislabs.com Subject: Re: Commit Bit Hi Toni, The commit bit is used because the initiator of QM has an IPsec SA set up before the responder does. The initiator has the IPsec SA set up as soon as he sends QM3, whereas the responder doesn't have his IPsec SA set up until he processes QM3. If the responder is a slow machine, or is overloaded, it could take a while to process QM3, and therefore could take a while to set up the IPsec SA. If the initiator sends an ESP packet to the responder right after sending QM3, the responder may not be ready to process it (or it could arive out of order). So, the commit bit was introduced to give the responder a method of telling the intiator "OK, my SA is set up now", so that no packets were dropped due to the timing issues described above. Stephane. ----- Original Message ----- From: To: Sent: Friday, June 02, 2000 8:30 AM Subject: Commit Bit > Could someone give me an example of the usefulness of the Commit Bit > in IKE? > I've read the RFC 2408 explaining how it works but I can't understand > completely its use. > A small example would clarify me a lot how it works. Just need to know > exactly when it's set and reset and when to send the CONNECT informational > message. > I understand the bit must be set when The ISAKMP SA is established > and reset afetr the phase I as it says in the RFC, but I can't see exactly > what do we win using it. > I know the subject was discussed some time ago but I haven't been > able to find a clear answer to my doubts. > Thnaks and sorry for the inconvenience. > > Toni Barrera > > From owner-ipsec@lists.tislabs.com Mon Jun 5 04:44:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10091; Mon, 5 Jun 2000 04:44:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18240 Mon, 5 Jun 2000 06:47:13 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E374B3@eseis06nok> To: ipsec@lists.tislabs.com Subject: IKE testing Date: Mon, 5 Jun 2000 13:49:47 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does anybody know availble test sites to test my IKE implementation? I've tried with NIST and SSH (currently down). It would be specially useful that it sends some pings after the negotiation to see it's really working fine. Thanks. Toni From owner-ipsec@lists.tislabs.com Mon Jun 5 05:27:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10841; Mon, 5 Jun 2000 05:27:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA18441 Mon, 5 Jun 2000 07:32:16 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E374BB@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: Commit Bit Date: Mon, 5 Jun 2000 14:39:26 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So the Commit bit is set in the last message of the initiator QM3 only. If the other side doesn't support the Commit bit, then we can begin sending packets after a certain timer, can't we? I mean because we won't receive any CONNECT message in return. Toni -----Original Message----- From: EXT Stephane Beaulieu [mailto:stephane@cisco.com] Sent: 02. June 2000 17:14 To: antonio.barrera@nokia.com; ipsec@lists.tislabs.com Subject: Re: Commit Bit Hi Toni, The commit bit is used because the initiator of QM has an IPsec SA set up before the responder does. The initiator has the IPsec SA set up as soon as he sends QM3, whereas the responder doesn't have his IPsec SA set up until he processes QM3. If the responder is a slow machine, or is overloaded, it could take a while to process QM3, and therefore could take a while to set up the IPsec SA. If the initiator sends an ESP packet to the responder right after sending QM3, the responder may not be ready to process it (or it could arive out of order). So, the commit bit was introduced to give the responder a method of telling the intiator "OK, my SA is set up now", so that no packets were dropped due to the timing issues described above. Stephane. ----- Original Message ----- From: To: Sent: Friday, June 02, 2000 8:30 AM Subject: Commit Bit > Could someone give me an example of the usefulness of the Commit Bit > in IKE? > I've read the RFC 2408 explaining how it works but I can't understand > completely its use. > A small example would clarify me a lot how it works. Just need to know > exactly when it's set and reset and when to send the CONNECT informational > message. > I understand the bit must be set when The ISAKMP SA is established > and reset afetr the phase I as it says in the RFC, but I can't see exactly > what do we win using it. > I know the subject was discussed some time ago but I haven't been > able to find a clear answer to my doubts. > Thnaks and sorry for the inconvenience. > > Toni Barrera > > From owner-ipsec@lists.tislabs.com Mon Jun 5 06:15:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12035; Mon, 5 Jun 2000 06:14:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18670 Mon, 5 Jun 2000 08:00:40 -0400 (EDT) Message-Id: <01BFCF13.DFC940E0.RuheenaR@future.futsoft.com> From: Ruheena Rashid Reply-To: "RuheenaR@future.futsoft.com" To: "ipsec@lists.tislabs.com" Cc: "'Ruheena Rashid'" Subject: RE: Commit Bit Date: Mon, 5 Jun 2000 17:31:24 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello I have some queries regarding the commit bit. RFC 2408 states that - "The Commit Bit can be set (at anytime) by either party participating in the SA establishment, and can be used during both phases of an ISAKMP SA establishment. However, the value MUST be reset after the Phase 1 negotiation." 1. What is the use of setting the commit bit in Phase 1 negotiation because it has to be reset after the completion of Phase 1 negotiation ? 2. What will be the behavior when the responder has set the commit bit in the Phase 2 negotiation ? Will it wait for the receipt of the NOTIFY payload with CONNECTED Notify message ? 3. Also, since the setting of commit bit requests the other end (peer) to wait until the receipt of NOTIFY payload with CONNECTED Notify message, this has to be informed to the IPsec so that no packets are dropped. How is this taken care ? Do we need to define a PF_KEY message to serve this purpose ? Regards Ruheena. Ruheena Rashid Software Engineer Future Software Pvt. Ltd. Nandanam Chennai -----Original Message----- From: antonio.barrera@nokia.com [SMTP:antonio.barrera@nokia.com] Sent: Monday, June 05, 2000 1:33 PM To: ipsec@lists.tislabs.com Subject: RE: Commit Bit So the Commit bit is set in the last message of the initiator QM3 only. If the other side doesn't support the Commit bit, then we can begin sending packets after a certain timer, can't we? I mean because we won't receive any CONNECT message in return. Toni -----Original Message----- From: EXT Stephane Beaulieu [mailto:stephane@cisco.com] Sent: 02. June 2000 17:14 To: antonio.barrera@nokia.com; ipsec@lists.tislabs.com Subject: Re: Commit Bit Hi Toni, The commit bit is used because the initiator of QM has an IPsec SA set up before the responder does. The initiator has the IPsec SA set up as soon as he sends QM3, whereas the responder doesn't have his IPsec SA set up until he processes QM3. If the responder is a slow machine, or is overloaded, it could take a while to process QM3, and therefore could take a while to set up the IPsec SA. If the initiator sends an ESP packet to the responder right after sending QM3, the responder may not be ready to process it (or it could arive out of order). So, the commit bit was introduced to give the responder a method of telling the intiator "OK, my SA is set up now", so that no packets were dropped due to the timing issues described above. Stephane. ----- Original Message ----- From: To: Sent: Friday, June 02, 2000 8:30 AM Subject: Commit Bit > Could someone give me an example of the usefulness of the Commit Bit > in IKE? > I've read the RFC 2408 explaining how it works but I can't understand > completely its use. > A small example would clarify me a lot how it works. Just need to know > exactly when it's set and reset and when to send the CONNECT informational > message. > I understand the bit must be set when The ISAKMP SA is established > and reset afetr the phase I as it says in the RFC, but I can't see exactly > what do we win using it. > I know the subject was discussed some time ago but I haven't been > able to find a clear answer to my doubts. > Thnaks and sorry for the inconvenience. > > Toni Barrera > > From owner-ipsec@lists.tislabs.com Mon Jun 5 06:35:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12221; Mon, 5 Jun 2000 06:35:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18808 Mon, 5 Jun 2000 08:28:34 -0400 (EDT) Message-Id: <01BFCF17.C93ED980.RuheenaR@future.futsoft.com> From: Ruheena Rashid Reply-To: "RuheenaR@future.futsoft.com" To: "'ipsec@lists.tislabs.com'" Subject: Query on cookies - RFC 2408 Date: Mon, 5 Jun 2000 17:59:24 +0530 Importance: high X-Priority: 1 (Highest) Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello I need some clarification on the generation of cookies. RFC 2408 mentions that - "ISAKMP requires that the cookie be unique for each SA establishment to help prevent replay attacks, therefore, the date and time MUST be added to the information hashed." How can the date and time information be added to the hashed information ? Thanks in advance Regards Ruheena. Ruheena Rashid Software Engineer Future Software Pvt. Ltd. Nandanam Chennai From owner-ipsec@lists.tislabs.com Mon Jun 5 07:53:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13234; Mon, 5 Jun 2000 07:52:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19356 Mon, 5 Jun 2000 09:47:24 -0400 (EDT) Message-ID: <393BB031.6EAEF162@indusriver.com> Date: Mon, 05 Jun 2000 09:50:42 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "RuheenaR@future.futsoft.com" CC: "'ipsec@lists.tislabs.com'" Subject: Re: Query on cookies - RFC 2408 References: <01BFCF17.C93ED980.RuheenaR@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > How can the date and time information be added to the hashed information ? Concatenate your current date and time of day (to their best available resolution) together with the IP addresses of the two peers into a buffer. Compute the hash of that buffer and then combine (XOR) the two halves of your hash result to get the cookie. We use SHA for the hash function. MD5 is probably OK but I'm not a cryptographer... Our implementation also includes a random value in the hashed buffer thatis computed once when we start our IKE daemon. This assures the cookies will vary if our daemon is restarted. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Mon Jun 5 08:28:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14601; Mon, 5 Jun 2000 08:28:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19528 Mon, 5 Jun 2000 10:20:50 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14651.47405.849704.50597@xedia.com> Date: Mon, 5 Jun 2000 10:29:01 -0400 (EDT) To: jharleman@certicom.com Cc: dharkins@cips.nokia.com, ipsec@lists.tislabs.com Subject: Re: Interoperability (was: Death to AH?) References: <852568F3.00226195.00@smtpmail.certicom.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "John" == John Harleman writes: John> There is no order, but there is a well documented strength even John> between differnent crypto systems. If you accept Dan's approach John> to variable key-length ciphers, why wouldn't you accpet it for John> variable key length public-key algorithms? I assume you meant that there is "a well documented ordering of strength for the different systems". If so, I would disagree. Certainly people have voiced the opinion that ECC with an x bit key is as strong as RSA with a y bit key. But others have voiced different opinions. Similarly, you may be able to find opinions on the relative strength of, say, IDEA, 3DES, and Blowfish, but I don't think you will find consensus. On the other hand, I would be surprised to see, for any reasonably designed cipher, a result that security decreases when the key size increases. So it appears safe to say there is a partial order, i.e., for two ciphers that use the *same* system but different key length, the one with the larger key has security >= that of the one with the smaller key. But I don't agree you can do anything analogous when the ciphers are from different systems -- whether the systems are symmetric or asymmetric. paul ---------------- ... Dan> And where in the scale do you add new groups or groups of Dan> different types-- elliptic curve vs. prime modulus? John> I think you have to leave that one out. The reason is that, John> unlike all the other examples, there is no clear order among John> these. That indeed is the problem with the group number: it John> only has a partial order. John> paul From owner-ipsec@lists.tislabs.com Mon Jun 5 08:38:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15226; Mon, 5 Jun 2000 08:38:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19671 Mon, 5 Jun 2000 10:32:07 -0400 (EDT) Message-Id: <200006051445.UAA18855@brahma.roc.com> X-Sender: gulnaazm@trinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 05 Jun 2000 20:18:46 +0530 To: "RuheenaR@future.futsoft.com" From: Gulnaaz Malled Subject: Re: Query on cookies - RFC 2408 Cc: "'ipsec@lists.tislabs.com'" In-Reply-To: <01BFCF17.C93ED980.RuheenaR@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Ruheena! How we have implemented is, we are calling the system time function to stamp the cookie while generating itself, before hashing the information. Thats how..... I hope I am talking to the point u asked, right?? -Regards At 05:59 PM 06/05/2000 +0530, you wrote: >Hello > >I need some clarification on the generation of cookies. > >RFC 2408 mentions that - > >"ISAKMP requires that the cookie be unique for each SA establishment to >help prevent replay attacks, therefore, the date and time MUST be added to >the information hashed." > >How can the date and time information be added to the hashed information ? > >Thanks in advance > >Regards >Ruheena. > >Ruheena Rashid >Software Engineer >Future Software Pvt. Ltd. >Nandanam >Chennai > From owner-ipsec@lists.tislabs.com Mon Jun 5 10:18:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20492; Mon, 5 Jun 2000 10:18:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20158 Mon, 5 Jun 2000 12:07:51 -0400 (EDT) From: Mohan Parthasarathy Message-Id: <200006051615.e55GFGQ11378@locked.eng.sun.com> Subject: Re: Death to AH? (was: Reasons for AH & ESP ) In-Reply-To: <14649.23433.986059.833174@thomasm-u1.cisco.com> from Michael Thomas at "Jun 3, 2000 12:24:57 pm" To: Michael Thomas Date: Mon, 5 Jun 2000 09:15:16 -0700 (PDT) CC: "Steven M. Bellovin" , Michael Richardson , ipsec@lists.tislabs.com X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Mohan Parthasarathy writes: > > Mobile IPv6 has introduced new IPv6 destination options which requires > > the use of AH. Section 4.4 of draft-ietf-mobileip-ipv6-12.txt > > explains the IPsec requirements. (June 8th is the deadline for > > any comments. It is to become a proposed standard). It specifically > > says ESP can't be used. > > Is there any particular reason why the binding cache > update messages in the destination options cannot > follow rather than precede an ESP header? It doesn't > look to me like there is any reason to keep destination > options in the clear, in which case ESP would work > fine. > Binding update messages itself can appear after AH/ESP header. But when used with HOME address option it should appear before. Earlier revision of this draft had the home address option after AH/ESP header. I don't know what made them change to put before the AH/ESP header. Something relevant to this can be seen in the following discussion of the ipng archives : http://www.wcug.wwu.edu/lists/ipng/199906/msg00042.html But still one could argue that AH still protects the CoA present in the IPv6 header's source address field. (This can still be overcome by using yet another "alternate-care-of-address" option. This is not a MUST/SHOULD in the draft). Why is it that the protection offered by AH to the IPv6 header's source address field is not important ? At least i can see it useful in this case. -mohan From owner-ipsec@lists.tislabs.com Mon Jun 5 11:29:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21540; Mon, 5 Jun 2000 11:29:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20372 Mon, 5 Jun 2000 13:16:56 -0400 (EDT) Message-ID: <393BE247.6DEF3B61@redcreek.com> Date: Mon, 05 Jun 2000 10:24:23 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: dharkins@cips.nokia.com, ipsec@lists.tislabs.com Subject: Re: Interoperability (was: Death to AH?) References: <4.3.2.7.2.20000602160158.045ac5b0@homebase.htt-consult.com> <200006022124.OAA22376@potassium.network-alchemy.com> <14648.10274.77357.584679@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > >>>>> "Dan" == Dan Harkins writes: > > Dan> On Fri, 02 Jun 2000 16:05:43 EDT you wrote > >> You mention several other problems. Perhaps you could start your > >> own thread on them :)' > >> > >> Gee I don't liek the way IKE doesn't really define approaches for > >> lifetimes for the ISAKMP SA. Results in interop challenges...... > > Dan> Here we go again Bob.... > > Dan> Quite a while ago I attempted to define an approach to deal with > Dan> things like lifetimes and key lengths and other attributes that > Dan> do not have a simple boolean acceptance criteria and > Dan> failed. There was no consensus. But I'm willing to try again: > > Dan> If someone offers you a keylength for a variable-keylenght > Dan> cipher which is greater than or equal to what you have > Dan> configured, accept it. If it's less reject it. > > I'd support that. See comments below. > Dan> If someone offers you a lifetime which is less than or equal to > Dan> what you have configured, accept it. If it's more reject it. > > I'd support that too. > > Dan> The hardest one though is the Diffie-Hellman group. I know of > Dan> quite a few people that will accept group 5 (and reject group 1) > Dan> if they're configured for group 2 but even saying that an > Dan> implementation SHOULD do that seemed to be too much for enough > Dan> people to kill it. > > Hm. Weird. Could we try that one again and see why this is? I argued this point at length with Dan around a year ago (or so). My original position was that we shouldn't write the ike standard such that the admin could not control whether this occurred or not. Dan argued that In the case of Blowfish, it requires no more work to use a longer key than a shorter one. We never finished the debate. I think I agree with Dan when it comes to crypto algorithms like Blowfish, i.e. when increasing the key length does not affect the load on the machine. On the other hand, I'm not sure that increasing to 3des when des is configured is the right thing to do, though I'm willing to consider other points of view. I think there is a definite issue with DH values though: if I am configured to accept group 2, sending me group 5 most definitely affects my work load in a significant way. This has DoS implications. That being the case, it might be better to make this a local decision. Scott > > Dan> And where in the scale do you add new groups > Dan> or groups of different types-- elliptic curve vs. prime modulus? > > I think you have to leave that one out. The reason is that, unlike > all the other examples, there is no clear order among these. That > indeed is the problem with the group number: it only has a partial > order. > > paul From owner-ipsec@lists.tislabs.com Mon Jun 5 12:00:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22155; Mon, 5 Jun 2000 12:00:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20519 Mon, 5 Jun 2000 13:54:43 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14651.60234.896260.377030@xedia.com> Date: Mon, 5 Jun 2000 14:02:50 -0400 (EDT) To: skelly@redcreek.com Cc: dharkins@cips.nokia.com, ipsec@lists.tislabs.com Subject: Re: Interoperability (was: Death to AH?) References: <4.3.2.7.2.20000602160158.045ac5b0@homebase.htt-consult.com> <200006022124.OAA22376@potassium.network-alchemy.com> <14648.10274.77357.584679@xedia.com> <393BE247.6DEF3B61@redcreek.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Scott" == Scott G Kelly writes: Scott> Paul Koning wrote: >> >>>>> "Dan" == Dan Harkins writes: Dan> Quite a while ago I attempted to define an approach to deal with Dan> things like lifetimes and key lengths and other attributes that Dan> do not have a simple boolean acceptance criteria and Dan> failed. There was no consensus. But I'm willing to try again: >> Dan> If someone offers you a keylength for a variable-keylenght Dan> cipher which is greater than or equal to what you have Dan> configured, accept it. If it's less reject it. >> I'd support that. Scott> I argued this point at length with Dan around a year ago (or Scott> so). My original position was that we shouldn't write the ike Scott> standard such that the admin could not control whether this Scott> occurred or not. Dan argued that In the case of Blowfish, it Scott> requires no more work to use a longer key than a shorter Scott> one. We never finished the debate. I think I agree with Dan Scott> when it comes to crypto algorithms like Blowfish, i.e. when Scott> increasing the key length does not affect the load on the Scott> machine. On the other hand, I'm not sure that increasing to Scott> 3des when des is configured is the right thing to do, though Scott> I'm willing to consider other points of view. Scott> I think there is a definite issue with DH values though: if I Scott> am configured to accept group 2, sending me group 5 most Scott> definitely affects my work load in a significant way. This has Scott> DoS implications. That being the case, it might be better to Scott> make this a local decision. Fair enough. And for some implementations the same would be true for DES vs. 3DES (while for others it would not be -- if you have a hardware assist that's bus or network bound, for example). Is the only problem one of specifying that this "allow upgrading to stronger ciphers" may be enabled or disabled as a policy matter if the implementation wishes to do that? If so, that sounds entirely reasonable to me. The impression I got from Dan's comment is that there was some opposition to the entire notion, which is harder to understand. Right now there's no text at all that describes this stuff. I suppose you could argue that it's a local matter -- people are allowed to do this if they feel like it. Probably so... but it seems useful to make it a recommended practice subject to some caveats about possible performance issues in at least some of the cases. paul PS. Dan, your return address is not working... email to it keeps bouncing. From owner-ipsec@lists.tislabs.com Tue Jun 6 09:01:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06771; Tue, 6 Jun 2000 09:01:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24510 Tue, 6 Jun 2000 10:23:22 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B78908C@md-exchange1.nai.com> From: "Mason, David" To: "'Scott G. Kelly'" , Paul Koning Cc: dharkins@cips.nokia.com, ipsec@lists.tislabs.com Subject: RE: Interoperability (was: Death to AH?) Date: Tue, 6 Jun 2000 07:30:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Beside possible DoS vulnerability (in the DH groups), another big argument against "negotiating up" was the asymmetry of negotiation. With "negotiating up", if the side configured with the stronger value initiates the rekey (or original connection) it succeeds, whereas with the same configuration if the weaker side initiates the rekey (or original connection) it fails. Of course some argued that with "negotiating up" at least the connection could be established if the right side always initiated and without "negotiating up" the connection would never be established. On the other hand, with "negotiating up" the connection would likely exhibit intermittant problems that might be harder to determine the cause of than when "negotiating up" is not being used. One (partial) resolution that was suggested was that for algorithms where an increase in key length does not mean an increase in workload the maximum key length was ALWAYS to be used (i.e., the algorithm was to be treated as a fixed key length algorithm). I don't recall anyone objecting to this (e.g., I don't think anyone wants 2 key TripleDes). -dave From owner-ipsec@lists.tislabs.com Tue Jun 6 10:03:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10491; Tue, 6 Jun 2000 10:03:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26291 Tue, 6 Jun 2000 11:57:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20000606120446.00af7f00@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Jun 2000 12:05:44 -0400 To: "Mason, David" , "'Scott G. Kelly'" , Paul Koning From: Robert Moskowitz Subject: RE: Interoperability (was: Death to AH?) Cc: dharkins@cips.nokia.com, ipsec@lists.tislabs.com In-Reply-To: <447A3F40A07FD211BA2700A0C99D759B78908C@md-exchange1.nai.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:30 AM 6/6/2000 -0700, Mason, David wrote: >I don't recall anyone objecting to this (e.g., >I don't think anyone wants 2 key TripleDes). SOme have asked for this for use in France where the limit is still 128 bits. And that is the problem with negotiating up. there might be legal restrictions :( Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Tue Jun 6 10:30:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10854; Tue, 6 Jun 2000 10:30:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27171 Tue, 6 Jun 2000 12:23:34 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B789092@md-exchange1.nai.com> From: "Mason, David" To: "'Robert Moskowitz'" , "Mason, David" , "'Scott G. Kelly'" , Paul Koning Cc: dharkins@cips.nokia.com, ipsec@lists.tislabs.com Subject: RE: Interoperability (was: Death to AH?) Date: Tue, 6 Jun 2000 09:30:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At one point someone was also asking for 40-bit DES and it was decided that these deficient key lengths were best specified by a separate transform ID (and ideally instead of assigning a specific transform ID change the DOI to have a private use range). I'm sure we're all glad that the working group did not buckle into political pressure to make providing weakened cryptography a standard. -dave -----Original Message----- From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com] Sent: Tuesday, June 06, 2000 12:06 PM To: Mason, David; 'Scott G. Kelly'; Paul Koning Cc: dharkins@cips.nokia.com; ipsec@lists.tislabs.com Subject: RE: Interoperability (was: Death to AH?) At 07:30 AM 6/6/2000 -0700, Mason, David wrote: >I don't recall anyone objecting to this (e.g., >I don't think anyone wants 2 key TripleDes). SOme have asked for this for use in France where the limit is still 128 bits. And that is the problem with negotiating up. there might be legal restrictions :( Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Tue Jun 6 10:43:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11007; Tue, 6 Jun 2000 10:43:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27284 Tue, 6 Jun 2000 12:37:32 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B789093@md-exchange1.nai.com> From: "Mason, David" To: "Mason, David" , "'Robert Moskowitz'" , "'Scott G. Kelly'" , "'Paul Koning'" Cc: "'dharkins@cips.nokia.com'" , "'ipsec@lists.tislabs.com'" Subject: RE: Interoperability (was: Death to AH?) Date: Tue, 6 Jun 2000 09:44:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk With the talk of moving AH to historical perhaps it's a good time to suggest moving DES and Group 1 to historical as well! -dave From owner-ipsec@lists.tislabs.com Tue Jun 6 10:50:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11145; Tue, 6 Jun 2000 10:50:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27347 Tue, 6 Jun 2000 12:46:10 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14653.11457.44684.374777@xedia.com> Date: Tue, 6 Jun 2000 12:54:25 -0400 (EDT) To: rgm-sec@htt-consult.com Cc: David_Mason@nai.com, ipsec@lists.tislabs.com Subject: RE: DES (was: Interoperability) References: <447A3F40A07FD211BA2700A0C99D759B789093@md-exchange1.nai.co m> <4.3.2.7.2.20000606125037.046c7430@homebase.htt-consult.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Robert" == Robert Moskowitz writes: Robert> At 09:44 AM 6/6/2000 -0700, Mason, David wrote: >> With the talk of moving AH to historical perhaps it's a good time >> to suggest moving DES and Group 1 to historical as well! Robert> SAAG 'voting' has DES to historical waiting on AES selection. Why? The "insecure" status of DES is unrelated to the AES process or schedule. paul From owner-ipsec@lists.tislabs.com Tue Jun 6 10:55:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11203; Tue, 6 Jun 2000 10:55:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27325 Tue, 6 Jun 2000 12:43:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20000606125037.046c7430@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Jun 2000 12:51:53 -0400 To: "Mason, David" , "Mason, David" , "'Scott G. Kelly'" , "'Paul Koning'" From: Robert Moskowitz Subject: RE: Interoperability (was: Death to AH?) Cc: "'dharkins@cips.nokia.com'" , "'ipsec@lists.tislabs.com'" In-Reply-To: <447A3F40A07FD211BA2700A0C99D759B789093@md-exchange1.nai.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:44 AM 6/6/2000 -0700, Mason, David wrote: >With the talk of moving AH to historical perhaps it's a good time to suggest >moving DES and Group 1 to historical as well! SAAG 'voting' has DES to historical waiting on AES selection. Hilarie's analysis positions gorup 1 fairly well. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Tue Jun 6 11:09:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11454; Tue, 6 Jun 2000 11:09:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27428 Tue, 6 Jun 2000 12:55:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20000606130140.046c0c80@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Jun 2000 13:02:39 -0400 To: Paul Koning From: Robert Moskowitz Subject: RE: DES (was: Interoperability) Cc: David_Mason@nai.com, ipsec@lists.tislabs.com In-Reply-To: <14653.11457.44684.374777@xedia.com> References: <447A3F40A07FD211BA2700A0C99D759B789093@md-exchange1.nai.co m> <4.3.2.7.2.20000606125037.046c7430@homebase.htt-consult.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:54 PM 6/6/2000 -0400, Paul Koning wrote: > >>>>> "Robert" == Robert Moskowitz writes: > > Robert> At 09:44 AM 6/6/2000 -0700, Mason, David wrote: > >> With the talk of moving AH to historical perhaps it's a good time > >> to suggest moving DES and Group 1 to historical as well! > > Robert> SAAG 'voting' has DES to historical waiting on AES selection. > >Why? > >The "insecure" status of DES is unrelated to the AES process or >schedule. See draft-ietf-saag-aes-ciph-00.txt and the ensuing discussion on the saag list. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Tue Jun 6 11:24:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11884; Tue, 6 Jun 2000 11:24:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27573 Tue, 6 Jun 2000 13:10:20 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14653.12906.406109.313895@xedia.com> Date: Tue, 6 Jun 2000 13:18:34 -0400 (EDT) To: rgm-sec@htt-consult.com Cc: David_Mason@nai.com, ipsec@lists.tislabs.com Subject: RE: DES (was: Interoperability) References: <447A3F40A07FD211BA2700A0C99D759B789093@md-exchange1.nai.co m> <4.3.2.7.2.20000606125037.046c7430@homebase.htt-consult.com> <4.3.2.7.2.20000606130140.046c0c80@homebase.htt-consult.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Robert" == Robert Moskowitz writes: Robert> At 12:54 PM 6/6/2000 -0400, Paul Koning wrote: >> Robert> SAAG 'voting' has DES to historical waiting on AES selection. >> Why? >> >> The "insecure" status of DES is unrelated to the AES process or >> schedule. Robert> See draft-ietf-saag-aes-ciph-00.txt I see nothing in there that argues against moving DES to historic status. Incidentally, it's curious that this draft doesn't appear in the drafts directory or drafts index. Perhaps because it's expired? Robert> and the ensuing discussion on the saag list. The SAAG homepage doesn't point to any archive of that list; is there one? paul From owner-ipsec@lists.tislabs.com Tue Jun 6 11:35:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11971; Tue, 6 Jun 2000 11:34:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27685 Tue, 6 Jun 2000 13:23:10 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B789096@md-exchange1.nai.com> From: "Mason, David" To: "'Paul Koning'" Cc: ipsec@lists.tislabs.com Subject: RE: DES (was: Interoperability) Date: Tue, 6 Jun 2000 10:30:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The archive files may be retrieved via anonymous ftp from ftp.tislabs.com in /pub/lists/saag -dave -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Tuesday, June 06, 2000 1:19 PM To: rgm-sec@htt-consult.com Cc: David_Mason@NAI.com; ipsec@lists.tislabs.com Subject: RE: DES (was: Interoperability) >>>>> "Robert" == Robert Moskowitz writes: Robert> At 12:54 PM 6/6/2000 -0400, Paul Koning wrote: >> Robert> SAAG 'voting' has DES to historical waiting on AES selection. >> Why? >> >> The "insecure" status of DES is unrelated to the AES process or >> schedule. Robert> See draft-ietf-saag-aes-ciph-00.txt I see nothing in there that argues against moving DES to historic status. Incidentally, it's curious that this draft doesn't appear in the drafts directory or drafts index. Perhaps because it's expired? Robert> and the ensuing discussion on the saag list. The SAAG homepage doesn't point to any archive of that list; is there one? paul From owner-ipsec@lists.tislabs.com Tue Jun 6 12:02:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12289; Tue, 6 Jun 2000 12:02:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27866 Tue, 6 Jun 2000 13:59:15 -0400 (EDT) Date: Tue, 6 Jun 2000 14:06:49 -0400 (EDT) From: Henry Spencer To: Robert Moskowitz cc: ipsec@lists.tislabs.com Subject: RE: DES (was: Interoperability) In-Reply-To: <4.3.2.7.2.20000606130140.046c0c80@homebase.htt-consult.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 6 Jun 2000, Robert Moskowitz wrote: > >The "insecure" status of DES is unrelated to the AES process or > >schedule. > > See draft-ietf-saag-aes-ciph-00.txt The -01 version of that draft apparently expired in late March; there is no -02 apparent. Was this just a clerical error, or has interest in the matter lapsed? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 7 13:09:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15094; Wed, 7 Jun 2000 13:09:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04150 Wed, 7 Jun 2000 14:42:31 -0400 (EDT) Message-Id: <3.0.32.20000607115234.0093d2d0@cymail.cylink.com> X-Sender: jburke@cymail.cylink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 07 Jun 2000 11:52:34 -0700 To: ipsec@lists.tislabs.com From: jburke@cylink.com (John Burke) Subject: Query: Status of The IKE draft (later than RFC 2409) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can someone please speak on what is the current status of the new draft on IKE, draft-ietf-ipsec-ike-01.txt by Dan Harkins and Dave Carrell, May 1999? I don't see the draft listed on the Ipsec-charter web page, and it IS over 6 months old. But my understanding was that participants in the bakeoffs were generally working to the new elements in this draft, particularly Oakley Group 5 and the Acknowledged Informational exchange. Should we all still consider that this draft is the generally agreed direction? Is any further action expected to forward it? Are there still controversial points? Thanks, John Burke From owner-ipsec@lists.tislabs.com Thu Jun 8 00:53:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA05460; Thu, 8 Jun 2000 00:53:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA06233 Thu, 8 Jun 2000 02:41:01 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: Paul Koning cc: dharkins@cips.nokia.com, ipsec@lists.tislabs.com Message-ID: <852568F8.0024EE84.00@smtpmail.certicom.com> Date: Wed, 7 Jun 2000 22:02:07 -0700 Subject: Re: Interoperability (was: Death to AH?) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul: Excuse my delay, but what do you think of the IPSec-AES draft and the key strenghts that were accepted into ANSI? As far as comparisons, with any cipher they are made by evaluating the time to crack using the best known attacks today. Provided that the cipher has undergone sufficient standards scrutiny such as all of the FIPS standards--DES, DSA, RSA, and ECC, I believe that these are valid. There will always be some disention around the edges, but isn't it better to use the yardstick that the overwhelming majority of the community agree upon? cheers - john Paul Koning on 05.06.2000 07:29:01 To: John Harleman/Certicom@Certicom cc: dharkins@cips.nokia.com, ipsec@lists.tislabs.com Subject: Re: Interoperability (was: Death to AH?) >>>>> "John" == John Harleman writes: John> There is no order, but there is a well documented strength even John> between differnent crypto systems. If you accept Dan's approach John> to variable key-length ciphers, why wouldn't you accpet it for John> variable key length public-key algorithms? I assume you meant that there is "a well documented ordering of strength for the different systems". If so, I would disagree. Certainly people have voiced the opinion that ECC with an x bit key is as strong as RSA with a y bit key. But others have voiced different opinions. Similarly, you may be able to find opinions on the relative strength of, say, IDEA, 3DES, and Blowfish, but I don't think you will find consensus. On the other hand, I would be surprised to see, for any reasonably designed cipher, a result that security decreases when the key size increases. So it appears safe to say there is a partial order, i.e., for two ciphers that use the *same* system but different key length, the one with the larger key has security >= that of the one with the smaller key. But I don't agree you can do anything analogous when the ciphers are from different systems -- whether the systems are symmetric or asymmetric. paul ---------------- ... Dan> And where in the scale do you add new groups or groups of Dan> different types-- elliptic curve vs. prime modulus? John> I think you have to leave that one out. The reason is that, John> unlike all the other examples, there is no clear order among John> these. That indeed is the problem with the group number: it John> only has a partial order. John> paul From owner-ipsec@lists.tislabs.com Thu Jun 8 08:11:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25106; Thu, 8 Jun 2000 08:11:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07761 Thu, 8 Jun 2000 09:46:40 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14655.42416.951518.465010@xedia.com> Date: Thu, 8 Jun 2000 09:54:56 -0400 (EDT) To: jharleman@certicom.com Cc: ipsec@lists.tislabs.com Subject: Re: Interoperability (was: Death to AH?) References: <852568F8.0024EE84.00@smtpmail.certicom.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "John" == John Harleman writes: John> Hi Paul: Excuse my delay, but what do you think of the John> IPSec-AES draft It looks fine, other than the issue that has been discussed a while ago that the suggested D-H sizes may create an unacceptable performance hit. Note that the draft makes no assertions about the relative strength of the 5 candidates. (Others have done so, e.g., in the context of the AES conferences. At this point I'd say that there is only very partial consensus in this area.) John> and the key strenghts that were accepted into ANSI? Haven't seen that. Could you elaborate? John> As far as comparisons, with any cipher they are made by John> evaluating the time to crack using the best known attacks John> today. Provided that the cipher has undergone sufficient John> standards scrutiny such as all of the FIPS standards--DES, DSA, John> RSA, and ECC, I believe that these are valid. There will always John> be some disention around the edges, but isn't it better to use John> the yardstick that the overwhelming majority of the community John> agree upon? What yardstick are you talking about? Any decent cipher will have strength (i.e., best known published attack) equal to brute force search, or nearly that. Given an adequate key size (i.e., not DES) that will do the job. I suppose you could argue, then, that requests for any supported block cipher of key length x and blocksize y should be interchangeable. Is that what you're suggesting? My point was that I don't know of "overwhelming majority" consensus saying that IDEA is stronger than Blowfish for the same key size, or vice versa. The same, only more so, applies to ECC vs. RSA/DSA -- there, proponents of the various schemes argue long and vociferously about the computational complexity of the various attacks. In particular, as a disinterested bystander I don't see "overwhelming majority" consensus that the math/crypto community understanding of best possible attacks for ECC is at a similar level of confidence as it is for RSA/DSA. This is why I commented that there does not exist a "well documented ordering of strength" across these systems. paul John> Paul Koning on 05.06.2000 07:29:01 John> To: John Harleman/Certicom@Certicom cc: John> dharkins@cips.nokia.com, ipsec@lists.tislabs.com Subject: Re: John> Interoperability (was: Death to AH?) >>>>> "John" == John Harleman writes: John> There is no order, but there is a well documented strength even John> between differnent crypto systems. If you accept Dan's approach John> to variable key-length ciphers, why wouldn't you accpet it for John> variable key length public-key algorithms? > I assume you meant that there is "a well documented ordering of > strength for the different systems". > If so, I would disagree. Certainly people have voiced the > opinion that ECC with an x bit key is as strong as RSA with a y > bit key. But others have voiced different opinions. > Similarly, you may be able to find opinions on the relative > strength of, say, IDEA, 3DES, and Blowfish, but I don't think > you will find consensus. From owner-ipsec@lists.tislabs.com Thu Jun 8 09:48:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02419; Thu, 8 Jun 2000 09:48:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08210 Thu, 8 Jun 2000 11:29:17 -0400 (EDT) Message-Id: <200006081422.HAA26941@potassium.network-alchemy.com> To: Paul Koning cc: skelly@redcreek.com, ipsec@lists.tislabs.com Subject: Re: Interoperability (was: Death to AH?) In-reply-to: Your message of "Mon, 05 Jun 2000 14:02:50 EDT." <14651.60234.896260.377030@xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26938.960474127.1@network-alchemy.com> Date: Thu, 08 Jun 2000 07:22:07 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I wasn't proposing to accept 3des when configured for des, that's a simple == or != issue, what I was proposing is some guidelines for those variables that aren't simple == or !=, those that can be >, <, >= or <= like keylength or lifetime. Diffie-Hellman groups got added on but they seem to be a simple == or != issue too. Dan. On Mon, 05 Jun 2000 14:02:50 EDT you wrote > >>>>> "Scott" == Scott G Kelly writes: > > Scott> Paul Koning wrote: > >> >>>>> "Dan" == Dan Harkins writes: > Dan> Quite a while ago I attempted to define an approach to deal with > Dan> things like lifetimes and key lengths and other attributes that > Dan> do not have a simple boolean acceptance criteria and > Dan> failed. There was no consensus. But I'm willing to try again: > >> > Dan> If someone offers you a keylength for a variable-keylenght > Dan> cipher which is greater than or equal to what you have > Dan> configured, accept it. If it's less reject it. > > >> I'd support that. > > Scott> I argued this point at length with Dan around a year ago (or > Scott> so). My original position was that we shouldn't write the ike > Scott> standard such that the admin could not control whether this > Scott> occurred or not. Dan argued that In the case of Blowfish, it > Scott> requires no more work to use a longer key than a shorter > Scott> one. We never finished the debate. I think I agree with Dan > Scott> when it comes to crypto algorithms like Blowfish, i.e. when > Scott> increasing the key length does not affect the load on the > Scott> machine. On the other hand, I'm not sure that increasing to > Scott> 3des when des is configured is the right thing to do, though > Scott> I'm willing to consider other points of view. > > Scott> I think there is a definite issue with DH values though: if I > Scott> am configured to accept group 2, sending me group 5 most > Scott> definitely affects my work load in a significant way. This has > Scott> DoS implications. That being the case, it might be better to > Scott> make this a local decision. > > Fair enough. And for some implementations the same would be true for > DES vs. 3DES (while for others it would not be -- if you have a > hardware assist that's bus or network bound, for example). > > Is the only problem one of specifying that this "allow upgrading to > stronger ciphers" may be enabled or disabled as a policy matter if the > implementation wishes to do that? If so, that sounds entirely > reasonable to me. The impression I got from Dan's comment is that > there was some opposition to the entire notion, which is harder to > understand. > > Right now there's no text at all that describes this stuff. I suppose > you could argue that it's a local matter -- people are allowed to do > this if they feel like it. Probably so... but it seems useful to make > it a recommended practice subject to some caveats about possible > performance issues in at least some of the cases. > > paul > > PS. Dan, your return address is not working... email to it keeps > bouncing. -- John C. Kelley Computer Scientist NAILabs at Network Associates, Inc. Glenwood, MD From owner-ipsec@lists.tislabs.com Thu Jun 8 10:45:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03537; Thu, 8 Jun 2000 10:45:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08521 Thu, 8 Jun 2000 12:29:43 -0400 (EDT) Message-ID: <393FCBAD.8D4E2930@redcreek.com> Date: Thu, 08 Jun 2000 09:37:01 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Paul Koning , ipsec@lists.tislabs.com Subject: Re: Interoperability (was: Death to AH?) References: <200006081422.HAA26941@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, Dan Harkins wrote: > > I wasn't proposing to accept 3des when configured for des, that's > a simple == or != issue, what I was proposing is some guidelines > for those variables that aren't simple == or !=, those that can > be >, <, >= or <= like keylength or lifetime. Diffie-Hellman > groups got added on but they seem to be a simple == or != > issue too. > > Dan. Sorry for the misunderstanding. I agree that guidelines for variable keylengths and lifetimes would be useful. Scott From owner-ipsec@lists.tislabs.com Thu Jun 8 11:22:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04124; Thu, 8 Jun 2000 11:22:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08634 Thu, 8 Jun 2000 13:11:49 -0400 (EDT) Date: Thu, 8 Jun 2000 12:19:59 -0500 From: Will Fiveash To: IETF IPsec Subject: RESPONDER-LIFETIME Notify question Message-ID: <20000608121959.A57732@austin.ibm.com> Mail-Followup-To: IETF IPsec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let's say as an initiator my code receives a notify RESPONDER-LIFETIME in the second Quick Mode message and the life duration isn't allowed by the local security policy. Currently my code will delete the Phase 2 SA and send a SA delete notify to the remote system. Do I need to send some sort of notify to tell the other side why I deleted the SA? -- Will Fiveash IBM AIX System Development (IPsec/IKE) From owner-ipsec@lists.tislabs.com Thu Jun 8 12:33:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05436; Thu, 8 Jun 2000 12:33:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08828 Thu, 8 Jun 2000 13:57:45 -0400 (EDT) Message-ID: <393FE04E.D41A8FE5@redcreek.com> Date: Thu, 08 Jun 2000 11:05:02 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Will Fiveash CC: IETF IPsec Subject: Re: RESPONDER-LIFETIME Notify question References: <20000608121959.A57732@austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Will, Will Fiveash wrote: > > Let's say as an initiator my code receives a notify RESPONDER-LIFETIME in > the second Quick Mode message and the life duration isn't allowed by the > local security policy. Currently my code will delete the Phase 2 SA and > send a SA delete notify to the remote system. Do I need to send some sort > of notify to tell the other side why I deleted the SA? > > -- > Will Fiveash > IBM AIX System Development (IPsec/IKE) The current notify message draft suggests sending ATTRIBUTES-NOT-SUPPORTED in this case. Scott From owner-ipsec@lists.tislabs.com Fri Jun 9 12:18:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05034; Fri, 9 Jun 2000 12:18:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13206 Fri, 9 Jun 2000 13:51:04 -0400 (EDT) Message-ID: <39411911.7ABF1FDE@rd.francetelecom.fr> Date: Fri, 09 Jun 2000 18:19:29 +0200 From: Jean-Michel COMBES X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: Mohan Parthasarathy CC: Michael Thomas , "Steven M. Bellovin" , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Death to AH? (was: Reasons for AH & ESP ) References: <200006051615.e55GFGQ11378@locked.eng.sun.com> Content-Type: multipart/alternative; boundary="------------26BA77B86994EEFF2006A642" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------26BA77B86994EEFF2006A642 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, the main reason why the Home Address option cannot follow rather than precede an ESP header is that the HA option contains the Mobile Node's home address which is used to perform IP filtering. So, we have : IPv6 header Hop-by-Hop Options header Destination Options header (with HA option) Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header (*) upper-layer header (*) - HA option is covered by AH - (*) is encrypted by ESP Regards. Mohan Parthasarathy a �crit : > > Mohan Parthasarathy writes: > > > Mobile IPv6 has introduced new IPv6 destination options which requires > > > the use of AH. Section 4.4 of draft-ietf-mobileip-ipv6-12.txt > > > explains the IPsec requirements. (June 8th is the deadline for > > > any comments. It is to become a proposed standard). It specifically > > > says ESP can't be used. > > > > Is there any particular reason why the binding cache > > update messages in the destination options cannot > > follow rather than precede an ESP header? It doesn't > > look to me like there is any reason to keep destination > > options in the clear, in which case ESP would work > > fine. > > > Binding update messages itself can appear after AH/ESP header. > But when used with HOME address option it should appear > before. Earlier revision of this draft had the home address option > after AH/ESP header. I don't know what made them change to put before > the AH/ESP header. Something relevant to this can be seen > in the following discussion of the ipng archives : > > http://www.wcug.wwu.edu/lists/ipng/199906/msg00042.html > > But still one could argue that AH still protects the CoA present > in the IPv6 header's source address field. (This can still be > overcome by using yet another "alternate-care-of-address" option. > This is not a MUST/SHOULD in the draft). Why is it that the > protection offered by AH to the IPv6 header's source address > field is not important ? At least i can see it useful in > this case. > > -mohan -- France Telecom R&D - DTL/SSR COMBES Jean-Michel, Internet/Intranet Security E-Mail : jeanmichel.combes@rd.francetelecom.fr Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 --------------26BA77B86994EEFF2006A642 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, the main reason why the Home Address option cannot follow rather than precede an ESP header is that the HA option contains the Mobile Node's home address which is used to perform IP filtering. So, we have : IPv6 header Hop-by-Hop Options header Destination Options header (with HA option) Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header (*) upper-layer header (*) - HA option is covered by AH - (*) is encrypted by ESP Regards. Mohan Parthasarathy a �crit : > > Mohan Parthasarathy writes: > > > Mobile IPv6 has introduced new IPv6 destination options which requires > > > the use of AH. Section 4.4 of draft-ietf-mobileip-ipv6-12.txt > > > explains the IPsec requirements. (June 8th is the deadline for > > > any comments. It is to become a proposed standard). It specifically > > > says ESP can't be used. > > > > Is there any particular reason why the binding cache > > update messages in the destination options cannot > > follow rather than precede an ESP header? It doesn't > > look to me like there is any reason to keep destination > > options in the clear, in which case ESP would work > > fine. > > >Binding update messages itself can appear after AH/ESP header. >But when used with HOME address option it should appear >before. Earlier revision of this draft had the home address option >after AH/ESP header. I don't know what made them change to put before >the AH/ESP header. Something relevant to this can be seen >in the following discussion of the ipng archives : > >http://www.wcug.wwu.edu/lists/ipng/199906/msg00042.html > >But still one could argue that AH still protects the CoA present >in the IPv6 header's source address field. (This can still be >overcome by using yet another "alternate-care-of-address" option. >This is not a MUST/SHOULD in the draft). Why is it that the >protection offered by AH to the IPv6 header's source address >field is not important ? At least i can see it useful in >this case. > >-mohan -- France Telecom R&D - DTL/SSR COMBES Jean-Michel, Internet/Intranet Security E-Mail : jeanmichel.combes@rd.francetelecom.fr Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 --------------26BA77B86994EEFF2006A642-- From owner-ipsec@lists.tislabs.com Tue Jun 13 07:23:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20120; Tue, 13 Jun 2000 07:23:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25156 Tue, 13 Jun 2000 08:55:56 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "=?gb2312?B?1tzV/g==?=" Cc: ipsec@lists.tislabs.com Subject: Re: Replay problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 09:00:41 -0400 Message-Id: <20000613130057.4A6D835DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <003601bfd502$ef251920$8a010b0a@zhouzheng.huawei.com.cn>, "=?gb2312? B?1tzV/g==?=" writes: > > In IPSEC, replay protection is privided by a Sequence Number Counter = >and a anti-replay window. But it cause some problem in current = >implementations according to RFC 2401 Appendix C. When attcker seizes a = >IPSec flow, the IP address, SPI are known, and then he can send the = >forge IP packets to the desination, which Sequence Number may be very = >lage, just simple as 2^32.=20 > In the case of using ESP without authentication, after received the = >forge packet, the anti-replay window of the SA will wrong slide to the = >last, causing deny receive most packets, otherwise rebuild the SA. This = >is a serious problem. > In other case, the desination receive the forge packet, need = >authenticate. When the attacter sends large forge packets, the = >destination may be denial of sevice becasue of it's performance is = >exhausted. Since the forge packet is discarded after it be = >authenticated. > How to slove this problem?=20 > If we receive a new IPSEC packet which sequence number is much larger = >than the last packet's, such as 128 or other specified number, we will = >consider it's a forge packet and discard it, otherwise slide the window = >simply. And it can aviod the DoS attack in large degree. The proper answer is to use authentication. That prevents even more serious attacks; see http://www.research.att.com/~smb/papers/badesp.ps (or .pdf). --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Jun 13 07:25:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20178; Tue, 13 Jun 2000 07:25:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24988 Tue, 13 Jun 2000 08:19:53 -0400 (EDT) Message-ID: <003601bfd502$ef251920$8a010b0a@zhouzheng.huawei.com.cn> From: "=?gb2312?B?1tzV/g==?=" To: Subject: Replay problem Date: Tue, 13 Jun 2000 14:45:16 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01BFD545.FD15FE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0033_01BFD545.FD15FE80 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable In IPSEC, replay protection is privided by a Sequence Number Counter = and a anti-replay window. But it cause some problem in current = implementations according to RFC 2401 Appendix C. When attcker seizes a = IPSec flow, the IP address, SPI are known, and then he can send the = forge IP packets to the desination, which Sequence Number may be very = lage, just simple as 2^32.=20 In the case of using ESP without authentication, after received the = forge packet, the anti-replay window of the SA will wrong slide to the = last, causing deny receive most packets, otherwise rebuild the SA. This = is a serious problem. In other case, the desination receive the forge packet, need = authenticate. When the attacter sends large forge packets, the = destination may be denial of sevice becasue of it's performance is = exhausted. Since the forge packet is discarded after it be = authenticated. How to slove this problem?=20 If we receive a new IPSEC packet which sequence number is much larger = than the last packet's, such as 128 or other specified number, we will = consider it's a forge packet and discard it, otherwise slide the window = simply. And it can aviod the DoS attack in large degree. ------=_NextPart_000_0033_01BFD545.FD15FE80 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

In IPSEC, replay = protection=20 is privided by a Sequence Number Counter and a anti-replay window. But = it cause=20 some problem in current implementations according to RFC 2401 Appendix = C.=20 When attcker seizes a IPSec flow, = the IP=20 address, SPI are known, and then he can send the forge IP packets to the = desination, which Sequence Number may be very lage, just simple as 2^32. =

In the case of = using ESP=20 without authentication, after received the forge packet, the anti-replay = window=20 of the SA will wrong slide to the last, causing deny receive most = packets,=20 otherwise rebuild the SA. This is a serious problem.

In other case, = the desination=20 receive the forge packet, need authenticate. When the attacter sends = large forge=20 packets, the destination may be denial of sevice becasue of it's = performance is=20 exhausted. Since the forge packet is discarded after it be=20 authenticated.

How to slove this = problem?=20

If we receive a new = IPSEC packet=20 which sequence number is much larger than the last packet's, such as 128 = or=20 other specified number, we will consider it's a forge packet and discard = it,=20 otherwise slide the window simply. And it can aviod the DoS attack in = large=20 degree.

------=_NextPart_000_0033_01BFD545.FD15FE80-- From owner-ipsec@lists.tislabs.com Tue Jun 13 08:05:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21429; Tue, 13 Jun 2000 08:05:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25530 Tue, 13 Jun 2000 09:54:26 -0400 (EDT) Message-ID: <714BE32F82EED211B9CA0008C7C5A4DA0313D872@zuk28exm01.ecid.cig.mot.com> From: Shi Rong-rongshi1 To: "'Steven M. Bellovin'" , ?? Cc: ipsec@lists.tislabs.com Subject: RE: Replay problem Date: Tue, 13 Jun 2000 15:01:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Steve, I noticed the discussion last year about loosing anti-replay protection in IPsec in case of manually SA management. Are there any changes in specificationsince then to address the issue of preserving anti-replay protection while using manaul SA mgmt? Regards, Rong From owner-ipsec@lists.tislabs.com Tue Jun 13 08:06:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21472; Tue, 13 Jun 2000 08:06:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25497 Tue, 13 Jun 2000 09:46:37 -0400 (EDT) To: itojun@iijlab.net Cc: ipsec@lists.tislabs.com Subject: Re: AH padding after MD5/SHA1 hash value In-Reply-To: Your message of "Tue, 13 Jun 2000 22:42:33 +0900" <29940.960903753@lychee.itojun.org> References: <29940.960903753@lychee.itojun.org> X-Mailer: Cue version 0.6 (000609-1000/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20000613225623I.sakane@ydc.co.jp> Date: Tue, 13 Jun 2000 22:56:23 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From what I understand from the wording in RFC240[234], > - for sender side, it is not illegal to attach more than 96 bits > into authentication data field. RFC2403 does not require us to > attach exactly 96bits. It just say "truncated value using the > first 96 bits MUST be supported". It is not clear to us whether > 96bit truncation is the requirement, or not. > This seems odd while we call those AH algorithms as "HMAC-MD5-96". > If we do not require truncation to 96bits, why we call it "96"? There is the reason at the section 5 in RFC2104, but it doesn't mentioned strongly. From owner-ipsec@lists.tislabs.com Tue Jun 13 08:17:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22214; Tue, 13 Jun 2000 08:17:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25591 Tue, 13 Jun 2000 10:05:30 -0400 (EDT) To: "Shoichi 'Ne' Sakane" cc: ipsec@lists.tislabs.com In-reply-to: sakane's message of Tue, 13 Jun 2000 22:56:23 JST. <20000613225623I.sakane@ydc.co.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: AH padding after MD5/SHA1 hash value From: itojun@iijlab.net Date: Tue, 13 Jun 2000 23:13:48 +0900 Message-ID: <22083.960905628@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> From what I understand from the wording in RFC240[234], >> - for sender side, it is not illegal to attach more than 96 bits >> into authentication data field. RFC2403 does not require us to >> attach exactly 96bits. It just say "truncated value using the >> first 96 bits MUST be supported". It is not clear to us whether >> 96bit truncation is the requirement, or not. >> This seems odd while we call those AH algorithms as "HMAC-MD5-96". >> If we do not require truncation to 96bits, why we call it "96"? >There is the reason at the section 5 in RFC2104, but it doesn't mentioned >strongly. it seems to me that RFC2104 section 5 gives us why it is secure even if we truncate. my question is opposite - why do we make the truncate optional, and I believe it's better to make the truncation mandatory. itojun From owner-ipsec@lists.tislabs.com Tue Jun 13 08:48:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24527; Tue, 13 Jun 2000 08:48:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25629 Tue, 13 Jun 2000 10:17:52 -0400 (EDT) To: ipsec@lists.tislabs.com cc: sakane@kame.net X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: AH padding after MD5/SHA1 hash value From: Jun-ichiro itojun Hagino Date: Tue, 13 Jun 2000 22:42:33 +0900 Message-ID: <29940.960903753@lychee.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Correct me if I'm wrong. I have a question about AH packet. From what I understand from the wording in RFC240[234], - for sender side, it is not illegal to attach more than 96 bits into authentication data field. RFC2403 does not require us to attach exactly 96bits. It just say "truncated value using the first 96 bits MUST be supported". It is not clear to us whether 96bit truncation is the requirement, or not. This seems odd while we call those AH algorithms as "HMAC-MD5-96". If we do not require truncation to 96bits, why we call it "96"? - Due to the way the document is written, receiver side will not notice even if the peer attaches more meat than 96 bits. Inbound check is done like this: (1) compute 128bit(MD5) or 160bit(SHA1) hash (2) compare first 96bit with authentication data field the receiving side will notice it only if it is picky about the length of AH portion length. We (KAME) have never noticed this during past interop events, since we only generate 96bit authentication data, and we do not care about too-long authentication data (we do reject too-short authentication data). We noticed that a MAJOR implementation attach the whole 160bits for HMAC-SHA1, and 128bit + 32bit padding for HMAC-MD5. Now. Why the document is written this way? If my understanding is correct, (1) we allow junk data to be attached at the end of authentication data, and (2) we have no real requirement to check if the junk data is rewritten or not. Even if man-in-the-middle rewrites junk data portion, we will never notice, and data exchange should go just fine. But, this worries me. Is it specwise okay if we reject any packet with longer-than-96bit authentication data? I know that we will not be able to interop with the particular implementation mentioned above. I hope more clarification to appear in the document. itojun RFC2402 chapter 2: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Payload Len | RESERVED | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Security Parameters Index (SPI) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number Field | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Authentication Data (variable) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC2403 chapter 2: > HMAC-MD5-96 produces a 128-bit authenticator value. This 128-bit > value can be truncated as described in RFC 2104. For use with either > ESP or AH, a truncated value using the first 96 bits MUST be <--- > supported. Upon sending, the truncated value is stored within the <--- > authenticator field. Upon receipt, the entire 128-bit value is > computed and the first 96 bits are compared to the value stored in > the authenticator field. No other authenticator value lengths are > supported by HMAC-MD5-96. From owner-ipsec@lists.tislabs.com Tue Jun 13 09:06:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25752; Tue, 13 Jun 2000 09:06:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25781 Tue, 13 Jun 2000 10:39:51 -0400 (EDT) From: pjkirner@tril-inc.com To: ZhouZh@huawei.com.cn Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: Replay problem X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Tue, 13 Jun 2000 10:49:37 -0400 X-MIMETrack: Serialize by Router on lntril01/Servers/Trilogy(Release 5.0.3 (Intl)|21 March 2000) at 06/13/2000 10:50:32 AM, Serialize complete at 06/13/2000 10:50:32 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0051231C852568FD_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 0051231C852568FD_= Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Tm90IG9ubHkgd2lsbCBhdXRoZW50aWNhdGlvbiBzb2x2ZSB0aGUgcHJvYmxlbSBhcyBTdGV2ZW4g YWxyZWFkeSBoYXMgDQppbmRpY2F0ZWQsIGJ1dCAgUkZDIDI0MDYgcmVxdWlyZXMgYXV0aGVudGlj YXRpb24gdG8gYmUgZW5hYmxlZCBpZiANCmFudGktcmVwbGF5IGlzIHR1cm5lZCBvbi4NCg0KICJU aGUgYW50aS1yZXBsYXkgc2VydmljZSBtYXkgYmUgc2VsZWN0ZWQgb25seSBpZiBkYXRhIG9yaWdp biANCmF1dGhlbnRpY2F0aW9uIGlzIHNlbGVjdGVkLCBhbmQgaXRzIGVsZWN0aW9uIGlzIHNvbGVs eSBhdCB0aGUgZGlzY3JldGlvbiANCm9mIHRoZSByZWNlaXZlci4iDQoNClBKIEtpcm5lcg0KVHJp bG9neSwgSW5jLg0KDQoNCg0KDQoNCiLW3NX+IiA8WmhvdVpoQGh1YXdlaS5jb20uY24+DQpTZW50 IGJ5OiBvd25lci1pcHNlY0BsaXN0cy50aXNsYWJzLmNvbQ0KMDYvMTMvMDAgMDI6NDUgQU0NCg0K IA0KICAgICAgICBUbzogICAgIDxpcHNlY0BsaXN0cy50aXNsYWJzLmNvbT4NCiAgICAgICAgY2M6 IA0KICAgICAgICBTdWJqZWN0OiAgICAgICAgUmVwbGF5IHByb2JsZW0NCg0KICAgIEluIElQU0VD LCByZXBsYXkgcHJvdGVjdGlvbiBpcyBwcml2aWRlZCBieSBhIFNlcXVlbmNlIE51bWJlciBDb3Vu dGVyIA0KYW5kIGEgYW50aS1yZXBsYXkgd2luZG93LiBCdXQgaXQgY2F1c2Ugc29tZSBwcm9ibGVt IGluIGN1cnJlbnQgDQppbXBsZW1lbnRhdGlvbnMgYWNjb3JkaW5nIHRvIFJGQyAyNDAxIEFwcGVu ZGl4IEMuIFdoZW4gYXR0Y2tlciBzZWl6ZXMgYSANCklQU2VjIGZsb3csIHRoZSBJUCBhZGRyZXNz LCBTUEkgYXJlIGtub3duLCBhbmQgdGhlbiBoZSBjYW4gc2VuZCB0aGUgZm9yZ2UgDQpJUCBwYWNr ZXRzIHRvIHRoZSBkZXNpbmF0aW9uLCB3aGljaCBTZXF1ZW5jZSBOdW1iZXIgbWF5IGJlIHZlcnkg bGFnZSwganVzdCANCnNpbXBsZSBhcyAyXjMyLiANCiAgICBJbiB0aGUgY2FzZSBvZiB1c2luZyBF U1Agd2l0aG91dCBhdXRoZW50aWNhdGlvbiwgYWZ0ZXIgcmVjZWl2ZWQgdGhlIA0KZm9yZ2UgcGFj a2V0LCB0aGUgYW50aS1yZXBsYXkgd2luZG93IG9mIHRoZSBTQSB3aWxsIHdyb25nIHNsaWRlIHRv IHRoZSANCmxhc3QsIGNhdXNpbmcgZGVueSByZWNlaXZlIG1vc3QgcGFja2V0cywgb3RoZXJ3aXNl IHJlYnVpbGQgdGhlIFNBLiBUaGlzIGlzIA0KYSBzZXJpb3VzIHByb2JsZW0uDQogICAgSW4gb3Ro ZXIgY2FzZSwgdGhlIGRlc2luYXRpb24gcmVjZWl2ZSB0aGUgZm9yZ2UgcGFja2V0LCBuZWVkIA0K YXV0aGVudGljYXRlLiBXaGVuIHRoZSBhdHRhY3RlciBzZW5kcyBsYXJnZSBmb3JnZSBwYWNrZXRz LCB0aGUgZGVzdGluYXRpb24gDQptYXkgYmUgZGVuaWFsIG9mIHNldmljZSBiZWNhc3VlIG9mIGl0 J3MgcGVyZm9ybWFuY2UgaXMgZXhoYXVzdGVkLiBTaW5jZSANCnRoZSBmb3JnZSBwYWNrZXQgaXMg ZGlzY2FyZGVkIGFmdGVyIGl0IGJlIGF1dGhlbnRpY2F0ZWQuDQogICBIb3cgdG8gc2xvdmUgdGhp cyBwcm9ibGVtPyANCiAgIElmIHdlIHJlY2VpdmUgYSBuZXcgSVBTRUMgcGFja2V0IHdoaWNoIHNl cXVlbmNlIG51bWJlciBpcyBtdWNoIGxhcmdlciANCnRoYW4gdGhlIGxhc3QgcGFja2V0J3MsIHN1 Y2ggYXMgMTI4IG9yIG90aGVyIHNwZWNpZmllZCBudW1iZXIsIHdlIHdpbGwgDQpjb25zaWRlciBp dCdzIGEgZm9yZ2UgcGFja2V0IGFuZCBkaXNjYXJkIGl0LCBvdGhlcndpc2Ugc2xpZGUgdGhlIHdp bmRvdyANCnNpbXBseS4gQW5kIGl0IGNhbiBhdmlvZCB0aGUgRG9TIGF0dGFjayBpbiBsYXJnZSBk ZWdyZWUuDQoNCg0K --=_alternative 0051231C852568FD_= Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk5vdCBvbmx5IHdpbGwgYXV0aGVu dGljYXRpb24gc29sdmUgdGhlIHByb2JsZW0gYXMgU3RldmVuIGFscmVhZHkgaGFzIGluZGljYXRl ZCwgYnV0ICZuYnNwO1JGQyAyNDA2IHJlcXVpcmVzIGF1dGhlbnRpY2F0aW9uIHRvIGJlIGVuYWJs ZWQgaWYgYW50aS1yZXBsYXkgaXMgdHVybmVkIG9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7JnF1b3Q7VGhlIGFudGktcmVwbGF5IHNlcnZp Y2UgbWF5IGJlIHNlbGVjdGVkIG9ubHkgaWYgZGF0YSBvcmlnaW4gYXV0aGVudGljYXRpb24gaXMg c2VsZWN0ZWQsIGFuZCBpdHMgZWxlY3Rpb24gaXMgc29sZWx5IGF0IHRoZSBkaXNjcmV0aW9uIG9m IHRoZSByZWNlaXZlci4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlBKIEtpcm5lcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+VHJpbG9neSwgSW5jLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O9bc1f4mcXVvdDsgJmx0O1pob3VaaEBodWF3ZWku Y29tLmNuJmd0OzwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlNlbnQgYnk6IG93bmVyLWlwc2VjQGxpc3RzLnRpc2xhYnMuY29tPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjA2LzEzLzAwIDAyOjQ1IEFNPC9mb250Pg0KPGJyPg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aXBzZWNA bGlzdHMudGlzbGFicy5jb20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2M6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YmplY3Q6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1JlcGxheSBwcm9ibGVtPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7IEluIElQU0VDLCByZXBsYXkgcHJvdGVjdGlvbiBp cyBwcml2aWRlZCBieSBhIFNlcXVlbmNlIE51bWJlciBDb3VudGVyIGFuZCBhIGFudGktcmVwbGF5 IHdpbmRvdy4gQnV0IGl0IGNhdXNlIHNvbWUgcHJvYmxlbSBpbiBjdXJyZW50IGltcGxlbWVudGF0 aW9ucyBhY2NvcmRpbmcgdG8gUkZDIDI0MDEgQXBwZW5kaXggQy4gV2hlbiBhdHRja2VyIHNlaXpl cyBhIElQU2VjIGZsb3csIHRoZSBJUCBhZGRyZXNzLCBTUEkgYXJlIGtub3duLCBhbmQgdGhlbiBo ZSBjYW4gc2VuZCB0aGUgZm9yZ2UgSVAgcGFja2V0cyB0byB0aGUgZGVzaW5hdGlvbiwgd2hpY2gg U2VxdWVuY2UgTnVtYmVyIG1heSBiZSB2ZXJ5IGxhZ2UsIGp1c3Qgc2ltcGxlIGFzIDJeMzIuIDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgSW4gdGhl IGNhc2Ugb2YgdXNpbmcgRVNQIHdpdGhvdXQgYXV0aGVudGljYXRpb24sIGFmdGVyIHJlY2VpdmVk IHRoZSBmb3JnZSBwYWNrZXQsIHRoZSBhbnRpLXJlcGxheSB3aW5kb3cgb2YgdGhlIFNBIHdpbGwg d3Jvbmcgc2xpZGUgdG8gdGhlIGxhc3QsIGNhdXNpbmcgZGVueSByZWNlaXZlIG1vc3QgcGFja2V0 cywgb3RoZXJ3aXNlIHJlYnVpbGQgdGhlIFNBLiBUaGlzIGlzIGEgc2VyaW91cyBwcm9ibGVtLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgSW4gb3Ro ZXIgY2FzZSwgdGhlIGRlc2luYXRpb24gcmVjZWl2ZSB0aGUgZm9yZ2UgcGFja2V0LCBuZWVkIGF1 dGhlbnRpY2F0ZS4gV2hlbiB0aGUgYXR0YWN0ZXIgc2VuZHMgbGFyZ2UgZm9yZ2UgcGFja2V0cywg dGhlIGRlc3RpbmF0aW9uIG1heSBiZSBkZW5pYWwgb2Ygc2V2aWNlIGJlY2FzdWUgb2YgaXQncyBw ZXJmb3JtYW5jZSBpcyBleGhhdXN0ZWQuIFNpbmNlIHRoZSBmb3JnZSBwYWNrZXQgaXMgZGlzY2Fy ZGVkIGFmdGVyIGl0IGJlIGF1dGhlbnRpY2F0ZWQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwO0hvdyB0byBzbG92ZSB0aGlzIHByb2JsZW0/IDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDtJZiB3ZSByZWNl aXZlIGEgbmV3IElQU0VDIHBhY2tldCB3aGljaCBzZXF1ZW5jZSBudW1iZXIgaXMgbXVjaCBsYXJn ZXIgdGhhbiB0aGUgbGFzdCBwYWNrZXQncywgc3VjaCBhcyAxMjggb3Igb3RoZXIgc3BlY2lmaWVk IG51bWJlciwgd2Ugd2lsbCBjb25zaWRlciBpdCdzIGEgZm9yZ2UgcGFja2V0IGFuZCBkaXNjYXJk IGl0LCBvdGhlcndpc2Ugc2xpZGUgdGhlIHdpbmRvdyBzaW1wbHkuIEFuZCBpdCBjYW4gYXZpb2Qg dGhlIERvUyBhdHRhY2sgaW4gbGFyZ2UgZGVncmVlLjwvZm9udD4NCjxicj4NCjxicj4NCg== --=_alternative 0051231C852568FD_=-- From owner-ipsec@lists.tislabs.com Tue Jun 13 09:36:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28342; Tue, 13 Jun 2000 09:36:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25987 Tue, 13 Jun 2000 11:17:24 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14662.20847.89186.713858@xedia.com> Date: Tue, 13 Jun 2000 11:21:19 -0400 (EDT) To: ZhouZh@huawei.com.cn Cc: ipsec@lists.tislabs.com Subject: Re: Replay problem References: <003601bfd502$ef251920$8a010b0a@zhouzheng.huawei.com.cn> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In IPSEC, replay protection is privided by a Sequence Number Counter > and a anti-replay window. But it cause some problem in current > implementations according to RFC 2401 Appendix C. When attcker seizes a > IPSec flow, the IP address, SPI are known, and then he can send the > forge IP packets to the desination, which Sequence Number may be very > lage, just simple as 2^32. > > In the case of using ESP without authentication, after received the > forge packet, the anti-replay window of the SA will wrong slide to the > last, causing deny receive most packets, otherwise rebuild the SA. This > is a serious problem. If you do not use authentication, then anti-replay checking is not done. As you have shown, it would not serve any purpose to do it. Unfortunately, ESP without authentication remains an allowed feature of ESP. It is wise to avoid it, though. paul From owner-ipsec@lists.tislabs.com Tue Jun 13 09:58:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29289; Tue, 13 Jun 2000 09:58:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26089 Tue, 13 Jun 2000 11:27:53 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Shi Rong-rongshi1 Cc: ?? , ipsec@lists.tislabs.com Subject: Re: Replay problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 11:33:49 -0400 Message-Id: <20000613153404.A047935DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <714BE32F82EED211B9CA0008C7C5A4DA0313D872@zuk28exm01.ecid.cig.mot.co m>, Shi Rong-rongshi1 writes: >Dear Steve, > >I noticed the discussion last year about loosing anti-replay protection in >IPsec in case of manually SA management. Are there any changes in >specificationsince then to address the issue of preserving anti-replay >protection while using manaul SA mgmt? > >Regards, > >Rong > No. The problem is that if a machine loses state (say, due to a reboot), it would restart the sequence space, allowing replays. There's also the issue of how to handle wrap-around. --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Jun 13 11:20:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00675; Tue, 13 Jun 2000 11:20:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26352 Tue, 13 Jun 2000 12:05:38 -0400 (EDT) Date: Tue, 13 Jun 2000 18:13:54 +0200 (METDST) From: Bart Preneel To: Jun-ichiro itojun Hagino cc: ipsec@lists.tislabs.com, sakane@kame.net Subject: Re: AH padding after MD5/SHA1 hash value In-Reply-To: <29940.960903753@lychee.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just want to point out that the 96 bits was chosen as a compromise (m = number of bits in the MAC, n is the number of bit of the hash): - increasing m makes a guessing attack more difficult (success probability of forgery is 2*{-m}) - decreasing m makes a birthday attack (based on internal collisions) more difficult (complexity of forgery is 2*{n/2} known text-MAC pairs and 2*{n-m} chosen text/MAC pairs). - m=96 has the advantage that it provides alignment. It is hard to compare two different attacks. And collecting 2**{64} known text/MAC pairs is far from feasible today. Nevertheless, one can learn from this that - paradoxically - increasing m may reduce security (the intuition behind this is that one gives away more information). Especially in the case of MD5, I would advise against increasing m beyond 96. For details: B. Preneel, P.C. van Oorschot, "On the security of iterated Message Authentication Codes," IEEE Transactions on Information Theory, Vol. 45, No. 1, January 1999, pp. 188--199 (journal version of our Crypto'95 paper). --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 http://www.esat.kuleuven.ac.be/~preneel ------------------------------------------------------------------------------- On Tue, 13 Jun 2000, Jun-ichiro itojun Hagino wrote: > > Correct me if I'm wrong. I have a question about AH packet. > > From what I understand from the wording in RFC240[234], > - for sender side, it is not illegal to attach more than 96 bits > into authentication data field. RFC2403 does not require us to > attach exactly 96bits. It just say "truncated value using the > first 96 bits MUST be supported". It is not clear to us whether > 96bit truncation is the requirement, or not. > This seems odd while we call those AH algorithms as "HMAC-MD5-96". > If we do not require truncation to 96bits, why we call it "96"? > - Due to the way the document is written, receiver side will not > notice even if the peer attaches more meat than 96 bits. > Inbound check is done like this: > (1) compute 128bit(MD5) or 160bit(SHA1) hash > (2) compare first 96bit with authentication data field > the receiving side will notice it only if it is picky about the > length of AH portion length. > > We (KAME) have never noticed this during past interop events, since > we only generate 96bit authentication data, and we do not care about > too-long authentication data (we do reject too-short authentication > data). We noticed that a MAJOR implementation attach the whole > 160bits for HMAC-SHA1, and 128bit + 32bit padding for HMAC-MD5. > > Now. Why the document is written this way? If my understanding is > correct, (1) we allow junk data to be attached at the end of > authentication data, and (2) we have no real requirement to check > if the junk data is rewritten or not. Even if man-in-the-middle > rewrites junk data portion, we will never notice, and data exchange > should go just fine. But, this worries me. > > Is it specwise okay if we reject any packet with longer-than-96bit > authentication data? I know that we will not be able to interop > with the particular implementation mentioned above. I hope more > clarification to appear in the document. > > itojun > > > RFC2402 chapter 2: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Next Header | Payload Len | RESERVED | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Security Parameters Index (SPI) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence Number Field | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + Authentication Data (variable) | > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > RFC2403 chapter 2: > > HMAC-MD5-96 produces a 128-bit authenticator value. This 128-bit > > value can be truncated as described in RFC 2104. For use with either > > ESP or AH, a truncated value using the first 96 bits MUST be <--- > > supported. Upon sending, the truncated value is stored within the <--- > > authenticator field. Upon receipt, the entire 128-bit value is > > computed and the first 96 bits are compared to the value stored in > > the authenticator field. No other authenticator value lengths are > > supported by HMAC-MD5-96. > From owner-ipsec@lists.tislabs.com Tue Jun 13 12:05:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01478; Tue, 13 Jun 2000 12:05:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26865 Tue, 13 Jun 2000 13:49:31 -0400 (EDT) From: "JACK MASON" To: Subject: Next Bakeoff Date: Tue, 13 Jun 2000 13:56:15 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20000613175707.PYXW402.dorsey@jack> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Last January in San Diego, Cisco Sys. proposed another "bakeoff" in September but was not going to sponsor the event. Does anyone have any info on when (if) the next bakeoff will be ? Thanks, Jack From owner-ipsec@lists.tislabs.com Tue Jun 13 12:23:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01752; Tue, 13 Jun 2000 12:23:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26947 Tue, 13 Jun 2000 14:14:15 -0400 (EDT) From: Dan McDonald Message-Id: <200006131822.LAA09713@kebe.Eng.Sun.COM> Subject: Re: Next Bakeoff In-Reply-To: <20000613175707.PYXW402.dorsey@jack> from JACK MASON at "Jun 13, 2000 01:56:15 pm" To: JACK MASON Date: Tue, 13 Jun 2000 11:22:30 -0700 (PDT) CC: ipsec@lists.tislabs.com X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Last January in San Diego, Cisco Sys. proposed another > "bakeoff" in September but was not going to sponsor the > event. Does anyone have any info on when (if) the next > bakeoff will be ? We had a small IPsec interoperability event at Connectathon (http://www.connectahon.org/), but because it followed the San Diego one, we didn't have a lot of turnout. The next Connectathon is March 1-8, 2001, and we are planning on doing IPsec/IKE testing again. If there's one between now and then (September or October is actually not a bad time), that'd be cool. Dan From owner-ipsec@lists.tislabs.com Wed Jun 14 04:04:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA28292; Wed, 14 Jun 2000 04:04:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA29762 Wed, 14 Jun 2000 05:30:38 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Cc: isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Deprecation of AH header from the IPSEC tool kit Date: Wed, 14 Jun 2000 10:38:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There has been some discussion recently on the possible deprecation of the Authentication Header defined for 'whole-packet' authentication. I 'think' the decision was to leave it alone, and allow AH to wait for its day. >From reading the various, associated methods of securing ISIS, OSPF and RIPV2 messages, it seems to me that AH is perfect for the protection of these protocols. The current HMAC-MD5 options have the following exposures that are solved with AH: 1) no source address authentication (IP header authentication in general) 2) poor/no replay protection 3) manual keys - which restricts key length and complexity to human-manageable keys, and makes for difficult key change procedures. IPSEC+AH would seem to be a good choice for all control traffic exchange between routers. If this exchange is confidential, the ESP could be used as well. Regards, Steve. From owner-ipsec@lists.tislabs.com Wed Jun 14 07:48:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05145; Wed, 14 Jun 2000 07:48:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00697 Wed, 14 Jun 2000 09:24:42 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14663.35217.793569.559881@xedia.com> Date: Wed, 14 Jun 2000 09:33:05 -0400 (EDT) To: Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Waters," == Waters, Stephen writes: Waters,> There has been some discussion recently on the possible Waters,> deprecation of the Authentication Header defined for Waters,> 'whole-packet' authentication. Waters,> I 'think' the decision was to leave it alone, and allow AH Waters,> to wait for its day. >> From reading the various, associated methods of securing ISIS, >> OSPF and Waters,> RIPV2 messages, it seems to me that AH is perfect for the Waters,> protection of these protocols. Waters,> The current HMAC-MD5 options have the following exposures Waters,> that are solved with AH: Waters,> 1) no source address authentication (IP header Waters,> authentication in general) 2) poor/no replay protection 3) Waters,> manual keys - which restricts key length and complexity to Waters,> human-manageable keys, and makes for difficult key change Waters,> procedures. Waters,> IPSEC+AH would seem to be a good choice for all control Waters,> traffic exchange between routers. If this exchange is Waters,> confidential, the ESP could be used as well. Yes, but if it's not confidential (which is the likely case) then ESP in authentication only mode will serve just as well. It's never been the point of any of this discussion to deprecate the notion that authentication is useful -- the issue is whether it makes sense to retain AH when ESP does the job with significantly less hassle. paul From owner-ipsec@lists.tislabs.com Wed Jun 14 10:09:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13345; Wed, 14 Jun 2000 10:09:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01228 Wed, 14 Jun 2000 11:22:14 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14663.42213.816377.583137@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 08:29:41 -0700 (PDT) To: Paul Koning Cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: <14663.35217.793569.559881@xedia.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > It's never been the point of any of this discussion to deprecate the > notion that authentication is useful -- the issue is whether it makes > sense to retain AH when ESP does the job with significantly less > hassle. What keeps nagging at me is the overhead of both AH and ESP, not to mention the added complexity. This might be water well under the bridge, but has the thought of having a mode to ESP which protects the outer headers? I know that's contrary to the "encapsulating" part, but if we want to converge on one crypto header, it seems to me that placing an artificial restriction that outside headers can never be protected is pretty arbitrary and wrongheaded (even though I'm persuaded by Steve Bellovin's arguments about v4 headers). Mike From owner-ipsec@lists.tislabs.com Wed Jun 14 11:00:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14295; Wed, 14 Jun 2000 11:00:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01516 Wed, 14 Jun 2000 12:48:59 -0400 (EDT) Message-Id: <200006140038.RAA28905@potassium.network-alchemy.com> To: Dan McDonald cc: JACK MASON , ipsec@lists.tislabs.com Subject: Re: Next Bakeoff In-reply-to: Your message of "Tue, 13 Jun 2000 11:22:30 PDT." <200006131822.LAA09713@kebe.Eng.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28902.960943101.1@network-alchemy.com> Date: Tue, 13 Jun 2000 17:38:21 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe there will be another one in September (17th to 22nd) in San Diego. Details will most surely be posted here when they get finalized. Dan. On Tue, 13 Jun 2000 11:22:30 PDT you wrote > > Last January in San Diego, Cisco Sys. proposed another > > "bakeoff" in September but was not going to sponsor the > > event. Does anyone have any info on when (if) the next > > bakeoff will be ? > > We had a small IPsec interoperability event at Connectathon > (http://www.connectahon.org/), but because it followed the San Diego one, we > didn't have a lot of turnout. The next Connectathon is March 1-8, 2001, and > we are planning on doing IPsec/IKE testing again. > > If there's one between now and then (September or October is actually not a > bad time), that'd be cool. > > Dan From owner-ipsec@lists.tislabs.com Wed Jun 14 11:01:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14318; Wed, 14 Jun 2000 11:01:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01557 Wed, 14 Jun 2000 12:55:20 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14663.47855.662864.377087@xedia.com> Date: Wed, 14 Jun 2000 13:03:43 -0400 (EDT) To: mat@cisco.com Cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: >> It's never been the point of any of this discussion to deprecate >> the notion that authentication is useful -- the issue is whether >> it makes sense to retain AH when ESP does the job with >> significantly less hassle. Michael> What keeps nagging at me is the overhead of both AH and ESP, Michael> not to mention the added complexity. Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? That's no help, because that is exactly the difference that makes AH so much harder than ESP. (Well, there's details like having the MAC in the header rather than the trailer. Then again, ESP puts the NextHeader value in the wrong place, so they're even...) The reason I like ESP authentication is precisely the fact that it doesn't contain all the hair needed to protect a subset of IP header fields. paul From owner-ipsec@lists.tislabs.com Wed Jun 14 11:23:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14650; Wed, 14 Jun 2000 11:23:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01707 Wed, 14 Jun 2000 13:16:44 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14663.49140.785124.646034@xedia.com> Date: Wed, 14 Jun 2000 13:25:08 -0400 (EDT) To: mat@cisco.com Cc: ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: What keeps nagging at me is the overhead Michael> of both AH and ESP, not to mention the added complexity. >> Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? >> That's no help, because that is exactly the difference that makes >> AH so much harder than ESP. (Well, there's details like having >> the MAC in the header rather than the trailer. Then again, ESP >> puts the NextHeader value in the wrong place, so they're even...) >> >> The reason I like ESP authentication is precisely the fact that it >> doesn't contain all the hair needed to protect a subset of IP >> header fields. Michael> Maybe you're misunderstanding me: if ESP had a bit which Michael> said "I'm protecting the outside headers too", it could be Michael> either signaled or potentially even done on an as-needed Michael> basis by the IPsec stack for IP headers which would Michael> otherwise require AH. I'm all for not protecting things that Michael> don't need protection otherwise. I think I understood. The issue is that the bit you're describing is actually the only essential difference between AH and ESP. In other words, you can think of it as the "do AH" bit. You can't just "protect the outside headers too". You have to be selective about it, protecting only immutable ones, skipping fields and headers that change in transit, mumble mumble mumble. That's the "hair" of AH I'm referring to. It doesn't matter what you call it or how you encode it. The hypothetical "ESP with the bit" you describe has to do the same thing so it has to contain the same amount of hair. paul From owner-ipsec@lists.tislabs.com Wed Jun 14 11:28:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14743; Wed, 14 Jun 2000 11:28:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01658 Wed, 14 Jun 2000 13:12:39 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14663.48838.383043.113376@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 10:20:06 -0700 (PDT) To: Paul Koning Cc: mat@cisco.com, Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: <14663.47855.662864.377087@xedia.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > Michael> What keeps nagging at me is the overhead of both AH and ESP, > Michael> not to mention the added complexity. > > Michael> This might be water well under the bridge, but has the > Michael> thought of having a mode to ESP which protects the outer > Michael> headers? > > That's no help, because that is exactly the difference that makes AH > so much harder than ESP. (Well, there's details like having the MAC > in the header rather than the trailer. Then again, ESP puts the > NextHeader value in the wrong place, so they're even...) > > The reason I like ESP authentication is precisely the fact that it > doesn't contain all the hair needed to protect a subset of IP header > fields. Maybe you're misunderstanding me: if ESP had a bit which said "I'm protecting the outside headers too", it could be either signaled or potentially even done on an as-needed basis by the IPsec stack for IP headers which would otherwise require AH. I'm all for not protecting things that don't need protection otherwise. Mike From owner-ipsec@lists.tislabs.com Wed Jun 14 12:15:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15677; Wed, 14 Jun 2000 12:15:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01986 Wed, 14 Jun 2000 14:04:19 -0400 (EDT) Message-ID: <3947C9D3.15B959C7@indusriver.com> Date: Wed, 14 Jun 2000 14:07:16 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: mat@cisco.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Michael> This might be water well under the bridge, but has the > Michael> thought of having a mode to ESP which protects the outer > Michael> headers? Aren't your goals met by using ESP _tunnel_ mode? Just tunnel the OSPF, RIP, etc, packet from one box to the other. The tunneled packet has an inner IP header is completely secured by ESP. This is the header seen by OSPF, RIP, etc, once ESP completes the authentication of the packet. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Wed Jun 14 12:18:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15735; Wed, 14 Jun 2000 12:18:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02033 Wed, 14 Jun 2000 14:10:55 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14663.52391.764650.742840@xedia.com> Date: Wed, 14 Jun 2000 14:19:19 -0400 (EDT) To: bmccann@indusriver.com Cc: mat@cisco.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> <3947C9D3.15B959C7@indusriver.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ben" == Ben McCann writes: Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? Ben> Aren't your goals met by using ESP _tunnel_ mode? Just tunnel Ben> the OSPF, RIP, etc, packet from one box to the other. The Ben> tunneled packet has an inner IP header is completely secured by Ben> ESP. This is the header seen by OSPF, RIP, etc, once ESP Ben> completes the authentication of the packet. That certainly does the job. The trouble appears if someone wants to use transport mode (perhaps to save a few bytes) and then decides that for some reason there are IP headers worthy of protection. That's where the messy hybrid (AH) appears. paul From owner-ipsec@lists.tislabs.com Wed Jun 14 12:21:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15798; Wed, 14 Jun 2000 12:21:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02026 Wed, 14 Jun 2000 14:10:35 -0400 (EDT) Message-ID: <3947CC5F.63D6EF93@mitel.com> Date: Wed, 14 Jun 2000 14:18:07 -0400 From: Dave Perks Organization: Mitel Corporation X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IP Security List Subject: [Fwd: Deprecation of AH header from the IPSEC tool kit] Content-Type: multipart/mixed; boundary="------------BA9A9D476461C935915202BB" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------BA9A9D476461C935915202BB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------BA9A9D476461C935915202BB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <394796FE.3D952F2C@mitel.com> Date: Wed, 14 Jun 2000 10:30:22 -0400 From: Dave Perks Organization: Mitel Corporation X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Waters, Stephen" Subject: Re: Deprecation of AH header from the IPSEC tool kit References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I only have experience with RIPV2, but have to argue with a point or two. In particular, I don't see why AH would be preferred over ESP(AH). I *do* however see why IPSEC would be preferred over RIPV2's authentication. "Waters, Stephen" wrote: > >From reading the various, associated methods of securing ISIS, OSPF and > RIPV2 messages, it seems to me that AH is perfect for the protection of > these protocols. > > The current HMAC-MD5 options have the following exposures that are solved > with AH: > > 1) no source address authentication (IP header authentication in general) IPSEC+ESP(AH) would protect the UDP header of RIPV2, so the UDP checksum would provide some limited protection of the source address. > 2) poor/no replay protection Agreed, but ESP(AH) would handle this too. > 3) manual keys - which restricts key length and complexity to > human-manageable keys, and makes for difficult key change procedures. Agreed, but ditto for ESP(AH). (On the other hand, trying to use IPSEC phase 1 and 2 before the routers can communicate could lead to a chicken-egg situation. I think that this might have been a motivation for the original built-in authentication scheme.) > IPSEC+AH would seem to be a good choice for all control traffic exchange > between routers. If this exchange is confidential, the ESP could be used as > well. RIPV2 is multicast, and AFAIK IPSEC hasn't addressed keying of multicast sessions. --------------BA9A9D476461C935915202BB-- From owner-ipsec@lists.tislabs.com Wed Jun 14 13:02:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16345; Wed, 14 Jun 2000 13:02:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02201 Wed, 14 Jun 2000 14:40:22 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14663.54131.519220.652837@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 11:48:19 -0700 (PDT) To: Paul Koning Cc: mat@cisco.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: <14663.49140.785124.646034@xedia.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > The issue is that the bit you're describing is actually the only > essential difference between AH and ESP. In other words, you can > think of it as the "do AH" bit. > > You can't just "protect the outside headers too". You have to be > selective about it, protecting only immutable ones, skipping fields > and headers that change in transit, mumble mumble mumble. That's the > "hair" of AH I'm referring to. It doesn't matter what you call it or > how you encode it. The hypothetical "ESP with the bit" you describe > has to do the same thing so it has to contain the same amount of hair. Sure. Doing AH-like functionality is a pain; if you have to do it, you have to do it -- that's just a given. What I don't like is having a completely separate header with its associated complexity and (especially) overhead. Right now though, if I had a flow which for some reason need privacy and outer header protection (ie, AH functionality), you'd have to put on an AH and ESP header. This means that the SPI and the Sequence are completely redundant, as well as having to burn another longword for the redundant header, thus I'm having to add yet another 12 bytes per packet. If we're talking about something like RTP audio, that's probably significant. Then of course there's the issue of, say, CRTP. I don't think that a profile for crypto for CRTP has been done to compress the predictable parts of the crypto headers, (ie, SPI, SEQ, next header), but having to contend with *both* AH and ESP would make crypto-aware CRTP an even uglier proposition. The same, incidentally, goes for normal header compression, and the coming IP enabled cellular stuff is going to absolutely demand both compression as well as security. Whether it is wise to open up this debate yet again is questionable, but life is only going to get more complicated if AH stays around. Pick your poison. Mike From owner-ipsec@lists.tislabs.com Wed Jun 14 13:02:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16347; Wed, 14 Jun 2000 13:02:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02234 Wed, 14 Jun 2000 14:46:09 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14663.54477.878441.566118@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 11:54:05 -0700 (PDT) To: Ben McCann Cc: Paul Koning , mat@cisco.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: <3947C9D3.15B959C7@indusriver.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> <3947C9D3.15B959C7@indusriver.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ben McCann writes: > > Michael> This might be water well under the bridge, but has the > > Michael> thought of having a mode to ESP which protects the outer > > Michael> headers? > > Aren't your goals met by using ESP _tunnel_ mode? Just tunnel the OSPF, > RIP, etc, packet from one box to the other. The tunneled packet has an > inner IP header is completely secured by ESP. This is the header seen > by OSPF, RIP, etc, once ESP completes the authentication of the packet. > See my previous post. Throwing bytes at the problem is certainly one way to solve it, but it may not be practical in many, many cases. Mike From owner-ipsec@lists.tislabs.com Wed Jun 14 13:04:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16384; Wed, 14 Jun 2000 13:04:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02266 Wed, 14 Jun 2000 14:56:33 -0400 (EDT) Message-Id: <200006141902.PAA11044@solidum.com> To: Michael Thomas , Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: Your message of "Wed, 14 Jun 2000 08:29:41 PDT." <14663.42213.816377.583137@thomasm-u1.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 15:02:50 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: >> It's never been the point of any of this discussion to deprecate the >> notion that authentication is useful -- the issue is whether it makes >> sense to retain AH when ESP does the job with significantly less >> hassle. Michael> What keeps nagging at me is the overhead of both AH and ESP, not Michael> to mention the added complexity. If two routers need privacy and authenticity, they can use end-to-end ESP, as they can get strong origin authentication by virtue of the integrity check succeeding in the ESP. Don't trust the source IP, rather take the appropriate source IP from the SA to look up the appropriate PCB for the TCP/UDP session you are protecting. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Wed Jun 14 13:39:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16729; Wed, 14 Jun 2000 13:39:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02225 Wed, 14 Jun 2000 14:44:24 -0400 (EDT) From: Dan McDonald Message-Id: <200006141852.LAA27430@kebe.Eng.Sun.COM> Subject: Re: [Fwd: Deprecation of AH header from the IPSEC tool kit] In-Reply-To: <3947CC5F.63D6EF93@mitel.com> from Dave Perks at "Jun 14, 2000 02:18:07 pm" To: Dave Perks Date: Wed, 14 Jun 2000 11:52:49 -0700 (PDT) CC: IP Security List X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > IPSEC+AH would seem to be a good choice for all control traffic exchange > > between routers. If this exchange is confidential, the ESP could be used as > > well. > > RIPV2 is multicast, and AFAIK IPSEC hasn't addressed keying of multicast > sessions. The tools are there for people to build multicast key management protocols for IPsec. An IPsec implementation should be able to handle manually-added multicast SAs already. Layering one's experimental multicast KM implementation on top shouldn't be difficult, modulo the actual hard work of building a multicast KM protocol. Dan From owner-ipsec@lists.tislabs.com Wed Jun 14 14:35:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17377; Wed, 14 Jun 2000 14:35:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02522 Wed, 14 Jun 2000 16:15:22 -0400 (EDT) Message-Id: <200006142022.QAA15540@solidum.com> To: mat@cisco.com, Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: Your message of "Wed, 14 Jun 2000 10:20:06 PDT." <14663.48838.383043.113376@thomasm-u1.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 16:22:37 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Thomas writes: Michael> Maybe you're misunderstanding me: if ESP had a bit which said Michael> "I'm protecting the outside headers too", it could be either Michael> signaled or potentially even done on an as-needed basis by the Michael> IPsec stack for IP headers which would otherwise require AH. I'm Michael> all for not protecting things that don't need protection Michael> otherwise. The point that Steve Bellovin keeps making, and which he has written about, is that AH does not provide much more in the way of authentication that ESP does not (at least for IPv4). The outer headers are all either irrelevant, or can be derived from the SPD, so you don't have to trust them. I believe that there are other things that AH provides (like the guarantee that the contents are not encrypted and therefore can be audited), and things that will be defined in IPv6-extension land that will make AH a useful thing to keep in the spec, just not MUST it. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Wed Jun 14 17:41:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19901; Wed, 14 Jun 2000 17:41:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02911 Wed, 14 Jun 2000 19:02:40 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14664.4302.578895.745820@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 16:10:06 -0700 (PDT) To: Michael Richardson Cc: mat@cisco.com, Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: <200006142022.QAA15540@solidum.com> References: <14663.48838.383043.113376@thomasm-u1.cisco.com> <200006142022.QAA15540@solidum.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > > >>>>> "Michael" == Michael Thomas writes: > Michael> Maybe you're misunderstanding me: if ESP had a bit which said > Michael> "I'm protecting the outside headers too", it could be either > Michael> signaled or potentially even done on an as-needed basis by the > Michael> IPsec stack for IP headers which would otherwise require AH. I'm > Michael> all for not protecting things that don't need protection > Michael> otherwise. > > The point that Steve Bellovin keeps making, and which he has written about, > is that AH does not provide much more in the way of authentication that > ESP does not (at least for IPv4). The outer headers are all either > irrelevant, or can be derived from the SPD, so you don't have to trust them. That's true of v4 IP headers. Is it also true of v6 routing headers? Is it also true of all of the rest of the v6 headers? I appreciate Steve's argument on this, and I think they're valid -- for v4 IP headers. What I don't agree with is that you can make a blanket statement that you can never have a situation where an outer header doesn't require some cryptographic protection. This is definitional: you can't do a security analysis on the undefined. So, in order to deprecate AH (which I think has a lot of merit), you'd have to do one of two things: 1) Put a stake in the ground saying that everything outside of the ESP header is fair game, and that if you must have protection you must put it inside (begging the question of per-hop headers which require the header be in the clear) 2) Hedge your bets by folding AH functionality into ESP (or something like ESP). This could be done by slavishly requiring AH functionality across the board, or it could be more clever and optimize only the cases where you have outer headers that need to be protected (and potentially which fields) I'm not comfortable with #1 because smacks of being able to predict the future with too much certainty. #2 is certainly not easy since it would require a careful analysis of each header to determine whether there is any benefit to including it into the MAC calculation. However there would be a net reduction in complexity and header size if we nuked AH, so maybe it's worth it. Mike From owner-ipsec@lists.tislabs.com Wed Jun 14 17:58:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20075; Wed, 14 Jun 2000 17:58:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02993 Wed, 14 Jun 2000 19:25:56 -0400 (EDT) Message-Id: <200006142334.TAA24904@solidum.com> To: Michael Thomas CC: ipsec@lists.tislabs.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: Your message of "Wed, 14 Jun 2000 16:10:06 PDT." <14664.4302.578895.745820@thomasm-u1.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 19:34:05 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk {Michael, i've cut the CC list, since I'm not on isis-wg or rip, and my posts don't go in anyway... you can put the CC back in and advise them the rest of the conversation is on ipsec, I leave you on because I don't know if you are on ipsec. Likely not, since we discussed this before. Feel free to forward my posts to isis-wg, etc....} >>>>> "Michael" == Michael Thomas writes: Michael> That's true of v4 IP headers. Is it also true of v6 routing Michael> headers? Is it also true of all of the rest of the v6 headers? I Michael> appreciate Steve's argument on this, and I think they're valid Michael> -- for v4 IP headers. What I don't agree with is that you can Thus my position: 1) make AH a MAY for routers/gateways that want to support IPsec/IPv4. (I would prefer that end nodes SHOULD still support AH, but that affects fewer implementations (Sun, Free/SWAN, KAME, OpenBSD, Microsoft?), but more systems.. Most people who are building gateways want privacy. 2) *leave* AH as a SHOULD/MUST for IPv6, but in particular, leave the details of this (SHOULD/MUST) to the ipngwg to decide if they wish to have all end systems support it for future possible use by extension headers, or other stuff. I say leave it to ipngwg to decide if IPsec AH is required (ESP is not for political reasons. IPngWG may wish to change their mind on that point...) because the decision whether or not to mandate AH in end systems is an engineering question, not a security question. (Wow! Steve, stay off that reply key for a moment) Assume that Steve Bellovin has ocnvinced everyone that all current IPv6 extension headers to not benefit from AH, or carry information that could be independantly verified from info stored in the SA-table. (e.g. legitimate source addresses, pointers to PCBs). i.e. there is no current reason to have AH vs ESP in IPv6. The situation then becomes: if a new extension header is introduced that would benefit (more precisely: be insecure and therefore undeployable) from the protections that AH can provide, it then falls to the proponent of the new extension to mandate that AH must exist. It may be hard to get agreement that the extension is important enough to cause AH to be included in new products, and the extension will never fly. The reason why we have a network layer WG, of course, is so that the extension header, routing, etc. people don't have to invent the wheel over and over again. So, it is really up to IPngwg to decide how much importance they want to put on being able to do new IPv6 extension headers in a secure fashion. Michael> Hedge your bets by folding AH functionality into ESP (or Michael> something like ESP). This could be done by slavishly requiring Michael> AH functionality across the board, or it could be more clever Michael> and optimize only the cases where you have outer headers that Michael> need to be protected (and potentially which fields) I think that there is no advantage to folding AH functionality in ESP. Numerous disadvantages in fact. a) there is no code savings. If you have AH functionality, you have it, your ESP code path just has one more condition to test. b) the knowledge of whether or not you are doing AH functionality in ESP would not be carried in the packet, but rather in the SA, since it would be negotiated. c) an external observer can not distinguish ESP(NULL)+AH functionality from ESP(AES)+normal integrity. This is good if you are interested solely in traffic analysis. This is bad if you want to do auditing at security gateways (aka firewalls), etc. Michael> I'm not comfortable with #1 because smacks of being able to Michael> predict the future with too much certainty. #2 is certainly not Michael> easy since it would require a careful analysis of each header to Michael> determine whether there is any benefit to including it into the Michael> MAC calculation. However there would be a net reduction in Michael> complexity and header size if we nuked AH, so maybe it's worth Michael> it. There is no reduction in complexity if you create an ESP that covers the headers. The question is more simply: rm rfc2402.txt or not. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Wed Jun 14 18:04:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21210; Wed, 14 Jun 2000 18:04:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03026 Wed, 14 Jun 2000 19:43:32 -0400 (EDT) To: Michael Richardson cc: Michael Thomas , ipsec@lists.tislabs.com In-reply-to: mcr's message of Wed, 14 Jun 2000 19:34:05 -0400. <200006142334.TAA24904@solidum.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Deprecation of AH header from the IPSEC tool kit From: itojun@iijlab.net Date: Thu, 15 Jun 2000 08:51:48 +0900 Message-ID: <14969.961026708@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Assume that Steve Bellovin has ocnvinced everyone that all current IPv6 >extension headers to not benefit from AH, or carry information that could >be independantly verified from info stored in the SA-table. (e.g. legitimate >source addresses, pointers to PCBs). i.e. there is no current reason to >have AH vs ESP in IPv6. the observation is incorrect. there are extension headers that require protection from AH: mobile-ip6 headers like binding update. itojun From owner-ipsec@lists.tislabs.com Wed Jun 14 18:46:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03064; Wed, 14 Jun 2000 18:46:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03099 Wed, 14 Jun 2000 20:05:28 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14664.8103.923043.964046@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 17:13:27 -0700 (PDT) To: Michael Richardson Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: <200006142334.TAA24904@solidum.com> References: <14664.4302.578895.745820@thomasm-u1.cisco.com> <200006142334.TAA24904@solidum.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > There is no reduction in complexity if you create an ESP that covers > the headers. The question is more simply: > rm rfc2402.txt > > or not. [cutting to the chase] If the end result is an AH'less v4 but MUST AH in v6, with oodles of v4 implementations which already support v4 AH, I'm not sure that there a whole lot of motivation deprecate it just for v4. You can just not run AH, after all. Are folks over here aware that the cellular folks are requiring ipv6 in next gen handsets, and all that implies for security? This issue is not entirely academic anymore. Mike From owner-ipsec@lists.tislabs.com Wed Jun 14 19:23:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08353; Wed, 14 Jun 2000 19:23:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03224 Wed, 14 Jun 2000 20:35:50 -0400 (EDT) Date: Wed, 14 Jun 2000 17:44:12 -0700 From: Paul Krumviede Subject: Re: Deprecation of AH header from the IPSEC tool kit In-reply-to: <14664.8103.923043.964046@thomasm-u1.cisco.com> To: Michael Thomas , Michael Richardson Cc: ipsec@lists.tislabs.com Message-id: <3226945962.961004652@sjo-dhcp0386.mcit.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --On Wednesday, 14 June, 2000 17:13 -0700 Michael Thomas wrote: > Are folks over here aware that the cellular > folks are requiring ipv6 in next gen handsets, > and all that implies for security? This issue is > not entirely academic anymore. note that draft-iab-wirelessws-00.txt indicates that there was resistance to acceptance of IPv6 in "any" of 3G standards efforts (section 3.10). it also notes that "there was considerable aversion to use of IPsec and IKE protocols due to perceived overhead and delay." -paul From owner-ipsec@lists.tislabs.com Wed Jun 14 19:47:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA11533; Wed, 14 Jun 2000 19:47:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03267 Wed, 14 Jun 2000 20:54:30 -0400 (EDT) Message-Id: <200006150102.VAA28935@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: Your message of "Thu, 15 Jun 2000 08:51:48 +0900." <14969.961026708@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 21:02:57 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "itojun" == itojun writes: >> Assume that Steve Bellovin has ocnvinced everyone that all current >> IPv6 extension headers to not benefit from AH, or carry information >> that could be independantly verified from info stored in the >> SA-table. (e.g. legitimate source addresses, pointers to >> PCBs). i.e. there is no current reason to have AH vs ESP in IPv6. itojun> the observation is incorrect. there are extension headers that itojun> require protection from AH: mobile-ip6 headers like binding itojun> update. Yes, I know. ipngwg could say, "mobile-ip6 is not important enough to mandate AH in all IPv6 end-nodes. If they want to support mobile-ip6, they'll need to do AH." But that would be up to ipngwg to say that. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Wed Jun 14 20:02:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA13277; Wed, 14 Jun 2000 20:01:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03392 Wed, 14 Jun 2000 21:41:13 -0400 (EDT) Message-Id: <200006150149.VAA30903@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: Your message of "Wed, 14 Jun 2000 19:34:05 EDT." <200006142334.TAA24904@solidum.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 21:49:39 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Richardson writes: Michael> Assume that Steve Bellovin has ocnvinced everyone that all Michael> current IPv6 extension headers to not benefit from AH, or carry ^do Michael> The reason why we have a network layer WG, of course, is so that ^security^ (==ipsec) :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Wed Jun 14 20:26:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA15700; Wed, 14 Jun 2000 20:26:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03279 Wed, 14 Jun 2000 20:57:13 -0400 (EDT) Message-Id: <200006150105.VAA29059@solidum.com> To: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: Your message of "Wed, 14 Jun 2000 17:13:27 PDT." <14664.8103.923043.964046@thomasm-u1.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 21:05:32 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Thomas writes: Michael> Michael Richardson writes: >> There is no reduction in complexity if you create an ESP that covers >> the headers. The question is more simply: rm rfc2402.txt >> >> or not. Michael> [cutting to the chase] Michael> If the end result is an AH'less v4 but MUST AH in v6, with Michael> oodles of v4 implementations which already support v4 AH, I'm Michael> not sure that there a whole lot of motivation deprecate it just Michael> for v4. You can just not run AH, after all. At present, you can't say that you are "IPsec IPv4 compliant" if you don't have IPv4. At least, that is what the marketing people have been lead to believe, and the customers, and those you have a lot of "checkbox-compliant" IPv4 AH implementations. I feel for these people, which is why I suggest that AH be moved to "MAY" for IPv4, but not deprecated. I also don't want to lose AH. Michael> Are folks over here aware that the cellular folks are requiring Michael> ipv6 in next gen handsets, and all that implies for security? Michael> This issue is not entirely academic anymore. Indeed!!! :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Thu Jun 15 05:15:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19932; Thu, 15 Jun 2000 05:15:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04645 Thu, 15 Jun 2000 06:31:32 -0400 (EDT) Message-Id: <200006151039.GAA25980@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-doi-tc-mib-03.txt Date: Thu, 15 Jun 2000 06:39:56 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New 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 : IPSec DOI Textual Conventions MIB Author(s) : J. Shriver Filename : draft-ietf-ipsec-doi-tc-mib-03.txt Pages : 21 Date : 14-Jun-00 This memo defines textual conventions for use in monitoring, status, and configuration MIBs for IPSec. It includes a MIB module that defines those textual conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-03.txt Internet-Drafts are also 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-doi-tc-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <20000614110433.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-doi-tc-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000614110433.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jun 15 07:14:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23847; Thu, 15 Jun 2000 07:14:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05226 Thu, 15 Jun 2000 08:30:32 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D282D5@new-exc1.ctron.com> From: "Waters, Stephen" To: Paul Koning Cc: ipsec@lists.tislabs.com Subject: RE: Deprecation of AH header from the IPSEC tool kit Date: Thu, 15 Jun 2000 13:38:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can see the ESP authentication is fine when tunnel mode is in use - but for peer to peer routing protocols, transport mode seems more appropriate and the security of IP header and options could then be a requirement. Steve. -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Wednesday, June 14, 2000 2:33 PM To: Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com; isis-wg@juniper.net; ospf@discuss.microsoft.com; ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Waters," == Waters, Stephen writes: Waters,> There has been some discussion recently on the possible Waters,> deprecation of the Authentication Header defined for Waters,> 'whole-packet' authentication. Waters,> I 'think' the decision was to leave it alone, and allow AH Waters,> to wait for its day. >> From reading the various, associated methods of securing ISIS, >> OSPF and Waters,> RIPV2 messages, it seems to me that AH is perfect for the Waters,> protection of these protocols. Waters,> The current HMAC-MD5 options have the following exposures Waters,> that are solved with AH: Waters,> 1) no source address authentication (IP header Waters,> authentication in general) 2) poor/no replay protection 3) Waters,> manual keys - which restricts key length and complexity to Waters,> human-manageable keys, and makes for difficult key change Waters,> procedures. Waters,> IPSEC+AH would seem to be a good choice for all control Waters,> traffic exchange between routers. If this exchange is Waters,> confidential, the ESP could be used as well. Yes, but if it's not confidential (which is the likely case) then ESP in authentication only mode will serve just as well. It's never been the point of any of this discussion to deprecate the notion that authentication is useful -- the issue is whether it makes sense to retain AH when ESP does the job with significantly less hassle. paul From owner-ipsec@lists.tislabs.com Thu Jun 15 07:37:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24352; Thu, 15 Jun 2000 07:37:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05407 Thu, 15 Jun 2000 09:13:33 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14664.55389.253584.9549@thomasm-u1.cisco.com> Date: Thu, 15 Jun 2000 06:21:33 -0700 (PDT) To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: <200006150102.VAA28935@solidum.com> References: <14969.961026708@coconut.itojun.org> <200006150102.VAA28935@solidum.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > > >>>>> "itojun" == itojun writes: > >> Assume that Steve Bellovin has ocnvinced everyone that all current > >> IPv6 extension headers to not benefit from AH, or carry information > >> that could be independantly verified from info stored in the > >> SA-table. (e.g. legitimate source addresses, pointers to > >> PCBs). i.e. there is no current reason to have AH vs ESP in IPv6. > > itojun> the observation is incorrect. there are extension headers that > itojun> require protection from AH: mobile-ip6 headers like binding > itojun> update. > > Yes, I know. > > ipngwg could say, "mobile-ip6 is not important enough to mandate AH > in all IPv6 end-nodes. If they want to support mobile-ip6, they'll > need to do AH." Not protecting Binding Cache Updates would relegate mobile v6 to the same krufty dog leg routing that is required in v4 mobility. I certainly would not support anything which made it harder to get to v6 style mobility, which is what the above would do. Whether that must be using AH is another matter. Mike From owner-ipsec@lists.tislabs.com Thu Jun 15 08:33:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25555; Thu, 15 Jun 2000 08:33:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05496 Thu, 15 Jun 2000 09:40:08 -0400 (EDT) Message-Id: <200006150444.VAA04179@potassium.network-alchemy.com> To: Paul Krumviede cc: Michael Thomas , Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-reply-to: Your message of "Wed, 14 Jun 2000 17:44:12 PDT." <3226945962.961004652@sjo-dhcp0386.mcit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4176.961044259.1@network-alchemy.com> Date: Wed, 14 Jun 2000 21:44:19 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 14 Jun 2000 17:44:12 PDT you wrote > > note that draft-iab-wirelessws-00.txt indicates that > there was resistance to acceptance of IPv6 in > "any" of 3G standards efforts (section 3.10). > it also notes that "there was considerable > aversion to use of IPsec and IKE protocols > due to perceived overhead and delay." It was this same perception that caused many wheels to be reinvented for WAP. The result is no better, and in some ways worse, than TCP/IP. WIPSec and WIKE will follow this tradition. Dan. From owner-ipsec@lists.tislabs.com Thu Jun 15 09:50:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27232; Thu, 15 Jun 2000 09:50:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06137 Thu, 15 Jun 2000 11:13:11 -0400 (EDT) From: John Ioannidis Date: Thu, 15 Jun 2000 11:21:41 -0400 (EDT) Message-Id: <200006151521.LAA05045@bual.research.att.com> To: ipsec@lists.tislabs.com Subject: Re: Deprecation of AH header from the IPSEC tool kit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > "any" of 3G standards efforts (section 3.10). My understanding is that 3GPP actually *does* want to use IETF standards as much as possible, because they want to interoperate with wireline terminals (to use some antiquated terminology). /ji From owner-ipsec@lists.tislabs.com Thu Jun 15 09:50:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27233; Thu, 15 Jun 2000 09:50:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06069 Thu, 15 Jun 2000 11:02:48 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D282D9@new-exc1.ctron.com> From: "Waters, Stephen" To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: RE: Deprecation of AH header from the IPSEC tool kit Date: Thu, 15 Jun 2000 16:08:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Although all sorts of attacks are possible, it is good to know when they are happening. With ESP-tunnel mode, the out header is exposed to various DOS attacks - like messing with the TTL, frag bits etc. For ESP-transport mode, the header and options fields are exposed. I think these are good reasons to use AH, or to add a variant of ESP that authenticates the whole packet - hopefully not encrypting the whole packet :) Steve. In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP). -----Original Message----- From: Michael Richardson [mailto:mcr@solidum.com] Sent: Wednesday, June 14, 2000 9:23 PM To: mat@cisco.com; Stephen.Waters@cabletron.com; ipsec@lists.tislabs.com; isis-wg@juniper.net; ospf@discuss.microsoft.com; ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Michael" == Michael Thomas writes: Michael> Maybe you're misunderstanding me: if ESP had a bit which said Michael> "I'm protecting the outside headers too", it could be either Michael> signaled or potentially even done on an as-needed basis by the Michael> IPsec stack for IP headers which would otherwise require AH. I'm Michael> all for not protecting things that don't need protection Michael> otherwise. The point that Steve Bellovin keeps making, and which he has written about, is that AH does not provide much more in the way of authentication that ESP does not (at least for IPv4). The outer headers are all either irrelevant, or can be derived from the SPD, so you don't have to trust them. I believe that there are other things that AH provides (like the guarantee that the contents are not encrypted and therefore can be audited), and things that will be defined in IPv6-extension land that will make AH a useful thing to keep in the spec, just not MUST it. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Thu Jun 15 10:12:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27771; Thu, 15 Jun 2000 10:12:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06298 Thu, 15 Jun 2000 11:34:12 -0400 (EDT) Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B88C@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Michael Richardson'" , Michael Thomas , ipsec@lists.tislabs.com Subject: RE: Deprecation of AH header from the IPSEC tool kit Date: Thu, 15 Jun 2000 08:41:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ok, time to stick my big nose in things. There have been many claims that there is absolutely nothing worth protecting with AH in the IP header. Well while doing some deep thinking about Security Policy a coworker and I came across a requirement for IPSO (RFC1108) U.S. Department of Defense Security Options for the Internet Protocol. It seems that DOD networks would like to have a IP header option that includes a tag that says how "classified" the packet is. Now RFC 2401 mentions this header explicitly and infact allows IPsec to make security determinations based on this field. I think this is a great value for AH where I can authenticate the IP Header options to verify that the RFC1108 header has not been changed, possibly removing security levels from my packet. Just a descenting opinion, I had never heard of 1108 myself. I am still in the Get Rid of AH camp myself (all though leaning farther out of that camp this morning) Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Michael Richardson [mailto:mcr@solidum.com] > Sent: Wednesday, June 14, 2000 6:06 PM > To: Michael Thomas; ipsec@lists.tislabs.com > Subject: Re: Deprecation of AH header from the IPSEC tool kit > > > > >>>>> "Michael" == Michael Thomas writes: > Michael> Michael Richardson writes: > >> There is no reduction in complexity if you create an > ESP that covers > >> the headers. The question is more simply: rm rfc2402.txt > >> > >> or not. > > Michael> [cutting to the chase] > > Michael> If the end result is an AH'less v4 but MUST AH > in v6, with > Michael> oodles of v4 implementations which already > support v4 AH, I'm > Michael> not sure that there a whole lot of motivation > deprecate it just > Michael> for v4. You can just not run AH, after all. > > At present, you can't say that you are "IPsec IPv4 > compliant" if you don't > have IPv4. At least, that is what the marketing people have > been lead to > believe, and the customers, and those you have a lot of > "checkbox-compliant" > IPv4 AH implementations. > I feel for these people, which is why I suggest that AH be moved to > "MAY" for IPv4, but not deprecated. > > I also don't want to lose AH. > > Michael> Are folks over here aware that the cellular > folks are requiring > Michael> ipv6 in next gen handsets, and all that implies > for security? > Michael> This issue is not entirely academic anymore. > > Indeed!!! > > :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Thu Jun 15 10:14:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27907; Thu, 15 Jun 2000 10:14:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06479 Thu, 15 Jun 2000 11:54:19 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14664.65048.866035.911339@xedia.com> Date: Thu, 15 Jun 2000 12:02:32 -0400 (EDT) To: Stephen.Waters@cabletron.com Cc: mcr@solidum.com, ipsec@lists.tislabs.com Subject: RE: Deprecation of AH header from the IPSEC tool kit References: <29752A74B6C5D211A4920090273CA3DC01D282D9@new-exc1.ctron.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Waters," == Waters, Stephen writes: Waters,> Although all sorts of attacks are possible, it is good to Waters,> know when they are happening. With ESP-tunnel mode, the out Waters,> header is exposed to various DOS attacks - like messing with Waters,> the TTL, frag bits etc. Waters,> For ESP-transport mode, the header and options fields are Waters,> exposed. Waters,> I think these are good reasons to use AH,... AH won't help with attacks on TTL or frag bits because those are mutable fields, they aren't authenticated because they cannot be. Yes, with ESP transport mode the header and option fields are not authenticated. If that matters it would be one thing. It doesn't matter for IPv4. For IPv6 it may matter in a very limited set of cases, though I'll want to look further before I'm convinced. paul From owner-ipsec@lists.tislabs.com Thu Jun 15 11:04:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28853; Thu, 15 Jun 2000 11:04:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06659 Thu, 15 Jun 2000 12:26:41 -0400 (EDT) From: John Ioannidis Date: Thu, 15 Jun 2000 12:35:08 -0400 (EDT) Message-Id: <200006151635.MAA11837@bual.research.att.com> To: bill.strahm@intel.com, ipsec@lists.tislabs.com, mat@cisco.com, mcr@solidum.com Subject: RE: Deprecation of AH header from the IPSEC tool kit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > about Security Policy a coworker and I came across a requirement for IPSO > (RFC1108) U.S. Department of Defense Security Options for the Internet In the presence of IPsec, IPSO (and CIPSO and stuff) are redundant. One can achieve the same effect by proper interpretation of SAs. Any system capable of verifying the AH header (so it can authenticate the IPSO) can simply make policy decisions based on the SA. /ji From owner-ipsec@lists.tislabs.com Thu Jun 15 11:20:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29089; Thu, 15 Jun 2000 11:20:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06771 Thu, 15 Jun 2000 13:03:28 -0400 (EDT) Message-Id: <200006151711.NAA03477@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: Your message of "Thu, 15 Jun 2000 14:40:19 +1000." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 15 Jun 2000 13:11:55 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Julian" == Julian Gomez writes: Julian> On Wed, 14 Jun 2000, Michael Richardson wrote: Julian> (snip) >> At present, you can't say that you are "IPsec IPv4 compliant" if you >> don't have IPv4. Julian> Don't you mean ``IPsec IPv4 compliant if you don't have AH`` ? Julian> (snip) Julian> "Premature optimisation is the root of all evil." - Knuth Yes... but correcting myself twice in an hour is a sign to stop posting :-) :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Thu Jun 15 12:45:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00938; Thu, 15 Jun 2000 12:45:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07060 Thu, 15 Jun 2000 14:08:36 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D282DF@new-exc1.ctron.com> From: "Waters, Stephen" To: Paul Koning Cc: ipsec@lists.tislabs.com Subject: RE: Deprecation of AH header from the IPSEC tool kit Date: Thu, 15 Jun 2000 19:16:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk good point Paul - bad examples. 'Interesting' attacks though.. Here's the list of immutable (unchanging/protected header fields): Version Internet Header Length Total Length Identification Protocol (This should be the value for AH.) Source Address Destination Address (without loose or strict source routing) I guess the fact that TTL/frag stuff are exposed makes you wonder what use it is protecting this lot!! These would be DOS attacks that there is little automatic defense from. Protection of option fields would be addressing a different spectrum of attack. Steve. -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Thursday, June 15, 2000 5:03 PM To: Stephen.Waters@cabletron.com Cc: mcr@solidum.com; ipsec@lists.tislabs.com Subject: RE: Deprecation of AH header from the IPSEC tool kit >>>>> "Waters," == Waters, Stephen writes: Waters,> Although all sorts of attacks are possible, it is good to Waters,> know when they are happening. With ESP-tunnel mode, the out Waters,> header is exposed to various DOS attacks - like messing with Waters,> the TTL, frag bits etc. Waters,> For ESP-transport mode, the header and options fields are Waters,> exposed. Waters,> I think these are good reasons to use AH,... AH won't help with attacks on TTL or frag bits because those are mutable fields, they aren't authenticated because they cannot be. Yes, with ESP transport mode the header and option fields are not authenticated. If that matters it would be one thing. It doesn't matter for IPv4. For IPv6 it may matter in a very limited set of cases, though I'll want to look further before I'm convinced. paul From owner-ipsec@lists.tislabs.com Thu Jun 15 13:44:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03470; Thu, 15 Jun 2000 13:44:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07338 Thu, 15 Jun 2000 15:17:57 -0400 (EDT) Date: Thu, 15 Jun 2000 11:25:39 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: Deprecation of AH header from the IPSEC tool kit In-Reply-To: <29752A74B6C5D211A4920090273CA3DC01D282D5@new-exc1.ctron.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 15 Jun 2000, Waters, Stephen wrote: > I can see the ESP authentication is fine when tunnel mode is in use - but > for peer to peer routing protocols, transport mode seems more appropriate > and the security of IP header and options could then be a requirement. If security of IP header and options is a requirement, then tunnel mode might be the better solution, despite the superficial attractiveness of transport mode. Retaining AH because transport mode needs it is rather weak, unless there are strong reasons why tunnel mode is not acceptable as an alternative. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 15 14:35:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04409; Thu, 15 Jun 2000 14:35:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07500 Thu, 15 Jun 2000 16:14:54 -0400 (EDT) Message-Id: <4.2.0.58.20000615123348.0098cbe0@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jun 2000 13:03:14 -0400 To: Ben McCann From: RJ Atkinson Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Cc: ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: <3947C9D3.15B959C7@indusriver.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:07 14/06/00 , Ben McCann wrote: >Aren't your goals met by using ESP _tunnel_ mode? No. ESP does not and can not authenticate the IP headers and IP-layer options. If the options are in a tunneled packet, the outer header's options (i.e. the ones actually used) are still unprotected. AH and ESP do not have the same security properties. The things that most folks dislike about AH would be similarly annoying if there were an ESP variant that protected the outer header. Ran rja@inet.org From owner-ipsec@lists.tislabs.com Thu Jun 15 14:39:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04476; Thu, 15 Jun 2000 14:39:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07506 Thu, 15 Jun 2000 16:15:55 -0400 (EDT) Message-Id: <4.2.0.58.20000615120731.0098ce20@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jun 2000 13:03:20 -0400 To: Michael Richardson From: RJ Atkinson Subject: Re: Deprecation of AH header from the IPSEC tool kit Cc: ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: <200006142022.QAA15540@solidum.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:22 14/06/00 , Michael Richardson wrote: > The point that Steve Bellovin keeps making, and which he has written about, is that AH does not provide much more in the way of >authentication that ESP does not (at least for IPv4). There are differences in semantics between AH and ESP: - AH permits hop-by-hop IP-layer option authentication. - AH also permits end-to-end IP-layer option authentication. - ESP does not protect IP-layer options at all. Tunneling the options is not relevant since the point of authenticating an IP-layer option is to authenticate the outer header option that will be examined during transit from source to destination. >The outer headers >are all either irrelevant, or can be derived from the SPD, so >you don't have to trust them. A counter-example is the Source Routing header, when can be authenticated hop-by-hop with AH and cannot be authenticated at all by ESP. Source routing attacks can be interesting and subtle. Another counter-example, which is supported in shipping product by major workstation vendors (e.g. Sun, HP), though it is not on the IETF standards-track at present are the various IP Security Options.[1] > I believe that there are other things that AH provides (like the >guarantee that the contents are not encrypted and therefore can be audited), >and things that will be defined in IPv6-extension land that will make AH >a useful thing to keep in the spec, just not MUST it. I mostly agree, but would tweak this slightly. The real issue here is that VPN Product vendors currently dominate the IPsec WG. VPN vendors don't want to support AH and aren't building IPv6 products, yet they want to claim to be fully "IPsec Compliant" (which is marketing speak; I have no clue what it really means). In short, some of the impetus behind this proposal is to solve a marketing problem -- most of the remainder is largely smoke-screen. So the thing to do is to edit the must-implement text clauses such that IPv4 VPN products (i.e. not implementing IPv6) do not need to implement AH and can claim to be fully compliant for marketing purposes. Then, AH could be implemented when/where it is sensible (e.g. in all IPv6 boxen ,so that IPv6 options can be protected hop-by-hop; in routers where vendors continue to run into as-implemented export controls that prevent easy licencing of authentication-only ESP [2]). AH should continue to be mandatory in all IPv6 implementations, so that security-sensitive IPv6 options can be protected end-to-end and hop-by-hop. The lack of ability to authenticate IPv4 options constrained the IPv4 design -- this should be avoided in IPv6. Even if one doesn't think the current IPv6 options are security relevant, one ought not constrain the protocol such that such options are forbidden for all time. It seems like a bug that the IPng WG isn't involved in this discussion. I only caught this myself because sundry routing protocol WGs were copied. Thanks to Michael for writing one of the more clear and crisp notes on this thread. Ran rja@inet.org [1] Unfortunately, the as-deployed IP Security Option is also processed by trusted devices that don't (and won't in their lifetime) support AH, so one can't just cease transmitting the IP Security Option and rely on sensitivity labels within the Security Association. AH can and is used to provide "firewall-like" checking externally before passing the IPSO/CIPSO label to the trusted device. I don't claim this is a good design, but it is deployed today and won't be going away for at least several years. [2] I continue to hear about the US making highly inconsistent decisions about authentication-only ESP. I have heard recent reports of licence approval and also recent reports of licence rejection. Router/switch vendors need to be able to use AH for routing protocol authentication because there are NEVER any export or import licencing issues with AH in ANY country. From owner-ipsec@lists.tislabs.com Thu Jun 15 18:57:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20268; Thu, 15 Jun 2000 18:57:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08367 Thu, 15 Jun 2000 20:29:32 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14665.30412.271672.844140@thomasm-u1.cisco.com> Date: Thu, 15 Jun 2000 17:37:32 -0700 (PDT) To: RJ Atkinson Cc: Michael Richardson , ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: Deprecation of AH header from the IPSEC tool kit In-Reply-To: <4.2.0.58.20000615120731.0098ce20@avarice.inner.net> References: <4.2.0.58.20000615120731.0098ce20@avarice.inner.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RJ Atkinson writes: > The real issue here is that VPN Product vendors currently dominate > the IPsec WG. VPN vendors don't want to support AH and aren't building > IPv6 products, yet they want to claim to be fully "IPsec Compliant" > (which is marketing speak; I have no clue what it really means). > In short, some of the impetus behind this proposal is to solve a > marketing problem -- most of the remainder is largely smoke-screen. I see. This couldn't have anything to do with header bandwidth overhead concerns, not to mention the near mind-bending complexity of 2 degrees of freedom with ah/esp/transport/tunnel and its interaction with things that need to consider IP headers. sign me Smoke E. Screen From owner-ipsec@lists.tislabs.com Thu Jun 15 20:26:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA02390; Thu, 15 Jun 2000 20:26:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA08656 Thu, 15 Jun 2000 21:51:01 -0400 (EDT) Date: Thu, 15 Jun 2000 18:59:30 -0700 From: Paul Krumviede Subject: Re: Deprecation of AH header from the IPSEC tool kit In-reply-to: <14665.30412.271672.844140@thomasm-u1.cisco.com> To: Michael Thomas Cc: ipsec@lists.tislabs.com Message-id: <3317863032.961095570@[10.0.1.53]> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --On Thursday, 15 June, 2000 17:37 -0700 Michael Thomas wrote: > RJ Atkinson writes: > > The real issue here is that VPN Product vendors currently dominate > > the IPsec WG. VPN vendors don't want to support AH and aren't > building > IPv6 products, yet they want to claim to be fully "IPsec > Compliant" > (which is marketing speak; I have no clue what it really > means). > In short, some of the impetus behind this proposal is to > solve a > marketing problem -- most of the remainder is largely > smoke-screen. > > I see. This couldn't have anything to do with > header bandwidth overhead concerns, not to mention > the near mind-bending complexity of 2 degrees of > freedom with ah/esp/transport/tunnel and its > interaction with things that need to consider > IP headers. The original message on this thread posited the use of AH for routing protocols. For that use, I would guess that header bandwidth isn't much of an issue. Consider BGP4 on 2.4 (or 9.6) Gbps links... Ignoring degenerate cases such as route flaps or broken implementations, just how much routing traffic is there in most situations where one would want to use something like AH? -paul From owner-ipsec@lists.tislabs.com Thu Jun 15 23:45:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA17667; Thu, 15 Jun 2000 23:45:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA09037 Fri, 16 Jun 2000 01:24:10 -0400 (EDT) Message-Id: <200006160532.BAA08121@bcn.East.Sun.COM> Date: Thu, 15 Jun 2000 22:32:53 -0700 (PDT) From: Radia Perlman Reply-To: Radia Perlman Subject: Re: Deprecation of AH header from the IPSEC tool kit To: OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tY47jNmd547KooeJYN/iYw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ran said: >> A counter-example is the Source Routing header, which can >> be authenticated hop-by-hop with AH ... How do you authenticate something hop-by-hop when the key is only known end-to-end? Are you maybe assuming hop-by-hop IPSec tunnels between the routers listed in the source route header? Radia From owner-ipsec@lists.tislabs.com Fri Jun 16 01:07:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA20858; Fri, 16 Jun 2000 01:07:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09372 Fri, 16 Jun 2000 02:54:28 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A544@baltimore.com> From: Chris Trobridge To: John Ioannidis , bill.strahm@intel.com, ipsec@lists.tislabs.com, mat@cisco.com, mcr@solidum.com Subject: RE: Deprecation of AH header from the IPSEC tool kit Date: Fri, 16 Jun 2000 08:02:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: John Ioannidis [mailto:ji@research.att.com] > > > about Security Policy a coworker and I came across a > requirement for IPSO > > (RFC1108) U.S. Department of Defense Security Options for > the Internet > > In the presence of IPsec, IPSO (and CIPSO and stuff) are > redundant. One > can achieve the same effect by proper interpretation of SAs. > Any system > capable of verifying the AH header (so it can authenticate the IPSO) > can simply make policy decisions based on the SA. > > /ji The security label can be used to select the SA in the first place. Chris From owner-ipsec@lists.tislabs.com Fri Jun 16 01:07:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA20878; Fri, 16 Jun 2000 01:07:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09327 Fri, 16 Jun 2000 02:41:59 -0400 (EDT) Date: Fri, 16 Jun 2000 16:49:51 +1000 (EST) From: KokMing Subject: Re: Deprecation of AH header from the IPSEC tool kit In-reply-to: <14665.30412.271672.844140@thomasm-u1.cisco.com> To: ipsec@lists.tislabs.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk snip.. > > The real issue here is that VPN Product vendors currently dominate > > the IPsec WG. VPN vendors don't want to support AH and aren't building > > IPv6 products, yet they want to claim to be fully "IPsec Compliant" > > (which is marketing speak; I have no clue what it really means). > > In short, some of the impetus behind this proposal is to solve a > > marketing problem -- most of the remainder is largely smoke-screen. > > I see. This couldn't have anything to do with > header bandwidth overhead concerns, not to mention > the near mind-bending complexity of 2 degrees of > freedom with ah/esp/transport/tunnel and its > interaction with things that need to consider > IP headers. Wouldn't it be better to enforce something like: "ESP can never be used without AH", or "One must apply encryption before authentication". And if I'm not mistaken, the aim of IPsec is to provide high quality security services for IP (note: NOT VPN). Complex variations in the name of flexibility aren't purposeful. This may sound harsh, but complex things don't last (look at OSI model). Kokming Ang ISRC Queensland University of Technology From owner-ipsec@lists.tislabs.com Fri Jun 16 01:14:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA21359; Fri, 16 Jun 2000 01:14:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09406 Fri, 16 Jun 2000 02:59:18 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A545@baltimore.com> From: Chris Trobridge To: Radia Perlman , ipsec@lists.tislabs.com Subject: RE: Deprecation of AH header from the IPSEC tool kit Date: Fri, 16 Jun 2000 08:07:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Ran said: > > >> A counter-example is the Source Routing > header, which can > >> be authenticated hop-by-hop with AH ... > > How do you authenticate something hop-by-hop when the key is only > known end-to-end? Are you maybe assuming hop-by-hop IPSec > tunnels between the > routers listed in the source route header? > > Radia > Intermediate hops can't use the end to end AH to verify the datagram. Of course the end point can check that the source route hasn't been modified in transit. I'm not sure what attacks this prevents beyond denial of service though? Chris From owner-ipsec@lists.tislabs.com Fri Jun 16 06:47:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10494; Fri, 16 Jun 2000 06:47:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10108 Fri, 16 Jun 2000 08:21:09 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E3754C@eseis06nok> To: ipsec@lists.tislabs.com Subject: Phase 2 IDs Date: Fri, 16 Jun 2000 15:29:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What are the allowed ID type in Phase 2. I take that all are allowed in phase 1, but phase 2 don't look like can accept FQDN types for instance. Can anyone enumerate all the supported type in phase 2. It'd be a great help. I'm pretty sure that types ID_IPV4_ADDR, ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR, ID_IPV6_ADDR_SUBNET are accepted, but I'm not sure about the rest. Here's the list of all the type so that no one has to check it from the RFC: ID_IPV4_ADDR 1 ID_FQDN 2 ID_USER_FQDN 3 ID_IPV4_ADDR_SUBNET 4 ID_IPV6_ADDR 5 ID_IPV6_ADDR_SUBNET 6 ID_IPV4_ADDR_RANGE 7 ID_IPV6_ADDR_RANGE 8 ID_DER_ASN1_DN 9 ID_DER_ASN1_GN 10 ID_KEY_ID 11 Thanks! Toni -----Original Message----- From: EXT Chris Trobridge [mailto:CTrobridge@baltimore.com] Sent: 16. June 2000 10:08 To: Radia Perlman; ipsec@lists.tislabs.com Subject: RE: Deprecation of AH header from the IPSEC tool kit > Ran said: > > >> A counter-example is the Source Routing > header, which can > >> be authenticated hop-by-hop with AH ... > > How do you authenticate something hop-by-hop when the key is only > known end-to-end? Are you maybe assuming hop-by-hop IPSec > tunnels between the > routers listed in the source route header? > > Radia > Intermediate hops can't use the end to end AH to verify the datagram. Of course the end point can check that the source route hasn't been modified in transit. I'm not sure what attacks this prevents beyond denial of service though? Chris From owner-ipsec@lists.tislabs.com Fri Jun 16 08:10:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14828; Fri, 16 Jun 2000 08:10:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10284 Fri, 16 Jun 2000 09:22:40 -0400 (EDT) Reply-To: From: "Vinod Porwal" To: Subject: IKECFG draft Date: Fri, 16 Jun 2000 19:10:07 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can somebody tell me where I can get the expired IKECFG draft : draft-ietf-ipsec-isakmp-mode-cfg-06.txt Regards, Vinod Porwal. From owner-ipsec@lists.tislabs.com Fri Jun 16 08:55:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15950; Fri, 16 Jun 2000 08:55:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10509 Fri, 16 Jun 2000 10:15:35 -0400 (EDT) Message-Id: <200006152215.PAA22277@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2857 on HMAC-RIPEMD-160-96 within ESP and AH Cc: rfc-ed@ISI.EDU, ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 15 Jun 2000 15:15:53 -0700 From: RFC Editor Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2857 Title: The Use of HMAC-RIPEMD-160-96 within ESP and AH Author(s): A. Keromytis, N. Provos Status: Standards Track Date: June 2000 Mailbox: angelos@dsl.cis.upenn.edu, provos@citi.umich.edu Pages: 7 Characters: 13544 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc2857.txt This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. This document is a product of the IP Security Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000615151307.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2857 --OtherAccess Content-Type: Message/External-body; name="rfc2857.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000615151307.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jun 16 08:55:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15962; Fri, 16 Jun 2000 08:55:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10515 Fri, 16 Jun 2000 10:16:34 -0400 (EDT) Message-Id: <4.2.0.58.20000615205547.00971460@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 15 Jun 2000 21:02:36 -0400 To: Michael Thomas From: RJ Atkinson Subject: Re: Deprecation of AH header from the IPSEC tool kit Cc: ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: <14665.30412.271672.844140@thomasm-u1.cisco.com> References: <4.2.0.58.20000615120731.0098ce20@avarice.inner.net> <4.2.0.58.20000615120731.0098ce20@avarice.inner.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 20:37 15/06/00 , Michael Thomas wrote: > I see. This couldn't have anything to do with > header bandwidth overhead concerns, Overhead is about the same for ESP-Auth-only and AH. >not to mention the near mind-bending complexity of 2 degrees of > freedom with ah/esp/transport/tunnel So use ESP-with-auth-and-encrypt to build VPNs -- if you don't need the properties available only with AH. The NRL 4.4-BSD code for ESP and AH was simple, tidy, and written in about 3 weeks by an undergraduate EE student (from the old RFCs). It worked. It included both transport and tunnel mode and multiple algorithms. A fair chunk of the coding time was spent dealing with mbuf-isms not present in IOS. The NRL code had PF_KEY for key management, but did not have ISAKMP/IKE. I strongly disagree that it is "near mind-bending complexity", using the old NRL code as an existence proof of this (both in code size and in terms of the time it originally took to code up back in 1995). >and its > interaction with things that need to consider > IP headers. If you really want to simplify an IPsec implementation, there are better targets out there than AH. Ran rja@inet.org From owner-ipsec@lists.tislabs.com Fri Jun 16 09:37:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18190; Fri, 16 Jun 2000 09:37:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10941 Fri, 16 Jun 2000 11:07:18 -0400 (EDT) Message-Id: <200006161507.LAA10937@lists.tislabs.com> Date: Fri, 16 Jun 2000 11:09:34 +0500 (EDT) From: Charles Lynn To: Radia Perlman cc: OSPF@discuss.microsoft.com, ipsec@lists.tislabs.com, isis-wg@juniper.net Subject: Re: Deprecation of AH header from the IPSEC tool kit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia, > How do you authenticate something hop-by-hop when the key is only known > end-to-end? Are you maybe assuming hop-by-hop IPSec tunnels between the > routers listed in the source route header? Yes, that would be the case (there would be multiple keys, one for each hop being protected, and "one" for end-to-end protection, if that were also included). Here is a picture. Note that the Hop-by-Hop IPsec might be ESP instead of AH; there is nothing (IMHO :-) worth protecting in the IPv6 header in this scenario (unless using the mobile IP scenario that has been described on the list). <----------------------------- AH e --------------------------> <--- AH 1 ---> <--- ESP ---> <--- AH 2 ---> <--- AH 3 ---> Routing Domain A Routing Domain B ............................... .............. +------+ : +--------+ +--------+ : : +--------+ : +------+ | Host |______| Router |______| Router |______| Router |______| Host | | 1 | : | Aa | | Ab | : : | Bc | : | 2 | +------+ : +--------+ +--------+ : : +--------+ : +------+ :.............................: :............: ^ ^ ^ ^ | | | | | +-------+ (Really | | | | IPv6 | paranoid) | | | | Aa->Ab| | | | +-------+ | | | | ESP | | | | | Aa:Ab | | | +-------+ +-------+ +-------+ +-------+ | IPv6 | | IPv6 | | IPv6 | | IPv6 | | H1->A | | H1->B | | H1->B | | H1->H2| +-------+ | | +-------+ +-------+ Hop | AH 1 | | | | AH 2 | | AH 3 | by | H1:Aa | | | | Ab:Bc | | H1:Aa | Hop +-------+ +-------+ +-------+ +-------+ |Routing| |Routing| |Routing| |Routing| |2 >B | |1 A | |1 A | |0 A | | H2 | | >H2 | | >H2 | | B | +-------+ +-------+ +-------+ +-------+ End | AH e | | AH e | | AH e | | AH e | to | H1:H2 | | H1:H2 | | H1:H2 | | H1:H2 | End +-------+ +-------+ +-------+ +-------+ |TCP/UDP| |TCP/UDP| |TCP/UDP| |TCP/UDP| +-------+ +-------+ +-------+ +-------+ Charlie From owner-ipsec@lists.tislabs.com Fri Jun 16 10:16:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19529; Fri, 16 Jun 2000 10:16:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11006 Fri, 16 Jun 2000 11:26:00 -0400 (EDT) From: John Ioannidis Date: Fri, 16 Jun 2000 11:34:27 -0400 (EDT) Message-Id: <200006161534.LAA09335@bual.research.att.com> To: Radia.Perlman@East.Sun.COM, clynn@bbn.com Subject: Re: Deprecation of AH header from the IPSEC tool kit Cc: OSPF@discuss.microsoft.com, ipsec@lists.tislabs.com, isis-wg@juniper.net Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Here is a picture. Note that the Hop-by-Hop IPsec might be ESP > instead of AH; there is nothing (IMHO :-) worth protecting in the IPv6 > header in this scenario (unless using the mobile IP scenario that has > been described on the list). > > <----------------------------- AH e --------------------------> > <--- AH 1 ---> <--- ESP ---> <--- AH 2 ---> <--- AH 3 ---> > If you are going to go through all this trouble, there is no point in using hop-by-hop routing headers; just set up IP tunnels from each hop to the next and be done with it! /ji From owner-ipsec@lists.tislabs.com Fri Jun 16 12:01:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22192; Fri, 16 Jun 2000 12:01:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11624 Fri, 16 Jun 2000 13:33:55 -0400 (EDT) Message-Id: <4.2.0.58.20000616071416.00974e60@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 16 Jun 2000 13:17:25 -0400 To: Radia Perlman From: RJ Atkinson Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Cc: OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net In-Reply-To: <200006160532.BAA08121@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:32 16/06/00 , Radia Perlman wrote: >Ran said: > > >> A counter-example is the Source Routing header, which can > >> be authenticated hop-by-hop with AH ... > >How do you authenticate something hop-by-hop when the key is only >known end-to-end? Nothing in the ESP or AH specs prevent the key from being known at an intermediate point. So the assumption that the key is only known end-to-end isn't always true. Kerberos turns out to be a good way to distribute keys for this application. At least one implementation of ESP/AH can use Kerberos for key management. (I separately hope that use of Kerberos will get standardised in the IETF for interoperability reasons). Several major ISPs (e.g. UUnet) have widespread deployment of Kerberos in their network, including in routers. >Are you maybe assuming hop-by-hop IPSec tunnels between the >routers listed in the source route header? No. Ran rja@inet.org From owner-ipsec@lists.tislabs.com Sun Jun 18 06:36:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08334; Sun, 18 Jun 2000 06:36:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16517 Sun, 18 Jun 2000 07:44:10 -0400 (EDT) Reply-To: From: "Vinod Porwal" To: Subject: Mode Config and IKECFG ? Date: Sun, 18 Jun 2000 17:31:42 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have seen the terms Mode Config and IKECFG being used on this list. Are these terms refer to the same method/draft ? If not, where will I find information on Mode Config ? Thanks in advance, Vinoid Porwal From owner-ipsec@lists.tislabs.com Mon Jun 19 08:02:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09658; Mon, 19 Jun 2000 08:02:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20432 Mon, 19 Jun 2000 09:36:14 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14670.9147.848439.1762@xedia.com> Date: Mon, 19 Jun 2000 09:44:27 -0400 (EDT) To: clynn@bbn.com Cc: Radia.Perlman@East.Sun.COM, OSPF@discuss.microsoft.com, ipsec@lists.tislabs.com, isis-wg@juniper.net Subject: Re: Deprecation of AH header from the IPSEC tool kit References: <200006161507.LAA10937@lists.tislabs.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Charles" == Charles Lynn writes: Charles> Radia, >> How do you authenticate something hop-by-hop when the key is only >> known end-to-end? Are you maybe assuming hop-by-hop IPSec tunnels >> between the routers listed in the source route header? Charles> Yes, that would be the case (there would be multiple keys, Charles> one for each hop being protected, and "one" for end-to-end Charles> protection, if that were also included). I suppose that's possible in some hypothetical security protocol. It doesn't even come close to anything in the IPsec architecture, though. There are many reasons for that. For example, IPsec is a two party protocol, applying protection between the two endpoints of a conversation. Second, if it wasn't already obvious from looking at IPsec, it becomes highly obvious when you look at IKE. Third, AH (RFC 2402) explicitly states that source route headers are NOT protected by AH. Take a look at the list of options protected by AH, as stated in appendix A of the RFC. That list is surprisingly small and includes none of the well-known options (to the extent that any option can qualify for that designation). From owner-ipsec@lists.tislabs.com Mon Jun 19 08:02:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09659; Mon, 19 Jun 2000 08:02:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20372 Mon, 19 Jun 2000 09:26:29 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14670.8566.842854.616416@xedia.com> Date: Mon, 19 Jun 2000 09:34:46 -0400 (EDT) To: rja@inet.org Cc: bmccann@indusriver.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> <4.2.0.58.20000615123348.0098cbe0@avarice.inner.net> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "RJ" == RJ Atkinson writes: RJ> At 14:07 14/06/00 , Ben McCann wrote: >> Aren't your goals met by using ESP _tunnel_ mode? RJ> No. ESP does not and can not authenticate the IP headers and RJ> IP-layer options. If the options are in a tunneled packet, the RJ> outer header's options (i.e. the ones actually used) are still RJ> unprotected. I believe you missed the point of the proposal. The discussion on AH has been around transport mode. I haven't seen any argument at all that touches on AH in tunnel mode. After all, the arguments (IP options, authenticating IP header content) don't apply to communication between security gateways. So the point is this: currently there are some cases where people feel they want to use AH in transport mode, the reason for AH being that there supposedly are headers or options that require strong integrity. Clearly, you get the same integrity -- or rather, more of it and more easily -- by wrapping the to-be-protected packet in an IPsec tunnel. Since the fields requiring protection are at that point in the INNER header, not the outer header, they are indeed protected if ESP is used. paul From owner-ipsec@lists.tislabs.com Mon Jun 19 08:15:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10362; Mon, 19 Jun 2000 08:15:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20526 Mon, 19 Jun 2000 10:01:07 -0400 (EDT) Message-Id: <3.0.5.32.20000616200927.00c4a960@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 16 Jun 2000 20:09:27 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Phase 2 IDs In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A02E3754C@eseis06nok> 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 lists.tislabs.com id OAA11854 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 15:29 16.6.2000 +0300, you wrote: > What are the allowed ID type in Phase 2. I take that all are allowed >in phase 1, but phase 2 don't look like can accept FQDN types for instance. >Can anyone enumerate all the supported type in phase 2. It'd be a great >help. I'm pretty sure that types ID_IPV4_ADDR, ID_IPV4_ADDR_SUBNET, >ID_IPV6_ADDR, ID_IPV6_ADDR_SUBNET are accepted, but I'm not sure about the >rest. > Here's the list of all the type so that no one has to check it from >the RFC: > > ID_IPV4_ADDR 1 > ID_FQDN 2 > ID_USER_FQDN 3 > ID_IPV4_ADDR_SUBNET 4 > ID_IPV6_ADDR 5 > ID_IPV6_ADDR_SUBNET 6 > ID_IPV4_ADDR_RANGE 7 > ID_IPV6_ADDR_RANGE 8 > ID_DER_ASN1_DN 9 > ID_DER_ASN1_GN 10 > ID_KEY_ID 11 > > Thanks! > >Toni > 1,4,5,6,7,8. As there are two IDs per QM, you can mix 1,4,7 or 5,6,8 freely. One ID IPv4 and the other IPv6 does not make sense. J�rn From owner-ipsec@lists.tislabs.com Mon Jun 19 08:27:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11130; Mon, 19 Jun 2000 08:27:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20669 Mon, 19 Jun 2000 10:15:26 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14670.11513.608392.215574@xedia.com> Date: Mon, 19 Jun 2000 10:23:53 -0400 (EDT) To: rja@inet.org Cc: Radia.Perlman@East.Sun.COM, OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit References: <200006160532.BAA08121@bcn.East.Sun.COM> <4.2.0.58.20000616071416.00974e60@avarice.inner.net> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "RJ" == RJ Atkinson writes: RJ> At 01:32 16/06/00 , Radia Perlman wrote: >> Ran said: >> >> >> A counter-example is the Source Routing header, which can >> be >> authenticated hop-by-hop with AH ... >> >> How do you authenticate something hop-by-hop when the key is only >> known end-to-end? RJ> Nothing in the ESP or AH specs prevent the key from being known RJ> at an intermediate point. So the assumption that the key is only RJ> known end-to-end isn't always true. I don't know about other people, but I'm not about to even consider the notion of a "security" protocol where the key is known all over the path. No way. paul From owner-ipsec@lists.tislabs.com Mon Jun 19 08:28:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11217; Mon, 19 Jun 2000 08:28:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20540 Mon, 19 Jun 2000 10:02:07 -0400 (EDT) From: vvolpe@cisco.com Message-ID: <8D0E009FB517D41183C60090277A3DDE0F4F5E@liam.cisco.com> To: ipsec@lists.tislabs.com Subject: INVALID SPI Notify Date: Fri, 16 Jun 2000 15:48:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I just noticed that the Invalid SPI notify message in the notify draft is > intended to indicate an unacceptable SPI received during a Phase 2 > negotiation. Can Invalid SPI also be used when an IPsec packet is > received on an unknown SPI, assuming a Phase 1 SA is established to the > peer and the message can be encrypted. If the answer is yes, what is the > format everyone is using? If the answer is no, then has this changed > recently? > > Victor > > From owner-ipsec@lists.tislabs.com Mon Jun 19 11:03:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21838; Mon, 19 Jun 2000 11:03:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21369 Mon, 19 Jun 2000 12:30:52 -0400 (EDT) Message-ID: <394E4CAA.355F8628@redcreek.com> Date: Mon, 19 Jun 2000 09:39:06 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: vvolpe@cisco.com CC: ipsec@lists.tislabs.com Subject: Re: INVALID SPI Notify References: <8D0E009FB517D41183C60090277A3DDE0F4F5E@liam.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Victor, vvolpe@cisco.com wrote: > > > I just noticed that the Invalid SPI notify message in the notify draft is > > intended to indicate an unacceptable SPI received during a Phase 2 > > negotiation. Can Invalid SPI also be used when an IPsec packet is > > received on an unknown SPI, assuming a Phase 1 SA is established to the > > peer and the message can be encrypted. If the answer is yes, what is the > > format everyone is using? If the answer is no, then has this changed > > recently? > > > > Victor Actually, I meant to propose this to the group a few weeks ago, as I am planning on rev'ing the notify messages draft soon. We have two options: either add another notify message for this, or expand the use of the existing INVALID-SPI message. A few of us think that expanding the use of the existing message is simplest, and could be accomplished by simply setting the DOI to 0 (isakmp) when it's phase 1, and setting it to 1 (ipsec) when it's for phase 2. Does anyone have any comments on this? Scott From owner-ipsec@lists.tislabs.com Mon Jun 19 12:08:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24666; Mon, 19 Jun 2000 12:08:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21707 Mon, 19 Jun 2000 13:33:15 -0400 (EDT) Message-ID: <394E59D3.5114259F@indusriver.com> Date: Mon, 19 Jun 2000 13:35:15 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: vvolpe@cisco.com, ipsec@lists.tislabs.com Subject: Re: INVALID SPI Notify References: <8D0E009FB517D41183C60090277A3DDE0F4F5E@liam.cisco.com> <394E4CAA.355F8628@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When would IKE complain of an invalid SPI during a phase 2 exchange? Its a 32-bit random number selected by the sender. The only case I can see is if the SPI was less than 256. (These values, I believe, are forbidden in IPSEC). Should IKE treat an _illegal_ value for the SPI during Phase 2 as some kind of protocol error that is distinct from INVALID-SPI? If it did, then INVALID-SPI can be unambiguously used by IPSEC to report receipt of an IPSEC packet whose SPI doesn't exist in the SAD. Use of the DOI to select between ISAKMP and IPSEC also works. I'm just curious why and when IKE (isakmp) is ever required to report INVALID-SPI. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Mon Jun 19 13:11:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26437; Mon, 19 Jun 2000 13:11:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22028 Mon, 19 Jun 2000 14:35:54 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14670.27117.456112.629255@xedia.com> Date: Mon, 19 Jun 2000 14:43:57 -0400 (EDT) To: rja@inet.org Cc: OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit References: <200006160532.BAA08121@bcn.East.Sun.COM> <4.2.0.58.20000616071416.00974e60@avarice.inner.net> <4.2.0.58.20000619132241.00981f00@avarice.inner.net> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "RJ" == RJ Atkinson writes: RJ> At 10:23 19/06/00 , Paul Koning wrote: Nothing in the ESP or AH RJ> specs prevent the key from being known at an intermediate point. RJ> So the assumption that the key is only known end-to-end isn't RJ> always true. >> I don't know about other people, but I'm not about to even >> consider the notion of a "security" protocol where the key is >> known all over the path. No way. RJ> Paul, RJ> I didn't say "all over the path". I said "at an intermediate RJ> point". The distinction is crucial. RJ> It is quite reasonable to authenticate traffic as it crosses an RJ> administrative boundary as part of implementing a administrative RJ> security policy. This is roughly the function of most stateful RJ> inspection firewalls, though those generally have limited RJ> assurance because they cannot authenticate the packet headers. RJ> With AH authentication, a firewall or security gateway can RJ> achieve much higher assurance than without AH authentication. I RJ> am aware of folks working on such products. Fair enough. It's common enough to put a security gateway in the same box as a firewall. For example, our own Access Point products do that today. Then again, they do that with ESP, which does all that is needed for this application. RJ> Also note that AH can be used with public-key digital signatures, RJ> rather than the commonly used symmetric hash. Huh? I see nothing of that in RFC 2402. In any case, given the performance (or rather, lack thereof) of digital signatures, it's unlikely that any extensions to AH or ESP to use digital signatures on a per-packet basis would see any significant use. paul From owner-ipsec@lists.tislabs.com Mon Jun 19 13:39:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27008; Mon, 19 Jun 2000 13:39:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22110 Mon, 19 Jun 2000 15:08:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <14670.27117.456112.629255@xedia.com> References: <200006160532.BAA08121@bcn.East.Sun.COM> <4.2.0.58.20000616071416.00974e60@avarice.inner.net> <4.2.0.58.20000619132241.00981f00@avarice.inner.net> <14670.27117.456112.629255@xedia.com> Date: Mon, 19 Jun 2000 15:09:30 -0400 To: Paul Koning From: Stephen Kent Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Cc: rja@inet.org, OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net Content-Type: multipart/alternative; boundary="============_-1250680259==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1250680259==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Paul, The following text is from 2402: 3.2 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. So, there is explicit mention of the potential use of digital signatures with AH. Steve --============_-1250680259==_ma============ Content-Type: text/enriched; charset="us-ascii" Paul, The following text is from 2402: Courier_New3.2 Authentication Algorithms The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). TimesFor multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. So, there is explicit mention of the potential use of digital signatures with AH. Steve --============_-1250680259==_ma============-- From owner-ipsec@lists.tislabs.com Mon Jun 19 13:50:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27202; Mon, 19 Jun 2000 13:50:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22168 Mon, 19 Jun 2000 15:25:29 -0400 (EDT) X-Authentication-Warning: janpc-home.cisco.com: vilhuber owned process doing -bs Date: Mon, 19 Jun 2000 12:33:32 -0700 (PDT) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: Next Bakeoff (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here's a note from Anita, that she asked me to pass on to the ipsec list. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 ---------- Forwarded message ---------- Date: Fri, 16 Jun 2000 15:13:25 -0700 From: Anita Freeman The next VPN Interoperability Workshop will be in San Diego at the Paradise Point Resort starting September 17 (set up day) through September 22, 2000. Please watch the mailing list for the application. Thanks, Anita From owner-ipsec@lists.tislabs.com Mon Jun 19 13:52:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27248; Mon, 19 Jun 2000 13:52:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22260 Mon, 19 Jun 2000 15:34:12 -0400 (EDT) Message-Id: <4.2.0.58.20000619130952.009e7780@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 19 Jun 2000 13:22:29 -0400 To: Paul Koning From: RJ Atkinson Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Cc: ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: <14670.8566.842854.616416@xedia.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> <4.2.0.58.20000615123348.0098cbe0@avarice.inner.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:34 19/06/00 , Paul Koning wrote: >I believe you missed the point of the proposal. > >The discussion on AH has been around transport mode. There seem to be several discussions. Note that, like many, I'm not on the IPsec list, but am on the OSPF and IS-IS lists. >I haven't seen >any argument at all that touches on AH in tunnel mode. After all, the >arguments (IP options, authenticating IP header content) don't apply >to communication between security gateways. The whole "tunnel-mode" vs "transport-mode" distinction is partly artificial, at least in IPng Land and arguably in IPv4-land as well. If one applies "transport-mode" to an IP packet containing IP-in-IP or Ethernet-in-IP, the result is approximately the same as "tunnel-mode". The primary difference is in the {esp,ah}_input() code where at tunnel decapsulation time, the inner IP header values need to be validated against the configured tunnel properties. This security check should apply to *any* IP-in-IP tunnel, not just a tunnel with ESP or AH. >So the point is this: currently there are some cases where people feel >they want to use AH in transport mode, the reason for AH being that >there supposedly are headers or options that require strong integrity. > >Clearly, you get the same integrity -- or rather, more of it and more >easily -- by wrapping the to-be-protected packet in an IPsec tunnel. Actually this is not the case. The point is that the integrity is needed for the options and headers that are *actually used* along the forwarding path (e.g. Source Routing headers/options). Any option or header inside a tunnel is NOT (by definition) used along the forwarding path, so ESP can never protect the IP-layer headers/options. >Since the fields requiring protection are at that point in the INNER >header, not the outer header, they are indeed protected if ESP is >used. One goal of AH (and difference from ESP) is to protect the fields at the IP-layer (headers or options) that are *actually used* while the packet is transiting the network. ESP cannot protect these headers in any case whatsoever. Again, the primary current users of AH are NOT building VPNs of any sort. They are using AH to provide integrity protection for routing protocols or similar information that does not need confidentiality, but does need strong authentication/integrity. The other primary current AH users are IPv6 users relying on end-to-end (i.e. host to host, no security gateway whatsoever) integrity. All IPv6 hosts have ESP and AH implemented (most using danmcd's BSD Sockets API extensions or similar), so the IPv6 world is substantially different from IPv4 (where few host currently ship with ESP or AH or even a proprietary security schema). Regards, Ran rja@inet.org From owner-ipsec@lists.tislabs.com Mon Jun 19 14:43:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28090; Mon, 19 Jun 2000 14:43:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22521 Mon, 19 Jun 2000 16:18:39 -0400 (EDT) Message-ID: <20000619202646.9220.qmail@web4001.mail.yahoo.com> Date: Mon, 19 Jun 2000 13:26:46 -0700 (PDT) From: Justin Young Subject: overcomplicated framework for multicast security without real value To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My company is working on a project for Internet streaming applications. I just finished reading "A Framework for Group Key Management for Multicast Security" and like to share some thoughts. Although authors are aware of the challenges of multicast security and understand the requirements imposed by different multicast applications, this framework is nearly useless in the real world. It's too complicated to implement and deploy, and provides little value in return for most applications. While ISPs may celebrate the opportunity for increasing the number on subscribers' monthly bill, the introduction of "trunk region" complicates the overall multicast security infrastructure and makes secured data distribution more vulnerable since it breaks the end-to-end security model. Some people may not want any third-party (ISP) get involved in the sensitive data transmission. And for most applications (as I will discuss below), this approach doesn't improve the scalability or performance after all. Authors claim that the primary advantages of the framework are (1) more scalable (2) reduced complexity, and illustrate them on two examples: Pay-per-view and Confidential Conferencing. Now let's look at them one by one. Case 1 - Pay-per-view (one-to-many): as the name says, you have to pay for per movie/live sport event/TV show and it's not refundable once you make the payment (even you change your mind after only ten minutes because the movie sucks). After each show, you have to pay again to register for another one. That means the lifetime of membership is fixed. All the members have to renew their session key for the complete next lifetime. In another word, the application server or key distribution server only has to maintain single session key for everybody within a single life time (bounded by show time) even some viewers may switch channel or leave their computer. This type of service is the majority of future multicast applications. The nature of those applications is that all members have to renew their group keys for each event. In this case, the proposed framework doesn't provide any value if not making it worse. You may argue that different members may have different lifetime, for example some couch potato may register a whole year for every pay-per-view events (if permitted by the ASP). But in this case, it makes better sense for ASPs to create several different membership levels and separate the management for each level (within application-specific context). In the near future, most streaming ASPs will most likely offer two types of multicast streaming services: monthly viewing service and pay-per-view. Time Warner has been doing it for years in its cable network. It seems this framework can be used to manage monthly viewing service. Members may call up and open/close their accounts anytime during the month. But is it really worth going through all that trouble while you can simply renew the key for everybody once every day (you have to renew it sooner or later anyway for security reason)? The point is that the timing granularity requirement is loose. Case 2 - Confidential Conferencing (many-to-many): the framework fits better for this type of application. But the nature of conference is that only limited number of people will attend. So you don't need scalability. You may ask: ever attend a meeting with over hundred people? That will be a party, not a conference. In a party, people usually gather into smaller groups and talk about their friends' private lives. In this case, people don't want their conversation to be heard by everybody and it's unnecessary for doing so. And still, even hundred members can be managed without any hierarchy. If the number increases, the group/conference usually will be divided into smaller groups each with different focus (like how IETF divides its working groups). In most cases the only event everybody participates may be listening to the speech of a single member, this becomes the one-to-many scenario. The bottom line is that unless authors can identify the services or applications (something requires extreme quick response for membership change) where this framework can really make sense, in my opinion, we'd better be thinking something else. __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ From owner-ipsec@lists.tislabs.com Mon Jun 19 15:23:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28871; Mon, 19 Jun 2000 15:22:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22704 Mon, 19 Jun 2000 17:02:25 -0400 (EDT) Message-ID: <20000619211027.15357.qmail@web4004.mail.yahoo.com> Date: Mon, 19 Jun 2000 14:10:27 -0700 (PDT) From: Justin Young Subject: overcomplicated framework for multicast security without real value To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My company is working on a project for Internet streaming applications. I just finished reading "A Framework for Group Key Management for Multicast Security" and like to share some thoughts. Although authors are aware of the challenges of multicast security and understand the requirements imposed by different multicast applications, this framework is nearly useless in the real world. It's too complicated to implement and deploy, and provides little value in return for most applications. While ISPs may celebrate the opportunity for increasing the number on subscribers' monthly bill, the introduction of "trunk region" complicates the overall multicast security infrastructure and makes secured data distribution more vulnerable since it breaks the end-to-end security model. Some people may not want any third-party (ISP) get involved in the sensitive data transmission. And for most applications (as I will discuss below), this approach doesn't improve the scalability or performance after all. Authors claim that the primary advantages of the framework are (1) more scalable (2) reduced complexity, and illustrate them on two examples: Pay-per-view and Confidential Conferencing. Now let's look at them one by one. Case 1 - Pay-per-view (one-to-many): as the name says, you have to pay for per movie/live sport event/TV show and it's not refundable once you make the payment (even you change your mind after only ten minutes because the movie sucks). After each show, you have to pay again to register for another one. That means the lifetime of membership is fixed. All the members have to renew their session key for the complete next lifetime. In another word, the application server or key distribution server only has to maintain single session key for everybody within a single life time (bounded by show time) even some viewers may switch channel or leave their computer. This type of service is the majority of future multicast applications. The nature of those applications is that all members have to renew their group keys for each event. In this case, the proposed framework doesn't provide any value if not making it worse. You may argue that different members may have different lifetime, for example some couch potato may register a whole year for every pay-per-view events (if permitted by the ASP). But in this case, it makes better sense for ASPs to create several different membership levels and separate the management for each level (within application-specific context). In the near future, most streaming ASPs will most likely offer two types of multicast streaming services: monthly viewing service and pay-per-view. Time Warner has been doing it for years in its cable network. It seems this framework can be used to manage monthly viewing service. Members may call up and open/close their accounts anytime during the month. But is it really worth going through all that trouble while you can simply renew the key for everybody once every day (you have to renew it sooner or later anyway for security reason)? The point is that the timing granularity requirement is loose. Case 2 - Confidential Conferencing (many-to-many): the framework fits better for this type of application. But the nature of conference is that only limited number of people will attend. So you don't need scalability. You may ask: ever attend a meeting with over hundred people? That will be a party, not a conference. In a party, people usually gather into smaller groups and talk about their friends' private lives. In this case, people don't want their conversation to be heard by everybody and it's unnecessary for doing so. And still, even hundred members can be managed without any hierarchy. If the number increases, the group/conference usually will be divided into smaller groups each with different focus (like how IETF divides its working groups). In most cases the only event everybody participates may be listening to the speech of a single member, this becomes the one-to-many scenario. The bottom line is that unless authors can identify the services or applications (something requires extreme quick response for membership change) where this framework can really make sense, in my opinion, we'd better be thinking something else. __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ From owner-ipsec@lists.tislabs.com Mon Jun 19 17:58:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03003; Mon, 19 Jun 2000 17:58:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23168 Mon, 19 Jun 2000 19:18:26 -0400 (EDT) Message-Id: <200006192326.TAA03469@bcn.East.Sun.COM> Date: Mon, 19 Jun 2000 19:26:38 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit To: rja@inet.org, pkoning@xedia.com Cc: OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1acJFXyVZXEgbb4YWyC0xA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ran, another basic question... What's the threat solved by authenticating the source route header at intermediate points? What would be the problem if a packet showed up at the destination, not having traversed the route you wanted? I'm assuming you're not trying to solve the confidentiality problem by making sure that the packet stays in "friendly" parts of the net, and therefore doesn't need encryption, but if it took a different route it would need encryption. Radia From owner-ipsec@lists.tislabs.com Tue Jun 20 03:31:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22247; Tue, 20 Jun 2000 03:31:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA24602 Tue, 20 Jun 2000 04:41:37 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E3756F@eseis06nok> To: ipsec@lists.tislabs.com Subject: IKE Delete message Date: Tue, 20 Jun 2000 11:49:51 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When sending this to notify the deletion of IPSEC SAs How do we know the Source and destination address of the SAs. Do we need to keep a list aside to know it. The message may contain 2 IPSEC SPIs to delete both established IPSEC SAs but there's one for each direction. Also, when is IKE supposed to send this message? It's possible that the IPSEC SAs expire after the ISAKMP SA and then there's no way to send this message. Thanks. Toni Barrera Arboix NRC Ruoholahti GSM +3580407431992 antonio.barrera@nokia.com From owner-ipsec@lists.tislabs.com Tue Jun 20 08:35:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12732; Tue, 20 Jun 2000 08:35:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25507 Tue, 20 Jun 2000 09:24:40 -0400 (EDT) From: FRousseau@chrysalis-its.com Message-ID: <918C70B01822D411A87400B0D0204DFF04C033@panda.chrysalis-its.com> To: ipsec@lists.tislabs.com Subject: Minimum IP Compression Algorithm for Interoperability Date: Tue, 20 Jun 2000 09:33:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDABC.32932878" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDABC.32932878 Content-Type: text/plain; charset="iso-8859-1" I am not sure if this has been discussed before since I have not followed the IPSec mailing list for a while. I understand from the Internet IP Security Domain of Interpretation for ISAKMP [RFC2407] that the IP Compression (IPComp) transforms define optional compression algorithms that can be negotiated to provide for IP payload compression [RFC2393] and that compression algorithms must be published and in the public domain. I also understand from RFC2394 that the DEFLATE compression algorithm is available publicly, and from RFC2395 that Hi/fn, Inc. holds patents on the LZS compression algorithm and that source and object licenses are available on a non-discriminatory basis. However, if an IPSec implementation also intends to support IPComp, I could not find in any documents which compression algorithm must be implemented as a minimum in order to support interoperability. Can someone please tell me which one of these two compression algorithms (i.e. DEFLATE [RFC2394] or LZS [RFC2395]) must be supported as a minimum for interoperability reason if implementing IPComp or if none has been mandated since IPComp interoperability was not a concerned? Thanks in advance for your answer. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFDABC.32932878 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Minimum IP Compression Algorithm for Interoperability

I am not sure if this has been discussed before since = I have not followed the IPSec mailing list for a while.

I understand from the Internet IP Security Domain of = Interpretation for ISAKMP [RFC2407] that the IP Compression (IPComp) = transforms define optional compression algorithms that can be = negotiated to provide for IP payload compression [RFC2393] and that = compression algorithms must be published and in the public = domain. I also understand from RFC2394 that the DEFLATE = compression algorithm is available publicly, and from RFC2395 that = Hi/fn, Inc. holds patents on the LZS compression algorithm and that = source and object licenses are available on a non-discriminatory = basis.

However, if an IPSec implementation also intends to = support IPComp, I could not find in any documents which compression = algorithm must be implemented as a minimum in order to support = interoperability.

Can someone please tell me which one of these two = compression algorithms (i.e. DEFLATE [RFC2394] or LZS [RFC2395]) must = be supported as a minimum for interoperability reason if implementing = IPComp or if none has been mandated since IPComp interoperability was = not a concerned?

Thanks in advance for your answer.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFDABC.32932878-- From owner-ipsec@lists.tislabs.com Tue Jun 20 08:39:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13205; Tue, 20 Jun 2000 08:39:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25559 Tue, 20 Jun 2000 09:28:53 -0400 (EDT) Message-Id: <4.2.0.58.20000619221740.009e79c0@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 19 Jun 2000 22:26:30 -0400 To: Paul Koning From: RJ Atkinson Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Cc: OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net In-Reply-To: <14670.27117.456112.629255@xedia.com> References: <200006160532.BAA08121@bcn.East.Sun.COM> <4.2.0.58.20000616071416.00974e60@avarice.inner.net> <4.2.0.58.20000619132241.00981f00@avarice.inner.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:43 19/06/00 , Paul Koning wrote: >Fair enough. It's common enough to put a security gateway in the same >box as a firewall. For example, our own Access Point products do that >today. Then again, they do that with ESP, which does all that is >needed for this application. Your assertion that "ESP does all that is needed" is not really true. ESP does nothing if the security policy requires authentication of anything that is an IP-layer option or header (and please consider that the current set of options/headers will be expanded over time in ways that none of us can predict). As noted earlier, the current set of security gateways generally do not provide very high assurance levels with respect to the IP packets. >Huh? I see nothing of that in RFC 2402. In any case, given the >performance (or rather, lack thereof) of digital signatures, it's >unlikely that any extensions to AH or ESP to use digital signatures on >a per-packet basis would see any significant use. It is true that digital signature creation can be compute intensive today on general purpose hardware. However, I will also note some folks are meeting this week about the use of digital signatures to protect routing protocols. Several major Tier-1 ISPs and routing vendors will be participating. So clearly there are a set of folks (both users and implementers) who think that there might well be an interesting applicability domain for digital signatures (whether or not those are digital signatures in AH) in the operational Internet. Ran rja@inet.org From owner-ipsec@lists.tislabs.com Tue Jun 20 08:39:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13244; Tue, 20 Jun 2000 08:39:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25558 Tue, 20 Jun 2000 09:28:53 -0400 (EDT) Message-Id: <4.2.0.58.20000619222642.0097f220@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 19 Jun 2000 22:32:19 -0400 To: Mailing List From: RJ Atkinson Subject: Re: Deprecation of AH header from the IPSEC tool kit Cc: isis-wg@juniper.net, ipsec@lists.tislabs.com In-Reply-To: <200006192326.TAA03469@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 19:26 19/06/00 , Radia Perlman - Boston Center for Networking wrote: >What's the threat solved by authenticating the source route header >at intermediate points? What would be the problem if a packet >showed up at the destination, not having traversed the route >you wanted? There are a variety of specific attacks facilitated by forged or improperly modified source routing headers. I'm sure you can think of several. I never ever provide cookbook information about specific threats or attack mechanisms in public mailing lists or public meetings. Some folks find this frustrating, but I have always and will always operate this way. Ran rja@inet.org From owner-ipsec@lists.tislabs.com Tue Jun 20 09:01:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14994; Tue, 20 Jun 2000 09:01:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26062 Tue, 20 Jun 2000 10:41:54 -0400 (EDT) Message-Id: <4.2.0.58.20000620103847.009893b0@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 20 Jun 2000 10:40:01 -0400 To: "Steven M. Bellovin" From: RJ Atkinson Subject: Re: Deprecation of AH header from the IPSEC tool kit Cc: Mailing List , isis-wg@juniper.net, ipsec@lists.tislabs.com In-Reply-To: <20000620142828.3C00735DC3@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:27 20/06/00 , Steven M. Bellovin wrote: >Cookbooks? I don't provide code, either. But I do discuss holes, >especially architectural holes, since that's the only way to get them fixed. Steve, We've had this conversation several times. I thought we'd long ago agreed to disagree on this. :-) Regards, Ran rja@inet.org From owner-ipsec@lists.tislabs.com Tue Jun 20 09:06:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15384; Tue, 20 Jun 2000 09:06:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26004 Tue, 20 Jun 2000 10:32:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <918C70B01822D411A87400B0D0204DFF04C033@panda.chrysalis-its.com> References: <918C70B01822D411A87400B0D0204DFF04C033@panda.chrysalis-its.com> Date: Tue, 20 Jun 2000 10:39:06 -0400 To: FRousseau@chrysalis-its.com From: Stephen Kent Subject: Re: Minimum IP Compression Algorithm for Interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francois, Because LZS is patented (at least in the US) and because HiFn has not offered the sort of licensing terms that would be required for all vendors to compete fairly, I don't think the IETF would mandate support of LZS. I believe that all of the RFCs that talks about LZS are informational, not standards track. Steve From owner-ipsec@lists.tislabs.com Tue Jun 20 10:49:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20436; Tue, 20 Jun 2000 10:49:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA26386 Tue, 20 Jun 2000 12:08:07 -0400 (EDT) Message-ID: <394F98CD.ECFE7EAF@redcreek.com> Date: Tue, 20 Jun 2000 09:16:13 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ben McCann CC: vvolpe@cisco.com, ipsec@lists.tislabs.com Subject: Re: INVALID SPI Notify References: <8D0E009FB517D41183C60090277A3DDE0F4F5E@liam.cisco.com> <394E4CAA.355F8628@redcreek.com> <394E59D3.5114259F@indusriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ben, Ben McCann wrote: > > When would IKE complain of an invalid SPI during a phase 2 exchange? Its > a 32-bit random number selected by the sender. The only case I can see > is if the SPI was less than 256. (These values, I believe, are forbidden > in IPSEC). > > Should IKE treat an _illegal_ value for the SPI during Phase 2 as some > kind of protocol error that is distinct from INVALID-SPI? If it did, then > INVALID-SPI can be unambiguously used by IPSEC to report receipt of an IPSEC > packet whose SPI doesn't exist in the SAD. > > Use of the DOI to select between ISAKMP and IPSEC also works. I'm just > curious why and when IKE (isakmp) is ever required to report INVALID-SPI. Guess I was a bit hasty in my reply - by "phase 2", I meant the case where an spi is rec'd with no corresponding entry. On the other hand, I think invalid-spi would still be appropriate if ike rec'd an spi less than 256. We could use the protocol id in the notify message to distinguish between whether it was with respect to an ongoing ike negotiation vs an ipsec session... Scott From owner-ipsec@lists.tislabs.com Tue Jun 20 11:50:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21870; Tue, 20 Jun 2000 11:50:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26677 Tue, 20 Jun 2000 13:19:09 -0400 (EDT) Message-ID: From: "Kavsan, Bronislav" To: "'Stephen Kent'" , FRousseau@chrysalis-its.com Cc: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability Date: Tue, 20 Jun 2000 13:13:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I strongly support Steve's statement here. Actually this issue was brought up few times - the last time at the VPN bakeoff in San Diego. > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, June 20, 2000 10:39 AM > To: FRousseau@chrysalis-its.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Minimum IP Compression Algorithm for Interoperability > > > Francois, > > Because LZS is patented (at least in the US) and because HiFn has not > offered the sort of licensing terms that would be required for all > vendors to compete fairly, I don't think the IETF would mandate > support of LZS. I believe that all of the RFCs that talks about LZS > are informational, not standards track. > > Steve > From owner-ipsec@lists.tislabs.com Tue Jun 20 12:39:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22777; Tue, 20 Jun 2000 12:39:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26858 Tue, 20 Jun 2000 14:16:13 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B7890CA@md-exchange1.nai.com> From: "Mason, David" To: "'Kavsan, Bronislav'" , "'Stephen Kent'" , FRousseau@chrysalis-its.com Cc: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability Date: Tue, 20 Jun 2000 11:23:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bronislav also brought up the following point found at the last bakeoff that most implementations were using the less efficient Deflate (header and Alder checksum) method and not using the undocumented feature of the Zlib that avoids that overhead. I don't believe this mailing list ever resolved this Deflate issue. If I recall it was suggested that the header and Alder checksum would be included if the IPCOMP_DEFLATE transform ID was used as it is currently specified in the DOI (rfc2407) and that a new transform ID would be allocated to specify Deflate without the header and Alder checksum. -dave From: Slava Kavsan [bkavsan@ire-ma.com] Sent: Friday, January 14, 2000 1:32 PM To: ipsec@lists.tislabs.com Subject: Deflate issue We discovered some Deflate implementation differences that control the inclusion of the Deflate header and Adler32 checksum. RFC2394 makes no mention of the Deflate header or Adler32 checksum . These items are redundant in the case of IPCOMP. It doesn't make sense to spend the time to do it as it uses bandwidth unnecessarily for the extra (8?) bytes. Unfortunately, the ability to NOT include the Deflate header and Adler32 checksum is an undocumented feature of the ZLIB implementation of Deflate, which is controlled by the -15 parameter to the deflateInit2_() Sooooo... should the inclusion of the extra header and the checksum be controlled by another IPCOMP attribute or should we simply all change the way Deflate engine is initialized from: if (Z_OK != deflateInit(&c_stream, Z_DEFAULT_COMPRESSION)) break; to: if (Z_OK != deflateInit2_(&c_stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED, -11, DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY, ZLIB_VERSION, sizeof(z_stream))) break; And similar for Inflate, from: if (Z_OK != inflateInit(&d_stream)) break; to: if (Z_OK != inflateInit2_(&d_stream, -15, ZLIB_VERSION, sizeof(z_stream))) break; From owner-ipsec@lists.tislabs.com Tue Jun 20 13:10:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23142; Tue, 20 Jun 2000 13:10:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26887 Tue, 20 Jun 2000 14:40:05 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D2830C@new-exc1.ctron.com> From: "Waters, Stephen" To: FRousseau@chrysalis-its.com Cc: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability Date: Tue, 20 Jun 2000 19:48:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This depends who you talk to. For compression to scale, folk are using compression chips. As far as I know (and I looked), there is not currently a chip available to do DEFLATE, so the answer could be 'LZS' since this is supported by commonly used Hi/fn chips. Steve. -----Original Message----- From: FRousseau@chrysalis-its.com [mailto:FRousseau@chrysalis-its.com] Sent: Tuesday, June 20, 2000 2:34 PM To: ipsec@lists.tislabs.com Subject: Minimum IP Compression Algorithm for Interoperability I am not sure if this has been discussed before since I have not followed the IPSec mailing list for a while. I understand from the Internet IP Security Domain of Interpretation for ISAKMP [RFC2407] that the IP Compression (IPComp) transforms define optional compression algorithms that can be negotiated to provide for IP payload compression [RFC2393] and that compression algorithms must be published and in the public domain. I also understand from RFC2394 that the DEFLATE compression algorithm is available publicly, and from RFC2395 that Hi/fn, Inc. holds patents on the LZS compression algorithm and that source and object licenses are available on a non-discriminatory basis. However, if an IPSec implementation also intends to support IPComp, I could not find in any documents which compression algorithm must be implemented as a minimum in order to support interoperability. Can someone please tell me which one of these two compression algorithms (i.e. DEFLATE [RFC2394] or LZS [RFC2395]) must be supported as a minimum for interoperability reason if implementing IPComp or if none has been mandated since IPComp interoperability was not a concerned? Thanks in advance for your answer. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 From owner-ipsec@lists.tislabs.com Tue Jun 20 13:23:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23266; Tue, 20 Jun 2000 13:23:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27037 Tue, 20 Jun 2000 15:11:10 -0400 (EDT) Message-Id: <4.2.0.58.20000620112747.009bd390@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 20 Jun 2000 11:29:22 -0400 To: Paul Koning From: RJ Atkinson Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Cc: OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net In-Reply-To: <14671.34433.745061.326648@xedia.com> References: <200006160532.BAA08121@bcn.East.Sun.COM> <4.2.0.58.20000616071416.00974e60@avarice.inner.net> <4.2.0.58.20000619132241.00981f00@avarice.inner.net> <4.2.0.58.20000619221740.009e79c0@avarice.inner.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:58 20/06/00 , Paul Koning wrote: >Clearly there are plenty of compelling applications for digital >signatures in the operational Internet. Protecting routing protocols >is one good example, and there are a bunch of others anyone could name >off the top of their head. As noted earlier, one of the current primary uses of AH is to protect routing protocols. I'm glad you agree that digital signatures could be compelling in that context. :-) Take care, Ran rja@inet.org From owner-ipsec@lists.tislabs.com Tue Jun 20 13:23:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23279; Tue, 20 Jun 2000 13:23:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27004 Tue, 20 Jun 2000 15:06:32 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14671.49845.262330.534968@xedia.com> Date: Tue, 20 Jun 2000 15:15:01 -0400 (EDT) To: David_Mason@nai.com Cc: bkavsan@rsasecurity.com, kent@bbn.com, FRousseau@chrysalis-its.com, ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability References: <447A3F40A07FD211BA2700A0C99D759B7890CA@md-exchange1.nai.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mason," == Mason, David writes: Mason,> Bronislav also brought up the following point found at the Mason,> last bakeoff that most implementations were using the less Mason,> efficient Deflate (header and Alder checksum) method and not Mason,> using the undocumented feature of the Zlib that avoids that Mason,> overhead. I don't believe this mailing list ever resolved Mason,> this Deflate issue. Mason,> If I recall it was suggested that the header and Alder Mason,> checksum would be included if the IPCOMP_DEFLATE transform ID Mason,> was used as it is currently specified in the DOI (rfc2407) Mason,> and that a new transform ID would be allocated to specify Mason,> Deflate without the header and Alder checksum. Hm, I don't remember a specific conclusion but Slava commented that the extra stuff is redundant and/or not relevant to IPcomp. So why retain it? It seems more straightforward to clarify the description to say that the existing ID means "Deflate without that overhead". Unless there's a good reason why it's useful to have a variant with those headers, let's not create a new ID and not define a variant that comes with that overhead. paul PS. Shouldn't the Deflate RFC be standards track? It seems odd to have the IPcomp spec be standards track but no compression algorithm that it needs be on that track. From owner-ipsec@lists.tislabs.com Tue Jun 20 13:44:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23534; Tue, 20 Jun 2000 13:44:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27010 Tue, 20 Jun 2000 15:06:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <29752A74B6C5D211A4920090273CA3DC01D2830C@new-exc1.ctron.com> References: <29752A74B6C5D211A4920090273CA3DC01D2830C@new-exc1.ctron.com> Date: Tue, 20 Jun 2000 15:06:34 -0400 To: "Waters, Stephen" From: Stephen Kent Subject: RE: Minimum IP Compression Algorithm for Interoperability Cc: FRousseau@chrysalis-its.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, >This depends who you talk to. For compression to scale, folk are using >compression chips. As far as I know (and I looked), there is not currently a >chip available to do DEFLATE, so the answer could be 'LZS' since this is >supported by commonly used Hi/fn chips. But, since I understand that HiFn does not license LZS to competing hardware vendors, it would be contrary to IETF procedures to make it a default (required) algorithm for use with IPCOMP. Steve From owner-ipsec@lists.tislabs.com Tue Jun 20 13:53:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23678; Tue, 20 Jun 2000 13:53:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27119 Tue, 20 Jun 2000 15:36:03 -0400 (EDT) Date: Tue, 20 Jun 2000 12:44:28 -0700 (PDT) From: Marc Hasson Message-Id: <200006201944.MAA19923@leo.mentat.com> To: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk wrote: > If I recall it was suggested that the header and Alder checksum > would be included if the IPCOMP_DEFLATE transform ID was used > as it is currently specified in the DOI (rfc2407) and that a > new transform ID would be allocated to specify Deflate without > the header and Alder checksum. > > -dave My recollection agrees with you about "it was suggested" but there were multiple suggestions and no apparent group concensus on the issue. See the prior discussion on this topic in the Jan 14->24 archives for ipsec or ippcp with subject "Deflate issue". The point was also made that the extra header and Alder checksums: added unnecessary computational and space overheads for ipsec/ippcp usage, was an "artifact" of how a existing/ZLIB implementations worked, and no one responded to my requests for any advantages to the usage of Alder32 and the deflate header that makes them worth using. Also, the existing IPCOMP documents' DEFLATE references do *not* refer to any documents which specify Adler32 and header checksums unless you search "deeper" (as in ZLIB specs or code), beyond whats specified by IPCOMP RFCs 2393/2394 with their RFC 1951 reference for the basic DEFLATE functionality. Suggested wording had been supplied to clarify the existing DEFLATE documents that are under control of the IPCOMP working group. But, admittedly, there was no working group concensus that I could detect on what to do here. No one commented on the specification clarifications made by myself or Slava. There are apparently some people who implemented these Alder checksums and deflate headers, presumably because of their usage of the ZLIB implementation. And these people (several?) interoperated fine at bake-offs, with this extra overhead that ZLIB generates in certain configurations. Even someone in *that* group stated "...we were all (except IRE) wrong.". But, admittedly, properly enforcing the basic specs could be a problem for a deployed based depending upon how much interoperation is going on out there now. Can anyone comment on whether there's significant inter-vendor DEFLATE usage with the extra Adler32 checksums and header? OTOH, someone coding strictly from the specs as I and others did would *not* (and don't) have Adler32 checksums nor deflate headers in their implementations. Perhaps we need a poll on what vendors have done what. I'd argue that its the more efficient variation that should *remain* the official DEFLATE specification for the long-haul and that additional transform IDs could be used for the "deflate with additional stuff" as a transition aid. Or the current transform ID's value could even become the transitional one, to save the (re)deployment heartbreak. But even if we decided, due to deployed base, to make the inefficient version the official DEFLATE its going to require more updating/explanation in the existing IPCOMP specs to guard against future implementation errors, let alone to properly describe the protocol. The minimal verbiage/procedures supplied by Slava and myself in the archives is all that would be needed to warn future implementers to do the right thing for the more efficient variation which the specs currently describe. But this has to be worked out as a group. -- Marc -- From owner-ipsec@lists.tislabs.com Tue Jun 20 15:04:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25031; Tue, 20 Jun 2000 15:04:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27273 Tue, 20 Jun 2000 16:29:51 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B7890CB@md-exchange1.nai.com> From: "Mason, David" To: "'Marc Hasson'" , ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability Date: Tue, 20 Jun 2000 13:34:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I'd argue that its the more efficient variation that should *remain* >the official DEFLATE specification for the long-haul and that >additional transform IDs could be used for the "deflate with additional >stuff" as a transition aid. Or the current transform ID's value could >even become the transitional one, to save the (re)deployment >heartbreak. But even if we decided, due to deployed base, to make the >inefficient version the official DEFLATE its going to require more >updating/explanation in the existing IPCOMP specs to guard against >future implementation errors, let alone to properly describe the >protocol. The minimal verbiage/procedures supplied by Slava and myself >in the archives is all that would be needed to warn future implementers >to do the right thing for the more efficient variation which the specs >currently describe. Yes the suggestion was that the current transform ID would become historical (the transitional one) and that the new transform ID would be the official one. The reason for this suggestion was that many (most/all?) vendors at the last bakeoff that had shipping products that supported IPCOMP included the header/checksum and that few (none?) had shipping products that did it the right way. -dave From owner-ipsec@lists.tislabs.com Tue Jun 20 15:22:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25404; Tue, 20 Jun 2000 15:22:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27476 Tue, 20 Jun 2000 17:09:21 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D28311@new-exc1.ctron.com> From: "Waters, Stephen" To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability Date: Tue, 20 Jun 2000 22:17:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree Steve - I was just 'stirring' in the hope that someone will develop a DEFLATE chip - or 'any-old' license-free compression that works O.K. for stateless mode. Steve. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, June 20, 2000 8:07 PM To: Waters, Stephen Cc: FRousseau@chrysalis-its.com; ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability Steve, >This depends who you talk to. For compression to scale, folk are using >compression chips. As far as I know (and I looked), there is not currently a >chip available to do DEFLATE, so the answer could be 'LZS' since this is >supported by commonly used Hi/fn chips. But, since I understand that HiFn does not license LZS to competing hardware vendors, it would be contrary to IETF procedures to make it a default (required) algorithm for use with IPCOMP. Steve From owner-ipsec@lists.tislabs.com Tue Jun 20 16:38:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26395; Tue, 20 Jun 2000 16:38:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27721 Tue, 20 Jun 2000 18:24:05 -0400 (EDT) Date: Tue, 20 Jun 2000 18:32:28 -0400 From: Ran Canetti Message-Id: <200006202232.SAA30878@ornavella.watson.ibm.com> To: ipsec@lists.tislabs.com, justin_young_98052@yahoo.com Subject: Re: overcomplicated framework for multicast security without real value Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Justin, Your note seems more suitable for the SMuG (Secure Multicast Group) working group of the IRTF, where multicast key management is discussed among other multicast security issues. The draft you read is one of the early drafts written by SMuG contributors; other work has been done since. The list is a "closed" one; but anyone who wants to contribute is most welcome to join. To do that, please write either myself or Thomas Hardjono (hardjono@nortelnetworks.com). Regarding your note, I agree with much of what you say. Indeed, there is a need to find a good compromise between simplicity and immediate applicability and some generality that would allow future extensions without re-doing everything from scratch. But I wanted to point out one thing that you seem to have missed in that draft (at least according to my understanding of it): the separation to "trunk region key" and other keys is relevant only to the re-keying messages. All the data is encrypted using one key that is common to all members. Thus, end-to-end security of the data is maintained. (In some cases, such as political barriers and some firewalls, one may be forced to re-encrypt the data. But this should be avoided whenever possible.) Best, Ran Canetti > > From owner-ipsec@lists.tislabs.com Mon Jun 19 17:37:31 2000 > Date: Mon, 19 Jun 2000 14:10:27 -0700 (PDT) > From: Justin Young > Subject: overcomplicated framework for multicast security without real > valueTo: ipsec@lists.tislabs.com > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Precedence: bulk > Content-Length: 4395 > > My company is working on a project for Internet > streaming applications. I just finished reading "A > Framework for Group Key Management for Multicast > Security" and like to share some thoughts. > > Although authors are aware of the challenges of > multicast security and understand the requirements > imposed by different multicast applications, this > framework is nearly useless in the real world. > > It's too complicated to implement and deploy, and > provides little value in return for most applications. > While ISPs may celebrate the opportunity for > increasing the number on subscribers' monthly bill, > the introduction of "trunk region" complicates the > overall multicast security infrastructure and makes > secured data distribution more vulnerable since it > breaks the end-to-end security model. Some people may > not want any third-party (ISP) get involved in the > sensitive data transmission. And for most applications > (as I will discuss below), this approach doesn't > improve the scalability or performance after all. > > Authors claim that the primary advantages of the > framework are (1) more scalable (2) reduced > complexity, and illustrate them on two examples: > Pay-per-view and Confidential Conferencing. Now let's > look at them one by one. > > Case 1 - Pay-per-view (one-to-many): as the name says, > you have > to pay for per movie/live sport event/TV show and it's > not refundable once you make the payment (even you > change your mind after only ten minutes because the > movie sucks). After each show, you have to pay again > to register for another one. That means the lifetime > of membership is fixed. All the members have to renew > their session key for the complete next lifetime. In > another word, the application server or key > distribution server only has to maintain single > session key for everybody within a single life time > (bounded by show time) even some viewers may switch > channel or leave their computer. This type of service > is the majority of future multicast applications. The > nature of those applications is that all members have > to renew their group keys for each event. In this > case, the proposed framework doesn't provide any value > if not making it worse. > > You may argue that different members may have > different lifetime, for example some couch potato may > register a whole year for every pay-per-view events > (if permitted by the ASP). But in this case, it makes > better sense for ASPs to create several different > membership levels and separate the management for each > level (within application-specific context). > > In the near future, most streaming ASPs will most > likely offer two types of multicast streaming > services: monthly viewing service and pay-per-view. > Time Warner has been doing it for years in its cable > network. It seems this framework can be used to > manage monthly viewing service. Members may call up > and open/close their accounts anytime during the > month. > But is it really worth going through all that trouble > while you can simply renew the key for everybody once > every day (you have to renew it sooner or later anyway > for security reason)? The point is that the timing > granularity requirement is loose. > > Case 2 - Confidential Conferencing (many-to-many): the > framework fits better for this type of > application. But the nature of conference is that only > limited number of people will attend. So you don't > need scalability. You may ask: ever attend a meeting > with over hundred people? That will be a party, not a > conference. In a party, people usually gather into > smaller groups and talk about their friends' private > lives. In this case, people don't want their > conversation to be heard by everybody and it's > unnecessary for doing so. And still, even hundred > members can be managed without any hierarchy. If the > number increases, the group/conference usually will > be divided into smaller groups each with different > focus (like how IETF divides its working groups). In > most cases the only event everybody participates may > be listening to the speech of a single member, this > becomes the one-to-many scenario. > > The bottom line is that unless authors can identify > the services or applications (something requires > extreme quick response for membership change) where > this framework can really make sense, in my opinion, > every day (you have to renew it sooner or later anyway > for security reason)? The point is that the timing > granularity requirement is loose. > > Case 2 - Confidential Conferencing (many-to-many): the > framework fits better for this type of > application. But the nature of conference is that only > limited number of people will attend. So you don't > need scalability. You may ask: ever attend a meeting > with over hundred people? That will be a party, not a > conference. In a party, people usually gather into > smaller groups and talk about their friends' private > lives. In this case, people don't want their > conversation to be heard by everybody and it's > unnecessary for doing so. And still, even hundred > members can be managed without any hierarchy. If the > number increases, the group/conference usually will > be divided into smaller groups each with different > focus (like how IETF divides its working groups). In > most cases the only event everybody participates may > be listening to the speech of a single member, this > becomes the one-to-many scenario. > > The bottom line is that unless authors can identify > the services or applications (something requires > extreme quick response for membership change) where > this framework can really make sense, in my opinion, > we'd better be thinking something else. > > From owner-ipsec@lists.tislabs.com Tue Jun 20 16:40:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26446; Tue, 20 Jun 2000 16:40:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27741 Tue, 20 Jun 2000 18:37:42 -0400 (EDT) Date: Tue, 20 Jun 2000 17:46:17 -0500 From: Will Fiveash To: IETF IPSec Subject: default life negotiation issue Message-ID: <20000620174617.A28856@austin.ibm.com> Mail-Followup-To: IETF IPSec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can a SA be negotiated that only contains a lifesize (no lifetime in seconds)? I ask this because I got a little confused by this paragraph in RFC2407 (DOI): If unspecified, the default value shall be assumed to be 28800 seconds (8 hours). If a initiator only proposes a lifesize attribute of KBytes, do I assume that they are also implicitly proposing the default lifetime value above? -- Will Fiveash IBM AIX System Development (IPsec/IKE) From owner-ipsec@lists.tislabs.com Tue Jun 20 17:15:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26882; Tue, 20 Jun 2000 17:15:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27822 Tue, 20 Jun 2000 19:08:55 -0400 (EDT) X-Authentication-Warning: janpc-home.cisco.com: vilhuber owned process doing -bs Date: Tue, 20 Jun 2000 16:16:57 -0700 (PDT) From: Jan Vilhuber To: Will Fiveash cc: IETF IPSec Subject: Re: default life negotiation issue In-Reply-To: <20000620174617.A28856@austin.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Will! Yes, I believe your assumption below is correct. At least that's how I've always interpreted it. jan On Tue, 20 Jun 2000, Will Fiveash wrote: > Can a SA be negotiated that only contains a lifesize (no lifetime in > seconds)? I ask this because I got a little confused by this paragraph in > RFC2407 (DOI): > > If unspecified, the default value shall be assumed to be 28800 seconds > (8 hours). > > If a initiator only proposes a lifesize attribute of KBytes, do I assume > that they are also implicitly proposing the default lifetime value above? > > -- > Will Fiveash > IBM AIX System Development (IPsec/IKE) > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Jun 20 18:10:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29228; Tue, 20 Jun 2000 18:10:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28023 Tue, 20 Jun 2000 19:53:20 -0400 (EDT) Date: Tue, 20 Jun 2000 19:01:56 -0500 From: Will Fiveash To: Jan Vilhuber Cc: IETF IPSec Subject: Re: default life negotiation issue Message-ID: <20000620190156.D25104@austin.ibm.com> Mail-Followup-To: Jan Vilhuber , IETF IPSec References: <20000620174617.A28856@austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.4i In-Reply-To: ; from vilhuber@cisco.com on Tue, Jun 20, 2000 at 04:16:57PM -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, I read my note again and I realize that it is a little confusing (I ask the same question in two different ways). Are you telling me that you assume that an SA may just use lifesize to determine its duration? If the initiator only proposed a lifesize, the responder would NOT assume the lifetime default was implicitly proposed? (These two questions should have the same answer.) On Tue, Jun 20, 2000 at 04:16:57PM -0700, Jan Vilhuber wrote: > Hi Will! > > Yes, I believe your assumption below is correct. At least that's how I've > always interpreted it. > > jan > > > On Tue, 20 Jun 2000, Will Fiveash wrote: > > > Can a SA be negotiated that only contains a lifesize (no lifetime in > > seconds)? I ask this because I got a little confused by this paragraph in > > RFC2407 (DOI): > > > > If unspecified, the default value shall be assumed to be 28800 seconds > > (8 hours). > > > > If a initiator only proposes a lifesize attribute of KBytes, do I assume > > that they are also implicitly proposing the default lifetime value above? ^^^^^^^^^^^^^^^^^^^^ Somewhat confused question whose answer should be the opposite of the previous question. -- Will Fiveash IBM AIX System Development (IPsec/IKE) From owner-ipsec@lists.tislabs.com Tue Jun 20 18:16:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA00229; Tue, 20 Jun 2000 18:16:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28093 Tue, 20 Jun 2000 20:08:55 -0400 (EDT) X-Authentication-Warning: janpc-home.cisco.com: vilhuber owned process doing -bs Date: Tue, 20 Jun 2000 17:17:00 -0700 (PDT) From: Jan Vilhuber To: Will Fiveash cc: IETF IPSec Subject: Re: default life negotiation issue In-Reply-To: <20000620190156.D25104@austin.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here's how I understand the paragraph in IPDOI you referred to: If there's no lifetime indicated in the exchange, then both sides MUST assume the default of 28800 seconds. If a lifesize is given, the default lifetime applies ALSO, and whichever conditions is hit first triggers the death of the SA ;) jan On Tue, 20 Jun 2000, Will Fiveash wrote: > Jan, > > I read my note again and I realize that it is a little confusing (I ask the > same question in two different ways). Are you telling me that you assume > that an SA may just use lifesize to determine its duration? If the > initiator only proposed a lifesize, the responder would NOT assume the > lifetime default was implicitly proposed? (These two questions should have > the same answer.) > > On Tue, Jun 20, 2000 at 04:16:57PM -0700, Jan Vilhuber wrote: > > Hi Will! > > > > Yes, I believe your assumption below is correct. At least that's how I've > > always interpreted it. > > > > jan > > > > > > On Tue, 20 Jun 2000, Will Fiveash wrote: > > > > > Can a SA be negotiated that only contains a lifesize (no lifetime in > > > seconds)? I ask this because I got a little confused by this paragraph in > > > RFC2407 (DOI): > > > > > > If unspecified, the default value shall be assumed to be 28800 seconds > > > (8 hours). > > > > > > If a initiator only proposes a lifesize attribute of KBytes, do I assume > > > that they are also implicitly proposing the default lifetime value above? > ^^^^^^^^^^^^^^^^^^^^ Somewhat confused question whose answer should be > the opposite of the previous question. > > -- > Will Fiveash > IBM AIX System Development (IPsec/IKE) > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Jun 20 18:57:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05031; Tue, 20 Jun 2000 18:57:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28191 Tue, 20 Jun 2000 20:40:53 -0400 (EDT) Date: Tue, 20 Jun 2000 20:47:40 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: IPsec List Subject: uniqueness of Message IDs and related issues In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF0102D6ED@exchange> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [I am sorry that this message is so long and complicated. I'm not sure how to safely separate the issues. I think that it is important that at least some of these points are nailed down.] RFC2408 "ISAKMP" 3.1 "ISAKMP Header Format" (near end) states that the Message ID must be unique: o Message ID (4 octets) - Unique Message Identifier used to identify protocol state during Phase 2 negotiations. This value is randomly generated by the initiator of the Phase 2 negotiation. In the event of simultaneous SA establishments (i.e. collisions), the value of this field will likely be different because they are independently generated and, thus, two security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. During Phase 1 negotiations, the value MUST be set to 0. I can find no further clarification about what is meant by "unique". Clearly we cannot require that the Message ID be unique for all peers since they may not be communicating (but no RFC or draft seems to state this). In the past, I've enforced this as unique per peer during the lifetime of my IKE daemon (Pluto, of the FreeS/WAN project). In other words, whenever Pluto wanted to use a Message ID, it first made sure that the Message ID hadn't been used before with the peer in question (at least since the Pluto process had started). Whenever a peer started an exchange with a previously used Message ID, Pluto rejected that as improper. One problem with this approach is that it requires that Pluto to store a growing and unbounded amount of state: the used Message IDs. I've just made a change that seems reasonable, but I cannot justify it from text in an RFC or draft. Pluto now requires that the Message ID only be unique within a single ISAKMP SA. Every Message ID seems to occur in a context of an ISAKMP SA, so this seems reasonable. There still may be a lot of Message IDs to store, but they expire with the ISAKMP SA. Furthermore, since an ISAKMP SA does not survive a restart of Pluto, it is OK for Pluto to "forget" all previously used Message IDs when it is restarted -- a RAM table suffices. And, of course, an ISAKMP SA is only between two hosts, so other hosts need not avoid Message IDs that they cannot know about. Perhaps a little encouragement comes from RFC2409 "IKE", section 5.5 "Phase 2 - Quick Mode": The message ID in the ISAKMP header identifies a Quick Mode in progress for a particular ISAKMP SA which itself is identified by the cookies in the ISAKMP header. But another part, 5.7 "ISAKMP Informational Exchanges" says: As noted the message ID in the ISAKMP header-- and used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another phase 2 exchange which generated this informational exchange. This does not qualify "unique" in any way. It does clearly use the admonition "MUST NOT". Limiting uniqueness to being within an ISAKMP SA won't work if some message refers to some object (say an IPSEC SA) negotiated under a different ISAKMP SA using only a Message ID. A quick look at draft-ietf-ipsec-notifymsg-02.txt makes me think that this isn't a problem, but I'm not sure. One way of avoiding the storage of Message IDs is to "just hope" that they are unique. They usually are. But this can hardly satisfy the "MUST NOT". I have another reason for disliking the "just hope" approach. draft-jenkins-ipsec-rekeying-06.txt seems too complicated and awkward to me. In "2.2.1.4 Responder Pre-Set-up Security Hole", a simple solution (Responder Pre-Set-up) is rejected due to an alleged replay attack. If Message IDs are not allowed to be repeated, the replay attack cannot succeed. I looked through many of the list messages for "Message ID" but found none of these questions addressed. But I did find the following: | Date: Mon, 13 Dec 1999 12:37:58 -0500 | From: Andrew Krywaniuk | To: Tero Kivinen | Cc: ipsec@lists.tislabs.com | Subject: RE: heartbeats (summary of responses) | > If we start sending hearbeats inside the IKE message we also | > might end up consuming our randomness quite fast. For each IKE message | > we need to create random message id and a random nonce. | | Hi Tero, | | I forgot to mention this before. I don't think randomness is really an issue | here. It is perfectly valid to use a seeded pseudorandom number generator | without consuming any additional randomness for each heartbeat. | | As far as I can tell, there is no security implication to using a | pseudorandom message id. I suspect that the reason why we don't simply use | 1,2,3... is actually to avoid collisions and not to generate entropy. Has a cryptologist clearly indicated whether the Message ID needs to be random, or is pseudo-random good enough, or is predictable acceptable? The part of RFC2408 quoted above clearly uses the phrase "randomly generated". Oops: I just noticed that RFC2409 and some of the drafts refer to "message ID", not "Message ID". I think that this is a mistake. But it also meant that I didn't find all uses. For the record these are: draft-ietf-ipsec-ike-01.txt (expired, but I presume it will be revived) draft-ietf-ipsec-isakmp-mode-cfg-05.txt draft-ietf-ipsec-isakmp-xauth-04.txt draft-ietf-ipsec-notifymsg-02.txt draft-ietf-ipsec-ike-01.txt 8 "Security Considerations" says: The message ID used for all non-Phase 1 exchanges MUST be pseudo- randomly generated using a strong random number generator. So that seems to settle it. Did this change get checked by a cryptologist? The part of RFC2408 quoted at the top uses the phrase "initiator of the Phase 2 negotiation" whereas draft-ietf-ipsec-ike-01.txt says "all non-Phase 1 exchanges". I'd guess that draft-ietf-ipsec-ike-01.txt's formulation should be used in RFC2408 because it is more accurate. I would like these questions clearly resolved. (But perhaps the only place they are not clearly resolved is in my mind.) - What is the scope over which a Message ID is to be unique? I propose that it be unique within the context of a single ISAKMP SA. - "MUST" or "SHOULD" a Message ID be unique? I propose that it "MUST" be unique. - MUST (SHOULD?) the Message ID be generated randomly, pseudo-randomly, or however the implementor feels like doing it? I propose that it be randomly, until a cryptologist convinces us that something less is enough - I think that the documents would be clearer if they always used "Message ID" instead of sometimes using "Message ID", MID, and M-ID. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Wed Jun 21 07:36:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10903; Wed, 21 Jun 2000 07:36:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01096 Wed, 21 Jun 2000 08:55:54 -0400 (EDT) Message-Id: <3.0.1.32.20000621181024.006f3b34@172.16.1.10> X-Sender: raghava@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 21 Jun 2000 18:10:24 +0500 To: ipsec@lists.tislabs.com From: raghava Subject: SCEP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could anyone help me to get the free souce code of SCEP client? And also I would like to know any CA Server that supports SCEP. -raghava From owner-ipsec@lists.tislabs.com Wed Jun 21 08:16:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12717; Wed, 21 Jun 2000 08:15:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01547 Wed, 21 Jun 2000 09:52:42 -0400 (EDT) Message-Id: <3.0.5.32.20000621105739.03badd80@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jun 2000 10:57:39 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: RE: Minimum IP Compression Algorithm for Interoperability In-Reply-To: <200006201944.MAA19923@leo.mentat.com> 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 lists.tislabs.com id EAA00340 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:44 20.6.2000 -0700, Marc Hasson wrote: >There are apparently some people who implemented these Alder checksums >and deflate headers, presumably because of their usage of the ZLIB >implementation. And these people (several?) interoperated fine at >bake-offs, with this extra overhead that ZLIB generates in certain >configurations. Even someone in *that* group stated "...we were all >(except IRE) wrong.". But, admittedly, properly enforcing the basic >specs could be a problem for a deployed based depending upon how much >interoperation is going on out there now. Can anyone comment on >whether there's significant inter-vendor DEFLATE usage with the extra >Adler32 checksums and header? > >OTOH, someone coding strictly from the specs as I and others did would >*not* (and don't) have Adler32 checksums nor deflate headers in their >implementations. Perhaps we need a poll on what vendors have done >what. > Since this: >"...we were all (except IRE) wrong." was my own speech, I'd like to announce that I did after that. Since the RFCs are _perfectly_ clear that the header and checksum MUST NOT be used, I removed them. F-Secure VPN+ 4.2 uses them, in 5.0 they are removed. 5.0 also compresses the inner header in tunnel mode. This will break interoperability, even with our own product. But such is life. Since the tunnel mode was also broken, I can just say the 5.0 is the first version to do compression (correctly). BTW, just changing the function calls (as suggested by IRE) does not solve the problem. I needed a short discussion with Mark Adler (of zlib fame) on the correct use of zlib's undocumented features, but finally got it right. And no, we don't support lzs. I'd be interested what the gateway people have to say. cisco? J�rn Sierwald, F-Secure Corp. From owner-ipsec@lists.tislabs.com Wed Jun 21 10:19:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26604; Wed, 21 Jun 2000 10:19:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02144 Wed, 21 Jun 2000 12:08:38 -0400 (EDT) Date: Wed, 21 Jun 2000 11:17:13 -0500 From: Will Fiveash To: Jan Vilhuber Cc: IETF IPsec Subject: Re: default life negotiation issue Message-ID: <20000621111713.A28792@austin.ibm.com> Mail-Followup-To: Jan Vilhuber , IETF IPsec References: <20000620190156.D25104@austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.4i In-Reply-To: ; from vilhuber@cisco.com on Tue, Jun 20, 2000 at 05:17:00PM -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, Okay, I understand your answer. I still think that that this sentence in RFC2407 is vague (discussing SA Life Type/Duration): If unspecified, the default value shall be assumed to be 28800 seconds (8 hours). One could easily interpret this to mean that only if there are no life attributes in a proposal should the default value be assumed. On Tue, Jun 20, 2000 at 05:17:00PM -0700, Jan Vilhuber wrote: > Here's how I understand the paragraph in IPDOI you referred to: > > If there's no lifetime indicated in the exchange, then both sides MUST assume > the default of 28800 seconds. If a lifesize is given, the default lifetime > applies ALSO, and whichever conditions is hit first triggers the death of the > SA ;) > > jan -- Will Fiveash IBM AIX System Development (IPsec/IKE) From owner-ipsec@lists.tislabs.com Wed Jun 21 10:58:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27211; Wed, 21 Jun 2000 10:58:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02304 Wed, 21 Jun 2000 12:48:31 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B7890CF@md-exchange1.nai.com> From: "Mason, David" To: "'Joern Sierwald'" , ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability Date: Wed, 21 Jun 2000 08:19:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem was that RFC 2394 did not make it "_perfectly_ clear that the header and checksum MUST NOT be used". Unfortunately both RFC 2394 and 1951 refer to the zlib source/documentation for use as a freely available deflate compliant package without mentioning the fact that the header/checksum should not be used. Since the header/checksum is the default mode of zlib and that not using the header/checksum feature is undocumented (and RFC 1950 mandates use of the checksum) this caused problems. If we're voting on the issue, I would join Joern to keep a single ID for Deflate with the drawback that "broken" implementations won't interoperate with correct implementations. And hopefully upgrading all the "broken" implementations won't be too painful. -dave -----Original Message----- From: Joern Sierwald [mailto:joern.sierwald@F-Secure.com] Sent: Wednesday, June 21, 2000 4:58 AM To: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability At 12:44 20.6.2000 -0700, Marc Hasson wrote: >There are apparently some people who implemented these Alder checksums >and deflate headers, presumably because of their usage of the ZLIB >implementation. And these people (several?) interoperated fine at >bake-offs, with this extra overhead that ZLIB generates in certain >configurations. Even someone in *that* group stated "...we were all >(except IRE) wrong.". But, admittedly, properly enforcing the basic >specs could be a problem for a deployed based depending upon how much >interoperation is going on out there now. Can anyone comment on >whether there's significant inter-vendor DEFLATE usage with the extra >Adler32 checksums and header? > >OTOH, someone coding strictly from the specs as I and others did would >*not* (and don't) have Adler32 checksums nor deflate headers in their >implementations. Perhaps we need a poll on what vendors have done >what. > Since this: >"...we were all (except IRE) wrong." was my own speech, I'd like to announce that I did after that. Since the RFCs are _perfectly_ clear that the header and checksum MUST NOT be used, I removed them. F-Secure VPN+ 4.2 uses them, in 5.0 they are removed. 5.0 also compresses the inner header in tunnel mode. This will break interoperability, even with our own product. But such is life. Since the tunnel mode was also broken, I can just say the 5.0 is the first version to do compression (correctly). BTW, just changing the function calls (as suggested by IRE) does not solve the problem. I needed a short discussion with Mark Adler (of zlib fame) on the correct use of zlib's undocumented features, but finally got it right. And no, we don't support lzs. I'd be interested what the gateway people have to say. cisco? J-rn Sierwald, F-Secure Corp. From owner-ipsec@lists.tislabs.com Wed Jun 21 11:33:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27923; Wed, 21 Jun 2000 11:33:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02504 Wed, 21 Jun 2000 13:17:11 -0400 (EDT) Date: Wed, 21 Jun 2000 20:25:50 +0300 (EET DST) Message-Id: <200006211725.UAA20498@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Mason, David" Cc: "'Joern Sierwald'" , ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability In-Reply-To: <447A3F40A07FD211BA2700A0C99D759B7890CF@md-exchange1.nai.com> References: <447A3F40A07FD211BA2700A0C99D759B7890CF@md-exchange1.nai.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mason, David writes: > The problem was that RFC 2394 did not make it "_perfectly_ > clear that the header and checksum MUST NOT be used". > Unfortunately both RFC 2394 and 1951 refer to the zlib > source/documentation for use as a freely available > deflate compliant package without mentioning the fact > that the header/checksum should not be used. Since the > header/checksum is the default mode of zlib and that not > using the header/checksum feature is undocumented (and > RFC 1950 mandates use of the checksum) this caused problems. > > If we're voting on the issue, I would join Joern to keep > a single ID for Deflate with the drawback that "broken" > implementations won't interoperate with correct implementations. > And hopefully upgrading all the "broken" implementations > won't be too painful. I think somebody should then add some text to RFC2394 document, about how to use those undocumented features. This could be added as "Appendix A Implementation notes when using zlib library" or something. -- kivinen@iki.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Jun 21 11:33:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27937; Wed, 21 Jun 2000 11:33:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02455 Wed, 21 Jun 2000 13:14:03 -0400 (EDT) From: FRousseau@chrysalis-its.com Message-ID: <918C70B01822D411A87400B0D0204DFF04C03B@panda.chrysalis-its.com> To: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability Date: Wed, 21 Jun 2000 13:23:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDBA5.6AE3C6E4" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDBA5.6AE3C6E4 Content-Type: text/plain; charset="iso-8859-1" Based on the comments made on this thread, does someone know when the DOI [RFC2407] will be updated to make the current DEFLATE transform ID historical and add a new DEFLATE transform ID without the extra header and Alder checksums, which would be the official on? In addition, do someone also know when RFC2394 will be updated to clarify the use and non-use of the extra header and Alder checksums with DEFLATE? Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFDBA5.6AE3C6E4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Minimum IP Compression Algorithm for = Interoperability

Based on the comments made on this thread, does = someone know when the DOI [RFC2407] will be updated to make the current = DEFLATE transform ID historical and add a new DEFLATE transform ID = without the extra header and Alder checksums, which would be the = official on?

In addition, do someone also know when RFC2394 will = be updated to clarify the use and non-use of the extra header and Alder = checksums with DEFLATE?

------_=_NextPart_001_01BFDBA5.6AE3C6E4-- From owner-ipsec@lists.tislabs.com Wed Jun 21 13:41:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00155; Wed, 21 Jun 2000 13:41:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02936 Wed, 21 Jun 2000 15:22:35 -0400 (EDT) Date: Wed, 21 Jun 2000 12:31:07 -0700 (PDT) From: Marc Hasson Message-Id: <200006211931.MAA14574@leo.mentat.com> To: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk wrote: > The problem was that RFC 2394 did not make it "_perfectly_ > clear that the header and checksum MUST NOT be used". Agreed! 2394/1951 don't explicitly mention those facilities at all. > Unfortunately both RFC 2394 and 1951 refer to the zlib > source/documentation for use as a freely available > deflate compliant package without mentioning the fact > that the header/checksum should not be used. Since the > header/checksum is the default mode of zlib and that not > using the header/checksum feature is undocumented (and > RFC 1950 mandates use of the checksum) this caused problems. However, if folks stuck strictly with the bits/protocols specified in the RFCs 2393, 2394, and 1951 one would not implement the header/checksums. Its only when one looks further into the Zlib references, uses Zlib, or digs up RFC 1950 (which isn't referenced as an RFC in any of 2393, 2394, 1951) that one would implement the additional header/checksum artifacts. The specs are fine as is but again I'd support an "implementation hint" in an appendix of 2394 to warn folks that wish to use off-the-shelf deflate packages that they should be wary that it produce/accept 2394/1951 encodings only. Writing down any "undocumented" methods to suppress the extra artifacts that folks have discovered into this same appendix sounds like a helpful suggestion. I believe we've had this suggestion since January, just no consensus yet to do it. -- Marc -- From owner-ipsec@lists.tislabs.com Wed Jun 21 19:25:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12454; Wed, 21 Jun 2000 19:25:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04149 Wed, 21 Jun 2000 21:16:27 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 21 Jun 2000 18:23:19 -0700 (PDT) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: group 10 and above? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm gald to say I won't be talking about AH or l2tp... Whatever happened to the discussion about groups 10, 11, and 12? I saw it at some point, but I haven't seen whether anyone has written up the groups in an rfc yet. Any takers? Tero? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Jun 21 21:09:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19455; Wed, 21 Jun 2000 21:09:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA04569 Wed, 21 Jun 2000 23:08:58 -0400 (EDT) Message-Id: <200006220315.UAA26048@ups.cisco.com> X-Sender: ntimms@ups.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 21 Jun 2000 19:31:09 -0700 To: ipsec@lists.tislabs.com From: Natalie Timms Subject: SCEP Informational Draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Raghava, The informational draft can be found at: http://search.ietf.org/internet-drafts/draft-nourse-scep-02.txt I don't think we've ever made source code available. Vendors like Entrust, Baltimore and Microsoft have based their SCEP support on the information presented in the draft. -Natalie -------------------------------------------------------------------------------------- Natalie Timms Ph Office : 425 468-0851 Software Engineer Email : ntimms@cisco.com VSEC BU Pager : 1 800 365 4578 or Cisco Systems ntimms@epage.cisco.com --------------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Jun 22 07:52:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14623; Thu, 22 Jun 2000 07:52:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06084 Thu, 22 Jun 2000 09:27:01 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E37596@eseis06nok> To: ipsec@lists.tislabs.com Subject: IKE Notify message - Status types Date: Thu, 22 Jun 2000 14:47:00 +0300 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are there other Status messages besides the CONNECTED one defined in IKE (RFC2408). I've seen in some documentation the existance of at least 2 more (RESPONDER-LIFETIME and REPLAY-STATUS) but I don't know where to find info about them. Just a reference of a draft or RFC would be enough. Thanks in advance! Toni Barrera Arboix NRC Ruoholahti (Helsinki) GSM +3580407431992 antonio.barrera@nokia.com From owner-ipsec@lists.tislabs.com Thu Jun 22 10:56:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23905; Thu, 22 Jun 2000 10:56:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06619 Thu, 22 Jun 2000 12:32:45 -0400 (EDT) Message-ID: <4DEC824F6F1FD3119BEF0000E86CEA01032A2BF3@mailserver.shastanets.com> From: Rahul Kulkarni To: "'antonio.barrera@nokia.com'" , ipsec@lists.tislabs.com Subject: RE: IKE Notify message - Status types Date: Thu, 22 Jun 2000 09:40:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Toni, The IPsec DOI (rfc 2407) has some info about them. Look up section 4.6.3 -- Rahul Kulkarni Nortel Networks rahul@nortelnetworks.com -----Original Message----- From: antonio.barrera@nokia.com [mailto:antonio.barrera@nokia.com] Sent: Thursday, June 22, 2000 4:47 AM To: ipsec@lists.tislabs.com Subject: IKE Notify message - Status types Importance: High Are there other Status messages besides the CONNECTED one defined in IKE (RFC2408). I've seen in some documentation the existance of at least 2 more (RESPONDER-LIFETIME and REPLAY-STATUS) but I don't know where to find info about them. Just a reference of a draft or RFC would be enough. Thanks in advance! Toni Barrera Arboix NRC Ruoholahti (Helsinki) GSM +3580407431992 antonio.barrera@nokia.com From owner-ipsec@lists.tislabs.com Thu Jun 22 10:57:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23938; Thu, 22 Jun 2000 10:57:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06649 Thu, 22 Jun 2000 12:39:43 -0400 (EDT) Date: Thu, 22 Jun 2000 19:48:22 +0300 (EET DST) Message-Id: <200006221648.TAA04328@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: antonio.barrera@nokia.com Cc: ipsec@lists.tislabs.com Subject: IKE Notify message - Status types In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A02E37596@eseis06nok> References: <0B3F42CA1FB6D2118FE50008C7894B0A02E37596@eseis06nok> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk antonio.barrera@nokia.com writes: > Are there other Status messages besides the CONNECTED one defined in > IKE (RFC2408). I've seen in some documentation the existance of at least 2 > more (RESPONDER-LIFETIME and REPLAY-STATUS) but I don't know where to find > info about them. Just a reference of a draft or RFC would be enough. > Thanks in advance! IPsec DOI RFC 2407: ---------------------------------------------------------------------- Network Working Group D. Piper Request for Comments: 2407 Network Alchemy Category: Standards Track November 1998 The Internet IP Security Domain of Interpretation for ISAKMP ... 4.6.3 IPSEC Notify Message Types ISAKMP defines two blocks of Notify Message codes, one for errors and one for status messages. ISAKMP also allocates a portion of each block for private use within a DOI. The IPSEC DOI defines the following private message types for its own use. Notify Messages - Error Types Value ----------------------------- ----- RESERVED 8192 Notify Messages - Status Types Value ------------------------------ ----- RESPONDER-LIFETIME 24576 REPLAY-STATUS 24577 INITIAL-CONTACT 24578 Notification Status Messages MUST be sent under the protection of an ISAKMP SA: either as a payload in the last Main Mode exchange; in a separate Informational Exchange after Main Mode or Aggressive Mode processing is complete; or as a payload in any Quick Mode exchange. These messages MUST NOT be sent in Aggressive Mode exchange, since Aggressive Mode does not provide the necessary protection to bind the Notify Status Message to the exchange. Nota Bene: a Notify payload is fully protected only in Quick Mode, where the entire payload is included in the HASH(n) digest. In Main Mode, while the notify payload is encrypted, it is not currently included in the HASH(n) digests. As a result, an active substitution attack on the Main Mode ciphertext could cause the notify status message type to be corrupted. (This is true, in general, for the last message of any Main Mode exchange.) While the risk is small, a corrupt notify message might cause the receiver to abort the entire negotiation thinking that the sender encountered a fatal error. Piper Standards Track [Page 22] RFC 2407 IP Security Domain of Interpretation November 1998 Implementation Note: the ISAKMP protocol does not guarantee delivery of Notification Status messages when sent in an ISAKMP Informational Exchange. To ensure receipt of any particular message, the sender SHOULD include a Notification Payload in a defined Main Mode or Quick Mode exchange which is protected by a retransmission timer. 4.6.3.1 RESPONDER-LIFETIME The RESPONDER-LIFETIME status message may be used to communicate the IPSEC SA lifetime chosen by the responder. When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (var) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP cookies) or four (4) (one IPSEC SPI) o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) o SPI - set to the two ISAKMP cookies or to the sender's inbound IPSEC SPI o Notification Data - contains an ISAKMP attribute list with the responder's actual SA lifetime(s) Implementation Note: saying that the Notification Data field contains an attribute list is equivalent to saying that the Notification Data field has zero length and the Notification Payload has an associated attribute list. 4.6.3.2 REPLAY-STATUS The REPLAY-STATUS status message may be used for positive confirmation of the responder's election on whether or not he is to perform anti-replay detection. When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (4) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP cookies) or four (4) (one IPSEC SPI) o Notify Message Type - set to REPLAY-STATUS o SPI - set to the two ISAKMP cookies or to the sender's inbound IPSEC SPI o Notification Data - a 4 octet value: Piper Standards Track [Page 23] RFC 2407 IP Security Domain of Interpretation November 1998 0 = replay detection disabled 1 = replay detection enabled 4.6.3.3 INITIAL-CONTACT The INITIAL-CONTACT status message may be used when one side wishes to inform the other that this is the first SA being established with the remote system. The receiver of this Notification Message might then elect to delete any existing SA's it has for the sending system under the assumption that the sending system has rebooted and no longer has access to the original SA's and their associated keying material. When used, the content of the Notification Data field SHOULD be null (i.e. the Payload Length should be set to the fixed length of Notification Payload). When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data (0) o DOI - set to IPSEC DOI (1) o Protocol ID - set to selected Protocol ID from chosen SA o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) o Notify Message Type - set to INITIAL-CONTACT o SPI - set to the two ISAKMP cookies o Notification Data - ... -- kivinen@iki.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Jun 22 10:58:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24002; Thu, 22 Jun 2000 10:58:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06655 Thu, 22 Jun 2000 12:40:48 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'IPsec List'" Subject: RE: uniqueness of Message IDs and related issues Date: Thu, 22 Jun 2000 12:44:50 -0400 Message-Id: <001701bfdc69$2f61ab30$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugh, This is my interpretation of the use of Message IDs in IKE: The intention of the Message ID is that it demultiplexes a stream of messages from a peer and passes each message on to the appropriate state machine. This allows multiple concurrent exchanges to not interfere with each other. (So if you are worried about collisions in 2^32 then you might want to check the generated Message ID against your current state table.) You don't need to suck up memory by storing all the previously used Message IDs. Replay protection is provided by making exchanges 3+ messages long and by using nonces (a message id can function as a nonce for this purpose). A nonce should be unpredictable to an adversary (although the attacks if it is not are pretty esoteric). A pseudorandom number generator does this well enough as long as you keep the seed value secret (of course you still have to generate the original seed from a truly random value). A Message ID should also be based off of a truly random seed so that two hosts running the same code don't consistently generate the same values. The Message ID is passed in the clear and is visible to an eavesdropper; therefore, it adds no real entropy to the secret key (against brute force) and its choice does not have cryptographic significance. I believe the MUST clause in the draft is a slight bit of hyperbole. Anyone want to add to/disagree with any of this? Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of D. Hugh Redelmeier > Sent: Tuesday, June 20, 2000 8:48 PM > To: IPsec List > Subject: uniqueness of Message IDs and related issues > > > [I am sorry that this message is so long and complicated. I'm not > sure how to safely separate the issues. I think that it is important > that at least some of these points are nailed down.] > > RFC2408 "ISAKMP" 3.1 "ISAKMP Header Format" (near end) states that > the Message ID must be unique: > > o Message ID (4 octets) - Unique Message Identifier used to > identify protocol state during Phase 2 negotiations. > This value > is randomly generated by the initiator of the Phase 2 > negotiation. In the event of simultaneous SA establishments > (i.e. collisions), the value of this field will likely be > different because they are independently generated > and, thus, two > security associations will progress toward establishment. > However, it is unlikely there will be absolute simultaneous > establishments. During Phase 1 negotiations, the value MUST be > set to 0. > > I can find no further clarification about what is meant by "unique". > > Clearly we cannot require that the Message ID be unique for all peers > since they may not be communicating (but no RFC or draft seems to > state this). > > In the past, I've enforced this as unique per peer during the lifetime > of my IKE daemon (Pluto, of the FreeS/WAN project). In other words, > whenever Pluto wanted to use a Message ID, it first made sure that the > Message ID hadn't been used before with the peer in question (at least > since the Pluto process had started). Whenever a peer started an > exchange with a previously used Message ID, Pluto rejected that as > improper. > > One problem with this approach is that it requires that Pluto to store > a growing and unbounded amount of state: the used Message IDs. > > I've just made a change that seems reasonable, but I cannot justify it > from text in an RFC or draft. Pluto now requires that the Message ID > only be unique within a single ISAKMP SA. Every Message ID seems to > occur in a context of an ISAKMP SA, so this seems reasonable. There > still may be a lot of Message IDs to store, but they expire with the > ISAKMP SA. Furthermore, since an ISAKMP SA does not survive a restart > of Pluto, it is OK for Pluto to "forget" all previously used Message > IDs when it is restarted -- a RAM table suffices. And, of course, an > ISAKMP SA is only between two hosts, so other hosts need not avoid > Message IDs that they cannot know about. > > Perhaps a little encouragement comes from RFC2409 "IKE", section 5.5 > "Phase 2 - Quick Mode": > > The message ID in the ISAKMP header identifies a Quick Mode in > progress for a particular ISAKMP SA which itself is > identified by the > cookies in the ISAKMP header. > > But another part, 5.7 "ISAKMP Informational Exchanges" says: > > As noted the message ID in the ISAKMP header-- and used in the prf > computation-- is unique to this exchange and MUST NOT be > the same as > the message ID of another phase 2 exchange which generated this > informational exchange. > > This does not qualify "unique" in any way. It does clearly use the > admonition "MUST NOT". > > Limiting uniqueness to being within an ISAKMP SA won't work if some > message refers to some object (say an IPSEC SA) negotiated under a > different ISAKMP SA using only a Message ID. A quick look at > draft-ietf-ipsec-notifymsg-02.txt makes me think that this isn't a > problem, but I'm not sure. > > One way of avoiding the storage of Message IDs is to "just hope" that > they are unique. They usually are. But this can hardly satisfy the > "MUST NOT". > > I have another reason for disliking the "just hope" approach. > draft-jenkins-ipsec-rekeying-06.txt seems too complicated and awkward > to me. In "2.2.1.4 Responder Pre-Set-up Security Hole", a simple > solution (Responder Pre-Set-up) is rejected due to an alleged replay > attack. If Message IDs are not allowed to be repeated, the replay > attack cannot succeed. > > I looked through many of the list messages for "Message ID" but found > none of these questions addressed. But I did find the following: > > | Date: Mon, 13 Dec 1999 12:37:58 -0500 > | From: Andrew Krywaniuk > | To: Tero Kivinen > | Cc: ipsec@lists.tislabs.com > | Subject: RE: heartbeats (summary of responses) > > | > If we start sending hearbeats inside the IKE message we also > | > might end up consuming our randomness quite fast. For > each IKE message > | > we need to create random message id and a random nonce. > | > | Hi Tero, > | > | I forgot to mention this before. I don't think randomness > is really an issue > | here. It is perfectly valid to use a seeded pseudorandom > number generator > | without consuming any additional randomness for each heartbeat. > | > | As far as I can tell, there is no security implication to using a > | pseudorandom message id. I suspect that the reason why we > don't simply use > | 1,2,3... is actually to avoid collisions and not to > generate entropy. > > Has a cryptologist clearly indicated whether the Message ID needs to > be random, or is pseudo-random good enough, or is predictable > acceptable? The part of RFC2408 quoted above clearly uses the phrase > "randomly generated". > > Oops: I just noticed that RFC2409 and some of the drafts refer to > "message ID", not "Message ID". I think that this is a mistake. But > it also meant that I didn't find all uses. For the record these are: > > draft-ietf-ipsec-ike-01.txt (expired, but I presume it will be > revived) > draft-ietf-ipsec-isakmp-mode-cfg-05.txt > draft-ietf-ipsec-isakmp-xauth-04.txt > draft-ietf-ipsec-notifymsg-02.txt > > draft-ietf-ipsec-ike-01.txt 8 "Security Considerations" says: > > The message ID used for all non-Phase 1 exchanges MUST be pseudo- > randomly generated using a strong random number generator. > > So that seems to settle it. Did this change get checked by a > cryptologist? > > The part of RFC2408 quoted at the top uses the phrase "initiator of > the Phase 2 negotiation" whereas draft-ietf-ipsec-ike-01.txt says "all > non-Phase 1 exchanges". I'd guess that draft-ietf-ipsec-ike-01.txt's > formulation should be used in RFC2408 because it is more accurate. > > > I would like these questions clearly resolved. (But perhaps the only > place they are not clearly resolved is in my mind.) > > - What is the scope over which a Message ID is to be unique? > > I propose that it be unique within the context of a single > ISAKMP SA. > > > - "MUST" or "SHOULD" a Message ID be unique? > > I propose that it "MUST" be unique. > > > - MUST (SHOULD?) the Message ID be generated randomly, > pseudo-randomly, or however the implementor feels like doing it? > > I propose that it be randomly, until a cryptologist convinces us > that something less is enough > > > - I think that the documents would be clearer if they always used > "Message ID" instead of sometimes using "Message ID", MID, and M-ID. > > Hugh Redelmeier > hugh@mimosa.com voice: +1 416 482-8253 > From owner-ipsec@lists.tislabs.com Thu Jun 22 12:48:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26063; Thu, 22 Jun 2000 12:48:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06974 Thu, 22 Jun 2000 14:03:57 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B7890D5@md-exchange1.nai.com> From: "Mason, David" To: "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: RE: group 10 and above? Date: Thu, 22 Jun 2000 11:10:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For the larger modp groups it would be beneficial to some systems if the number of set bits at the beginning and end of the primes was increased from 64 to 128. -dave -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Wednesday, June 21, 2000 9:23 PM To: ipsec@lists.tislabs.com Subject: group 10 and above? I'm gald to say I won't be talking about AH or l2tp... Whatever happened to the discussion about groups 10, 11, and 12? I saw it at some point, but I haven't seen whether anyone has written up the groups in an rfc yet. Any takers? Tero? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Jun 22 13:07:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26307; Thu, 22 Jun 2000 13:07:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07150 Thu, 22 Jun 2000 14:52:28 -0400 (EDT) Message-ID: <3950D0C1.7A0FA043@surfnet.nl> Date: Wed, 21 Jun 2000 16:27:13 +0200 From: Janus Liebregts Organization: SURFnet bv X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en,nl MIME-Version: 1.0 To: raghava CC: ipsec@lists.tislabs.com Subject: Re: SCEP References: <3.0.1.32.20000621181024.006f3b34@172.16.1.10> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5ADA94FFA9A7D293C94E267C" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms5ADA94FFA9A7D293C94E267C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit raghava, I'm not aware of any free source code SCEP clients. on http://www.sec.nl/persons/janus/scep you will find CA products supporting SCEP. regards, janus raghava wrote: > > Could anyone help me to get the free souce code of SCEP client? > And also I would like to know any CA Server that supports SCEP. > > -raghava --------------ms5ADA94FFA9A7D293C94E267C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJjQYJKoZIhvcNAQcCoIIJfjCCCXoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B58wggQAMIIC6KADAgECAgEYMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAk5MMRAwDgYD VQQKEwdTVVJGbmV0MRIwEAYDVQQDEwlPZmZpY2UtQ0ExIjAgBgkqhkiG9w0BCQEWE2NhLWFk bWluQHN1cmZuZXQubmwwHhcNMDAwNTMwMTQ1NjMzWhcNMDEwNTMwMTQ1NjMzWjBkMQswCQYD VQQGEwJOTDEQMA4GA1UEChMHU1VSRm5ldDEYMBYGA1UEAxMPSmFudXMgTGllYnJlZ3RzMSkw JwYJKoZIhvcNAQkBFhpKYW51cy5MaWVicmVndHNAc3VyZm5ldC5ubDCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEApBexzx6P0WFSwVgvB6qgJNvLGE754sy3ZiyaIT++TDWZwSWdJrBg VUpBPw3zA6mBsAFz7sqfzkUsABUfR3/Zp2IvQ59eH4GgyDfZVF/nLFmG8F8jX2xuPgcuhbMO P2cARL1+3Jo5BMj+yVWJ+wSeOVD9esPL6jyLpCc8utdGbWMCAwEAAaOCAUwwggFIMAsGA1Ud DwQEAwIF4DBsBglghkgBhvhCAQ0EXxZdQ1BTIHVzZWQgZm9yIGlzc3VpbmcgdGhpcyBjZXJ0 OiBodHRwczovL2NyZWNoZS53aW5kLnN1cmZuZXQubmwvb2ZmaWNlLWNhL29mZmljZS1DUFMu MS4xYS5odG1sMB0GA1UdDgQWBBStDAvVghHK7F7n1CVXSL5bKkKyTzCBqwYDVR0jBIGjMIGg oYGKpIGHMIGEMQswCQYDVQQGEwJOTDEQMA4GA1UEChMHU1VSRm5ldDEeMBwGA1UECxMVaHR0 cDovL3BraS5zdXJmbmV0Lm5sMRwwGgYDVQQDExNTVVJGbmV0IFBDQSBSb290IENBMSUwIwYJ KoZIhvcNAQkBFhZTVVJGbmV0LVBDQUBTVVJGbmV0Lm5sghEAwqunAwAAGNgAAAAQAAAAFDAN BgkqhkiG9w0BAQUFAAOCAQEAWOlBIZCFsF8NWQyBHG+Qqakbz6MgQW4Yz80bVmAEcR4QzlQA tsX7/EL6AqSGGpFfK1pAMtmAzuKGYwV/q+siXEnUxNDKn/qLNmuldOhiz0PQnoh7tNMiGlFO o5ENnot+b6Q0F5fpZCnpKzIOzOIbc/dDi+S9pmr8F4CXqqi/NbXmvs54a8SqAwDqu1vrRICX nDY139nckcjRDaAFeweXUVle8COru0jqvh1mGbA57QcnMZ/ABn1ZRu/4VDP66CyTi+27a6Q3 xN8JRHMtuhrtFR1oGD7LEwsSayT8xDIeq5Lj5vb/gMg5X751NceXfn+IeOtHT5mls/zu/xpg cQtdaTCCA5cwggJ/oAMCAQICEQDCq6cDAAAY2AAAABAAAAAUMA0GCSqGSIb3DQEBBQUAMIGE MQswCQYDVQQGEwJOTDEQMA4GA1UEChMHU1VSRm5ldDEeMBwGA1UECxMVaHR0cDovL3BraS5z dXJmbmV0Lm5sMRwwGgYDVQQDExNTVVJGbmV0IFBDQSBSb290IENBMSUwIwYJKoZIhvcNAQkB FhZTVVJGbmV0LVBDQUBTVVJGbmV0Lm5sMB4XDTAwMDQwNzEzMDAwOFoXDTAzMDMwNzE0MDAw OFowVzELMAkGA1UEBhMCTkwxEDAOBgNVBAoTB1NVUkZuZXQxEjAQBgNVBAMTCU9mZmljZS1D QTEiMCAGCSqGSIb3DQEJARYTY2EtYWRtaW5Ac3VyZm5ldC5ubDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALOwcNZSpOQ3BXQ8cVlFzRR71LnZb6ofGIh7drJUVcY9PyoPsVzs BYwBKGXOEEEH0LWPCaJri6Zzb5PmKnYRGTkV/xRTXxh62rbC8Qy1tzhFqQVouOf+4wXgGUaH lOQj6xGJantRgWqs/yPtcyghW/Urs8lhjnS/6LgPMtWTzp32ifa4Np18iF68SODStYd4SqFk NYPAWVSEa/NqXG1GKJtwxryUsNSGEweku06fNIF8OiyT+2o33GdrxOn7/JgvdzBpjH16PF9h P/Lz+Vj35TSDlk4NpYhdGLy5LJZIb7DQMAimLjAxjIWdOV38Y3Q6t7cfNoYku+mH/+BRuj8+ PXkCAwEAAaMwMC4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAYYwEQYJYIZIAYb4QgEBBAQD AgAHMA0GCSqGSIb3DQEBBQUAA4IBAQAxJqIa12wDcJLD4XfJUeZSMWcgg2rkVMG/o1NXU8Wz Oa5s7NT/Cu8iUZmYCeyE+n+LVAM39Nz1uKP5/N/GuXn95CAJDWhusGMgmPyw0YH2YYBM1vIP dLNOFFlXoey9tSFvDXncETOGAJL3llo/XbsZFS/Rg2piCz4fvSWcQdZXeDr/2GQ+oeufwLQV CxU7THu+PT5phKUAGswgOWoPMUrbcIFJvzrA0JBFvHs5PfVVZy5OErNPsLZFXD6I00yQhmgb rmy9MTVWISVWp37jsE+r4AbxapLXbefroYDU5q+8Y6XeHNZaZal/BzbNLb/BGkkev4TwPd82 zci5ulReq7txMYIBtjCCAbICAQEwXDBXMQswCQYDVQQGEwJOTDEQMA4GA1UEChMHU1VSRm5l dDESMBAGA1UEAxMJT2ZmaWNlLUNBMSIwIAYJKoZIhvcNAQkBFhNjYS1hZG1pbkBzdXJmbmV0 Lm5sAgEYMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDAwNjIxMTQyNzE0WjAjBgkqhkiG9w0BCQQxFgQUGyBRJYGFRbSXs9jNGcnz /55XzlkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBd g66BEsNq8hw2wYLOLgywdE2xO99puQb2esw1y6JIMx5Dmaz9dO0XYdVQpqCK91fZ0+43hSEd inpOuNF+9n5MyPRhDO2C5aZ61yUGuQ+oZZ0TxUPA9nODZQn/YRCm9pMEKCFek8cek3+5hZue H1Y6ddCeIPmGQU5A46RsNpMmOg== --------------ms5ADA94FFA9A7D293C94E267C-- From owner-ipsec@lists.tislabs.com Thu Jun 22 13:09:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26341; Thu, 22 Jun 2000 13:09:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07182 Thu, 22 Jun 2000 14:54:35 -0400 (EDT) Message-Id: <3.0.5.32.20000621195423.00ad83d0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jun 2000 19:54:23 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: RE: Minimum IP Compression Algorithm for Interoperability In-Reply-To: <918C70B01822D411A87400B0D0204DFF04C03B@panda.chrysalis-its .com> 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 lists.tislabs.com id NAA02608 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francois wrote: >Based on the comments made on this thread, does someone know when >the DOI [RFC2407] will be updated to make the current DEFLATE >transform ID historical and add a new DEFLATE transform ID without >the extra header and Alder checksums, which would be the official on? > Ain't gonna happen. That was actually my proposal, but the general reply was "Why should the people who got it _right_ change their implementation (switch to other ID), making the new version incompatible to their old versions? And BTW, learn how to read, especially RFCs." Fair enough. The general suggestion in this case would be "Will the programmers please fix their broken software". >In addition, do someone also know when RFC2394 will be updated >to clarify the use and non-use of the extra header and Alder checksums with DEFLATE? > Well, it's not a draft, it's a RFC already. Changing it is not trivial. Tero suggested the same, but I think it would be better to put that information into another place: Into the zlib documentation! J�rn From owner-ipsec@lists.tislabs.com Thu Jun 22 13:09:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26356; Thu, 22 Jun 2000 13:09:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07054 Thu, 22 Jun 2000 14:26:00 -0400 (EDT) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Dan Harkins'" , "Andrew Krywaniuk" Cc: "'IPsec List'" Subject: RE: uniqueness of Message IDs and related issues Date: Thu, 22 Jun 2000 14:28:51 -0400 Message-Id: <002001bfdc77$b79bc040$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <200006221725.KAA15437@potassium.network-alchemy.com> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The MUST clause is not hyperbole. It states that the > message ID of the > notify MUST NOT be the same as the message ID of the Quick > Mode exchange > that generated the error. This is because, as you noted, the > message ID > is used to demultiplex the exchanges that two peers may be engaging in > at any one moment-- this can be more than 1. This verbage resolved an > interoperability issue some time ago. Sure, but I was actually refering to this quote: The message ID used for all non-Phase 1 exchanges MUST be pseudo- randomly generated using a strong random number generator. I think that's a bit of hyperbole. As you mentioned, the important thing is that the Message ID is not used for two exchanges which occur in temporal proximity (if you'll excuse the Star Trek-ish terminology). > Also, if the message ID has no cryptographic significance > then it does > not need to be based off a "truely random seed". Okay, sure. The point of my original message was that you don't need to keep adding entropy for every Message ID you generate. You just need a stream of unpredictable data; it doesn't have to be truly random. (and to defeat an adversary who can guess your entire state you need a truly random seed) Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > Sent: Thursday, June 22, 2000 1:26 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'IPsec List' > Subject: Re: uniqueness of Message IDs and related issues > > > OK, I'll disagree with some of it. > > The MUST clause is not hyperbole. It states that the > message ID of the > notify MUST NOT be the same as the message ID of the Quick > Mode exchange > that generated the error. This is because, as you noted, the > message ID > is used to demultiplex the exchanges that two peers may be engaging in > at any one moment-- this can be more than 1. This verbage resolved an > interoperability issue some time ago. > > Also, if the message ID has no cryptographic significance > then it does > not need to be based off a "truely random seed". > > Dan. > > On Thu, 22 Jun 2000 12:44:50 EDT you wrote > > > > I believe the MUST clause in the draft is a slight bit of hyperbole. > > > > Anyone want to add to/disagree with any of this? > > > > Andrew > From owner-ipsec@lists.tislabs.com Thu Jun 22 13:15:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26434; Thu, 22 Jun 2000 13:15:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07213 Thu, 22 Jun 2000 14:56:28 -0400 (EDT) Message-Id: <200006221725.KAA15437@potassium.network-alchemy.com> To: andrew.krywaniuk@alcatel.com cc: "'IPsec List'" Subject: Re: uniqueness of Message IDs and related issues In-reply-to: Your message of "Thu, 22 Jun 2000 12:44:50 EDT." <001701bfdc69$2f61ab30$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15434.961694749.1@network-alchemy.com> Date: Thu, 22 Jun 2000 10:25:49 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, I'll disagree with some of it. The MUST clause is not hyperbole. It states that the message ID of the notify MUST NOT be the same as the message ID of the Quick Mode exchange that generated the error. This is because, as you noted, the message ID is used to demultiplex the exchanges that two peers may be engaging in at any one moment-- this can be more than 1. This verbage resolved an interoperability issue some time ago. Also, if the message ID has no cryptographic significance then it does not need to be based off a "truely random seed". Dan. On Thu, 22 Jun 2000 12:44:50 EDT you wrote > > I believe the MUST clause in the draft is a slight bit of hyperbole. > > Anyone want to add to/disagree with any of this? > > Andrew From owner-ipsec@lists.tislabs.com Thu Jun 22 15:12:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28684; Thu, 22 Jun 2000 15:12:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07656 Thu, 22 Jun 2000 16:22:31 -0400 (EDT) From: FRousseau@chrysalis-its.com Message-ID: <918C70B01822D411A87400B0D0204DFF04C04C@panda.chrysalis-its.com> To: joern.sierwald@F-Secure.com Cc: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability Date: Thu, 22 Jun 2000 16:31:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDC88.EA40BD3C" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDC88.EA40BD3C Content-Type: text/plain; charset="iso-8859-1" Joern, See comments below. Francois >-----Original Message----- >From: Joern Sierwald [mailto:joern.sierwald@F-Secure.com] >Sent: Wednesday, June 21, 2000 1:54 PM >To: ipsec@lists.tislabs.com >Subject: RE: Minimum IP Compression Algorithm for Interoperability > >Francois wrote: > >>Based on the comments made on this thread, does someone know when >>the DOI [RFC2407] will be updated to make the current DEFLATE >>transform ID historical and add a new DEFLATE transform ID without >>the extra header and Alder checksums, which would be the official on? > >Ain't gonna happen. That was actually my proposal, but the general reply >was "Why should the people who got it _right_ change their implementation >(switch to other ID), making the new version incompatible to their old >versions? >And BTW, learn how to read, especially RFCs." > >Fair enough. The general suggestion in this case would be >"Will the programmers please fix their broken software". I agree with the general consensus of not updating RFC2407. >>In addition, do someone also know when RFC2394 will be updated >>to clarify the use and non-use of the extra header and Alder checksums >>with DEFLATE? > >Well, it's not a draft, it's a RFC already. Changing it is not trivial. >Tero suggested the same, but I think it would be better to put that >information >into another place: > >Into the zlib documentation! However, although RFC2394 is an RFC, it is not yet on the standard track and could be replaced by an updated version containing an Appendix clarifying the non-use of the extra header and Adler checksum as suggested by others. >J-rn > ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFDC88.EA40BD3C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Minimum IP Compression Algorithm for = Interoperability

Joern,

See comments below.

Francois

>-----Original Message-----
>From: Joern Sierwald [mailto:joern.sierwald@F-Secu= re.com]
>Sent: Wednesday, June 21, 2000 1:54 PM
>To: ipsec@lists.tislabs.com
>Subject: RE: Minimum IP Compression Algorithm = for Interoperability
>
>Francois wrote:
>
>>Based on the comments made on this thread, = does someone know when
>>the DOI [RFC2407] will be updated to make = the current DEFLATE
>>transform ID historical and add a new = DEFLATE transform ID without
>>the extra header and Alder checksums, which = would be the official on?
>
>Ain't gonna happen. That was actually my = proposal, but the general reply
>was "Why should the people who got it = _right_ change their implementation
>(switch to other ID), making the new version = incompatible to their old
>versions?
>And BTW, learn how to read, especially = RFCs."
>
>Fair enough. The general suggestion in this case = would be
>"Will the programmers please fix their = broken software".

I agree with the general consensus of not updating = RFC2407.

>>In addition, do someone also know when = RFC2394 will be updated
>>to clarify the use and non-use of the extra = header and Alder checksums
>>with DEFLATE?
>
>Well, it's not a draft, it's a RFC already. = Changing it is not trivial.
>Tero suggested the same, but I think it would be = better to put that
>information
>into another place:
>
>Into the zlib documentation!

However, although RFC2394 is an RFC, it is not yet on = the standard track and could be replaced by an updated version = containing an Appendix clarifying the non-use of the extra header and = Adler checksum as suggested by others.

>J-rn
>
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFDC88.EA40BD3C-- From owner-ipsec@lists.tislabs.com Thu Jun 22 19:29:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12085; Thu, 22 Jun 2000 19:29:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA08588 Thu, 22 Jun 2000 21:01:40 -0400 (EDT) Date: Thu, 22 Jun 2000 18:10:14 -0700 (PDT) From: Marc Hasson Message-Id: <200006230110.SAA19138@leo.mentat.com> To: ipsec@lists.tislabs.com Subject: RE: Minimum IP Compression Algorithm for Interoperability X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: FRousseau@chrysalis-its.com ... > >Well, it's not a draft, it's a RFC already. Changing it is not trivial. > >Tero suggested the same, but I think it would be better to put that > >information > >into another place: > > > >Into the zlib documentation! > > However, although RFC2394 is an RFC, it is not yet on the standard track and > could be replaced by an updated version containing an Appendix clarifying > the non-use of the extra header and Adler checksum as suggested by others. I agree completely. Also I don't think the zlib documentation update is sufficient for implementers who may pick up random/old versions of zlib code/documentation. Its 2394 that folks on this list and the ippcp list have control over, not the zlib documentation. If the zlib documentation could also be updated to show clearly how to not generate/require the header/checksum features that would be nice, but I don't know who would do that or where it lives. Its essential that 2394 be as clear as possible if only so that people not on our mailing lists can judge interoperability problems correctly between 2 future implementations, by carefully reading the spec. The current 2394 leads people to use zlib without any constraints or hints on that usage, which encourages people to use it without understanding the true protocol required. -- Marc -- From owner-ipsec@lists.tislabs.com Fri Jun 23 09:26:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21145; Fri, 23 Jun 2000 09:26:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11294 Fri, 23 Jun 2000 10:47:26 -0400 (EDT) Message-ID: <000b01bfdd22$3c4a44b0$064190d5@corrado> Reply-To: "Corrado Derenale" From: "Corrado Derenale" To: References: <3.0.1.32.20000621181024.006f3b34@172.16.1.10> Subject: SCEP Server Date: Fri, 23 Jun 2000 16:49:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, ive just finished with writing a SCEP server using openssl. I've done it for my hight degree. The whole work will be published in a few week... stay tuned :-) :-) :-) ----- Original Message ----- From: raghava To: Sent: Wednesday, June 21, 2000 3:10 PM Subject: SCEP > > Could anyone help me to get the free souce code of SCEP client? > And also I would like to know any CA Server that supports SCEP. > > -raghava > From owner-ipsec@lists.tislabs.com Fri Jun 23 12:22:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00529; Fri, 23 Jun 2000 12:22:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11836 Fri, 23 Jun 2000 13:52:53 -0400 (EDT) Message-ID: <3953A5ED.DDCB9211@ire-ma.com> Date: Fri, 23 Jun 2000 14:01:17 -0400 From: Christopher Welles Reply-To: cwelles@ire-ma.com Organization: IRE X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: SCEP References: <3.0.1.32.20000621181024.006f3b34@172.16.1.10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Raghava: IRE has Windows SCEP client code, which we are selling to OEMs. SCEP is based on PKCS10 and PKCS7. If you're familiar with the PKCS7 and PKCS10, and have library code to implement them, the SCEP implementation is about 4K lines of C++ code. (If your platform is Windows, Microsoft's CryptoAPI has PKCS7 and PKCS10 support .) If you don't have PKCS7/10, each one is probably another 2K to 4K to implement, assuming you have an ASN.1 library to handle the message encode/decode. Hope this helps. Chris raghava wrote: > Could anyone help me to get the free souce code of SCEP client? > And also I would like to know any CA Server that supports SCEP. > > -raghava -- ___________________________________________________________________ Christopher Welles w (978) 539 4822 Information Resource Engineering http://www.ire.com From owner-ipsec@lists.tislabs.com Fri Jun 23 18:20:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11651; Fri, 23 Jun 2000 18:20:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13060 Fri, 23 Jun 2000 19:57:33 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 23 Jun 2000 17:05:43 -0700 (PDT) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: phase 2 and ports Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was wondering if anyone had a good solution to this problem, or if people are interested in one in general. Maybe people don't think this is a problem? I'd like to hear opinions. Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to name a few). Other protocols a priori use more than one port (can't think of any examples, but I don't see why this couldn't be the case), yet the ID payload has a field for a single port only. There's no way in IKE to negotiate something like src-ip=A, src-port=8-10, dst-IP=B, dst-port=8-10 (an example only). As far as I can tell, you'd have to negotiate one SA per port, i.e. 3 SA's in the above example (times 2, since we're doing bidirectional). There's really TWO problems here: a) port-ranges would be usefull for applications that know a priori what ports they are going to use. On a side note, it's always kind of bothered me that we need 2 ID payloads. I assume this is so we can reuse the ID payload from phase 1, but it might be handy to define a generic payload that defines the selector as a whole in a single payload. b) an application-ID would be usefull for applications that do NOT know a priori what ports to use (l2tp for example). I could see using the tuple protocol:port as an application identifier, and somehow 'teach' ipsec to identify what traffic constitutes that application (note I'm not advocating adding l2tp code into ipsec; this could conceivably be done via some API between the two..). Has anyone come up with a solution for this? Does someone think this is NOT a problem (in which case I'd like to hear some proposed ways of dealing with the above; but see PS below)? From my readings of the rfc's, I don't see how this can be done, although ipsec certainly can handle multiple ports. You just can't negotiate it in IKE... jan P.S. I know of at least one vendor that solves this problem by using port=0 (i.e. 'all ports') and filtering traffic behind ipsec. I don't consider that a good solution, since the peer may not know of this filtering and needlessly encrypts and sends stuff that the other side is just going to toss anyway. It wastes CPU on both sides and wastes bandwidth. It's also a bit hard to debug ("We negotiated all ports... I wonder why none of my traffic is getting through...") -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Jun 26 01:50:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA00910; Mon, 26 Jun 2000 01:50:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18436 Mon, 26 Jun 2000 02:40:00 -0400 (EDT) Message-ID: <3956FCCC.2A96334F@lmf.ericsson.se> Date: Mon, 26 Jun 2000 09:48:44 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: ipsec@lists.tislabs.com Subject: Re: phase 2 and ports References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to > name a few). Other protocols a priori use more than one port (can't think of This is a real problem. Maybe we could come up with an API or a protocol to enable applications to control security services in the manner you propose. >a) port-ranges would be usefull for applications that know a priori what I remember in the last IETF Steven Bellovin gave a talk about a similar problem for SCTP (one of the signaling protocols). There the problem was with several IP addresses. If somebody's going to extend ID payloads, such extensions should cover both issues. > ports they are going to use. On a side note, it's always kind of bothered > me that we need 2 ID payloads. I assume this is so we can reuse the ID Isn't this because, say, L2TP client is has a wildcard port number and the server a fixed one? Jari From owner-ipsec@lists.tislabs.com Mon Jun 26 07:58:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11907; Mon, 26 Jun 2000 07:58:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19740 Mon, 26 Jun 2000 09:02:18 -0400 (EDT) Message-Id: <200006240131.e5O1VJJ109685@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: ipsec@lists.tislabs.com Subject: Re: phase 2 and ports In-reply-to: Your message of "Fri, 23 Jun 2000 17:05:43 PDT." Reply-to: sommerfeld@East.Sun.COM Date: Fri, 23 Jun 2000 21:31:19 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I was wondering if anyone had a good solution to this problem, or if people > are interested in one in general. Maybe people don't think this is a > problem? This is a real problem. > Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to > name a few). Other protocols a priori use more than one port (can't think of > any examples, but I don't see why this couldn't be the case), yet the ID > payload has a field for a single port only. There's no way in IKE to > negotiate something like src-ip=A, src-port=8-10, dst-IP=B, dst-port=8-10 (an > example only). > > As far as I can tell, you'd have to negotiate one SA per port, i.e. 3 SA's in > the above example (times 2, since we're doing bidirectional). Multiple SA's isn't necessarily a problem -- from a crypto-paranoia standpoint, it's better to use different keys for different things. To reuse ftp as an example, the files being transferred and the control channel may want very different protection. (e.g., if you're uploading stuff to an anonymous FTP site you may only need integrity protection on the ftp-data connection but want to keep the passwords, etc., on the control connection secret). The tricky part comes with knowing which policy to apply to the floating port.. [aside: If there's a perception that the multiple phase-2 exchanges needed are a performance problem then maybe I should go resurrect my inline keying draft..] > b) an application-ID would be usefull for applications that do NOT know a > priori what ports to use (l2tp for example). I could see using the tuple > protocol:port as an application identifier, and somehow 'teach' ipsec to > identify what traffic constitutes that application. warning: This opens a naming can-of-worms. With some application assistance (i.e., ftpd telling the stack "I want the data connection I'm initiating to connect back to the same principal/entity which initiated the control connection i accepted") this might not be so bad. I'm increasingly coming to think that we need to start specifying the handling of principals and identities within IPSEC and IKE a bit more closely. for what it's worth, I like the general properties of the model presented in [1] quite a bit, but fitting that into the existing IKE framework will be messy. > P.S. I know of at least one vendor that solves this problem by using port=0 > (i.e. 'all ports') and filtering traffic behind ipsec. It's their right to do this, but it's pretty unfriendly. - Bill [1] Authentication in Distributed Systems: Theory and Practice Butler Lampson, Martin Abadi, Michael Burrows, Edward Wobber http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-083.html From owner-ipsec@lists.tislabs.com Mon Jun 26 08:38:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13195; Mon, 26 Jun 2000 08:38:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20030 Mon, 26 Jun 2000 10:19:34 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: sommerfeld@East.Sun.COM Cc: Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: phase 2 and ports Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jun 2000 10:28:17 -0400 Message-Id: <20000626142818.54EF635DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200006240131.e5O1VJJ109685@thunk.east.sun.com>, Bill Sommerfeld wri tes: > >Multiple SA's isn't necessarily a problem -- from a crypto-paranoia >standpoint, it's better to use different keys for different things. Usually, that's correct, though from a traffic analysis standpoint it's not. Also see my paper on probable plaintext attacks on IPsec. > > > > b) an application-ID would be usefull for applications that do NOT know a > > priori what ports to use (l2tp for example). I could see using the tuple > > protocol:port as an application identifier, and somehow 'teach' ipsec to > > identify what traffic constitutes that application. > >warning: This opens a naming can-of-worms. > >With some application assistance (i.e., ftpd telling the stack "I want >the data connection I'm initiating to connect back to the same >principal/entity which initiated the control connection i accepted") >this might not be so bad. > >I'm increasingly coming to think that we need to start specifying the >handling of principals and identities within IPSEC and IKE a bit more >closely. for what it's worth, I like the general properties of the >model presented in [1] quite a bit, but fitting that into the existing >IKE framework will be messy. "Opens" the can of worms? I wish we would open it -- I've been complaining about this issue for years. (See http://www.research.att.com/~smb/talks/ipsec-cert.ps, which is a talk I gave in December, 1996 at the San Jose IETF.) --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon Jun 26 13:05:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22807; Mon, 26 Jun 2000 13:05:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21085 Mon, 26 Jun 2000 14:39:42 -0400 (EDT) Date: Mon, 26 Jun 2000 14:47:28 -0400 (EDT) From: Skip Booth To: Jari Arkko cc: Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: phase 2 and ports In-Reply-To: <3956FCCC.2A96334F@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Jun 2000, Jari Arkko wrote: > Jan Vilhuber wrote: > > > Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to > > name a few). Other protocols a priori use more than one port (can't think of > > This is a real problem. > > Maybe we could come up with an API or a protocol to enable applications > to control security services in the manner you propose. > > >a) port-ranges would be usefull for applications that know a priori what > > I remember in the last IETF Steven Bellovin gave a talk about a similar > problem for SCTP (one of the signaling protocols). There the problem was > with several IP addresses. If somebody's going to extend ID payloads, > such extensions should cover both issues. > > > ports they are going to use. On a side note, it's always kind of bothered > > me that we need 2 ID payloads. I assume this is so we can reuse the ID > > Isn't this because, say, L2TP client is has a wildcard port number and > the server a fixed one? Actually the server starts on a fixed port and then may move to a dynamic port on its reply. The potential flow is: LAC to LNS: SCCRQ (src UDP port = Wildcard, dst UDP port = 1701) LNS to LAC: SCCRP (src UDP port = Wildcard, dst UDP port = Wildcard) LAC to LNS: SCCCN (src UDP port = Wildcard, dst UDP port = Wildcard) Currently IKE doesn't have a method for negotiating such a sequence without negotiated 2 phase 2 SA's or negotiating ANY to ANY on the ports, or Fixed to Any on the ports. The later two cases allow for traffic other than L2TP to be put into the tunnel which is not desirable. The Security Gateways would be required to implement secondary acls behind the IPsec SAs to stop non-L2TP traffic if ANY is negotiated. In the L2TP security draft we have proposed negotiating 2 phase 2 SAs if both peers need to float their UDP ports. It would definitely be nice if IKE had a built in method for taking care of this. -Skip > > Jari > > From owner-ipsec@lists.tislabs.com Mon Jun 26 13:05:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22822; Mon, 26 Jun 2000 13:05:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20997 Mon, 26 Jun 2000 14:17:32 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Jan Vilhuber'" , Subject: RE: phase 2 and ports Date: Mon, 26 Jun 2000 14:21:30 -0400 Message-Id: <004b01bfdf9b$5a3ee720$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > P.S. I know of at least one vendor that solves this problem > by using port=0 > (i.e. 'all ports') and filtering traffic behind ipsec. I > don't consider that > a good solution, since the peer may not know of this > filtering and needlessly > encrypts and sends stuff that the other side is just going to > toss anyway. It > wastes CPU on both sides and wastes bandwidth. It's also a > bit hard to debug > ("We negotiated all ports... I wonder why none of my traffic > is getting > through...") In mind, this is still the theoretically "correct" way of solving the problem. The way to avoid black holes is to use a firewall policy sharing protocol. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > Sent: Friday, June 23, 2000 8:06 PM > To: ipsec@lists.tislabs.com > Subject: phase 2 and ports > > > I was wondering if anyone had a good solution to this > problem, or if people > are interested in one in general. Maybe people don't think > this is a problem? > I'd like to hear opinions. > > Here's the problem: Some protocols float ports (example l2tp, > ftp, h.323, to > name a few). Other protocols a priori use more than one port > (can't think of > any examples, but I don't see why this couldn't be the case), > yet the ID > payload has a field for a single port only. There's no way in IKE to > negotiate something like src-ip=A, src-port=8-10, dst-IP=B, > dst-port=8-10 (an > example only). > > As far as I can tell, you'd have to negotiate one SA per > port, i.e. 3 SA's in > the above example (times 2, since we're doing bidirectional). > > There's really TWO problems here: > > a) port-ranges would be usefull for applications that know a > priori what > ports they are going to use. On a side note, it's always > kind of bothered > me that we need 2 ID payloads. I assume this is so we can > reuse the ID > payload from phase 1, but it might be handy to define a > generic payload > that defines the selector as a whole in a single payload. > b) an application-ID would be usefull for applications that > do NOT know a > priori what ports to use (l2tp for example). I could see > using the tuple > protocol:port as an application identifier, and somehow > 'teach' ipsec to > identify what traffic constitutes that application (note I'm not > advocating adding l2tp code into ipsec; this could > conceivably be done via > some API between the two..). > > Has anyone come up with a solution for this? Does someone > think this is NOT a > problem (in which case I'd like to hear some proposed ways of > dealing with > the above; but see PS below)? From my readings of the rfc's, > I don't see how > this can be done, although ipsec certainly can handle > multiple ports. You > just can't negotiate it in IKE... > > jan > > P.S. I know of at least one vendor that solves this problem > by using port=0 > (i.e. 'all ports') and filtering traffic behind ipsec. I > don't consider that > a good solution, since the peer may not know of this > filtering and needlessly > encrypts and sends stuff that the other side is just going to > toss anyway. It > wastes CPU on both sides and wastes bandwidth. It's also a > bit hard to debug > ("We negotiated all ports... I wonder why none of my traffic > is getting > through...") > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Mon Jun 26 13:43:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23424; Mon, 26 Jun 2000 13:43:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21194 Mon, 26 Jun 2000 15:19:45 -0400 (EDT) Message-Id: <200006261921.MAA02694@potassium.network-alchemy.com> To: Jan Vilhuber cc: ipsec@lists.tislabs.com Subject: Re: phase 2 and ports In-reply-to: Your message of "Fri, 23 Jun 2000 17:05:43 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2691.962047294.1@network-alchemy.com> Date: Mon, 26 Jun 2000 12:21:34 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, It's a big problem that we punted on. I believe (correct me if I'm wrong Steve) that the draft that became RFC2401 actually discussed selector parameters for port ranges but that was removed because it was not possible to express them in IKE (using ISAKMP inside of the DOI). This issue is part of http://www.lounge.org/ike_doi_errata.html which drove the son-of-ike draft, which quietly expired. There was discussion in Adelaide about what to do with IKE and whether it would produce any progeny but there didn't seem to be any concensus. Of course reving the key management troika (or even better combining those three into 1 new document) would also cause RFC2401 to be revved. Dan. On Fri, 23 Jun 2000 17:05:43 PDT you wrote > I was wondering if anyone had a good solution to this problem, or if people > are interested in one in general. Maybe people don't think this is a problem? > I'd like to hear opinions. > > Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to > name a few). Other protocols a priori use more than one port (can't think of > any examples, but I don't see why this couldn't be the case), yet the ID > payload has a field for a single port only. There's no way in IKE to > negotiate something like src-ip=A, src-port=8-10, dst-IP=B, dst-port=8-10 (an > example only). > > As far as I can tell, you'd have to negotiate one SA per port, i.e. 3 SA's in > the above example (times 2, since we're doing bidirectional). > > There's really TWO problems here: > > a) port-ranges would be usefull for applications that know a priori what > ports they are going to use. On a side note, it's always kind of bothered > me that we need 2 ID payloads. I assume this is so we can reuse the ID > payload from phase 1, but it might be handy to define a generic payload > that defines the selector as a whole in a single payload. > b) an application-ID would be usefull for applications that do NOT know a > priori what ports to use (l2tp for example). I could see using the tuple > protocol:port as an application identifier, and somehow 'teach' ipsec to > identify what traffic constitutes that application (note I'm not > advocating adding l2tp code into ipsec; this could conceivably be done via > some API between the two..). > > Has anyone come up with a solution for this? Does someone think this is NOT a > problem (in which case I'd like to hear some proposed ways of dealing with > the above; but see PS below)? From my readings of the rfc's, I don't see how > this can be done, although ipsec certainly can handle multiple ports. You > just can't negotiate it in IKE... > > jan > > P.S. I know of at least one vendor that solves this problem by using port=0 > (i.e. 'all ports') and filtering traffic behind ipsec. I don't consider that > a good solution, since the peer may not know of this filtering and needlessly > encrypts and sends stuff that the other side is just going to toss anyway. It > wastes CPU on both sides and wastes bandwidth. It's also a bit hard to debug > ("We negotiated all ports... I wonder why none of my traffic is getting > through...") > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Mon Jun 26 14:54:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24537; Mon, 26 Jun 2000 14:54:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21233 Mon, 26 Jun 2000 15:26:08 -0400 (EDT) Date: Mon, 26 Jun 2000 15:33:57 -0400 (EDT) From: Skip Booth To: Jari Arkko cc: Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: phase 2 and ports In-Reply-To: <3956FCCC.2A96334F@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Jun 2000, Jari Arkko wrote: > Jan Vilhuber wrote: > > > Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to > > name a few). Other protocols a priori use more than one port (can't think of > > This is a real problem. > > Maybe we could come up with an API or a protocol to enable applications > to control security services in the manner you propose. Does anyone remember the draft titled: draft-mcdonald-simple-ipsec-api-01.txt It has long since expired and I don't recall giving it more than a casual glance at the time, but I am wondering whether there was anything useful in this draft to use as a starting point for such an API. If someone still has a copy of this sitting around, please send it to me. -Skip > > >a) port-ranges would be usefull for applications that know a priori what > > I remember in the last IETF Steven Bellovin gave a talk about a similar > problem for SCTP (one of the signaling protocols). There the problem was > with several IP addresses. If somebody's going to extend ID payloads, > such extensions should cover both issues. > > > ports they are going to use. On a side note, it's always kind of bothered > > me that we need 2 ID payloads. I assume this is so we can reuse the ID > > Isn't this because, say, L2TP client is has a wildcard port number and > the server a fixed one? > > Jari > > From owner-ipsec@lists.tislabs.com Tue Jun 27 02:12:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA24072; Tue, 27 Jun 2000 02:12:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA23251 Tue, 27 Jun 2000 03:16:43 -0400 (EDT) Message-Id: <200006270725.LAA22289@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Jan Vilhuber , Dan Harkins Date: Tue, 27 Jun 2000 11:24:38 +0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: phase 2 and ports CC: ipsec@lists.tislabs.com In-reply-to: <200006261921.MAA02694@potassium.network-alchemy.com> References: Your message of "Fri, 23 Jun 2000 17:05:43 PDT." X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 26 Jun 00, at 12:21, Dan Harkins wrote: Jan, Dan, actually there is another problem here: while IKE can negotiate level of traffic protection (by means of SA payload), it currently is unable to negotiate scope of this protection - initiator can only suggest this scope (via IDui & IDur payloads) and responder can only accept it or reject the whole exchange. This is due to (as Dan pointed out far ago) ID payload semantics currently is overloaded - in Quick Mode it simultaneously represents scope of protection desired by initiator and, hidden in it, actual parameters of IP packet that has triggered this Quick Mode. One of the possible solutions would be to separate this functions by introducing new payload, say Policy Payload. Its format must allow to represent complex policy constructions, such as lists and ranges of IP addresses, protocols and ports. In this case initiator would send both ID payloads and Policy payload in Quick Mode. ID payloads must indicate actual IP packet parameters that has triggered this negotiation and Policy payload must indicate the desirable for initiator scope of protection. Of course, parameters represented in ID payloads must "fit" into Policy payload. Responder must return ID payloads intact (as currently), but is allowed to modify Policy payload according to its local policy requirements regarding scope of protection. For security reasons it must be allowed only to "narrow" scope of protection. Of course, ID payloads must still "fit" into this modified scope. On receipt of this message initiator decides whether this modified scope is acceptable for him, or not, and continues exchange or terminates it accordingly. This is rather simple sceme that, by the way, allows backward compatibility with current approach. Regards, Valera. > Jan, > > It's a big problem that we punted on. I believe (correct me if I'm wrong > Steve) that the draft that became RFC2401 actually discussed selector > parameters for port ranges but that was removed because it was not possible > to express them in IKE (using ISAKMP inside of the DOI). > > This issue is part of http://www.lounge.org/ike_doi_errata.html which > drove the son-of-ike draft, which quietly expired. There was discussion in > Adelaide about what to do with IKE and whether it would produce any progeny > but there didn't seem to be any concensus. Of course reving the key > management troika (or even better combining those three into 1 new document) > would also cause RFC2401 to be revved. > > Dan. > > On Fri, 23 Jun 2000 17:05:43 PDT you wrote > > I was wondering if anyone had a good solution to this problem, or if people > > are interested in one in general. Maybe people don't think this is a problem? > > I'd like to hear opinions. > > > > Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to > > name a few). Other protocols a priori use more than one port (can't think of > > any examples, but I don't see why this couldn't be the case), yet the ID > > payload has a field for a single port only. There's no way in IKE to > > negotiate something like src-ip=A, src-port=8-10, dst-IP=B, dst-port=8-10 (an > > example only). > > > > As far as I can tell, you'd have to negotiate one SA per port, i.e. 3 SA's in > > the above example (times 2, since we're doing bidirectional). > > > > There's really TWO problems here: > > > > a) port-ranges would be usefull for applications that know a priori what > > ports they are going to use. On a side note, it's always kind of bothered > > me that we need 2 ID payloads. I assume this is so we can reuse the ID > > payload from phase 1, but it might be handy to define a generic payload > > that defines the selector as a whole in a single payload. > > b) an application-ID would be usefull for applications that do NOT know a > > priori what ports to use (l2tp for example). I could see using the tuple > > protocol:port as an application identifier, and somehow 'teach' ipsec to > > identify what traffic constitutes that application (note I'm not > > advocating adding l2tp code into ipsec; this could conceivably be done via > > some API between the two..). > > > > Has anyone come up with a solution for this? Does someone think this is NOT a > > problem (in which case I'd like to hear some proposed ways of dealing with > > the above; but see PS below)? From my readings of the rfc's, I don't see how > > this can be done, although ipsec certainly can handle multiple ports. You > > just can't negotiate it in IKE... > > > > jan > > > > P.S. I know of at least one vendor that solves this problem by using port=0 > > (i.e. 'all ports') and filtering traffic behind ipsec. I don't consider that > > a good solution, since the peer may not know of this filtering and needlessly > > encrypts and sends stuff that the other side is just going to toss anyway. It > > wastes CPU on both sides and wastes bandwidth. It's also a bit hard to debug > > ("We negotiated all ports... I wonder why none of my traffic is getting > > through...") > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > From owner-ipsec@lists.tislabs.com Tue Jun 27 09:05:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18659; Tue, 27 Jun 2000 09:05:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25021 Tue, 27 Jun 2000 10:12:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200006261921.MAA02694@potassium.network-alchemy.com> References: <200006261921.MAA02694@potassium.network-alchemy.com> Date: Tue, 27 Jun 2000 10:19:27 -0400 To: Dan Harkins From: Stephen Kent Subject: Re: phase 2 and ports Cc: Jan Vilhuber , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan is right. We used to have port ranges and similar features for SPD configuration in the I-D precursor to RFC 2401, but they were deleted because IKE didn't support them and nobody wanted to change the IKE spec. Note, that we have a WG on IP security policy and it is exploring ways to offer real negotiation for IPsec peers, prior to IKE exchanges. That way one need not add complexity to IKE but one can offer more sophisticated negotiation capabilities. Steve From owner-ipsec@lists.tislabs.com Tue Jun 27 10:16:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22834; Tue, 27 Jun 2000 10:15:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25396 Tue, 27 Jun 2000 11:41:04 -0400 (EDT) Message-ID: <3958CD1F.D29958DF@lmf.ericsson.se> Date: Tue, 27 Jun 2000 18:49:51 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber , Skip Booth CC: ipsec@lists.tislabs.com Subject: Re: phase 2 and ports References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > I remember in the last IETF Steven Bellovin gave a talk about a similar > > problem for SCTP (one of the signaling protocols). There the problem was > > with several IP addresses. If somebody's going to extend ID payloads, > > such extensions should cover both issues. > > > Is 'several ip-addresses' not covered by the id-payload? You can do > IPV$_ADD_RANGE, _SUBNET and simply ADDR. Does this not cover it? Is it > because either the addresses are not consecutive? Or are they not known a > priori? Can you elaborate a bit more, so I can make sure if my new payload > (which I'm already designing) will cover this? I think the issue was that you have, say, two IP addresses on two different subnets for reliability reasons. Hence the addresses are not a range or subnet, but rather a set. Perhaps they *could* be covered by some larger subnet in *some* network situations. Or covered with several SAs. But these people who would use that sort of thing were worried about performance and delays of the nxn case if n equals the redundancy number. Skip Booth wrote: >> > ports they are going to use. On a side note, it's always kind of bothered >> > me that we need 2 ID payloads. I assume this is so we can reuse the ID >> >> Isn't this because, say, L2TP client is has a wildcard port number and >> the server a fixed one? >Actually the server starts on a fixed port and then may move to a dynamic port >on its reply. Yes, that problem too exists for L2TP. I wasn't trying to say L2TP uses fixed ports, I was trying to make a point about why we had 2 ID payloads. I should have used another example than L2TP. Jari From owner-ipsec@lists.tislabs.com Tue Jun 27 10:44:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23297; Tue, 27 Jun 2000 10:44:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25549 Tue, 27 Jun 2000 12:25:08 -0400 (EDT) X-Authentication-Warning: janpc-home.cisco.com: vilhuber owned process doing -bs Date: Tue, 27 Jun 2000 09:33:15 -0700 (PDT) From: Jan Vilhuber To: "Scott G. Kelly" cc: Stephen Kent , Dan Harkins , ipsec@lists.tislabs.com Subject: Re: phase 2 and ports In-Reply-To: <3958D4CD.D139BD15@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 27 Jun 2000, Scott G. Kelly wrote: > Stephen Kent wrote: > > > > Jan is right. We used to have port ranges and similar features for > > SPD configuration in the I-D precursor to RFC 2401, but they were > > deleted because IKE didn't support them and nobody wanted to change > > the IKE spec. > > > > Note, that we have a WG on IP security policy and it is exploring > > ways to offer real negotiation for IPsec peers, prior to IKE > > exchanges. That way one need not add complexity to IKE but one can > > offer more sophisticated negotiation capabilities. > > > > Steve > > I agree that actual policy exchange might be better handled within ipsp, > but I would really like to see ike support something more comprehensive > than the current mechanism. If we wished to minimize complexity, this > could consist in simply permitting multiple ID payloads, Skip also suggested this to me. I rejected this, because I don't like the implicit semantics of the two ID payloads to begin with. Having multiples of two ID payloads just adds to the non-obvious nature of how ID payloads are used in phase 2. I'd much rather come up with a new payload. In my mind I dubbed it the selector payload, but someone else mentioned Policy Payload, which I can also live with. jan > and/or adding > some new ID payloads to facilitate ranges. I think this is a serious > shortcoming in terms of real-world requirements. > > On a related note, I think we may be getting bogged down with this > notion that we can't change ike in any way. While I think it would be > ill-advised to change ike in a fundamental way (i.e. changing one of the > existing exchanges in a way that creates interoperability and > compatibility issues), I think we should be open to extending ike when a > solid case for it exists. > > Scott > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Jun 27 10:46:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23352; Tue, 27 Jun 2000 10:46:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25498 Tue, 27 Jun 2000 12:14:49 -0400 (EDT) Message-ID: <3958D4CD.D139BD15@redcreek.com> Date: Tue, 27 Jun 2000 09:22:37 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Dan Harkins , Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: phase 2 and ports References: <200006261921.MAA02694@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Jan is right. We used to have port ranges and similar features for > SPD configuration in the I-D precursor to RFC 2401, but they were > deleted because IKE didn't support them and nobody wanted to change > the IKE spec. > > Note, that we have a WG on IP security policy and it is exploring > ways to offer real negotiation for IPsec peers, prior to IKE > exchanges. That way one need not add complexity to IKE but one can > offer more sophisticated negotiation capabilities. > > Steve I agree that actual policy exchange might be better handled within ipsp, but I would really like to see ike support something more comprehensive than the current mechanism. If we wished to minimize complexity, this could consist in simply permitting multiple ID payloads, and/or adding some new ID payloads to facilitate ranges. I think this is a serious shortcoming in terms of real-world requirements. On a related note, I think we may be getting bogged down with this notion that we can't change ike in any way. While I think it would be ill-advised to change ike in a fundamental way (i.e. changing one of the existing exchanges in a way that creates interoperability and compatibility issues), I think we should be open to extending ike when a solid case for it exists. Scott From owner-ipsec@lists.tislabs.com Tue Jun 27 14:26:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27434; Tue, 27 Jun 2000 14:25:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26322 Tue, 27 Jun 2000 15:39:21 -0400 (EDT) Message-ID: <3959050E.1FA45B91@ennovatenetworks.com> Date: Tue, 27 Jun 2000 15:48:30 -0400 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: "Scott G. Kelly" , Stephen Kent , Dan Harkins , ipsec@lists.tislabs.com, dfox@ennovatenetworks.com Subject: Re: phase 2 and ports References: Content-Type: multipart/mixed; boundary="------------EA9E71508D0DC2E09F8C1691" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------EA9E71508D0DC2E09F8C1691 Content-Type: multipart/alternative; boundary="------------4E740CB104A6E82DDA346488" --------------4E740CB104A6E82DDA346488 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A new Policy Payload could also solve the problem I currently have, which occurs when dealing with more than one IP Address Realm. Say for instance, customer A has his own private IP network distinctly separate from customer B's network. Customer A and B each have a "virtual router" on the VPN switch. In this case, one needs to differentiate, in IKE, which IP network an SA pertains to. Look at this example: 10.1/16 ---------+ +------- 10.2/16 network A | | network B +-------+ +-------+ |VPN |--Global IP Network--|VPN | |Switch | |Switch | +-------+ +-------+ | | 10.1/16 ----------+ +------- 10.2/16 network B network A In IKE, in order to set up an SA for packets going from 10.1/16 to 10.2/16 in network A, you need to specify for the SA: network A source 10.1/16 destination 10.1/16 Currently, there is no way to specify this kind of topology in IKE. Now this brings up the issue that more and more complex policies may be envisioned. The Policy Payload could be extensibly defined to allow for this. Another global solution that I have in mind is to have all policies configured out-of-band, and simply have IKE include a Policy Identifier. Jan Vilhuber wrote: > On Tue, 27 Jun 2000, Scott G. Kelly wrote: > > Stephen Kent wrote: > > > > > > Jan is right. We used to have port ranges and similar features for > > > SPD configuration in the I-D precursor to RFC 2401, but they were > > > deleted because IKE didn't support them and nobody wanted to change > > > the IKE spec. > > > > > > Note, that we have a WG on IP security policy and it is exploring > > > ways to offer real negotiation for IPsec peers, prior to IKE > > > exchanges. That way one need not add complexity to IKE but one can > > > offer more sophisticated negotiation capabilities. > > > > > > Steve > > > > I agree that actual policy exchange might be better handled within ipsp, > > but I would really like to see ike support something more comprehensive > > than the current mechanism. If we wished to minimize complexity, this > > could consist in simply permitting multiple ID payloads, > > Skip also suggested this to me. I rejected this, because I don't like the > implicit semantics of the two ID payloads to begin with. Having multiples of > two ID payloads just adds to the non-obvious nature of how ID payloads are > used in phase 2. > > I'd much rather come up with a new payload. In my mind I dubbed it the > selector payload, but someone else mentioned Policy Payload, which I can also > live with. > > jan > > > and/or adding > > some new ID payloads to facilitate ranges. I think this is a serious > > shortcoming in terms of real-world requirements. > > > > On a related note, I think we may be getting bogged down with this > > notion that we can't change ike in any way. While I think it would be > > ill-advised to change ike in a fundamental way (i.e. changing one of the > > existing exchanges in a way that creates interoperability and > > compatibility issues), I think we should be open to extending ike when a > > solid case for it exists. > > > > Scott > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 --------------4E740CB104A6E82DDA346488 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit A new Policy Payload could also solve the problem I currently have, which occurs when dealing with more than one IP Address Realm.

Say for instance, customer A has his own private IP network distinctly separate from customer B's network. Customer A and B each have a "virtual router" on the VPN switch. In this case, one needs to differentiate, in IKE, which IP network an SA pertains to.

Look at this example:

10.1/16 ---------+                             +------- 10.2/16
network A         |                             |        network B
               +-------+                     +-------+
               |VPN    |--Global IP Network--|VPN    |
               |Switch |                     |Switch |
               +-------+                     +-------+
                  |                             |
10.1/16 ----------+                             +------- 10.2/16
network B                                                network A

In IKE, in order to set up an SA for packets going from 10.1/16 to 10.2/16 in network A, you need to specify for the SA:
network A
source 10.1/16
destination 10.1/16

Currently, there is no way to specify this kind of topology in IKE.

Now this brings up the issue that more and more complex policies may be envisioned. The Policy Payload could be extensibly defined to allow for this.

Another global solution that I have in mind is to have all policies configured out-of-band, and simply have IKE include a Policy Identifier.

Jan Vilhuber wrote:

On Tue, 27 Jun 2000, Scott G. Kelly wrote:
> Stephen Kent wrote:
> >
> > Jan is right. We used to have port ranges and similar features for
> > SPD configuration in the I-D precursor to RFC 2401, but they were
> > deleted because IKE didn't support them and nobody wanted to change
> > the IKE spec.
> >
> > Note, that we have a WG on IP security policy and it is exploring
> > ways to offer real negotiation for IPsec peers, prior to IKE
> > exchanges. That way one need not add complexity to IKE but one can
> > offer more sophisticated negotiation capabilities.
> >
> > Steve
>
> I agree that actual policy exchange might be better handled within ipsp,
> but I would really like to see ike support something more comprehensive
> than the current mechanism. If we wished to minimize complexity, this
> could consist in simply permitting multiple ID payloads,
Skip also suggested this to me. I rejected this, because I don't like the
implicit semantics of the two ID payloads to begin with. Having multiples of
two ID payloads just adds to the non-obvious nature of how ID payloads are
used in phase 2.
I'd much rather come up with a new payload. In my mind I dubbed it the
selector payload, but someone else mentioned Policy Payload, which I can also
live with.
jan
> and/or adding
> some new ID payloads to facilitate ranges. I think this is a serious
> shortcoming in terms of real-world requirements.
>
> On a related note, I think we may be getting bogged down with this
> notion that we can't change ike in any way. While I think it would be
> ill-advised to change ike in a fundamental way (i.e. changing one of the
> existing exchanges in a way that creates interoperability and
> compatibility issues), I think we should be open to extending ike when a
> solid case for it exists.
>
> Scott
>
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847

--------------4E740CB104A6E82DDA346488-- --------------EA9E71508D0DC2E09F8C1691 Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;work:978-206-0405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Principal Software Engineer fn:Daniel Fox end:vcard --------------EA9E71508D0DC2E09F8C1691-- From owner-ipsec@lists.tislabs.com Tue Jun 27 14:40:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27620; Tue, 27 Jun 2000 14:40:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26558 Tue, 27 Jun 2000 16:18:51 -0400 (EDT) Message-Id: <200006272027.e5RKR7J102737@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: "Scott G. Kelly" , Stephen Kent , Dan Harkins , ipsec@lists.tislabs.com Subject: Re: phase 2 and ports In-reply-to: Your message of "Tue, 27 Jun 2000 09:33:15 PDT." Reply-to: sommerfeld@East.Sun.COM Date: Tue, 27 Jun 2000 16:27:07 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A "selector payload" sounds more correct than a "policy payload" -- the responder should know why the initiator decided it needed a new SA, so the SA's can be scoped appropriately. - Bill From owner-ipsec@lists.tislabs.com Tue Jun 27 15:09:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28211; Tue, 27 Jun 2000 15:09:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26592 Tue, 27 Jun 2000 16:38:56 -0400 (EDT) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Jan Vilhuber'" , "Andrew Krywaniuk" Cc: Subject: RE: phase 2 and ports Date: Tue, 27 Jun 2000 16:42:54 -0400 Message-Id: <005c01bfe078$462a5520$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jan, > > In mind, this is still the theoretically "correct" way of > solving the > > problem. The way to avoid black holes is to use a firewall > policy sharing > > protocol. > > > Well.. No. It's not 'correct'. It may be 'A' way of solving > this problem, if > we all agree that selectors be negotiated outside of phase > II, which I'm not > sure I would agree to. Afterall, isn't that one of the > functions of phase II? Well, obviously there's no single literally *correct* way to do anything. (I did say "in my mind" and put "correct" in quotes...) What we have now is based on engineering decisions -- some modularity violations to avoid overdesign and some arbitrary decisions to resolve deadlock. (As Steve K said, the reason we negotiate ports in phase 2 is to avoid the need for a communications protocol between the IKE daemon and the firewall if they are not co-located.) However, if you accept the model where we draw an abstract line between the authentication and authorization packages (I'm lumping firewalling in with authorization here), then an external (to IKE) exchange of policy information is the most desirable. The use of a policy payload isn't such a bad idea, since it appears that ISAKMP would be merely functioning as transport (opening up giant can of worms based on same argument re. XAuth). Negotiation isn't really the best word though (as one of the presenters at the last IPSP meeting pointed out, it is better to simply take the union of the two security policies instead of attempting to negotiate a common ground). What concerns me is that if we created a policy payload, we would also have to define an encoding scheme, and to make the payload meaningful we would have to create such a behemoth that we would be duplicating a large percentage of the work that IPSP is already doing. Of course, if you already have something written up, then publish it and feel free to prove me wrong (at which point we can dispense with firewalls altogether). Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Monday, June 26, 2000 3:45 PM > To: Andrew Krywaniuk > Cc: ipsec@lists.tislabs.com > Subject: RE: phase 2 and ports > > > On Mon, 26 Jun 2000, Andrew Krywaniuk wrote: > > > P.S. I know of at least one vendor that solves this problem > > > by using port=0 > > > (i.e. 'all ports') and filtering traffic behind ipsec. I > > > don't consider that > > > a good solution, since the peer may not know of this > > > filtering and needlessly > > > encrypts and sends stuff that the other side is just going to > > > toss anyway. It > > > wastes CPU on both sides and wastes bandwidth. It's also a > > > bit hard to debug > > > ("We negotiated all ports... I wonder why none of my traffic > > > is getting > > > through...") > > > > In mind, this is still the theoretically "correct" way of > solving the > > problem. The way to avoid black holes is to use a firewall > policy sharing > > protocol. > > > Well.. No. It's not 'correct'. It may be 'A' way of solving > this problem, if > we all agree that selectors be negotiated outside of phase > II, which I'm not > sure I would agree to. Afterall, isn't that one of the > functions of phase II? > > It certainly works, and if you can somehow communicate your > firewall policy > to your peer, then you solve the black-hole problem, but then > we should > consider removing the ID payloads from phase II altogether, > to simplify it, > and require that an external protocol be used to negotiate > the selectors... > > I'd much rather define a payload in IKE phase II which gives > us a richer way > to specify our selectors. I have something written up, which > needs a bit more > polishing, which I'd be happy to throw out as a strawman. > That way, the > 'firewall policy sharing' could be done IN phase II. > > jan > > > > > Andrew > > -------------------------------------- > > Beauty with out truth is insubstantial. > > Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Tue Jun 27 17:25:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA29985; Tue, 27 Jun 2000 17:25:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26930 Tue, 27 Jun 2000 19:09:26 -0400 (EDT) Message-ID: <39593614.D163D670@cisco.com> Date: Wed, 28 Jun 2000 01:17:40 +0200 From: Frederic Detienne Reply-To: fd@cisco.com Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: ipsec@lists.tislabs.com Subject: Re: phase 2 and ports References: <200006240131.e5O1VJJ109685@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, typically, those applications have one "static" port number (when they are RFC compliant). E.g. FTP data connection _should_ have one side connected to port 20. This solves most (common) issues. Beyond that, up to protocol designers to take care about what they do if security is a concern. I admit, not everything will behave like this but port negociation is broken in essence: what to do with a fragmented packet for instance ? The port numbers may not appear anymore; how do selectors match then ? Do we have to keep track of the IP packet-id in case we see the next fragments ? Then what if the encryption process is load balanced across devices ? (and so on with more and more problems). There is no complete solution to this. It would be better to fix a range of validity on what IKE can negociate and let network or protocol designers deal with it. My opinion is that we should not make IKE more complex than it is; this is a pandora box which will lead to subtle mis-configurations and problems. fred Jan wrote: > Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to > name a few). Other protocols a priori use more than one port (can't think of > any examples, but I don't see why this couldn't be the case), yet the ID > payload has a field for a single port only. There's no way in IKE to > negotiate something like src-ip=A, src-port=8-10, dst-IP=B, dst-port=8-10 (an > example only). > From owner-ipsec@lists.tislabs.com Tue Jun 27 19:43:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04405; Tue, 27 Jun 2000 19:43:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27254 Tue, 27 Jun 2000 21:06:59 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 27 Jun 2000 19:14:51 -0600 From: "Hilarie Orman" To: , Cc: , Subject: Re: phase 2 and ports Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_DC84B185.55345DC0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_DC84B185.55345DC0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable It should be OK to use an IPSEC SA for a port other than the one originally negotiated. It's the sender's option, eh? I think this is = less likely to cause trouble than to have relative naming (e.g. the port that Harry used when Sarah had received twice as many bytes as Spot sent Harry on port 3000). How about putting the naming scheme and selection of credentials into a security policy discovery protocol that can act as the control channel for setting up the IKE negotiations? That channel might have policy for matching names and namespaces, and perhaps could negotiate "IKE-names" that could be used in the IKE negotiations. Hilarie >>> Bill Sommerfeld 06/23/00 07:31PM >>> > I was wondering if anyone had a good solution to this problem, or if = people > are interested in one in general. Maybe people don't think this is a > problem? This is a real problem. > Here's the problem: Some protocols float ports (example l2tp, ftp, = h.323, to > name a few). Other protocols a priori use more than one port (can't = think of > any examples, but I don't see why this couldn't be the case), yet the ID > payload has a field for a single port only. There's no way in IKE to > negotiate something like src-ip=3DA, src-port=3D8-10, dst-IP=3DB, = dst-port=3D8-10 (an > example only). >=20 > As far as I can tell, you'd have to negotiate one SA per port, i.e. 3 = SA's in > the above example (times 2, since we're doing bidirectional). Multiple SA's isn't necessarily a problem -- from a crypto-paranoia standpoint, it's better to use different keys for different things. To reuse ftp as an example, the files being transferred and the control channel may want very different protection. (e.g., if you're uploading stuff to an anonymous FTP site you may only need integrity protection on the ftp-data connection but want to keep the passwords, etc., on the control connection secret). The tricky part comes with knowing which policy to apply to the floating port.. [aside: If there's a perception that the multiple phase-2 exchanges needed are a performance problem then maybe I should go resurrect my inline keying draft..] > b) an application-ID would be usefull for applications that do NOT know = a > priori what ports to use (l2tp for example). I could see using the = tuple > protocol:port as an application identifier, and somehow 'teach' ipsec = to > identify what traffic constitutes that application. warning: This opens a naming can-of-worms. With some application assistance (i.e., ftpd telling the stack "I want the data connection I'm initiating to connect back to the same principal/entity which initiated the control connection i accepted") this might not be so bad. I'm increasingly coming to think that we need to start specifying the handling of principals and identities within IPSEC and IKE a bit more closely. for what it's worth, I like the general properties of the model presented in [1] quite a bit, but fitting that into the existing IKE framework will be messy. > P.S. I know of at least one vendor that solves this problem by using = port=3D0 > (i.e. 'all ports') and filtering traffic behind ipsec.=20 It's their right to do this, but it's pretty unfriendly. - Bill [1] Authentication in Distributed Systems: Theory and Practice Butler Lampson, Martin Abadi, Michael Burrows, Edward Wobber =20 http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-083= .html --=_DC84B185.55345DC0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

It should be OK to use an IPSEC SA for a port other than the = one

originally negotiated. It's the sender's option, eh? I = think=20 this is less

likely to cause trouble than to have relative naming (e.g. the = port

that Harry used when Sarah had received twice as many bytes

as Spot sent Harry on port 3000).

How about putting the naming scheme and selection of credentials

into a security policy discovery protocol that can act as the

control channel for setting up the IKE negotiations? = That

channel might have policy for matching names and namespaces,

and perhaps could negotiate "IKE-names" that could be used

in the IKE negotiations.

Hilarie

>>> Bill Sommerfeld <sommerfeld@East.Sun.COM> = 06/23/00=20 07:31PM >>>

> I was wondering if anyone had a good = solution=20 to this problem, or if people
> are interested in one in general. = Maybe=20 people don't think this is a
> problem?

This is a real=20 problem.

> Here's the problem: Some protocols float ports = (example=20 l2tp, ftp, h.323, to
> name a few). Other protocols a priori use = more than=20 one port (can't think of
> any examples, but I don't see why this = couldn't=20 be the case), yet the ID
> payload has a field for a single port = only.=20 There's no way in IKE to
> negotiate something like src-ip=3DA,=20 src-port=3D8-10, dst-IP=3DB, dst-port=3D8-10 (an
> example only).
= >=20
> As far as I can tell, you'd have to negotiate one SA per port, = i.e. 3=20 SA's in
> the above example (times 2, since we're doing=20 bidirectional).

Multiple SA's isn't necessarily a problem -- from = a=20 crypto-paranoia
standpoint, it's better to use different keys for = different=20 things.
To reuse ftp as an example, the files being transferred and=20 the
control channel may want very different protection. (e.g., = if=20 you're
uploading stuff to an anonymous FTP site you may only need=20 integrity
protection on the ftp-data connection but want to keep the=20 passwords,
etc., on the control connection secret).

The tricky = part=20 comes with knowing which policy to apply to the
floating=20 port..

[aside: If there's a perception that the multiple phase-2=20 exchanges
needed are a performance problem then maybe I should go = resurrect=20 my
inline keying draft..]

> b) an application-ID would be = usefull=20 for applications that do NOT know a
>    priori what = ports=20 to use (l2tp for example). I could see using the tuple
>  &= nbsp;=20 protocol:port as an application identifier, and somehow 'teach' ipsec=20 to
>    identify what traffic constitutes that=20 application.

warning: This opens a naming can-of-worms.

With = some=20 application assistance (i.e., ftpd telling the stack "I want
the = data=20 connection I'm initiating to connect back to the same
principal/entity = which=20 initiated the control connection i accepted")
this might not be so=20 bad.

I'm increasingly coming to think that we need to start = specifying=20 the
handling of principals and identities within IPSEC and IKE a bit=20 more
closely. for what it's worth, I like the general properties = of=20 the
model presented in [1] quite a bit, but fitting that into the=20 existing
IKE framework will be messy.

> P.S. I know of at = least one=20 vendor that solves this problem by using port=3D0
> (i.e. 'all = ports') and=20 filtering traffic behind ipsec.

It's their right to do this, but = it's=20 pretty unfriendly.

       =20             - Bill

[1]= =20 Authentication in Distributed Systems: Theory and Practice
Butler = Lampson,=20 Martin Abadi, Michael Burrows, Edward Wobber
http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstr= acts/src-rr-083.html

--=_DC84B185.55345DC0-- From owner-ipsec@lists.tislabs.com Tue Jun 27 19:51:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04639; Tue, 27 Jun 2000 19:51:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27303 Tue, 27 Jun 2000 21:40:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3958D4CD.D139BD15@redcreek.com> References: <200006261921.MAA02694@potassium.network-alchemy.com> <3958D4CD.D139BD15@redcreek.com> Date: Tue, 27 Jun 2000 19:46:59 -0400 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: phase 2 and ports Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, I agree that we need appropriate payload types for IKE. The IPSP work will not fix that problem. Sorry to have not been clear in my reply. Steve From owner-ipsec@lists.tislabs.com Tue Jun 27 20:17:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA05933; Tue, 27 Jun 2000 20:17:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA27356 Tue, 27 Jun 2000 22:00:34 -0400 (EDT) Message-Id: <200006280208.CAA10567@orchard.arlington.ma.us> To: "Hilarie Orman" cc: sommerfeld@East.Sun.COM, vilhuber@cisco.com, ipsec@lists.tislabs.com, ipsec-policy@vpnc.org Subject: Re: phase 2 and ports In-Reply-To: Message from "Hilarie Orman" of "Tue, 27 Jun 2000 19:14:51 MDT." Reply-to: sommerfeld@orchard.arlington.ma.us Date: Tue, 27 Jun 2000 22:08:37 -0400 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It should be OK to use an IPSEC SA for a port other than the one > originally negotiated. It's the sender's option, eh? Huh? rfc2401 says otherwise -- ports can be specified in inbound as well as outbound policy. Folks involved with NRL ipsec implementation have told me that inbound enforcement of unique sa's per connection was always on their TODO list.. - Bill From owner-ipsec@lists.tislabs.com Wed Jun 28 03:34:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26191; Wed, 28 Jun 2000 03:34:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA28356 Wed, 28 Jun 2000 04:43:38 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E375BD@eseis06nok> To: ipsec@lists.tislabs.com Subject: Informational exchanges Date: Wed, 28 Jun 2000 11:51:00 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are the Status Type like CONNECTED or INITIAL_CONTACT sent as Informational Exchanges always? I thought so but I'm testing against an implementation that uses them in a Quick Mode exchange putting the HASH and the NOTIFY payloads the same way as it should be in an Informational exchange. Does this make sense? And if it does are there other implementations doing this like this or the normal is to have it as an Informational exchange? If both can happen then I'll have to put a flag to support both, otherwise I'll just use the common one. Thanks! Toni From owner-ipsec@lists.tislabs.com Wed Jun 28 07:59:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04637; Wed, 28 Jun 2000 07:59:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29186 Wed, 28 Jun 2000 09:05:00 -0400 (EDT) Message-ID: <53D69AD06EFAD311842300A0C99B4F0825E52D@ticsmtp2.innovation.siemens.ca> From: Claudio Lordello To: Daniel Fox , Jan Vilhuber Cc: "Scott G. Kelly" , Stephen Kent , Dan Harkins , ipsec@lists.tislabs.com Subject: RE: phase 2 and ports Date: Wed, 28 Jun 2000 09:10:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I also have this very same problem. I have posted some messages regarding this issue in the past but it did not trigger a discussion (see http://www.vpnc.org/ietf-ipsec/mail-archive/msg00555.html ). I was considering suggesting additions to the ID payload itself to include a "virtual router" identifier to solve this issue but I agree that a Policy Payload (or Selector Payload) could also solve it. The question is how to identify a virtual router in a global way. That can be easy in a private environment but more complicated in an open one. One suggestion that I would have is to use a global VPN identifier as defined in RFC 2685 (http://www.ietf.org/rfc/rfc2685.txt?number=2685). Claudio Lordello. Siemens. > -----Original Message----- > From: Daniel Fox [SMTP:dfox@ennovatenetworks.com] > Sent: Tuesday, June 27, 2000 3:49 PM > To: Jan Vilhuber > Cc: Scott G. Kelly; Stephen Kent; Dan Harkins; ipsec@lists.tislabs.com; > dfox@ennovatenetworks.com > Subject: Re: phase 2 and ports > > A new Policy Payload could also solve the problem I currently have, which > occurs when dealing with more than one IP Address Realm. > > Say for instance, customer A has his own private IP network distinctly > separate from customer B's network. Customer A and B each have a "virtual > router" on the VPN switch. In this case, one needs to differentiate, in > IKE, which IP network an SA pertains to. > > Look at this example: > > 10.1/16 ---------+ +------- 10.2/16 > network A | | network B > +-------+ +-------+ > |VPN |--Global IP Network--|VPN | > |Switch | |Switch | > +-------+ +-------+ > | | > 10.1/16 ----------+ +------- 10.2/16 > network B network A > > In IKE, in order to set up an SA for packets going from 10.1/16 to 10.2/16 > in network A, you need to specify for the SA: > network A > source 10.1/16 > destination 10.1/16 > > Currently, there is no way to specify this kind of topology in IKE. > > Now this brings up the issue that more and more complex policies may be > envisioned. The Policy Payload could be extensibly defined to allow for > this. > > Another global solution that I have in mind is to have all policies > configured out-of-band, and simply have IKE include a Policy Identifier. > > Jan Vilhuber wrote: > > On Tue, 27 Jun 2000, Scott G. Kelly wrote: > > Stephen Kent wrote: > > > > > > Jan is right. We used to have port ranges and similar features > for > > > SPD configuration in the I-D precursor to RFC 2401, but they > were > > > deleted because IKE didn't support them and nobody wanted to > change > > > the IKE spec. > > > > > > Note, that we have a WG on IP security policy and it is > exploring > > > ways to offer real negotiation for IPsec peers, prior to IKE > > > exchanges. That way one need not add complexity to IKE but one > can > > > offer more sophisticated negotiation capabilities. > > > > > > Steve > > > > I agree that actual policy exchange might be better handled within > ipsp, > > but I would really like to see ike support something more > comprehensive > > than the current mechanism. If we wished to minimize complexity, > this > > could consist in simply permitting multiple ID payloads, > > Skip also suggested this to me. I rejected this, because I don't > like the > implicit semantics of the two ID payloads to begin with. Having > multiples of > two ID payloads just adds to the non-obvious nature of how ID > payloads are > used in phase 2. > > I'd much rather come up with a new payload. In my mind I dubbed it > the > selector payload, but someone else mentioned Policy Payload, which I > can also > live with. > > jan > > > and/or adding > > some new ID payloads to facilitate ranges. I think this is a > serious > > shortcoming in terms of real-world requirements. > > > > On a related note, I think we may be getting bogged down with this > > > notion that we can't change ike in any way. While I think it would > be > > ill-advised to change ike in a fundamental way (i.e. changing one > of the > > existing exchanges in a way that creates interoperability and > > compatibility issues), I think we should be open to extending ike > when a > > solid case for it exists. > > > > Scott > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose (408) > 527-0847 > << File: Card for Daniel Fox >> From owner-ipsec@lists.tislabs.com Wed Jun 28 09:11:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09571; Wed, 28 Jun 2000 09:11:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29624 Wed, 28 Jun 2000 10:47:05 -0400 (EDT) Message-ID: <395A1209.CD52AC40@ennovatenetworks.com> Date: Wed, 28 Jun 2000 10:56:09 -0400 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Claudio Lordello CC: Jan Vilhuber , "Scott G. Kelly" , Stephen Kent , Dan Harkins , ipsec@lists.tislabs.com, dfox@ennovatenetworks.com Subject: Re: phase 2 and ports References: <53D69AD06EFAD311842300A0C99B4F0825E52D@ticsmtp2.innovation.siemens.ca> Content-Type: multipart/mixed; boundary="------------A58A165115CA92CA8FCFE6AF" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------A58A165115CA92CA8FCFE6AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Using the RFC 2685 may be workable, I'll look at it more closely. Actually, I broached this subject months ago, with some suggesting that we use the Secrecy Level. But if we are opening up a Selector Payload, then perhaps we can put it there. Claudio Lordello wrote: > I also have this very same problem. I have posted some messages regarding > this issue in the past but it did not trigger a discussion (see > http://www.vpnc.org/ietf-ipsec/mail-archive/msg00555.html ). > > I was considering suggesting additions to the ID payload itself to include a > "virtual router" identifier to solve this issue but I agree that a Policy > Payload (or Selector Payload) could also solve it. > > The question is how to identify a virtual router in a global way. That can > be easy in a private environment but more complicated in an open one. One > suggestion that I would have is to use a global VPN identifier as defined in > RFC 2685 (http://www.ietf.org/rfc/rfc2685.txt?number=2685). > > Claudio Lordello. > Siemens. > > > -----Original Message----- > > From: Daniel Fox [SMTP:dfox@ennovatenetworks.com] > > Sent: Tuesday, June 27, 2000 3:49 PM > > To: Jan Vilhuber > > Cc: Scott G. Kelly; Stephen Kent; Dan Harkins; ipsec@lists.tislabs.com; > > dfox@ennovatenetworks.com > > Subject: Re: phase 2 and ports > > > > A new Policy Payload could also solve the problem I currently have, which > > occurs when dealing with more than one IP Address Realm. > > > > Say for instance, customer A has his own private IP network distinctly > > separate from customer B's network. Customer A and B each have a "virtual > > router" on the VPN switch. In this case, one needs to differentiate, in > > IKE, which IP network an SA pertains to. > > > > Look at this example: > > > > 10.1/16 ---------+ +------- 10.2/16 > > network A | | network B > > +-------+ +-------+ > > |VPN |--Global IP Network--|VPN | > > |Switch | |Switch | > > +-------+ +-------+ > > | | > > 10.1/16 ----------+ +------- 10.2/16 > > network B network A > > > > In IKE, in order to set up an SA for packets going from 10.1/16 to 10.2/16 > > in network A, you need to specify for the SA: > > network A > > source 10.1/16 > > destination 10.1/16 > > > > Currently, there is no way to specify this kind of topology in IKE. > > > > Now this brings up the issue that more and more complex policies may be > > envisioned. The Policy Payload could be extensibly defined to allow for > > this. > > > > Another global solution that I have in mind is to have all policies > > configured out-of-band, and simply have IKE include a Policy Identifier. > > > > Jan Vilhuber wrote: > > > > On Tue, 27 Jun 2000, Scott G. Kelly wrote: > > > Stephen Kent wrote: > > > > > > > > Jan is right. We used to have port ranges and similar features > > for > > > > SPD configuration in the I-D precursor to RFC 2401, but they > > were > > > > deleted because IKE didn't support them and nobody wanted to > > change > > > > the IKE spec. > > > > > > > > Note, that we have a WG on IP security policy and it is > > exploring > > > > ways to offer real negotiation for IPsec peers, prior to IKE > > > > exchanges. That way one need not add complexity to IKE but one > > can > > > > offer more sophisticated negotiation capabilities. > > > > > > > > Steve > > > > > > I agree that actual policy exchange might be better handled within > > ipsp, > > > but I would really like to see ike support something more > > comprehensive > > > than the current mechanism. If we wished to minimize complexity, > > this > > > could consist in simply permitting multiple ID payloads, > > > > Skip also suggested this to me. I rejected this, because I don't > > like the > > implicit semantics of the two ID payloads to begin with. Having > > multiples of > > two ID payloads just adds to the non-obvious nature of how ID > > payloads are > > used in phase 2. > > > > I'd much rather come up with a new payload. In my mind I dubbed it > > the > > selector payload, but someone else mentioned Policy Payload, which I > > can also > > live with. > > > > jan > > > > > and/or adding > > > some new ID payloads to facilitate ranges. I think this is a > > serious > > > shortcoming in terms of real-world requirements. > > > > > > On a related note, I think we may be getting bogged down with this > > > > > notion that we can't change ike in any way. While I think it would > > be > > > ill-advised to change ike in a fundamental way (i.e. changing one > > of the > > > existing exchanges in a way that creates interoperability and > > > compatibility issues), I think we should be open to extending ike > > when a > > > solid case for it exists. > > > > > > Scott > > > > > > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose (408) > > 527-0847 > > << File: Card for Daniel Fox >> --------------A58A165115CA92CA8FCFE6AF Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;work:978-206-0405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Principal Software Engineer fn:Daniel Fox end:vcard --------------A58A165115CA92CA8FCFE6AF-- From owner-ipsec@lists.tislabs.com Thu Jun 29 05:50:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10296; Thu, 29 Jun 2000 05:50:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03178 Thu, 29 Jun 2000 06:57:56 -0400 (EDT) Message-Id: <200006291047.GAA25272@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-vlado-ipsec-keep-alive-00.txt Date: Thu, 29 Jun 2000 06:47:06 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Security Association and Key Management Protocol (ISAKMP) Keep-Alive Message exchange Author(s) : V. Zafirov Filename : draft-vlado-ipsec-keep-alive-00.txt Pages : 7 Date : 28-Jun-00 This memo describes a protocol utilizing ISAKMP protocol necessary for checking status of specific Ipsec tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vlado-ipsec-keep-alive-00.txt Internet-Drafts are also 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-vlado-ipsec-keep-alive-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vlado-ipsec-keep-alive-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <20000628112305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vlado-ipsec-keep-alive-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-vlado-ipsec-keep-alive-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000628112305.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jun 29 12:20:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27727; Thu, 29 Jun 2000 12:20:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05128 Thu, 29 Jun 2000 13:34:09 -0400 (EDT) Message-ID: <395B56E8.FD6EA558@radware.com> Date: Thu, 29 Jun 2000 10:02:16 -0400 From: Vlado Zafirov X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stephane Beaulieu CC: ipsec@lists.tislabs.com Subject: Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt References: <200006291047.GAA25272@ietf.org> <053d01bfe1d0$a775ddf0$cbd62ca1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Stephane, Well that's my first internet-draft I ever published so please excuse me for any mistakes I made. I meant to make very simple, low-bandwidth and easy to implement exchange. I read very fast the proposal draft that you was so kind to send me. It' very very good. However I believe too complicated and needs a lot of work to be implemented and it's pretty bandwidth intesive. About comments: 1. Yes, it's not a problem. I will make that change and resubmit the draft. However when Client dies it's just simple mater of reconnecting. Usually problem is when Secure Gateway loose connection because it's should be restarted or this connection dropped manually. 2. I didn't thought of that and I was not aware of that practice. Thank you so much for the feedback. This will be changed too. Stephane Beaulieu wrote: > Hi Vlado, > > I'm not sure if you were aware of it, but there is another Internet-Draft > whose goal it is to provide the same functionality. See > http://www.vpnc.org/draft-ietf-ipsec-heartbeats > > It has received quite a bit of feedback, and I think that most people are > pretty satisfied with it. > > Other comments: > 1- Is this protocol for Gate-Gate only? If so why? A Client to Gate > scenario would be just as beneficial. > > 2 - You can't just pick Exchange #6 (no comments from the peanut gallery > please :). That's in the reserved range and can only be assigned by IANA. > You have to pick a number from the Private Use range. Once the draft > becomes an RFC, then a new number will be assigned from the Reserved Range. -- Vlado Zafirov RADWare, INC Technical Support Engineer Tel: (202) 625-1505 Fax: (202) 625-1506 Confidentiality Note: This e-mail, and any attachment to it, contains privileged and confidential information intended only for the use of the individual(s) or entity named in the e-mail. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that reading it is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. From owner-ipsec@lists.tislabs.com Thu Jun 29 13:17:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28561; Thu, 29 Jun 2000 13:17:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05359 Thu, 29 Jun 2000 15:04:17 -0400 (EDT) Message-ID: <006e01bfe1fe$2937aa80$cbd62ca1@cisco.com> From: "Stephane Beaulieu" To: "Scott G. Kelly" , "Vlado Zafirov" Cc: References: <200006291047.GAA25272@ietf.org> <053d01bfe1d0$a775ddf0$cbd62ca1@cisco.com> <395B56E8.FD6EA558@radware.com> <395B9C80.5EE3639C@redcreek.com> Subject: Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt Date: Thu, 29 Jun 2000 15:13:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, then I stand corrected. I was only trying to point out to Vlado that there was another draft in progress. I don't recall Vlado ever posting comments about the other draft, therefore I wasn't sure he knew of its existance. I'd rather see comments on the existing draft, rather than having 2 drafts trying to solve the same problem. This would surely help achieve interoperability a lot sooner. > Comments below - > > Vlado Zafirov wrote: > > > > Hi Stephane, > > Well that's my first internet-draft I ever published so please excuse me > > for any mistakes I made. > > > > I meant to make very simple, low-bandwidth and easy to implement exchange. > > > > I read very fast the proposal draft that you was so kind to send me. It' very > > very good. However I believe too complicated and needs a lot of work > > to be implemented and it's pretty bandwidth intesive. > > > > About comments: > > 1. Yes, it's not a problem. I will make that change and resubmit the draft. > > However when Client dies it's just simple mater of reconnecting. Usually > > problem is when Secure Gateway loose connection because it's should be > > restarted or this connection dropped manually. > > > > 2. I didn't thought of that and I was not aware of that practice. Thank you > > so much for the feedback. This will be changed too. > > > > Stephane Beaulieu wrote: > > > > > Hi Vlado, > > > > > > I'm not sure if you were aware of it, but there is another Internet-Draft > > > whose goal it is to provide the same functionality. See > > > http://www.vpnc.org/draft-ietf-ipsec-heartbeats > > > > > > It has received quite a bit of feedback, and I think that most people are > > > pretty satisfied with it. > > This is absolute nonsense. Take a straw poll right now. > > > > All in all, I think the rough consensus was that a much simpler > mechanism would suffice. > > Scott > > From owner-ipsec@lists.tislabs.com Thu Jun 29 13:18:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28582; Thu, 29 Jun 2000 13:18:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05302 Thu, 29 Jun 2000 14:51:27 -0400 (EDT) Message-ID: <395B9C80.5EE3639C@redcreek.com> Date: Thu, 29 Jun 2000 11:59:12 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Vlado Zafirov CC: Stephane Beaulieu , ipsec@lists.tislabs.com Subject: Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt References: <200006291047.GAA25272@ietf.org> <053d01bfe1d0$a775ddf0$cbd62ca1@cisco.com> <395B56E8.FD6EA558@radware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Comments below - Vlado Zafirov wrote: > > Hi Stephane, > Well that's my first internet-draft I ever published so please excuse me > for any mistakes I made. > > I meant to make very simple, low-bandwidth and easy to implement exchange. > > I read very fast the proposal draft that you was so kind to send me. It' very > very good. However I believe too complicated and needs a lot of work > to be implemented and it's pretty bandwidth intesive. > > About comments: > 1. Yes, it's not a problem. I will make that change and resubmit the draft. > However when Client dies it's just simple mater of reconnecting. Usually > problem is when Secure Gateway loose connection because it's should be > restarted or this connection dropped manually. > > 2. I didn't thought of that and I was not aware of that practice. Thank you > so much for the feedback. This will be changed too. > > Stephane Beaulieu wrote: > > > Hi Vlado, > > > > I'm not sure if you were aware of it, but there is another Internet-Draft > > whose goal it is to provide the same functionality. See > > http://www.vpnc.org/draft-ietf-ipsec-heartbeats > > > > It has received quite a bit of feedback, and I think that most people are > > pretty satisfied with it. This is absolute nonsense. Take a straw poll right now. All in all, I think the rough consensus was that a much simpler mechanism would suffice. Scott From owner-ipsec@lists.tislabs.com Thu Jun 29 13:29:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28791; Thu, 29 Jun 2000 13:29:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05392 Thu, 29 Jun 2000 15:14:15 -0400 (EDT) Message-ID: <395BA09F.BEBAB4A4@radware.com> Date: Thu, 29 Jun 2000 15:16:47 -0400 From: Vlado Organization: RADware.com X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en,bg MIME-Version: 1.0 To: "Scott G. Kelly" CC: Stephane Beaulieu , ipsec@lists.tislabs.com Subject: Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt References: <200006291047.GAA25272@ietf.org> <053d01bfe1d0$a775ddf0$cbd62ca1@cisco.com> <395B56E8.FD6EA558@radware.com> <395B9C80.5EE3639C@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, I don't thnk so. I think this simpler alogirthm is doing the same job with less bandwith, faster processing AND EASY implementation. There is some things to be added 1. Negotiation (this is only for backward compability) - This can easy. The software can have option - keep-alive on,off,auto. In auto mode initiator sends keep-alive packets, if he receives ISAKMP Info message UNSUPPORTED-EXCHANGE-TYPE then he knows the other end doesn't support that exchange. 2. This can be further updated with rule: use keep-alive when there is no traffic for that SA for certain amount of time, default equal to the keep-alive time. "Scott G. Kelly" wrote: > Comments below - > > Vlado Zafirov wrote: > > > > Hi Stephane, > > Well that's my first internet-draft I ever published so please excuse me > > for any mistakes I made. > > > > I meant to make very simple, low-bandwidth and easy to implement exchange. > > > > I read very fast the proposal draft that you was so kind to send me. It' very > > very good. However I believe too complicated and needs a lot of work > > to be implemented and it's pretty bandwidth intesive. > > > > About comments: > > 1. Yes, it's not a problem. I will make that change and resubmit the draft. > > However when Client dies it's just simple mater of reconnecting. Usually > > problem is when Secure Gateway loose connection because it's should be > > restarted or this connection dropped manually. > > > > 2. I didn't thought of that and I was not aware of that practice. Thank you > > so much for the feedback. This will be changed too. > > > > Stephane Beaulieu wrote: > > > > > Hi Vlado, > > > > > > I'm not sure if you were aware of it, but there is another Internet-Draft > > > whose goal it is to provide the same functionality. See > > > http://www.vpnc.org/draft-ietf-ipsec-heartbeats > > > > > > It has received quite a bit of feedback, and I think that most people are > > > pretty satisfied with it. > > This is absolute nonsense. Take a straw poll right now. > > > > All in all, I think the rough consensus was that a much simpler > mechanism would suffice. > > Scott From owner-ipsec@lists.tislabs.com Fri Jun 30 08:48:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09017; Fri, 30 Jun 2000 08:48:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12628 Fri, 30 Jun 2000 10:01:02 -0400 (EDT) Message-ID: <395CAA53.4C6F2B22@F-Secure.com> Date: Fri, 30 Jun 2000 17:10:27 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Vlado Zafirov