From test-admin@portal1.gw.tislabs.com Sun Sep 1 02:02:28 2002 Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8192R217404 for ; Sun, 1 Sep 2002 02:02:27 -0700 (PDT) Received: by sentry.gw.tislabs.com; id FAA14519; Sun, 1 Sep 2002 05:01:56 -0400 (EDT) Received: from portal1.gw.tislabs.com(192.94.214.242) by sentry.gw.tislabs.com via smap (V5.5) id xma014266; Sun, 1 Sep 02 09:01:20 GMT Received: from portal1.gw.tislabs.com (localhost [127.0.0.1]) by portal1.gw.tislabs.com (8.12.6/8.12.6) with ESMTP id g8191kFk002939 for ; Sun, 1 Sep 2002 05:01:46 -0400 (EDT) Message-Id: <200209010901.g8191kFk002939@portal1.gw.tislabs.com> Date: Sun, 01 Sep 2002 05:01:45 -0400 Subject: portal1 mailing list memberships reminder From: mailman-owner@lists.tislabs.com To: ietf-ipsec@vpnc.org X-No-Archive: yes X-Ack: no Sender: test-admin@lists.tislabs.com Errors-To: test-admin@lists.tislabs.com X-BeenThere: test@portal1 X-Mailman-Version: 2.0.9 Precedence: bulk This is a reminder, sent out once a month, about your portal1 mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ipsec-request@portal1) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@portal1. Thanks! Passwords for ietf-ipsec@vpnc.org: List Password // URL ---- -------- ipsec@portal1 izdoob http://portal1.gw.tislabs.com:8180/mailman/options/ipsec/ietf-ipsec%40vpnc.org From owner-ipsec@lists.tislabs.com Sun Sep 1 13:58:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g81KwU210378; Sun, 1 Sep 2002 13:58:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24959 Sun, 1 Sep 2002 15:58:41 -0400 (EDT) X-Originating-IP: [217.29.140.5] From: "Mohammad Awad" To: ipsec@lists.tislabs.com Subject: the first message to responder Date: Sun, 01 Sep 2002 23:13:41 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Sep 2002 20:13:41.0875 (UTC) FILETIME=[10FE0C30:01C251F4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all: Is this scenario, the truth. the responder must receive the first packet from the initiator (e.g. src(10.1.1.1:333) dst(127.22.3.45:21)) to look it up in his SPD and decide upon the security services that must br afforded. if it is that, what can be the link between this first message (from initiator), and the next ISAKMP one that begins the negotiation. Isn't it important to link those two messages to exponentiate that the same application/peer has them both? thanx all _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ipsec@lists.tislabs.com Mon Sep 2 08:10:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g82FA1200352; Mon, 2 Sep 2002 08:10:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28396 Mon, 2 Sep 2002 10:15:48 -0400 (EDT) Date: Mon, 02 Sep 2002 22:04:18 +0800 From: Jerry Yao Subject: Re: Clarification of potential NAT multiple client solutions To: ipsec@lists.tislabs.com Message-id: <001001c2528a$01b81180$04a7c6ca@jlu.edu.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook Express 5.00.2615.200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <2E33960095B58E40A4D3345AB9F65EC1056BF00A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think to solve the conflicts described in draft-ietf-ipsec-udp-encaps-03.txt sections 5.2 and 5.3, we should include the port as a part of selector, than the server can pick out the corresponding SA to protect the packets that send to clients behind the NAT. Is there any problem to involve port as a part of selector? > We have had requests to clarify potential solutions to problem of multiple clients behind the same NAT simultaneously connecting to the same destination IP address. draft-ietf-ipsec-udp-encaps-03.txt sections 5.2 and 5.3 say you MUST avoid the problem. Therefore you must implement some kind of solution for this problem. If your solution is not to support the scenario, you can still interoperate with others and support just one client behind the same NAT with SA state to you at any one time. > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-03.txt From owner-ipsec@lists.tislabs.com Mon Sep 2 08:14:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g82FEL200598; Mon, 2 Sep 2002 08:14:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28455 Mon, 2 Sep 2002 10:32:50 -0400 (EDT) Message-Id: <200209021447.g82ElNHt031251@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: suites - phase 1 vs 2 In-reply-to: Your message of "Fri, 30 Aug 2002 17:48:20 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 02 Sep 2002 10:47:21 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> I'm trying not to use the terms phase 1 and phase 2 algorithms Charlie> because phase 1 negotiates both an IKE-SA and a Child-SA (ESP Charlie> and/or AH and/or IPcomp). I believe the definition of a suite Charlie> should include the protocol it is securing. That means we need a Charlie> minimum of two suites: one of IKE and one for ESP. People are okay. agreed. Charlie> likely to want additional suites for ESP+IPcomp, for AH, and for Charlie> who knows what other combinations. If suites are independent of I think that we have ESP suites like: 1) 3DES/MD5 (i.e. no IPcomp) 2) 3DES/SHA1 3) 3DES/MD5/LZS 4) AES/SHA1/LZS ... that is, I'm pretty sure that we want the IPcomp choice (or not) to be part of the ESP suite, not a seperate list. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPXN59YqHRg3pndX9AQGo2wP+MyMTw2H6MedIPlibLTR2YSCGtTyIBfdz l9BaqdPB197DOcjjTPyPYLnSFbazY/RmF/pZEXOLzku1hOWTyyewnGJt16FPJ+HJ 83Ny/5J/d8NBTZkdLUnkT0m5YhXEj+EEn8tZzaChpg9XMES2Pu6FIpXLDw8Dy0D0 bFtZudWUKA0= =uGu1 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Sep 2 23:48:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g836mV218919; Mon, 2 Sep 2002 23:48:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA29948 Tue, 3 Sep 2002 01:50:09 -0400 (EDT) X-Originating-IP: [12.40.232.3] From: "S Lal" To: rcharlet@redcreek.com Cc: ipsec@lists.tislabs.com Subject: Reg. ICMP handling in IPsec Date: Tue, 03 Sep 2002 11:35:11 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Sep 2002 06:05:11.0619 (UTC) FILETIME=[DCF0F930:01C2530F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ricky, I find your description very useful as it complimnets the section 6 of RFC 2401. It seems that ICMP handling in IPsec is going to more prorietary way. But, how does the products will support the SPD entries with requiremnet that there should be a SA for Ping packets but separate action for ICMP errors ? I have few questions regarding handling of ICMP messages from R1 to SGw1. Based on the presence of SPI, you have marked that the message is meant for E1'. So, did you assume that SGw1 is acting as purely router and it does not support any of the managemnet applications like telnet/snmp which may use transport mode SAs. If SGw1 is supporting the both kinds of SAs, then how it will determine that the message is intended for me or the n/w supported behind me , i.e. E1' . regards To: ipsec Subject: ICMP in IPSec From: Ricky Charlet Date: Fri, 14 May 1999 21:04:45 +0000 Organization: RedCreek Communications Inc. Sender: owner-ipsec@lists.tislabs.com -------------------------------------------------------------------------------- Howdy () There exists a draft named draft-ietf-icmp-handle-44-00.txt which is a template nameing each ICMP message and provides a space describing how to handle that ICMP message. The draft is a template because none of the descriptions are filled in. Back at the 44th (Minneapolis) I believe I recall the working group deciding that ICMP handling needed to get more specific befor closing the group. There was a call for volunteers to put in effort. I volunteered and here is a bit of effort. I have not followed Michael Richardson's draft (icmp-handle) in my 'initial thoughts' post. I find it more clear to ponder these out in terms of 'situational examples'. I hope (naively??) that my list of situations is complete. The goal would be to move from my situational format to filling in Michael's draft with the details per message rather than per situation. These are my initial thoughts. I am looking for feed back. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### ===================== || || +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | | | E1 |---|Sgw1 |---| R1 |---|Sgw2 |---| R2 |----| E2 | | | | | | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ E1' E2' Terminology: o E1 and E2 are IPSec endpoints. These endpoints are defined in Sgw1 and Sgw2 by IPSec selectors. o Sgw1 and Sgw2 are IPsec Security Gateways. o R1 and R2 are non-IPSec routers. o E1' and E2' are derived from the deffinitions of E1 and E2. These 'prime' endpoints are defined only by IP address or IP Address range. Whereas E1 and E2 may have been defined by IP address(range) and ports and protocols, and/or fqdn, and/or user@fqdn etc... ICMP traffic from Sgw1 to E1. Sgw1 needs to ask itself if it trusts that the traffic causing the ICMP event is really from E1, a trusted endpoint. Sgw1 may choose to always trust that any traffic received from this interface is authentic, may decide never to trust any traffic received on this interface, or may decide that traffic received on this interface is authentic only if its source address matches E1'. This matching, only results in weak authentication which could easily be spoofed. The choice of never trust, always trust, or match src address against E1' to determine trust, when considering whether to respond to ICMP MUST be an administratively configurable behavior per interface with the default action being never to trust. ICMP traffic from R1 to E1. This is unexpected. R1 should never have any knowledge of E1's IP address and therfore should not be able to direct ICMP messages at E1'. All such ICMP traffic MUST be silently discarded by Sgw1 unless an operator has configured an applicible bypass IPSec selector (this is NOT recomended). ICMP traffic from R1 to Sgw1. Traffic from R1 does not arrive in an SA and is therefore of highly suspect integrity. If R1 is sending an IMCP error message, then the original offending IP packet returned with the ICMP error message is almost certianly trunkated, possilby making it impossible to deterime the original sender's IP address. Also, there are extremely few ICMP messages which R1 might return that E1' could possibly be interested in. These are "fragmentation needed", "unreachable due to TOS (net and host)", and to a lessor degree "source quench" and/or ECN notifications. The Fragmentation and TOS messages are of possible interest to E1' because the associated bits from E1's IP header were copied to the tunnel mode outer IP header and therefore exposed to the Internet which might rerun valid errors related to these fields. Since the outer IP header hides all other information about the inner IP header, no ICMP reachable errors, or redirect errors, or TTL errors, or parameter problem errors relate to the IP header which E1' sent. The only other valid information that R1 may have for E1' would relate to flow control. A source quench message inticates that E1' should take some flow control action, but the soruce quench mechanism is depricated and current router implementations are advised not to originate ICMP soruce quench messages so these are safly ignorable. There is a new experimental protocol called "Explicite Congestion Notification". If it is ever embraced by the IPSec comunity, some people may wish to examine how to make it work in this scenario. But as for now, ECN will not be considered. So Sgw1 has four questions to answer about ICMP messages received from R1 intended for return to E1'. 1. Is this message intended for me directly or for some endpoint I protect? 2. Is this an interesting message? 3. Do I trust the message? 4. Is there enough information in the message to be useful to E1'? To answer question number 1 above use the following logic: If message is an ICMP query, then it is not for E1'... respond to ICMP queries to this interface as per local interface policy. If message is an ICMP error, then examine the original offending packet data IPSec Header field for a valid SPI number. Presence of an SPI implies that this message is intended for some endpoint and not for the Sgw itself. If the message is in fact intended for this Sgw, then local policy should specify whether to handle/respond or ignore the message. If message is intended for some endpoint behind this gateway, and local policy allowed ICMP processing on this interface, then proceed to question 2 from above. To answer question 2above, only the IMCP error messages: o fragmentation needed but DF set o network unreachable for TOS o host unreachable for TOS MAY be forwarded onward to E1'. All other ICMP messages intended for E1' MUST be dropped. Now you may ask yourself, "What about all those unreachable messages?" Receipt of an 'unreachable' IMCP error message on Sgw1 while it was trying to send to Sgw2 is not a problem that E1 need be informed of directly. It is an implementation concern with what to do when tunneled traffic is attempting to reach an unreachable peer gateway. To answer question number 3 above, the only secure course is to not trust messages appearing at Sgw1 which did not arrive in an SA. But an Operations and Maintenance group might evaluate the security risk (DOS attack) of accepting these limited IMCP error messages as worth the value of knowing about PMTU, and/or TOS reachability. So they will need a configurable option to allow each of these messages. The IMCP configuration MUST allow for explicit pass/block filtering on Fragmentation Needed messages, and on TOS messages. These filter rules are over and above what is achievable with IPSec selectors. To answer question 4 above, first understand the problem. It may be that the IMCP error message did not bundle the entire original offending IP packet. We know the original offending IP packet was a tunneled packet with an outer IP header, and an IPSec header, and an inner IP header and data and trailers. In order to be useful to E1', we need to recover the original inner IP header and first 8 bytes of IP data. This is because E1' will need to deliver this IMCP message to a transport protocol, therefore E1' will need to identify the exact socket this packet was sent from. Attempting to guess E1's identity from the SPI# in the SA header (almost always present in the returned original offending packet) will be insufficient to identify the exact socket on E1' and is therefore a fruitless endeavor. But recovering the inner IP header from the original offending packet may not always be possible. And even if it is possible, it will most likely be a difficult endeavor. Recovering the inner IP header in the case of an AH tunneled packet requires that we be able to see the entire outer IP header (20 bytes +options) the entire AH header (32 or more bytes), 20 or more bytes of the inner IP header (full header sans options) and 8 bytes of inner IP payload. If there is enough data present, then the inner IP packet header may be read. But it is extremely unlikely that the entire original IP packet was returned so that the data will not be able to be authenticated (but understand that if we have gotten this far, it means that an administrator has already made the choice to trust this information in spite of its inability to be authenticated). Recovering the inner IP header in the case of an ESP tunneled packet requires that we be ale to see the entire outer IP header (20 bytes +options) and enough of the ESP packet so that we may reference the SPI and then decrypt enough of the payload data to reveal the inner IP header, optinos and first 8 bytes of data. Again, it is very unlikely that we will have the entire original IP packet and will not be able to authenticate, but a trust decisions has already been made in spite of this limitation. In cases of SA bundles where there are multiple transforms applied, the SPI will indicate to us which transforms we need to undo and how much of the original IP packet we need to recover. If the original inner IP packet header cannot be recovered, cease all further processing related to handling this error and drop the ICMP packet. An implementation MAY wish to make this an auditable event. If the original inner IP packet header and the first 8 bytes of original IP packet data can be recovered, then the security gateway MUST construct a new IMCP error message. It MUST be addressed to the source address named in the original inner IP header. It's ICMP type, ICMP code, IP TOS, and IP precedence MUST match the old ICMP packet (now being discarded). And the data it contains MUST be the original inner IP packet header plus 8 bytes of the original inner IP packet data. ICMP traffic from Sgw2 to Sgw1: This situation occurs when Sgw2 receives an IP packet from Sgw1 which is addressed to Sgw2. This occurs frequently since Sgw2 is the endpoint of a tunnel. This discussion should not be confused with Sgw2 deciding to send an ICMP error to E1', which might occur after tunnel decapsulation. That situation is discussed in the next section. Sgw2 may respond to an IMCP query from Sgw1, or may generate an ICMP error to return to Sgw1. Sgw2 may respond to a query in the clear if an IPSec selector matching protocol=IMCP and src address=Sgw1 allowed the bypass action (Sgw2 might have query responded to anything in the Internet if the bypass selector for protocol=ICMP had allowed). Sgw2 may respond to an IMCP query from Sgw1 in an SA if the IPSec selector specified a Secure action. (This SA might need to be negotiated, the IMCP query response SHOULD be held until the SA is up). Sgw2 MUST NOT ever decide to generate an ICMP error message to Sgw1 at this point. Realize that this is before any SPI matching and IPSec untransforming has cured. After IPSec untransforming has occurred, Sgw2 may decide to send errors back to E1', that is covered in the next section. At this point, there is no error message that Sgw2 could send to Sgw1 which Sgw1 may find to be actionable. The IP packet was obviously deliverable. It is not yet known if it is administratively prohibited or TOS prohibited. It is not realistic to tell an ISAKMP peer to redirect. Even if the packet times out during re-assemble on Sgw2, this is not information that Sgw1 cares about (in a tunnel mode SA). ICMP traffic from Sgw2 to E1': After Sgw2 has SPI matched the tunneled packet and untransformed the packet, it has the IP header and payload from E1' in hand. Sgw2 may either realize that E1' has sent it an ICMP query or that traffic sent by E1' destined for other locations, is offending and it should send back an IMCP error to E1'. Because the traffic arrived through an SA, Sgw2 MUST consider the traffic authentic. ICMP queries should be handled as per relevant RFC and returned to E1' being sent trough the complementary SA back to Sgw1. Sgw1 must be able to recognize that ICMP traffic arriving in an SA, destined to E1' and sourced from that SA's ISAKMP peer is allowable and forward the ICMP packet. Sgw1 MUST do this even if the SA selectors did not natrually allow ICMP traffic. When Sgw2 decides to return an ICMP error to E1', similar processing occurs. Sgw2 creates the IMCP error message and MUST attach the entire offending IP packet and must ensure that the DF bit is cleared. Note, that at this point, the offending IP packet is in an un-encapsulated state. The ICMP packet which bundles the original offending IP packet is sent to E1' via Sgw1 through the complement SA of the SA it arrived on. Sgw1 recognizes that an ICMP packet to E1' arriving on an SA from the ISAKMP peer far end of the SA is allowable and forwards the packet. ICMP traffic from R2 to E1' MUST be dropped by Sgw2 due to no match with selectors. But, note a workaround here. If an operations and maintenance group wishes to trust and allow these ICMP messages (from R2 to E1'), then they may configure on Sgw1 and Sgw2, new selectors which match R1's IP addresses, to E1's IP address(es) and protocol = ICMP. In this case, R2 becomes a new, legitimate endpoint (let's say E3). An SA from Sgw2 to Sgw1 for carrying E3 to E1' ICMP traffic is negotiated and utilized. The parameters of this SA will be entirely up to the O&M group. ICMP traffic from E2' to E1': Handle as per IPSec selector specifications on Sgw2. It is recommended that even when E2 is more narrowly idenified than an IP address, that protocol=ICMP be configured to fit in the selector. New requirements for IPSec Security Gateways. o a per interface ICMP allow/deny/if-match-endpoint-IP config toggle o a per interface trust ICMP error frag-needed toggle o a per interface trust ICMP error TOS deny toggle o when generating an ICMP error, MUST bundel entire original IP datagram and clear DF bit. o Never send ICMP errors to an ISAKMP peer. -------------------------------------------------------------------------------- Follow-Ups: Re: ICMP in IPSec From: Ari Huttunen Re: ICMP in IPSec From: Michael Richardson Re: ICMP in IPSec From: "Loretta Zhou" -------------------------------------------------------------------------------- Prev by Date: Re: IKE transport (was INITIAL-CONTACT issues) Next by Date: ISP's who assign unrouteable addresses Prev by thread: RE: draft-ietf-ipsec-policy-schema-00.txt Next by thread: Re: ICMP in IPSec Index(es): Main Thread _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ipsec@lists.tislabs.com Tue Sep 3 07:56:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83Eun209729; Tue, 3 Sep 2002 07:56:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00874 Tue, 3 Sep 2002 10:06:43 -0400 (EDT) Date: Sun, 01 Sep 2002 00:41:54 +0900 Message-ID: From: Mitsuru KANDA / =?ISO-2022-JP?B?GyRCP0BFRBsoQiAbJEI9PBsoQg==?= To: "Andrew Wenlang Zhu" Cc: Subject: Re: IPSec v6 on linux In-Reply-To: <000801c2505f$7b3bff80$6f690d0f@AZ735043> References: <15727.44113.263383.84182@pkoning.dev.equallogic.com> <000801c2505f$7b3bff80$6f690d0f@AZ735043> User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Andrew, > Does anybody aware any IPsec can support IPV6 on this kernel? Please try to use USAGI IPsec (http://www.linux-ipv6.org/) -mk From owner-ipsec@lists.tislabs.com Tue Sep 3 07:57:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83Ev9209754; Tue, 3 Sep 2002 07:57:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00855 Tue, 3 Sep 2002 10:04:38 -0400 (EDT) From: Sabrina Minshall Message-Id: <200208310218.TAA09565@shell.accesscom.com> Subject: ICMP error generation To: ipsec@lists.tislabs.com Date: Fri, 30 Aug 2002 19:18:22 -0700 (PDT) CC: Sabrina Minshall X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DCC-Hypersurf-Metrics: mercury.hypersurf.com 1047; Body=1 Fuz1=1 Fuz2=1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, suppose a VPN gateway encrypts a packet and the next hop to the tunnel (endpoint) is unreachable. What should be done? Should the packet be dropped (without generating an ICMP host/net unreachable?). sabrina From owner-ipsec@lists.tislabs.com Tue Sep 3 09:56:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83Gu0219146; Tue, 3 Sep 2002 09:56:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01288 Tue, 3 Sep 2002 12:04:08 -0400 (EDT) Message-Id: <200209031618.g83GIdP2019423@kebe.east.sun.com> Subject: Re: suites - phase 1 vs 2 In-Reply-To: <200209021447.g82ElNHt031251@marajade.sandelman.ottawa.on.ca> from Michael Richardson at "Sep 2, 2002 10:47:21 am" To: Michael Richardson Date: Tue, 3 Sep 2002 12:18:36 -0400 (EDT) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering 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 > I think that we have ESP suites like: > > 1) 3DES/MD5 (i.e. no IPcomp) > 2) 3DES/SHA1 > 3) 3DES/MD5/LZS > 4) AES/SHA1/LZS > ... > > that is, I'm pretty sure that we want the IPcomp choice (or not) to be part > of the ESP suite, not a seperate list. You either need to also include AH (whether it's there or not), OR you need to treat AH, ESP, and IPcomp as separate protocols. You can't just include subsets. You need to either treat the whole problem, or decompose the problem completely. Dan From owner-ipsec@lists.tislabs.com Tue Sep 3 09:59:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83GxJ219608; Tue, 3 Sep 2002 09:59:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01301 Tue, 3 Sep 2002 12:17:10 -0400 (EDT) From: "Housley, Russ" To: "Hallam-Baker, Phillip" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020903121829.03468c20@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Sep 2002 12:21:31 -0400 Subject: RE: Last ditch proposal for crypto suites In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40DF2DD25@vhqpostal.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phill: I think the SHOULD is the way to handle the key size issue. Here is how the S/MIME WG addressed this issue in RFC 2633. A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits. A user agent MUST NOT generate RSA key pairs less than 512 bits long. Creating keys longer than 1024 bits may cause some older S/MIME receiving agents to not be able to verify signatures, but gives better security and is therefore valuable. A receiving agent SHOULD be able to verify signatures with keys of any size over 512 bits. Some agents created in the United States have chosen to create 512 bit keys in order to get more advantageous export licenses. However, 512 bit keys are considered by many to be cryptographically insecure. Implementors should be aware that multiple (active) key pairs may be associated with a single individual. For example, one key pair may be used to support confidentiality, while a different key pair may be used for authentication. Russ At 08:49 AM 8/30/2002 -0700, Hallam-Baker, Phillip wrote: >I don't think we should spec the RSA keystrengths since this is not >typically a negotiated parameter, the parties tend to have one key and the >trustworthiness of that key is the issue. > >i.e. the endpoint may reject a key because it does not accept the >certificate (or other validation). If an end point rejects 1024 bit keys as >a matter of policy that will be incorporated into the certification policy. > >What we should do however is to require that the implementations accept key >sizes up to at least 2048 bits and possibly 4096. As a practical matter >requiring keys to be multiples of 32 bits is also a good idea (there is a >1000 bit key in use). > > > Phill > > > -----Original Message----- > > From: Alex Alten [mailto:Alten@attbi.com] > > Sent: Friday, August 30, 2002 10:22 AM > > To: Hallam-Baker, Phillip; Charlie_Kaufman@notesdev.ibm.com; > > ipsec@lists.tislabs.com > > Subject: RE: Last ditch proposal for crypto suites > > > > > > This sounds reasonable. Shouldn't we also spec the RSA key lengths? > > And is 3DES-CBC doing EDE or EEE? (I assume EDE is preferable?) > > > > - Alex > > > > > > At 06:45 AM 8/30/2002 -0700, Hallam-Baker, Phillip wrote: > > >Actually following on from Radia's point I think we would > > have three suites: > > > > > >1: RSA/3DES-CBC/SHA-1 > > >2: RSA/AES-CTR-128/SHA-2 > > >3: RSA/AES-CTR-256/SHA-2 > > > > > >The argument for suite 3 being that if something > > catastrophic does happen in > > >the processing world there is a last ditch fallback. > > > > > >I would limit the SHOULD suites to the DSA variants of the above but > > >excluding 3DES since the demand for DSA is likely to be > > restricted to people > > >who want NIST acredited crypto and 3DES ain't acredited. > > > > > >4: DSA/AES-CTR-128/SHA-2 > > >5: DSA/AES-CTR-256/SHA-2 > > > > > >I don't want any other suites. I don't want EC variants, I > > don't want a > > >different chaining mode for each day of the week. > > > > > >One thing that would be very useful for integration with > > specs in the Web > > >Services space is if a unique URN was specified for each suite. EG > > >urn:ietf:rfcxxx:cryptosuite-1 > > > > > >This would then allow the suite specification to be > > specified in negotiation > > >at the Web services level. So that a UDDI directory or WSDL > > could contain a > > >policy statement that says 'this service requires the use of IPSEC > > >cryptosuite 2 or 4'. > > > > > >Note that we have fewer suites in total than we had > > symmetric algs for IKE1. > > > > > > > > > Phill > > > > > >> -----Original Message----- > > >> From: Alex Alten [mailto:Alten@attbi.com] > > >> Sent: Friday, August 30, 2002 2:33 AM > > >> To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com > > >> Subject: Re: Last ditch proposal for crypto suites > > >> > > >> > > >> At 05:58 PM 8/29/2002 -0400, > > Charlie_Kaufman@notesdev.ibm.com wrote: > > >> > > > >> >I propose that we remove the text for a la carte negotiation > > >> from the IKEv2 > > >> >spec, > > >> ... > > >> > > >> I'm amazed that after so many years the WG is still arguing > > >> over this issue > > >> (or maybe I'm not). As Steve B. pointed out interoperability > > >> and buggy code > > >> are very important considerations. > > >> > > >> We only need to spec two MUST have suites. RSA/3DES-CBC/SHA-1 and > > >> RSA/AES-CTR-128/SHA-2. Forget the rest, they are going into > > >> the dustbin > > >> of history. Details like PFS, HMAC should be the same across > > >> the suites. > > >> > > >> What I'll add, along with my vote to do suites, is that the > > >> receiver MUST > > >> accept whatever suite the sender chooses to use. This will > > >> make life a lot > > >> easier and will not be a "security" problem. The difference > > >> between 3DES and > > >> AES-128 is minor. What we are really after is to provide an > > >> upgrade path from > > >> 3DES to AES, to gain the huge performance improvement and yet > > >> not screw our > > >> existing customers. > > >> > > >> Choose the mandatory suites wisely and sparingly. Once the > > >> IKEv2 dust has > > >> settled there will be much more difficult fish to fry. > > >> > > >> Good luck Charlie & Co., > > >> > > >> - Alex > > >> > > >> -- > > >> > > >> Alex Alten > > >> Alten@ATTBI.com > > >> > > > > > -- > > > > Alex Alten > > Alten@ATTBI.com > > From owner-ipsec@lists.tislabs.com Tue Sep 3 10:05:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83H5d220241; Tue, 3 Sep 2002 10:05:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01341 Tue, 3 Sep 2002 12:25:17 -0400 (EDT) Message-ID: <3D74E63A.4040002@isi.edu> Date: Tue, 03 Sep 2002 09:41:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sabrina Minshall CC: ipsec@lists.tislabs.com, Sabrina Minshall Subject: Re: ICMP error generation References: <200208310218.TAA09565@shell.accesscom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sabrina Minshall wrote: > Hi All, > suppose a VPN gateway encrypts a packet and the next hop to the > tunnel (endpoint) is unreachable. What should be done? Should > the packet be dropped (without generating an ICMP host/net > unreachable?). > > sabrina This is more of a tunnel issue. RFC2003, although not exactly what IPsec specifies, addresses these issues for IP-encapsulation tunnels already. Notably Sec 3.2 says the packet SHOULD be dropped, and Sec 4.1 says that an ICMP Unreachable SHOULD be returned. RFC2401 addresses the IPsec-specific version, which includes some additional filtering rules which do not appear to preclude 2003-style handling. Joe From owner-ipsec@lists.tislabs.com Tue Sep 3 10:24:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g83HOc221330; Tue, 3 Sep 2002 10:24:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01405 Tue, 3 Sep 2002 12:44:30 -0400 (EDT) Message-Id: <200209031658.g83GwRCJ007621@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: suites - phase 1 vs 2 In-reply-to: Your message of "Tue, 03 Sep 2002 12:18:36 EDT." <200209031618.g83GIdP2019423@kebe.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 03 Sep 2002 12:58:27 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan McDonald writes: >> 1) 3DES/MD5 (i.e. no IPcomp) >> 2) 3DES/SHA1 >> 3) 3DES/MD5/LZS >> 4) AES/SHA1/LZS >> ... >> >> that is, I'm pretty sure that we want the IPcomp choice (or not) to be part >> of the ESP suite, not a seperate list. Dan> You either need to also include AH (whether it's there or not), OR Dan> you need Dan> to treat AH, ESP, and IPcomp as separate protocols. You can't just Dan> include I would actually prefer to do the former - include AH or not. This gets rid of the various debates about IP ESP AH IP vs IP AH ESP IP vs IP AH IP ESP IP ... This becomes part of the ciphersuite. I think that ciphersuites would then essentially become use cases. Does that give us too many of them? I doubt it. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPXTqMYqHRg3pndX9AQEq3QP/UVPJO0/TpIm/hxcCbxGDYQyw9A/NkBp4 5Xd3HIXR59c225vq3kLZakDF79PQMfzPAfzq0TBvIUPYVm0wcFHfbSqvBJXpPz7f PScLQwBru63R7/rtB5hX/7VFqtT1rLvvcLP5MkmokA07TnCoRdfKMLhtgyhcfDlh h5R6pGNqjQo= =T10K -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Sep 3 21:38:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g844cm224391; Tue, 3 Sep 2002 21:38:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03063 Tue, 3 Sep 2002 23:51:02 -0400 (EDT) Message-ID: <20020904040510.28007.qmail@web11504.mail.yahoo.com> Date: Tue, 3 Sep 2002 21:05:10 -0700 (PDT) From: Feng Ye Subject: IPSec NAT pass-through: how the server side distinguish different client? To: ipsec@lists.tislabs.com In-Reply-To: <000001c24743$bd9d2a90$0402a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I have implemented IPSec NAT pass through in the access box by looking at cookie/SPI values. I can sucessfully do the 1 to 1 and 1 to many cases, but can't do the many to 1 case, because I don't know how to configure the public side VPN server. That server don't know how to distinguish different clients behind the NAT, because they all have the same tunnel endpoint IP address (the NAT public address), and they all use ESP, and the same encrypt/authenticate algorithm. So to the server, all of them belongs to the same SA. Captured packets in the server side shows that even different clients use different SPI to talk to the server, the server responses with the same SPI, thus caused the problem. I tested with cisco 2600 and win2000 as the VPN server, all has the same problem. Is anybody there can give me a clue? Thanks a lot! feng __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From owner-ipsec@lists.tislabs.com Wed Sep 4 07:38:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84EcL221287; Wed, 4 Sep 2002 07:38:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04003 Wed, 4 Sep 2002 09:44:50 -0400 (EDT) Message-ID: <00ad01c253ba$b6fe0b40$17301bd2@xajump.edu.cn> From: "climbor" To: Subject: Question about KE payload Date: Wed, 4 Sep 2002 10:28:07 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id WAA02878 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, Here is my question: How to construct the KE payload if there are multiple SA in the first Quick message and each SA have different PFS group (say group 1 and group 2)? Construct multiple KE payload too? Or just select the longer one? Or this is just a invalid case (Netscreen support multiple SA with different PFS group, I guest so from its manual)? thanks From owner-ipsec@lists.tislabs.com Wed Sep 4 10:09:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84H9w200269; Wed, 4 Sep 2002 10:09:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04272 Wed, 4 Sep 2002 12:15:24 -0400 (EDT) Message-ID: <20020904162945.35420.qmail@web11503.mail.yahoo.com> Date: Wed, 4 Sep 2002 09:29:45 -0700 (PDT) From: Feng Ye Subject: RE: IPSec NAT pass-through: how the server distinguish different clients? To: ipsec@lists.tislabs.com Cc: Van Aken Dirk In-Reply-To: <421CB3B9B2D2F645B548D213C0A90E55090DEE@edgmsmsg01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the answer. But what I observed is the opposite. I captured all the packets in the server VPN side, what I see from the captured packets are: 1. When clientA talk with the server, there're ESP packets going back and forth with clientA's SPI (say, SPI_A) and server's SPI (say, SPI_S). 2. Then clientB start to talk with the server, I can see there're UDP/500 packets for main mode and quick mode. 3. Then clientB send ESP with a different SPI (say, SPI_B), however, upon receiving SPI_B, the server still responds with SPI_S, not a new SPI. So when this response packet reached my NAT box, the box has associated SPI_S with SPI_A so it forward the packet to clientA. This caused the problem. I think the problem is in server setting, how can the server distinguish different clients behind the NAT, since for all these clients, the server settings are the same: same tunnel destination IP address (the NAT public address), same protocol (ESP), same encryption/authentication (DES-MD5, etc). Anybody has a clue? Besides, this is not about UDP encapsulation, it's pure ESP packets. Thanks! feng --- Van Aken Dirk wrote: > Hi Feng, > > Do I understand you correctly i.e. > > 1) packets form the clients to the server always use > the same SPI value > > 2) packets from the server to the clients use a > different SPI value per > client > > Can you confirm this ? > > BTW, regarding selection of SPI value it is > important to know that the SPI > is chosen by the receiving system. > i.e If a client wants to receive packets from a > server, it is the client > that tells the server which SPI value to use. > > Best regards - Dirk > > -----Original Message----- > From: Feng Ye [mailto:f_ye@yahoo.com] > Sent: Wednesday 4 September 2002 6:05 > To: ipsec@lists.tislabs.com > Subject: IPSec NAT pass-through: how the server side > distinguish > different client? > > > Hello, > > I have implemented IPSec NAT pass through in the > access box by looking at cookie/SPI values. I can > sucessfully do the 1 to 1 and 1 to many cases, but > can't do the many to 1 case, because I don't know > how > to configure the public side VPN server. > That server don't know how to distinguish different > clients behind the NAT, because they all have the > same > tunnel endpoint IP address (the NAT public address), > and they all use ESP, and the same > encrypt/authenticate algorithm. So to the server, > all > of them belongs to the same SA. Captured packets in > the server side shows that even different clients > use > different SPI to talk to the server, the server > responses with the same SPI, thus caused the > problem. > I tested with cisco 2600 and win2000 as the VPN > server, all has the same problem. > Is anybody there can give me a clue? Thanks a lot! > > feng > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From owner-ipsec@lists.tislabs.com Wed Sep 4 10:55:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Ht7202577; Wed, 4 Sep 2002 10:55:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04391 Wed, 4 Sep 2002 13:08:00 -0400 (EDT) Message-ID: <008001c25437$89713f30$7505010a@SindhuSriha> From: "Srinivasa Rao Addepalli" To: "Feng Ye" , References: <20020904040510.28007.qmail@web11504.mail.yahoo.com> Subject: Re: IPSec NAT pass-through: how the server side distinguish different client? Date: Wed, 4 Sep 2002 10:21:42 -0700 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You need to create different SPD policies on the VPN server for each client behind your NAT (having IPSEC NAT passthrough). These SPD policies on the VPN server should have client IP addresses (private IP addresses) as destination IP address selector. Remote security gateway IP address on these SPD policies needs to be public IP address on the NAT box. Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Feng Ye" To: Sent: Tuesday, September 03, 2002 9:05 PM Subject: IPSec NAT pass-through: how the server side distinguish different client? > Hello, > > I have implemented IPSec NAT pass through in the > access box by looking at cookie/SPI values. I can > sucessfully do the 1 to 1 and 1 to many cases, but > can't do the many to 1 case, because I don't know how > to configure the public side VPN server. > That server don't know how to distinguish different > clients behind the NAT, because they all have the same > tunnel endpoint IP address (the NAT public address), > and they all use ESP, and the same > encrypt/authenticate algorithm. So to the server, all > of them belongs to the same SA. Captured packets in > the server side shows that even different clients use > different SPI to talk to the server, the server > responses with the same SPI, thus caused the problem. > I tested with cisco 2600 and win2000 as the VPN > server, all has the same problem. > Is anybody there can give me a clue? Thanks a lot! > > feng > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > From owner-ipsec@lists.tislabs.com Wed Sep 4 12:24:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g84JOq205259; Wed, 4 Sep 2002 12:24:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04554 Wed, 4 Sep 2002 14:33:59 -0400 (EDT) From: BSingh@Nomadix.com Message-ID: <89680B404BA1DD419E6D93B28B41899B73B0B3@01mail.nomadix.com> To: f_ye@yahoo.com, ipsec@lists.tislabs.com Subject: RE: IPSec NAT pass-through: how the server distinguish different clients? Date: Wed, 4 Sep 2002 11:36:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Feng, I have observed that Cisco VPN concentrator distinguishes different connections coming from the same IP (NAT IP) based on the source port. So you have to change the IKE source port for different connections coming from clients behind the NAT.. Then Cisco recognizes them as different connections. But I have also observed that this is not reliable and the connections break as Cisco sends some IKE packets back with destination port 500 which the NAT box doesn't know who to forward to.. And even if you forward to all clients it doesn't really stay on.. Best course is to do UDP encapsulation. Hope this helps.. -Bik > -----Original Message----- > From: Feng Ye [mailto:f_ye@yahoo.com] > Sent: Wednesday, September 04, 2002 9:30 AM > To: ipsec@lists.tislabs.com > Cc: Van Aken Dirk > Subject: RE: IPSec NAT pass-through: how the server > distinguish different clients? > > > Thanks for the answer. But what I observed is the > opposite. I captured all the packets in the server VPN > side, what I see from the captured packets are: > 1. When clientA talk with the server, there're ESP > packets going back and forth with clientA's SPI (say, > SPI_A) and server's SPI (say, SPI_S). > 2. Then clientB start to talk with the server, I can > see there're UDP/500 packets for main mode and quick > mode. > 3. Then clientB send ESP with a different SPI (say, > SPI_B), however, upon receiving SPI_B, the server > still responds with SPI_S, not a new SPI. So when this > response packet reached my NAT box, the box has > associated SPI_S with SPI_A so it forward the packet > to clientA. This caused the problem. > > I think the problem is in server setting, how can the > server distinguish different clients behind the NAT, > since for all these clients, the server settings are > the same: same tunnel destination IP address (the NAT > public address), same protocol (ESP), same > encryption/authentication (DES-MD5, etc). > > Anybody has a clue? Besides, this is not about UDP > encapsulation, it's pure ESP packets. > > Thanks! > > feng > > > --- Van Aken Dirk wrote: > > Hi Feng, > > > > Do I understand you correctly i.e. > > > > 1) packets form the clients to the server always use > > the same SPI value > > > > 2) packets from the server to the clients use a > > different SPI value per > > client > > > > Can you confirm this ? > > > > BTW, regarding selection of SPI value it is > > important to know that the SPI > > is chosen by the receiving system. > > i.e If a client wants to receive packets from a > > server, it is the client > > that tells the server which SPI value to use. > > > > Best regards - Dirk > > > > -----Original Message----- > > From: Feng Ye [mailto:f_ye@yahoo.com] > > Sent: Wednesday 4 September 2002 6:05 > > To: ipsec@lists.tislabs.com > > Subject: IPSec NAT pass-through: how the server side distinguish > > different client? > > > > > > Hello, > > > > I have implemented IPSec NAT pass through in the > > access box by looking at cookie/SPI values. I can > > sucessfully do the 1 to 1 and 1 to many cases, but > > can't do the many to 1 case, because I don't know > > how > > to configure the public side VPN server. > > That server don't know how to distinguish different > > clients behind the NAT, because they all have the > > same > > tunnel endpoint IP address (the NAT public address), > > and they all use ESP, and the same > > encrypt/authenticate algorithm. So to the server, > > all > > of them belongs to the same SA. Captured packets in > > the server side shows that even different clients > > use > > different SPI to talk to the server, the server > > responses with the same SPI, thus caused the > > problem. > > I tested with cisco 2600 and win2000 as the VPN > > server, all has the same problem. > > Is anybody there can give me a clue? Thanks a lot! > > > > feng > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com > From owner-ipsec@lists.tislabs.com Wed Sep 4 21:03:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8543d200395; Wed, 4 Sep 2002 21:03:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA05326 Wed, 4 Sep 2002 23:17:21 -0400 (EDT) From: Bill Manning Message-Id: <200209050330.g853UqJ06106@boreas.isi.edu> Subject: Re: IPSec v6 on linux In-Reply-To: from "Mitsuru KANDA / [?ISO-2022-JP?]" at "Sep 1, 2 00:41:54 am" To: mk@karaba.org (Mitsuru KANDA / =?ISO-2022-JP?B?GyRCP0BFRBsoQiAbJEI9PBsoQg==?=) Date: Wed, 4 Sep 2002 20:30:52 -0700 (PDT) Cc: Andrew_zhu@hp.com, ipsec@lists.tislabs.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % % Hello, Andrew, % % > Does anybody aware any IPsec can support IPV6 on this kernel? % Please try to use USAGI IPsec (http://www.linux-ipv6.org/) % % -mk % I am finding out that the ipsec stuff under USAGI is not compatable with the FreeSwan work. I hate to have both versions running on/in my dualstack machines. Can these two activities be harmonized? Or am I just overlooking something simple? -- --bill From owner-ipsec@lists.tislabs.com Thu Sep 5 02:46:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g859ke207217; Thu, 5 Sep 2002 02:46:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA05951 Thu, 5 Sep 2002 04:58:29 -0400 (EDT) Message-ID: <004c01c253f4$0d96fdc0$d2204789@kchundurd01> From: "kiran kumar" To: "climbor" , References: <00ad01c253ba$b6fe0b40$17301bd2@xajump.edu.cn> Subject: Re: Question about KE payload Date: Wed, 4 Sep 2002 14:48:36 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's not possible to have seperate DH-group for each SA negotiated in first Quick message. The same KE payload must apply to all SA's being negotiated. "refer section 5.5.-rfc 2409". ''All offers made during a Quick Mode are logically related and must be consistant. For example, if a KE payload is sent, the attribute describing the Diffie-Hellman group MUST be included in every transform of every proposal of every SA being negotiated. Similarly, if client identities are used, they MUST apply to every SA in the negotiation". It's an in-valid case. thanks, kiran kumar ----- Original Message ----- From: "climbor" To: Sent: Wednesday, September 04, 2002 7:58 AM Subject: Question about KE payload > Hi all, > > Here is my question: > How to construct the KE payload if there are multiple SA in the first Quick message and each SA have different PFS group (say group 1 and group 2)? Construct multiple KE payload too? Or just select the longer one? Or this is just a invalid case (Netscreen support multiple SA with different PFS group, I guest so from its manual)? > > thanks > From owner-ipsec@lists.tislabs.com Thu Sep 5 03:33:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85AX9211620; Thu, 5 Sep 2002 03:33:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA06102 Thu, 5 Sep 2002 05:53:37 -0400 (EDT) Message-ID: <002a01c253fb$b26f4ad0$d2204789@kchundurd01> From: "kiran kumar" To: "climbor" Cc: References: <00ad01c253ba$b6fe0b40$17301bd2@xajump.edu.cn> <001f01c254a0$470a40b0$bc64a8c0@saket> <001701c254c1$0aea8c40$17301bd2@xajump.edu.cn> Subject: Re: Question about KE payload Date: Wed, 4 Sep 2002 15:42:55 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's not a valid case. If you are going to send KE in Quick Mode then the same DH-group must be present in every transform in every proposal in every SA. Even netscreen doesn't allow this configuration. You recheck this. Cheers, kiran kumar ----- Original Message ----- From: "climbor" Cc: Sent: Thursday, September 05, 2002 3:15 PM Subject: Re: Question about KE payload To: "kiran kumar" ; "Saket Dandawate" > Hi, > thanks Saket and kiran. > > Then what about a single SA payload with several proposal? > > HDR*, HASH(1), SA, Ni, > [, KE ] [, IDci, IDcr ] --> > <-- HDR*, HASH(2), SA, Nr, > [, KE ] [, IDci, IDcr ] > HDR*, HASH(3) --> > > 1. ISAKMP header > 2. Hash > 3. -SA payload (SA 0) > -Proposal Payload #1 > -Transform Payload > -Attribute Payloads with Group 1 > -Proposal Payload #2 > -Transform Payload > -Attribute Payloads with Group 2 > -Other Proposal Payload > ...... > 4. KE payload > 5. Identity Payload IDci > 6. Identity Payload IDcr > > Is this case valid? If so how to construct the KE payload? > This question came to me when I read the menu of NetScreen > Firewall. It can be configed like this: > set ike p2-proposal G1 group1 ... > set ike p2-proposal G2 group2 ... > and then, > set vpn VPN gateway SOME_GW proposal G1 G2 ... > then I just wonder how does the NetScreen deal with this case? > > From owner-ipsec@lists.tislabs.com Thu Sep 5 07:50:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85EoZ227502; Thu, 5 Sep 2002 07:50:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06532 Thu, 5 Sep 2002 09:53:17 -0400 (EDT) Message-ID: <001701c254c1$0aea8c40$17301bd2@xajump.edu.cn> From: "climbor" To: "kiran kumar" , "Saket Dandawate" Cc: References: <00ad01c253ba$b6fe0b40$17301bd2@xajump.edu.cn> <001f01c254a0$470a40b0$bc64a8c0@saket> Subject: Re: Question about KE payload Date: Thu, 5 Sep 2002 17:45:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id FAA06039 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, thanks Saket and kiran. Then what about a single SA payload with several proposal? HDR*, HASH(1), SA, Ni, [, KE ] [, IDci, IDcr ] --> <-- HDR*, HASH(2), SA, Nr, [, KE ] [, IDci, IDcr ] HDR*, HASH(3) --> 1. ISAKMP header 2. Hash 3. -SA payload (SA 0) -Proposal Payload #1 -Transform Payload -Attribute Payloads with Group 1 -Proposal Payload #2 -Transform Payload -Attribute Payloads with Group 2 -Other Proposal Payload ...... 4. KE payload 5. Identity Payload IDci 6. Identity Payload IDcr Is this case valid? If so how to construct the KE payload? This question came to me when I read the menu of NetScreen Firewall. It can be configed like this: set ike p2-proposal G1 group1 ... set ike p2-proposal G2 group2 ... and then, set vpn VPN gateway SOME_GW proposal G1 G2 ... then I just wonder how does the NetScreen deal with this case? From owner-ipsec@lists.tislabs.com Thu Sep 5 17:01:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8601ag27357; Thu, 5 Sep 2002 17:01:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07509 Thu, 5 Sep 2002 19:10:25 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40DF2E4BF@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "Housley, Russ" , "Hallam-Baker, Phillip" Cc: ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Thu, 5 Sep 2002 16:26:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree that SHOULD is the right way to go on generation, only I would suggest that at this stage 1024 bits would be an appropriate level for at least. However on the support side I think that implementations that use 128 bit ciphers need to be supporting RSA keys of at least 2048 bits and would say they SHOULD go up to 4096. > > Phill: > > I think the SHOULD is the way to handle the key size issue. > Here is how the S/MIME WG addressed this issue in RFC 2633. > > A user agent SHOULD generate RSA key pairs at a minimum > key size of > 768 bits. A user agent MUST NOT generate RSA key pairs > less than 512 > bits long. Creating keys longer than 1024 bits may cause > some older > S/MIME receiving agents to not be able to verify signatures, but > gives better security and is therefore valuable. A receiving agent > SHOULD be able to verify signatures with keys of any size over 512 > bits. Some agents created in the United States have > chosen to create > 512 bit keys in order to get more advantageous export licenses. > However, 512 bit keys are considered by many to be > cryptographically > insecure. Implementors should be aware that multiple (active) key > pairs may be associated with a single individual. For example, one > key pair may be used to support confidentiality, while a different > key pair may be used for authentication. > From owner-ipsec@lists.tislabs.com Thu Sep 5 20:37:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g863b4k08833; Thu, 5 Sep 2002 20:37:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07870 Thu, 5 Sep 2002 22:53:13 -0400 (EDT) From: "Jayant Shukla" To: , , Subject: RE: IPSec NAT pass-through: how the server distinguish different clients? Date: Thu, 5 Sep 2002 20:04:58 -0700 Message-ID: <00c601c25552$2f3c5ec0$0402a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <89680B404BA1DD419E6D93B28B41899B73B0B3@01mail.nomadix.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Bik, I am not very clear on your explanation. Is it for IPsec with UDP encapsulation or without? If it is for IPsec (without UDP encapsulation), then I do not understand your comment about distinguishing connections based on source port number. The UDP encapsulation draft does not specify the use of ports and lists this issue as one of the problems. Therefore, CISCO's implementation may not be according to the draft. If they are using ports to distinguish the traffic, then there are IPR issues. We have patents pending that cover it. Although we are considering giving up our IPR, we have not done so yet. Regards, Jayant www.trlokom.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of BSingh@Nomadix.com > Sent: Wednesday, September 04, 2002 11:36 AM > To: f_ye@yahoo.com; ipsec@lists.tislabs.com > Subject: RE: IPSec NAT pass-through: how the server distinguish different > clients? > > Feng, > > I have observed that Cisco VPN concentrator distinguishes different > connections coming from the same IP (NAT IP) based on the source port. So > you have to change the IKE source port for different connections coming > from > clients behind the NAT.. Then Cisco recognizes them as different > connections. But I have also observed that this is not reliable and the > connections break as Cisco sends some IKE packets back with destination > port > 500 which the NAT box doesn't know who to forward to.. And even if you > forward to all clients it doesn't really stay on.. > > Best course is to do UDP encapsulation. > > Hope this helps.. > > -Bik > > > -----Original Message----- > > From: Feng Ye [mailto:f_ye@yahoo.com] > > Sent: Wednesday, September 04, 2002 9:30 AM > > To: ipsec@lists.tislabs.com > > Cc: Van Aken Dirk > > Subject: RE: IPSec NAT pass-through: how the server > > distinguish different clients? > > > > > > Thanks for the answer. But what I observed is the > > opposite. I captured all the packets in the server VPN > > side, what I see from the captured packets are: > > 1. When clientA talk with the server, there're ESP > > packets going back and forth with clientA's SPI (say, > > SPI_A) and server's SPI (say, SPI_S). > > 2. Then clientB start to talk with the server, I can > > see there're UDP/500 packets for main mode and quick > > mode. > > 3. Then clientB send ESP with a different SPI (say, > > SPI_B), however, upon receiving SPI_B, the server > > still responds with SPI_S, not a new SPI. So when this > > response packet reached my NAT box, the box has > > associated SPI_S with SPI_A so it forward the packet > > to clientA. This caused the problem. > > > > I think the problem is in server setting, how can the > > server distinguish different clients behind the NAT, > > since for all these clients, the server settings are > > the same: same tunnel destination IP address (the NAT > > public address), same protocol (ESP), same > > encryption/authentication (DES-MD5, etc). > > > > Anybody has a clue? Besides, this is not about UDP > > encapsulation, it's pure ESP packets. > > > > Thanks! > > > > feng > > > > > > --- Van Aken Dirk wrote: > > > Hi Feng, > > > > > > Do I understand you correctly i.e. > > > > > > 1) packets form the clients to the server always use > > > the same SPI value > > > > > > 2) packets from the server to the clients use a > > > different SPI value per > > > client > > > > > > Can you confirm this ? > > > > > > BTW, regarding selection of SPI value it is > > > important to know that the SPI > > > is chosen by the receiving system. > > > i.e If a client wants to receive packets from a > > > server, it is the client > > > that tells the server which SPI value to use. > > > > > > Best regards - Dirk > > > > > > -----Original Message----- > > > From: Feng Ye [mailto:f_ye@yahoo.com] > > > Sent: Wednesday 4 September 2002 6:05 > > > To: ipsec@lists.tislabs.com > > > Subject: IPSec NAT pass-through: how the server side distinguish > > > different client? > > > > > > > > > Hello, > > > > > > I have implemented IPSec NAT pass through in the > > > access box by looking at cookie/SPI values. I can > > > sucessfully do the 1 to 1 and 1 to many cases, but > > > can't do the many to 1 case, because I don't know > > > how > > > to configure the public side VPN server. > > > That server don't know how to distinguish different > > > clients behind the NAT, because they all have the > > > same > > > tunnel endpoint IP address (the NAT public address), > > > and they all use ESP, and the same > > > encrypt/authenticate algorithm. So to the server, > > > all > > > of them belongs to the same SA. Captured packets in > > > the server side shows that even different clients > > > use > > > different SPI to talk to the server, the server > > > responses with the same SPI, thus caused the > > > problem. > > > I tested with cisco 2600 and win2000 as the VPN > > > server, all has the same problem. > > > Is anybody there can give me a clue? Thanks a lot! > > > > > > feng > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com > > From owner-ipsec@lists.tislabs.com Thu Sep 5 23:59:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g866xVk26301; Thu, 5 Sep 2002 23:59:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA08250 Fri, 6 Sep 2002 02:14:43 -0400 (EDT) Date: Fri, 6 Sep 2002 08:29:01 +0200 From: Stefan Schlott To: Andrew Wenlang Zhu Cc: ipsec@lists.tislabs.com Subject: Re: IPSec v6 on linux Message-ID: <20020906062901.GA5066@orca.informatik.uni-ulm.de> References: <15727.44113.263383.84182@pkoning.dev.equallogic.com> <000801c2505f$7b3bff80$6f690d0f@AZ735043> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000801c2505f$7b3bff80$6f690d0f@AZ735043> User-Agent: Mutt/1.3.27i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, > I am use Red hat Linux with kernel 2.4.18. > Does anybody aware any IPsec can support IPV6 on this kernel? As part of my diploma thesis, I implemented some rudimentary IPv6 kernel functionality; Gerhard Gessler adpated the FreeSwan Pluto key exchange daemon for IPv6. The whole package is available on http://www.ipv6.iabg.de/download/index.shtml I haven't tried it lately, so I don't know if the kernel patches will work with 2.4.18 (during development, I used to work with the 2.4.0preX-series; the last kernel patch I created was for 2.4.7). Hope it helps, Stefan. -- *--- please cut here... -------------------------------------- thanks! ---* |-> E-Mail: stefan.schlott@informatik.uni-ulm.de PGP-Key: 0x2F36F4FE <-| | esa$ gcc ariane5.c -Wall -o ariane5 | | ariane5.c: 666: warning: long float implicitly truncated to unsigned | | type | *-------------------------------------------------------------------------* From owner-ipsec@lists.tislabs.com Fri Sep 6 02:43:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g869hkk18320; Fri, 6 Sep 2002 02:43:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08633 Fri, 6 Sep 2002 05:00:06 -0400 (EDT) Message-Id: <3.0.3.32.20020906021247.014bcc08@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 06 Sep 2002 02:12:47 -0700 To: ipsec@lists.tislabs.com From: Alex Alten Subject: It's all over (except for the screaming & shouting). Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The market has finally spoken. IPsec has lost the VPN race. Recently I talked with an number of very senior level people in the IT trenchs. A lot of PC upgrades to XP & Win2K were done to get VPN capability. The OS default is PPTP with 40b DES (MPPE). Not L2TP w/IPsec. I bet many Cisco folks are upset. IPsec will probably hang on in specialized niches like net to net VPNs, etc. What a humbling result. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Sep 6 06:29:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86DTok02592; Fri, 6 Sep 2002 06:29:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08978 Fri, 6 Sep 2002 08:43:42 -0400 (EDT) Date: Fri, 06 Sep 2002 19:13:34 +0900 Message-ID: From: Mitsuru KANDA / =?ISO-2022-JP?B?GyRCP0BFRBsoQiAbJEI9PBsoQg==?= To: Bill Manning Cc: Andrew_zhu@hp.com, ipsec@lists.tislabs.com Subject: Re: IPSec v6 on linux In-Reply-To: <200209050330.g853UqJ06106@boreas.isi.edu> References: <200209050330.g853UqJ06106@boreas.isi.edu> User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At Wed, 4 Sep 2002 20:30:52 -0700 (PDT), Bill Manning wrote: > > % > % Hello, Andrew, > % > % > Does anybody aware any IPsec can support IPV6 on this kernel? > % Please try to use USAGI IPsec (http://www.linux-ipv6.org/) > % > % -mk > % > > I am finding out that the ipsec stuff under USAGI is not compatable with > the FreeSwan work. I hate to have both versions running on/in my > dualstack machines. Can these two activities be harmonized? Or > am I just overlooking something simple? ...Yes, currently usagi and freeswan mostly don't share kernel code. It is difficult to change current klips(fs' kernel stack) to handle both ipv4 and ipv6 in same code base. but usagi try to be careful to keep freeswan's PF_KEY/PF_KEY extention interface. (so pluto/ipv6 runs on usagi stack.) -mk From owner-ipsec@lists.tislabs.com Fri Sep 6 06:29:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86DTok02593; Fri, 6 Sep 2002 06:29:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08984 Fri, 6 Sep 2002 08:44:43 -0400 (EDT) From: "Russell Harrison" Subject: Re: It's all over (except for the screaming & shouting). To: Alex Alten , ipsec@lists.tislabs.com X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Fri, 06 Sep 2002 22:51:10 +1000 Message-ID: In-Reply-To: <3.0.3.32.20020906021247.014bcc08@mail> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, Trolling on working group mailing lists is never appreciated. -RH On Fri, 6 Sep 2002 19:12:47 +1000 Alex Alten wrote: > > The market has finally spoken. IPsec has lost the VPN > race. > > Recently I talked with an number of very senior level > people in the > IT trenchs. A lot of PC upgrades to XP & Win2K were done > to get VPN > capability. The OS default is PPTP with 40b DES (MPPE). > Not L2TP > w/IPsec. I bet many Cisco folks are upset. > > IPsec will probably hang on in specialized niches like > net to net > VPNs, etc. > > What a humbling result. > > - Alex > -- > > Alex Alten > Alten@ATTBI.com > > From owner-ipsec@lists.tislabs.com Fri Sep 6 06:29:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86DTok02591; Fri, 6 Sep 2002 06:29:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08990 Fri, 6 Sep 2002 08:45:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20020905163716.031c33b0@sj-email.cisco.com> X-Sender: brford@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-Priority: 2 (High) Date: Thu, 05 Sep 2002 16:54:40 -0400 To: ipsec@lists.tislabs.com From: Brian Ford Subject: Trouble in IPSec VPN land Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2294158==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_2294158==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >Trouble in VPN land >Meanwhile, the Big Three are becoming frustrated over interoperability >problems with the multivendor VPN gear used on the ANX, a huge privately >run e-commerce network that is mainly for the automotive industry. As has >been the case since the ANX was founded two years ago, the service is only >provided by ISPs that have met strict quality controls approved by >technical staff of ANXeBusiness, a division of SAIC that bought the ANX >from the AIAG a few years ago. Trading partners that want to use ANX, >including those outside the auto industry such as Boeing, must use IP >Security (IPSec)-based VPNs to encrypt data with other ANX trading partners. >However, VPNs have been the sore spot for ANX because it has proven >impossible to get different vendors' VPN gear to work together despite >extensive IPSec equipment testing. Erik Naugle, CTO at ANXeBusiness, >explains: "The standard has enough loopholes [that] you can be compliant >with the specification but not be interoperable." See: http://www.nwfusion.com/news/2002/0902autotech.html?docid=2047 Brian Ford Consulting Engineer Corporate Consulting Engineering, Office of the Chief Technology Officer Cisco Systems, Inc. http://www.cisco.com e-mail: brford@cisco.com --=====================_2294158==_.ALT Content-Type: text/html; charset="us-ascii"

Trouble in VPN land
Meanwhile, the Big Three are becoming frustrated over interoperability problems with the multivendor VPN gear used on the ANX, a huge privately run e-commerce network that is mainly for the automotive industry. As has been the case since the ANX was founded two years ago, the service is only provided by ISPs that have met strict quality controls approved by technical staff of ANXeBusiness, a division of SAIC that bought the ANX from the AIAG a few years ago. Trading partners that want to use ANX, including those outside the auto industry such as Boeing, must use IP Security (IPSec)-based VPNs to encrypt data with other ANX trading partners.
However, VPNs have been the sore spot for ANX because it has proven impossible to get different vendors' VPN gear to work together despite extensive IPSec equipment testing. Erik Naugle, CTO at ANXeBusiness, explains: "The standard has enough loopholes [that] you can be compliant with the specification but not be interoperable."


See: http://www.nwfusion.com/news/2002/0902autotech.html?docid=2047



Brian Ford
Consulting Engineer
Corporate Consulting Engineering, Office of the Chief Technology Officer
Cisco Systems, Inc.
e-mail: brford@cisco.com

--=====================_2294158==_.ALT-- From owner-ipsec@lists.tislabs.com Fri Sep 6 09:35:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86GZBk12269; Fri, 6 Sep 2002 09:35:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09425 Fri, 6 Sep 2002 11:41:14 -0400 (EDT) From: BSingh@Nomadix.com Message-ID: <89680B404BA1DD419E6D93B28B41899B8A656B@01mail.nomadix.com> To: jshukla@trlokom.com, BSingh@Nomadix.com, ipsec@lists.tislabs.com Subject: RE: IPSec NAT pass-through: how the server distinguish different clients? Date: Fri, 6 Sep 2002 08:43:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant, Distinguishing the connections based on source port is for the non-UDP encapsulation case. I have developed and tested IPsec ALG for our NAPT product (USG) and while trying to do connections from multiple clients behind the NAT we found that Cisco required floating of IKE source port otherwise it will lead to termination of the original connection as soon as a new client connected to the same VPN server.. We also found this in Cisco's release notes for the concentrator we were using (3000 series).. Regards, Bik > -----Original Message----- > From: Jayant Shukla [mailto:jshukla@trlokom.com] > Sent: Thursday, September 05, 2002 8:05 PM > To: BSingh@Nomadix.com; f_ye@yahoo.com; ipsec@lists.tislabs.com > Subject: RE: IPSec NAT pass-through: how the server distinguish > different clients? > > > Hi Bik, > > I am not very clear on your explanation. Is it for IPsec with UDP > encapsulation or without? > > If it is for IPsec (without UDP encapsulation), then I do not > understand > your comment about distinguishing connections based on source port > number. > > The UDP encapsulation draft does not specify the use of ports > and lists > this issue as one of the problems. Therefore, CISCO's > implementation may > not be according to the draft. > > If they are using ports to distinguish the traffic, then there are IPR > issues. We have patents pending that cover it. Although we are > considering giving up our IPR, we have not done so yet. > > Regards, > Jayant > www.trlokom.com > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > > On Behalf Of BSingh@Nomadix.com > > Sent: Wednesday, September 04, 2002 11:36 AM > > To: f_ye@yahoo.com; ipsec@lists.tislabs.com > > Subject: RE: IPSec NAT pass-through: how the server distinguish > different > > clients? > > > > Feng, > > > > I have observed that Cisco VPN concentrator distinguishes different > > connections coming from the same IP (NAT IP) based on the > source port. > So > > you have to change the IKE source port for different connections > coming > > from > > clients behind the NAT.. Then Cisco recognizes them as different > > connections. But I have also observed that this is not reliable and > the > > connections break as Cisco sends some IKE packets back with > destination > > port > > 500 which the NAT box doesn't know who to forward to.. And > even if you > > forward to all clients it doesn't really stay on.. > > > > Best course is to do UDP encapsulation. > > > > Hope this helps.. > > > > -Bik > > > > > -----Original Message----- > > > From: Feng Ye [mailto:f_ye@yahoo.com] > > > Sent: Wednesday, September 04, 2002 9:30 AM > > > To: ipsec@lists.tislabs.com > > > Cc: Van Aken Dirk > > > Subject: RE: IPSec NAT pass-through: how the server > > > distinguish different clients? > > > > > > > > > Thanks for the answer. But what I observed is the > > > opposite. I captured all the packets in the server VPN > > > side, what I see from the captured packets are: > > > 1. When clientA talk with the server, there're ESP > > > packets going back and forth with clientA's SPI (say, > > > SPI_A) and server's SPI (say, SPI_S). > > > 2. Then clientB start to talk with the server, I can > > > see there're UDP/500 packets for main mode and quick > > > mode. > > > 3. Then clientB send ESP with a different SPI (say, > > > SPI_B), however, upon receiving SPI_B, the server > > > still responds with SPI_S, not a new SPI. So when this > > > response packet reached my NAT box, the box has > > > associated SPI_S with SPI_A so it forward the packet > > > to clientA. This caused the problem. > > > > > > I think the problem is in server setting, how can the > > > server distinguish different clients behind the NAT, > > > since for all these clients, the server settings are > > > the same: same tunnel destination IP address (the NAT > > > public address), same protocol (ESP), same > > > encryption/authentication (DES-MD5, etc). > > > > > > Anybody has a clue? Besides, this is not about UDP > > > encapsulation, it's pure ESP packets. > > > > > > Thanks! > > > > > > feng > > > > > > > > > --- Van Aken Dirk wrote: > > > > Hi Feng, > > > > > > > > Do I understand you correctly i.e. > > > > > > > > 1) packets form the clients to the server always use > > > > the same SPI value > > > > > > > > 2) packets from the server to the clients use a > > > > different SPI value per > > > > client > > > > > > > > Can you confirm this ? > > > > > > > > BTW, regarding selection of SPI value it is > > > > important to know that the SPI > > > > is chosen by the receiving system. > > > > i.e If a client wants to receive packets from a > > > > server, it is the client > > > > that tells the server which SPI value to use. > > > > > > > > Best regards - Dirk > > > > > > > > -----Original Message----- > > > > From: Feng Ye [mailto:f_ye@yahoo.com] > > > > Sent: Wednesday 4 September 2002 6:05 > > > > To: ipsec@lists.tislabs.com > > > > Subject: IPSec NAT pass-through: how the server side distinguish > > > > different client? > > > > > > > > > > > > Hello, > > > > > > > > I have implemented IPSec NAT pass through in the > > > > access box by looking at cookie/SPI values. I can > > > > sucessfully do the 1 to 1 and 1 to many cases, but > > > > can't do the many to 1 case, because I don't know > > > > how > > > > to configure the public side VPN server. > > > > That server don't know how to distinguish different > > > > clients behind the NAT, because they all have the > > > > same > > > > tunnel endpoint IP address (the NAT public address), > > > > and they all use ESP, and the same > > > > encrypt/authenticate algorithm. So to the server, > > > > all > > > > of them belongs to the same SA. Captured packets in > > > > the server side shows that even different clients > > > > use > > > > different SPI to talk to the server, the server > > > > responses with the same SPI, thus caused the > > > > problem. > > > > I tested with cisco 2600 and win2000 as the VPN > > > > server, all has the same problem. > > > > Is anybody there can give me a clue? Thanks a lot! > > > > > > > > feng > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > > > > > From owner-ipsec@lists.tislabs.com Fri Sep 6 10:24:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86HOqk15995; Fri, 6 Sep 2002 10:24:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09520 Fri, 6 Sep 2002 12:37:36 -0400 (EDT) Message-ID: From: "Lordello, Claudio" To: "'Alex Alten'" , ipsec@lists.tislabs.com Cc: "Lordello, Claudio" Subject: RE: It's all over (except for the screaming & shouting). Date: Fri, 6 Sep 2002 09:41:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From what I have observed in a client 2K or XP, when one creates a new VPN connection, the default network protocol is "Automatic" which works for either PPTP or L2TP/IPsec. Unless one overrides that in the client to specifically pick one or the other, which one is actually negotiated will depend on the server one is dialing into. So I am not sure what you mean by "the OS default is PPTP with 40b DES". Could you please clarify. Claudio. -----Original Message----- From: Alex Alten [mailto:Alten@attbi.com] Sent: Friday, September 06, 2002 5:13 AM To: ipsec@lists.tislabs.com Subject: It's all over (except for the screaming & shouting). The market has finally spoken. IPsec has lost the VPN race. Recently I talked with an number of very senior level people in the IT trenchs. A lot of PC upgrades to XP & Win2K were done to get VPN capability. The OS default is PPTP with 40b DES (MPPE). Not L2TP w/IPsec. I bet many Cisco folks are upset. IPsec will probably hang on in specialized niches like net to net VPNs, etc. What a humbling result. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Sep 6 13:00:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86K0bk22794; Fri, 6 Sep 2002 13:00:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09923 Fri, 6 Sep 2002 15:11:51 -0400 (EDT) From: "Russell Harrison" Subject: Re: It's all over (except for the screaming & shouting). To: "Lordello, Claudio" , "'Alex Alten'" , ipsec@lists.tislabs.com Cc: "Lordello, Claudio" X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Sat, 07 Sep 2002 04:54:27 +1000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk More importantly, how is this relevant? Irrespective of the validity of Alten's claims, he has backed his arguments with nothing more than heresay. In the case that his claims were valid, it is still irrelevant from the perspective of this working group. May this thread end here. -RH On Fri, 6 Sep 2002 23:41:56 +1000 "Lordello, Claudio" wrote: > >From what I have observed in a client 2K or XP, when one > creates a new VPN > connection, the default network protocol is "Automatic" > which works for > either PPTP or L2TP/IPsec. Unless one overrides that in > the client to > specifically pick one or the other, which one is actually > negotiated will > depend on the server one is dialing into. So I am not > sure what you mean by > "the OS default is PPTP with 40b DES". Could you please > clarify. > > Claudio. > > -----Original Message----- > From: Alex Alten [mailto:Alten@attbi.com] > Sent: Friday, September 06, 2002 5:13 AM > To: ipsec@lists.tislabs.com > Subject: It's all over (except for the screaming & > shouting). > > > > The market has finally spoken. IPsec has lost the VPN > race. > > Recently I talked with an number of very senior level > people in the > IT trenchs. A lot of PC upgrades to XP & Win2K were done > to get VPN > capability. The OS default is PPTP with 40b DES (MPPE). > Not L2TP > w/IPsec. I bet many Cisco folks are upset. > > IPsec will probably hang on in specialized niches like > net to net > VPNs, etc. > > What a humbling result. > > - Alex > -- > > Alex Alten > Alten@ATTBI.com > > > NOTICE: This e-mail and any files transmitted with it are > confidential and > are only for the use of the person to whom they are > addressed. If you are > not the intended recipient you have received this e-mail > in error. Any use, > dissemination, forwarding, printing, copying or dealing > in any way > whatsoever with this e-mail is strictly prohibited. If > you have received > this e-mail in error, please reply immediately by way of > advice to us. It is > the addressee's - recipient's duty to virus scan and > otherwise test the > information provided before loading onto any computer > system. Zento does > not warrant that the information is free of a virus or > any other defect or > error. Any views expressed in this message are those of > the individual > sender, except where the sender specifically states them > to be the views of > Zento. > > From owner-ipsec@lists.tislabs.com Sun Sep 8 16:04:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g88N4Uk11656; Sun, 8 Sep 2002 16:04:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13224 Sun, 8 Sep 2002 17:55:49 -0400 (EDT) Message-Id: <3.0.3.32.20020908150811.0133c1c8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 08 Sep 2002 15:08:11 -0700 To: "Lordello, Claudio" , ipsec@lists.tislabs.com From: Alex Alten Subject: RE: It's all over (except for the screaming & shouting). Cc: "Lordello, Claudio" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe L2TP needs a cert and PPTP does not. That's a significant advantage for PPTP. - Alex At 09:41 AM 9/6/2002 -0400, Lordello, Claudio wrote: >>From what I have observed in a client 2K or XP, when one creates a new VPN >connection, the default network protocol is "Automatic" which works for >either PPTP or L2TP/IPsec. Unless one overrides that in the client to >specifically pick one or the other, which one is actually negotiated will >depend on the server one is dialing into. So I am not sure what you mean by >"the OS default is PPTP with 40b DES". Could you please clarify. > >Claudio. > >-----Original Message----- >From: Alex Alten [mailto:Alten@attbi.com] >Sent: Friday, September 06, 2002 5:13 AM >To: ipsec@lists.tislabs.com >Subject: It's all over (except for the screaming & shouting). > > > >The market has finally spoken. IPsec has lost the VPN race. > >Recently I talked with an number of very senior level people in the >IT trenchs. A lot of PC upgrades to XP & Win2K were done to get VPN >capability. The OS default is PPTP with 40b DES (MPPE). Not L2TP >w/IPsec. I bet many Cisco folks are upset. > >IPsec will probably hang on in specialized niches like net to net >VPNs, etc. > >What a humbling result. > >- Alex >-- > >Alex Alten >Alten@ATTBI.com > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Tue Sep 10 07:40:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8AEehk29465; Tue, 10 Sep 2002 07:40:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16526 Tue, 10 Sep 2002 09:38:27 -0400 (EDT) Message-Id: <200209101352.g8ADqt6o077500@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Cc: Jari Arkko Subject: quick mode "proxy" case Date: Tue, 10 Sep 2002 15:52:55 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC 2409 specifies: The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. In order to make the discussion clearer I propose this terminology: - for these phase 2 identities: "traffic selectors" - for the case where the initiator acts on behalf of another party: the "proxy" case - for the "local policy" requirement: "authorization". The question is: [how] do you implement the "proxy" case for transport mode? (please provide the interesting details!) Regards Francis.Dupont@enst-bretagne.fr PS: a better wording for the SOI should be wellcome (as I am afraid this is rarely implemented because not understood or not understable by users). From owner-ipsec@lists.tislabs.com Tue Sep 10 22:13:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8B5DIk16702; Tue, 10 Sep 2002 22:13:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17831 Wed, 11 Sep 2002 00:11:34 -0400 (EDT) Message-ID: <002901c2594b$827ffb80$bc64a8c0@saket> From: "Saket Dandawate" To: "Francis Dupont" , Cc: "Jari Arkko" References: <200209101352.g8ADqt6o077500@givry.rennes.enst-bretagne.fr> Subject: Re: quick mode "proxy" case Date: Wed, 11 Sep 2002 09:57:16 +0530 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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Francis, To add to ur question can anybody tell me how do we specify address range, say IPV4addressrange in proxy mode using identity payloads. Also what i couldnt understand was, are u interested in IKE or IPsec role. Since IKE doesnt care whether its Tunnel or transport. It just exchanges the attributes and IDi,IDr. Local policies in IPsec does the rest Regards Saket. ----- Original Message ----- From: "Francis Dupont" To: Cc: "Jari Arkko" Sent: Tuesday, September 10, 2002 7:22 PM Subject: quick mode "proxy" case > RFC 2409 specifies: > > The identities of the SAs negotiated in Quick Mode are implicitly > assumed to be the IP addresses of the ISAKMP peers, without any > implied constraints on the protocol or port numbers allowed, unless > client identifiers are specified in Quick Mode. If ISAKMP is acting > as a client negotiator on behalf of another party, the identities of > the parties MUST be passed as IDci and then IDcr. Local policy will > dictate whether the proposals are acceptable for the identities > specified. If the client identities are not acceptable to the Quick > Mode responder (due to policy or other reasons), a Notify payload > with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. > > In order to make the discussion clearer I propose this terminology: > - for these phase 2 identities: "traffic selectors" > - for the case where the initiator acts on behalf of another party: > the "proxy" case > - for the "local policy" requirement: "authorization". > > The question is: [how] do you implement the "proxy" case for > transport mode? (please provide the interesting details!) > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: a better wording for the SOI should be wellcome (as I am afraid > this is rarely implemented because not understood or not understable > by users). From owner-ipsec@lists.tislabs.com Wed Sep 11 00:28:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8B7SXk04265; Wed, 11 Sep 2002 00:28:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18197 Wed, 11 Sep 2002 02:41:04 -0400 (EDT) Message-Id: <200209110655.g8B6tg6o079680@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Saket Dandawate" cc: ipsec@lists.tislabs.com, "Jari Arkko" Subject: Re: quick mode "proxy" case In-reply-to: Your message of Wed, 11 Sep 2002 09:57:16 +0530. <002901c2594b$827ffb80$bc64a8c0@saket> Date: Wed, 11 Sep 2002 08:55:42 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: To add to ur question can anybody tell me how do we specify address range, say IPV4addressrange in proxy mode using identity payloads. => in the case I am interested to the only possible identity types are ID_IPV4_ADDR and ID_IPV6_ADDR (names are at least complex/ambiguous and subnets/ranges don't fit with transport mode). Also what i couldnt understand was, are u interested in IKE or IPsec role. Since IKE doesnt care whether its Tunnel or transport. It just exchanges the attributes and IDi,IDr. Local policies in IPsec does the rest => local policies are not a second order detail in the "proxy" case. But we can look at the case where more than one SA is negociated in a quick/phase 2 exchange... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Sep 11 07:25:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BEPfk12060; Wed, 11 Sep 2002 07:25:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19011 Wed, 11 Sep 2002 09:32:15 -0400 (EDT) Date: Tue, 10 Sep 2002 21:54:41 +0800 (SGT) From: Parijat Mishra X-X-Sender: parijat@lothlorien.ipv6.icr.a-star.edu.sg To: Stefan Schlott Cc: Andrew Wenlang Zhu , Subject: Re: IPSec v6 on linux In-Reply-To: <20020906062901.GA5066@orca.informatik.uni-ulm.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I upgraded the Stephan/IABG code to work with kernel 2.4.16. It will work with kernel 2.4.18 if you are not afraid of some minor hand-patching. You can download it from: http://www.icr.a-star.edu.sg/~parijat.swamp/downloads/freeswan-1.96-ipv6-upd.tar.gz Uuse the second download, without MIPL; the version integrated with MIPL is (terribly) buggy. On Fri, 6 Sep 2002, Stefan Schlott wrote: > Hi, > > > I am use Red hat Linux with kernel 2.4.18. > > Does anybody aware any IPsec can support IPV6 on this kernel? > As part of my diploma thesis, I implemented some rudimentary IPv6 kernel > functionality; Gerhard Gessler adpated the FreeSwan Pluto key exchange > daemon for IPv6. The whole package is available on > http://www.ipv6.iabg.de/download/index.shtml > > I haven't tried it lately, so I don't know if the kernel patches will work > with 2.4.18 (during development, I used to work with the 2.4.0preX-series; > the last kernel patch I created was for 2.4.7). > > Hope it helps, > Stefan. > > -- Sincerely, Parijat Mishra R & D Engineer, Institute for Communications Research Tel: (65)68709353 From owner-ipsec@lists.tislabs.com Wed Sep 11 13:06:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8BK69k01491; Wed, 11 Sep 2002 13:06:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19534 Wed, 11 Sep 2002 15:06:42 -0400 (EDT) Message-ID: <3D7F9AC4.BA117036@docomolabs-usa.com> Date: Wed, 11 Sep 2002 12:34:28 -0700 From: Pars Mutaf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: security policy discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I've a question about IPsec and I'm not sure IPSP is the answer, therefore I'm asking it in this list. I assume Alice and Bob don't know each other, so they have no security association. Alice doesn't care about security, but Bob cares.. Alice sends a packet to Bob for the first time. It is not an IKE, JKF packet. It is the actual packet of a session (e.g. TCP SYN). Bob doesn't want to communicate unless a security association is established. What happens in this case? Bob replies with IKE/JFK? Or Alice detects Bob's security policy before attempting to communicate? Thank you in advance. And sorry if it is a too basic question or this is not really in the scope of this WG... Regards, pars From owner-ipsec@lists.tislabs.com Thu Sep 12 14:22:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CLMok25457; Thu, 12 Sep 2002 14:22:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21926 Thu, 12 Sep 2002 16:27:13 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3D7F9AC4.BA117036@docomolabs-usa.com> Subject: Re: security policy discovery To: Pars Mutaf Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002 Message-ID: Date: Thu, 12 Sep 2002 16:40:44 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09042002ANP|September 04, 2002) at 09/12/2002 04:35:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I've a question about IPsec and I'm not sure IPSP > is the answer, therefore I'm asking it in this list. > > I assume Alice and Bob don't know each other, so > they have no security association. Alice doesn't care > about security, but Bob cares.. > I don't believe IPsec explicitly addresses this case, in the sense of saying what endpoints MUST do in some interoperable sense. Many people have asked for "opportunistic encryption" where sessions are encrypted if the endpoints discover they are capable of doing so, but I don't believe that is specified anywhere either. Both of these things *could* be done in a way that follows the spec; it's just that the spec doesn't say how. > Alice sends a packet to Bob for the first time. It is not > an IKE, JKF packet. It is the actual packet of a session > (e.g. TCP SYN). > > Bob doesn't want to communicate unless a security > association is established. > I believe that the IPsec architecture does not envision this configuration. I believe it assumes that the initiator decides whether a protected channel should be established. In this case, Bob would drop the packet. If Alice is capable of speaking ESP if Bob wants to do so, Alice should attempt it before sending the first packet. One could imagine, however, Bob seeing the unprotected packet and letting that trigger an IKE SA setup. The initial TCP SYN would be dropped, but if it was still being retried when the ESP SA comes up, Alice would send one of the retried packets inside the ESP SA and the conversation would ensue. Alternately, one could imagine Bob passing on a limited class of packets (like TCP SYN) and letting the response packet trigger the setup of the ESP SA. > What happens in this case? Bob replies with IKE/JFK? > Or Alice detects Bob's security policy before attempting > to communicate? I believe there is no defined security policy discovery protocol. There may be a defined ICMP response to the dropped packet indicating that IPsec was needed (which could trigger Alice's initiating an SA). --Charlie Kaufman Opinions expressed may not even by mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Thu Sep 12 16:42:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CNgSk02976; Thu, 12 Sep 2002 16:42:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22184 Thu, 12 Sep 2002 18:54:15 -0400 (EDT) Date: Thu, 12 Sep 2002 16:08:08 -0700 (PDT) From: Jan Vilhuber To: cc: Pars Mutaf , , Subject: Re: security policy discovery In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Sep 2002 Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > > > I've a question about IPsec and I'm not sure IPSP > > is the answer, therefore I'm asking it in this list. > > > > I assume Alice and Bob don't know each other, so > > they have no security association. Alice doesn't care > > about security, but Bob cares.. > > > I don't believe IPsec explicitly addresses this case, > in the sense of saying what endpoints MUST do in some > interoperable sense. Many people have asked for > "opportunistic encryption" where sessions are encrypted > if the endpoints discover they are capable of doing so, > but I don't believe that is specified anywhere either. > http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-10.txt > Both of these things *could* be done in a way that > follows the spec; it's just that the spec doesn't say > how. > > > Alice sends a packet to Bob for the first time. It is not > > an IKE, JKF packet. It is the actual packet of a session > > (e.g. TCP SYN). > > > > Bob doesn't want to communicate unless a security > > association is established. > > > I believe that the IPsec architecture does not > envision this configuration. I believe it assumes > that the initiator decides whether a protected > channel should be established. In this case, Bob > would drop the packet. If Alice is capable of speaking > ESP if Bob wants to do so, Alice should attempt it > before sending the first packet. > > One could imagine, however, Bob seeing the unprotected > packet and letting that trigger an IKE SA setup. The > initial TCP SYN would be dropped, but if it was still > being retried when the ESP SA comes up, Alice would send > one of the retried packets inside the ESP SA and the > conversation would ensue. Alternately, one could > imagine Bob passing on a limited class of packets (like > TCP SYN) and letting the response packet trigger the > setup of the ESP SA. > > > What happens in this case? Bob replies with IKE/JFK? > > Or Alice detects Bob's security policy before attempting > > to communicate? > > I believe there is no defined security policy > discovery protocol. Ages ago, IPSP defined SPP (which I've yet to read): http://www.ietf.org/internet-drafts/draft-ietf-ipsp-spp-01.txt Scott Fluhrer recently (salt lake city? minneapolis?) presented TED (Tunnel Endpoint Discovery). Sadly, that draft is now expired. I've been thinking of adding some stuff and resubmitting this, if there's sufficient interest. When we presented this, quite a few people seemed interest. But, as seems normal for IPSP, things petered out and were never heard from again... SPP was resubmitted as a result of Scott presenting TED. jan > There may be a defined ICMP response > to the dropped packet indicating that IPsec was > needed (which could trigger Alice's initiating an > SA). > > > --Charlie Kaufman > > Opinions expressed may not even by mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Sep 12 16:55:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8CNtfk03290; Thu, 12 Sep 2002 16:55:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22268 Thu, 12 Sep 2002 19:17:24 -0400 (EDT) Date: Thu, 12 Sep 2002 17:29:54 -0600 Message-Id: <200209122329.g8CNTsF14324@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: Charlie_Kaufman@notesdev.ibm.com Cc: mutaf@docomolabs-usa.com, ipsec@lists.tislabs.com In-reply-to: Yourmessage Subject: Re: security policy discovery Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At one time there was a vision of the future in which the majority of network traffic would have cryptographic protection, so the default behavior would be to negotiate IPSec SA's, falling back to plaintext, perhaps, if there was no solution. IPSP has been trying to address security policy discovery, but not as an automatic side effect of a cleartext communication attempt. That's because in the Alice-Bob case, Bob might never see Alice's unprotected packet - it would be caught and discarded by earlier protection devices in Bob's network. IPSP tries to address the problem of discovering the security gateways trying to find a negotiable set of SA's that will cover the Alice/Bob traffic, but only in the case that Alice or Bob has already made a decison to setup IPSec. If in response to a plaintext packet something emanating from the Bobside declares "Alice-Bob requires IPSec", then Alice can take that as a signal initiate some key exchange/IPsec negotiation protcol. But, given that Alice has expressed a willingness to communicate without crypto protection, one might suspect her committment to confidentiality to be half-hearted. Hilarie From owner-ipsec@lists.tislabs.com Thu Sep 12 20:17:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8D3HCk16490; Thu, 12 Sep 2002 20:17:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22719 Thu, 12 Sep 2002 22:29:31 -0400 (EDT) From: "Satyadeva Konduru" To: , "'Pars Mutaf'" Cc: , Subject: RE: security policy discovery Date: Thu, 12 Sep 2002 19:44:34 -0700 Message-ID: <005701c25acf$7eafdd60$3e00010a@caymas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > One could imagine, however, Bob seeing the unprotected > packet and letting that trigger an IKE SA setup. The > initial TCP SYN would be dropped, but if it was still > being retried when the ESP SA comes up, Alice would send > one of the retried packets inside the ESP SA and the > conversation would ensue. Alternately, one could > imagine Bob passing on a limited class of packets (like > TCP SYN) and letting the response packet trigger the > setup of the ESP SA. In this scenario, is there not a problem of spoofed packets unnecessarily setting up tunnels between Bob and Alice. Each think that the other side needs a tunnel to send traffic. This could become a denial of service attack, especially if the lifetimes are small, since both Bob and Alice will keep setting up tunnels and thus make the setup of genuine tunnels slow. -Satyadeva Konduru Caymas Systems Inc. From owner-ipsec@lists.tislabs.com Thu Sep 12 21:00:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8D40lk17679; Thu, 12 Sep 2002 21:00:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA22864 Thu, 12 Sep 2002 23:20:40 -0400 (EDT) Date: Thu, 12 Sep 2002 23:34:54 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: security policy discovery In-Reply-To: <005701c25acf$7eafdd60$3e00010a@caymas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Sep 2002, Satyadeva Konduru wrote: > In this scenario, is there not a problem of spoofed packets > unnecessarily setting up tunnels between Bob and Alice. Each think that > the other side needs a tunnel to send traffic. This could become a > denial of service attack, especially if the lifetimes are small, since > both Bob and Alice will keep setting up tunnels and thus make the setup > of genuine tunnels slow. Bob and Alice would be well advised to adaptively adjust the lifetime of the tunnels they set up, so that if they are starting to burn significant numbers of cycles setting up and tearing down tunnels to the same place, they lengthen the tunnel life to reduce the overhead. (Keeping a tunnel open costs essentially nothing, at least not until rekeying time.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Sep 13 14:34:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8DLYAk15649; Fri, 13 Sep 2002 14:34:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24805 Fri, 13 Sep 2002 16:25:56 -0400 (EDT) Date: Fri, 13 Sep 2002 13:39:36 -0700 (PDT) From: Jan Vilhuber To: Henry Spencer cc: IP Security List Subject: RE: security policy discovery In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Sep 2002, Henry Spencer wrote: > On Thu, 12 Sep 2002, Satyadeva Konduru wrote: > > In this scenario, is there not a problem of spoofed packets > > unnecessarily setting up tunnels between Bob and Alice. Each think that > > the other side needs a tunnel to send traffic. This could become a > > denial of service attack, especially if the lifetimes are small, since > > both Bob and Alice will keep setting up tunnels and thus make the setup > > of genuine tunnels slow. > > Bob and Alice would be well advised to adaptively adjust the lifetime of > the tunnels they set up, so that if they are starting to burn significant > numbers of cycles setting up and tearing down tunnels to the same place, > they lengthen the tunnel life to reduce the overhead. (Keeping a tunnel > open costs essentially nothing, at least not until rekeying time.) > That's true for end-hosts only. The memory and resources (crypto slots for example) used when terminating on a concentrator shouldn't be ignored so lightly. That's not to say we need to make a great big fuss about it either. Just don't ignore seemingly trivial costs, because in aggregation they can add up. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Mon Sep 16 18:15:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H1Fqk11412; Mon, 16 Sep 2002 18:15:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00408 Mon, 16 Sep 2002 20:28:29 -0400 (EDT) Date: Mon, 16 Sep 2002 17:27:28 -0700 (PDT) From: Jan Vilhuber To: Subject: Merging IKEv2 and JFKr? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Or "How to dress up Frankenstein to look presentable". I'm wondering about the wisdom of merging IKEv2 with JFK'isms. Seeing that I haven't read the revised IKEv2+JFK proposal (because it's not out yet), this is mostly based on my thoughts of what *I* would do, were I to merge the two. I expect there's not that many ways to skin this cat. Firstly, it doesn't seem needed. The difference is that JFK assumes it's ALWAYS under attack, versus IKEv2 that gives you a mechanism to verify the initiator's 'liveness' if you think you're under attack. So it's not like IKEv2 doesn't address DoS issues. It does. Code messiness. You may poo-poo that concept, but we all understand IKE code and the coding-/design- philosophy behind it. You may not like it, but there's a certain amount of expertise out there. By adding JFK'isms into the mix, you're now mixing two very different philosophies into one protocol, which sounds like it's prone to be buggy, hard to analyze, etc etc. Instead of a protocol designed by a committee, we now have a protocol designed by TWO committees. Along the same lines (or maybe 'by example'), IKE has always been 'encrypted packet' or 'non encrypted packet'. Now we have a 'half-encrypted' packet. Sigh. If someone has a clean way of doing this (An 'encrypted payload' similar to Kink's KINK_ENCRYPT payload (section 5.1.8 of the kink draft, FWIW) maybe?), maybe this can be made to work, if absolutely necessary. Extensibility: I keep thinking that prior to the SOI discussions, we had talked about simplifying IKEv1 hashing, so that ALL payloads are hashed and authenticated, no matter what they were. That has clear implications to extensibility, i.e. future payloads. I realize one of JFK's goals was 'non-extensibility', but I thought I saw rough consensus towards extensibility during the recent chinese-menu mails... Now by merging JFKr into IKEv2, we complicate the hashing mechanism again to the point where we have to think about which payloads can be part of the hash and which can't (also, which payloads must be repeated and which mustn't or don't need to). Legacy Authentication: This is really a subset of "extensibility". I'm trying to fit some legacy authentication scheme into IKEv2, and I have some ideas. Trying to fit them into an IKEv2+JFK protocol (assuming what's in my mind is similar to what Charlie is working on) makes it that much harder. Packet sizes: By repeating msg1 in msg3, msg3 necessarily gets larger. William kept trying to get people to realize that we have a UDP fragmentation issue, when certs (or cert chains) are sent, so this seems like a move in the wrong direction. Paul Hoffman had some ideas of changing the ID payload so that it can include a URL, i.e. pointer to the cert instead of the cert itself, and that may help. Based on my gut feeling, I vote to leave IKEv2 as is, rather than grafting JFK'isms onto IKEv2. If it gave us something we can't live without, I wouldn't have that much of an issue with it, but I don't see a very good reason to do it (the cost outweighs the gain). Flame away. "Me too's" or "Ditto's" highly encouraged. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Mon Sep 16 22:45:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H5jGk24437; Mon, 16 Sep 2002 22:45:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA00924 Tue, 17 Sep 2002 01:16:31 -0400 (EDT) Message-ID: <002c01c25e09$950d0410$bc64a8c0@saket> From: "Saket Dandawate" To: Subject: Notification payload in IKE Date: Tue, 17 Sep 2002 10:47:56 +0530 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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk HI All, Notification Payload is used only to notify the other peer what went wrong. But the field Notification Data is present. My questions? 1. Or is it necessary to send notification Data? 2. how do we send notification data? Any Standard way since rfc 2409 doesn't speak on any particular format to be followed for sending Notification Data? Regards Saket From owner-ipsec@lists.tislabs.com Tue Sep 17 00:24:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H7OSk09343; Tue, 17 Sep 2002 00:24:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01132 Tue, 17 Sep 2002 02:47:48 -0400 (EDT) X-Originating-IP: [217.29.140.5] From: "Mohammad Awad" To: ipsec@lists.tislabs.com Subject: How the responder know the selectors Date: Tue, 17 Sep 2002 09:46:57 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Sep 2002 06:46:58.0661 (UTC) FILETIME=[0509B950:01C25E16] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've a question plz. Now Alice wants to send to Bob a packet (say (tcp 88==>21)). Both support and require IPsec. Alice's IPsec module will prevent the packet transmission and commence negotiating IKE with Bob beginning with the SA payload. How does Bob, now, know the original packet that was tended to be sent (say (tcp 88==>21)) to decide on which SA should he negotiate, given that the security services proposed depend on the selectors of the packet. Thanx _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ipsec@lists.tislabs.com Tue Sep 17 08:51:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HFp7k22414; Tue, 17 Sep 2002 08:51:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02095 Tue, 17 Sep 2002 11:08:27 -0400 (EDT) Date: Tue, 17 Sep 2002 11:06:58 -0400 (EDT) From: Henry Spencer To: Mohammad Awad cc: ipsec@lists.tislabs.com Subject: Re: How the responder know the selectors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 17 Sep 2002, Mohammad Awad wrote: > Alice's IPsec module will prevent the packet transmission and commence > negotiating IKE with Bob beginning with the SA payload. How does Bob, now, > know the original packet that was tended to be sent (say (tcp 88==>21)) to > decide on which SA should he negotiate, given that the security services > proposed depend on the selectors of the packet. Without prearrangement, he doesn't know anything except what Alice sent as part of negotiations. So if this sort of scheme is to work, he must be willing to negotiate a general-purpose set of security services without knowing exactly what traffic will be sent. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Sep 17 11:56:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HIupk03246; Tue, 17 Sep 2002 11:56:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02384 Tue, 17 Sep 2002 14:17:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 17 Sep 2002 11:17:00 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Merging IKEv2 and JFKr? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan is correct here. JFKr was designed without extensibility in mind, particularly in that you have to be very careful about the contents of the unencrypted and encrypted parts of messages 3 and 4. We won't really know until Charlie delivers the first IKEv2 draft with the JFKr'd Phase 1, but it is likely to be much less extensible than the original IKEv2. It will certainly be harder for implementers to get messages 3 and 4 correct. The WG straw poll didn't show a strong majority favoring either proposal. Approximately equal numbers of people said: - the original IKEv2 Phase 1 was best - JFKr was better because the responder could always assume he was under attack The latter arguments aren't consistent because the same thing is true for the original IKEv2. In the original IKEv2, the "difficulty" for an initiator to choose what to do when receiving message 3 is pretty minor. If the encrypt bit is not turned on, resend with the nonce; if the encrypt bit is turned on, continue on as normal. It would be sad if we ended up restricting ourselves to a hard-to-extend IKEv2. The minor "difficulty" in the original IKEv2 proposal is certainly worth the much lower difficulty in extending the protocol for things that this WG wants, such as standardized legacy authentication and remote access. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Sep 17 12:14:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HJENk03784; Tue, 17 Sep 2002 12:14:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02422 Tue, 17 Sep 2002 14:43:42 -0400 (EDT) Message-Id: <4.3.2.7.1.20020917114002.00ae31a0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 11:41:08 -0700 To: "Mohammad Awad" , ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Re: How the responder know the selectors In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Look at the ID payload, that might help you to undestnad the issue -cheers -ramana >I've a question plz. >Now Alice wants to send to Bob a packet (say (tcp 88==>21)). Both support >and require IPsec. >Alice's IPsec module will prevent the packet transmission and commence >negotiating IKE with Bob beginning with the SA payload. How does Bob, now, >know the original packet that was tended to be sent (say (tcp 88==>21)) to >decide on which SA should he negotiate, given that the security services >proposed depend on the selectors of the packet. >Thanx From owner-ipsec@lists.tislabs.com Tue Sep 17 12:57:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HJvdk04632; Tue, 17 Sep 2002 12:57:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02589 Tue, 17 Sep 2002 15:18:16 -0400 (EDT) Message-ID: <3D877FD9.F3458445@lucent.com> Date: Tue, 17 Sep 2002 15:17:45 -0400 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Merging IKEv2 and JFKr? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote: > Jan is correct here. Ditto - me too. From owner-ipsec@lists.tislabs.com Tue Sep 17 13:29:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HKTxk05984; Tue, 17 Sep 2002 13:29:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02647 Tue, 17 Sep 2002 15:38:45 -0400 (EDT) Message-Id: <200209171937.g8HJbt824243@sydney.East.Sun.COM> Date: Tue, 17 Sep 2002 15:37:55 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Regarding pre-round trip for stateless cookie (Jan's issue) To: ipsec@lists.tislabs.com, vilhuber@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RY453Fu/IS67UFNJ3dL/0A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re: From: Jan Vilhuber I'm wondering about the wisdom of merging IKEv2 with JFK'isms. Seeing that I haven't read the revised IKEv2+JFK proposal (because it's not out yet), this is mostly based on my thoughts of what *I* would do, were I to merge the two. I expect there's not that many ways to skin this cat. First a nontechnical point...I've changed the subject line because I think it's always better to focus on a particular technical detail rather than which spec something might have come from. At this point there are not n candidate proposals with n sets of authors, but instead a single draft that all the authors of all the drafts, and actually, everyone in the WG, is collaborating on. Everyone wants something that is correct, reasonably simple, and reflects as close as can be measured, the feelings of the WG. Back to the technical issue Jan raised, which I'll call "4/6 vs 4", where "4/6" means letting Bob, if he wants to do stateless cookies, request an optional round trip before the 4-message exchange. In the greater scheme of things, I don't think this issue matters all that much, but I've changed my mind about this recently and it would be good if the WG could weigh in, if people (especially implementers) have strong opinions. The summary is that I originally believed in "4", but now that I've helped work out the details of "4", at this point I agree with you, Jan, that "4/6" seems simpler, but I also don't think it's all that important and can live with either way. I'd been arguing about this very point with my original coauthors Dan Harkins and Charlie Kaufman since before our first draft. I wanted 4, they wanted 4/6. They were not able to explain to me very eloquently at the time why they wanted to do 4/6. It seemed to me that the WG would think a 4 message exchange would be preferable to a (4, sometimes 6) message exchange. At first Dan and Charlie just told me that it would be "a pain in the neck". And when I pressed for more details they used some of your arguments, like "half the message encrypted, half unencrypted", which didn't seem to me like it should be all that much of a hassle. Then Charlie brought up the fragmentation attack, and I was convinced that the 4/6 method was better, because it keeps all messages small until the stateless cookie has been returned, so that one could build an implementation that saved reassembly resources for IP addresses that have returned stateless cookies. It was probably me that suggested, though, in order to look more like a "merged" proposal, that we make the modification to always be 4 messages. It was only after we were working out the details that I understood what Charlie and Dan meant by "pain in the neck". It's doable, but the protocol is a lot more complicated. I don't think it's necessary for any "political" reasons that we do anything any particular way. I think at this point it's clear everyone is collaborating on one proposal, and wants to do something correct, as simple as possible, and reflective of the WG's wishes. If we're not choosing "proposal A from this set of authors" vs "proposal B from this set of authors" and instead focusing on a well-defined technical point, and the WG has sound arguments for a particular opinion, we'll all support that way of doing things ("sound" means that the result would be correct, not overly complex, etc.) So let's focus on this one technical issue. The 4/6 protocol can be summarized as follows: messages 1 and 2 are D-H exchange (and nonces, and crypto negotiation) messages 3 and 4 are encrypted and integrity protected with a function of the D-H key, and consist of the identities, and proofs of knowledge of the secret, using some function of messages 1 and 2. The simplest and easiest, implementation-wise, is to sign all of messages 1 and 2, exactly as transmitted. We modified that to "sign your own message concatenated with the other side's nonce", at Sara Bitan's suggestion, which seemed like it wouldn't be harder, and certainly all fields would be still protected in one or the other side's signature. We were trying to avoid the issue Jan brought up of wrangling over which fields should be covered, and what the canonical order would be, and having implementations have to move all the fields around to create the canonical hash. if Bob wants to use a stateless cookie before doing the handshake, he replies to a message 1 without a cookie by saying "try again, using this cookie" The 4-always protocol is more conceptually complicated, since Bob, when he receives message 3, cannot be assumed to have any state. Since there are parts of messages 1 and 2 that need to be integrity protected (like the crypto negotiation), Alice has to repeat all of message 1, and Bob has to be able to reproduce, bit for bit, what he would have generated as message 2, so that he can sign that. There are the issues you brought up, Jan, about which fields need to be in the signature, which need to be repeated, etc. There are many strategies for how Bob might want to use the fields of cookie and nonce to encode state for himself. We don't want to constrain an implementation, and yet we need to define at least one way that works. Radia From owner-ipsec@lists.tislabs.com Tue Sep 17 14:40:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HLewk09528; Tue, 17 Sep 2002 14:40:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02839 Tue, 17 Sep 2002 16:47:33 -0400 (EDT) Message-Id: <200209172046.g8HKki801853@sydney.East.Sun.COM> Date: Tue, 17 Sep 2002 16:46:44 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Regarding pre-round trip for stateless cookie (Jan's issue) To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KM8diLZ4CuRghCvt7nlmqg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just thought I'd clarify something Paul Hoffman said (and again, I changed the subject line to focus on the technical issue). >> From: Paul Hoffman / VPNC >> - JFKr was better because the responder could always assume he was under attack >> The latter arguments aren't consistent because the same thing is true >> for the original IKEv2. Just because I had to read the above a few times before I understood what he was saying, I thought I'd restate it in my own words. What he's saying is that with the "4/6" design, if it's hard for Bob to make a decision about whether he thinks he's under attack, then he can always assume he's under attack, and always do the 6-message exchange. The downside of the 6-message exchange is the extra round trip. The downside of "4" are the implementation issues Jan raised, and it is more complicated to specify and understand. One other thing I was going to say in response to Jan's comment: >>I expect there's not that many ways to skin this cat. A quote I read once (forgot who said it) and can't resist sharing is "If there's more than one way to skin a cat, I don't want to hear about it" :-) Radia From owner-ipsec@lists.tislabs.com Tue Sep 17 14:46:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HLkjk09664; Tue, 17 Sep 2002 14:46:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02848 Tue, 17 Sep 2002 16:52:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6757.0 Content-class: urn:content-classes:message Subject: RE: It's all over (except for the screaming & shouting) - transition from PPTP Date: Tue, 17 Sep 2002 13:51:27 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D019A9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: It's all over (except for the screaming & shouting) - transition from PPTP Thread-Index: AcJXiMxQSmO7naZZS5qqWwFfYV98iQG6ygDg From: "William Dixon" To: "Alex Alten" , "Lordello, Claudio" , Cc: "Lordello, Claudio" X-OriginalArrivalTime: 17 Sep 2002 20:51:27.0806 (UTC) FILETIME=[FE33ADE0:01C25E8B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, because so many people read this list, I feel compelled to correct some things here, partially because I know many on the list don't use Windows, so they might now know otherwise. But also because it might help understanding of L2TP/IPsec integration designs, and bears a little on IKEv2 & JFK requirements (legacy auth, non-PKI auth, user vs. machine, and do they address VPN remote access requirements or not). Customers - Yes I also see that many large, but also small, customers prefer to use the native Microsoft VPN client, which in Win2k & XP's case supports both PPTP and L2TP/IPsec. There are many reasons. But the major security interest point I've heard from customers is that our L2TP/IPsec design authenticates both machine and user independently. And the user authentication supports both legacy passwords, and is flexible enough to plug in their own auth methods using EAP. This is a deployment requirement for many customers that is not well supported in current IPsec/IKE-only VPN products, and not well adopted in other IETF work, and not currently addressed in the JFK or IKEv2 work. IPsec tunnel mode for remote access using IKECFG & XAUTH died years ago in the standards process, but obviously is supported by many vendors who have substantial VPN market share, typically measured by gateway, not by clients. The IPRSA work most recently completed to use IPsec tunnel mode seems to have an unclear status, at least according the web page. I see their drafts are stuck in the RFC Editor queue, not sure why. Suffice to say however, that IPSRA's document status isn't blocking customer IPsec adoption for remote access, and that adopting the Windows VPN as a client doesn't equal adopting PPTP. I'd hope the trend of customers towards using the native VPN client means that customers are willing to transition to L2TP/IPsec once we get the NAT-T client update out, and that they finally have a solution for PKI deployment. Transition from PPTP - A number of things happened in the market from '98 to '01 that caused customers to move off of PPTP and adopt IPsec solutions for remote access. Customers are well served by having a variety of choices based on IPsec. I don't think you are seeing customers transition back to PPTP if they have already deployed a 3rd party IPsec tunnel mode solution, unless they found that NAT was just too problematic, even with IPsec-aware NATs percolating slowly into the infrastructure (which can only allow IPsec tunnel mode, not IPsec transport mode required by L2TP without NAT-T). Microsoft has been committed to L2TP/IPsec for remote access as a replacement for PPTP. We shipped the first implementation of this in Windows 2000 Beta2 around April 1998. The Win2k VPN connectoid has detection logic called "automatic mode" to help facilitate transition away from PPTP to L2TP/IPsec. The logic checks to see if a machine certificate exists, and if so, attempts L2TP/IPsec, by first negotiating IKE with machine cert auth, then L2TP SCCRQ (connection request control message) and all other L2TP traffic is communicated over the IPsec SA protection. This provides an initial mutual machine authentication before a user ID or the password hash is ever sent to the gateway. The automatic IPsec policy created by Win2k/XP/.NET L2TP requires IKE Main Mode machine certificate authentication and sets the CA root list based on what certs have been issued to the machine. Cross-certs, deep-hierarchies, and non-Microsoft PKI are supported by IPsec in general, so L2TP/IPsec inherits this. We only supported certificates for the IKE auth method in Win2k because we didn't think pre-shared key was secure enough for this scenario (referencing the published technique to discover IKE weak preshared key values by Prof. John Pliam), and because we supported only IKE Main Mode, which limited how a pre-shared key could be used with many clients - essentially a group-preshared key. We have actively campaigned against using a preshared key in general. The work on RFC 3193 was in progress so we provided the ability to use custom IPsec policy for L2TP for gateway to gateway VPN connections and to not use IPsec at all for connecting secure networks that only needed L2TP encapsulation tunneling services. This is explained in http://support.microsoft.com/default.aspx?scid=kb;en-us;Q240262 Nevertheless, we received significant customer feedback that our automatic preference for L2TP/IPsec was too aggressive, blocked by NATs, and PKI was too hard to deploy. Yet, people wanted to use IPsec instead of PPTP - understandable. Thus we changed the Windows XP VPN connectoid "automatic" preference to be PPTP, and we provided the configuration for an IKE preshared key in the client VPN config for L2TP/IPSec. In all cases the choice can be controlled by the user, and the VPN gateway administrator or by the VPN client administrator who can bake in the choice between PPTP and L2TP/IPsec, as well as a pre-shared key, in the Connection Manager pre-packaged "connection" configuration (has a dial phone book, VPN server list, custom extension code, etc). We still don't recommend preshared key, but it's there if you have to use it. NAT-Traversal - We are almost done. It's more than 1 1/2 years after the Feb '01 drafts for UDP encapsulation, and the significant revision of draft-02 Feb '02 to use a non-500 UDP port due to IPsec aware NATs. These drafts are in last call WG, and should solve the remaining technical blocker for transition from PPTP to L2TP/IPsec for those who want to use the Windows native VPN client. The NAT-T drafts also provide the solution for IPsec tunnel mode VPN clients. So all IPsec-based VPN usages are served. For transition away from PPTP, there remains the PKI deployment issue which everyone is struggling with. But there are solutions which scale to make enrollment and renewal easy in certain environments, and most CA vendors support web-based PKI enrollment services. It should only be a matter of time before customers understand what their options are, the costs and can choose a solution. However, I think a significant number of customers will not deploy PKI as their user authentication mechanism. The 802.1x wireless community has also been seeing that PKI is still too hard to deploy, adding user password-based authentication inside a server-authenticated TLS session. Thus I think it is a mistake to believe that even something like PIC will solve the PKI deployment problem. I think Son of IKE should provide for password-based authentication of users, or adopt an EAP or GSS-API method to be extensible. Encryption - Win2k-2195 and Service Pack 1 (SP1) released with the high encryption pack separate and included in the box where allowed. Win2k SP2 shipped with the high encryption pack installed by default where allowed. The high encryption pack provides 128bit RC4, as well as 3DES encryption. Windows XP ships with support for high encryption where allowed, as will Windows .NET Server. So using Windows native VPN does not equal using 40bit RC4. User Authentication - Win2k, XP and .NET Server implementations of PPTP and L2TP provide user authentication via the normal and standard PPP authentication mechanisms. They can do this with legacy userid/password via PAP, CHAP, MSCHAP, MSCHAPv2, etc and using EAP-TLS (RFC 2716), which provides user certificate authentication, either using smartcards or certificates in the user's account on disk. Also EAP plugins on the client, gateway and/or Radius Server for 3rd party authentication schemes can be added. So your PPTP client can use RC4 128bit encryption authenticating users with their smartcard or RSA's SecurID system, or something custom. PPTP vs. L2TP/IPsec. Windows 2000 Server and many other gateways today support both protocols, and the Windows VPN client functionality exists to allow customers to use L2TP/IPsec when possible, and automatically switch to PPTP if not. Given the strong user authentication capabilities in EAP-TLS in PPTP, this may be sufficient for many customers until they can move to L2TP/IPsec entirely. For those not actively engaged in the IPsec stds process, please refer to this site for more details http://www.microsoft.com/vpn -----Original Message----- From: Alex Alten [mailto:Alten@attbi.com] Sent: Sunday, September 08, 2002 3:08 PM To: Lordello, Claudio; ipsec@lists.tislabs.com Cc: Lordello, Claudio Subject: RE: It's all over (except for the screaming & shouting). I believe L2TP needs a cert and PPTP does not. That's a significant advantage for PPTP. - Alex At 09:41 AM 9/6/2002 -0400, Lordello, Claudio wrote: >>From what I have observed in a client 2K or XP, when one creates a new >>VPN >connection, the default network protocol is "Automatic" which works for >either PPTP or L2TP/IPsec. Unless one overrides that in the client to >specifically pick one or the other, which one is actually negotiated >will depend on the server one is dialing into. So I am not sure what >you mean by "the OS default is PPTP with 40b DES". Could you please >clarify. > >Claudio. > >-----Original Message----- >From: Alex Alten [mailto:Alten@attbi.com] >Sent: Friday, September 06, 2002 5:13 AM >To: ipsec@lists.tislabs.com >Subject: It's all over (except for the screaming & shouting). > > > >The market has finally spoken. IPsec has lost the VPN race. > >Recently I talked with an number of very senior level people in the IT >trenchs. A lot of PC upgrades to XP & Win2K were done to get VPN >capability. The OS default is PPTP with 40b DES (MPPE). Not L2TP >w/IPsec. I bet many Cisco folks are upset. > >IPsec will probably hang on in specialized niches like net to net VPNs, >etc. > >What a humbling result. > >- Alex >-- > >Alex Alten >Alten@ATTBI.com > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Tue Sep 17 15:44:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HMibk14360; Tue, 17 Sep 2002 15:44:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03145 Tue, 17 Sep 2002 18:11:36 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: Re: Merging IKEv2 and JFKr? To: Jan Vilhuber Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_09102002NP September 10, 2002 Message-ID: Date: Tue, 17 Sep 2002 18:08:47 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09132002NP|September 13, 2002) at 09/17/2002 06:04:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > I'm wondering about the wisdom of merging IKEv2 with JFK'isms. Seeing > that I haven't read the revised IKEv2+JFK proposal (because it's not > out yet), this is mostly based on my thoughts of what *I* would do, > were I to merge the two. I expect there's not that many ways to skin > this cat. > I apologize for the delay. I was hoping to get a new draft out by the end of August, but a draft I sent to the smaller author community generated such a volume of feedback that I'm still trying to reconcile it all. > Firstly, it doesn't seem needed. The difference is that JFK assumes it's > ALWAYS under attack, versus IKEv2 that gives you a mechanism to verify > the initiator's 'liveness' if you think you're under attack. So it's > not like IKEv2 doesn't address DoS issues. It does. > There are other differences between JFK and IKEv2, and other issues to resolve. > Code messiness. You may poo-poo that concept, but we all understand > IKE code and the coding-/design- philosophy behind it. You may not > like it, but there's a certain amount of expertise out there. By > adding JFK'isms into the mix, you're now mixing two very different > philosophies into one protocol, which sounds like it's prone to be > buggy, hard to analyze, etc etc. Instead of a protocol designed by a > committee, we now have a protocol designed by TWO committees. > > Along the same lines (or maybe 'by example'), IKE has always been > 'encrypted packet' or 'non encrypted packet'. Now we have a > 'half-encrypted' packet. Sigh. If someone has a clean way of doing > this (An 'encrypted payload' similar to Kink's KINK_ENCRYPT payload > (section 5.1.8 of the kink draft, FWIW) maybe?), maybe this can be > made to work, if absolutely necessary. > Yes, that's how I wrote it, as suggested by someone (I think Paul Hoffman). It is not quite as clean, but it is nearly so. > Extensibility: I keep thinking that prior to the SOI discussions, we > had talked about simplifying IKEv1 hashing, so that ALL payloads are > hashed and authenticated, no matter what they were. That has clear > implications to extensibility, i.e. future payloads. I realize one of > JFK's goals was 'non-extensibility', but I thought I saw rough > consensus towards extensibility during the recent chinese-menu > mails... Now by merging JFKr into IKEv2, we complicate the hashing > mechanism again to the point where we have to think about which > payloads can be part of the hash and which can't (also, which payloads > must be repeated and which mustn't or don't need to). > I don't believe we've lost any extensibility with the JFK changes. What's central to extensibility is saying in the spec what an implementation should do with things it doesn't recognise, including how to do the cryptographic protection. The spec still does that. (Of course, whether extensibility actually works out depends on how well we guess what extensions people will want.) > Legacy Authentication: This is really a subset of "extensibility". I'm > trying to fit some legacy authentication scheme into IKEv2, and I have > some ideas. Trying to fit them into an IKEv2+JFK protocol (assuming > what's in my mind is similar to what Charlie is working on) makes it > that much harder. > Discussing such extensions on the list might help assure that they will be possible. Paul told me a little about how legacy authentication was squeezed into IKEv1 and indeed that JFK changes to IKEv2 make that mechanism harder. But there are other encodings that might be just as good. > Packet sizes: By repeating msg1 in msg3, msg3 necessarily gets > larger. William kept trying to get people to realize that we have a > UDP fragmentation issue, when certs (or cert chains) are sent, so this > seems like a move in the wrong direction. Paul Hoffman had some ideas > of changing the ID payload so that it can include a URL, i.e. pointer > to the cert instead of the cert itself, and that may help. > The JFK related changes do make it harder to defend against carefully constructed UDP fragmentation attacks, though it was never easy and it's still possible. (A group of us has submitted a paper describing how). I'd like to add URLs as an optional way to "encode" certificates, but we can't depend on that to keep the messages to a single UDP fragment. > Based on my gut feeling, I vote to leave IKEv2 as is, rather than > grafting JFK'isms onto IKEv2. If it gave us something we can't live > without, I wouldn't have that much of an issue with it, but I don't > see a very good reason to do it (the cost outweighs the gain). > Why do I have visions of someone snatching my smaller but still tasty looking bale of hay? I believe that the original IKEv2 proposal was better than the combined proposal, and that the combined proposal is better than the JFK proposal. I'm sure most if not all of the JFK people believe that JFK was better than the combined proposal, but that the combined proposal is better than the original IKEv2. It's a compromise. Nobody thinks it's the best we can do. But neither is there any proposal that everyone would agree is better (or at least none we're likely to stumble upon before the next ice age). --Charlie Opinions expressed may not even by mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Tue Sep 17 15:55:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8HMtgk14576; Tue, 17 Sep 2002 15:55:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02904 Tue, 17 Sep 2002 17:09:49 -0400 (EDT) Message-Id: <4.3.2.7.1.20020917114624.00ae1150@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 14:06:48 -0700 To: "Saket Dandawate" , From: Ramana Yarlagadda Subject: Re: Notification payload in IKE In-Reply-To: <002c01c25e09$950d0410$bc64a8c0@saket> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Saket At 10:47 AM 9/17/02 +0530, Saket Dandawate wrote: > Notification Payload is used only to notify the other peer what went >wrong. But the field Notification Data is present. >My questions? > >1. Or is it necessary to send notification Data? It is not mandatory in most of the cases. But it is always good if we can send and receive(and process) notiy or informational payloads. >2. how do we send notification data? Any Standard way since rfc 2409 >doesn't speak on any particular format to be followed for sending >Notification Data? Through the informational exchange. And the notification payload is defined in RFC2408. -ramana From owner-ipsec@lists.tislabs.com Tue Sep 17 17:42:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8I0gGk18952; Tue, 17 Sep 2002 17:42:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03620 Tue, 17 Sep 2002 20:10:00 -0400 (EDT) Message-ID: <3D87C426.12F544A4@bstormnetworks.com> Date: Tue, 17 Sep 2002 17:09:10 -0700 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Saket Dandawate CC: ipsec@lists.tislabs.com Subject: Re: Notification payload in IKE References: <002c01c25e09$950d0410$bc64a8c0@saket> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Sep 2002 00:09:40.0076 (UTC) FILETIME=[AE8C12C0:01C25EA7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Saket, There was a draft on this for IKEv1, but it has not been updated for some time. I know of at least one major vendor who has implemented these notify message formats. Hopefully, IKEv2 will address this. Here's a URL for an expired version of the notify messages draft: http://community.roxen.com/developers/idocs/drafts/draft-ietf-ipsec-notifymsg-04.html Hope this helps, Scott Saket Dandawate wrote: > > HI All, > > Notification Payload is used only to notify the other peer what went > wrong. But the field Notification Data is present. > My questions? > > 1. Or is it necessary to send notification Data? > 2. how do we send notification data? Any Standard way since rfc 2409 > doesn't speak on any particular format to be followed for sending > Notification Data? > > Regards > Saket From owner-ipsec@lists.tislabs.com Tue Sep 17 17:53:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8I0rLk19379; Tue, 17 Sep 2002 17:53:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03672 Tue, 17 Sep 2002 20:23:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200209172046.g8HKki801853@sydney.East.Sun.COM> References: <200209172046.g8HKki801853@sydney.East.Sun.COM> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 17 Sep 2002 16:32:30 -0700 To: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Regarding pre-round trip for stateless cookie (Jan's issue) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:46 PM -0400 9/17/02, Radia Perlman - Boston Center for Networking wrote: >What he's saying is that with the "4/6" design, if it's hard for >Bob to make a decision about whether he thinks he's under attack, >then he can always assume he's under attack, and always do the >6-message exchange. Yep, that's what I was trying to say. :-) In addition, from the initiator side, it is trivial for the initiator to decide if the message he gets back from the responder is a "please retry" message or is a real message 3. If the encrypt bit is off, it's a "please retry"; if the encrypt bit is on, it's a real message 3. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Sep 18 07:27:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IERuk24835; Wed, 18 Sep 2002 07:27:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04815 Wed, 18 Sep 2002 09:42:00 -0400 (EDT) Message-ID: <20020918014413.42450.qmail@web13902.mail.yahoo.com> Date: Tue, 17 Sep 2002 18:44:13 -0700 (PDT) From: Rajesh Patel Subject: RE: IPSec NAT pass-through: how the server distinguish different clients? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In a separate thread William Dixon wrote - > NAT-Traversal - We are almost done. It's more than 1 1/2 years after > the Feb '01 drafts for UDP encapsulation, and the significant revision > of draft-02 Feb '02 to use a non-500 UDP port due to IPsec aware NATs. > These drafts are in last call WG, and should solve the remaining > technical blocker for transition from PPTP to L2TP/IPsec for those who > want to use the Windows native VPN client. The NAT-T drafts also > provide the solution for IPsec tunnel mode VPN clients. So all > IPsec-based VPN usages are served. I have been following the NAT Traversal draft (draft-ietf-ipsec-udp-encaps-03.txt) for a while. The only reason to consider this solution is to allow multiple clients behind a NAT to connect to the same server using transport mode. However, I just don't see it working in real life situations. The biggest problem that I see is the conflict "traffic-desc" mentioned in the draft (Section 5.3), where traffic-desc is the port/protocol pair. If two machines happen to pick the same port/protocol, then this solution does not work. For TCP, most TCP/IP implementations pick source port starting from around 1025 (after skipping system ports). So the chances of two machines picking up the same source port are very high. The chances of destination port conflict are going to be very high since these are going to be a few standard ports (such as HTTP, telnet etc.). For UDP, it is even worse. Since many UDP applications pick their own source port, this means that one can not use the same UDP application on two different machines behind the same NAT. To me there does not seem to be any advantage in using this approach over IPSec pass-through. Why is IETF even considering standardizing this draft when the draft itself mentions so many limitations that are so glaring and requires modifications to IKE? Raj __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From owner-ipsec@lists.tislabs.com Wed Sep 18 11:12:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IICPk06537; Wed, 18 Sep 2002 11:12:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05185 Wed, 18 Sep 2002 13:38:36 -0400 (EDT) Message-Id: <200209181737.g8IHbQ6e014718@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Regarding pre-round trip for stateless cookie (Jan's issue) In-reply-to: Your message of "Tue, 17 Sep 2002 16:46:44 EDT." <200209172046.g8HKki801853@sydney.East.Sun.COM> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 18 Sep 2002 13:37:25 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Radia" == Radia Perlman <- Boston Center for Networking > writes: Radia> Just because I had to read the above a few times before I Radia> understood what Radia> he was saying, I thought I'd restate it in my own words. Radia> What he's saying is that with the "4/6" design, if it's hard for Radia> Bob to make a decision about whether he thinks he's under attack, Radia> then he can always assume he's under attack, and always do the Radia> 6-message exchange. I am of the opinion that for any system which has a non-trivial number of defined connections, that it pretty much impossible for Bob to determine that he isn't under attack. The only deployments that I can see that could determine for certain that they aren't under attack would be two or three node VPNs. The moment you add even half a dozen road warriors, or in FreeSWAN's case, 2^32 potential OE connections, one might as well assume one is under attack. As such, I question any design that introduces complexity to optomize the unusual case. I would rather have shorter setups times, but I would rather it was resistant to DDoS. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPYi50oqHRg3pndX9AQEedAP+LeMDs4hz+j9xblXuBRC8D1hdJtKF2dEE tzxk4Wx+SYfvVmqhlcyrYpNdffm/q+KcbVdGReJ8jUepsGU/tZ3g+iH6bee5db8G LSVLawmzcX43Uyz6rv9hUUDX7dNXS31FQBXg/JLfJngGG5AdGr1/7BDDCNnxsmtR mr+SVG6UuUQ= =zn8f -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Sep 18 12:28:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IJS4k09885; Wed, 18 Sep 2002 12:28:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05370 Wed, 18 Sep 2002 14:55:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200209181737.g8IHbQ6e014718@marajade.sandelman.ottawa.on.ca> References: <200209181737.g8IHbQ6e014718@marajade.sandelman.ottawa.on.ca> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 18 Sep 2002 11:54:40 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Regarding pre-round trip for stateless cookie (Jan's issue) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:37 PM -0400 9/18/02, Michael Richardson wrote: > I am of the opinion that for any system which has a non-trivial number >of defined connections, that it pretty much impossible for Bob to determine >that he isn't under attack. For both the 4/6 and always-4 choices, it doesn't matter if you are actually under attack: it only matters if being under attack causes you to run out of resources. If you are under attack but have plenty of resources, it doesn't matter. Thus, the only thing that a system needs to determine is whether it is getting low on resources. In 4/6, if you get low on resources, you go to 6 mode. In always-4, you start re-using your DH exponents. > The only deployments that I can see that could determine for certain >that they aren't under attack would be two or three node VPNs. Lots of systems could determine if they are getting low on resources, particularly if we know that the resources are the ability to do large multiplies, and free space in the fragmentation buffers. > As such, I question any design that introduces complexity to optomize the >unusual case. I would rather have shorter setups times, but I would rather >it was resistant to DDoS. There appear to be (at least) two types of complexity: complexity of the protocol, and complexity of extending the protocol. For both the 4/6 and always-4 choices, the protocol complexity is the same ("do I have any DH exponents ready for this new connection?"). However, as this thread is pointing out, the extension complexity for 4/6 appears much less than for always-4, which is why Jan asked why are changing IKEv2 to use it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Sep 18 19:31:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8J2VYk29736; Wed, 18 Sep 2002 19:31:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05922 Wed, 18 Sep 2002 21:52:24 -0400 (EDT) Message-Id: <200209190151.g8J1pt802901@sydney.East.Sun.COM> Date: Wed, 18 Sep 2002 21:51:53 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Regarding pre-round trip for stateless cookie (Jan's issue) To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Vrhkc7auWLrag4B+RzQR2g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> From: Michael Richardson >>I would rather have shorter setups times, but I would rather >>it was resistant to DDoS. I don't think the stateless cookie is very useful for DDoS. It's only useful for the kind of DOS in which the attacker system is using fake IP addresses. In a DDoS situation, the innocent zombies will be using their own addresses. As for shorter setup times...ironically, the 4/6 protocol might have lower latency! a) if you don't care about Bob being stateless until receipt of the stateless cookie, then the 4/6 protocol would be lower latency, because it will be 4 messages, and the messages will have fewer bits to transmit (message 3 doesn't have to repeat all of message 1 and part of message 2) b) if you do care about Bob being stateless, then the 4/6 protocol would have 6 messages, but unintuitively might still be lower total latency because of two issues: . fewer total bits to transmit (small issue) . Alice and Bob can't be doing their exponentiation in parallel. If Bob is stateless, he can't do any computation until receipt of message 3 from Alice. The time to do the exponentiations of g^b and g^ab might be longer than the transmission time of the first 2 messages. Again, I'm not claiming this is a very important issue either way, and I got the impression from Charlie's message that he's not thrilled about being pushed back and forth on an issue that doesn't matter very much. But it *is* interesting that latency can be less with a 6 message protocol than a 4 message protocol. (at least *I* think it's interesting. :-) ) Radia From owner-ipsec@lists.tislabs.com Fri Sep 20 06:52:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KDqmk12056; Fri, 20 Sep 2002 06:52:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09227 Fri, 20 Sep 2002 09:14:42 -0400 (EDT) Message-Id: <200209201152.HAA19042@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ctr-01.txt Date: Fri, 20 Sep 2002 07:52:47 -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 : Using AES Counter Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ctr-01.txt Pages : 18 Date : 2002-9-19 This document describes the use of AES Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload confidentiality mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ciph-aes-ctr-01.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-ciph-aes-ctr-01.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: <2002-9-19154710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ctr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-19154710.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Sep 20 06:52:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KDqnk12067; Fri, 20 Sep 2002 06:52:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09218 Fri, 20 Sep 2002 09:12:41 -0400 (EDT) X-Authentication-Warning: glenlivet.cisco.com: bora set sender to bora@cisco.com using -f To: ipsec@lists.tislabs.com Subject: IPSec NAT pass-through and TCP checksums References: <20020918014413.42450.qmail@web13902.mail.yahoo.com> From: Bora Akyol Date: 19 Sep 2002 19:12:12 -0700 In-Reply-To: <20020918014413.42450.qmail@web13902.mail.yahoo.com> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From a review of the NAT-T and UDP encap IDs, it seems that the entity that is within the private network (and behind the NAT gw) does not have access to the public side IP address of the NAT gw. This in turn causes the receiver of transport-udp mode traffic to recompute the entire TCP checksum as opposed to an adjustment of it. >From the statements in the relevant sections of the ID, it seems that this is in fact correct. I am wondering however, why not simply add a NAT-NA (NAT Address) payload (optionally) sent by the public side device, which has this address, to the other party involved in the IKE exchange so that a simple recomputation should suffice. Of course if both sides are behind NAT gws then all bets are off. I may be opening up an old wound here unknowingly, and my apologies for that in advance. Regards, Bora Akyol ps. I did try to search the list archives on this topic but neither of the two FTP sites are working tonight. From owner-ipsec@lists.tislabs.com Fri Sep 20 10:23:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KHNOk25380; Fri, 20 Sep 2002 10:23:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09740 Fri, 20 Sep 2002 12:51:27 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869BC6@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Bora Akyol'" , ipsec@lists.tislabs.com Subject: RE: IPSec NAT pass-through and TCP checksums Date: Fri, 20 Sep 2002 09:52:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >From the statements in the relevant sections of the ID, it seems that > this is in fact correct. I am wondering however, why not simply add a > NAT-NA (NAT Address) payload (optionally) sent by the public side > device, which has this address, to the other party involved in > the IKE exchange so that a simple recomputation should suffice. Of > course if both sides are behind NAT gws then all bets are off. This occurred to me, actually I think we can even sort out the double NAT case. The initiator sends as part of the key agreement a statement of 1) What it believes its source IP address to be 2) What it believes the destination IP address to be This can then be stored with the SA and used to fix up the packets. > I may be opening up an old wound here unknowingly, and my apologies > for that in advance. Patent troll perhaps??? When in the distant past there were discussions of NAT the frequent pushback was 'if you are NAT on the NET you are NOT on the NET'. So I would not take a great deal of notice of the old wounds. The WG now understands that NATs exist and are not going away and so we all have to work out how we can live with them (translation I have a NAT box at home and I want my VPN to work through it)... Phill From owner-ipsec@lists.tislabs.com Fri Sep 20 10:46:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KHkmk26140; Fri, 20 Sep 2002 10:46:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09819 Fri, 20 Sep 2002 13:20:10 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869BC8@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "Hallam-Baker, Phillip" , "'Bora Akyol'" , ipsec@lists.tislabs.com Subject: RE: IPSec NAT pass-through and TCP checksums Date: Fri, 20 Sep 2002 10:20:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > I may be opening up an old wound here unknowingly, and my apologies > > for that in advance. > > Patent troll perhaps??? Ack, lest anyone missunderstand, I was attempting to point out that the 'old wound' to be reopened might have been the demands of a patent troll, not that Bora is a patent troll. Phill From owner-ipsec@lists.tislabs.com Sun Sep 22 12:41:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8MJexv29386; Sun, 22 Sep 2002 12:41:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13411 Sun, 22 Sep 2002 14:54:15 -0400 (EDT) From: VAHUJA@aol.com Message-ID: <125.16f62d26.2abf6bb2@aol.com> Date: Sun, 22 Sep 2002 14:53:38 EDT Subject: Diffie Hellman implementation To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 7.0 for Windows US sub 10637 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a request - if any one is familiar and can point to a software implementation of Diffie-Hemman??? Thanks in advance, Vijay Ahuja From owner-ipsec@lists.tislabs.com Sun Sep 22 14:39:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8MLd7v02693; Sun, 22 Sep 2002 14:39:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13671 Sun, 22 Sep 2002 17:07:51 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com Subject: Re: Regarding pre-round trip for stateless cookie (Jan's issue) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Sep 2002 17:07:20 -0400 Message-Id: <20020922210720.B56EF7B68@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200209190151.g8J1pt802901@sydney.East.Sun.COM>, Radia Perlman - Bos ton Center for Networking writes: > > >As for shorter setup times...ironically, the 4/6 protocol might have >lower latency! > Maybe, though that would depend on both CPU time and round-trip time -- and CPUs are getting faster, unlike the speed of light. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From owner-ipsec@lists.tislabs.com Mon Sep 23 06:23:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NDN7v03946; Mon, 23 Sep 2002 06:23:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15014 Mon, 23 Sep 2002 08:54:07 -0400 (EDT) Message-ID: <03f801c26300$2ae648c0$32204789@skeisamd01> From: "Suresh Singh K." To: , References: <185.ed24788.2ac0607e@aol.com> Subject: Re: Diffie Hellman implementation Date: Mon, 23 Sep 2002 18:23:06 +0530 Organization: Analog Devices Inc 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Try www.swox.com/gmp/ Cheers ! Suresh ----- Original Message ----- From: To: Sent: Monday, September 23, 2002 5:48 PM Subject: Re: Diffie Hellman implementation > Thanks....appreciate it.. > > > From owner-ipsec@lists.tislabs.com Mon Sep 23 06:23:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NDN7v03947; Mon, 23 Sep 2002 06:23:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14949 Mon, 23 Sep 2002 08:50:06 -0400 (EDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) From: "Amey Gokhale" Subject: Periodic certificate validation check To: ipsec@lists.tislabs.com Date: Mon, 23 Sep 2002 12:51:52 +0100 X-Postmaster: Sent from Postmaster http://www.postmaster.co.uk/, the world's premier free web-based email service, based in London, England. X-Postmaster-Trace: Account name: agokhale; Local time: Mon Sep 23 12:51:52 2002; Local host: pmweb8.uk1.bibliotech.net; Remote host: 202.54.40.36; Referer site: www.postmaster.co.uk X-Complaints-To: Administrator@postmaster.co.uk Message-Id: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi list, During IKE, with certificate based authentication method, validity(CRL checking) of the user certificate is done only during initial stage that is during SA negotiation. If the certificate gets revoked after the connection is established, does the implementation should check periodically for the validity of the certificate in between a running connection? If yes then does some notification need to be generated n sent to the other party about the revoked certificate? With regards, Amey Gokhale. From owner-ipsec@lists.tislabs.com Mon Sep 23 08:29:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NFTDv06767; Mon, 23 Sep 2002 08:29:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15376 Mon, 23 Sep 2002 10:58:42 -0400 (EDT) Message-Id: <200209231457.g8NEvbUw001085@thunk.east.sun.com> From: Bill Sommerfeld To: "Amey Gokhale" cc: ipsec@lists.tislabs.com Subject: Re: Periodic certificate validation check In-Reply-To: Your message of "Mon, 23 Sep 2002 12:51:52 BST." Reply-to: sommerfeld@east.sun.com Date: Mon, 23 Sep 2002 10:57:37 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If the certificate gets revoked after the connection is established, > does the implementation ... check periodically for the validity of > the certificate in between a running connection? Not that I've seen. In many cases you can get the revocation behavior you seem to want by using a relatively short lifetime on your IKE SA, forcing the cert to be re-validated on a regular basis. - Bill From owner-ipsec@lists.tislabs.com Mon Sep 23 10:15:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NHFiv09010; Mon, 23 Sep 2002 10:15:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15589 Mon, 23 Sep 2002 12:34:37 -0400 (EDT) Message-ID: <027e01c2631f$aec77b40$1e02a8c0@entrust.com> From: "Greg Carter" To: "Amey Gokhale" , References: Subject: Re: Periodic certificate validation check Date: Mon, 23 Sep 2002 12:38:44 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I remember talking about this way back... Ideally you would constrain the IKE phase one SA life time to not be greater than the next update time of the CRL (and not past the certificate lifetime). However you wouldn't fetch the CRL until after you agreed on the SA. So you would have to modify the SA lifetime locally (no big deal) if the agreed lifetime was longer than the next update field in the CRL. Then initiate a new IKE SA just prior to the CRL next update period. At which time a new CRL will be available, so the new IKE exchange will force a CRL check, if it fails your IKE set-up would fail and you would follow the normal failure path. Since the CRL lifetime is set by those running the CA, it is assumed that the security policy in place is satisfied with the CRL update period. So theoretically, constraining the IPSec lifetimes to those of the CRL should be OK. If you were using OCSP the same applies (use the next update field). Greg Carter ----- Original Message ----- From: "Amey Gokhale" To: Sent: Monday, September 23, 2002 7:51 AM Subject: Periodic certificate validation check > Hi list, > > During IKE, with certificate based authentication method, validity(CRL checking) of the user certificate is done only during initial stage that is during SA negotiation. > > If the certificate gets revoked after the connection is established, does the implementation should check periodically for the validity of the certificate in between a running connection? If yes then does some notification need to be generated n sent to the other party about the revoked certificate? From owner-ipsec@lists.tislabs.com Mon Sep 23 10:54:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NHsKv09912; Mon, 23 Sep 2002 10:54:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15765 Mon, 23 Sep 2002 13:23:01 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869BCF@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Greg Carter'" , Amey Gokhale , ipsec@lists.tislabs.com Subject: RE: Periodic certificate validation check Date: Mon, 23 Sep 2002 10:24:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If you were using OCSP the same applies (use the next update field). The next update field is only useful in that fashion if the OCSP service is CRL driven. In the case of the VeriSign OCSP service the OCSP service always reports the current status of the certificate as defined by the authoritative certificate status database. If you want to have pre-emptive cancellation of sessions based on revocation of certificates you really need to define a very different interface to the PKI that provides active status notification. For the sake of prior-art this is described in my X-TASS research note. However I don't think that there is sufficient demand for a system that involved that degree of complexity. In practice the way to pre-empt applications is in the authorization layer. The overhead of support for pre-emption is such that you do not want to duplicate the effort for authentication and authorization infrastructures - if in fact it is worth implementing at all. However this is addressed, it is not an IPSEC problem... Phill From owner-ipsec@lists.tislabs.com Mon Sep 23 13:15:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NKFnv13330; Mon, 23 Sep 2002 13:15:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16274 Mon, 23 Sep 2002 15:27:00 -0400 (EDT) From: mzimmerman@icsalabs.com Message-ID: To: sureshsingh.keisam@analog.com, VAHUJA@aol.com, ipsec@lists.tislabs.com Subject: RE: Diffie Hellman implementation Date: Mon, 23 Sep 2002 15:25:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The following may also be helpful. http://www.linuxjournal.com/article.php?sid=6131 Regards, -----Original Message----- From: Suresh Singh K. [mailto:sureshsingh.keisam@analog.com] Sent: Monday, September 23, 2002 8:53 AM To: VAHUJA@aol.com; ipsec@lists.tislabs.com Subject: Re: Diffie Hellman implementation Try www.swox.com/gmp/ Cheers ! Suresh ----- Original Message ----- From: To: Sent: Monday, September 23, 2002 5:48 PM Subject: Re: Diffie Hellman implementation > Thanks....appreciate it.. > > > *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *********************************************************************** From owner-ipsec@lists.tislabs.com Mon Sep 23 16:36:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NNaLv18384; Mon, 23 Sep 2002 16:36:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16619 Mon, 23 Sep 2002 19:07:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6757.0 Content-class: urn:content-classes:message Subject: RE: IPSec NAT pass-through and TCP checksums Date: Mon, 23 Sep 2002 16:07:04 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D01A36@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: IPSec NAT pass-through and TCP checksums Thread-Index: AcJgx8jVbIyFop2MSJez14LxXhY61wCipKeg From: "William Dixon" To: "Hallam-Baker, Phillip" , "Bora Akyol" , X-OriginalArrivalTime: 23 Sep 2002 23:07:05.0118 (UTC) FILETIME=[EEE573E0:01C26355] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The purpose of the existing Original Address payload in quick mode is to provide the information to the authenticated peer for how to fix up the TCP/UDP checksums that are protected by ESP encapsulation, if the TCP/UDP receiver chooses to do so. If the TCP/UDP receiver knows that the traffic was received over an IPsec SA, it may choose not to recalculate or verify a checksum on inbound traffic that it consumes. However, I refer you to the mail by Brian Swander 7/29/02 to the IPsec list that dealt with a more general problem of this case, multiple IPsec NAT-T clients behind the same NAT going to the same receiver IP address. Note the operative phrase above: "that it consumes". These drafts do not intend to provide a solution if you have to NAT the traffic before it is encapsulated with IPsec ESP or after it is decapsulated, such as NATing traffic from a remote office's private address space before or after it gets IPsec tunneled to HQ network. The drafts only claim to provide a solution within IKE & ESP UDP encapsulation for passing IPsec ESP transport or tunneled traffic across NATs that exist between the IKE/IPsec peers. Bora, your suggestion of the involvement of the NAT violates the requirements draft - that a solution must be independent of and essentially transparent to existing deployed NATs. Further, there would be no way to trust such a message and no way to depend on NAT vendors implementing it. Plus the external source address shouldn't be that useful, because you don't know whether there were 1 or 2 or N NATs on the traffic outbound before you received it - what if you received multiple.... -----Original Message----- From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] Sent: Friday, September 20, 2002 9:52 AM To: 'Bora Akyol'; ipsec@lists.tislabs.com Subject: RE: IPSec NAT pass-through and TCP checksums > >From the statements in the relevant sections of the ID, it seems that > this is in fact correct. I am wondering however, why not simply add a > NAT-NA (NAT Address) payload (optionally) sent by the public side > device, which has this address, to the other party involved in the IKE > exchange so that a simple recomputation should suffice. Of course if > both sides are behind NAT gws then all bets are off. This occurred to me, actually I think we can even sort out the double NAT case. The initiator sends as part of the key agreement a statement of 1) What it believes its source IP address to be 2) What it believes the destination IP address to be This can then be stored with the SA and used to fix up the packets. > I may be opening up an old wound here unknowingly, and my apologies > for that in advance. Patent troll perhaps??? When in the distant past there were discussions of NAT the frequent pushback was 'if you are NAT on the NET you are NOT on the NET'. So I would not take a great deal of notice of the old wounds. The WG now understands that NATs exist and are not going away and so we all have to work out how we can live with them (translation I have a NAT box at home and I want my VPN to work through it)... Phill -----Original Message----- From: Bora Akyol [mailto:bora@cisco.com] Sent: Thursday, September 19, 2002 7:12 PM To: ipsec@lists.tislabs.com Subject: IPSec NAT pass-through and TCP checksums >From a review of the NAT-T and UDP encap IDs, it seems that the entity that is within the private network (and behind the NAT gw) does not have access to the public side IP address of the NAT gw. This in turn causes the receiver of transport-udp mode traffic to recompute the entire TCP checksum as opposed to an adjustment of it. >From the statements in the relevant sections of the ID, it seems that this is in fact correct. I am wondering however, why not simply add a NAT-NA (NAT Address) payload (optionally) sent by the public side device, which has this address, to the other party involved in the IKE exchange so that a simple recomputation should suffice. Of course if both sides are behind NAT gws then all bets are off. I may be opening up an old wound here unknowingly, and my apologies for that in advance. Regards, Bora Akyol ps. I did try to search the list archives on this topic but neither of the two FTP sites are working tonight. From owner-ipsec@lists.tislabs.com Tue Sep 24 06:43:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ODhJv18109; Tue, 24 Sep 2002 06:43:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17816 Tue, 24 Sep 2002 09:12:36 -0400 (EDT) Date: Mon, 23 Sep 2002 16:24:20 -0700 (PDT) Message-Id: <20020923.162420.16721891.bora@cisco.com> To: wdixon@windows.microsoft.com Cc: pbaker@verisign.com, ipsec@lists.tislabs.com Subject: Re: IPSec NAT pass-through and TCP checksums From: Bora Akyol In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC105D01A36@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC105D01A36@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William I don't think in my email I required the NAT to provide a message, I said that the party in the public network can tell the party in the private network what it thinks its public side address (effectively the address of the NAT) is. It looks like the draft is geared towards a host coming from behind a NAT with a VPN box/router sitting in the public network and providing connectivity. I think this is a perfectly normal case in which the host sitting behind the NAT has the option to disregard the TCP checksums when and if it desires for transport mode, but if the box sitting behind the NAT also happens to be a router, then for every packet that it receives in TRANSPORT mode, it looks like it needs to calculate complete TCP checksum. This seems very inefficient to me. Suppose that I have a NAT/VPN router in my house and I have 6-10 computers behind it, now this router when I configure transport mode, is recomputing TCP checksums for every packet that it receives. Do you agree that this may present a problem? Bora From: "William Dixon" Subject: RE: IPSec NAT pass-through and TCP checksums Date: Mon, 23 Sep 2002 16:07:04 -0700 > The purpose of the existing Original Address payload in quick mode is to > provide the information to the authenticated peer for how to fix up the > TCP/UDP checksums that are protected by ESP encapsulation, if the > TCP/UDP receiver chooses to do so. If the TCP/UDP receiver knows that > the traffic was received over an IPsec SA, it may choose not to > recalculate or verify a checksum on inbound traffic that it consumes. > However, I refer you to the mail by Brian Swander 7/29/02 to the IPsec > list that dealt with a more general problem of this case, multiple IPsec > NAT-T clients behind the same NAT going to the same receiver IP address. > > > Note the operative phrase above: "that it consumes". These drafts do > not intend to provide a solution if you have to NAT the traffic before > it is encapsulated with IPsec ESP or after it is decapsulated, such as > NATing traffic from a remote office's private address space before or > after it gets IPsec tunneled to HQ network. The drafts only claim to > provide a solution within IKE & ESP UDP encapsulation for passing IPsec > ESP transport or tunneled traffic across NATs that exist between the > IKE/IPsec peers. > > Bora, your suggestion of the involvement of the NAT violates the > requirements draft - that a solution must be independent of and > essentially transparent to existing deployed NATs. Further, there would > be no way to trust such a message and no way to depend on NAT vendors > implementing it. Plus the external source address shouldn't be that > useful, because you don't know whether there were 1 or 2 or N NATs on > the traffic outbound before you received it - what if you received > multiple.... > > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] > Sent: Friday, September 20, 2002 9:52 AM > To: 'Bora Akyol'; ipsec@lists.tislabs.com > Subject: RE: IPSec NAT pass-through and TCP checksums > > > > > >From the statements in the relevant sections of the ID, it seems that > > this is in fact correct. I am wondering however, why not simply add a > > NAT-NA (NAT Address) payload (optionally) sent by the public side > > device, which has this address, to the other party involved in the IKE > > > exchange so that a simple recomputation should suffice. Of course if > > both sides are behind NAT gws then all bets are off. > > This occurred to me, actually I think we can even sort out the double > NAT case. > > The initiator sends as part of the key agreement a statement of > 1) What it believes its source IP address to be > 2) What it believes the destination IP address to be > > This can then be stored with the SA and used to fix up the packets. > > > > I may be opening up an old wound here unknowingly, and my apologies > > for that in advance. > > Patent troll perhaps??? > > When in the distant past there were discussions of NAT the frequent > pushback was 'if you are NAT on the NET you are NOT on the NET'. So > I would not take a great deal of notice of the old wounds. > > The WG now understands that NATs exist and are not going away and so we > all have to work out how we can live with them (translation I have a NAT > box at home and I want my VPN to work through it)... > > > Phill > > -----Original Message----- > From: Bora Akyol [mailto:bora@cisco.com] > Sent: Thursday, September 19, 2002 7:12 PM > To: ipsec@lists.tislabs.com > Subject: IPSec NAT pass-through and TCP checksums > > > > >From a review of the NAT-T and UDP encap IDs, > it seems that the entity that is within the > private network (and behind the NAT gw) does not have access to the > public side IP address of the NAT gw. > > This in turn causes the receiver of transport-udp mode traffic to > recompute the entire TCP checksum as opposed to an adjustment of it. > > >From the statements in the relevant sections of the ID, it seems that > this is in fact correct. I am wondering however, why not simply add a > NAT-NA (NAT Address) payload (optionally) sent by the public side > device, which has this address, to the other party involved in the IKE > exchange so that a simple recomputation should suffice. Of course if > both sides are behind NAT gws then all bets are off. > > I may be opening up an old wound here unknowingly, and my apologies for > that in advance. > > Regards, > > Bora Akyol > > ps. I did try to search the list archives on this topic > but neither of the two FTP sites are working tonight. > From owner-ipsec@lists.tislabs.com Tue Sep 24 06:43:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ODhJv18108; Tue, 24 Sep 2002 06:43:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17822 Tue, 24 Sep 2002 09:13:36 -0400 (EDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) From: "Amey Gokhale" Subject: Re: Periodic certificate validation check To: "Greg Carter" Cc: ipsec@lists.tislabs.com Date: Tue, 24 Sep 2002 13:17:22 +0100 X-Postmaster: Sent from Postmaster http://www.postmaster.co.uk/, the world's premier free web-based email service, based in London, England. X-Postmaster-Trace: Account name: agokhale; Local time: Tue Sep 24 13:17:22 2002; Local host: pmweb6.uk1.bibliotech.net; Remote host: 202.54.40.36; Referer site: www.postmaster.co.uk X-Complaints-To: Administrator@postmaster.co.uk Message-Id: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Keeping IKE SA lifetime just below CRL next update time could cause a lot of overhead over a VPN gateway as phillip mentioned. The CRL update time of verisign is 10 days. what if any third party server has frequent CRL updations? All IKE SA;s will be invalidated accordingly causing IPSec SAs to break down. That will lead frequent SA negotiations causing lot of overhead. In that case is there any standard approach to be followed? Regards, Amey Gokhale. On Mon, 23 Sep 2002 12:38:44 -0400 "Greg Carter" wrote: > I remember talking about this way back... > > Ideally you would constrain the IKE phase one SA life time to not be greater > than the next update time of the CRL (and not past the certificate > lifetime). However you wouldn't fetch the CRL until after you agreed on the > SA. So you would have to modify the SA lifetime locally (no big deal) if > the agreed lifetime was longer than the next update field in the CRL. Then > initiate a new IKE SA just prior to the CRL next update period. At which > time a new CRL will be available, so the new IKE exchange will force a CRL > check, if it fails your IKE set-up would fail and you would follow the > normal failure path. > > Since the CRL lifetime is set by those running the CA, it is assumed that > the security policy in place is satisfied with the CRL update period. So > theoretically, constraining the IPSec lifetimes to those of the CRL should > be OK. > > If you were using OCSP the same applies (use the next update field). > Greg Carter > ----- Original Message ----- > From: "Amey Gokhale" > To: > Sent: Monday, September 23, 2002 7:51 AM > Subject: Periodic certificate validation check > > > > Hi list, > > > > During IKE, with certificate based authentication method, validity(CRL > checking) of the user certificate is done only during initial stage that is > during SA negotiation. > > > > If the certificate gets revoked after the connection is established, does > the implementation should check periodically for the validity of the > certificate in between a running connection? If yes then does some > notification need to be generated n sent to the other party about the > revoked certificate? > > > From owner-ipsec@lists.tislabs.com Tue Sep 24 09:12:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OGCQv26287; Tue, 24 Sep 2002 09:12:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18389 Tue, 24 Sep 2002 11:37:45 -0400 (EDT) Message-ID: <033901c263e0$e297f9b0$1e02a8c0@entrust.com> From: "Greg Carter" To: "Amey Gokhale" , References: Subject: Re: Periodic certificate validation check Date: Tue, 24 Sep 2002 11:41:44 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well ideally the CA would be using CRL distribution points and therefore you would not have all the users under the same CRL. So there would be multiple CRLs each expiring at different times. I can't speak for Verisign but I would guess that the 10 days is for their free public CAs, I would assume that their Enterprise offering has a configurable period (much less than 10 days). Again you would not interrupt the current SA while negotiating the next. Regardless of CRL/Certificates you would negotiate the next IKE SA at SA Expiry Time - X, where X is random but constrained to an appropriate value (I think this is talked about in the RFCs). This way you wont have both ends pulling down the connection and both attempting IKE negations at the same time. So if you use the above SA negotiation approach, along with a CA that supports CRL distribution points, the overhead should not be a problem. The "potential" overhead would only occur when an SA is negotiated that would be longer than a CRL validity period (or certificate). CRLs are generally valid for at least 4 hours. I know that the Entrust CA supports CRL distribution points and CRL validity periods configurable from 4-48 hours. Greg. ----- Original Message ----- From: "Amey Gokhale" To: "Greg Carter" Cc: Sent: Tuesday, September 24, 2002 8:17 AM Subject: Re: Periodic certificate validation check > Keeping IKE SA lifetime just below CRL next update time could cause a lot of overhead over a VPN gateway as phillip mentioned. > > The CRL update time of verisign is 10 days. what if any third party server has frequent CRL updations? All IKE SA;s will be invalidated accordingly causing IPSec SAs to break down. That will lead frequent SA negotiations causing lot of overhead. > In that case is there any standard approach to be followed? > > Regards, > Amey Gokhale. From owner-ipsec@lists.tislabs.com Tue Sep 24 09:35:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OGZev28017; Tue, 24 Sep 2002 09:35:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18451 Tue, 24 Sep 2002 12:06:54 -0400 (EDT) Message-ID: <053801c263e3$e392f420$344f728c@mantis> From: "jmc-cs" To: Subject: How to order(purchase) IEEE802.11i draft? Date: Wed, 25 Sep 2002 00:03:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can anyone advise me how to order (or purchase) the IEEE802.11i Draft? I searched on the IEEE catalog&store database, but nothing found. Where can I order this draft??? Regards jmc From owner-ipsec@lists.tislabs.com Tue Sep 24 09:59:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OGxBv29038; Tue, 24 Sep 2002 09:59:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA18594 Tue, 24 Sep 2002 12:32:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6757.0 Content-class: urn:content-classes:message Subject: RE: IPSec NAT pass-through: how the server distinguish different clients? Date: Tue, 24 Sep 2002 09:31:30 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D01A47@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: IPSec NAT pass-through: how the server distinguish different clients? Thread-Index: AcJfG+wgfY6+GPpCTZaqjfqE/WOLmAEyRAnA From: "William Dixon" To: "Rajesh Patel" , X-OriginalArrivalTime: 24 Sep 2002 16:31:29.0769 (UTC) FILETIME=[D5F05D90:01C263E7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Raj, what scenario are you talking about ? Where are the NATs, where are the initiators, responders, what is their policy, tunnel/transport, is there app integration with IKE or is it transparent to IKE, is IPsec integrated into the initiator/responder TCPIP stack or is it bump-in-the-wire, a mix, etc ? Isn't this the general problem with IKE quick mode SA proposals going through a NAT unmodified ? The NAT's support IKE/ESP passthrough doesn't solve that either. Even being able to talk to the first-hop NAT to learn your external IP doesn't solve the upstream NAT problem. Brian's mail outlined many of implementation techniques possible to solve the client behind a NAT problem, which can require work on the initiator or responder or both. So what you choose depends on what type of scenario you are trying to make work. The current drafts have significant value for many situations where IPsec can be used by clients initiating TCP/UDP and other protocol "connections" over IPsec through one or more NATs, where the NAT is not involved in any way and simply passes UDP traffic with NAT or NAPT operations on the packets. If your complaint is that it isn't perfect solution for IPsec IPv4 through NATs, then my answer is, yes, but it will help us bridge the gap and secure IPv4 traffic in many scenarios before IPv6 is more generally available. -----Original Message----- From: Rajesh Patel [mailto:rajeshmpatel@yahoo.com] Sent: Tuesday, September 17, 2002 6:44 PM To: ipsec@lists.tislabs.com Subject: RE: IPSec NAT pass-through: how the server distinguish different clients? In a separate thread William Dixon wrote - > NAT-Traversal - We are almost done. It's more than 1 1/2 years after > the Feb '01 drafts for UDP encapsulation, and the significant revision > of draft-02 Feb '02 to use a non-500 UDP port due to IPsec aware NATs. > These drafts are in last call WG, and should solve the remaining > technical blocker for transition from PPTP to L2TP/IPsec for those who > want to use the Windows native VPN client. The NAT-T drafts also > provide the solution for IPsec tunnel mode VPN clients. So all > IPsec-based VPN usages are served. I have been following the NAT Traversal draft (draft-ietf-ipsec-udp-encaps-03.txt) for a while. The only reason to consider this solution is to allow multiple clients behind a NAT to connect to the same server using transport mode. However, I just don't see it working in real life situations. The biggest problem that I see is the conflict "traffic-desc" mentioned in the draft (Section 5.3), where traffic-desc is the port/protocol pair. If two machines happen to pick the same port/protocol, then this solution does not work. For TCP, most TCP/IP implementations pick source port starting from around 1025 (after skipping system ports). So the chances of two machines picking up the same source port are very high. The chances of destination port conflict are going to be very high since these are going to be a few standard ports (such as HTTP, telnet etc.). For UDP, it is even worse. Since many UDP applications pick their own source port, this means that one can not use the same UDP application on two different machines behind the same NAT. To me there does not seem to be any advantage in using this approach over IPSec pass-through. Why is IETF even considering standardizing this draft when the draft itself mentions so many limitations that are so glaring and requires modifications to IKE? Raj __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From owner-ipsec@lists.tislabs.com Tue Sep 24 18:57:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8P1vXv25315; Tue, 24 Sep 2002 18:57:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19670 Tue, 24 Sep 2002 21:19:39 -0400 (EDT) Date: 24 Sep 2002 21:00:41 -0400 Message-ID: <009401c2642e$f8fe16f0$366ae640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Jan Vilhuber'" , " " Subject: RE: Merging IKEv2 and JFKr? 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some replies to the entire discussion of last week (not just Jan's message): I acknowledge the need for some compromise. But I do agree with Charlie's earlier observation that any IKEv2-JFKr will probably be inferior (IMHO) to the original IKEv2 draft. It was too long in coming, but the IKEv2 draft really did represent the logical clarification and evolution of IKE. It is neither unrealistic (what I like to call "simplicity by omission"), nor politically motivated, nor unnecessarily innovative. So as far as I'm concerned, any merging of the drafts is going to be more of a "minimize the damage" type of operation than a "best of both worlds" scenario. Like Jan said, extensibility is the number 1 concern about any such Frankenstein/chimera. From our earlier survey, I concluded that there is a rough consensus (at least among implementers) that extensibility is a good thing. In my experience, extensibility doesn't just pay off in the long run; to some extent it pays off now. We don't all live in a fantasy world where we can wait until a draft reaches Internet Standard status before we start shipping. Many of us find ourselves constantly chasing a moving target. Obviously you can't anticipate everything, but failure to account for future development results in some really ugly kludges... the Internet is full of them. BTW, whatever became of the SOI discussion summary that Barbara promised to post a couple of months ago? It was supposed to summarize the popular opinion on each issue, confirm the requirements, and influence the design direction. In regard to a few other issues that have been brought up recently: Speaking as someone who successfully implemented the revised hash, I don't particularly want to go back to the old way of doing it. There are many ways to handle incoming IKE messages, but for those of us who do most of our IKE processing on pre-parsed packets it is much easier to sign/hash an arbitrary blob of data than to assemble the buffer piecemeal. The half-encrypted message idea doesn't particularly appeal to me, but I won't claim that we can't handle it. The protocol doesn't rely on encryption for security, so there's no real danger of this modification introducing security holes. I'm really not a big fan of the "repeat payloads from message 1 in message 3" idea. People complained about IKE being too complicated because you need code to parse every payload twice (once for main mode and once for aggressive), but this strategy has leads to the same result (plus fragmentation, bandwidth wastage, etc). I also endorse the "URL to a cert" suggestion. I will deal with the 4 vs 6/4 issue in a separate message, since Radia branched off a new thread. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > Sent: Monday, September 16, 2002 8:27 PM > To: ipsec@lists.tislabs.com > Subject: Merging IKEv2 and JFKr? > > > Or "How to dress up Frankenstein to look presentable". > > I'm wondering about the wisdom of merging IKEv2 with JFK'isms. Seeing > that I haven't read the revised IKEv2+JFK proposal (because it's not > out yet), this is mostly based on my thoughts of what *I* would do, > were I to merge the two. I expect there's not that many ways to skin > this cat. > > Firstly, it doesn't seem needed. The difference is that JFK > assumes it's > ALWAYS under attack, versus IKEv2 that gives you a mechanism to verify > the initiator's 'liveness' if you think you're under attack. So it's > not like IKEv2 doesn't address DoS issues. It does. > > Code messiness. You may poo-poo that concept, but we all understand > IKE code and the coding-/design- philosophy behind it. You may not > like it, but there's a certain amount of expertise out there. By > adding JFK'isms into the mix, you're now mixing two very different > philosophies into one protocol, which sounds like it's prone to be > buggy, hard to analyze, etc etc. Instead of a protocol designed by a > committee, we now have a protocol designed by TWO committees. > > Along the same lines (or maybe 'by example'), IKE has always been > 'encrypted packet' or 'non encrypted packet'. Now we have a > 'half-encrypted' packet. Sigh. If someone has a clean way of doing > this (An 'encrypted payload' similar to Kink's KINK_ENCRYPT payload > (section 5.1.8 of the kink draft, FWIW) maybe?), maybe this can be > made to work, if absolutely necessary. > > Extensibility: I keep thinking that prior to the SOI discussions, we > had talked about simplifying IKEv1 hashing, so that ALL payloads are > hashed and authenticated, no matter what they were. That has clear > implications to extensibility, i.e. future payloads. I realize one of > JFK's goals was 'non-extensibility', but I thought I saw rough > consensus towards extensibility during the recent chinese-menu > mails... Now by merging JFKr into IKEv2, we complicate the hashing > mechanism again to the point where we have to think about which > payloads can be part of the hash and which can't (also, which payloads > must be repeated and which mustn't or don't need to). > > Legacy Authentication: This is really a subset of "extensibility". I'm > trying to fit some legacy authentication scheme into IKEv2, and I have > some ideas. Trying to fit them into an IKEv2+JFK protocol (assuming > what's in my mind is similar to what Charlie is working on) makes it > that much harder. > > Packet sizes: By repeating msg1 in msg3, msg3 necessarily gets > larger. William kept trying to get people to realize that we have a > UDP fragmentation issue, when certs (or cert chains) are sent, so this > seems like a move in the wrong direction. Paul Hoffman had some ideas > of changing the ID payload so that it can include a URL, i.e. pointer > to the cert instead of the cert itself, and that may help. > > Based on my gut feeling, I vote to leave IKEv2 as is, rather than > grafting JFK'isms onto IKEv2. If it gave us something we can't live > without, I wouldn't have that much of an issue with it, but I don't > see a very good reason to do it (the cost outweighs the gain). > > Flame away. "Me too's" or "Ditto's" highly encouraged. > > jan > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > http://www.eff.org/cafe > > From owner-ipsec@lists.tislabs.com Tue Sep 24 18:57:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8P1vbv25328; Tue, 24 Sep 2002 18:57:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19664 Tue, 24 Sep 2002 21:17:39 -0400 (EDT) Date: 24 Sep 2002 20:58:40 -0400 Message-ID: <009301c2642e$b0a5bc00$366ae640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Radia Perlman - Boston Center for Networking'" , " " , " " Subject: RE: Regarding pre-round trip for stateless cookie (Jan's issue) 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200209171937.g8HJbt824243@sydney.East.Sun.COM> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My opinion of the "always 4 message" technique is that it is just a case of JFK being unnecessarily innovative. Getting DoS protection in 4 messages may be technically cool, but it doesn't really mean much. Under heavy load you have to expect increased latency, and the small message size and streamlined code path of IKEv2 should actually help throughput relative to JFK. I use the term "under load" rather than "under attack" since I figure that implementers would use a simple algorithm based on CPU+memory usage to decide when to enter 6 mode, as Paul pointed out earlier. ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Radia Perlman - > Boston Center for Networking > Sent: Tuesday, September 17, 2002 3:38 PM > To: ipsec@lists.tislabs.com; vilhuber@cisco.com > Subject: Regarding pre-round trip for stateless cookie (Jan's issue) > > > Re: > From: Jan Vilhuber > > I'm wondering about the wisdom of merging IKEv2 with > JFK'isms. Seeing > that I haven't read the revised IKEv2+JFK proposal > (because it's not > out yet), this is mostly based on my thoughts of what > *I* would do, > were I to merge the two. I expect there's not that many > ways to skin > this cat. > > First a nontechnical point...I've changed the subject line > because I think > it's always better to focus on a particular technical detail > rather than > which spec something might have come from. At this point there are not > n candidate proposals with n sets of authors, but instead a single > draft that all the authors of all the drafts, and actually, everyone > in the WG, is collaborating on. Everyone wants something that > is correct, > reasonably simple, and reflects as close as can be measured, > the feelings > of the WG. > > Back to the technical issue Jan raised, which I'll call "4/6 > vs 4", where > "4/6" means letting Bob, if he wants to do stateless cookies, request > an optional round trip before the 4-message exchange. > In the greater scheme of things, I don't think this issue > matters all that much, > but I've changed my mind about this recently and it would be > good if the > WG could weigh in, if people (especially implementers) have strong > opinions. The summary is that I originally believed > in "4", but now that I've helped work out the details of "4", > at this point I agree with you, Jan, that "4/6" seems simpler, but > I also don't think it's all that important and can live with > either way. > > I'd been arguing about this very point with my original coauthors > Dan Harkins and Charlie Kaufman since before our first draft. I wanted > 4, they wanted 4/6. > They were not able to explain to me very eloquently at the time > why they wanted to > do 4/6. It seemed to me that the WG would think a 4 message exchange > would be preferable to a (4, sometimes 6) message exchange. > At first Dan and > Charlie > just told me that it would be "a pain in the neck". And when I pressed > for more details they used some of your arguments, > like "half the message encrypted, > half unencrypted", which didn't seem to me like it should be all that > much of a hassle. Then Charlie brought up the fragmentation attack, > and I was convinced that the 4/6 method was better, because it keeps > all messages small until the stateless cookie has been returned, so > that one could build an implementation that saved reassembly resources > for IP addresses that have returned stateless cookies. > > It was probably me that suggested, though, in order to look more like > a "merged" proposal, that we make the modification to always > be 4 messages. > It was only after we were working out the details that I > understood what > Charlie and Dan meant by "pain in the neck". It's doable, but > the protocol > is a lot more complicated. > > I don't think it's necessary for any "political" reasons that > we do anything > any particular way. I think at this point it's clear everyone > is collaborating > on one proposal, and wants to do something correct, as simple > as possible, > and reflective of the WG's wishes. If we're not choosing > "proposal A from > this set of authors" vs "proposal B from this set of authors" > and instead > focusing on a well-defined technical point, and the WG has > sound arguments > for a particular opinion, we'll all support that way of doing > things ("sound" > means that the result would be correct, not overly complex, etc.) > > So let's focus on this one technical issue. > > The 4/6 protocol can be summarized as follows: > messages 1 and 2 are D-H exchange (and nonces, and crypto > negotiation) > messages 3 and 4 are encrypted and integrity protected with > a function > of the D-H key, and consist of the identities, and proofs > of knowledge > of the secret, using some function of messages 1 and 2. > The simplest > and easiest, implementation-wise, is to sign all of > messages 1 and 2, > exactly as transmitted. We modified that to "sign your own message > concatenated with the other side's nonce", at Sara > Bitan's suggestion, > which seemed like it wouldn't be harder, and certainly all fields > would be still protected in one or the other side's signature. We > were trying to avoid the issue Jan brought up of wrangling over > which fields should be covered, and what the canonical > order would be, > and having implementations have to move all the fields around to > create the canonical hash. > if Bob wants to use a stateless cookie before doing the handshake, > he replies to a message 1 without a cookie by saying "try again, > using this cookie" > > The 4-always protocol is more conceptually complicated, since > Bob, when > he receives message 3, cannot be assumed to have any > state. Since there > are parts of messages 1 and 2 that need to be integrity > protected (like > the crypto negotiation), Alice has to repeat all of message 1, and > Bob has to be able to reproduce, bit for bit, what he would have > generated as message 2, so that he can sign that. There are the > issues you brought up, Jan, about which fields need to be in the > signature, which need to be > repeated, etc. There are many strategies for how Bob might want > to use the fields of cookie and nonce to encode state for himself. > We don't want to constrain an implementation, and yet we need to > define at least one way that works. > > Radia > > From owner-ipsec@lists.tislabs.com Wed Sep 25 07:03:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PE38v01502; Wed, 25 Sep 2002 07:03:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20957 Wed, 25 Sep 2002 09:30:19 -0400 (EDT) Message-ID: <3D91A3BE.2070904@6wind.com> Date: Wed, 25 Sep 2002 13:53:34 +0200 From: Jean-Mickael Guerin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: fr-fr MIME-Version: 1.0 To: mgupta@iprg.nokia.com Cc: ipsec@lists.tislabs.com Subject: draft-gupta-ospf-ospfv3-auth-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I have a question concerning SA granularity. The draft says: In the incoming path, OSPF protocol, SPI and ingress interface ID MUST be used to locate the SA to be applied. If ESP is used with non-null encryption, I think that OSPF protocol field is not available. If 'm correct, I think in this case we can only use SPI and ingress interface. If incoming packet is decrypted correctly, then we can check against an inbound policy linked to this SA, which would have protocol selector set to OSPF protocol. Regards, Jean-Mickael From owner-ipsec@lists.tislabs.com Wed Sep 25 11:48:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PImav17547; Wed, 25 Sep 2002 11:48:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21643 Wed, 25 Sep 2002 14:16:09 -0400 (EDT) Message-ID: <20020925181113.49642.qmail@web13902.mail.yahoo.com> Date: Wed, 25 Sep 2002 11:11:13 -0700 (PDT) From: Rajesh Patel Subject: RE: IPSec NAT pass-through: how the server distinguish different clients? To: William Dixon , ipsec@lists.tislabs.com In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC105D01A47@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William - > Raj, what scenario are you talking about ? Where are the NATs, where > are the initiators, responders, what is their policy, tunnel/transport, > is there app integration with IKE or is it transparent to IKE, is IPsec > integrated into the initiator/responder TCPIP stack or is it > bump-in-the-wire, a mix, etc ? I am discussing the scenario from Section 5.3 of your draft. There it clearly states that the proposal may not work when multiple clients behind a NAT are communicating with a server using Transport mode. In my previous e-mail, I explained what will not work. To me, this is the *only* scenario of interest, because I cannot think of any other case that is not solved by the already deployed method of IPsec pass-thru. Can you? > Isn't this the general problem with IKE quick mode SA proposals going > through a NAT unmodified ? The NAT's support IKE/ESP passthrough > doesn't solve that either. No it isn't. > Even being able to talk to the first-hop NAT > to learn your external IP doesn't solve the upstream NAT problem. I did not suggest that. It is not even relevant to my question. The problem arises because traffic-desc (transport layer port numbers as IP address is same) may clash between clients that are behind NAT. What has that got to do with NATs IP address? I think you might be confusing the check-sum problem with the problem that I have pointed out. > Brian's mail outlined many of implementation techniques possible to > solve the client behind a NAT problem, which can require work on the > initiator or responder or both. He gave six options: 1) First two have patent issues. 2) Next two are plain ridiculous. Application level fix in a network layer solution? Tying application to IKE? IPR issues even there! 3) Last two amount to abandoning transport mode. > If your complaint is that it isn't perfect solution for IPsec IPv4 My complain is that 50% of your draft is trying to solve a problem that IPsec pass-thru already solves and remaining 50% of your draft proposes a solution that does not work! Basically your draft requires IPsec vendors to implement stuff the does not seem to be necessary, considering the proliferation of NATs with IPsec pass-thru. Versions after Versions of this flawed draft have been released over the past two years, and we have had to waste our time and money implementing them. > through NATs, then my answer is, yes, but it will help us bridge the gap > and secure IPv4 traffic in many scenarios before IPv6 is more generally > available. When are you people going to figure out that NATs are not going to disappear when IPv6 is deployed? Whenever that happens..... Raj __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-ipsec@lists.tislabs.com Wed Sep 25 17:29:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8Q0Tlv05683; Wed, 25 Sep 2002 17:29:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22328 Wed, 25 Sep 2002 19:57:55 -0400 (EDT) X-mProtect: <200209252357> Nokia Silicon Valley Messaging Protection Message-ID: <3D924D4D.35EBF621@iprg.nokia.com> Date: Wed, 25 Sep 2002 16:57:02 -0700 From: Mukesh Gupta Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Mickael Guerin CC: ipsec@lists.tislabs.com, nmelam@iprg.nokia.com, OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt References: <3D91A3BE.2070904@6wind.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jean-Mickael, Thanks for the correction. You are right. Word OSPF needs to be removed from there. The new sentence should be "In the incoming path, protocol, SPI and ingress interface ID MUST be used to locate the SA to be applied." where the protocol can be ESP or AH. Check against the inbound policy linked to the SA should be done by the general IPsec implementation. I don't see anything that needs to be handled differently for OSPFv3. So, I think, we don't need to add anything about it in this draft. I will make the suggested correction in the next version of the draft. Cheers. Mukesh Jean-Mickael Guerin wrote: > Hello, > I have a question concerning SA granularity. The draft says: > In the incoming path, OSPF protocol, SPI and ingress interface ID MUST > be used to locate the SA to be applied. > If ESP is used with non-null encryption, I think that OSPF protocol > field is not available. > If 'm correct, I think in this case we can only use SPI and ingress > interface. If incoming packet is decrypted correctly, then we can check > against an inbound policy linked to this SA, which would have protocol > selector set to OSPF protocol. > > Regards, > > Jean-Mickael -- ****************************************************************** Work fascinates me. I can look at it for hours ! ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ipsec@lists.tislabs.com Thu Sep 26 03:09:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QA93v25219; Thu, 26 Sep 2002 03:09:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA23459 Thu, 26 Sep 2002 05:30:56 -0400 (EDT) To: Mukesh Gupta Cc: Jean-Mickael Guerin , ipsec@lists.tislabs.com, nmelam@iprg.nokia.com, OSPF@DISCUSS.MICROSOFT.COM In-reply-to: mgupta's message of Wed, 25 Sep 2002 16:57:02 MST. <3D924D4D.35EBF621@iprg.nokia.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: draft-gupta-ospf-ospfv3-auth-01.txt From: itojun@iijlab.net Date: Thu, 26 Sep 2002 18:30:06 +0900 Message-Id: <20020926093006.70B804B22@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Thanks for the correction. You are right. Word OSPF needs to be removed from >there. The new sentence should be >"In the incoming path, protocol, SPI and ingress interface ID MUST be used >to locate the SA to be applied." >where the protocol can be ESP or AH. is there any need for documenting it? i mean, this is exactly the same as normal IPsec processing. i think dropping the descrption and pointing people to ipsec document is the right thing to do. (the tricky thing is that you need to be aware of link-local scopes, which may be worth documenting) itojun From owner-ipsec@lists.tislabs.com Thu Sep 26 05:23:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QCNTv06474; Thu, 26 Sep 2002 05:23:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23644 Thu, 26 Sep 2002 07:55:20 -0400 (EDT) From: sakari.poussa@nokia.com X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Protocol and port fields in selectors Date: Thu, 26 Sep 2002 14:46:03 +0300 Message-ID: Thread-Topic: Protocol and port fields in selectors Thread-Index: AcJlUklmyapNe1D0Qhy+5vfnS6G92g== To: X-OriginalArrivalTime: 26 Sep 2002 11:46:04.0176 (UTC) FILETIME=[4B1DC100:01C26552] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id HAA23638 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a question about protocol and src/dst port fields in the SAD selectors. Is it allowed to have the protocol field as wildcard and still specify src/dst port as a specific value? Or is it so that transport layer protocol which actually has ports (like TCP/UDP/SCTP) must be specified along with the ports. I guess it is the latter case according to the rfc2401, page 20 table, but I just wanted to be sure. -sakari From owner-ipsec@lists.tislabs.com Thu Sep 26 06:42:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QDggv11170; Thu, 26 Sep 2002 06:42:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23872 Thu, 26 Sep 2002 09:09:51 -0400 (EDT) Date: Thu, 26 Sep 2002 09:10:17 +0200 From: Ghislaine Labouret To: ipsec@lists.tislabs.com Cc: Philippe Cousin Subject: Potential bakeoff in France in 2003 Message-ID: <20020926091017.A53358@itesec.hsc.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the Yokohama IETF, people asked if there were plans for a new IPsec bakeoff. The ETSI Interoperability Service, called Plugtests (currently organizing an IPv6 interoperability event) is willing to organize one in France in 2003, in particular as funding support from EU can be found. See more info on the service at www.etsi.org/plugtests In order to determine interest for such an event, we would like to get feedback from the members of the list: - Would you be willing to come to such an event? - What would you like to test? - Which timing would be more suitable? Please send your answer and interest for such an event to plugtests@etsi.fr Thank you. -- Ghislaine Labouret, HSC (www.hsc.fr/ipsec/) Philippe Cousin, ETSI From owner-ipsec@lists.tislabs.com Thu Sep 26 08:28:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QFScv17090; Thu, 26 Sep 2002 08:28:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24174 Thu, 26 Sep 2002 10:49:55 -0400 (EDT) Message-ID: <3D931E46.1010505@isi.edu> Date: Thu, 26 Sep 2002 07:48:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sakari.poussa@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: Protocol and port fields in selectors References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sakari.poussa@nokia.com wrote: > Hi, > > I have a question about protocol and src/dst port fields in the SAD selectors. > > Is it allowed to have the protocol field as wildcard and still specify src/dst > port as a specific value? Or is it so that transport layer protocol which actually > has ports (like TCP/UDP/SCTP) must be specified along with the ports. > > I guess it is the latter case according to the rfc2401, page 20 table, but > I just wanted to be sure. Not all transport protocols even have ports (e.g., IP, ICMP, and EGP are all 'transport' protocols, and none have ports). The port field is defined only relative to a particular transport protocol. To cover multiple protocols under one port (e.g., TCP/NFS and UDP/NFS) seems to require multiple selectors. Joe From owner-ipsec@lists.tislabs.com Thu Sep 26 10:45:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QHjXv25027; Thu, 26 Sep 2002 10:45:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24461 Thu, 26 Sep 2002 13:10:54 -0400 (EDT) Message-ID: <3D933D2B.2070607@nortelnetworks.com> Date: Thu, 26 Sep 2002 13:00:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com CC: ipsec@lists.tislabs.com Subject: IKEv2 next version References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I was wondering about the status of the revised version of the IKEv2 draft (-03-). Thanks. regards, Lakshminath Charlie_Kaufman@notesdev.ibm.com wrote: > > > > I apologize for the delay. I was hoping to get a new draft out by the > end of August, but a draft I sent to the smaller author community > generated such a volume of feedback that I'm still trying to reconcile > it all. > From owner-ipsec@lists.tislabs.com Thu Sep 26 11:33:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8QIXev26253; Thu, 26 Sep 2002 11:33:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24583 Thu, 26 Sep 2002 14:02:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org (Unverified) Message-Id: In-Reply-To: <20020926091017.A53358@itesec.hsc.fr> References: <20020926091017.A53358@itesec.hsc.fr> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 26 Sep 2002 11:02:18 -0700 To: Ghislaine Labouret , ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Potential bakeoff in France in 2003 Cc: Philippe Cousin Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:10 AM +0200 9/26/02, Ghislaine Labouret wrote: >At the Yokohama IETF, people asked if there were plans for a new IPsec >bakeoff. The ETSI Interoperability Service, called Plugtests (currently >organizing an IPv6 interoperability event) is willing to organize one in >France in 2003, in particular as funding support from EU can be found. >See more info on the service at www.etsi.org/plugtests Could you give us a guess about how much participation might cost per person or per company? --Paul Hoffman, Director --VPN Consortium From f10fj2jvct@bellsouth.net Thu Sep 26 18:49:34 2002 Received: from mail.grepa.com (mail.grepa.com [210.16.21.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8R1nPv21304 for ; Thu, 26 Sep 2002 18:49:27 -0700 (PDT) Received: from interscan ([190.20.1.10]) by mail.grepa.com (8.9.3/8.9.3) with SMTP id JAA27940; Fri, 27 Sep 2002 09:20:11 +0800 Received: from 212.10.193.90 by interscan (InterScan E-Mail VirusWall NT); Tue, 24 Sep 2002 07:06:29 +0800 From: "Bernard Tori" To: hjdej@newmail.net, holley@china.com, jblakebrooks@netscape.net, huevobas@lycos.com, hung.loan.boston@postoffice.worldnet.att.net, heliumboy@excite.com, howlett@camtech.net.au, hsu@amerauto.com, holger-nebel@addcom.de, igotcha@monumental.com, hugheap@auburn.edu, h2eau@iserv.net, howie@panetwork.com, hrocha@sparksplug.com, holleman@westsound.com, gsexton@mtpearl.nf.ca, ietf-ipsec@imc.org, hospitality@wiley.com, iace@artsci.net, ildiko@writeme.com, hanrahan@ulsterbank.com, hr58@psi.net, igorek@goti.net, honey@kansas.net, gweissman@summitviews.com, hogeye265@lycos.com, idle@mindfukers.com, honp@ktm.x400gw.i, gowins@excite.com, i-honda@dns.marutakai.or.jp, hartzband@earthlink.net, gwalrath@zzzzzzzzz.net, hotpics@webbox.com, gwiggins@angloamerican.com, i.larose@thedoghousemail.com, illes@primary.net, gurlma@gurlmail.com, joshd85@msn.com, jonathannelson@msn.com, imth@damngood.com, gsandre@redcross.ca, gr82bhere@usa.net, gsandoz@worldnet.att.net, ia@asiamail.com, immblap@netvigator.com, homesnland@earthlink.com, ill@bdt.com, icanpaint@webtv.net Subject: Wipe Out Tax Debt Reply-To: thomasrebaQ23C4@excite.com Content-type: text/html; charset=ISO-8859-1 X-Mailer: AOL 6.0 for Windows US sub 10539 Message-ID: Date: Mon Sep 23 13:57:24 2002
Wipe Out Tax Debt, End your IRS tax problems!

Would you like to resolve IRS and State tax problems quickly and easily? Would you like to save yourself a lot of money? If you owe $5,000 USD or more, read on!

Our nationally recognized tax attorneys, paralegals, legal assistants and licensed enrolled agents can help you no matter where you live in the US. By directly negotiating with the IRS and State authorities we can settle your debts for far less than what you currently owe!

For a FREE analysis and more information on this subject, please fill out the short form below (all fields required). In the debt size field please also include any penalties or interest that you owe.


Full Name   
State   
Phone Number   
Time to Contact   
Tax Debt Size   
E-Mail   
 


Thank you for your time! Please submit this form only once, and please allow 5-10 business days for processing.


If you wish to receive no further such advertisements, please reply to this email with the word Remove in the subject line.

f10fj2jvct From owner-ipsec@lists.tislabs.com Fri Sep 27 07:15:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8REF0v05913; Fri, 27 Sep 2002 07:15:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26337 Fri, 27 Sep 2002 09:27:56 -0400 (EDT) Message-ID: <3D941441.2030307@6wind.com> Date: Fri, 27 Sep 2002 10:18:09 +0200 From: Jean-Mickael Guerin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: fr-fr MIME-Version: 1.0 To: itojun@iijlab.net, Mukesh Gupta Cc: ipsec@lists.tislabs.com, nmelam@iprg.nokia.com, OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Finally I think that this way to secure ospfv3 can be applied to other protocols that exchange both multicast and unicast packets. I mean that for example we can do the same for RIPng. Just need to replace OSPF protocol 89 with RIPng/UDP port 521. The requirement is just on incoming path since destination address is ignored, use static keys, and as Itojun said, SPD aware of link-local scope. May be reserved SPI can be recommanded to facilate configuration. Furthermore I beleive it works for NDP, as far as SPD selectors can permit it (e.g. protocol ICMPv6, type=neighbor solicit). But the scenario must support the assumption that hosts can share a key. Regards, Jean-Mickael itojun@iijlab.net wrote: >>Thanks for the correction. You are right. Word OSPF needs to be removed from >>there. The new sentence should be >>"In the incoming path, protocol, SPI and ingress interface ID MUST be used >>to locate the SA to be applied." >>where the protocol can be ESP or AH. >> > > is there any need for documenting it? i mean, this is exactly > the same as normal IPsec processing. i think dropping the descrption > and pointing people to ipsec document is the right thing to do. > (the tricky thing is that you need to be aware of link-local scopes, > which may be worth documenting) > > itojun > > -- Jean-Mickael GUERIN Tel : +33 1 39 30 92 33 Web site : www.6wind.com From owner-ipsec@lists.tislabs.com Fri Sep 27 07:15:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8REF5v05931; Fri, 27 Sep 2002 07:15:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26343 Fri, 27 Sep 2002 09:28:58 -0400 (EDT) X-Mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: Potential bakeoff in France in 2003 Date: Fri, 27 Sep 2002 12:13:42 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A333311E3@email10.etsihq.org> Thread-Topic: Potential bakeoff in France in 2003 Thread-Index: AcJlhuMDWe46nTLbQmOBye2Vht0BCAAh5nmS From: "Philippe Cousin" To: "Paul Hoffman / VPNC" , "Ghislaine Labouret" , X-OriginalArrivalTime: 27 Sep 2002 10:13:43.0203 (UTC) FILETIME=[8EDA1F30:01C2660E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id GAA26140 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It will be about 500 Euros per participant regards philippe -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Thu 26/09/2002 20:02 To: Ghislaine Labouret; ipsec@lists.tislabs.com Cc: Philippe Cousin Subject: Re: Potential bakeoff in France in 2003 At 9:10 AM +0200 9/26/02, Ghislaine Labouret wrote: >At the Yokohama IETF, people asked if there were plans for a new IPsec >bakeoff. The ETSI Interoperability Service, called Plugtests (currently >organizing an IPv6 interoperability event) is willing to organize one in >France in 2003, in particular as funding support from EU can be found. >See more info on the service at www.etsi.org/plugtests Could you give us a guess about how much participation might cost per person or per company? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Sep 27 10:51:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8RHpIv19715; Fri, 27 Sep 2002 10:51:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27120 Fri, 27 Sep 2002 13:18:24 -0400 (EDT) X-mProtect: <200209271717> Nokia Silicon Valley Messaging Protection Message-ID: <3D9492B3.321113E0@iprg.nokia.com> Date: Fri, 27 Sep 2002 10:17:39 -0700 From: Mukesh Gupta Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Mickael Guerin CC: itojun@iijlab.net, ipsec@lists.tislabs.com, nmelam@iprg.nokia.com, OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt References: <3D941441.2030307@6wind.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are you suggesting that we should make the draft generic to all such protocols instead of being specific to OSPFv3 ?? Jean-Mickael Guerin wrote: > Finally I think that this way to secure ospfv3 can be applied to other > protocols that exchange both multicast and unicast packets. I mean that > for example we can do the same for RIPng. Just need to replace OSPF > protocol 89 with RIPng/UDP port 521. > The requirement is just on incoming path since destination address is > ignored, use static keys, and as Itojun said, SPD aware of link-local > scope. May be reserved SPI can be recommanded to facilate configuration. > > Furthermore I beleive it works for NDP, as far as SPD selectors can > permit it (e.g. protocol ICMPv6, type=neighbor solicit). But the > scenario must support the assumption that hosts can share a key. > > Regards, > > Jean-Mickael > > itojun@iijlab.net wrote: > > >>Thanks for the correction. You are right. Word OSPF needs to be removed from > >>there. The new sentence should be > >>"In the incoming path, protocol, SPI and ingress interface ID MUST be used > >>to locate the SA to be applied." > >>where the protocol can be ESP or AH. > >> > > > > is there any need for documenting it? i mean, this is exactly > > the same as normal IPsec processing. i think dropping the descrption > > and pointing people to ipsec document is the right thing to do. > > (the tricky thing is that you need to be aware of link-local scopes, > > which may be worth documenting) > > > > itojun > > > > > > -- > > Jean-Mickael GUERIN > Tel : +33 1 39 30 92 33 > Web site : www.6wind.com -- ****************************************************************** Your attitude is more important than your aptitude in determining your altitude. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ipsec@lists.tislabs.com Sat Sep 28 04:38:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8SBcWv18826; Sat, 28 Sep 2002 04:38:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA28688 Sat, 28 Sep 2002 06:56:54 -0400 (EDT) X-Originating-IP: [217.29.140.5] From: "Mohammad Awad" To: ipsec@lists.tislabs.com Subject: using ip-based cert. in NAT-T Date: Sat, 28 Sep 2002 12:56:48 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Sep 2002 10:56:48.0901 (UTC) FILETIME=[BE761350:01C266DD] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Neither the internal IPs nor their certificates can be registered in the DNS. This makes the other peer which is negotiating IKE main mode with the NATed host, uses a certificate with subject rather than the IP to (may be FQDN) to authenticate the NATed host, which may be less secure. What if the internal hosts behind the NAT can -somehow- register their certificates in the DNS with an approach like this: Each NATed host will be provided an identifier that is unique amongst the NATed hosts behind one NAT (ie, those hosts having the same external IP). This NAT-ID will be included in the options fields of the IP header of the NATed packet. Another RR.s in the DNS are to be added, with extensions to hold that NAT-ID, one RR record for each NATed host. Then the certificates can be registered in that RR NAT record and used by the remote peer to obtain the certificate of the NATed host. how do you find that approach? _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ipsec@lists.tislabs.com Sat Sep 28 04:38:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8SBcWv18825; Sat, 28 Sep 2002 04:38:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA28689 Sat, 28 Sep 2002 06:56:54 -0400 (EDT) X-Originating-IP: [217.29.140.5] From: "Mohammad Awad" To: ipsec@lists.tislabs.com Subject: using ip-based cert. in NAT-T Date: Sat, 28 Sep 2002 12:56:28 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Sep 2002 10:56:30.0088 (UTC) FILETIME=[B33F7080:01C266DD] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Neither the internal IPs nor their certificates can be registered in the DNS. This makes the other peer which is negotiating IKE main mode with the NATed host, uses a certificate with subject rather than the IP to (may be FQDN) to authenticate the NATed host, which may be less secure. What if the internal hosts behind the NAT can -somehow- register their certificates in the DNS with an approach like this: Each NATed host will be provided an identifier that is unique amongst the NATed hosts behind one NAT (ie, those hosts having the same external IP). This NAT-ID will be included in the options fields of the IP header of the NATed packet. Another RR.s in the DNS are to be added, with extensions to hold that NAT-ID, one RR record for each NATed host. Then the certificates can be registered in that RR NAT record and used by the remote peer to obtain the certificate of the NATed host. how do you find that approach? _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ipsec@lists.tislabs.com Sat Sep 28 12:49:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8SJnLv20220; Sat, 28 Sep 2002 12:49:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29506 Sat, 28 Sep 2002 15:16:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Sat, 28 Sep 2002 15:07:17 -0400 To: "Amey Gokhale" From: Stephen Kent Subject: Re: Periodic certificate validation check Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:51 PM +0100 9/23/02, Amey Gokhale wrote: >Hi list, > >During IKE, with certificate based authentication method, >validity(CRL checking) of the user certificate is done only during >initial stage that is during SA negotiation. > >If the certificate gets revoked after the connection is established, >does the implementation should check periodically for the validity >of the certificate in between a running connection? If yes then does >some notification need to be generated n sent to the other party >about the revoked certificate? > > >With regards, >Amey Gokhale. Generally, this might be considered overkill. Whatever sort of transaction one executes, there is always the possibility that a cert is revoked during the course of the transaction. Few applications try to do any sort of continuous verification of cert validity. In the IPsec context, SA lifetimes could be constrained to be no longer than the NextIssue date/time for the relevant CRL, but even this may not be critical. Steve From owner-ipsec@lists.tislabs.com Sat Sep 28 13:24:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8SKODv23483; Sat, 28 Sep 2002 13:24:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29555 Sat, 28 Sep 2002 15:59:07 -0400 (EDT) X-Originating-IP: [217.53.1.5] From: "Mohammad Awad" To: ipsec@lists.tislabs.com Subject: using ip-based cert. in NAT-T Date: Sat, 28 Sep 2002 21:58:18 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Sep 2002 19:58:19.0304 (UTC) FILETIME=[64402280:01C26729] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Neither the internal IPs nor their certificates can be registered in the DNS. This makes the other peer which is negotiating IKE main mode with the NATed host, uses a certificate with subject rather than the IP to (may be FQDN) to authenticate the NATed host, which may be less secure. What if the internal hosts behind the NAT can -somehow- register their certificates in the DNS with an approach like this: Each NATed host will be provided an identifier that is unique amongst the NATed hosts behind one NAT (ie, those hosts having the same external IP). This NAT-ID will be included in the options fields of the IP header of the NATed packet. Another RR.s in the DNS are to be added, with extensions to hold that NAT-ID, one RR record for each NATed host. Then the certificates can be registered in that RR NAT record and used by the remote peer to obtain the certificate of the NATed host. how do you find that approach? _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ipsec@lists.tislabs.com Sat Sep 28 17:53:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8T0rsv04646; Sat, 28 Sep 2002 17:53:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29967 Sat, 28 Sep 2002 20:21:44 -0400 (EDT) From: "Jayant Shukla" To: "'Mohammad Awad'" , Subject: RE: using ip-based cert. in NAT-T Date: Sat, 28 Sep 2002 17:18:49 -0700 Message-ID: <000001c2674d$c915d870$0402a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Mohammad Awad > > Neither the internal IPs nor their certificates can be registered in the > DNS. This makes the other peer which is negotiating IKE main mode with the > NATed host, uses a certificate with subject rather than the IP to (may be > FQDN) to authenticate the NATed host, which may be less secure. > What if the internal hosts behind the NAT can -somehow- register their > certificates in the DNS with an approach like this: > Each NATed host will be provided an identifier that is unique amongst the > NATed hosts behind one NAT (ie, those hosts having the same external IP). > This NAT-ID will be included in the options fields of the IP header of the > NATed packet. Another RR.s in the DNS are to be added, with extensions to > hold that NAT-ID, one RR record for each NATed host. > Then the certificates can be registered in that RR NAT record and used by > the remote peer to obtain the certificate of the NATed host. > how do you find that approach? > > Something very similar has been tried by us and it did not work. Most ISPs drop packets with unknown IP options and some very large ISPs drop any packet with IP options. Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Mon Sep 30 07:46:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8UEk3v22509; Mon, 30 Sep 2002 07:46:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02862 Mon, 30 Sep 2002 09:55:47 -0400 (EDT) Message-ID: <3D9824EF.2010102@6wind.com> Date: Mon, 30 Sep 2002 12:18:23 +0200 From: Jean-Mickael Guerin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Mukesh Gupta , ipsec@lists.tislabs.com Cc: itojun@iijlab.net, nmelam@iprg.nokia.com Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt References: <3D941441.2030307@6wind.com> <3D9492B3.321113E0@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mukesh Gupta wrote: >Are you suggesting that we should make the draft generic to all such protocols >instead of being specific to OSPFv3 ?? > Well I think the description of the incoming path could be moved into a generic one. This part of the draft can be helpful to secure RIPng, and other protocols that exchanges both multicast and unicast packets within a link scope. OSPFv3 still needs its specific sections,Virtual link for instance, and perhaps you could point out the use of LSA sequence ID which helps against the lake of replay protection. Jean-Mickael > >Jean-Mickael Guerin wrote: > >>Finally I think that this way to secure ospfv3 can be applied to other >>protocols that exchange both multicast and unicast packets. I mean that >>for example we can do the same for RIPng. Just need to replace OSPF >>protocol 89 with RIPng/UDP port 521. >>The requirement is just on incoming path since destination address is >>ignored, use static keys, and as Itojun said, SPD aware of link-local >>scope. May be reserved SPI can be recommanded to facilate configuration. >> >>Furthermore I beleive it works for NDP, as far as SPD selectors can >>permit it (e.g. protocol ICMPv6, type=neighbor solicit). But the >>scenario must support the assumption that hosts can share a key. >> >>Regards, >> >>Jean-Mickael >> >>itojun@iijlab.net wrote: >> >>>>Thanks for the correction. You are right. Word OSPF needs to be removed from >>>>there. The new sentence should be >>>>"In the incoming path, protocol, SPI and ingress interface ID MUST be used >>>>to locate the SA to be applied." >>>>where the protocol can be ESP or AH. >>>> >>> is there any need for documenting it? i mean, this is exactly >>> the same as normal IPsec processing. i think dropping the descrption >>> and pointing people to ipsec document is the right thing to do. >>> (the tricky thing is that you need to be aware of link-local scopes, >>> which may be worth documenting) >>> >>>itojun >>> >>> >>-- >> >>Jean-Mickael GUERIN >>Tel : +33 1 39 30 92 33 >>Web site : www.6wind.com >> > >-- >****************************************************************** >Your attitude is more important than your aptitude in determining your altitude. >****************************************************************** >Mukesh Gupta >Phone: (650) 625-2264 >Cell : (650) 868-9111 >http://www.iprg.nokia.com/~mgupta >****************************************************************** > > From owner-ipsec@lists.tislabs.com Mon Sep 30 09:21:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8UGL6v26612; Mon, 30 Sep 2002 09:21:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03115 Mon, 30 Sep 2002 11:46:12 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3D933D2B.2070607@nortelnetworks.com> Subject: Re: IKEv2 next version To: Lakshminath Dondeti Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_09102002 September 10, 2002 Message-ID: Date: Sat, 28 Sep 2002 23:14:13 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_09252002NP|September 25, 2002) at 09/30/2002 11:40:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I was wondering about the status of the revised version of the IKEv2 > draft (-03-). Thanks. > > regards, > Lakshminath It is getting close. I have a draft that incorporates suites and the "always 4 messages", but there are still more comments to process and there is a raging 4 vs. 4/6 debate. I'd like to post something as an I-D that is self-consistent and that I believe could advance unchanged if there were no other comments (as the previous IKEv2 drafts were). If I can't get there in the next week, I should probably post what I have in order to focus the debate. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Mon Sep 30 14:00:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8UL0bv12223; Mon, 30 Sep 2002 14:00:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03616 Mon, 30 Sep 2002 16:17:37 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15768.45347.768493.526354@thomasm-u1.cisco.com> Date: Mon, 30 Sep 2002 13:16:35 -0700 (PDT) To: andrew.krywaniuk@alcatel.com Cc: "'Jan Vilhuber'" , " " Subject: RE: Merging IKEv2 and JFKr? In-Reply-To: <009401c2642e$f8fe16f0$366ae640@ca.alcatel.com> References: <009401c2642e$f8fe16f0$366ae640@ca.alcatel.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 So I wasn't at the last meeting, but it's seemed fairly obvious to me that there's been consensus around IKEv2 (fwiw, I've never been anti-IKEv2). What is to be gained by trying to merge these two other than a sort of Medieval peace by marrying different bloodlines? JFK's big appeal, IMO, was its simplicity. The WG has clearly decided that wasn't compelling enough argument. Mike Andrew Krywaniuk writes: > Some replies to the entire discussion of last week (not just Jan's message): > > I acknowledge the need for some compromise. But I do agree with Charlie's > earlier observation that any IKEv2-JFKr will probably be inferior (IMHO) to > the original IKEv2 draft. It was too long in coming, but the IKEv2 draft > really did represent the logical clarification and evolution of IKE. It is > neither unrealistic (what I like to call "simplicity by omission"), nor > politically motivated, nor unnecessarily innovative. So as far as I'm > concerned, any merging of the drafts is going to be more of a "minimize the > damage" type of operation than a "best of both worlds" scenario. > > Like Jan said, extensibility is the number 1 concern about any such > Frankenstein/chimera. From our earlier survey, I concluded that there is a > rough consensus (at least among implementers) that extensibility is a good > thing. In my experience, extensibility doesn't just pay off in the long run; > to some extent it pays off now. We don't all live in a fantasy world where > we can wait until a draft reaches Internet Standard status before we start > shipping. Many of us find ourselves constantly chasing a moving target. > Obviously you can't anticipate everything, but failure to account for future > development results in some really ugly kludges... the Internet is full of > them. > > BTW, whatever became of the SOI discussion summary that Barbara promised to > post a couple of months ago? It was supposed to summarize the popular > opinion on each issue, confirm the requirements, and influence the design > direction. > > In regard to a few other issues that have been brought up recently: > > Speaking as someone who successfully implemented the revised hash, I don't > particularly want to go back to the old way of doing it. There are many ways > to handle incoming IKE messages, but for those of us who do most of our IKE > processing on pre-parsed packets it is much easier to sign/hash an arbitrary > blob of data than to assemble the buffer piecemeal. > > The half-encrypted message idea doesn't particularly appeal to me, but I > won't claim that we can't handle it. The protocol doesn't rely on encryption > for security, so there's no real danger of this modification introducing > security holes. > > I'm really not a big fan of the "repeat payloads from message 1 in message > 3" idea. People complained about IKE being too complicated because you need > code to parse every payload twice (once for main mode and once for > aggressive), but this strategy has leads to the same result (plus > fragmentation, bandwidth wastage, etc). > > I also endorse the "URL to a cert" suggestion. > > I will deal with the 4 vs 6/4 issue in a separate message, since Radia > branched off a new thread. > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > > Sent: Monday, September 16, 2002 8:27 PM > > To: ipsec@lists.tislabs.com > > Subject: Merging IKEv2 and JFKr? > > > > > > Or "How to dress up Frankenstein to look presentable". > > > > I'm wondering about the wisdom of merging IKEv2 with JFK'isms. Seeing > > that I haven't read the revised IKEv2+JFK proposal (because it's not > > out yet), this is mostly based on my thoughts of what *I* would do, > > were I to merge the two. I expect there's not that many ways to skin > > this cat. > > > > Firstly, it doesn't seem needed. The difference is that JFK > > assumes it's > > ALWAYS under attack, versus IKEv2 that gives you a mechanism to verify > > the initiator's 'liveness' if you think you're under attack. So it's > > not like IKEv2 doesn't address DoS issues. It does. > > > > Code messiness. You may poo-poo that concept, but we all understand > > IKE code and the coding-/design- philosophy behind it. You may not > > like it, but there's a certain amount of expertise out there. By > > adding JFK'isms into the mix, you're now mixing two very different > > philosophies into one protocol, which sounds like it's prone to be > > buggy, hard to analyze, etc etc. Instead of a protocol designed by a > > committee, we now have a protocol designed by TWO committees. > > > > Along the same lines (or maybe 'by example'), IKE has always been > > 'encrypted packet' or 'non encrypted packet'. Now we have a > > 'half-encrypted' packet. Sigh. If someone has a clean way of doing > > this (An 'encrypted payload' similar to Kink's KINK_ENCRYPT payload > > (section 5.1.8 of the kink draft, FWIW) maybe?), maybe this can be > > made to work, if absolutely necessary. > > > > Extensibility: I keep thinking that prior to the SOI discussions, we > > had talked about simplifying IKEv1 hashing, so that ALL payloads are > > hashed and authenticated, no matter what they were. That has clear > > implications to extensibility, i.e. future payloads. I realize one of > > JFK's goals was 'non-extensibility', but I thought I saw rough > > consensus towards extensibility during the recent chinese-menu > > mails... Now by merging JFKr into IKEv2, we complicate the hashing > > mechanism again to the point where we have to think about which > > payloads can be part of the hash and which can't (also, which payloads > > must be repeated and which mustn't or don't need to). > > > > Legacy Authentication: This is really a subset of "extensibility". I'm > > trying to fit some legacy authentication scheme into IKEv2, and I have > > some ideas. Trying to fit them into an IKEv2+JFK protocol (assuming > > what's in my mind is similar to what Charlie is working on) makes it > > that much harder. > > > > Packet sizes: By repeating msg1 in msg3, msg3 necessarily gets > > larger. William kept trying to get people to realize that we have a > > UDP fragmentation issue, when certs (or cert chains) are sent, so this > > seems like a move in the wrong direction. Paul Hoffman had some ideas > > of changing the ID payload so that it can include a URL, i.e. pointer > > to the cert instead of the cert itself, and that may help. > > > > Based on my gut feeling, I vote to leave IKEv2 as is, rather than > > grafting JFK'isms onto IKEv2. If it gave us something we can't live > > without, I wouldn't have that much of an issue with it, but I don't > > see a very good reason to do it (the cost outweighs the gain). > > > > Flame away. "Me too's" or "Ditto's" highly encouraged. > > > > jan > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > > http://www.eff.org/cafe > > > > > From owner-ipsec@lists.tislabs.com Mon Sep 30 14:42:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8ULgHv13622; Mon, 30 Sep 2002 14:42:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03698 Mon, 30 Sep 2002 17:12:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6757.0 Content-class: urn:content-classes:message Subject: RE: using ip-based cert. in NAT-T Date: Mon, 30 Sep 2002 14:11:25 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D01A9C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: using ip-based cert. in NAT-T Thread-Index: AcJnKrB2eDIi83P9QBCD9ZnW+j6j6gBlwo2A From: "William Dixon" To: "Mohammad Awad" , X-OriginalArrivalTime: 30 Sep 2002 21:11:26.0359 (UTC) FILETIME=[EFF71A70:01C268C5] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mohammad, are you making a comment or asking questions about the NAT-T drafts, or asking a question to help with some other kind of implementation ? Where did you see this technique ? "This NAT-ID will be included in the options fields of the IP header of the NATed packet." The current upd-encaps draft does not do this. RFC 2401 doesn't describe any requirements for integration with DNS IP mappings for IPsec in general. So anything you invent with respect to a dependency on DNS containing mappings is implementation-defined, and thus not dealt with by the NAT-T drafts. Certainly DNS has definitions for records to contain the public key associated with a name or an IP address, and if your DNS supports that it may also support multiple public key records for that IP address vs. just one. There is no requirement to use an IP address in the certificate for IKE. Thus The IKE Main Mode ID type often depends upon the IPsec policy system being used - which is an implementation choice of the IPsec vendor. Obviously for dynamic IP address clients, putting the IP in the cert doesn't make much sense. 2401 does suggest that a gateway can lookup the DNS name for a dynamic client as long as dynamic DNS is being used, however, it's unclear if the DNS update will replicate fast enough in the authority servers to service gateway's request, or what to do when DNS entries are not made at all. Again, this is IPsec policy defined by the implementation. For routers or static servers, it may make sense if you can have multiple certs on the router each with a router's IP address, use multiple IP addresses in the SubjectAltName or can deal with updating the credential when the IP address of the router changes. Does the cert have an EKU that indicates an OID for IPsec usage ? If not, then is the PKI issuer authorized to claim an IP address for the machine in the cert it issues ? Given those issues, and the difficulty of PKI in general, I don't see IP addresses in a certificate viable for most cases, only a very few uses of IPsec. But it's certainly allowed. The use of an IP address in the IKE quick mode SA Proxy ID is specifically dealt with in http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-03.txt -----Original Message----- From: Mohammad Awad [mailto:maa1074@hotmail.com] Sent: Saturday, September 28, 2002 12:58 PM To: ipsec@lists.tislabs.com Subject: using ip-based cert. in NAT-T Neither the internal IPs nor their certificates can be registered in the DNS. This makes the other peer which is negotiating IKE main mode with the NATed host, uses a certificate with subject rather than the IP to (may be FQDN) to authenticate the NATed host, which may be less secure. What if the internal hosts behind the NAT can -somehow- register their certificates in the DNS with an approach like this: Each NATed host will be provided an identifier that is unique amongst the NATed hosts behind one NAT (ie, those hosts having the same external IP). This NAT-ID will be included in the options fields of the IP header of the NATed packet. Another RR.s in the DNS are to be added, with extensions to hold that NAT-ID, one RR record for each NATed host. Then the certificates can be registered in that RR NAT record and used by the remote peer to obtain the certificate of the NATed host. how do you find that approach? _________________________________________________________________ Join the world's largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ipsec@lists.tislabs.com Mon Sep 30 15:00:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8UM0Hv14344; Mon, 30 Sep 2002 15:00:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03738 Mon, 30 Sep 2002 17:27:34 -0400 (EDT) Message-Id: <200209302127.g8ULRE809628@sydney.East.Sun.COM> Date: Mon, 30 Sep 2002 17:27:14 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: Merging IKEv2 and JFKr? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BCh/daWOuq0Cc/OUM7wG+A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> From: Michael Thomas >> So I wasn't at the last meeting, but it's seemed >> fairly obvious to me that there's been consensus >> around IKEv2 (fwiw, I've never been anti-IKEv2). >> What is to be gained by trying to merge these two >> other than a sort of Medieval peace by marrying >> different bloodlines? JFK's big appeal, IMO, was >> its simplicity. The WG has clearly decided that >> wasn't compelling enough argument. >> Mike I don't think that thinking about it as "merging two specs" makes much sense. That would be like interspersing words or something, and certainly nobody is proposing that. What's really being "merged" is the author names, and that's certainly a win. The important question is what actual modifications are being made? The main two things are: a) changing from a la carte negotiation to suites (which incidentally wasn't part of either spec, but all contributers thought it would be a simpler, better protocol with suites) b) changing to an "always 4 message" protocol where Bob is stateless until receipt of message 3. Indeed, both of these changes sounded easier when first proposed, than when actually worked out. For instance, although I still prefer suites, I'm not exactly sure how the ESP/AH extended sequence numbers are supposed to work, now that we're not individually negotiating features. I guess it will be defined as part of the suite (not only what cryptographic algorithms are used, but whether ESP/AH extended sequence numbers will be used). The 4-message thing is certainly more complicated to understand, and there were some thorny issues. I advocated for this change, but had somewhat of a change of heart after seeing the implications. But it's doable, and I believe we have worked out all the details, and it would be good for implementers to think about it once they can see it fully worked out. It's hard to compare until a concrete proposal is made, all written down. Hopefully the spec will be distributed to the ipsec list real soon now, and then people can argue with more information about whether these changes are a net plus or a net minus, or not significant enough either way to worry about. And although it's moot in this case, in general it would be good for people to get in the habit of saying something like "A is simpler than B because it leaves out feature X" rather than "A's advantage over B is simplicity", because often when people are saying this sort of thing, A isn't actually simpler than B, but people just say so and it gets repeated, or it appears simpler because of not having worked out some details, or it's simpler because of leaving out features that people wouldn't be happy leaving out. Radia