From owner-ipsec@lists.tislabs.com Mon Apr 1 06:26: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 g31EQZm29420; Mon, 1 Apr 2002 06:26:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00183 Mon, 1 Apr 2002 08:32:45 -0500 (EST) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Catherine A. Meadows'" , , Cc: "Andrew Krywaniuk" , Subject: RE: Suggestion for SOI wrt PFS Date: Sun, 31 Mar 2002 23:36:20 -0500 Message-ID: <000901c1d936$c6c81fb0$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200203291758.MAA14270@liverwurst.fw5540.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I think that this (using phase 2 with D-H > to generate a new SKEYSEED_d) works for PFS, but I am worried > about the added > complexity. Adding a new type of phase 2 for calculating the > SKEYSEED_d comes dangerously close to shoehorning in a > "phase 1 1/2", which we are trying to avoid. Are the savings > gained from avoiding a new Phase 1 exchange worth this added > complexity? I don't think this is what people are referring to when they talk about a phase 1.5. Also I wasn't proposing a new type of phase 2 exchange. Nevertheless, I have no objection to replacing PFS with more frequent phase 1 rekeying, except that this got shouted down as inefficient the last time I proposed it. My new proposal attempts to be more efficient and also resolve the PFS interop problem (so there is also a simplification benefit). The problem I see is that PFS (as defined in IKE) is currently implemented as a configuration parameter when it could be a runtime parameter. This causes interop problems because PFS (and the DH group) can't be negotiated in the same was as other parameters. I support Paul's idea for having a set of named ciphersuites. I've been advocating this idea for years, but I anticipated that PFS would be the main problem. If you use 3DES with SHA1, that will work with most people's default configurations; therefore, the ciphersuite will reflect what is already out there. But PFS will cause a problem, because there is about a 50% chance that a given implementation will have it on by default and a 50% chance that it will be off. 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. From owner-ipsec@lists.tislabs.com Mon Apr 1 06:26: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 g31EQcm29438; Mon, 1 Apr 2002 06:26:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00349 Mon, 1 Apr 2002 08:41:38 -0500 (EST) Date: Mon, 1 Apr 2002 14:19:59 +0530 (IST) From: Sri Siddhartha Kodali To: ipsec@lists.tislabs.com Subject: [ Problems setting up CA server ] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi !! As a part of our project work on Virtual Private Networks using IPSEC, we have to setup a CA server so that vpn enabled routers can authenticate and enroll the Certificate Authority Server.We are not able to find any freely avialable Certificate Authority servers.Can any one suggest us freely avialable CA servers on Linux and Windows Platforms Thanking You Siddharth Kodali siddhu@bits-pilani.ac.in From owner-ipsec@lists.tislabs.com Mon Apr 1 06:26: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 g31EQem29452; Mon, 1 Apr 2002 06:26:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00340 Mon, 1 Apr 2002 08:41:27 -0500 (EST) Date: Sun, 31 Mar 2002 15:09:18 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Bill Sommerfeld , , Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: <200203312301.g2VN17Om010548@coredump.keromytis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 31 Mar 2002, Angelos D. Keromytis wrote: > > In message , Jan > Vilhuber writes: > > > >But you STILL need to redo the rsa sigs. Just caching the certificate > >validation buy's you having to redo all that, but having to redo the > >rsa is costly anyway. > > > >And please don't say "but rsa operations are cheap" because they > >aren't.. > > RSA operations are cheap. They're not cheap enough to do 1000 tunnel setups > per second In other words they are NOT cheap, but the cost is bearable, when you have to do only a small/limited number of them. "RSA operations are cheap, except when they are not". Bogus. Not everything has hardware support and not every device has a P6 1GHz... > (without hardware support), but you can easily sustain a couple > of hundred, even on a moderate box. And I've seen no argument (let alone a > convincing one) why you'd need massive amounts of tunnels/sec (your IPsec > gateway likely won't be able to handle traffic for them anyway). Certainly not if we have to constantly do rsa operations for every transaction, that's true. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Apr 1 06:26: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 g31EQfm29462; Mon, 1 Apr 2002 06:26:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00456 Mon, 1 Apr 2002 08:47:09 -0500 (EST) Message-Id: <200203302138.g2ULcKY16044@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: QoS considerations In-reply-to: Your message of "Sun, 24 Mar 2002 18:57:43 EST." <277DD60FB639D511AC0400B0D068B71E02937627@CORPMX14> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 30 Mar 2002 16:38:19 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Black" == Black David writes: >> This essentially says to use RSVP to signal the QoS for the resulting >> ESP packets that are generated. This signal travels to the first edge >> routing >> of the diffserv cloud [called the "diffedge" device in 2998] (and I >> would imagine no further), causing the edge router of the ISP to enact >> some admission control based upon (dest, proto, SPI#) [see >> RFC2207]. The packet is then admited to the proper diffserv queue and >> has the appropriate DSCP stamped on it. Black> This causes the ISP's edge router to have to classify traffic Black> based on SPI#. That's an example of microflow classification, and Black> a rather unusual one. An alternative model would be to apply the unusual? What's usual on a framework that is barely deployed :-) SPI is 4 bytes at 4 bytes further into the packet than TCP/UDP port pair.. Black> DSCPs that the ISP is expecting at the customer's VPN gateway that Black> is facing the ISP; the ISP then classifies traffic based on DSCP Black> and conducts admission control on the basis of that Black> classification. Yes, that could be done as well. I would tend to think of doing this when the enterprise itself is doing diffserv already. Black> Both solutions require the signaling to pass from the VPN gateway Black> to the ISP, and are subject to failure if it doesn't (e.g., Black> something in between discards RSVP traffic or decides to rewrite Black> the DSCPs because it can). At which point, one gets "Best Effort" :-( Black> If IPsec is running end-to-end, so the IPsec implementations are Black> on hosts attached to a customer network rather than on an Black> ISP-facing VPN gateway, things get more complicated, and RFC 2998 Black> is certainly one approach to a solution. Another is to use Black> whatever's appropriate for the customer network and have an Black> ISP-facing device reclassify the traffic and apply the DSCPs as Black> appropriate for the customer's policy for usage of the ISP. This Yes. My impression is that is really doesn't matter where the device that translates RSVP -> DSCP is. CPE or ISP-located, doesn't matter. ] 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 NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPKYwR4qHRg3pndX9AQF82gP/dxF0Oz+Ka5pxZtuTTzAu1J+uRatPr4M9 8ZcIZhl4Ir68bkKoaIE96VKS96fgYQEsy/XbEgjuJEw4CdnkWUTDyo2zwuPPH8y0 DfkDKhgwseCzvb9XKdObKy7ltg8Fnt7j6hvNK/7luZpmfuD3ShiIcUuKeJaHysFH DpQuNK9keHg= =UWoY -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Apr 1 06:26: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 g31EQnm29479; Mon, 1 Apr 2002 06:26:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00394 Mon, 1 Apr 2002 08:44:34 -0500 (EST) Date: Sun, 31 Mar 2002 15:00:40 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Bill Sommerfeld , , Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: <200203291820.g2TIKOOm014329@coredump.keromytis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 29 Mar 2002, Angelos D. Keromytis wrote: > > In message , Jan > Vilhuber writes: > > > >Then you'd have to reauthenticate, which you may not want to (public > >key operation and all). At least that's the only difference I can > >see. This is somewhat lighter weight than a full phase 1. > > > >[ I haven't thought this proposal through yet, so I'm not coming down > >on one side or the other ;) ] > > The argument I made a while ago, about caching the results of a > cert chain validation hold for this case too. But you STILL need to redo the rsa sigs. Just caching the certificate validation buy's you having to redo all that, but having to redo the rsa is costly anyway. And please don't say "but rsa operations are cheap" because they aren't.. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Apr 1 06:28: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 g31ERxm29504; Mon, 1 Apr 2002 06:27:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00546 Mon, 1 Apr 2002 08:50:59 -0500 (EST) Message-Id: <200203312325.g2VNP5Om019814@coredump.keromytis.com> To: Jan Vilhuber Cc: Bill Sommerfeld , andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: Suggestion for SOI wrt PFS In-reply-to: Your message of "Sun, 31 Mar 2002 15:09:18 PST." Date: Sun, 31 Mar 2002 18:25:05 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: > >In other words they are NOT cheap, but the cost is bearable, when you >have to do only a small/limited number of them. > >"RSA operations are cheap, except when they are not". Bogus. Cost is always measured in comparison to the task at hand (and the derived benefit). >Not everything has hardware support and not every device has a P6 1GHz... I never said that everything has hardware support (so why do you keep repeating it ?); and the numbers I posted a few weeks ago were from a more moderate box than a P6 1GHz... My home IPsec gateway is a 450Mhz Pentium (a low-power SBC), but has no problem establishing a few tunnels every 20 minutes --- despite in fact doing full certificate verification and RSA signature (oh, and PFS). I'm giving you some facts -- something I haven't seen from you yet. >> of hundred, even on a moderate box. And I've seen no argument (let alone a >> convincing one) why you'd need massive amounts of tunnels/sec (your IPsec >> gateway likely won't be able to handle traffic for them anyway). > >Certainly not if we have to constantly do rsa operations for every >transaction, that's true. So you're saying that you *do* have a business need for a box that can support a sustained SA setup rate of 1000 tunnels/second ? Could you expand on it ? -Angelos From owner-ipsec@lists.tislabs.com Mon Apr 1 06:29: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 g31ET7m29692; Mon, 1 Apr 2002 06:29:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00509 Mon, 1 Apr 2002 08:50:01 -0500 (EST) Date: Fri, 29 Mar 2002 16:19:02 -0800 (PST) Message-Id: <200203300019.QAA08194@potomac.incog.com> From: Mike Ditto To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com In-reply-to: <200203270233.g2R2XYQ01734@fatty.lounge.org> (message from Dan Harkins on Tue, 26 Mar 2002 18:33:34 -0800) Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On the specific idea of making TS optional, isn't it effectively optional already? Can't an implementation that has no use for them always propose wildcard selectors, and always accept (and ignore) any selectors proposed to it? Dan Harkins wrote: > If the selectors that defined your particular SPD entry allowed this > received packet already then no "broadening" would be necessary. That depends on what you mean by SPD. Do you mean the traffic selectors affiliated with each SA, as communicated by IKE/SOI/whatever? Or do you mean the configured policy that I must enforce? They are quite different things. Traffic selectors as currently proposed are simple sets of addresses, protocols, port numbers and the like. My policy is, in essence, a function that takes a packet as input and produces a boolean output. I can't take some selectors and see if they match my policy, and if I somehow encode my policy function (say, as a Java class file or a bit vector with a value for every conceivable IP packet) and send it to you when we're negotiating a tunnel, it will be just as useless to you as your traffic selectors are to me. I could, with a lot of otherwise unnecessary work, generate a set of selectors that loosely approximates my policy, and use them to negotiate a tunnel with you. If your end does reduce the set at all, I have no way of knowing whether that subset will actually allow the services I want to use over that tunnel. In general, the "approximation selectors" will include some things that aren't really included by the policy, or exclude some things that are, or some of both. So there will always be a discrepancy between the actual policy and the traffic selectors. This could probably be lived with if the discrepancy was small, like a few corner cases. But for some commonly used services, the discrepancy is so large that the selectors have no value (because they are wildcards) or prevent interoperability (because they are too constraining). > A new > packet that required "broadening a tunnel's traffic selectors" would BY > DEFINITION be dropped on the other side so there is no point in sending > it under protection of that SA in the first place. That is only true if each end somehow knows exactly how the other end's policy actually differs from the negotiated traffic selectors. I can see how this could work if both ends are the same implementation, or if both are trivial implementations that don't have any policy other than addresses and port numbers. But I don't see how it can work in real life. > If we choose to just do away with the TS payloads (as you suggest) then > we have no standard way of agreeing on anything. What would happen is that > two boxes would be correctly configured to protect FOO (some protocol) but > because the definition of how to implement protection of FOO is left to the > imagination of those implementing IPsec the two boxes might not interoperate. We can still agree about any particular packet, which is the only thing we have agree on. I don't see why they wouldn't interoperate, unless their respective definitions of the service are actually incompatible, which is equally possible regardless of how IKE works or even whether IPsec is in use at all. -=] Mike [=- From owner-ipsec@lists.tislabs.com Mon Apr 1 06:29: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 g31ET7m29693; Mon, 1 Apr 2002 06:29:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00508 Mon, 1 Apr 2002 08:50:00 -0500 (EST) Date: Fri, 29 Mar 2002 19:18:12 -0800 (PST) Message-Id: <200203300318.TAA08252@potomac.incog.com> From: Mike Ditto To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com In-reply-to: <200203300132.g2U1WaH00410@fatty.lounge.org> (message from Dan Harkins on Fri, 29 Mar 2002 17:32:36 -0800) Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > An implementation that has no need for selectors is not an IPsec > implementation. This discussion goes to one of the basic issues of IPsec use: Why would you want more than one SA between the same addresses and with identical security parameters (identities, algorithms, etc.)? Some people say there is no need for such. The alternative view says that it is useful to segregate traffic by service or session between multiple equivalent SAs, perhaps to prevent known plaintext attacks or denial of service attacks between multiple users of a shared tunnel. I concede that this may be useful. But what is a service, and what is a session? Is it reasonable to think that heterogeneous systems can describe services to each other in an interoperable way? If IPsec wants to support this concept, shouldn't it do so in a way that allows each implementation to implement reasonably complex services? Or should it define an overly simple concept of service segregation that may be difficult or impossible to support in some implementations, and may be insecure? I claim that the current and proposed traffic selection concepts preclude the secure use of some commonly used services, and preclude some implementations that seem reasonable. I'm speaking with knowledge of a particular implementation, a moderately successful commercial product that has implemented IP layer security for 6 years. It does this without any need for "traffic selectors" because it was designed before IPsec was standardized and originally used SKIP, which does not support multiple equivalent SAs between the same endpoints. We added IPsec protocols much later. The version that supports IPsec is interoperable with (at least some) standard IPsec/IKE implementations when used in a single-tunnel-for-all-allowed-services style of operation. It is, I believe, not interoperable with other IKE implementations configured to segregate traffic between SAs based on port number style selectors. Why is this? It is because IKE was designed with a concept of "service" that is not compatible with our basic design. I can't blame IPsec/IKE designers for this because I don't think anyone (from this product's development group or elsewhere) brought up this issue when IKE was standardized. But now that the can of worms is open again, I feel free to point out limitations that could be avoided in the next go-around. > > Traffic selectors as currently proposed are simple > > sets of addresses, protocols, port numbers and the like. My policy is, > > in essence, a function that takes a packet as input and produces a > > boolean output. > > No, it's a tertiary output. drop, bypass, or protect. Not at this level of determining whether a packet is appropriate for a given SA. Only a binary classification is provided by the traffic selectors; a packet either matches or it doesn't. > But if it's the term > "policy" that is causing this confusion then don't think of it as "policy". > It's the set of traffic selectors that specify "protect". But again, I don't have those selectors, and I can't fabricate selectors that actually correspond to the policy, because I support services that do not correspond directly to port numbers or other things that the traffic selector notation can represent. > It's unnecessary to generate a set of selectors? How do you use IPsec then? When an outgoing packet's policy (which is determined by a packet classifier and policy database) specifies IPsec with particular security parameters, I look for an SA with those parameters. If there isn't one, I negotiate for one. The only information I have available to offer the peer during this negotiation is information in the one particular packet I have, and the security parameters from the policy. (I also have a list of abstract service names that have no portable meaning; some people have suggested standardizing service tokens that could convey this information.) There are no "selectors" involved; the policy database and packet classifier are opaque to the packet disposition engine, and don't contain IPsec-style selectors even internally. For incoming IPsec packets, I simply see if the SA's security parameters match those of the decrypted packet's policy. If I supported service- based SA segregation, and IPsec provided a mechanism for me to do so, this is where I would notify the other end of a policy mismatch, and give it a hint how to resolve it (i.e., create a new SA, or use such-and-such existing SA that is appropriate). > It actually does work in real life. I'm sure it does with implementations that are designed from the start with the same limitations as IKEv1. I'm hoping for something better. -=] Mike [=- From owner-ipsec@lists.tislabs.com Mon Apr 1 06:30: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 g31EU7m29899; Mon, 1 Apr 2002 06:30:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00668 Mon, 1 Apr 2002 08:53:57 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Fri, 29 Mar 2002 10:45:02 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Fixing identity and cert-sending Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We have an opportunity in successor-to-IKE to fix two major problems that have plagued us in IKEv1: a misunderstanding about what is identity, and having to send certificates every time because you don't know if the other party already has your certificate. This proposal (which could work in either IKEv2 or JFK) covers both topics at once because it turns out that they are related. Suggestions are welcome. The discussion below is for the successor-to-IKE proposals. Ignore everything about today's cert, certrequest, and ID payloads; they will not be used. Messages 1 and 2 MAY include a TrustedRoot payload. The TrustedRoot payload includes a series of one or more PKIX keyIdentifiers of roots trusted by the sender. This payload is completely optional and is used only to inform the recipient of what capabilities the sender has. Messages 1 and 2 MUST include exactly one IDAccepted payload. The payload holds a series of one or more fields indicating the FullID types that the sender will accept. The receiver MUST NOT send any FullID payloads that are not listed in the sender's IDAccepted payload. Messages 3 and 4 MUST include exactly one FullID payload. The payload's format is an ID type followed by content. The ID types are: 1 PKIX cert -- A standalone PKIX cert. 2 Cert bundle -- A simple ASN.1 sequence of PKIX certs. A bundle can have end-entity certs or cert chains. The first cert in the bundle is the sender's preferred identity certificate, but beyond that there is no meaning to the ordering. 3 Hash-and-URL of PKIX cert -- The first 20 octets are the SHA-1 of a certificate; the rest is a URL that resolves to the cert. This is described in more detail below. 4 URL to a PKIX cert bundle -- This is described in more detail below. 5 PKIX keyIdentifier -- Identifies a self-signed certificate that the receiver has already pre-loaded. Note that this is only useful when using self-signed certs. 6 IDForSharedSecret -- This is only for use with shared secrets. It is an ASCII string (all octets are 31 < x < 127) of any length. For ID types 3 and 4: the URL scheme must be http, although it can be on any port, and there might be requirements for how the named part looks. The URL might be to a persistent repository, or it might be to the initiating machine (such as in a remote access client). For type 3, the recipient might cache the cert with the hash as an index, or it can be retrieved from the URL. If a system that is using certs knows that it cannot resolve URLs (because it is not yet on the Internet), it should use 1 and 2 in its IDAccepted payload. If a system can resolve URLs, it should use include type 3 and 4. All systems should be able to handle bundles because the other party might have multiple identities which have different certificates. There will be new error codes: - Could not get your cert through the URL - Could not get your cert bundle through the URL - Bundle was malformed - Could not find the cert that matches the keyIdentifier - Could not use your IDForSharedSecret The authentication data needs to specify what kind of authentication is being used (signed or HMACed). --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Apr 1 06:30: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 g31EU9m29917; Mon, 1 Apr 2002 06:30:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00576 Mon, 1 Apr 2002 08:52:04 -0500 (EST) Message-Id: <200203291820.g2TIKOOm014329@coredump.keromytis.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jan Vilhuber Cc: Bill Sommerfeld , andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: Suggestion for SOI wrt PFS In-reply-to: Your message of "Thu, 28 Mar 2002 19:21:11 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Mar 2002 13:20:24 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: > >Then you'd have to reauthenticate, which you may not want to (public >key operation and all). At least that's the only difference I can >see. This is somewhat lighter weight than a full phase 1. > >[ I haven't thought this proposal through yet, so I'm not coming down >on one side or the other ;) ] The argument I made a while ago, about caching the results of a cert chain validation hold for this case too. -Angelos From owner-ipsec@lists.tislabs.com Mon Apr 1 06:31: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 g31EVGm00120; Mon, 1 Apr 2002 06:31:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00572 Mon, 1 Apr 2002 08:51:59 -0500 (EST) Message-Id: <200203312301.g2VN17Om010548@coredump.keromytis.com> To: Jan Vilhuber Cc: Bill Sommerfeld , andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: Suggestion for SOI wrt PFS In-reply-to: Your message of "Sun, 31 Mar 2002 15:00:40 PST." Date: Sun, 31 Mar 2002 18:01:07 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: > >But you STILL need to redo the rsa sigs. Just caching the certificate >validation buy's you having to redo all that, but having to redo the >rsa is costly anyway. > >And please don't say "but rsa operations are cheap" because they >aren't.. RSA operations are cheap. They're not cheap enough to do 1000 tunnel setups per second (without hardware support), but you can easily sustain a couple of hundred, even on a moderate box. And I've seen no argument (let alone a convincing one) why you'd need massive amounts of tunnels/sec (your IPsec gateway likely won't be able to handle traffic for them anyway). -Angelos From owner-ipsec@lists.tislabs.com Mon Apr 1 06:31: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 g31EVbm00158; Mon, 1 Apr 2002 06:31:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00616 Mon, 1 Apr 2002 08:52:55 -0500 (EST) Date: Sun, 31 Mar 2002 15:01:31 -0800 (PST) From: Jan Vilhuber To: "Catherine A. Meadows" cc: , , Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: <200203291758.MAA14270@liverwurst.fw5540.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 29 Mar 2002, Catherine A. Meadows wrote: > I sent this already, but forgot to cc the list: > And I replied to the one that wasn't cc'd to the list :) Here's the reply: As another data point consider VPN client-software, that may have to re-prompt the user for new passwords (shared keys or one-time passwords) when doing a new phase 1. That MAY be undesireable, although I have no evidence on what customers want either way. Generally, people do NOT want to be reprompted for passwords in the middle of a session, though... Given that, doing a PFS and feeding it back into the SKEYSEED seems favorable.. jan > I think that this (using phase 2 with D-H > to generate a new SKEYSEED_d) works for PFS, but I am worried about the added > complexity. Adding a new type of phase 2 for calculating the > SKEYSEED_d comes dangerously close to shoehorning in a > "phase 1 1/2", which we are trying to avoid. Are the savings > gained from avoiding a new Phase 1 exchange worth this added complexity? > > I do agree, though, that we need a precise definition of PFS, what > we want it to achieve, and where it should go. The best place > for this is probably in the requirements document. The current > draft of the document describes a mechanisms for achieving PFS (use > D-H to create a shared key), but doesn't talk about the property itself. > > Cathy > > Catherine Meadows > Code 5543 > Center for High Assurance Computer Systems > Naval Research Laboratory > Washington, DC 20375 > > phone: +1-202-767-3490 > fax: +1-202-404-7942 > > > > > > From owner-ipsec@lists.tislabs.com Thu Mar 28 22:26:24 2002 > > Date: Thu, 28 Mar 2002 19:21:11 -0800 (PST) > > From: Jan Vilhuber > > To: Bill Sommerfeld > > cc: , > > Subject: Re: Suggestion for SOI wrt PFS > > MIME-Version: 1.0 > > Sender: owner-ipsec@lists.tislabs.com > > > > On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > > > > > > The ideal situation would be that the peers negotiate an IKE SA (with DH) > > > > and one or more IPsec SAs (not using DH). After a specified timeout (the > > > > forward secrecy interval), the peers forget SKEYSEED_d, and the next phase 2 > > > > exchange would have to contain a DH. This DH would be used to generate the > > > > new SKEYSEED_d for subsequent exchanges. > > > > > > So, why not just start a new phase 1 at this point? > > > > > > > Then you'd have to reauthenticate, which you may not want to (public > > key operation and all). At least that's the only difference I can > > see. This is somewhat lighter weight than a full phase 1. > > > > [ I haven't thought this proposal through yet, so I'm not coming down > > on one side or the other ;) ] > > > > jan > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Apr 1 06: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 g31Ekmm00645; Mon, 1 Apr 2002 06:46:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00916 Mon, 1 Apr 2002 09:08:41 -0500 (EST) Message-Id: <200204011215.HAA21901@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-sonofike-rqts-00.txt Date: Mon, 01 Apr 2002 07:15:32 -0500 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 : Son-of-IKE Requirements Author(s) : C. Madson Filename : draft-ietf-ipsec-sonofike-rqts-00.txt Pages : 41 Date : 29-Mar-02 Various proposals have been made for updating the IKE protocol. This effort has been known as 'Son of IKE (SOI)'. One thing that is missing from the discussion is an evaluation of the scope of SOI, identifying which problems it should solve. Sections of this document discuss various scenarios that are considered important for SOI. Once this scoping is done, it becomes easier to specify the requirements of the protocol. This document also discusses protocol, policy and security requirements for SOI, along with recommendations for protocol improvement in such areas as modularity, extensibility, protocol convergence and simplicity, which are important regardless of the scope of SOI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.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-sonofike-rqts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020329130755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-sonofike-rqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020329130755.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Apr 1 07:01: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 g31F0xm01166; Mon, 1 Apr 2002 07:01:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01164 Mon, 1 Apr 2002 09:22:08 -0500 (EST) From: "Catherine A. Meadows" Date: Fri, 29 Mar 2002 12:58:43 -0500 (EST) Message-Id: <200203291758.MAA14270@liverwurst.fw5540.net> To: sommerfeld@east.sun.com, vilhuber@cisco.com Subject: Re: Suggestion for SOI wrt PFS Cc: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I sent this already, but forgot to cc the list: I think that this (using phase 2 with D-H to generate a new SKEYSEED_d) works for PFS, but I am worried about the added complexity. Adding a new type of phase 2 for calculating the SKEYSEED_d comes dangerously close to shoehorning in a "phase 1 1/2", which we are trying to avoid. Are the savings gained from avoiding a new Phase 1 exchange worth this added complexity? I do agree, though, that we need a precise definition of PFS, what we want it to achieve, and where it should go. The best place for this is probably in the requirements document. The current draft of the document describes a mechanisms for achieving PFS (use D-H to create a shared key), but doesn't talk about the property itself. Cathy Catherine Meadows Code 5543 Center for High Assurance Computer Systems Naval Research Laboratory Washington, DC 20375 phone: +1-202-767-3490 fax: +1-202-404-7942 > From owner-ipsec@lists.tislabs.com Thu Mar 28 22:26:24 2002 > Date: Thu, 28 Mar 2002 19:21:11 -0800 (PST) > From: Jan Vilhuber > To: Bill Sommerfeld > cc: , > Subject: Re: Suggestion for SOI wrt PFS > MIME-Version: 1.0 > Sender: owner-ipsec@lists.tislabs.com > > On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > > > > The ideal situation would be that the peers negotiate an IKE SA (with DH) > > > and one or more IPsec SAs (not using DH). After a specified timeout (the > > > forward secrecy interval), the peers forget SKEYSEED_d, and the next phase 2 > > > exchange would have to contain a DH. This DH would be used to generate the > > > new SKEYSEED_d for subsequent exchanges. > > > > So, why not just start a new phase 1 at this point? > > > > Then you'd have to reauthenticate, which you may not want to (public > key operation and all). At least that's the only difference I can > see. This is somewhat lighter weight than a full phase 1. > > [ I haven't thought this proposal through yet, so I'm not coming down > on one side or the other ;) ] > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Mon Apr 1 07:10: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 g31FALm01554; Mon, 1 Apr 2002 07:10:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01303 Mon, 1 Apr 2002 09:31:31 -0500 (EST) Message-Id: <200203301834.g2UIYEU00312@fatty.lounge.org> To: Mike Ditto Cc: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Fri, 29 Mar 2002 19:18:12 PST." <200203300318.TAA08252@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <309.1017513254.1@tibernian.com> Date: Sat, 30 Mar 2002 10:34:14 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 29 Mar 2002 19:18:12 PST you wrote > > I'm speaking with knowledge of a particular implementation, a moderately > successful commercial product that has implemented IP layer security for > 6 years. It does this without any need for "traffic selectors" because > it was designed before IPsec was standardized and originally used SKIP, > which does not support multiple equivalent SAs between the same > endpoints. We added IPsec protocols much later. The version that > supports IPsec is interoperable with (at least some) standard IPsec/IKE > implementations when used in a single-tunnel-for-all-allowed-services > style of operation. It is, I believe, not interoperable with other IKE > implementations configured to segregate traffic between SAs based on > port number style selectors. Why is this? It is because IKE was > designed with a concept of "service" that is not compatible with our > basic design. No, it's because this is still not an IPsec-compliant implementation. You would have this problem with SAs that were manually created that segregated traffic between SAs based on port and protocol. This only looks like an IKE issue because that is where your non-compliance is first shown. The specification deals with more than producing and consuming packets of a certain format. If you do not have any "traffic selectors" then you are not RFC2401 compliant. It is not surprising that you're having trouble interoperating with an IPsec compliant implementation that is doing things which are completely valid according to the specification. > > But if it's the term > > "policy" that is causing this confusion then don't think of it as "policy". > > It's the set of traffic selectors that specify "protect". > > But again, I don't have those selectors, and I can't fabricate selectors > that actually correspond to the policy, because I support services that > do not correspond directly to port numbers or other things that the > traffic selector notation can represent. Again, then this is not an IPsec compliant device. You're asking for IPsec to change so your non-compliant implementation which has some nebulous classification scheme (that does not use RFC2401 selectors) can interoperate with an IPsec compliant device. > > It actually does work in real life. > > I'm sure it does with implementations that are designed from the start > with the same limitations as IKEv1. I'm hoping for something better. If what you have today is so wonderous and does not suffer from these "limitations" then don't just sit and snipe and hope. Write a draft that specifies how traffic should be classified without selectors. Then once you've done away with selectors there will be no need for an SA establishment protocol to use them. What you have proposed so far not only does not solve the problems with the current approach (the desire to specify a protection of protocols that float ports such that all the ports it uses are under the protection of a single SA) it actually creates other problems (that have been discussed earlier in this thread). Dan. From owner-ipsec@lists.tislabs.com Mon Apr 1 07:21: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 g31FLNm02960; Mon, 1 Apr 2002 07:21:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01414 Mon, 1 Apr 2002 09:45:47 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15528.30002.854691.842292@thomasm-u1.cisco.com> Date: Mon, 1 Apr 2002 06:56:50 -0800 (PST) To: "Angelos D. Keromytis" Cc: Jan Vilhuber , Bill Sommerfeld , andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: <200203312325.g2VNP5Om019814@coredump.keromytis.com> References: <200203312325.g2VNP5Om019814@coredump.keromytis.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 Angelos D. Keromytis writes: > So you're saying that you *do* have a business need for a box that can > support a sustained SA setup rate of 1000 tunnels/second ? Could you > expand on it ? Oh please. Not everything is a site-site VPN. IKE was specifically deemed useless by Packetcable for cable telephony because restart avalanches of tens or hundreds of *thousands* subscriber boxes would lead to unacceptible down times. That's *one* business need, and hardly a unique one. Any high fan out use of IPsec is going to care a great deal about how the high fan in box behaves, and the number of SA's per second is an important number. Mike From owner-ipsec@lists.tislabs.com Mon Apr 1 07:21: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 g31FLWm02977; Mon, 1 Apr 2002 07:21:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01437 Mon, 1 Apr 2002 09:48:14 -0500 (EST) Message-Id: <200203300132.g2U1WaH00410@fatty.lounge.org> To: Mike Ditto Cc: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Fri, 29 Mar 2002 16:19:02 PST." <200203300019.QAA08194@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <407.1017451956.1@tibernian.com> Date: Fri, 29 Mar 2002 17:32:36 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 29 Mar 2002 16:19:02 PST you wrote > On the specific idea of making TS optional, isn't it effectively > optional already? Can't an implementation that has no use for them > always propose wildcard selectors, and always accept (and ignore) any > selectors proposed to it? The information that is proposed comes from the SPD. You can define policy that says, 0.0.0.0 <--> 0.0.0.0 but to whom would you send every single packet and why would you expect to only receive packets from that person? An implementation that has no need for selectors is not an IPsec implementation. > Dan Harkins wrote: > > If the selectors that defined your particular SPD entry allowed this > > received packet already then no "broadening" would be necessary. > > That depends on what you mean by SPD. Do you mean the traffic selectors > affiliated with each SA, as communicated by IKE/SOI/whatever? Or do you > mean the configured policy that I must enforce? They are quite > different things. They are an expression of your policy that deals with what packets need IPsec protection. Your "policy" may also say other things that have nothing to do with protecting packets with IPsec but that is not what the TS payloads are dealing with. The information conveyed in the TS payloads comes out of the SPD. The way it happens is that an SPD extry exists with an action of "protect" and a packet gets a hit on that entry when it is checked against the SPD during IPsec processing. If an SA already exists to satisfy this then the packet is protected by the SA and sent out. If an SA doesn't exist then the SPD entry that caused the hit is given to IKE. > Traffic selectors as currently proposed are simple > sets of addresses, protocols, port numbers and the like. My policy is, > in essence, a function that takes a packet as input and produces a > boolean output. No, it's a tertiary output. drop, bypass, or protect. But if it's the term "policy" that is causing this confusion then don't think of it as "policy". It's the set of traffic selectors that specify "protect". > I can't take some selectors and see if they match my > policy, and if I somehow encode my policy function (say, as a Java class > file or a bit vector with a value for every conceivable IP packet) and > send it to you when we're negotiating a tunnel, it will be just as > useless to you as your traffic selectors are to me. You can "encode your policy" in any manner you choose but you must support the ability to classify packets in a well-defined manner (according to RFC2401). It is packet classification in this well-defined manner that is conveyed in the TS payload. My selectors are not useless to you because they allow you to unambiguously determine which SA should be used to send packets to me. If you have a wildcard selector entry for port and protocol to me and I have separate entries for protocol=TCP and protocol=UDP to you and I initiate initiate an IKE connection to you I will tell you how I want to constrain the SAs we create, say protocol=TCP. Then later if I initiate to you because a UDP packet got a hit in my SPD check we will create another pair of SAs for UDP traffic. Now if we did not send TS payloads you would have 2 SAs to me that could both be used to satisfy your policy. You get a TCP packet. Which SA do you use? > I could, with a lot of otherwise unnecessary work, generate a set of > selectors that loosely approximates my policy, and use them to negotiate > a tunnel with you. It's unnecessary to generate a set of selectors? How do you use IPsec then? > > A new > > packet that required "broadening a tunnel's traffic selectors" would BY > > DEFINITION be dropped on the other side so there is no point in sending > > it under protection of that SA in the first place. > > That is only true if each end somehow knows exactly how the other end's > policy actually differs from the negotiated traffic selectors. I can > see how this could work if both ends are the same implementation, or if > both are trivial implementations that don't have any policy other than > addresses and port numbers. But I don't see how it can work in real > life. Each end does not have to know how the other end's policy differs from the negotiated set, they just have to know the largest intersection. And they then know, unambiguously, what packets to send to the other end under the protection of which SA. It actually does work in real life. Dan. From owner-ipsec@lists.tislabs.com Mon Apr 1 08:34:15 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 g31GYEm11343; Mon, 1 Apr 2002 08:34:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01910 Mon, 1 Apr 2002 10:54:39 -0500 (EST) Message-ID: <005301c1d997$24e0dcd0$48c02ca1@amer.cisco.com> Reply-To: "Darren Dukes" From: "Darren Dukes" To: "Jan Vilhuber" , Cc: References: Subject: Re: Suggestion for SOI wrt PFS Date: Mon, 1 Apr 2002 11:06:12 -0500 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 From: "Jan Vilhuber" > On Fri, 29 Mar 2002, Catherine A. Meadows wrote: > > > I sent this already, but forgot to cc the list: > > > > And I replied to the one that wasn't cc'd to the list :) Here's the > reply: > > > As another data point consider VPN client-software, that may have to > re-prompt the user for new passwords (shared keys or one-time > passwords) when doing a new phase 1. That MAY be undesireable, > although I have no evidence on what customers want either > way. I know for a fact this is a sticking point with customers, re-sending a one-time PW every day or two is even met with a great deal of resistance. > Generally, people do NOT want to be reprompted for passwords in > the middle of a session, though... > > Given that, doing a PFS and feeding it back into the SKEYSEED seems > favorable.. One difference between the IKEv1 PFS and the mechanism Andrew proposes (or even rekeying the Phase1 more often) is the inability to generate a new SKEYSEED_D based on QM traffic unless the QM SAs KByte stats are relayed back to the IKE SA that created them. For implementations capable of Gbps bursts I think this functionality would likely be needed. Darren > > jan > > > > > I think that this (using phase 2 with D-H > > to generate a new SKEYSEED_d) works for PFS, but I am worried about the added > > complexity. Adding a new type of phase 2 for calculating the > > SKEYSEED_d comes dangerously close to shoehorning in a > > "phase 1 1/2", which we are trying to avoid. Are the savings > > gained from avoiding a new Phase 1 exchange worth this added complexity? > > > > I do agree, though, that we need a precise definition of PFS, what > > we want it to achieve, and where it should go. The best place > > for this is probably in the requirements document. The current > > draft of the document describes a mechanisms for achieving PFS (use > > D-H to create a shared key), but doesn't talk about the property itself. > > > > Cathy > > > > Catherine Meadows > > Code 5543 > > Center for High Assurance Computer Systems > > Naval Research Laboratory > > Washington, DC 20375 > > > > phone: +1-202-767-3490 > > fax: +1-202-404-7942 > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Thu Mar 28 22:26:24 2002 > > > Date: Thu, 28 Mar 2002 19:21:11 -0800 (PST) > > > From: Jan Vilhuber > > > To: Bill Sommerfeld > > > cc: , > > > Subject: Re: Suggestion for SOI wrt PFS > > > MIME-Version: 1.0 > > > Sender: owner-ipsec@lists.tislabs.com > > > > > > On Thu, 28 Mar 2002, Bill Sommerfeld wrote: > > > > > > > > The ideal situation would be that the peers negotiate an IKE SA (with DH) > > > > > and one or more IPsec SAs (not using DH). After a specified timeout (the > > > > > forward secrecy interval), the peers forget SKEYSEED_d, and the next phase 2 > > > > > exchange would have to contain a DH. This DH would be used to generate the > > > > > new SKEYSEED_d for subsequent exchanges. > > > > > > > > So, why not just start a new phase 1 at this point? > > > > > > > > > > Then you'd have to reauthenticate, which you may not want to (public > > > key operation and all). At least that's the only difference I can > > > see. This is somewhat lighter weight than a full phase 1. > > > > > > [ I haven't thought this proposal through yet, so I'm not coming down > > > on one side or the other ;) ] > > > > > > jan > > > -- > > > Jan Vilhuber vilhuber@cisco.com > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Mon Apr 1 09: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 g31HjWm12928; Mon, 1 Apr 2002 09:45:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02291 Mon, 1 Apr 2002 12:07:17 -0500 (EST) Date: Mon, 1 Apr 2002 09:18:46 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Bill Sommerfeld , , Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: <200203312325.g2VNP5Om019814@coredump.keromytis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 31 Mar 2002, Angelos D. Keromytis wrote: > > In message , Jan > Vilhuber writes: > > > >In other words they are NOT cheap, but the cost is bearable, when you > >have to do only a small/limited number of them. > > > >"RSA operations are cheap, except when they are not". Bogus. > > Cost is always measured in comparison to the task at hand (and the derived > benefit). > > >Not everything has hardware support and not every device has a P6 1GHz... > > I never said that everything has hardware support (so why do you keep > repeating it ?); and the numbers I posted a few weeks ago were from a > more moderate box than a P6 1GHz... > > My home IPsec gateway is a 450Mhz Pentium (a low-power SBC), but has no > problem establishing a few tunnels every 20 minutes --- despite in fact > doing full certificate verification and RSA signature (oh, and PFS). I'm > giving you some facts -- something I haven't seen from you yet. > Right. Ad hominem.. The home box you or I have is not the issue. It's the concentrator that terminates all the hundreds of thousands connections that's the issue. One every 20 minutes for your home box is fine. One every 20 minutes multiplied by several hundred thousand is the issue. > >> of hundred, even on a moderate box. And I've seen no argument (let alone a > >> convincing one) why you'd need massive amounts of tunnels/sec (your IPsec > >> gateway likely won't be able to handle traffic for them anyway). > > > >Certainly not if we have to constantly do rsa operations for every > >transaction, that's true. > > So you're saying that you *do* have a business need for a box that can > support a sustained SA setup rate of 1000 tunnels/second ? Could you > expand on it ? Cisco builds gateways. I'm after the most efficient protocol I can get. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Apr 1 10:21:44 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 g31ILim15825; Mon, 1 Apr 2002 10:21:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02476 Mon, 1 Apr 2002 12:46:24 -0500 (EST) Message-Id: <200204011754.g31HsPOm015828@coredump.keromytis.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Michael Thomas Cc: Jan Vilhuber , Bill Sommerfeld , andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: Suggestion for SOI wrt PFS In-reply-to: Your message of "Mon, 01 Apr 2002 06:56:50 PST." <15528.30002.854691.842292@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Apr 2002 12:54:25 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <15528.30002.854691.842292@thomasm-u1.cisco.com>, Michael Thomas wri tes: > >Oh please. Not everything is a site-site VPN. IKE >was specifically deemed useless by Packetcable for >cable telephony because restart avalanches of tens >or hundreds of *thousands* subscriber boxes would >lead to unacceptible down times. That's *one* >business need, and hardly a unique one. Any high >fan out use of IPsec is going to care a great deal >about how the high fan in box behaves, and the >number of SA's per second is an important number. (Oh please)^2! The majority of deployments (such as they are) of IPsec these days is on VPNs or similar topologies (and I'll include host-to-host IPsec in this as well). That's not to say that this is all IPsec is going to be used for (hopefully not!), but we should be designing for the currently-known (or widely agreed-upon future) common case. If we're going to go to the realm of science fiction and decide that we want to use IPsec in a network with 10^6-to-1 ratio of clients/servers (as in cable modems vs. head office servers), you'll allow me to postulate a $300 modexp chip in the latter, capable of doing 4K ops/second (it'll be out in the market in a couple of months, as a matter of fact --- so not much of SciFi material there :-) -Angelos From owner-ipsec@lists.tislabs.com Mon Apr 1 10:22: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 g31IM5m15850; Mon, 1 Apr 2002 10:22:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02505 Mon, 1 Apr 2002 12:49:11 -0500 (EST) Date: Mon, 1 Apr 2002 10:00:08 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Michael Thomas , Bill Sommerfeld , , Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: <200204011754.g31HsPOm015828@coredump.keromytis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 1 Apr 2002, Angelos D. Keromytis wrote: > > In message <15528.30002.854691.842292@thomasm-u1.cisco.com>, Michael Thomas wri > tes: > > > >Oh please. Not everything is a site-site VPN. IKE > >was specifically deemed useless by Packetcable for > >cable telephony because restart avalanches of tens > >or hundreds of *thousands* subscriber boxes would > >lead to unacceptible down times. That's *one* > >business need, and hardly a unique one. Any high > >fan out use of IPsec is going to care a great deal > >about how the high fan in box behaves, and the > >number of SA's per second is an important number. > > (Oh please)^2! > > The majority of deployments (such as they are) of IPsec these days is on VPNs > or similar topologies (and I'll include host-to-host IPsec in this as well). > That's not to say that this is all IPsec is going to be used for (hopefully > not!), but we should be designing for the currently-known (or widely > agreed-upon future) common case. > That's hard to do when no one wants to discuss the requirements draft... jan > If we're going to go to the realm of science fiction and decide that we want to > use IPsec in a network with 10^6-to-1 ratio of clients/servers (as in cable > modems vs. head office servers), you'll allow me to postulate a $300 modexp > chip in the latter, capable of doing 4K ops/second (it'll be out in the market > in a couple of months, as a matter of fact --- so not much of SciFi material > there :-) > -Angelos > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Apr 1 10:23: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 g31INLm15885; Mon, 1 Apr 2002 10:23:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02488 Mon, 1 Apr 2002 12:47:36 -0500 (EST) Date: Mon, 1 Apr 2002 09:59:08 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Bill Sommerfeld , , Subject: Are RSA opertaions cheap? (was Re: Suggestion for SOI wrt PFS) In-Reply-To: <200203312325.g2VNP5Om019814@coredump.keromytis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 31 Mar 2002, Angelos D. Keromytis wrote: > > In message , Jan > Vilhuber writes: > > > >In other words they are NOT cheap, but the cost is bearable, when you > >have to do only a small/limited number of them. > > > >"RSA operations are cheap, except when they are not". Bogus. > > Cost is always measured in comparison to the task at hand (and the derived > benefit). > > >Not everything has hardware support and not every device has a P6 1GHz... > > I never said that everything has hardware support (so why do you keep > repeating it ?); and the numbers I posted a few weeks ago were from a > more moderate box than a P6 1GHz... > > My home IPsec gateway is a 450Mhz Pentium (a low-power SBC), but has no > problem establishing a few tunnels every 20 minutes --- despite in fact > doing full certificate verification and RSA signature (oh, and PFS). I'm > giving you some facts -- something I haven't seen from you yet. > OK.. numbers: My ipsec gateway here at home is a cisco 806, with a MPC 855T RISC, 50Mhz. When I'm on a voice call (goes over the ipsec tunnel), and I log into the router using SSH (2 RSA operations, if I recall that protocol), the voice quality is severely impacted for the duration (about 1 second). Now you could with some justification argue that this is not a great ipsec gateway. I've long argued that we (cisco) need stronger processors and a bunch of other stuff I won't get into here. The folks that build and sell the hardware have their own priorities, and I have to work with what I get. We're not talking PC's here, afterall. We're talking smallish devices. You'd probably see the same symptoms (substitute voice traffic for simple data traffic) on your other example from a few weeks ago: The palm pilot. I know there are ipsec clients for palm pilots (why you'd want to is a bit beyond me, but it seems some people have a legitimate use). I'd be willing to bet money that if you did an rsa operation, that traffic would effectively stop flowing for the duration of the rsa operation. Or the operation would take forever, meaning you'd have to tweak the implementation with nice long timeouts. But as I said earlier: The end-stations REALLY aren't the issue at all. It's the concentrators that have to terminate a large number of connections. RSA is not cheap. It's merely acceptable when you have plenty of CPU and don't do them often. The question you must ask yourself is: Do you want ipsec to be ubiquitous, i.e. useful on as many devices as we can make it work for? Or do you only want it to be used in situations where people have 450MHz pentiums available? As you may or may not have noticed, many groups in and outside the IETF are having to come up with their own keying schemes because IKE won't work for them. I've heard "Oh please... not IKE" so many times its ridiculous. Protocol complexity has something to do with it, but as Mike Thomas pointed out in another posting, there were cases (packetcable just one of them) where the computations necessary were simply unreasonable. This will always happen, of course. There'll always be applications for which IKE (of JFK or IKEv2) won't be suitable. It's our job to make the protocol as useful as possible, though. Throwing RSA operations around like candy at a Mardi Gras parade simply won't do. I'm all for simplifying the protocol, where appropriate, i.e. where it doesn't impact usability. > >> of hundred, even on a moderate box. And I've seen no argument (let alone a > >> convincing one) why you'd need massive amounts of tunnels/sec (your IPsec > >> gateway likely won't be able to handle traffic for them anyway). > > > >Certainly not if we have to constantly do rsa operations for every > >transaction, that's true. > > So you're saying that you *do* have a business need for a box that can > support a sustained SA setup rate of 1000 tunnels/second ? Could you > expand on it ? Sure. You do the math: How many ipsec peers would it take, rekeying at (your example) every 20 minutes, to give me a sustained rate of 1000 tunnels per second? The more I reduce the number of heavy operations (RSA, DH, etc..), the greater the number of IPsec peers I can support on a given hardware. Agreed? No number needed. This is common sense. Why would I NOT want to maximize the number of IPsec peers I can handle? Doesn't everyone have a business need to maximize the use of their hardware? If I have one keying scheme where the number of peers I can support is 1 million, and there's another scheme where (all things being equal) the number of peers I could handle is 3 million, which do you think I should pick? Which do you think I should work towards? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Apr 1 10:32: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 g31IWem16019; Mon, 1 Apr 2002 10:32:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02604 Mon, 1 Apr 2002 13:00:09 -0500 (EST) Date: Mon, 1 Apr 2002 10:11:37 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Michael Thomas , Bill Sommerfeld , , Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: <200204011754.g31HsPOm015828@coredump.keromytis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 1 Apr 2002, Angelos D. Keromytis wrote: > > In message <15528.30002.854691.842292@thomasm-u1.cisco.com>, Michael Thomas wri > tes: > > > >Oh please. Not everything is a site-site VPN. IKE > >was specifically deemed useless by Packetcable for > >cable telephony because restart avalanches of tens > >or hundreds of *thousands* subscriber boxes would > >lead to unacceptible down times. That's *one* > >business need, and hardly a unique one. Any high > >fan out use of IPsec is going to care a great deal > >about how the high fan in box behaves, and the > >number of SA's per second is an important number. > > (Oh please)^2! > > The majority of deployments (such as they are) of IPsec these days > is on VPNs or similar topologies (and I'll include host-to-host > IPsec in this as well). That's not to say that this is all IPsec is > going to be used for (hopefully not!), but we should be designing > for the currently-known (or widely agreed-upon future) common case. > > If we're going to go to the realm of science fiction and decide that > we want to use IPsec in a network with 10^6-to-1 ratio of > clients/servers (as in cable modems vs. head office servers), you'll > allow me to postulate a $300 modexp chip in the latter, capable of > doing 4K ops/second Again: What if I can do 3 times the number of Sa setups with the same hardware (with $300 modexp chip or whatever) with a different protocol that doesn't need as many RSA operations? jan > (it'll be out in the market in a couple of > months, as a matter of fact --- so not much of SciFi material there > :-) > -Angelos > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Apr 1 10:34: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 g31IYFm16055; Mon, 1 Apr 2002 10:34:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02558 Mon, 1 Apr 2002 12:55:39 -0500 (EST) From: "Andrew Wenlang Zhu" To: "'Sri Siddhartha Kodali'" , Subject: RE: [ Problems setting up CA server ] Date: Mon, 1 Apr 2002 10:07:10 -0800 Message-ID: <001601c1d9a8$0bb6ff80$6f690d0f@AZ735043> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Openssl can be used as a simple CA server. You may try it from www.openssl.org. Andrew >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sri >Siddhartha Kodali >Sent: Monday, April 01, 2002 12:50 AM >To: ipsec@lists.tislabs.com >Subject: [ Problems setting up CA server ] > > > >Hi !! > >As a part of our project work on Virtual Private Networks using >IPSEC, we have to setup a CA server so that vpn enabled routers can >authenticate and enroll the Certificate Authority Server.We >are not able >to find any freely avialable Certificate Authority servers.Can any one >suggest us freely avialable CA servers on Linux and Windows Platforms > >Thanking You >Siddharth Kodali >siddhu@bits-pilani.ac.in > > From owner-ipsec@lists.tislabs.com Mon Apr 1 10:57: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 g31IvKm16535; Mon, 1 Apr 2002 10:57:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02724 Mon, 1 Apr 2002 13:14:45 -0500 (EST) Message-Id: <200204011822.g31IMqOm025536@coredump.keromytis.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jan Vilhuber Cc: Bill Sommerfeld , andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: Are RSA opertaions cheap? (was Re: Suggestion for SOI wrt PFS) In-reply-to: Your message of "Mon, 01 Apr 2002 09:59:08 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Apr 2002 13:22:52 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: > >You'd probably see the same symptoms (substitute voice traffic for >simple data traffic) on your other example from a few weeks ago: The >palm pilot. I know there are ipsec clients for palm pilots (why you'd >want to is a bit beyond me, but it seems some people have a legitimate >use). I'd be willing to bet money that if you did an rsa operation, >that traffic would effectively stop flowing for the duration of the >rsa operation. Or the operation would take forever, meaning you'd have >to tweak the implementation with nice long timeouts. In pure software, yes (I think an RSA signature with 1024-bit keys takes something like 30 seconds). However, Palm VII has support for EC crypto (I'm not sure if it's software or hardware), which is used every time one connects to the CDPD network --- and it's pretty fast! My cellphone has TLS certificates for use with WAP (although I'll admit I've never used WAP, so I can't comment on its performance...) >The question you must ask yourself is: Do you want ipsec to be >ubiquitous, i.e. useful on as many devices as we can make it work for? >Or do you only want it to be used in situations where people have >450MHz pentiums available? As you may or may not have noticed, many >groups in and outside the IETF are having to come up with their own >keying schemes because IKE won't work for them. I've heard "Oh >please... not IKE" so many times its ridiculous. Protocol complexity >has something to do with it, but as Mike Thomas pointed out in another >posting, there were cases (packetcable just one of them) where the >computations necessary were simply unreasonable. Actually, the cases I know of had everything to do with protocol (and spec) complexity --- I'm somewhat familiar with 3GPP, and the spec was definitely the root cause. >> So you're saying that you *do* have a business need for a box that can >> support a sustained SA setup rate of 1000 tunnels/second ? Could you >> expand on it ? > >Sure. You do the math: How many ipsec peers would it take, rekeying at >(your example) every 20 minutes, to give me a sustained rate of 1000 >tunnels per second? 1.2 million peers on a single box. That's if you actually rekey every 20 seconds (and not every hour or two, or longer, now that we have AES). But let's keep these numbers for a second. You'll need 104MB of RAM just to keep the SPI and the keys for each SA (2 SAs per peer) --- never mind the SPD, credentials, pointers, and all kinds of other bookkeeping information. If you actually add everything up, you'll find out that with 1.2 million peers, you definitely need a 64-bit architecture :-) Now, a box that can route 10Gbit/s and can also do 3DES-SHA1 at the same speed would be able to exchange about 8kbit/s with each peer. I know of a couple of recent "products" (unclear if they will be commercially available, hence the double quotes) that can actually do 10Gbit/s encryption with specialized hardware (no current bus can actually support this rate), but these tend to assume very high traffic aggregation --- they don't do very well when there is a lot (or even *any*) crypto context switching, and they assume instantaneous SPD lookups (think of them as link encryptors using IPsec). Current commercial state-of-the-art crypto hardware does about 1Gbit/sec 3DES-SHA1 (we're ignoring all OS and other network costs for the moment) --- that means about 800 bits/ sec with each peer at *peak* rate, which no bus architecture I know of can actually support (PCI seems to peak at about 600-700kbit/sec). And this is the sum traffic of *both* directions. So, basically, you'll be able to support a keystroke in one direction (TCP packet with SACK+timestamp and a single byte of data in one direction, and the corresponding ACK in the other direction) :-) And that's if you have hardware crypto support for symmetric encryption; if you do it in software, divide you numbers by a factor of 10 to 100 (perhaps more, if you're using a puny CPU). >Why would I NOT want to maximize the number of IPsec peers I can >handle? Doesn't everyone have a business need to maximize the use of >their hardware? If I have one keying scheme where the number of peers >I can support is 1 million, and there's another scheme where (all >things being equal) the number of peers I could handle is 3 million, >which do you think I should pick? Which do you think I should work >towards? If your box cannot support 3 million peers anyway, but it can support 1 million peers with a simpler protocol (and corresponding implementation), which should you work towards ? -Angelos From owner-ipsec@lists.tislabs.com Mon Apr 1 11:26: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 g31JQtm19173; Mon, 1 Apr 2002 11:26:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02890 Mon, 1 Apr 2002 13:46:47 -0500 (EST) Date: Mon, 1 Apr 2002 13:58:22 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Are RSA opertaions cheap? (was Re: Suggestion for SOI wrt PFS) In-Reply-To: <200204011822.g31IMqOm025536@coredump.keromytis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 1 Apr 2002, Angelos D. Keromytis wrote: > If your box cannot support 3 million peers anyway, but it can support > 1 million peers with a simpler protocol (and corresponding implementation), > which should you work towards ? Depends on details. If the simpler protocol gives a performance advantage equal to, say, six months of hardware improvement, that is questionable as a criterion for selection in protocol standardization. That sort of edge would matter only if all else were equal, or very nearly so. In such a case, the simplicity is a stronger argument than the performance advantage. If the advantage is equal to five years' hardware improvement, that's more substantive. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Apr 1 12:32: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 g31KWgm22528; Mon, 1 Apr 2002 12:32:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03289 Mon, 1 Apr 2002 14:56:17 -0500 (EST) Message-Id: <200204012006.g31K6css018688@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: "Catherine A. Meadows" , sommerfeld@east.sun.com, andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: Your message of "Sun, 31 Mar 2002 15:01:31 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 01 Apr 2002 15:06:38 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Generally, people do NOT want to be reprompted for passwords in the > middle of a session, though... this is no doubt one of the reasons why PIC does legacy authentication and issues certs prior to kicking off IKE. - Bill From owner-ipsec@lists.tislabs.com Mon Apr 1 12:36: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 g31Kajm22618; Mon, 1 Apr 2002 12:36:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03310 Mon, 1 Apr 2002 15:01:29 -0500 (EST) Date: Mon, 1 Apr 2002 12:13:03 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: "Catherine A. Meadows" , , Subject: Re: Suggestion for SOI wrt PFS In-Reply-To: <200204012006.g31K6css018688@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 1 Apr 2002, Bill Sommerfeld wrote: > > Generally, people do NOT want to be reprompted for passwords in the > > middle of a session, though... > > this is no doubt one of the reasons why PIC does legacy authentication > and issues certs prior to kicking off IKE. > Agreed. But note there hasn't been agreement (see Cheryl's requirements document) on whether we want to punt all remote access to IPSRA (thus using PIC), or not. If we use PIC for all legacy authentication (aside: why is it called legacy, when it's still being used extensively?), then the discussion degrades into 'is rsa cheap'... jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Apr 1 12:59: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 g31Kx7m23394; Mon, 1 Apr 2002 12:59:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03430 Mon, 1 Apr 2002 15:26:02 -0500 (EST) Date: Mon, 1 Apr 2002 12:14:16 -0800 (PST) Message-Id: <200204012014.MAA08817@potomac.incog.com> From: Mike Ditto To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com In-reply-to: <200203301834.g2UIYEU00312@fatty.lounge.org> (message from Dan Harkins on Sat, 30 Mar 2002 10:34:14 -0800) Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > On Fri, 29 Mar 2002 19:18:12 PST you wrote [ ... ] > > It is, I believe, not interoperable with other IKE > > implementations configured to segregate traffic between SAs based on > > port number style selectors. Why is this? It is because IKE was > > designed with a concept of "service" that is not compatible with our > > basic design. > > No, it's because this is still not an IPsec-compliant implementation. I think I agree with your facts but you misconstrued my rhetorical question. I was asking, why didn't I just go ahead and create a fully IPsec-compliant system? The answer is that to do so would require a complete redesign of a very complex product, (not only the parts related to security protocols, but the whole policy design) and a loss of functionality that I consider important. This is the basis of my belief that IPsec could and should have been designed with a looser coupling to the policy representation, and that the current design of IPsec precludes some reasonable implementations of network security products (I say "reasonable," because one such implementation works quite well with a non-IPsec form of network layer security). > You would have this problem with SAs that were manually created that > segregated traffic between SAs based on port and protocol. This only > looks like an IKE issue because that is where your non-compliance is > first shown. I don't think that's true, because with manual keying I can map services to SPIs with mutually agreed intended use. It doesn't matter if the two implementations have totally different ways of representing policy if they are independently manually configured. The problem is in trying to express "intended use" over the wire using a protocol that can't describe real services. > What you have proposed so far not only does not solve the problems with > the current approach (the desire to specify a protection of protocols that > float ports such that all the ports it uses are under the protection of a > single SA) it actually creates other problems (that have been discussed > earlier in this thread). I'm aware that I haven't solved the problem. My main point is to suggest that the solution might not lie down the path of making a more complex and comprehensive TS mechanism, but rather might involve finding a way to avoid bringing TS into the protocol at all. > If what you have today is so wonderous and does not suffer from these > "limitations" then don't just sit and snipe and hope. Write a draft that > specifies how traffic should be classified without selectors. Then once > you've done away with selectors there will be no need for an SA establishment > protocol to use them. If I refine my ideas enough to make that worthwhile, I'll do it. I admit I'm not there yet. I wouldn't have brought it up at all except that some others seemed to have arrived at similar ideas and I'm hoping that we can come up with something that works for everybody. -=] Mike [=- From owner-ipsec@lists.tislabs.com Mon Apr 1 13:23: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 g31LNEm24316; Mon, 1 Apr 2002 13:23:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03556 Mon, 1 Apr 2002 15:42:42 -0500 (EST) Message-Id: <200204012052.g31KqDC02006@fatty.lounge.org> To: Mike Ditto Cc: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Mon, 01 Apr 2002 12:14:16 PST." <200204012014.MAA08817@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2003.1017694333.1@tibernian.com> Date: Mon, 01 Apr 2002 12:52:13 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On: Mon, 01 Apr 2002 12:14:16 PST you wrote > Dan Harkins wrote: > > You would have this problem with SAs that were manually created that > > segregated traffic between SAs based on port and protocol. This only > > looks like an IKE issue because that is where your non-compliance is > > first shown. > > I don't think that's true, because with manual keying I can map services > to SPIs with mutually agreed intended use. It doesn't matter if the two > implementations have totally different ways of representing policy if > they are independently manually configured. The problem is in trying to > express "intended use" over the wire using a protocol that can't > describe real services. There is a one-to-one mapping between the selector parameters defined in RFC2401 and the TS types. If you can manually configure protection of some service on a compliant device using RFC2401 selectors and have it interoperate with your non-compliant implementation then I maintain you can allow your IKE implementation to use the TS information it receives to establish them dynamically. If you can do it manually you should be able to write code to do it dynamically. If the TS payload is incapable of describing the real service then so are the selector parameters. And then, as I said, you would be unable to interoperate with an IPsec-compliant device using manually-keyed SAs and therefore this is not an IKE issue. It's an issue of your code not being compliant. Dan. From owner-ipsec@lists.tislabs.com Mon Apr 1 16:32: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 g320WVm16270; Mon, 1 Apr 2002 16:32:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04429 Mon, 1 Apr 2002 18:38:31 -0500 (EST) Message-Id: <200204012348.g31Nm4C03126@fatty.lounge.org> To: Mike Ditto Cc: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Mon, 01 Apr 2002 15:06:59 PST." <200204012306.PAA08872@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3123.1017704884.1@tibernian.com> Date: Mon, 01 Apr 2002 15:48:04 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 01 Apr 2002 15:06:59 PST you wrote > Dan Harkins wrote: > [ ... ] > > If you can manually configure protection of some > > service on a compliant device using RFC2401 selectors and have it interoper >ate > > with your non-compliant implementation then I maintain you can allow your > > IKE implementation to use the TS information it receives to establish them > > dynamically. If you can do it manually you should be able to write code to > > do it dynamically. > > No, the problem is that my definition of a service is translatable > neither to, nor from, a bunch of port numbers. So that means that your definition of a "service" is not translatable to an IPsec selector. > .... as long as they both allow the desired traffic, things work > with manual keying... To manually configure an IPsec-compliant device to "allow the desired traffic" you have to map your idea of this "service" into a set of selectors. Since your definition of a "service" can not be translated into an IPsec selector you are therefore unable to interoperate with an IPsec-compliant device when IKE is removed from your problemspace. Therefore, as I've been saying for quite some time now, it is not an IKE problem. > and would work with IKE if IKE didn't require the > ends to describe in advance what traffic each SA would carry. Manually keyed SAs require you to describe the traffic for each SA in advance too! Dan. From owner-ipsec@lists.tislabs.com Mon Apr 1 16:32: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 g320WWm16283; Mon, 1 Apr 2002 16:32:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04489 Mon, 1 Apr 2002 18:54:09 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Mike Ditto'" Cc: Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) Date: Mon, 1 Apr 2002 18:57:45 -0500 Message-ID: <000901c1d9d9$061785a0$1e72788a@ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <200203300019.QAA08194@potomac.incog.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, what you suggest is a valid alternative to TS. However, if you want to understand what the purpose of TS is, it might be helpful to think of them as an SPD optimization. For every packet that comes in (in addition to enforcing your regular firewalling rules), you must ensure that it originates from a valid IP, on an SA that was negotiated using the correct IKE identity, and that the SA uses the required cryptographic transforms. This is all part of the SPD check. Doing this check for every incoming packet could be very expensive, so it would be nice to have a cache of the selector->SA binding, and that's what the TS does. When you receive a packet on the SA, you simply compare the TSs and this guarantees both that the transforms are acceptable and that the TS->id binding is correct for this flow. Of course, in order to use this optimization, you must be able to guarantee that the TS->SA binding is the best match for any IP/port in the TS. In the general case, this means that your SPD lookup matrix must be invertable. This is why Steve Kent keeps pushing the "decorrelated SPD" model that will be incorporated into RFC 2401bis. Note that the use of TS I just described does not necessarily mean that you have to send the TS on the wire. You could simply attach them to the SA data structure on your end, and this would allow you to express more complicated rules. The reason for sending them on the wire is that IKE acts (among other things) as a policy agreement protocol. By sending the rules you will enforce to the peer (or a subset thereof), you make it easier for the user to diagnose configuration errors. (And since you theoretically already have the TS from the SPD caching mechanism, it isn't difficult to send them on the wire.) 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 Mike Ditto > Sent: Friday, March 29, 2002 7:19 PM > To: dharkins@tibernian.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) > > > On the specific idea of making TS optional, isn't it effectively > optional already? Can't an implementation that has no use for them > always propose wildcard selectors, and always accept (and ignore) any > selectors proposed to it? > > > Dan Harkins wrote: > > If the selectors that defined your particular SPD entry > allowed this > > received packet already then no "broadening" would be necessary. > > That depends on what you mean by SPD. Do you mean the > traffic selectors > affiliated with each SA, as communicated by IKE/SOI/whatever? > Or do you > mean the configured policy that I must enforce? They are quite > different things. Traffic selectors as currently proposed are simple > sets of addresses, protocols, port numbers and the like. My > policy is, > in essence, a function that takes a packet as input and produces a > boolean output. I can't take some selectors and see if they match my > policy, and if I somehow encode my policy function (say, as a > Java class > file or a bit vector with a value for every conceivable IP packet) and > send it to you when we're negotiating a tunnel, it will be just as > useless to you as your traffic selectors are to me. > > I could, with a lot of otherwise unnecessary work, generate a set of > selectors that loosely approximates my policy, and use them > to negotiate > a tunnel with you. If your end does reduce the set at all, I have no > way of knowing whether that subset will actually allow the services I > want to use over that tunnel. In general, the "approximation > selectors" > will include some things that aren't really included by the policy, or > exclude some things that are, or some of both. So there will > always be > a discrepancy between the actual policy and the traffic > selectors. This > could probably be lived with if the discrepancy was small, like a few > corner cases. But for some commonly used services, the discrepancy is > so large that the selectors have no value (because they are wildcards) > or prevent interoperability (because they are too constraining). > > > > A new > > packet that required "broadening a tunnel's traffic > selectors" would BY > > DEFINITION be dropped on the other side so there is no > point in sending > > it under protection of that SA in the first place. > > That is only true if each end somehow knows exactly how the > other end's > policy actually differs from the negotiated traffic selectors. I can > see how this could work if both ends are the same > implementation, or if > both are trivial implementations that don't have any policy other than > addresses and port numbers. But I don't see how it can work in real > life. > > > > If we choose to just do away with the TS payloads (as you > suggest) then > > we have no standard way of agreeing on anything. What would > happen is that > > two boxes would be correctly configured to protect FOO > (some protocol) but > > because the definition of how to implement protection of > FOO is left to the > > imagination of those implementing IPsec the two boxes might > not interoperate. > > We can still agree about any particular packet, which is the > only thing > we have agree on. I don't see why they wouldn't interoperate, unless > their respective definitions of the service are actually incompatible, > which is equally possible regardless of how IKE works or even whether > IPsec is in use at all. > > > -=] Mike [=- > From owner-ipsec@lists.tislabs.com Mon Apr 1 21:51: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 g325pRm27711; Mon, 1 Apr 2002 21:51:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA05993 Tue, 2 Apr 2002 00:04:02 -0500 (EST) Message-ID: <3CA93FF9.7060508@cdac.ernet.in> Date: Tue, 02 Apr 2002 10:52:01 +0530 From: puja User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Sri Siddhartha Kodali CC: ipsec@lists.tislabs.com Subject: Re: [ Problems setting up CA server ] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk go to http://www.openca.org/openca/download-releases.shtml its a freely downloadable CA server regards puja Sri Siddhartha Kodali wrote: >Hi !! > >As a part of our project work on Virtual Private Networks using >IPSEC, we have to setup a CA server so that vpn enabled routers can >authenticate and enroll the Certificate Authority Server.We are not able >to find any freely avialable Certificate Authority servers.Can any one >suggest us freely avialable CA servers on Linux and Windows Platforms > >Thanking You >Siddharth Kodali >siddhu@bits-pilani.ac.in > From owner-ipsec@lists.tislabs.com Mon Apr 1 23:03: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 g3273Nm01439; Mon, 1 Apr 2002 23:03:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06287 Tue, 2 Apr 2002 01:17:29 -0500 (EST) Message-Id: <200204020627.g326QoC03815@fatty.lounge.org> To: Mike Ditto Cc: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Mon, 01 Apr 2002 18:11:02 PST." <200204020211.SAA09117@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3812.1017728810.1@tibernian.com> Date: Mon, 01 Apr 2002 22:26:50 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 01 Apr 2002 18:11:02 PST you wrote > Dan Harkins wrote: > > > and would work with IKE if IKE didn't require the > > > ends to describe in advance what traffic each SA would carry. > > > > Manually keyed SAs require you to describe the traffic for each SA in > > advance too! > > No, there are two differences. Manual keying doesn't require each end > to know what the other end's policy is, and manual keying doesn't > require sending a traffic description on the wire. I can phone you up > and say "Let's set up our gateways to let us talk Telnet on ESP SPI 17 > and HTTP on ESP SPI 42." You configure your implementation your way, > I configure mine my way, and we communicate. You might actually > configure your end to allow FTP and traceroute as well, and my end > will never know or care (but it will reject those packets if you ever > send them). Notice how I didn't say that manual keying requires each end to know what the other end's policy is, nor did I say that it requires sending a traffic description on the wire. I said it requires you to describe the traffic for each SA in advance. And your example of a telephone call (in which the traffic is described) prior to the sending of traffic proves this. Please go back and reread what was written. All I'm saying is that if a certain set of selectors manually configured on one end corresponds to whatever it is you manually do on your end then there is a mapping between a set of IPsec selectors, and therefore an equivalent set of TS payloads, and whatever your configuration looks like. So it should be very straightforward for you to write some code to do that mapping dynamically. > I don't need IPsec selectors on my end, and you're free > to use them on your end. I am not trying to force you to be IPsec-compliant. Only pointing out that if you can truely interoperate with an IPsec-compliant device using manual keying (as you maintain) then it should be easy to write code to interoperate using IKE and TS payloads. Therefore the only problem you have is that you don't want to (or cannot) write the code necessary to do that. But that is not a problem that can or should be solved by this working group. Dan. From owner-ipsec@lists.tislabs.com Tue Apr 2 02:16: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 g32AG5m04654; Tue, 2 Apr 2002 02:16:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA07126 Tue, 2 Apr 2002 04:16:53 -0500 (EST) Message-ID: From: Chris Trobridge To: Michael Thomas , "Angelos D. Keromytis" Cc: ipsec@lists.tislabs.com Subject: RE: Suggestion for SOI wrt PFS Date: Tue, 2 Apr 2002 10:29:07 +0100 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 I share this concern. It's not the required average rate that's the problem - I reckon this is likely to be less than one per second. The issue is the peak rate required when a system (re)starts. This is particularly acute with star networks and impacts onto reliability. Chris -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: 01 April 2002 15:57 To: Angelos D. Keromytis Cc: Jan Vilhuber; Bill Sommerfeld; andrew.krywaniuk@alcatel.com; ipsec@lists.tislabs.com Subject: Re: Suggestion for SOI wrt PFS Angelos D. Keromytis writes: > So you're saying that you *do* have a business need for a box that can > support a sustained SA setup rate of 1000 tunnels/second ? Could you > expand on it ? Oh please. Not everything is a site-site VPN. IKE was specifically deemed useless by Packetcable for cable telephony because restart avalanches of tens or hundreds of *thousands* subscriber boxes would lead to unacceptible down times. That's *one* business need, and hardly a unique one. Any high fan out use of IPsec is going to care a great deal about how the high fan in box behaves, and the number of SA's per second is an important number. Mike ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. From owner-ipsec@lists.tislabs.com Tue Apr 2 05:51: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 g32DpHm20858; Tue, 2 Apr 2002 05:51:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08588 Tue, 2 Apr 2002 08:13:47 -0500 (EST) Date: Mon, 1 Apr 2002 18:11:02 -0800 (PST) Message-Id: <200204020211.SAA09117@potomac.incog.com> From: Mike Ditto To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com In-reply-to: <200204012348.g31Nm4C03126@fatty.lounge.org> (message from Dan Harkins on Mon, 01 Apr 2002 15:48:04 -0800) Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > and would work with IKE if IKE didn't require the > > ends to describe in advance what traffic each SA would carry. > > Manually keyed SAs require you to describe the traffic for each SA in > advance too! No, there are two differences. Manual keying doesn't require each end to know what the other end's policy is, and manual keying doesn't require sending a traffic description on the wire. I can phone you up and say "Let's set up our gateways to let us talk Telnet on ESP SPI 17 and HTTP on ESP SPI 42." You configure your implementation your way, I configure mine my way, and we communicate. You might actually configure your end to allow FTP and traceroute as well, and my end will never know or care (but it will reject those packets if you ever send them). I don't need IPsec selectors on my end, and you're free to use them on your end. -=] Mike [=- From owner-ipsec@lists.tislabs.com Tue Apr 2 05:51: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 g32DpIm20873; Tue, 2 Apr 2002 05:51:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08604 Tue, 2 Apr 2002 08:14:46 -0500 (EST) Date: Tue, 2 Apr 2002 11:17:33 +0530 (IST) From: Sri Siddhartha Kodali To: ipsec@lists.tislabs.com Subject: [CA enrollment for ipsec ] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Respected Sir, I am using a 7100 cisco based VPN router as my vpn(ipsec) gateway. I would want to enroll the VPN gateways with a Certificate Authority Server.I tried out few CA's but all of them support https protocol for authentication and enrollment.but the 7100 vpn router supports only http based protocol..Could you please suggest me some solution for this. Thanking You Yours sincerely Siddharth Kodali siddhu@bits-pilani.ac.in From owner-ipsec@lists.tislabs.com Tue Apr 2 05:51: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 g32DpHm20857; Tue, 2 Apr 2002 05:51:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08568 Tue, 2 Apr 2002 08:11:51 -0500 (EST) Date: Mon, 1 Apr 2002 15:06:59 -0800 (PST) Message-Id: <200204012306.PAA08872@potomac.incog.com> From: Mike Ditto To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com In-reply-to: <200204012052.g31KqDC02006@fatty.lounge.org> (message from Dan Harkins on Mon, 01 Apr 2002 12:52:13 -0800) Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: [ ... ] > If you can manually configure protection of some > service on a compliant device using RFC2401 selectors and have it interoperate > with your non-compliant implementation then I maintain you can allow your > IKE implementation to use the TS information it receives to establish them > dynamically. If you can do it manually you should be able to write code to > do it dynamically. No, the problem is that my definition of a service is translatable neither to, nor from, a bunch of port numbers. There are two mapping functions in use by the two implementations, each can take a particular packet and answer the "does it match" question, but there is no way to compute whether my policy is equivalent to yours except in the context of a particular packet. In general, they won't be exactly equivalent anyway, but as long as they both allow the desired traffic, things work with manual keying, and would work with IKE if IKE didn't require the ends to describe in advance what traffic each SA would carry. -=] Mike [=- From owner-ipsec@lists.tislabs.com Tue Apr 2 05:51: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 g32DpOm20893; Tue, 2 Apr 2002 05:51:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08566 Tue, 2 Apr 2002 08:11:46 -0500 (EST) Message-Id: <200204012225.RAA27174@nwmail.wh.lucent.com> Content-Type: text/plain; charset="koi8-r" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Jan Vilhuber Subject: Re: Suggestion for SOI wrt PFS Date: Mon, 1 Apr 2002 17:22:12 -0500 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA03982 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Monday 01 April 2002 15:13, Jan Vilhuber wrote: > Agreed. But note there hasn't been agreement (see Cheryl's > requirements document) on whether we want to punt all remote access > to IPSRA (thus using PIC), or not. In my opinion - the answer to the above is no. > If we use PIC for all legacy authentication For all non-PK (which some call "legacy" :-) auth? I hope not. > (aside: why is it called > legacy, when it's still being used extensively?), then the discussion > degrades into 'is rsa cheap'... Ah, some PK fanatics believe that if they call, say secure tokens "legacy", it will go away and PK certs come to replace it (:-). And no, RSA isn't cheap. I wonder why some began pulling EC crypto into the discussion, considering the uncertainty of EC patent coverage and scarcity of [free] implementations [for example, I know of one existing, and of none fast]. -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Tue Apr 2 06:03: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 g32E3vm21355; Tue, 2 Apr 2002 06:03:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08637 Tue, 2 Apr 2002 08:27:49 -0500 (EST) Message-ID: <3CA97D70.2A98ED58@ieee.org> Date: Tue, 02 Apr 2002 11:44:16 +0200 From: Khaled Elsayed X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: te-wg@ops.ietf.org, tccc@comsoc.org, itc@comsoc.org, idwg-public@zurich.ibm.com, ipsec@lists.tislabs.com, midcom@ietf.org, pilc@grc.nasa.gov Subject: 2nd CFP IEEE Communications Magazine -- Internet Technology Series Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Apologies if you receive multiple copies. If you are interested in participating in the review process, please see the end of the message. HTML version of this CFP can be found at http://inetseries.tripod.com/cfp.html ---------------------------------------------------------- Call for Papers IEEE Communications Magazine Internet Technology Series Series Editors Michah Lerner (AT&T) and Khaled Elsayed (Cairo University) The Internet Technology series of the IEEE Communications Magazine is calling for original tutorial papers that discuss the following specific topics: - Traffic Engineering for Large Scale IP-based Networks - BGP Scalability Issues and Route optimization Methods in a Multihoming Environment - Performance Enhancement Services and Proxies: Scalable and Practical Methods for Data and Media Services - Verifiable and Affordable Security: Specification and Assurance of Security The IEEE Communications Magazine is read by tens of thousands of Communications Society members. The magazine has also been ranked as the number 1 telecommunications journal according to the ISI citation database for year 2000. The papers will be available on the Internet through Communications Magazine Interactive, the WWW edition of the magazine. Details about IEEE Communications Magazine can be found at http://www.comsoc.org/ci/. Sample publications published within the Internet Technology Series can be found in the January 2001 and July 2001 issues of the IEEE Communications Magazine. Tentative Schedule ================== Manuscripts due: May 1, 2002 Notification of acceptance: July 1, 2002 Final copy due: One month before final publication date Prospective Magazine issue: Oct. 2002 How to Submit Manuscripts ========================= Article Style Information ========================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for content, and will be copyedited for compliance with the magazine's style guidelines. Page proofs will be sent to the contact author for final review prior to publication. Mathematical equations should not be used unless they are vital to the presentation. Even then, they should be kept to a minimum. If the article has numerous equations, please contact the editor handling the manuscript. References should be included only to guide readers to more information on the topic; the reference list should not include every available source (a limit of ten references is recommended). Use footnotes only where necessary. Articles should not exceed 4500 words. Figures and tables should be limited to a combined total of six. If the article exceeds these recommended limits, please contact the editor handling the manuscript. Submission ========================= Electronic submission of manuscripts as either PDF (preferred) or Postscript is required. Please send your submission to both of the series editors: Khaled Elsayed: khaled@ieee.org Michah Lerner: michah@ieee.org ---------------------------------------------------------- For those interested in participating in the review process, please fill in the following form and send it to the editors. Name: Institution/Affiliation: Position (optional): E-mail address: Research Interests: From owner-ipsec@lists.tislabs.com Tue Apr 2 10:12:15 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 g32ICEm08236; Tue, 2 Apr 2002 10:12:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09596 Tue, 2 Apr 2002 12:17:27 -0500 (EST) From: "Andrew Wenlang Zhu" To: "'Sri Siddhartha Kodali'" , Subject: RE: [CA enrollment for ipsec ] Date: Tue, 2 Apr 2002 09:28:59 -0800 Message-ID: <000201c1da6b$e0eed970$6f690d0f@AZ735043> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems that 7100 VPN uses SCEP to enroll the certificate. Verisign support SCEP and you could get a certificate for test purpose. But I do not remember the detailed application process. Andrew >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sri >Siddhartha Kodali >Sent: Monday, April 01, 2002 9:48 PM >To: ipsec@lists.tislabs.com >Subject: [CA enrollment for ipsec ] > > > >Respected Sir, > >I am using a 7100 cisco based VPN router as my vpn(ipsec) gateway. >I would want to enroll the VPN gateways with a Certificate Authority >Server.I tried out few CA's but all of them support https protocol >for authentication and enrollment.but the 7100 vpn router supports >only http based protocol..Could you please suggest me some solution >for this. > >Thanking You >Yours sincerely >Siddharth Kodali >siddhu@bits-pilani.ac.in > > > From owner-ipsec@lists.tislabs.com Tue Apr 2 13:06: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 g32L6Bm17106; Tue, 2 Apr 2002 13:06:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10559 Tue, 2 Apr 2002 15:21:47 -0500 (EST) Date: Tue, 2 Apr 2002 12:04:56 -0800 (PST) Message-Id: <200204022004.MAA09425@potomac.incog.com> From: Mike Ditto To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com In-reply-to: <200204020627.g326QoC03815@fatty.lounge.org> (message from Dan Harkins on Mon, 01 Apr 2002 22:26:50 -0800) Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > All I'm saying is that if a certain set of selectors manually configured on > one end corresponds to whatever it is you manually do on your end then there > is a mapping between a set of IPsec selectors, and therefore an equivalent > set of TS payloads, and whatever your configuration looks like. But the two ends' configurations DON'T correspond to each other. Each end has a policy that describes a superset of the traffic that will actually be sent. Probably both ends have defined a policy that uses the smallest superset that their respective policy notations allow. But they are in general not the same superset if they do not use the same notation. To require them to use the same notation is an unnecessary constraint on the implementations, and an unclean overlapping of layers of the security "stack". > So it should > be very straightforward for you to write some code to do that mapping > dynamically. It's not. What you seem to keep missing is that it is possible and useful to classify packets by criteria that don't directly correspond to port numbers. There is no translation from such a classifier to a list of IPsec-style selectors. The only thing that my policy and the other end's 2401-style policy have in common is that they both describe a superset of the traffic that will actually be carried, and they can both answer the "does it match" question about a particular packet. I know that the problem I'm describing is not a problem that past IPsec work has aimed to solve. I wouldn't be spending so much effort describing a new problem that future IPsec designs could solve except for the fact that there is probably a common solution to this one and the problem of "dynamic ports". They are essentially the same problem, that the traffic selection description is not flexible enough to describe more complex services. They are different in that the dynamic ports problem can be solved by a more complex TS agreement mechanism, while my problem can not be solved that way. I think they can both be solved by avoiding TS agreement. When I have a more concrete proposal I'll let the group know. -=] Mike [=- From owner-ipsec@lists.tislabs.com Tue Apr 2 13:50: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 g32LoRm17963; Tue, 2 Apr 2002 13:50:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10743 Tue, 2 Apr 2002 16:10:02 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200204022004.MAA09425@potomac.incog.com> References: <200204022004.MAA09425@potomac.incog.com> Date: Tue, 2 Apr 2002 16:15:40 -0500 To: Mike Ditto From: Stephen Kent Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:04 PM -0800 4/2/02, Mike Ditto wrote: >Dan Harkins wrote: > > All I'm saying is that if a certain set of selectors manually configured on > > one end corresponds to whatever it is you manually do on your end >then there > > is a mapping between a set of IPsec selectors, and therefore an equivalent > > set of TS payloads, and whatever your configuration looks like. > >But the two ends' configurations DON'T correspond to each other. Each >end has a policy that describes a superset of the traffic that will >actually be sent. Probably both ends have defined a policy that uses >the smallest superset that their respective policy notations allow. But >they are in general not the same superset if they do not use the same >notation. To require them to use the same notation is an unnecessary >constraint on the implementations, and an unclean overlapping of layers >of the security "stack". I have to disagree with this assertion. The language used to describe security policies could, as you note, be a purely local matter, but to do so invites trouble. Security policies applied to IPsec SAs, unlike in most firewall security policy descriptions, must be compatible with the policies of peer IPsec devices with which communication is enabled. Thus it is appropriate to adopt uniform means of describing that policy, to facilitate secure communication. Abesnt a uniform means of describing a policy, two peers trying to communicate have a lot of ways to miscommunicate the policy and thus waste lots of time debugging mysterious problems. IPsec allows for the user interface to represent policy info to a user or administrator in any fashion that is powerful enough to represent what the SPD mandates as a minimal functionality. There is not standard imposed on representation at that interface, which is consistent with the way most IETF standards work. However, transmission of the policy info via IKE payloads provides the standard representation I alluded to above, to minimize the ambiguities that might otherwise arise. There is no layer violation here. > > > So it should > > be very straightforward for you to write some code to do that mapping > > dynamically. > >It's not. What you seem to keep missing is that it is possible and >useful to classify packets by criteria that don't directly correspond to >port numbers. There is no translation from such a classifier to a list >of IPsec-style selectors. The only thing that my policy and the other >end's 2401-style policy have in common is that they both describe a >superset of the traffic that will actually be carried, and they can both >answer the "does it match" question about a particular packet. Ultimately, whatever policy you employ is reducible to a set of syntactic checks on packets (plus, if you want to get fancy, maybe other inputs like TOD). The current set of traffic selectors was designed to accommodate a range of policies and we are planning to expand that range, to better accommodate the needs of users. Are you suggesting that the policies you perceive as necessary to express cannot be translated into some form of selectors, not just the current set but a more extensive set that we can provide going forward? If so, some examples would be useful. >I know that the problem I'm describing is not a problem that past IPsec >work has aimed to solve. I wouldn't be spending so much effort >describing a new problem that future IPsec designs could solve except >for the fact that there is probably a common solution to this one and >the problem of "dynamic ports". They are essentially the same problem, >that the traffic selection description is not flexible enough to >describe more complex services. They are different in that the dynamic >ports problem can be solved by a more complex TS agreement mechanism, >while my problem can not be solved that way. I think they can both be >solved by avoiding TS agreement. When I have a more concrete proposal >I'll let the group know. Dynamic ports can be accommodated, I think, based on comments we have received from other developers. So, yes, we need a better description of your problem in order to understand what the issues are. Steve From owner-ipsec@lists.tislabs.com Tue Apr 2 15:12: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 g32NCjm21820; Tue, 2 Apr 2002 15:12:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11003 Tue, 2 Apr 2002 17:25:21 -0500 (EST) Message-Id: <200204022234.g32MYlE00808@fatty.lounge.org> To: Mike Ditto Cc: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) In-Reply-To: Your message of "Tue, 02 Apr 2002 12:04:56 PST." <200204022004.MAA09425@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <805.1017786887.1@tibernian.com> Date: Tue, 02 Apr 2002 14:34:47 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 02 Apr 2002 12:04:56 PST you wrote > > What you seem to keep missing is that it is possible and > useful to classify packets by criteria that don't directly correspond to > port numbers. There is no translation from such a classifier to a list > of IPsec-style selectors. Well then it is possible to configure your box to classify a flow in a way that is not possible to configure on an IPsec-compliant box. Therefore you are a non-interoperable implementation EVEN WHEN IKE IS NOT USED. Therefore this problem you have is not one of IKE using TS payloads because even if it didn't YOU STILL WOULD NOT INTEROPERATE. I don't keep missing it. I'm just ignoring it because you are trying to simultaneously maintain two contradictory positions and I am trying to pin you down. The utility of what you describe is irrelevant to the problem you brought up (you can't interoperate with IKE) and the solution you proposed (to get rid of the TS payload). You basically can't have it both ways (even though you are trying to by selectively bringing up one side in one email and another in a different). Either you can interoperate with manually-keyed SAs, and therefore all you need to do is write some code and you'd work with IKE; or you can't interoperate with manually-keyed SAs in which case it is your problem because you are intentionally non-compliant. Dan. From owner-ipsec@lists.tislabs.com Tue Apr 2 15: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 g32NFmm21896; Tue, 2 Apr 2002 15:15:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11038 Tue, 2 Apr 2002 17:40:19 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15530.13836.843000.200635@gargle.gargle.HOWL> Date: Tue, 2 Apr 2002 17:51:56 -0500 From: Paul Koning To: ford@incog.com Cc: ipsec@lists.tislabs.com Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2) References: <200204020627.g326QoC03815@fatty.lounge.org> <200204022004.MAA09425@potomac.incog.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 2 April 2002) by Mike Ditto: > Dan Harkins wrote: > > All I'm saying is that if a certain set of selectors manually configured on > > one end corresponds to whatever it is you manually do on your end then there > > is a mapping between a set of IPsec selectors, and therefore an equivalent > > set of TS payloads, and whatever your configuration looks like. > > But the two ends' configurations DON'T correspond to each other. Each > end has a policy that describes a superset of the traffic that will > actually be sent. Probably both ends have defined a policy that uses > the smallest superset that their respective policy notations allow. That's not enough. Implementing a policy, in the case of IPsec at least, means (a) accepting traffic that matches the rule, and also (b) rejecting ALL traffic that does not match the rule. So "a superset" is not a valid substitute for an exact match. paul From owner-ipsec@lists.tislabs.com Tue Apr 2 21:03: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 g33535m28787; Tue, 2 Apr 2002 21:03:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12484 Tue, 2 Apr 2002 23:06:38 -0500 (EST) Message-Id: <3.0.5.32.20020402225856.00845d00@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 02 Apr 2002 22:58:56 -0500 To: touch@ISI.EDU, larse@ISI.EDU From: Mark Duffy Subject: questions on draft-touch-ipsec-vpn Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a few questions for the authors of draft-touch-ipsec-vpn-03.txt. The draft addresses the use of IPsec to secure the virtual links of an overlay network. In this application, the goal is to make forwarding decisions based on evaluating the packet destination address against a forwarding table, rather than by evaluating a set of packet selectors against an SPD. I.e. the policy aspect of IPsec is not desired in this application and must somehow be gotten around. The draft describes using IP-in-IP tunnelling and securing the result with transport mode IPsec (IIPtran). Why choose this approach over simply negotiating tunnel mode IPsec with wild-card selectors (i.e. 0.0.0.0/0) and then at a higher level using the routing decision to choose which tunnel to use? IIPtran may appear to retain more vestiges of IPsec policy (i.e. the policy being to apply transport mode IPsec to all traffic between the tunnel end points) but I believe this is illusory as in fact the same packets get the same IPsec treatment with IIPtran as with the wild-card selectors approach. In the final analysis, both approaches make the entire decision based only on the overlay forwarding table. I get a hint from reading the draft that the proposal may be motivated by an implementation environment where there is already a platform with an IP stack and IPsec embedded in it, and it is desired not to change the IPsec implementation or its relationship to the rest of the IP stack. Is that the reason for this choice of approaches? Thanks, Mark From owner-ipsec@lists.tislabs.com Tue Apr 2 22:45: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 g336jmm00473; Tue, 2 Apr 2002 22:45:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA12871 Wed, 3 Apr 2002 01:01:52 -0500 (EST) Message-ID: <3CAA9D8A.1090500@isi.edu> Date: Tue, 02 Apr 2002 22:13:30 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Mark Duffy CC: larse@ISI.EDU, ipsec@lists.tislabs.com Subject: Re: questions on draft-touch-ipsec-vpn References: <3.0.5.32.20020402225856.00845d00@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy wrote: > Hi, I have a few questions for the authors of draft-touch-ipsec-vpn-03.txt. > > The draft addresses the use of IPsec to secure the virtual links of an > overlay network. In this application, the goal is to make forwarding > decisions based on evaluating the packet destination address against a > forwarding table, rather than by evaluating a set of packet selectors > against an SPD. I.e. the policy aspect of IPsec is not desired in this > application and must somehow be gotten around. > > The draft describes using IP-in-IP tunnelling and securing the result with > transport mode IPsec (IIPtran). Why choose this approach over simply > negotiating tunnel mode IPsec with wild-card selectors (i.e. 0.0.0.0/0) and > then at a higher level using the routing decision to choose which tunnel to > use? This was addressed in a presentation in Minneapolis. The counterexample is when two tunnels, both with wildcard selectors, go out the same physical interface. In that case, the routing table has insufficient information to indicate which tunnel to use. There are two solutions: 1. use IIPtran 2. use a new virtual device for each new IPsec tunnel i.e., such that the routing table sends packets to that device name These two solutions are equivalent in function, but different in complexity. #2 implies that all SPDs have either one or more transport mode SA, or exactly one tunnel mode SA (and no transport mode SAs). This ends up treating tunnel mode as a special case w.r.t. association with devices, for an indirect (routing) reason. We feel that IIPtran is a simpler and more direct solution, as it acknoweldges the separate functions of tunneling and IPsec. > I get a hint from reading the draft that the proposal may be motivated by > an implementation environment where there is already a platform with an IP > stack and IPsec embedded in it, and it is desired not to change the IPsec > implementation or its relationship to the rest of the IP stack. Is that > the reason for this choice of approaches? We certainly prefer solutions that don't require new protocols or new implementations where possible. IIPtran achieves more of that than #2 above as well. Joe From owner-ipsec@lists.tislabs.com Wed Apr 3 06:44: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 g33EiTm19568; Wed, 3 Apr 2002 06:44:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14855 Wed, 3 Apr 2002 08:55:30 -0500 (EST) Date: Tue, 2 Apr 2002 15:36:27 -0800 (PST) Message-Id: <200204022336.PAA09543@potomac.incog.com> From: Mike Ditto To: ipsec@lists.tislabs.com Subject: Is TS agreement necessary? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hypothesis: If we were satisfied to let all traffic of equivalent security characteristics (identities, transforms, etc.) share a single SA (or to be distributed arbitrarily among multiple equivalent SAs), we wouldn't need any traffic selector agreement (or negotiation, whatever) protocol. TS payloads tell the other end how you want your traffic segregated between multiple equivalent SAs, and when it must negotiate a new SA even though there already exists one with the right parameters. In case I'm not being clear with terminology, by "traffic segregation" I mean segregation of traffic from multiple sources (i.e. users) but equivalent IPsec security parameters into different SAs to protect mutually distrusting users against known-plaintext or DoS attacks from other users of the same secure tunnel. Eliminating TS agreement would solve the dynamic ports problem and eliminate my other complaint about IKE, already much too verbosely discussed recently here. But then, how to solve the traffic segregation problem? What if this kind of traffic segregation was performed at the sender's discretion? I.e. each end independently decides how to segregate the traffic it sends, and accepts the other end's choice as long as it meets the general security parameters required by the policy. During SA establishment, the initiator specifies in an abstract way the degree of sharing to apply to each proposed SA (pair). I see three levels of sharing being important: completely shared, unique address, and unique session. Unique address means that once the SA (pair) has been used to talk to a particular remote address, it can't be used for sending to any other remote address. Unique session means the analogous thing with session, where "session" is defined by the implementation. A recommended model for defining "session" would be based on the TCP/UDP 5-tuple, but implementations would be allowed to vary to some degree. This way, if my implementation considers the control connection and the data connections of an FTP session to be one "session", and the other end considers those to be multiple distinct "sessions", there is still interoperability. It might be a good idea even to allow simple IPsec implementations (e.g. for embedded use) not to implement traffic segregation, falling back to "completely shared" SAs, in a transparently interoperable way. Two questions: Does this meet the requirements of those who strongly believe in the importance of this kind of traffic segregation? I'm not such a strong believer; most of the scenarios I've heard where it's relevant seem to have nearly identical weaknesses with and without traffic segregation, or are better handled by assigning unique identities to the unique users. But I'll take others' word that it's an important capability, and ask such people whether this proposal is sufficient. Is this idea actually simpler than the workable alternatives? I haven't seen a concrete proposal for extending TS to handle dynamic ports, so I can't offer an opinion on that alternative yet. -=] Mike [=- From owner-ipsec@lists.tislabs.com Wed Apr 3 06:44: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 g33EiXm19580; Wed, 3 Apr 2002 06:44:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14861 Wed, 3 Apr 2002 08:56:31 -0500 (EST) Message-Id: <200204030446.XAA13831@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: "Michael Thomas" Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Date: Tue, 2 Apr 2002 23:43:21 -0500 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com, marcovici@lucent.com References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <15530.22026.752100.186019@thomasm-u1.cisco.com> In-Reply-To: <15530.22026.752100.186019@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id XAA12589 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tuesday 02 April 2002 20:08, Michael Thomas wrote: > > If people want a "light weight" keying scheme for > IPsec, it should either be pursued in IPsec WG, or > through a BOF......As I've mentioned, there are some > of our folks who have some interest in this, and > their scheme doesn't require per node storage of > anything but the key and something akin to the > EngineBoots counter in SNMPv3. This would be a > much better solution to this problem. Actually, this is interesting - because indeed there are applications and protocols that want to use IPsec for protection, but don't want to use IKE for key negotiation. For example, SIP would prefer AKA to arrive at the shared session keys... My only concern is that the BOF road may take too long. What would IPSEC WG folks say about a lightweight protocol, that has most of the SA parameters pre-defined (hard-coded), and very few left for negotiation (the keys, and maybe something else)? A good question is whether those interested can agree upon such an arrangement (and if not - then IKE-like protocol is a-must, to offer negotiation of every thing that somebody must have). Mike, could you put me in touch with those people who are interested? Thanks! -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Wed Apr 3 06:52: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 g33Eqam19724; Wed, 3 Apr 2002 06:52:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15082 Wed, 3 Apr 2002 09:18:44 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15531.4608.584000.178711@gargle.gargle.HOWL> Date: Wed, 3 Apr 2002 09:30:24 -0500 From: Paul Koning To: touch@ISI.EDU Cc: ipsec@lists.tislabs.com Subject: Re: questions on draft-touch-ipsec-vpn References: <3.0.5.32.20020402225856.00845d00@email.quarrytech.com> <3CAA9D8A.1090500@isi.edu> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 2 April 2002) by Joe Touch: > There are two solutions: > > 1. use IIPtran > > 2. use a new virtual device for each new IPsec tunnel > i.e., such that the routing table sends packets to that device name > > These two solutions are equivalent in function, but different in > complexity. #2 implies that all SPDs have either one or more transport > mode SA, or exactly one tunnel mode SA (and no transport mode SAs). This > ends up treating tunnel mode as a special case w.r.t. association with > devices, for an indirect (routing) reason. That sure sounds like an implementation detail that's an artifact of a particular implementation choice. Virtual devices and routing tables don't exist in the RFCs, for good reasons -- they are an internal matter. You can use them if you like, or use something else if that is easier. I built an implementation that does not require a virtual device per tunnel -- that approach never came up as a possibility during the design. Tunnel mode is functionally equivalent to transport mode applied to an IP-IP tunnel, and in fact is inspired by that construct even if it's not identical in all details. If you want to talk with other implementations that happen to have IP-IP tunneling implemented for some reason, and they also include transport mode, then clearly you can use that stack. Of course, a lot of security gateways don't care to implement such a stack. On the other hand, if you mean to mandate such a combination as a replacement, or an additional requirement, in place of tunnel mode, I have to object. paul From owner-ipsec@lists.tislabs.com Wed Apr 3 08:05: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 g33G5am27317; Wed, 3 Apr 2002 08:05:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15366 Wed, 3 Apr 2002 10:17:19 -0500 (EST) Message-ID: <3CAB122B.8000505@kolumbus.fi> Date: Wed, 03 Apr 2002 17:31:07 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: uri@bell-labs.com Cc: Michael Thomas , ipsec@lists.tislabs.com, marcovici@lucent.com Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <15530.22026.752100.186019@thomasm-u1.cisco.com> <200204030446.XAA13831@nwmail.wh.lucent.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Uri Blumenthal wrote: > On Tuesday 02 April 2002 20:08, Michael Thomas wrote: > > > > If people want a "light weight" keying scheme for > > IPsec, it should either be pursued in IPsec WG, or > > through a BOF......As I've mentioned, there are some > > of our folks who have some interest in this, and > > their scheme doesn't require per node storage of > > anything but the key and something akin to the > > EngineBoots counter in SNMPv3. This would be a > > much better solution to this problem. > > Actually, this is interesting - because indeed there are applications > and protocols that want to use IPsec for protection, but don't want > to use IKE for key negotiation. This is true, but from the point of view of Mobile IPv6, we didn't really want to enter the discussion of key management protocols. (I'm personally sure that Son-of-IKE will solve many of the problems IKE has, though I haven't checked lately to verify this.) Instead, what the Mobile IPv6 folks wanted to do was to use IPsec as-is for certain tasks. One of these tasks was protection of BUs between the MN and the CN. Now, our options in regards to this are as follows: 1. Require IPsec + IKE. No replay problem. 2. Require at least IPsec, but keep IKE as optional. Don't add any features for replay protection. Folks who don't use IKE will suffer from the replay vulnerability. 3. Require at least IPsec, optional IKE but add an application layer feature for replay protection to prevent replays if you happened to not have IKE. This was the DT-recommended approach. 4. Require at least IPSec and a TBD light weight key management scheme, perhaps optional IKE in some cases. No application layer features. Replay protection works perfectly for everyone. Somehow I think that if we are targeting RFC in about a month or so option #4 isn't going to give us that. However, this discussion has caused me to rethink some of the reasons on why we recommended option #3. Option #2 might also be quite reasonable, and would have the added benefit that whatever the IETF keeps generating on the key management front could easily be adopted whenever it becomes available. KINK could be used in environments where it is available, for instance, and Son-of-IKE when it gets ready. OTOH, the application layer replay protection has* been in the mobile ipv6 drafts from the stone age so I don't think that it's such a bad idea either. Comments? Jari *) We have been discussing a modification of the replay protection on the list, to require NV memory to be used or not. From owner-ipsec@lists.tislabs.com Wed Apr 3 08:43:56 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 g33Ghtm28849; Wed, 3 Apr 2002 08:43:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15609 Wed, 3 Apr 2002 11:01:01 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15531.10727.959342.461589@thomasm-u1.cisco.com> Date: Wed, 3 Apr 2002 08:12:23 -0800 (PST) To: Jari Arkko Cc: uri@bell-labs.com, Michael Thomas , ipsec@lists.tislabs.com, marcovici@lucent.com Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? In-Reply-To: <3CAB122B.8000505@kolumbus.fi> References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <15530.22026.752100.186019@thomasm-u1.cisco.com> <200204030446.XAA13831@nwmail.wh.lucent.com> <3CAB122B.8000505@kolumbus.fi> 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 I honestly don't see why MIP needs to go beyond saying "use IPsec, beware manual keys". That is, so long as there is a viable way of keying IPsec which enables replay protection -- and there is -- MIP doesn't need to be any more specific *how* to do that. If people want a lighter weight option than either IKE, JFK, KINK etc, than that is a IPsec WG problem. But MIP, IMO, doesn't need to boil the ocean here. If it's an interesting problem to solve for MIP, it's an equally interesting problem to solve for a whole slew of other protocols which might be protected by IPsec. That is, generality good, one-off bad. In any case, my larger point here is that a mandatory mechanism for MIP which requires per node consumption of NVRAM on a Home Agent as a MUST IMPLEMENT, where IKE, JFK, KINK, etc don't place any such requirements on IPsec seems onerous, and should be optional. Ideally, it would be one of a set of acceptible choices. Mike Jari Arkko writes: > Uri Blumenthal wrote: > > > On Tuesday 02 April 2002 20:08, Michael Thomas wrote: > > > > > > If people want a "light weight" keying scheme for > > > IPsec, it should either be pursued in IPsec WG, or > > > through a BOF......As I've mentioned, there are some > > > of our folks who have some interest in this, and > > > their scheme doesn't require per node storage of > > > anything but the key and something akin to the > > > EngineBoots counter in SNMPv3. This would be a > > > much better solution to this problem. > > > > Actually, this is interesting - because indeed there are applications > > and protocols that want to use IPsec for protection, but don't want > > to use IKE for key negotiation. > > > This is true, but from the point of view of Mobile IPv6, we didn't > really want to enter the discussion of key management protocols. (I'm > personally sure that Son-of-IKE will solve many of the problems IKE has, > though I haven't checked lately to verify this.) > > Instead, what the Mobile IPv6 folks wanted to do was to use IPsec as-is > for certain tasks. One of these tasks was protection of BUs between the > MN and the CN. Now, our options in regards to this are as follows: > > 1. Require IPsec + IKE. No replay problem. > 2. Require at least IPsec, but keep IKE as optional. Don't add > any features for replay protection. Folks who don't use IKE > will suffer from the replay vulnerability. > 3. Require at least IPsec, optional IKE but add an application > layer feature for replay protection to prevent replays if > you happened to not have IKE. This was the DT-recommended > approach. > 4. Require at least IPSec and a TBD light weight key management > scheme, perhaps optional IKE in some cases. No application > layer features. Replay protection works perfectly for everyone. > > Somehow I think that if we are targeting RFC in about a month or so > option #4 isn't going to give us that. However, this discussion has > caused me to rethink some of the reasons on why we recommended > option #3. Option #2 might also be quite reasonable, and would have > the added benefit that whatever the IETF keeps generating on the > key management front could easily be adopted whenever it becomes > available. KINK could be used in environments where it is available, > for instance, and Son-of-IKE when it gets ready. OTOH, the application > layer replay protection has* been in the mobile ipv6 drafts from the > stone age so I don't think that it's such a bad idea either. > > Comments? > > Jari > *) We have been discussing a modification of the replay protection > on the list, to require NV memory to be used or not. > From owner-ipsec@lists.tislabs.com Wed Apr 3 10:09: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 g33I9Im03442; Wed, 3 Apr 2002 10:09:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15947 Wed, 3 Apr 2002 12:20:05 -0500 (EST) Message-ID: <3CAB3CCE.68852E3C@sonicwall.com> Date: Wed, 03 Apr 2002 09:33:02 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Ditto CC: ipsec@lists.tislabs.com Subject: Re: Is TS agreement necessary? References: <200204022336.PAA09543@potomac.incog.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2002 17:32:44.0988 (UTC) FILETIME=[90A9C7C0:01C1DB35] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Mike, Suppose, as you suggest, that we allowed negotiation of multiple SAs between two peers without specifying TS values. Ultimately, there must be *some* policy rule associated with each of these SAs since, as you suggest, the point is to somehow segregate traffic between them. That is, for a given SA, some traffic is allowed, and some is not. Please elaborate upon how we determine which traffic is appropriate for each SA once they are established. As an aside, can you tell us why wildcard TS values do not satisfy your requirements in the same way that omitting TS values would? Thanks, Scott Mike Ditto wrote: > > Hypothesis: If we were satisfied to let all traffic of equivalent > security characteristics (identities, transforms, etc.) share a single > SA (or to be distributed arbitrarily among multiple equivalent SAs), we > wouldn't need any traffic selector agreement (or negotiation, whatever) > protocol. TS payloads tell the other end how you want your traffic > segregated between multiple equivalent SAs, and when it must negotiate a > new SA even though there already exists one with the right parameters. > > In case I'm not being clear with terminology, by "traffic segregation" I > mean segregation of traffic from multiple sources (i.e. users) but > equivalent IPsec security parameters into different SAs to protect > mutually distrusting users against known-plaintext or DoS attacks from > other users of the same secure tunnel. > > Eliminating TS agreement would solve the dynamic ports problem and > eliminate my other complaint about IKE, already much too verbosely > discussed recently here. But then, how to solve the traffic segregation > problem? > > What if this kind of traffic segregation was performed at the sender's > discretion? I.e. each end independently decides how to segregate the > traffic it sends, and accepts the other end's choice as long as it meets > the general security parameters required by the policy. During SA > establishment, the initiator specifies in an abstract way the degree of > sharing to apply to each proposed SA (pair). I see three levels of > sharing being important: completely shared, unique address, and unique > session. Unique address means that once the SA (pair) has been used to > talk to a particular remote address, it can't be used for sending to any > other remote address. Unique session means the analogous thing with > session, where "session" is defined by the implementation. A > recommended model for defining "session" would be based on the TCP/UDP > 5-tuple, but implementations would be allowed to vary to some degree. > > This way, if my implementation considers the control connection and the > data connections of an FTP session to be one "session", and the other > end considers those to be multiple distinct "sessions", there is still > interoperability. > > It might be a good idea even to allow simple IPsec implementations > (e.g. for embedded use) not to implement traffic segregation, falling > back to "completely shared" SAs, in a transparently interoperable way. > > Two questions: > > Does this meet the requirements of those who strongly believe in the > importance of this kind of traffic segregation? I'm not such a strong > believer; most of the scenarios I've heard where it's relevant seem to > have nearly identical weaknesses with and without traffic segregation, > or are better handled by assigning unique identities to the unique > users. But I'll take others' word that it's an important capability, > and ask such people whether this proposal is sufficient. > > Is this idea actually simpler than the workable alternatives? I haven't > seen a concrete proposal for extending TS to handle dynamic ports, so I > can't offer an opinion on that alternative yet. > > -=] Mike [=- From owner-ipsec@lists.tislabs.com Wed Apr 3 10:19: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 g33IJcm04410; Wed, 3 Apr 2002 10:19:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16086 Wed, 3 Apr 2002 12:40:27 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15531.16691.268161.547825@thomasm-u1.cisco.com> Date: Wed, 3 Apr 2002 09:51:47 -0800 (PST) To: uri@bell-labs.com Cc: Michael Thomas , Jari Arkko , ipsec@lists.tislabs.com, marcovici@lucent.com, Black_David@emc.com Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? In-Reply-To: <200204031734.MAA27006@nwmail.wh.lucent.com> References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <3CAB122B.8000505@kolumbus.fi> <15531.10727.959342.461589@thomasm-u1.cisco.com> <200204031734.MAA27006@nwmail.wh.lucent.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 Uri wrote: > On Wednesday 03 April 2002 11:12, Michael Thomas wrote: > > I honestly don't see why MIP needs to go beyond > > saying "use IPsec, beware manual keys".=20 > > Because nobody really WANTS to use manual keys? > And because while IKEv1 is a hog (and no real negotiation > seems necessary), something VERY light-weight is needed? > > >That is, so long as there is a viable way of keying IPsec > > which enables replay protection -- and there is -- > > MIP doesn't need to be any more specific *how* to > > do that. > > Don't you think there might be interoperability issues if the exact way=20 > of keying IPsec is omitted? Also, creating SA is *more* than just=20 > keying.=20 I don't think that "interoperability" is quite the right word here. A mobile node and home agent which run IPsec/IKE could be interoperable. However, in practice unless I am part of that domain, know the right authentication mechanisms, etc, we might not be able to mutually authenticate. This is a deployment issue, however, not an interoperability issue. Use of IKE, SOI, KINK, manualkey, manualkey+ are all deployment isses, IMO. I don't think the IETF needs to be in the business of saying which choice to make here, and certainly not MIP WG. I think it's quite reasonable for MIP to say that something better than straight manual keys is needed, but specifying how it's accomplished shouldn't be a requirement any more than MIP shouldn't be saying that you must implement IKE with certs or IKE with pre-shared keys, or IKE with AAA hacks, or whatever. > 1. "Negotiate on paper" - i.e. define most if not all the attributes of=20 > SA that should satisfy usage criteriae (including the crypto suite). > 2. Select a simple key agreement protocol (any Bellare-Rogaway=20 > derivative should do nicely) - such as *interlocked* CHAP or AKA. > 3. Specify all of the above in a generic draft. IMO, at the point you have to put a shared key into both boxes, you might as well put the rest of the information in there too. At the point you want to start negotiating stuff, you've already gone beyond "lightweight" IMHO :-) > > In any case, my larger point here is that a > > mandatory mechanism for MIP which requires per > > node consumption of NVRAM on a Home Agent as a > > MUST IMPLEMENT, where IKE, JFK, KINK, etc don't > > place any such requirements on IPsec seems > > onerous, and should be optional. Ideally, it > > would be one of a set of acceptible choices. > > The above doesn't make sense, because you *have* to have something in=20 > NVRAM regardless. The question is - exactly what. And a simplified=20 > approach allows you to "memorize" less than IKE or JFK would=20 > require.=20 You don't need *per node* permanent memory for IKE/KINK/SOI. That's the difference. Mike From owner-ipsec@lists.tislabs.com Wed Apr 3 10:28: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 g33ISvm04662; Wed, 3 Apr 2002 10:28:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16166 Wed, 3 Apr 2002 12:49:11 -0500 (EST) Message-ID: <3CAB35BC.3030304@kolumbus.fi> Date: Wed, 03 Apr 2002 20:02:52 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: uri@bell-labs.com, ipsec@lists.tislabs.com, marcovici@lucent.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <15530.22026.752100.186019@thomasm-u1.cisco.com> <200204030446.XAA13831@nwmail.wh.lucent.com> <3CAB122B.8000505@kolumbus.fi> <15531.10727.959342.461589@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas wrote: > I honestly don't see why MIP needs to go beyond > saying "use IPsec, beware manual keys". > ... > In any case, my larger point here is that a > mandatory mechanism for MIP which requires per > node consumption of NVRAM on a Home Agent as a > MUST IMPLEMENT, where IKE, JFK, KINK, etc don't > place any such requirements on IPsec seems > onerous, and should be optional. Ideally, it > would be one of a set of acceptible choices. You may have a point here. How about this: 1. We require at least manual IPsec 2. We provide application layer sequence# in order to order BUs (not just prevent replay) 3. We point out that if the HA reboots and loses state when only manually keyed IPsec is used, replays become possible (vendors can still prevent losing state if they want to) Jari From owner-ipsec@lists.tislabs.com Wed Apr 3 10:37:03 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 g33Ib3m04994; Wed, 3 Apr 2002 10:37:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16239 Wed, 3 Apr 2002 12:56:05 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 3 Apr 2002 10:08:11 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Fixing identity and cert-sending Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some folks have asked me if the new identity/cert proposal deals with "legacy authentication" (which is just a negative-sounding codeword for "authentication that doesn't involve public key crypto"). The answer is yes, definitely. Note the terms used for one of the identity types: >6 IDForSharedSecret -- This is only for use with shared secrets. It is an > ASCII string (all octets are 31 < x < 127) of any length. That's "shared secret", not "preshared secret". Neither IKEv2 not JFK tie the secret to the IP address, so there is no need to preshare the key. A legacy auth system usually returns an authentication item, either to the user or to some other system (such as the IPsec gateway). As long as that authentication item has two parts that are cryptographically separate, it can be used with the new proposal. As simple scenario is username-and-password. The IDForSharedSecret is the username, and the key added to the HMAC is the password. When receiving this message, the system looks up the password based on the username, possibly using something like RADIUS. A more complex scenario involves a hardware token that doesn't do public key crypto. Typically, the user does some challenge-response dance with the authenticating server and is then authenticated. At that point, as long as the user has two pieces of authentication information, they can use them in an HMAC. For systems that only return one item (such as a long hash), there must be some agreement on how to split that into two items, such as "80 bits and 80 bits". That can be done by the legacy auth vendor, possibly instantiated in an informational RFC. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 3 10:42: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 g33IgGm05177; Wed, 3 Apr 2002 10:42:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16310 Wed, 3 Apr 2002 13:03:08 -0500 (EST) Message-ID: <3CAB4031.3050706@isi.edu> Date: Wed, 03 Apr 2002 09:47:29 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Koning CC: ipsec@lists.tislabs.com Subject: Re: questions on draft-touch-ipsec-vpn References: <3.0.5.32.20020402225856.00845d00@email.quarrytech.com> <3CAA9D8A.1090500@isi.edu> <15531.4608.584000.178711@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > Excerpt of message (sent 2 April 2002) by Joe Touch: > >>There are two solutions: >> >>1. use IIPtran >> >>2. use a new virtual device for each new IPsec tunnel >>i.e., such that the routing table sends packets to that device name >> >>These two solutions are equivalent in function, but different in >>complexity. #2 implies that all SPDs have either one or more transport >>mode SA, or exactly one tunnel mode SA (and no transport mode SAs). This >>ends up treating tunnel mode as a special case w.r.t. association with >>devices, for an indirect (routing) reason. > > That sure sounds like an implementation detail that's an artifact of a > particular implementation choice. Virtual devices and routing tables > don't exist in the RFCs, for good reasons -- they are an internal > matter. You can use them if you like, or use something else if that > is easier. I built an implementation that does not require a virtual > device per tunnel -- that approach never came up as a possibility > during the design. Which is why we thought that IIPtran was a better way to describe the solution. #2 _requires_ describing what could (and/or should) be considered implementation details. Note, however, that some so-called implementation details have implications in functionality. RFC2401 describes the use of different SPDs for each interface, equivalent to using interface as an additional index into the SPD. Depending on your perspective, this is either an implementation detail or a functionality requirement of the protocol. > Tunnel mode is functionally equivalent to transport mode applied to an > IP-IP tunnel, and in fact is inspired by that construct even if it's > not identical in all details. It is exactly in the details where they differ that cause problems for dynamic routing, as described in our draft. They are not precisely functionally equivalent, in that the order of SPD indexing and forwarding lookup differ, notably for tunnels that exit the same physical interface. > If you want to talk with other implementations that happen to have > IP-IP tunneling implemented for some reason, and they also include > transport mode, then clearly you can use that stack. Of course, a lot > of security gateways don't care to implement such a stack. On the > other hand, if you mean to mandate such a combination as a > replacement, or an additional requirement, in place of tunnel mode, I > have to object. Talking with other implementations requires equivalent packets on the wire, and any endpoint coordination. IIPtran sends the same resulting packets, and does not affect IPsec endpoint coordination (SPD entries). It does affect IKE and other IPsec setup protocols, as described in our draft. We are currently determining how best to proceed with these recommendations in the context of the RFC2401-bis update. We (Lars and I, and a few others) feel that using IIPtran as a replacement for tunnel mode simplifies IPsec and results in increased capability, by removing the redundent description of tunneling as a special case for IPsec. Others feel that IIPtran can be included as an 'equivalent variant' of tunnel mode. In either case, that debate will occur in the context of RFC2401-bis. Our draft is intended to describe the change, not to mandate it. From owner-ipsec@lists.tislabs.com Wed Apr 3 10:42: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 g33Iglm05203; Wed, 3 Apr 2002 10:42:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16317 Wed, 3 Apr 2002 13:04:07 -0500 (EST) Message-ID: <3CAB4092.1060104@isi.edu> Date: Wed, 03 Apr 2002 09:49:06 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Mark Duffy CC: touch@ISI.EDU, ipsec@lists.tislabs.com Subject: Re: questions on draft-touch-ipsec-vpn References: <3.0.5.32.20020402225856.00845d00@email.quarrytech.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040108070609040900070201" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms040108070609040900070201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Duffy wrote: ... > The draft describes using IP-in-IP tunnelling and securing the result with > transport mode IPsec (IIPtran). Why choose this approach over simply > negotiating tunnel mode IPsec with wild-card selectors (i.e. 0.0.0.0/0) and > then at a higher level using the routing decision to choose which tunnel to > use? Mainly because current IP routing daemons already work over IPIP tunnels, while you'd have to re-implement them at that higher level and make them aware of IPsec SAs. IP routing is based on the notion of directly connected interfaces - the problem with some IPsec tunnel mode implementations is that their SAs are not interfaces. > IIPtran may appear to retain more vestiges of IPsec policy (i.e. the policy > being to apply transport mode IPsec to all traffic between the tunnel end > points) but I believe this is illusory as in fact the same packets get the > same IPsec treatment with IIPtran as with the wild-card selectors approach. > In the final analysis, both approaches make the entire decision based only > on the overlay forwarding table. As Joe said, IIPtran allows current protocols to work on overlays without modifications. Of course you can reimplement them all to be aware of IPsec SAs, but why would you? > I get a hint from reading the draft that the proposal may be motivated by > an implementation environment where there is already a platform with an IP > stack and IPsec embedded in it, and it is desired not to change the IPsec > implementation or its relationship to the rest of the IP stack. Is that > the reason for this choice of approaches? We are mostly based on KAME right now, which IMO is an excellent implementation of the IPsec specs, including tunnel mode. We're not hacking around a broken stack; we really believe that IIPtran is the right thing to do :-) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms040108070609040900070201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwMzE3NDkwNlowIwYJKoZIhvcNAQkEMRYEFPdWeAHSWNoP47XlK7KgQAGRHeAIMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYBGzteG3yp/Dg726ZsymD4EqyK/aBZSb43F+31JviIyfBXnCUBB8E5OvZZkgdkGmPUi QvoHyyOHwzM5PYsWGwvaXQZ53MCbQxQvTnsrlWCtQRnQa1aTHmfJo4F/5AOvsUtLW++YQZ51 hPKKgG0W1nfRT0d7AZ6DTcJELbHPDc3dIAAAAAAAAA== --------------ms040108070609040900070201-- From owner-ipsec@lists.tislabs.com Wed Apr 3 10:42:56 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 g33Igum05221; Wed, 3 Apr 2002 10:42:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16309 Wed, 3 Apr 2002 13:03:08 -0500 (EST) Message-Id: <200204031734.MAA27006@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Michael Thomas , Jari Arkko Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Date: Wed, 3 Apr 2002 12:30:41 -0500 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com, marcovici@lucent.com, Black_David@emc.com References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <3CAB122B.8000505@kolumbus.fi> <15531.10727.959342.461589@thomasm-u1.cisco.com> In-Reply-To: <15531.10727.959342.461589@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA15956 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday 03 April 2002 11:12, Michael Thomas wrote: > I honestly don't see why MIP needs to go beyond > saying "use IPsec, beware manual keys". Because nobody really WANTS to use manual keys? And because while IKEv1 is a hog (and no real negotiation seems necessary), something VERY light-weight is needed? >That is, so long as there is a viable way of keying IPsec > which enables replay protection -- and there is -- > MIP doesn't need to be any more specific *how* to > do that. Don't you think there might be interoperability issues if the exact way of keying IPsec is omitted? Also, creating SA is *more* than just keying. > If people want a lighter weight option than either IKE, JFK, KINK > etc, than that is a IPsec WG problem. But MIP, IMO, doesn't need to > boil the ocean here. If it's an interesting problem to solve for MIP, > it's an equally interesting problem to solve for a whole slew of > other protocols which might be protected by IPsec. > That is, generality good, one-off bad. The description of the problem to solve seemed to be: 1. IPsec is preferred as protection mechanism, but 2. SA is established via IKEv1 and people don't want to pay this price. 3. So a lightweight "compact" protocol for establishing SA is needed, 4. but it must be defined as two peers must know how to negotiate. A possible solution (as I see it) could be: 1. "Negotiate on paper" - i.e. define most if not all the attributes of SA that should satisfy usage criteriae (including the crypto suite). 2. Select a simple key agreement protocol (any Bellare-Rogaway derivative should do nicely) - such as *interlocked* CHAP or AKA. 3. Specify all of the above in a generic draft. Those who can live with SA attributes specified in (1) can use this simple protocol and save on code and time. Those who must use full power of IKE will either take IKEv1, or wait till IKEv2 (hopefully soon). > In any case, my larger point here is that a > mandatory mechanism for MIP which requires per > node consumption of NVRAM on a Home Agent as a > MUST IMPLEMENT, where IKE, JFK, KINK, etc don't > place any such requirements on IPsec seems > onerous, and should be optional. Ideally, it > would be one of a set of acceptible choices. The above doesn't make sense, because you *have* to have something in NVRAM regardless. The question is - exactly what. And a simplified approach allows you to "memorize" less than IKE or JFK would require. > Jari Arkko writes: > > Uri Blumenthal wrote: > > > On Tuesday 02 April 2002 20:08, Michael Thomas wrote: > > > > If people want a "light weight" keying scheme for > > > > IPsec, it should either be pursued in IPsec WG, or > > > > through a BOF......As I've mentioned, there are some > > > > of our folks who have some interest in this, and > > > > their scheme doesn't require per node storage of > > > > anything but the key and something akin to the > > > > EngineBoots counter in SNMPv3. This would be a > > > > much better solution to this problem. > > > > > > Actually, this is interesting - because indeed there are > > > applications and protocols that want to use IPsec for > > > protection, but don't want to use IKE for key negotiation. > > > > This is true, but from the point of view of Mobile IPv6, we didn't > > really want to enter the discussion of key management protocols. > > (I'm personally sure that Son-of-IKE will solve many of the > > problems IKE has, though I haven't checked lately to verify this.) > > > > Instead, what the Mobile IPv6 folks wanted to do was to use IPsec > > as-is for certain tasks. One of these tasks was protection of BUs > > between the MN and the CN. Now, our options in regards to this are > > as follows: > > > > 1. Require IPsec + IKE. No replay problem. > > 2. Require at least IPsec, but keep IKE as optional. Don't add > > any features for replay protection. Folks who don't use IKE > > will suffer from the replay vulnerability. > > 3. Require at least IPsec, optional IKE but add an application > > layer feature for replay protection to prevent replays if > > you happened to not have IKE. This was the DT-recommended > > approach. > > 4. Require at least IPSec and a TBD light weight key management > > scheme, perhaps optional IKE in some cases. No application > > layer features. Replay protection works perfectly for > > everyone. > > > > Somehow I think that if we are targeting RFC in about a month or > > so option #4 isn't going to give us that. However, this discussion > > has caused me to rethink some of the reasons on why we recommended > > option #3. Option #2 might also be quite reasonable, and would > > have the added benefit that whatever the IETF keeps generating on > > the key management front could easily be adopted whenever it > > becomes available. KINK could be used in environments where it is > > available, for instance, and Son-of-IKE when it gets ready. OTOH, > > the application layer replay protection has* been in the mobile > > ipv6 drafts from the stone age so I don't think that it's such a > > bad idea either. > > > > Comments? > > > > Jari > > *) We have been discussing a modification of the replay protection > > on the list, to require NV memory to be used or not. -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Wed Apr 3 10:52:26 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 g33IqQm05504; Wed, 3 Apr 2002 10:52:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16380 Wed, 3 Apr 2002 13:06:43 -0500 (EST) Message-ID: <3CAB39E1.7090902@kolumbus.fi> Date: Wed, 03 Apr 2002 20:20:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: uri@bell-labs.com Cc: Michael Thomas , ipsec@lists.tislabs.com, marcovici@lucent.com, Black_David@emc.com Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <3CAB122B.8000505@kolumbus.fi> <15531.10727.959342.461589@thomasm-u1.cisco.com> <200204031734.MAA27006@nwmail.wh.lucent.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The description of the problem to solve seemed to be: > > 1. IPsec is preferred as protection mechanism, but > 2. SA is established via IKEv1 and people don't want to pay this price. > 3. So a lightweight "compact" protocol for establishing SA is needed, > 4. but it must be defined as two peers must know how to negotiate. Uri, I'm not sure this was exactly the problem description. I'm sure lots of people are willing to pay the price. The problem was more about whether those folks who use manual keying would (a) be vulnerable to replay attacks or (b) the existing application layer sequence# would be used to protect also against this, even across reboots. While the subject of new key management protocols is very interesting and even some new work might be useful there, I'm not sure the MIPv6 case is the right application. There, we'd much rather use whatever the mainstream internet key management protocol happens to be at any specific time. I also think it is realistic to assume some folks will be using manual keys, and could potentially expose themselves to replay attacks. But that's fine as long those folks have been warned about it. Jari From owner-ipsec@lists.tislabs.com Wed Apr 3 12:20: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 g33KKcm12187; Wed, 3 Apr 2002 12:20:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16796 Wed, 3 Apr 2002 14:26:52 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Is TS agreement necessary? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 3 Apr 2002 11:35:16 -0800 Message-ID: Thread-Topic: Is TS agreement necessary? Thread-Index: AcHbPxeXaRShNzziTfq1lhtLtKd92wABnttg From: "Rajesh Mohan" To: "Scott G. Kelly" , "Mike Ditto" Cc: X-OriginalArrivalTime: 03 Apr 2002 19:35:16.0991 (UTC) FILETIME=[AECC68F0:01C1DB46] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA16793 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@SonicWALL.com] > Sent: Wednesday, April 03, 2002 9:33 AM > To: Mike Ditto > Cc: ipsec@lists.tislabs.com > Subject: Re: Is TS agreement necessary? > > > Hi Mike, > > Suppose, as you suggest, that we allowed negotiation of multiple SAs > between two peers without specifying TS values. Ultimately, there must > be *some* policy rule associated with each of these SAs since, as you > suggest, the point is to somehow segregate traffic between them. That > is, for a given SA, some traffic is allowed, and some is not. Please > elaborate upon how we determine which traffic is appropriate > for each SA > once they are established. In my case, on the sender side, I would decide on a tunnel based on VLAN ID or the port from which the packet was received. The selectors in IPSec makes it less flexible for applications like these. > > As an aside, can you tell us why wildcard TS values do not > satisfy your > requirements in the same way that omitting TS values would? > 0.0.0.0/0 is used to mean "allow tunnel traffic only". Something like "allow all traffic from tunnel" will be useful. A tunnel without selectors can be used for that. > Thanks, > > Scott > > Mike Ditto wrote: > > > > Hypothesis: If we were satisfied to let all traffic of equivalent > > security characteristics (identities, transforms, etc.) > share a single > > SA (or to be distributed arbitrarily among multiple > equivalent SAs), we > > wouldn't need any traffic selector agreement (or > negotiation, whatever) > > protocol. TS payloads tell the other end how you want your traffic > > segregated between multiple equivalent SAs, and when it > must negotiate a > > new SA even though there already exists one with the right > parameters. > > > > In case I'm not being clear with terminology, by "traffic > segregation" I > > mean segregation of traffic from multiple sources (i.e. users) but > > equivalent IPsec security parameters into different SAs to protect > > mutually distrusting users against known-plaintext or DoS > attacks from > > other users of the same secure tunnel. > > > > Eliminating TS agreement would solve the dynamic ports problem and > > eliminate my other complaint about IKE, already much too verbosely > > discussed recently here. But then, how to solve the > traffic segregation > > problem? > > > > What if this kind of traffic segregation was performed at > the sender's > > discretion? I.e. each end independently decides how to > segregate the > > traffic it sends, and accepts the other end's choice as > long as it meets > > the general security parameters required by the policy. During SA > > establishment, the initiator specifies in an abstract way > the degree of > > sharing to apply to each proposed SA (pair). I see three levels of > > sharing being important: completely shared, unique address, > and unique > > session. Unique address means that once the SA (pair) has > been used to > > talk to a particular remote address, it can't be used for > sending to any > > other remote address. Unique session means the analogous thing with > > session, where "session" is defined by the implementation. A > > recommended model for defining "session" would be based on > the TCP/UDP > > 5-tuple, but implementations would be allowed to vary to > some degree. > > > > This way, if my implementation considers the control > connection and the > > data connections of an FTP session to be one "session", and > the other > > end considers those to be multiple distinct "sessions", > there is still > > interoperability. > > > > It might be a good idea even to allow simple IPsec implementations > > (e.g. for embedded use) not to implement traffic > segregation, falling > > back to "completely shared" SAs, in a transparently > interoperable way. > > > > Two questions: > > > > Does this meet the requirements of those who strongly believe in the > > importance of this kind of traffic segregation? I'm not > such a strong > > believer; most of the scenarios I've heard where it's > relevant seem to > > have nearly identical weaknesses with and without traffic > segregation, > > or are better handled by assigning unique identities to the unique > > users. But I'll take others' word that it's an important > capability, > > and ask such people whether this proposal is sufficient. > > > > Is this idea actually simpler than the workable > alternatives? I haven't > > seen a concrete proposal for extending TS to handle dynamic > ports, so I > > can't offer an opinion on that alternative yet. > > > > -=] Mike [=- > From owner-ipsec@lists.tislabs.com Wed Apr 3 12:26: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 g33KQXm12344; Wed, 3 Apr 2002 12:26:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16902 Wed, 3 Apr 2002 14:42:49 -0500 (EST) Message-ID: <3CAB5E42.983D3E43@sonicwall.com> Date: Wed, 03 Apr 2002 11:55:46 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rajesh Mohan CC: Mike Ditto , ipsec@lists.tislabs.com Subject: Re: Is TS agreement necessary? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2002 19:55:29.0441 (UTC) FILETIME=[81799910:01C1DB49] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Rajesh, Rajesh Mohan wrote: > > Suppose, as you suggest, that we allowed negotiation of multiple SAs > > between two peers without specifying TS values. Ultimately, there must > > be *some* policy rule associated with each of these SAs since, as you > > suggest, the point is to somehow segregate traffic between them. That > > is, for a given SA, some traffic is allowed, and some is not. Please > > elaborate upon how we determine which traffic is appropriate > > for each SA > > once they are established. > > In my case, on the sender side, I would decide on a tunnel based on VLAN ID > or the port from which the packet was received. The selectors in IPSec makes > it less flexible for applications like these. A VLAN ID is typically a layer-2 construct, which may explain why it is difficult to use it as a selector for layer-3 security mechanism. Assuming this ID is not contained in the IP packet which traverses the tunnel, the remote gateway has no way to verify that such a packet matches his local policy. Do you think this is not important? > > As an aside, can you tell us why wildcard TS values do not > > satisfy your > > requirements in the same way that omitting TS values would? > > > > 0.0.0.0/0 is used to mean "allow tunnel traffic only". Something like > "allow all traffic from tunnel" will be useful. A tunnel without selectors > can be used for that. Maybe I'm misunderstanding. What is the distinction between these two cases? I would interpret the 0.0.0.0/0 selector to mean "permit any/all traffic in this tunnel". By "allow all traffic from tunnel", do you mean to imply that you'd like to reference a particular tunnel in some other policy rule? Thanks, Scott From owner-ipsec@lists.tislabs.com Wed Apr 3 12:43: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 g33KhBm12961; Wed, 3 Apr 2002 12:43:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17032 Wed, 3 Apr 2002 15:04:12 -0500 (EST) Message-Id: <200204032014.g33KERss018524@thunk.east.sun.com> From: Bill Sommerfeld To: "Rajesh Mohan" cc: "Scott G. Kelly" , "Mike Ditto" , ipsec@lists.tislabs.com Subject: Re: Is TS agreement necessary? In-Reply-To: Your message of "Wed, 03 Apr 2002 11:35:16 PST." Reply-to: sommerfeld@east.sun.com Date: Wed, 03 Apr 2002 15:14:27 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In my case, on the sender side, I would decide on a tunnel based on > VLAN ID or the port from which the packet was received. The > selectors in IPSec makes it less flexible for applications like > these. So, that sounds like it's accomodated by "different SPD per inbound interface", which is what 2401 tells you to do.. - Bill From owner-ipsec@lists.tislabs.com Wed Apr 3 13:03: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 g33L3Xm13521; Wed, 3 Apr 2002 13:03:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17171 Wed, 3 Apr 2002 15:24:11 -0500 (EST) Date: Wed, 3 Apr 2002 12:01:05 -0800 (PST) Message-Id: <200204032001.MAA09886@potomac.incog.com> From: Mike Ditto To: skelly@SonicWALL.com CC: ipsec@lists.tislabs.com In-reply-to: <3CAB3CCE.68852E3C@sonicwall.com> (skelly@SonicWALL.com) Subject: Re: Is TS agreement necessary? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" wrote: > Suppose, as you suggest, that we allowed negotiation of multiple SAs > between two peers without specifying TS values. Ultimately, there must > be *some* policy rule associated with each of these SAs since, as you > suggest, the point is to somehow segregate traffic between them. That > is, for a given SA, some traffic is allowed, and some is not. Please > elaborate upon how we determine which traffic is appropriate for each SA > once they are established. OK. At the time of sending a packet, the SA lookup would work basically the same as it does currently; the SPD and SAD would determine which SA is used. I'm not proposing removing selectors from the SAD, I'm just proposing that the selectors aren't sent explicitly in SA establishment. When I initiate SA negotiation, I get to decide what goes in the selectors on my end, just like current IKE implementations. What's different is how the selectors are set up for SAs that were requested by my peer. When my peer asks me to add an SA pair to my SAD, I mark the SAs as "completely shared", "address unique" or "session unique" as my peer requests. If it's "completely shared" then I add a completely wildcarded selector to the outbound SA. If it's one of the "unique" styles, I don't add any selectors and I will never use the outbound SA until the peer has sent me some traffic on the inbound one. Whenever I receive traffic on an inbound SA I add the corresponding selectors to the matching outbound SA. If the SA (pair) is "address unique" I add to the outbound SA a destination address selector using the packet's (inner) source address. If the SA (pair) is "session unique" then I add to the outbound SA a selector that describes my concept of a session for that protocol (the easiest definition of session for RFC2401-style implementations would be to use port numbers). But the ends don't have to agree on the exact definition of a session. An implementation is still able to use selectors on inbound SAs to efficiently validate inbound traffic. When an inbound packet doesn't match the inbound SA's selectors, the SPD is checked and if the packet is allowed, the appropriate selectors are added to the inbound and outbound SAs. The core idea of this proposal, the thing that makes interoperability possible without agreement on the definition of a session, is that the sender of each packet is free to choose between multiple equivalent SAs however it sees convenient to implement, and the receiver accepts the decision as long as the chosen SA matches the security parameters. When establishing SAs, the initiator gives an abstract hint to the responder about the desired granularity of segregation. > As an aside, can you tell us why wildcard TS values do not satisfy your > requirements in the same way that omitting TS values would? I think wildcard TS values would satisfy my requirements if I was allowed to ignore any non-wildcard selectors sent to me, and if I didn't want to implement traffic segregation. -=] Mike [=- From owner-ipsec@lists.tislabs.com Wed Apr 3 13:04: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 g33L4im13567; Wed, 3 Apr 2002 13:04:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17172 Wed, 3 Apr 2002 15:24:12 -0500 (EST) From: "Casey Carr" To: Cc: "IPSec Policy WG" Subject: FW: Dead peer detection Date: Wed, 3 Apr 2002 15:21:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry. I sent this to the IPSec Policy WG the first time by mistake. I think it more appropriate in the general IPSec WG. -----Original Message----- From: Casey Carr [mailto:caseyc@cipheroptics.com] Sent: Wednesday, April 03, 2002 2:24 PM To: IPSec Policy WG Subject: Dead peer detection Is there an RFC or draft on standards track to deal with dead peer detection? After spending some time reviewing the IPSec, IKE, ISAKMP RFCs I have drawn the conclusion that there is not a "standard" way to implement dead peer detection. Have I reached a valid conclusion? Are other IPSec vendors implementing proprietary solutions? If so, have there been interoperability issues? I reviewed draft-ietf-ipsec-dpd-00.txt. It appears to be a year old without revisions which leads me to believe that it may not be widely accepted. It also appears from a statement in JFK that the authors regard this as an implementation issue: "A second major reason for Phase II is dead peer detection. IPsec gateways often need to know if the other end of a security association is dead, both to free up resources and to avoid "black holes". In JFK, this is done by noting the time of the last packet received. A peer that wishes to elicit a packet may send a "ping". Such hosts MAY decline any proposed security associations that do not permit such "ping" packets." Thanks, Casey From owner-ipsec@lists.tislabs.com Wed Apr 3 14:21: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 g33MLTm17625; Wed, 3 Apr 2002 14:21:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17619 Wed, 3 Apr 2002 16:39:42 -0500 (EST) From: "Stephane Beaulieu" To: "Casey Carr" , Subject: RE: Dead peer detection Date: Wed, 3 Apr 2002 16:51:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Casey, There are 3 or 4 different ways of doing Dead Peer Detection that I am aware of. Cisco has an older method reffered to as Keepalives in our older releases of IOS, VPN3000, and PIX. It is undocumented (to the public) though I believe some of our partners have also implemented it. All of our newer releases support the DPD draft you referenced, and we are going to slowly deprecate keepalives. We published DPD in the IPsec WG in hopes to get it standardized. However, there hasn't been much interest which is why the draft has been idle. I think the WG chairs also decided that DPD was outside the scope of the WG because of the moratorium. I sent an email to Ted a few weeks ago asking whether we could try to go standards-track with it or if we should just go out as Informational. I'm still waiting for a response. I know that Nortel also has some scheme which addresses the same issues, though they apparently have a patent on it. I'm sure there are other proprietary versions which are probably all very simliar except for the bits on the wire. Hope this helps, Stephane. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Casey Carr > Sent: Wednesday, April 03, 2002 3:22 PM > To: ipsec@lists.tislabs.com > Cc: IPSec Policy WG > Subject: FW: Dead peer detection > > > Sorry. I sent this to the IPSec Policy WG the first time by mistake. > > I think it more appropriate in the general IPSec WG. > > -----Original Message----- > From: Casey Carr [mailto:caseyc@cipheroptics.com] > Sent: Wednesday, April 03, 2002 2:24 PM > To: IPSec Policy WG > Subject: Dead peer detection > > > Is there an RFC or draft on standards track to deal with dead peer > detection? After spending some time reviewing the IPSec, IKE, > ISAKMP RFCs I > have drawn the conclusion that there is not a "standard" way to implement > dead peer detection. Have I reached a valid conclusion? Are other IPSec > vendors implementing proprietary solutions? If so, have there been > interoperability issues? > > I reviewed draft-ietf-ipsec-dpd-00.txt. It appears to be a year > old without > revisions which leads me to believe that it may not be widely accepted. > > It also appears from a statement in JFK that the authors regard > this as an > implementation issue: > > "A second major reason for Phase II is dead peer detection. IPsec > gateways often need to know if the other end of a security association > is dead, both to free up resources and to avoid "black holes". > In JFK, this is done by noting the time of the last packet received. > A peer that wishes to elicit a packet may send a "ping". Such > hosts MAY decline any proposed security associations that do not > permit such "ping" packets." > > > Thanks, > Casey > From owner-ipsec@lists.tislabs.com Wed Apr 3 14:22: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 g33MMgm17661; Wed, 3 Apr 2002 14:22:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17656 Wed, 3 Apr 2002 16:42:07 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Is TS agreement necessary? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 3 Apr 2002 13:50:34 -0800 Message-ID: Thread-Topic: Is TS agreement necessary? Thread-Index: AcHbSiOl78hAh9zpS3aqYp8KbJUpdAAAS8zg From: "Rajesh Mohan" To: "Scott G. Kelly" Cc: "Mike Ditto" , X-OriginalArrivalTime: 03 Apr 2002 21:50:34.0552 (UTC) FILETIME=[953DEB80:01C1DB59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA17653 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@sonicwall.com] > Sent: Wednesday, April 03, 2002 11:56 AM > To: Rajesh Mohan > Cc: Mike Ditto; ipsec@lists.tislabs.com > Subject: Re: Is TS agreement necessary? > > > Hi Rajesh, > > Rajesh Mohan wrote: > > > > > Suppose, as you suggest, that we allowed negotiation of > multiple SAs > > > between two peers without specifying TS values. > Ultimately, there must > > > be *some* policy rule associated with each of these SAs > since, as you > > > suggest, the point is to somehow segregate traffic > between them. That > > > is, for a given SA, some traffic is allowed, and some is > not. Please > > > elaborate upon how we determine which traffic is appropriate > > > for each SA > > > once they are established. > > > > In my case, on the sender side, I would decide on a tunnel > based on VLAN ID > > or the port from which the packet was received. The > selectors in IPSec makes > > it less flexible for applications like these. > > A VLAN ID is typically a layer-2 construct, which may explain > why it is > difficult to use it as a selector for layer-3 security mechanism. > Assuming this ID is not contained in the IP packet which traverses the > tunnel, the remote gateway has no way to verify that such a packet > matches his local policy. Do you think this is not important? > I am sure it is important in most cases. But in cases where you trust the peer, (like between branch offices), it should be good enough if the packet is authenticated. Am I compromising security here? > > > As an aside, can you tell us why wildcard TS values do not > > > satisfy your > > > requirements in the same way that omitting TS values would? > > > > > > > 0.0.0.0/0 is used to mean "allow tunnel traffic only". > Something like > > "allow all traffic from tunnel" will be useful. A tunnel > without selectors > > can be used for that. > > Maybe I'm misunderstanding. What is the distinction between these two > cases? I would interpret the 0.0.0.0/0 selector to mean > "permit any/all > traffic in this tunnel". By "allow all traffic from tunnel", > do you mean > to imply that you'd like to reference a particular tunnel in > some other > policy rule? > Maybe it a implementation issue. Excuse me if I misinterpreted the RFC completely. When a packet comes through a tunnel, then there is no issue with 0.0.0.0/0. However, for a packet coming in clear, we will first check if it is part of some VPN. If it is, then we have to drop the packet. If I have 0.0.0.0/0 for this tunnel, then all traffic will match it which means we will not allow clear traffic at all. Thanks -Rajesh M > Thanks, > > Scott > From owner-ipsec@lists.tislabs.com Wed Apr 3 14:23: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 g33MNDm17682; Wed, 3 Apr 2002 14:23:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17698 Wed, 3 Apr 2002 16:47:00 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200204022336.PAA09543@potomac.incog.com> References: <200204022336.PAA09543@potomac.incog.com> Date: Wed, 3 Apr 2002 16:59:50 -0500 To: Mike Ditto From: Stephen Kent Subject: Re: Is TS agreement necessary? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, > >What if this kind of traffic segregation was performed at the sender's >discretion? I.e. each end independently decides how to segregate the >traffic it sends, and accepts the other end's choice as long as it meets >the general security parameters required by the policy. During SA >establishment, the initiator specifies in an abstract way the degree of >sharing to apply to each proposed SA (pair). I see three levels of >sharing being important: completely shared, unique address, and unique >session. Unique address means that once the SA (pair) has been used to >talk to a particular remote address, it can't be used for sending to any >other remote address. Unique session means the analogous thing with >session, where "session" is defined by the implementation. A >recommended model for defining "session" would be based on the TCP/UDP >5-tuple, but implementations would be allowed to vary to some degree. we have adopted the selector mechanism, in part, to allow sites to make the decision of what granularity of traffic muxing on an SA is acceptable. this proposal takes away that capability and tries to substitute three options. It is not clear that this reduced flexibility will meet all requirements now and going forward. Also, the suggestion that "session" would be an implementation defined concept could pose serious interoperability problems, and it leaves prospective users wondering what will happen when their implementation interacts with another. >This way, if my implementation considers the control connection and the >data connections of an FTP session to be one "session", and the other >end considers those to be multiple distinct "sessions", there is still >interoperability. How? if the other end wants them to be separate sessions, won't it reject data traffic you send over the SA that was established first for control traffic? >It might be a good idea even to allow simple IPsec implementations >(e.g. for embedded use) not to implement traffic segregation, falling >back to "completely shared" SAs, in a transparently interoperable way. It's always easy to imagine limited functionality implementations of a protocol for restrictive environments that might otherwise have some difficulty implementing the full set of required functions for the protocol. 20 years ago we saw that in LANs, where some folks decided that computing the TCP checkusm was a waste of time for traffic that was local to their LAN. Adoption of standards always implies compromises; a standard is rarely the optimal way to implement a set of functions for the full range of environments in which it may be employed. >Two questions: > >Does this meet the requirements of those who strongly believe in the >importance of this kind of traffic segregation? I'm not such a strong >believer; most of the scenarios I've heard where it's relevant seem to >have nearly identical weaknesses with and without traffic segregation, >or are better handled by assigning unique identities to the unique >users. But I'll take others' word that it's an important capability, >and ask such people whether this proposal is sufficient. In short, no. >Is this idea actually simpler than the workable alternatives? I haven't >seen a concrete proposal for extending TS to handle dynamic ports, so I >can't offer an opinion on that alternative yet. As you noted, we need to have concrete proposals on the table for other options. I would not be surprised to see the alternatives be more complex, but if the result is also less ambiguous than what I understand from above, the comparison is inappropriate anyway. Steve From owner-ipsec@lists.tislabs.com Wed Apr 3 14:34: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 g33MY6m17947; Wed, 3 Apr 2002 14:34:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17741 Wed, 3 Apr 2002 16:56:23 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Is TS agreement necessary? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 3 Apr 2002 14:04:50 -0800 Message-ID: Thread-Topic: Is TS agreement necessary? Thread-Index: AcHbVSEIaeF2nDwvRnGKiYp7hINoxAABKC8w From: "Rajesh Mohan" To: Cc: "Scott G. Kelly" , "Mike Ditto" , X-OriginalArrivalTime: 03 Apr 2002 22:04:50.0879 (UTC) FILETIME=[93A70CF0:01C1DB5B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA17738 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Bill, > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Wednesday, April 03, 2002 12:14 PM > To: Rajesh Mohan > Cc: Scott G. Kelly; Mike Ditto; ipsec@lists.tislabs.com > Subject: Re: Is TS agreement necessary? > > > > In my case, on the sender side, I would decide on a tunnel based on > > VLAN ID or the port from which the packet was received. The > > selectors in IPSec makes it less flexible for applications like > > these. > > So, that sounds like it's accomodated by "different SPD per inbound > interface", which is what 2401 tells you to do.. > I guess I missed this out. But still, I think having selectors in IPSec is not required in some cases. Let me try to justify it using another example. Say, we have this special box made to be used in data centers. We have regular IPSec complaint box in corporate network. It will be convenient for the administrator at data center to tunnel all traffic of a particular VLAN to the corporate network. He does not care what network is at the remote end. On the other end, the corporate administrator has well defined selectors for the tunnel to the cage. In this unsymmetric setup, having no selectors at IPSec (and a way to negotiate this in IKEv2) is useful. Thanks, -Rajesh M > - Bill > From owner-ipsec@lists.tislabs.com Wed Apr 3 15:01: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 g33N16m18731; Wed, 3 Apr 2002 15:01:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17951 Wed, 3 Apr 2002 17:24:42 -0500 (EST) Message-Id: <200204032234.g33MYAW01612@fatty.lounge.org> To: Mike Ditto Cc: skelly@SonicWALL.com, ipsec@lists.tislabs.com Subject: Re: Is TS agreement necessary? In-Reply-To: Your message of "Wed, 03 Apr 2002 12:01:05 PST." <200204032001.MAA09886@potomac.incog.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1609.1017873250.1@tibernian.com> Date: Wed, 03 Apr 2002 14:34:10 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 03 Apr 2002 12:01:05 PST you wrote > > OK. At the time of sending a packet, the SA lookup would work basically > the same as it does currently; the SPD and SAD would determine which SA > is used. I'm not proposing removing selectors from the SAD, I'm just > proposing that the selectors aren't sent explicitly in SA establishment. > > When I initiate SA negotiation, I get to decide what goes in the > selectors on my end, just like current IKE implementations. What's > different is how the selectors are set up for SAs that were requested by > my peer. When my peer asks me to add an SA pair to my SAD, I mark the > SAs as "completely shared", "address unique" or "session unique" as my > peer requests. The peer requests some "shared" or "unique" -ness to be assigned to the SA during SA establishment time? How is that to be done exactly and why is that any better than a TS payload? And what is a "session" if it doesn't involve ports and protocols? > When establishing SAs, the initiator gives an abstract hint to the responder > about the desired granularity of segregation. You're proposing to replace a specific indication with an abstract hint. It looks like there's lots of room for interpretation and disinteroperability in this. That sounds worse than what we have today with IKEv1 and much, much worse than what is proposed with the TS payload. Dan. From owner-ipsec@lists.tislabs.com Wed Apr 3 16:31:24 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 g340VNm21175; Wed, 3 Apr 2002 16:31:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18529 Wed, 3 Apr 2002 18:53:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Dead peer detection Date: Wed, 3 Apr 2002 16:06:13 -0800 Message-ID: <7B8824D690092B4B90B0EF4674750A65022DF5C2@USEXCH3.us.sonicwall.com> Thread-Topic: Dead peer detection Thread-Index: AcHbXKPZlmBVI1iqRHCNjChKYuv1XgADMcfQ From: "Ricky Charlet" To: "'Stephane Beaulieu'" , "Casey Carr" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA18526 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, Hey, I was interested! Very early on I asked the draft authors about their intentions and they told me to not implement the -00 draft because they envisioned significant change. So I waited. (and waited...). If we implemented the -00 draft, would we interoperate with you? Any VPN vendor will run across the customer driven request for tunnel-black-hole-detection and possibly for supporting alternative tunnels to backup gateways. Dead peer detection (of some sort) is a fundamental requirement for these. Yet End-to-End IPsec'ers see any DPD mechanism as dangerous overhead and unnecessary complexity. Even among folks who want a standardized DPD mechanism, disagreements over the driving requirements (should it support site-to-site tunnels, should it support remote access without interfering with accounting or PPP link keep alive, other reasonable use cases may be envisioned) lead to opposing suggestions for its implementation (in IKE, in ESP/AH, in the clear). I believe that of the people who are actually deploying home grown solutions for DPD, this draft-ietf-ipsec-dpd-00.txt (with its implementation in authenticated IKE exchanges) solves their problem set. It solves our problem set. Also on the horizon it IKEv2 which has a DPD mechanism proposed within it (thanks Kaufman and IKEv2 team). -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : rcharlet@sonciwall.com : usa (408) 962-8711 > -----Original Message----- > From: Stephane Beaulieu [mailto:stephane@cisco.com] > Sent: Wednesday, April 03, 2002 1:51 PM > To: Casey Carr; ipsec@lists.tislabs.com > Subject: RE: Dead peer detection > > > Hi Casey, > > There are 3 or 4 different ways of doing Dead Peer Detection > that I am aware > of. Cisco has an older method reffered to as Keepalives in our older > releases of IOS, VPN3000, and PIX. It is undocumented (to the public) > though I believe some of our partners have also implemented it. > > All of our newer releases support the DPD draft you > referenced, and we are > going to slowly deprecate keepalives. We published DPD in > the IPsec WG in > hopes to get it standardized. However, there hasn't been > much interest > which is why the draft has been idle. I think the WG chairs > also decided > that DPD was outside the scope of the WG because of the > moratorium. I sent > an email to Ted a few weeks ago asking whether we could try to go > standards-track with it or if we should just go out as > Informational. I'm > still waiting for a response. > > I know that Nortel also has some scheme which addresses the > same issues, > though they apparently have a patent on it. > > I'm sure there are other proprietary versions which are > probably all very > simliar except for the bits on the wire. > > Hope this helps, > Stephane. > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Casey Carr > > Sent: Wednesday, April 03, 2002 3:22 PM > > To: ipsec@lists.tislabs.com > > Cc: IPSec Policy WG > > Subject: FW: Dead peer detection > > > > > > Sorry. I sent this to the IPSec Policy WG the first time > by mistake. > > > > I think it more appropriate in the general IPSec WG. > > > > -----Original Message----- > > From: Casey Carr [mailto:caseyc@cipheroptics.com] > > Sent: Wednesday, April 03, 2002 2:24 PM > > To: IPSec Policy WG > > Subject: Dead peer detection > > > > > > Is there an RFC or draft on standards track to deal with dead peer > > detection? After spending some time reviewing the IPSec, IKE, > > ISAKMP RFCs I > > have drawn the conclusion that there is not a "standard" > way to implement > > dead peer detection. Have I reached a valid conclusion? > Are other IPSec > > vendors implementing proprietary solutions? If so, have there been > > interoperability issues? > > > > I reviewed draft-ietf-ipsec-dpd-00.txt. It appears to be a year > > old without > > revisions which leads me to believe that it may not be > widely accepted. > > > > It also appears from a statement in JFK that the authors regard > > this as an > > implementation issue: > > > > "A second major reason for Phase II is dead peer detection. IPsec > > gateways often need to know if the other end of a > security association > > is dead, both to free up resources and to avoid "black holes". > > In JFK, this is done by noting the time of the last > packet received. > > A peer that wishes to elicit a packet may send a "ping". Such > > hosts MAY decline any proposed security associations that do not > > permit such "ping" packets." > > > > > > Thanks, > > Casey > > > > From owner-ipsec@lists.tislabs.com Wed Apr 3 16:32: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 g340W1m21196; Wed, 3 Apr 2002 16:32:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18551 Wed, 3 Apr 2002 18:56:09 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200204032234.OAA09939@potomac.incog.com> References: <200204032234.OAA09939@potomac.incog.com> Date: Wed, 3 Apr 2002 19:06:12 -0500 To: Mike Ditto From: Stephen Kent Subject: Re: Is TS agreement necessary? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:34 PM -0800 4/3/02, Mike Ditto wrote: >Stephen Kent wrote: >> we have adopted the selector mechanism, in part, to allow sites to >> make the decision of what granularity of traffic muxing on an SA is >> acceptable. this proposal takes away that capability and tries to >> substitute three options. It is not clear that this reduced >> flexibility will meet all requirements now and going forward. Also, > >I agree. But it's clear that the present model doesn't meet all >requirements now and going forward, as demonstrated by the need to >make significant changes to IPsec for a new transport protocol. I >think it's a serious design flaw that IPsec standards and >implementations have to be changed to accomodate a new transport >protocol. My proposal would eliminate that dependency. Which new transport protocol are you talking about? We're making a number of changes to IPsec based on experience and on new requirements. For example, the new ESP version allows for bigger sequence numbers (to accommodate faster interfaces), support for combined crypto modes, and facilities for better traffic flow confidentiality. The replacement for IKE will significantly reduce complexity, offer better DoS resistance, etc. If you are referring to changes to representation of traffic selectors in IKE payloads, I should point out that some of these changes are putting back what was in the document that became 2401, but had to be removed just before publication, to accommodate some limitations in the current IKE negotiation capabilities. So, any changes to accommodate dynamic ports, etc., are an important but small part of the overall set of changes we will make to these protocols. > > the suggestion that "session" would be an implementation defined >> concept could pose serious interoperability problems, and it leaves >> prospective users wondering what will happen when their >> implementation interacts with another. > >I don't think so; see below. > >> >This way, if my implementation considers the control connection and the >> >data connections of an FTP session to be one "session", and the other >> >end considers those to be multiple distinct "sessions", there is still >> >interoperability. >> >> How? if the other end wants them to be separate sessions, won't it >> reject data traffic you send over the SA that was established first >> for control traffic? > >No, that's the core of this idea: the receiver trusts the sender to >make segregation decisions. If the peer starts sending you stuff that >your policy allows, but you weren't expecting to arrive on that >particular SA, adjust your expectations to match the sender's choice. >This guarantees interoperability even in the face of very different >implementations and their ideas of service and session. we designed IPsec to not have to trust peers to do the right thing. we adopted a defensive posture consistent with the security principle of least privilege. I'm not sure how to interpret your comments relative to this well known security principle. >Suppose my implementation supports a new transport protocol which is, >say layered on top of UDP port 12345, and I want to segregate my >different sessions within that protocol on different SAs. It would be >nice if I could do that without changing IPsec and IKE and waiting for >the other end to upgrade its implementation. Of course if the other >end doesn't know about my special protocol, it won't do segregation >beyond what it knows (lumping all of UDP port 12345 together), but it >will interoperate and I can at least segregate my outbound traffic. >And if the other end does know about my new transport protocol >(perhaps it's running my implementation too), the desired behavior is >achieved without having to violate or update the IPsec standards. Whoops, terminology error. UDP is the transport protocol here. What rides above it is an application. I have a hard time interpreting what you are proposing given the combination of terminology errors and what I perceive as persistent vagueness in the examples. > > >It might be a good idea even to allow simple IPsec implementations >> >(e.g. for embedded use) not to implement traffic segregation, falling >> >back to "completely shared" SAs, in a transparently interoperable way. >> >> It's always easy to imagine limited functionality implementations of >> a protocol for restrictive environments that might otherwise have >> some difficulty implementing the full set of required functions for >> the protocol. 20 years ago we saw that in LANs, where some folks >> decided that computing the TCP checkusm was a waste of time for >> traffic that was local to their LAN. Adoption of standards always >> implies compromises; a standard is rarely the optimal way to >> implement a set of functions for the full range of environments in >> which it may be employed. > >Right. That's why I think it's a valuable property of my proposal >that interoperability is maintained without having to negotiate the >use of an optional feature... it just works if one side (or both) >decides to use completely shared SAs. Your descriptions have not yet convinced me, and others, that interoperability is achieved and at no loss of access control granularity. > > >Does this meet the requirements of those who strongly believe in the >> >importance of this kind of traffic segregation? I'm not such a strong >> >believer; most of the scenarios I've heard where it's relevant seem to >> >have nearly identical weaknesses with and without traffic segregation, >> >or are better handled by assigning unique identities to the unique >> >users. But I'll take others' word that it's an important capability, >> >and ask such people whether this proposal is sufficient. >> >> In short, no. > >OK, why? Is it becuase you (as a user/policy administrator) really >don't trust the other end to do as much segregation as you want, and >you want it to be strictly enforced by your end? that's a good starting point for being defensive. > Because there would >be a possibility that the other end's implementation would lump more >things together than you expect? another good reason. > I can understand those complaints, >but to me, some vagueness in the details of traffic segregation is >a small price to pay for increased interoperability, simplicity, and >freedom of implementation choice. Ah, maybe I am beginning to understand your perspective. You want to remove existing access control features which have well defined characteristics and replace them with more abstract facilities. The exact implications of these more abstract facilities are less clear, because they have to remain abstract in order to facilitate the "freedom of implementation choice." This really is not about implementation choices, but about the functions that a user can expect from an IPsec implementation. Within the current IPsec specs, there is freedom for different implementations, but the services provided should be predictable, objectively verifiable, and not open to ambiguous interpretation. I consider those to be hallmarks of a good security protocol specification and in revising 2401, I hope to improve how we communicate the services offered, as well as expanding some of them to better meet the needs of users. Steve From owner-ipsec@lists.tislabs.com Wed Apr 3 16:37: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 g340bRm21313; Wed, 3 Apr 2002 16:37:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18451 Wed, 3 Apr 2002 18:38:57 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15531.38219.373164.292105@thomasm-u1.cisco.com> Date: Wed, 3 Apr 2002 15:50:35 -0800 (PST) To: "Rajesh Mohan" Cc: , "Scott G. Kelly" , "Mike Ditto" , Subject: RE: Is TS agreement necessary? In-Reply-To: References: 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 Rajesh Mohan writes: > Say, we have this special box made to be used in data centers. We have regular IPSec complaint box in corporate network. It will be convenient for the administrator at data center to tunnel all traffic of a particular VLAN to the corporate network. He does not care what network is at the remote end. On the other end, the corporate administrator has well defined selectors for the tunnel to the cage. > > In this unsymmetric setup, having no selectors at IPSec (and a way to negotiate this in IKEv2) is useful. Ok, I'm probably in left field here, but what you seem to be describing is a completely permissive traffic selector, not a lack of one. What's the problem here? Mike From owner-ipsec@lists.tislabs.com Wed Apr 3 17:19:54 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 g341Jrm22599; Wed, 3 Apr 2002 17:19:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18792 Wed, 3 Apr 2002 19:42:05 -0500 (EST) Message-Id: <3.0.5.32.20020403195104.007fde00@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 03 Apr 2002 19:51:04 -0500 To: Lars Eggert From: Mark Duffy Subject: Re: questions on draft-touch-ipsec-vpn Cc: touch@ISI.EDU, ipsec@lists.tislabs.com In-Reply-To: <3CAB4092.1060104@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:49 PM 4/3/02 -0500, Lars Eggert wrote: >Mark Duffy wrote: >... >> The draft describes using IP-in-IP tunnelling and securing the result >with >> transport mode IPsec (IIPtran). Why choose this approach over simply >> negotiating tunnel mode IPsec with wild-card selectors (i.e. >0.0.0.0/0) and >> then at a higher level using the routing decision to choose which >tunnel to >> use? > >Mainly because current IP routing daemons already work over IPIP >tunnels, while you'd have to re-implement them at that higher level and >make them aware of IPsec SAs. IP routing is based on the notion of >directly connected interfaces - the problem with some IPsec tunnel mode >implementations is that their SAs are not interfaces. This consideration seems specific to certain implementation environments, e.g. when building something running as an "application" (term used here in a very loose sense) on top of a "standard OS". In other environments such as certain embedded ones I am familiar with, IPsec tunnels can just as easily be cast as routable interfaces as IPIP tunnels can be (perhaps even easier :-) Mind you, I'm not sure that IIPtran has a downside in such environments (that's what I'm trying to figure out!) I just don't think it has the stated upside for such environments. --Mark From owner-ipsec@lists.tislabs.com Wed Apr 3 17:19:54 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 g341Jrm22600; Wed, 3 Apr 2002 17:19:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18793 Wed, 3 Apr 2002 19:42:06 -0500 (EST) Message-Id: <3.0.5.32.20020403194048.008c8470@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 03 Apr 2002 19:40:48 -0500 To: Joe Touch From: Mark Duffy Subject: Re: questions on draft-touch-ipsec-vpn Cc: larse@ISI.EDU, ipsec@lists.tislabs.com In-Reply-To: <3CAA9D8A.1090500@isi.edu> References: <3.0.5.32.20020402225856.00845d00@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:13 PM 4/2/02 -0800, Joe Touch wrote: >Mark Duffy wrote: >> Hi, I have a few questions for the authors of draft-touch-ipsec-vpn-03.txt. >> >> The draft addresses the use of IPsec to secure the virtual links of an >> overlay network. In this application, the goal is to make forwarding >> decisions based on evaluating the packet destination address against a >> forwarding table, rather than by evaluating a set of packet selectors >> against an SPD. I.e. the policy aspect of IPsec is not desired in this >> application and must somehow be gotten around. >> >> The draft describes using IP-in-IP tunnelling and securing the result with >> transport mode IPsec (IIPtran). Why choose this approach over simply >> negotiating tunnel mode IPsec with wild-card selectors (i.e. 0.0.0.0/0) and >> then at a higher level using the routing decision to choose which tunnel to >> use? > >This was addressed in a presentation in Minneapolis. The counterexample >is when two tunnels, both with wildcard selectors, go out the same >physical interface. In that case, the routing table has insufficient >information to indicate which tunnel to use. > >There are two solutions: > >1. use IIPtran > >2. use a new virtual device for each new IPsec tunnel >i.e., such that the routing table sends packets to that device name I think what you mean by "use a virtual device for each ... tunnel" is that the IPsec tunnel is modeled in the system as a point to point link, onto which the system has an interface, correct? With IIPtran, doesn't the IP-in-IP tunnel have to be modeled in exactly that same way? Maybe I am being thick but I don't see the gain there. In either case I would see motivations following from one other in the same order: a. I want to create a point-point link in the overlay network b. I need an "overlay" interface at both routers of the overlay network. c. I create a tunnel connecting those overlay interfaces Both IIPtran, and tunnel mode IPsec with 0.0.0.0/0 selectors can accomplish this; the latter just seems more direct. (At least, when implementing from certain starting points -- I understand you are working within the constraints of an existing platform/stack.) >These two solutions are equivalent in function, but different in >complexity. #2 implies that all SPDs have either one or more transport >mode SA, or exactly one tunnel mode SA (and no transport mode SAs). This >ends up treating tunnel mode as a special case w.r.t. association with >devices, for an indirect (routing) reason. I don't follow that. I think #2 by definition involves tunnel mode SAs; that is how it is isolating the overlay traffic. Each virtual link would *typically* consist of a single bidirectional SA pair. However, it could conceivably consist of an aggregate of any number of SA pairs, so long as a) they all go to the same overlay next hop, and b) the union of all their selectors is 0.0.0.0/0, i.e. between them all they will admit any packet. In any event, what is the special case with respect to devices you mention? If that refers to casting the tunnel endpoints as IP interfaces of the overlay router, I come back to believing that the same would be required of the IP-in-ip tunnels. --Mark From owner-ipsec@lists.tislabs.com Wed Apr 3 17:25: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 g341Pmm22752; Wed, 3 Apr 2002 17:25:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18886 Wed, 3 Apr 2002 19:50:43 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Is TS agreement necessary? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 3 Apr 2002 16:59:05 -0800 Message-ID: Thread-Topic: Is TS agreement necessary? Thread-Index: AcHbadW2tOyz78PURi2Svq8fe6j+cQAByvnw From: "Rajesh Mohan" To: "Michael Thomas" Cc: X-OriginalArrivalTime: 04 Apr 2002 00:59:05.0759 (UTC) FILETIME=[EB3F22F0:01C1DB73] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA18883 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Mike, > > > Rajesh Mohan writes: > > Say, we have this special box made to be used in data > centers. We have regular IPSec complaint box in corporate > network. It will be convenient for the administrator at data > center to tunnel all traffic of a particular VLAN to the > corporate network. He does not care what network is at the > remote end. On the other end, the corporate administrator has > well defined selectors for the tunnel to the cage. > > > > In this unsymmetric setup, having no selectors at IPSec > (and a way to negotiate this in IKEv2) is useful. > > Ok, I'm probably in left field here, but what you seem > to be describing is a completely permissive traffic > selector, not a lack of one. What's the problem here? > There are two things I did not understand in your reply, "left side" and "permissive traffic selector". The first one probaly does not matter :-). I am not sure about the second. Anyway, I will try to clarify myself further. There were two proposals so far to solve problems caused by having static selectors in IPSec (and hence IKE). The first was to not have selectors and the second is to have dynamic selectors. In the case of dynamic selectors, the selectors will be expanded based on the type of traffic flow or the traffic received through the tunnel. In the case of no selectors, the traffic enforcer is actually outside IPSec. When we have a option to not have selectors in IPSec, the decision to tunnel or not can be part of (say) firewall rules. When I say selectors should be optional, I do not mean that implementation of selectors be optional. IPSec complaint implementations should support selectors but there should be a way to setup a tunnel without actually specifying a selector. The example I gave was to illustrate a case where having static selectors does not help. There were other examples before. I am trying to convince that selectors should be optional/dynamic. - Rajesh M > Mike > From owner-ipsec@lists.tislabs.com Wed Apr 3 17:40: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 g341emm23117; Wed, 3 Apr 2002 17:40:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19019 Wed, 3 Apr 2002 20:05:15 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Is TS agreement necessary? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 3 Apr 2002 17:13:30 -0800 Message-ID: Thread-Topic: Is TS agreement necessary? Thread-Index: AcHbc+8sOdwTUzjTSkKp2TKlGlA6PgAAQhWg From: "Rajesh Mohan" To: "Stephen Kent" , "Mike Ditto" Cc: X-OriginalArrivalTime: 04 Apr 2002 01:13:30.0984 (UTC) FILETIME=[EEF5FE80:01C1DB75] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA19014 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > we designed IPsec to not have to trust peers to do the right thing. > we adopted a defensive posture consistent with the security principle > of least privilege. I'm not sure how to interpret your comments > relative to this well known security principle. > I think we are imposing the trust model on the end users here. It should be configurable. If the administrators chooses to trust the peer, then there should be a way to configure it. If we do not allow, people will workaround it. For example, if it is required, people will do IP in IP with the gateways as selectors. -Rajesh M From owner-ipsec@lists.tislabs.com Wed Apr 3 18:57: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 g342vtm24832; Wed, 3 Apr 2002 18:57:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19596 Wed, 3 Apr 2002 21:19:16 -0500 (EST) Date: Wed, 3 Apr 2002 18:30:13 -0800 (PST) From: Jan Vilhuber To: Casey Carr cc: , IPSec Policy WG Subject: Re: FW: Dead peer detection 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 Wed, 3 Apr 2002, Casey Carr wrote: > Sorry. I sent this to the IPSec Policy WG the first time by mistake. > > I think it more appropriate in the general IPSec WG. > > -----Original Message----- > From: Casey Carr [mailto:caseyc@cipheroptics.com] > Sent: Wednesday, April 03, 2002 2:24 PM > To: IPSec Policy WG > Subject: Dead peer detection > > > Is there an RFC or draft on standards track to deal with dead peer > detection? After spending some time reviewing the IPSec, IKE, ISAKMP RFCs I > have drawn the conclusion that there is not a "standard" way to implement > dead peer detection. Have I reached a valid conclusion? Are other IPSec > vendors implementing proprietary solutions? If so, have there been > interoperability issues? > > I reviewed draft-ietf-ipsec-dpd-00.txt. It appears to be a year old without > revisions which leads me to believe that it may not be widely accepted. > > It also appears from a statement in JFK that the authors regard this as an > implementation issue: > > "A second major reason for Phase II is dead peer detection. IPsec > gateways often need to know if the other end of a security association > is dead, both to free up resources and to avoid "black holes". > In JFK, this is done by noting the time of the last packet received. When we were designing the DPD mechanism published in the draft, we actually considered this. Given that media traffic can easily be unidirectional (UDP/RTP traffic needs no ack's), we didn't think this was appropriate, since you could go your whole life without a packet in the other direction (internet radio comes to mind, except of course that most of those run over tcp..). > A peer that wishes to elicit a packet may send a "ping". Such > hosts MAY decline any proposed security associations that do not > permit such "ping" packets." > The sense I get in the working group is that the key protocol should indeed have formalized key management functionality (deletes, informationals, DPD, etc). Using pings has its own set of problems, so we should formalize this all under the key management protocol (i.e. son of IKE). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Apr 3 19:18: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 g343IIm25392; Wed, 3 Apr 2002 19:18:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA19718 Wed, 3 Apr 2002 21:42:40 -0500 (EST) Date: Wed, 3 Apr 2002 18:54:13 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec mailling list Subject: Re: Is TS agreement necessary? 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 Wed, 3 Apr 2002, Stephen Kent wrote: > Your descriptions have not yet convinced me, and others, that > interoperability is achieved and at no loss of access control > granularity. > I think we had a similar debate on this list about the access control granularity of IPsec, and what are the concequences of loosing it, when L2TP+IPsec (L2TP secured with IPsec to provide remote access) was discussed on this list a couple of years ago. First, we are talking about a peer that has successfully authenticated to us in phase1(or its equivalent), and we have successfully identified who the peer is. What is the point in someone strongly authenticating to us, and then attacking us using a secured channel which has traffic source authentication? Secondly, isn't access control and intrusion detection much more than looking at src/dst IP address, transport protocol and port? Yes, IPsec provides limited access control, but how many deployments deem the access control provided by IPsec sufficient, and not run Firewalls and IDS systems, on all traffic, including the traffic that arrived/sent on IPsec tunnels. The limited access control provided by IPsec may sometimes even be regarded as a false sense of security, if people are not running a firewall/IDS on the traffic that is protected by IPsec. We often see IPsec and firewalls bundled as a single product, because if you want serious access control and IDS, you should be running a firewall. If an IPsec tunnel can be implemented in an interoperable manner to look like a virtual point-to-point link, it can have a lot of benefits. The IPsec secured virtual point-to-point link can be made visible to the routing protocols, and we can run routing on that link to automatically get the resiliency and all the other benefits provided by routing. No need to run keepalives or DPDs, which only provide information of connectivity to the IPsec gateways, and provide no information about the connectivity to the traffic destination. We can route multicast traffic across the point-to-point link too. Yes, we loose the limited access control that IPsec provides, but any serious deployment would not soley depend on the access control provided by IPsec. Isn't the simplicity derived from not having to negotiate traffic selectors in a key management/establishment protocol and not having to do the job of routing (DPD/Keepalive) and other benefits mentioned above worth sacrificing the limited access control provided by IPsec? I feel that TS agreement is necessary atleast to the extent that, it would be nice to come up with an interoperable way of treating the IPsec tunnel as a point-to-point link. chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Apr 4 04:46:03 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 g34Ck3m13192; Thu, 4 Apr 2002 04:46:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22989 Thu, 4 Apr 2002 06:49:52 -0500 (EST) Message-Id: <200204041202.HAA10654@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-jfk-02.txt Date: Thu, 04 Apr 2002 07:01:59 -0500 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 : Just Fast Keying (JFK) Author(s) : W. Aiello, S. Bellovin et al. Filename : draft-ietf-ipsec-jfk-02.txt Pages : Date : 03-Apr-02 This draft discusses JFK, a key management protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-02.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-jfk-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-jfk-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020403130422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-jfk-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-jfk-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020403130422.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Apr 4 05:31: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 g34DVTm14851; Thu, 4 Apr 2002 05:31:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23274 Thu, 4 Apr 2002 07:57:43 -0500 (EST) Date: Wed, 3 Apr 2002 15:00:29 -0800 (PST) Message-Id: <200204032300.PAA09990@potomac.incog.com> From: Mike Ditto To: dharkins@tibernian.com CC: skelly@SonicWALL.com, ipsec@lists.tislabs.com In-reply-to: <200204032234.g33MYAW01612@fatty.lounge.org> (message from Dan Harkins on Wed, 03 Apr 2002 14:34:10 -0800) Subject: Re: Is TS agreement necessary? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > When I initiate SA negotiation, I get to decide what goes in the > > selectors on my end, just like current IKE implementations. What's > > different is how the selectors are set up for SAs that were requested by > > my peer. When my peer asks me to add an SA pair to my SAD, I mark the > > SAs as "completely shared", "address unique" or "session unique" as my > > peer requests. > > The peer requests some "shared" or "unique" -ness to be assigned to > the SA during SA establishment time? How is that to be done exactly and > why is that any better than a TS payload? You mean how does the initiator know which style to request? It could be explicit in the policy (the "shared" or "unique" attribute of the SPD entry) or implicit in the application (maybe a VPN gateway would always request shared SAs). I think I'd prefer something explicit. Or do you mean how does this go in the SA establishment protocol? It would go in a place similar to where the TS payloads would have been, except that there would be one segregation parameter specified for each matched pair of SAs, since the responder will have to learn and keep track of traffic selectors for the SAs as a pair. > You're proposing to replace a specific indication with an abstract hint. > It looks like there's lots of room for interpretation and disinteroperability > in this. That sounds worse than what we have today with IKEv1 and much, > much worse than what is proposed with the TS payload. Some email may have passed in transit, but I've explained that there is no risk of disinteroperability. If the responder ignores or misinterprets the hint, things still work, because the sender of any packet is free to use whatever method is convenient or appropriate in its implementation for traffic segregation, taking the hint into account or not. The receiver will check that the SA was an appropriate one as far as its own policy. The worst case result of mis-interpretation of the segregation hint is different segregation policy in the two directions, and that difference would be documentable characteristics of the two implementations. -=] Mike [=- From owner-ipsec@lists.tislabs.com Thu Apr 4 05:31: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 g34DVvm14924; Thu, 4 Apr 2002 05:31:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23273 Thu, 4 Apr 2002 07:57:42 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Is TS agreement necessary? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 3 Apr 2002 14:31:20 -0800 Message-ID: Thread-Topic: Is TS agreement necessary? Thread-Index: AcHbVxeux0wU6d/aSuynhXgNiW4l3AAAfqFw From: "Sankar Ramamoorthi" To: "Mike Ditto" , Cc: X-OriginalArrivalTime: 03 Apr 2002 22:31:20.0619 (UTC) FILETIME=[47361FB0:01C1DB5F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA17934 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Mike Ditto [mailto:ford@incog.com] > Sent: Wednesday, April 03, 2002 12:01 PM > To: skelly@SonicWALL.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Is TS agreement necessary? > > > "Scott G. Kelly" wrote: > > Suppose, as you suggest, that we allowed negotiation of > multiple SAs > > between two peers without specifying TS values. > Ultimately, there must > > be *some* policy rule associated with each of these SAs > since, as you > > suggest, the point is to somehow segregate traffic between > them. That > > is, for a given SA, some traffic is allowed, and some is > not. Please > > elaborate upon how we determine which traffic is > appropriate for each SA > > once they are established. > > OK. At the time of sending a packet, the SA lookup would > work basically > the same as it does currently; the SPD and SAD would > determine which SA > is used. I'm not proposing removing selectors from the SAD, I'm just > proposing that the selectors aren't sent explicitly in SA > establishment. > > When I initiate SA negotiation, I get to decide what goes in the > selectors on my end, just like current IKE implementations. What's > different is how the selectors are set up for SAs that were > requested by > my peer. When my peer asks me to add an SA pair to my SAD, I mark the > SAs as "completely shared", "address unique" or "session unique" as my > peer requests. If it's "completely shared" then I add a completely > wildcarded selector to the outbound SA. If it's one of the "unique" > styles, I don't add any selectors and I will never use the outbound SA > until the peer has sent me some traffic on the inbound one. > > Whenever I receive traffic on an inbound SA I add the corresponding > selectors to the matching outbound SA. If the SA (pair) is "address > unique" I add to the outbound SA a destination address selector using > the packet's (inner) source address. If the SA (pair) is "session > unique" then I add to the outbound SA a selector that describes my > concept of a session for that protocol (the easiest definition of > session for RFC2401-style implementations would be to use > port numbers). > But the ends don't have to agree on the exact definition of a session. > > An implementation is still able to use selectors on inbound SAs to > efficiently validate inbound traffic. When an inbound packet doesn't > match the inbound SA's selectors, the SPD is checked and if the packet > is allowed, the appropriate selectors are added to the inbound and > outbound SAs. > > The core idea of this proposal, the thing that makes interoperability > possible without agreement on the definition of a session, is that the > sender of each packet is free to choose between multiple > equivalent SAs > however it sees convenient to implement, and the receiver accepts the > decision as long as the chosen SA matches the security > parameters. When > establishing SAs, the initiator gives an abstract hint to the > responder > about the desired granularity of segregation. abstract hint need to be standardized for interoperability, since the hints are going to part of the negotiation. Once done they could construe as a solution for ipsec traffic segregeation for complex services (dynamic ports) - It is that versus somehow conveying the dynamic selectors explicitly. Explicitly conveying selector information provides the comforting feeling that both peers know that each agree on exactly what type of traffic is going to flow through the tunnel. One problem I see with hints are - Both peers have to maintain faithful stateful inspection to keep track of the session (othewise 'session-unique' hint cannot be supported). It may or may not be always feasible. Also if the state of the session is not faithfully tracked, there is a possiblity for the receiver to incorrectly drop/accept the packets. I do think however that IPsec solution scope should be defined 1) Should the scope be limited to a collection of layer4 information some of which may be dynamically determined? 2) Should IPsec granularity apply to layer5(and above information) such as URL, specific file-date?.. I think IPsec should not allow 2) - It would be useful if the requirements can capture the scope explicitly when discussing the requirements for dynamic ports. > > > > As an aside, can you tell us why wildcard TS values do not > satisfy your > > requirements in the same way that omitting TS values would? > > I think wildcard TS values would satisfy my requirements if I was > allowed to ignore any non-wildcard selectors sent to me, and if I > didn't want to implement traffic segregation. > > > -=] Mike [=- > > From owner-ipsec@lists.tislabs.com Thu Apr 4 05:32:15 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 g34DWEm14971; Thu, 4 Apr 2002 05:32:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23343 Thu, 4 Apr 2002 07:59:42 -0500 (EST) Message-ID: <3CABADBC.9000506@isi.edu> Date: Wed, 03 Apr 2002 17:34:52 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Mark Duffy CC: Joe Touch , ipsec@lists.tislabs.com Subject: Re: questions on draft-touch-ipsec-vpn References: <3.0.5.32.20020402225856.00845d00@email.quarrytech.com> <3.0.5.32.20020403194048.008c8470@email.quarrytech.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020906030409040704090005" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms020906030409040704090005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Duffy wrote: > I think what you mean by "use a virtual device for each ... tunnel" is that > the IPsec tunnel is modeled in the system as a point to point link, onto > which the system has an interface, correct? With IIPtran, doesn't the > IP-in-IP tunnel have to be modeled in exactly that same way? Maybe I am > being thick but I don't see the gain there. We assumed that RFC2003-compliant IP tunnels are implemented as proper interfaces. You're right that it would be conceivable to implement them differently (divert socket hacks, etc.), and on such platforms they would need to be fixed just like SAs would need to be so they are present in the routing table. (I wouldn't want to use such a platform, however :-) > In either case I would see motivations following from one other in the same > order: > a. I want to create a point-point link in the overlay network > b. I need an "overlay" interface at both routers of the overlay network. > c. I create a tunnel connecting those overlay interfaces Yes. Note that neither of these steps has involved security yet. So far, what you have described is setting up an IP tunnel in a virtual topology, and can be done soley with RFC2003. With IIPtran, you then have d. secure the new tunnel using IPsec transport mode which is a orthogonal step (modulo inbound processing as described in the ID). The nice thing about IIPtran is that it decouples security from topology. Deploy your topology with IP tunnels. Then, if you want it secure, turn on transport mode; if not, just leave it. The nice thing about tunnel mode is IKE, actually. There is no comparable protocol to set up IP tunnels. (There should be, however, and tunnel negotiation should be stripped from IKE - but that's a topic for another thread :-) > Both IIPtran, and tunnel mode IPsec with 0.0.0.0/0 selectors can accomplish > this; the latter just seems more direct. (At least, when implementing from > certain starting points -- I understand you are working within the > constraints of an existing platform/stack.) 0.0.0.0/0 selectors seem to require a certain order of operations during outbound processing (forwarding over physical interfaces before IPsec matching), otherwise you could get encapsulation loops. IIPtran does not depend on implementation side effects. >>These two solutions are equivalent in function, but different in >>complexity. #2 implies that all SPDs have either one or more transport >>mode SA, or exactly one tunnel mode SA (and no transport mode SAs). This >>ends up treating tunnel mode as a special case w.r.t. association with >>devices, for an indirect (routing) reason. > > I don't follow that. I think #2 by definition involves tunnel mode SAs; > that is how it is isolating the overlay traffic. Each virtual link would > *typically* consist of a single bidirectional SA pair. However, it could > conceivably consist of an aggregate of any number of SA pairs, so long as > a) they all go to the same overlay next hop, and b) the union of all their > selectors is 0.0.0.0/0, i.e. between them all they will admit any packet. > In any event, what is the special case with respect to devices you mention? You must enforce that your SA pseudo tunnels are only ever associated with exactly one tunnel mode SA (or a non-overlapping combination as you said), otherwise you'd see encapsulation loops. You then need to furthermore enforce that all non-tunnel devices only ever get associated with transport mode SAs, otherwise you again get tunnels that aren't represented in the routing table, and you're back at square one. These seem like strong indications that encapsulation is an interface capability, not an SA one. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms020906030409040704090005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwNDAxMzQ1M1owIwYJKoZIhvcNAQkEMRYEFOLWJmr7YE9Ix2/pFqO+kUO4BgX0MFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAjwlQNZ7X/kvRyoCwXpE39VZhbkXAUID0VBf8ZclC4m0LeXi4/s8Ui5DLOa0jPHJBQ 9SmKCzVXoFpFBPhoBalISpa8osBtV3YX8j+Ji76p98p5G68uP5fPoV2Jhg3ZfBvMBYiKiwua bMtkWtZZmXvVvCkJnClkAqI7p8I/jz4wPwAAAAAAAA== --------------ms020906030409040704090005-- From owner-ipsec@lists.tislabs.com Thu Apr 4 05:33: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 g34DX5m15102; Thu, 4 Apr 2002 05:33:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23298 Thu, 4 Apr 2002 07:58:46 -0500 (EST) Message-ID: <3CABA942.3050507@isi.edu> Date: Wed, 03 Apr 2002 17:15:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: larse@ISI.EDU, ipsec@lists.tislabs.com Subject: Re: questions on draft-touch-ipsec-vpn References: <3.0.5.32.20020402225856.00845d00@email.quarrytech.com> <3.0.5.32.20020403194048.008c8470@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy wrote: > At 10:13 PM 4/2/02 -0800, Joe Touch wrote: > >>Mark Duffy wrote: >> >>>Hi, I have a few questions for the authors of draft-touch-ipsec-vpn-03.txt. >>> >>>The draft addresses the use of IPsec to secure the virtual links of an >>>overlay network. In this application, the goal is to make forwarding >>>decisions based on evaluating the packet destination address against a >>>forwarding table, rather than by evaluating a set of packet selectors >>>against an SPD. I.e. the policy aspect of IPsec is not desired in this >>>application and must somehow be gotten around. >>> >>>The draft describes using IP-in-IP tunnelling and securing the result with >>>transport mode IPsec (IIPtran). Why choose this approach over simply >>>negotiating tunnel mode IPsec with wild-card selectors (i.e. 0.0.0.0/0) and >>>then at a higher level using the routing decision to choose which tunnel to >>>use? >> >>This was addressed in a presentation in Minneapolis. The counterexample >>is when two tunnels, both with wildcard selectors, go out the same >>physical interface. In that case, the routing table has insufficient >>information to indicate which tunnel to use. >> >>There are two solutions: >> >>1. use IIPtran >> >>2. use a new virtual device for each new IPsec tunnel >>i.e., such that the routing table sends packets to that device name > > I think what you mean by "use a virtual device for each ... tunnel" is that > the IPsec tunnel is modeled in the system as a point to point link, onto > which the system has an interface, correct? With IIPtran, doesn't the > IP-in-IP tunnel have to be modeled in exactly that same way? Maybe I am > being thick but I don't see the gain there. #2 requires an implementation that has a handle (a device, at least in systems we've used) that can be used as a destination in the routing table. IIPtran doesn't require that handle, because it wraps the packet in an IP address that can be used to identify the SA. > In either case I would see motivations following from one other in the same > order: > a. I want to create a point-point link in the overlay network > b. I need an "overlay" interface at both routers of the overlay network. > c. I create a tunnel connecting those overlay interfaces > > Both IIPtran, and tunnel mode IPsec with 0.0.0.0/0 selectors can accomplish > this; the latter just seems more direct. We think the former is more direct, because it is sufficient to have IPsec transport mode with existing tunneling mechaninsms. The latter requires that tunnel mode be used in a particular way, and with particular constraints depending on the implementation (notably when tunnels go out the same interface, as already discussed). >>These two solutions are equivalent in function, but different in >>complexity. #2 implies that all SPDs have either one or more transport >>mode SA, or exactly one tunnel mode SA (and no transport mode SAs). This >>ends up treating tunnel mode as a special case w.r.t. association with >>devices, for an indirect (routing) reason. > > I don't follow that. I think #2 by definition involves tunnel mode SAs; > that is how it is isolating the overlay traffic. Yes. In #2, a tunnel would have a SPD with exactly one entry, a tunnel mode SA. No SPD could ever have anything EXCEPT a single tunnel mode SA OR multiple transport-mode SAs (that's all I was saying above). > Each virtual link would > *typically* consist of a single bidirectional SA pair. However, it could > conceivably consist of an aggregate of any number of SA pairs, so long as > a) they all go to the same overlay next hop, and b) the union of all their > selectors is 0.0.0.0/0, i.e. between them all they will admit any packet Consider a). If the tunnels start in the same place, have the same selector, and go to the same place, AND are in the same virtual link SPD, the routing table doesn't have enough information to distinguish when to use each SA. Only one would ever get used. Consider b); that might work, but if you're putting up tunnels for a VPN, they typically always have 0.0.0.0/0 selectors. > In any event, what is the special case with respect to devices you mention? > If that refers to casting the tunnel endpoints as IP interfaces of the > overlay router, I come back to believing that the same would be required of > the IP-in-ip tunnels. The IP-in-IP tunnels, by virtue of wrapping the packet first, encode sufficient information in the wrapper to distinguish outgoing SA. That's how they differ from solutions that try to do BOTH wrapping AND keying in the same step (i.e., IPsec tunnel mode). This is explained in one of the first diagrams in our ID. Joe From owner-ipsec@lists.tislabs.com Thu Apr 4 05:33: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 g34DXXm15177; Thu, 4 Apr 2002 05:33:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23257 Thu, 4 Apr 2002 07:56:41 -0500 (EST) Date: Wed, 3 Apr 2002 14:34:11 -0800 (PST) Message-Id: <200204032234.OAA09939@potomac.incog.com> From: Mike Ditto To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Wed, 3 Apr 2002 16:59:50 -0500) Subject: Re: Is TS agreement necessary? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > we have adopted the selector mechanism, in part, to allow sites to > make the decision of what granularity of traffic muxing on an SA is > acceptable. this proposal takes away that capability and tries to > substitute three options. It is not clear that this reduced > flexibility will meet all requirements now and going forward. Also, I agree. But it's clear that the present model doesn't meet all requirements now and going forward, as demonstrated by the need to make significant changes to IPsec for a new transport protocol. I think it's a serious design flaw that IPsec standards and implementations have to be changed to accomodate a new transport protocol. My proposal would eliminate that dependency. > the suggestion that "session" would be an implementation defined > concept could pose serious interoperability problems, and it leaves > prospective users wondering what will happen when their > implementation interacts with another. I don't think so; see below. > >This way, if my implementation considers the control connection and the > >data connections of an FTP session to be one "session", and the other > >end considers those to be multiple distinct "sessions", there is still > >interoperability. > > How? if the other end wants them to be separate sessions, won't it > reject data traffic you send over the SA that was established first > for control traffic? No, that's the core of this idea: the receiver trusts the sender to make segregation decisions. If the peer starts sending you stuff that your policy allows, but you weren't expecting to arrive on that particular SA, adjust your expectations to match the sender's choice. This guarantees interoperability even in the face of very different implementations and their ideas of service and session. Suppose my implementation supports a new transport protocol which is, say layered on top of UDP port 12345, and I want to segregate my different sessions within that protocol on different SAs. It would be nice if I could do that without changing IPsec and IKE and waiting for the other end to upgrade its implementation. Of course if the other end doesn't know about my special protocol, it won't do segregation beyond what it knows (lumping all of UDP port 12345 together), but it will interoperate and I can at least segregate my outbound traffic. And if the other end does know about my new transport protocol (perhaps it's running my implementation too), the desired behavior is achieved without having to violate or update the IPsec standards. > >It might be a good idea even to allow simple IPsec implementations > >(e.g. for embedded use) not to implement traffic segregation, falling > >back to "completely shared" SAs, in a transparently interoperable way. > > It's always easy to imagine limited functionality implementations of > a protocol for restrictive environments that might otherwise have > some difficulty implementing the full set of required functions for > the protocol. 20 years ago we saw that in LANs, where some folks > decided that computing the TCP checkusm was a waste of time for > traffic that was local to their LAN. Adoption of standards always > implies compromises; a standard is rarely the optimal way to > implement a set of functions for the full range of environments in > which it may be employed. Right. That's why I think it's a valuable property of my proposal that interoperability is maintained without having to negotiate the use of an optional feature... it just works if one side (or both) decides to use completely shared SAs. > >Does this meet the requirements of those who strongly believe in the > >importance of this kind of traffic segregation? I'm not such a strong > >believer; most of the scenarios I've heard where it's relevant seem to > >have nearly identical weaknesses with and without traffic segregation, > >or are better handled by assigning unique identities to the unique > >users. But I'll take others' word that it's an important capability, > >and ask such people whether this proposal is sufficient. > > In short, no. OK, why? Is it becuase you (as a user/policy administrator) really don't trust the other end to do as much segregation as you want, and you want it to be strictly enforced by your end? Because there would be a possibility that the other end's implementation would lump more things together than you expect? I can understand those complaints, but to me, some vagueness in the details of traffic segregation is a small price to pay for increased interoperability, simplicity, and freedom of implementation choice. -=] Mike [=- From owner-ipsec@lists.tislabs.com Thu Apr 4 05:33: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 g34DXnm15207; Thu, 4 Apr 2002 05:33:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA23299 Thu, 4 Apr 2002 07:58:47 -0500 (EST) Date: Wed, 3 Apr 2002 16:52:27 -0800 (PST) Message-Id: <200204040052.QAA10042@potomac.incog.com> From: Mike Ditto To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Wed, 3 Apr 2002 19:06:12 -0500) Subject: Re: Is TS agreement necessary? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >I agree. But it's clear that the present model doesn't meet all > >requirements now and going forward, as demonstrated by the need to > >make significant changes to IPsec for a new transport protocol. I > >think it's a serious design flaw that IPsec standards and > >implementations have to be changed to accomodate a new transport > >protocol. My proposal would eliminate that dependency. > > Which new transport protocol are you talking about? Any transport protocol for which traffic segregation is desired. IPsec is currently specified with special case handling for TCP and UDP. A clean network-layer security protocol would not overflow into the transport layer like that. I think it's great that the IPsec documents give special emphasis to TCP and UDP when explaining processing or describing a model implementation or policy notation, but the protocols and the normative behavior specification should have stayed cleanly within the network layer. > >No, that's the core of this idea: the receiver trusts the sender to > >make segregation decisions. If the peer starts sending you stuff that > >your policy allows, but you weren't expecting to arrive on that > >particular SA, adjust your expectations to match the sender's choice. > >This guarantees interoperability even in the face of very different > >implementations and their ideas of service and session. > > we designed IPsec to not have to trust peers to do the right thing. > we adopted a defensive posture consistent with the security principle > of least privilege. I'm not sure how to interpret your comments > relative to this well known security principle. >From a security point of view, traffic segregation inherently assumes a degree of trust of the peer. You can't enforce that the peer or something beyond it doesn't leak everything between the SAs. You can still fully enforce access control, and my proposal doesn't reduce that. > >Suppose my implementation supports a new transport protocol which is, > >say layered on top of UDP port 12345, and I want to segregate my > >different sessions within that protocol on different SAs. It would be > >nice if I could do that without changing IPsec and IKE and waiting for > >the other end to upgrade its implementation. Of course if the other > >end doesn't know about my special protocol, it won't do segregation > >beyond what it knows (lumping all of UDP port 12345 together), but it > >will interoperate and I can at least segregate my outbound traffic. > >And if the other end does know about my new transport protocol > >(perhaps it's running my implementation too), the desired behavior is > >achieved without having to violate or update the IPsec standards. > > Whoops, terminology error. UDP is the transport protocol here. What > rides above it is an application. I have a hard time interpreting > what you are proposing given the combination of terminology errors > and what I perceive as persistent vagueness in the examples. My mistake there is related to a part of my point: policy enforcement should not always be focused at the transport layer. As for the specific example, call it an application protocol, or modify my example to say "IP protocol 234" instead. The point is that locking the definition of a session into the SA establishment protocol, based on two specific transport protocols, is constraining on implementation choices, on growth, and on the actual functionality that the system can provide. Current network security products classify traffic into sessions by many criteria other than TCP/UDP port numbers, and future ones will want to do things that haven't been thought of yet. > Your descriptions have not yet convinced me, and others, that > interoperability is achieved and at no loss of access control > granularity. I haven't suggested any change to access control granularity. The policy is still applied to every packet, and if you like, you can still implement that policy using RFC2401-style selectors. > >OK, why? Is it becuase you (as a user/policy administrator) really > >don't trust the other end to do as much segregation as you want, and > >you want it to be strictly enforced by your end? > > that's a good starting point for being defensive. Defensive against what? As I said, traffic segregation already assumes some trust of the peer. Is there a vulnerability or not? > > Because there would > >be a possibility that the other end's implementation would lump more > >things together than you expect? > > another good reason. Again, I have to point out that the peer has full access to and control over the data flows at the other end. If your end considers two packets to belong to two different sessions, and the other end considers them to be part of the same session, your expectation that the other end will respect your segregation desires seems misplaced. -=] Mike [=- From owner-ipsec@lists.tislabs.com Thu Apr 4 05:34: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 g34DYSm15232; Thu, 4 Apr 2002 05:34:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23367 Thu, 4 Apr 2002 08:00:44 -0500 (EST) Message-ID: <006a01c1dbcb$ce6823e0$bd0da8c0@shiva> From: "Shiva" To: Subject: Help Date: Thu, 4 Apr 2002 16:58:12 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C1DBF9.E8127D30" 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 X-MDRemoteIP: 192.168.13.189 X-Return-Path: shiva@mistralsoftware.com X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C1DBF9.E8127D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to install FreeSwan ipsec on Linux-7.0(kernel 2.2.16-22) I am following the procedure given in the installation document, but I = am getting an error at the stage of running 'make menugo'. The error is = about patch. I would like to know if there is any fix to this problem. Thanking you Shiva ------=_NextPart_000_0067_01C1DBF9.E8127D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to install FreeSwan ipsec = on=20 Linux-7.0(kernel 2.2.16-22) I am following the procedure given in = the=20 installation document, but I am getting an error at the stage of = running =20 'make menugo'. The error is about=20 patch. I would like to know if there is any = fix to this=20 problem. Thanking you Shiva ------=_NextPart_000_0067_01C1DBF9.E8127D30-- From owner-ipsec@lists.tislabs.com Thu Apr 4 06:40: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 g34EeQm19397; Thu, 4 Apr 2002 06:40:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23709 Thu, 4 Apr 2002 08:55:56 -0500 (EST) From: "Casey Carr" To: "Ricky Charlet" , "'Stephane Beaulieu'" , Subject: RE: Dead peer detection Date: Thu, 4 Apr 2002 08:59:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <7B8824D690092B4B90B0EF4674750A65022DF5C2@USEXCH3.us.sonicwall.com> X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We are just addressing this from a requirements standpoint. My hunch is that we will have to implement something prior to SOI so we would at least consider the draft DPD as a potential solution. Casey -----Original Message----- From: Ricky Charlet [mailto:rcharlet@SonicWALL.com] Sent: Wednesday, April 03, 2002 7:06 PM To: 'Stephane Beaulieu'; Casey Carr; ipsec@lists.tislabs.com Subject: RE: Dead peer detection Howdy, Hey, I was interested! Very early on I asked the draft authors about their intentions and they told me to not implement the -00 draft because they envisioned significant change. So I waited. (and waited...). If we implemented the -00 draft, would we interoperate with you? Any VPN vendor will run across the customer driven request for tunnel-black-hole-detection and possibly for supporting alternative tunnels to backup gateways. Dead peer detection (of some sort) is a fundamental requirement for these. Yet End-to-End IPsec'ers see any DPD mechanism as dangerous overhead and unnecessary complexity. Even among folks who want a standardized DPD mechanism, disagreements over the driving requirements (should it support site-to-site tunnels, should it support remote access without interfering with accounting or PPP link keep alive, other reasonable use cases may be envisioned) lead to opposing suggestions for its implementation (in IKE, in ESP/AH, in the clear). I believe that of the people who are actually deploying home grown solutions for DPD, this draft-ietf-ipsec-dpd-00.txt (with its implementation in authenticated IKE exchanges) solves their problem set. It solves our problem set. Also on the horizon it IKEv2 which has a DPD mechanism proposed within it (thanks Kaufman and IKEv2 team). -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : rcharlet@sonciwall.com : usa (408) 962-8711 > -----Original Message----- > From: Stephane Beaulieu [mailto:stephane@cisco.com] > Sent: Wednesday, April 03, 2002 1:51 PM > To: Casey Carr; ipsec@lists.tislabs.com > Subject: RE: Dead peer detection > > > Hi Casey, > > There are 3 or 4 different ways of doing Dead Peer Detection > that I am aware > of. Cisco has an older method reffered to as Keepalives in our older > releases of IOS, VPN3000, and PIX. It is undocumented (to the public) > though I believe some of our partners have also implemented it. > > All of our newer releases support the DPD draft you > referenced, and we are > going to slowly deprecate keepalives. We published DPD in > the IPsec WG in > hopes to get it standardized. However, there hasn't been > much interest > which is why the draft has been idle. I think the WG chairs > also decided > that DPD was outside the scope of the WG because of the > moratorium. I sent > an email to Ted a few weeks ago asking whether we could try to go > standards-track with it or if we should just go out as > Informational. I'm > still waiting for a response. > > I know that Nortel also has some scheme which addresses the > same issues, > though they apparently have a patent on it. > > I'm sure there are other proprietary versions which are > probably all very > simliar except for the bits on the wire. > > Hope this helps, > Stephane. > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Casey Carr > > Sent: Wednesday, April 03, 2002 3:22 PM > > To: ipsec@lists.tislabs.com > > Cc: IPSec Policy WG > > Subject: FW: Dead peer detection > > > > > > Sorry. I sent this to the IPSec Policy WG the first time > by mistake. > > > > I think it more appropriate in the general IPSec WG. > > > > -----Original Message----- > > From: Casey Carr [mailto:caseyc@cipheroptics.com] > > Sent: Wednesday, April 03, 2002 2:24 PM > > To: IPSec Policy WG > > Subject: Dead peer detection > > > > > > Is there an RFC or draft on standards track to deal with dead peer > > detection? After spending some time reviewing the IPSec, IKE, > > ISAKMP RFCs I > > have drawn the conclusion that there is not a "standard" > way to implement > > dead peer detection. Have I reached a valid conclusion? > Are other IPSec > > vendors implementing proprietary solutions? If so, have there been > > interoperability issues? > > > > I reviewed draft-ietf-ipsec-dpd-00.txt. It appears to be a year > > old without > > revisions which leads me to believe that it may not be > widely accepted. > > > > It also appears from a statement in JFK that the authors regard > > this as an > > implementation issue: > > > > "A second major reason for Phase II is dead peer detection. IPsec > > gateways often need to know if the other end of a > security association > > is dead, both to free up resources and to avoid "black holes". > > In JFK, this is done by noting the time of the last > packet received. > > A peer that wishes to elicit a packet may send a "ping". Such > > hosts MAY decline any proposed security associations that do not > > permit such "ping" packets." > > > > > > Thanks, > > Casey > > > > From owner-ipsec@lists.tislabs.com Thu Apr 4 07:47: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 g34Fl0m23441; Thu, 4 Apr 2002 07:47:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24150 Thu, 4 Apr 2002 10:05:14 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 4 Apr 2002 10:16:31 -0500 To: "Rajesh Mohan" From: Stephen Kent Subject: RE: Is TS agreement necessary? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:13 PM -0800 4/3/02, Rajesh Mohan wrote: > > >> we designed IPsec to not have to trust peers to do the right thing. >> we adopted a defensive posture consistent with the security principle >> of least privilege. I'm not sure how to interpret your comments >> relative to this well known security principle. >> > >I think we are imposing the trust model on the end users here. It >should be configurable. If the administrators chooses to trust the >peer, then there should be a way to configure it. > >If we do not allow, people will workaround it. For example, if it is >required, people will do IP in IP with the gateways as selectors. > > >-Rajesh M Good security engineering dictates mutual suspicion in contexts such as these. This is not a "trust model" in a PKI sense. Steve From owner-ipsec@lists.tislabs.com Thu Apr 4 08:02: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 g34G2Dm23855; Thu, 4 Apr 2002 08:02:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24285 Thu, 4 Apr 2002 10:24:54 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 4 Apr 2002 10:33:29 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: Is TS agreement necessary? Cc: ipsec mailling list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:54 PM -0800 4/3/02, Chinna N.R. Pellacuru wrote: >On Wed, 3 Apr 2002, Stephen Kent wrote: >> Your descriptions have not yet convinced me, and others, that >> interoperability is achieved and at no loss of access control >> granularity. >> > >I think we had a similar debate on this list about the access control >granularity of IPsec, and what are the concequences of loosing it, when >L2TP+IPsec (L2TP secured with IPsec to provide remote access) was >discussed on this list a couple of years ago. > >First, we are talking about a peer that has successfully authenticated to >us in phase1(or its equivalent), and we have successfully identified who >the peer is. What is the point in someone strongly authenticating to us, >and then attacking us using a secured channel which has traffic source >authentication? the answer is that merely because we have authenticated a peer, that does not mean that we are prepared to allow that peer to have unconstrained access to all resources behind the IPsec implementation, whether the implementation is at an enclave perimeter or a single machine. what if one of the peers is an organization that has just been compromised and thus traffic from that site is no longer "friendly?" the point is that authentication and authorization are distinct aspects of security and IPsec makes provisions to support both, at variable granularities. >Secondly, isn't access control and intrusion detection much more than >looking at src/dst IP address, transport protocol and port? Yes, IPsec >provides limited access control, but how many deployments deem the access >control provided by IPsec sufficient, and not run Firewalls and IDS >systems, on all traffic, including the traffic that arrived/sent on IPsec >tunnels. The limited access control provided by IPsec may sometimes even >be regarded as a false sense of security, if people are not running a >firewall/IDS on the traffic that is protected by IPsec. We often see IPsec >and firewalls bundled as a single product, because if you want serious >access control and IDS, you should be running a firewall. Access control and IDS can be effected at various layers in the protocol stack. it is desirable to be able to enforce access control at more than one layer and when doing this it is often appropriate to distribute the enforcement to different devices, consistent with the characteristics of each device. In the case of access controls based on IP layer data, an IPsec implementation is an ideal location to enforce such controls, consistent with the secure binding of authentication data to the traffic, based on the SA via which the traffic was received (looking) at this from a receiver's perspective). Transport layer controls might be enforced elsewhere, but, as with firewalls, it generally is convenient to perform the enforcement at the same place and at the same time because of the proximity of the header info. Also, if access controls for these two closely related layers are enforced at different points in the system, there is a need for closer coordination of the management of the access control databases at those different points. I think the comments re IDS are irrelevant here. IPsec includes no IDS provisions and we're not debating that functionality. With regard to firewalls, IPsec already provides the functions of a stateless packet filtering firewall, so putting another one behind an IPsec device would be redundant. If we enhance IPsec to provide stateful packet filtering, still at the IP and transport layers, then the range of redundant configurations is even bigger. I agree that an IPsec device is not a substitute for an application later proxy firewall, but your comments above do not specify what flavor of firewall you are referring to, so it's hard to tell what argument you are making. If one bundles IPsec and a firewall as a single product, then a vendor has flexibility in offering the IPsec access controls within that product; there is no need for redundancy, a topic we have discussed many times in the past. >If an IPsec tunnel can be implemented in an interoperable manner to look >like a virtual point-to-point link, it can have a lot of benefits. The >IPsec secured virtual point-to-point link can be made visible to the >routing protocols, and we can run routing on that link to automatically >get the resiliency and all the other benefits provided by routing. No need >to run keepalives or DPDs, which only provide information of connectivity >to the IPsec gateways, and provide no information about the connectivity >to the traffic destination. We can route multicast traffic across the >point-to-point link too. Yes, we loose the limited access control that >IPsec provides, but any serious deployment would not soley depend on the >access control provided by IPsec. We obviously differ in our views of whether the access controls provided gy Ipsec are "limited" or not, and thus whether removing them entirely, as you suggest, and substituting a simple IP layer encryption and integrity service would be a good idea. >Isn't the simplicity derived from not having to negotiate traffic >selectors in a key management/establishment protocol and not having to do >the job of routing (DPD/Keepalive) and other benefits mentioned above >worth sacrificing the limited access control provided by IPsec? No. Steve From owner-ipsec@lists.tislabs.com Thu Apr 4 11:17: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 g34JHlm05211; Thu, 4 Apr 2002 11:17:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25346 Thu, 4 Apr 2002 13:15:31 -0500 (EST) From: "Stephane Beaulieu" To: "Ricky Charlet" , "Casey Carr" , Subject: RE: Dead peer detection Date: Thu, 4 Apr 2002 13:27:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <7B8824D690092B4B90B0EF4674750A65022DF5C2@USEXCH3.us.sonicwall.com> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Howdy, > > Hey, I was interested! Very early on I asked the draft authors > about their intentions and they told me to not implement the -00 draft > because they envisioned significant change. So I waited. (and > waited...). If we implemented the -00 draft, would we interoperate with > you? Well, as one of the authors, I can honestly say I don't recall that conversation. Yes, if you implemented -00, you would interoperate (well... hopefully at least ;). IOS, PIX, VPN3000, and our Client have all implemented the -00 draft seperately, and have had successful interop. Perhaps we can test at the next bakeoff? > > Any VPN vendor will run across the customer driven request for > tunnel-black-hole-detection and possibly for supporting alternative > tunnels to backup gateways. Dead peer detection (of some sort) is a > fundamental requirement for these. > > Yet End-to-End IPsec'ers see any DPD mechanism as dangerous > overhead and unnecessary complexity. Even among folks who want a > standardized DPD mechanism, disagreements over the driving requirements > (should it support site-to-site tunnels, should it support remote access > without interfering with accounting or PPP link keep alive, other > reasonable use cases may be envisioned) lead to opposing suggestions for > its implementation (in IKE, in ESP/AH, in the clear). > > I believe that of the people who are actually deploying home > grown solutions for DPD, this draft-ietf-ipsec-dpd-00.txt (with its > implementation in authenticated IKE exchanges) solves their problem set. > It solves our problem set. > > Also on the horizon it IKEv2 which has a DPD mechanism proposed > within it (thanks Kaufman and IKEv2 team). > > > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." Benjamin Franklin > > Ricky Charlet : rcharlet@sonciwall.com : usa (408) 962-8711 > > > > -----Original Message----- > > From: Stephane Beaulieu [mailto:stephane@cisco.com] > > Sent: Wednesday, April 03, 2002 1:51 PM > > To: Casey Carr; ipsec@lists.tislabs.com > > Subject: RE: Dead peer detection > > > > > > Hi Casey, > > > > There are 3 or 4 different ways of doing Dead Peer Detection > > that I am aware > > of. Cisco has an older method reffered to as Keepalives in our older > > releases of IOS, VPN3000, and PIX. It is undocumented (to the public) > > though I believe some of our partners have also implemented it. > > > > All of our newer releases support the DPD draft you > > referenced, and we are > > going to slowly deprecate keepalives. We published DPD in > > the IPsec WG in > > hopes to get it standardized. However, there hasn't been > > much interest > > which is why the draft has been idle. I think the WG chairs > > also decided > > that DPD was outside the scope of the WG because of the > > moratorium. I sent > > an email to Ted a few weeks ago asking whether we could try to go > > standards-track with it or if we should just go out as > > Informational. I'm > > still waiting for a response. > > > > I know that Nortel also has some scheme which addresses the > > same issues, > > though they apparently have a patent on it. > > > > I'm sure there are other proprietary versions which are > > probably all very > > simliar except for the bits on the wire. > > > > Hope this helps, > > Stephane. > > > > > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Casey Carr > > > Sent: Wednesday, April 03, 2002 3:22 PM > > > To: ipsec@lists.tislabs.com > > > Cc: IPSec Policy WG > > > Subject: FW: Dead peer detection > > > > > > > > > Sorry. I sent this to the IPSec Policy WG the first time > > by mistake. > > > > > > I think it more appropriate in the general IPSec WG. > > > > > > -----Original Message----- > > > From: Casey Carr [mailto:caseyc@cipheroptics.com] > > > Sent: Wednesday, April 03, 2002 2:24 PM > > > To: IPSec Policy WG > > > Subject: Dead peer detection > > > > > > > > > Is there an RFC or draft on standards track to deal with dead peer > > > detection? After spending some time reviewing the IPSec, IKE, > > > ISAKMP RFCs I > > > have drawn the conclusion that there is not a "standard" > > way to implement > > > dead peer detection. Have I reached a valid conclusion? > > Are other IPSec > > > vendors implementing proprietary solutions? If so, have there been > > > interoperability issues? > > > > > > I reviewed draft-ietf-ipsec-dpd-00.txt. It appears to be a year > > > old without > > > revisions which leads me to believe that it may not be > > widely accepted. > > > > > > It also appears from a statement in JFK that the authors regard > > > this as an > > > implementation issue: > > > > > > "A second major reason for Phase II is dead peer detection. IPsec > > > gateways often need to know if the other end of a > > security association > > > is dead, both to free up resources and to avoid "black holes". > > > In JFK, this is done by noting the time of the last > > packet received. > > > A peer that wishes to elicit a packet may send a "ping". Such > > > hosts MAY decline any proposed security associations that do not > > > permit such "ping" packets." > > > > > > > > > Thanks, > > > Casey > > > > > > > From owner-ipsec@lists.tislabs.com Thu Apr 4 12:15: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 g34KFYm09359; Thu, 4 Apr 2002 12:15:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25822 Thu, 4 Apr 2002 14:35:49 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15532.44528.656396.950623@ryijy.hel.fi.ssh.com> Date: Thu, 4 Apr 2002 22:48:00 +0300 From: Tero Kivinen To: vilhuber@cisco.com (Jan Vilhuber), CC: Paul Hoffman / VPNC Subject: Re: Do we actually need dynamic ports? X-Mailer: VM 6.89 under Emacs 20.7.1 References: Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk vilhuber@cisco.com (Jan Vilhuber) writes: > This is no different than creating a second SA, I suppose. You want > traffic for the FTP data channel? Create a new SA for > it. Alternatively, and this is what Pyda's and my draft does, pass an > indicator that identifies the previous SA, and ADD to it. Saves > memory, at almost no additional cost. Why have a special case for ADD and DELETE, why not simply renegotiate new SA with new set of selectors (i.e add new selectors, remove the ones you do not want), and when that new SA is ready, delete the old SA. I.e simply make ADD and DELETE to be rekey of the existing SA. For IKEv1 you could not do that, as there was no way to express the set of selectors, but with TS we can do that, so now that is an option. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Apr 4 12: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 g34KFjm09372; Thu, 4 Apr 2002 12:15:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25830 Thu, 4 Apr 2002 14:37:23 -0500 (EST) Date: Thu, 4 Apr 2002 11:48:56 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec mailling list Subject: Re: Is TS agreement necessary? 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, 4 Apr 2002, Stephen Kent wrote: > At 6:54 PM -0800 4/3/02, Chinna N.R. Pellacuru wrote: > >On Wed, 3 Apr 2002, Stephen Kent wrote: > >> Your descriptions have not yet convinced me, and others, that > >> interoperability is achieved and at no loss of access control > >> granularity. > >> > > > >I think we had a similar debate on this list about the access control > >granularity of IPsec, and what are the concequences of loosing it, when > >L2TP+IPsec (L2TP secured with IPsec to provide remote access) was > >discussed on this list a couple of years ago. > > > >First, we are talking about a peer that has successfully authenticated to > >us in phase1(or its equivalent), and we have successfully identified who > >the peer is. What is the point in someone strongly authenticating to us, > >and then attacking us using a secured channel which has traffic source > >authentication? > > the answer is that merely because we have authenticated a peer, that > does not mean that we are prepared to allow that peer to have > unconstrained access to all resources behind the IPsec > implementation, whether the implementation is at an enclave perimeter > or a single machine. what if one of the peers is an organization > that has just been compromised and thus traffic from that site is no > longer "friendly?" the point is that authentication and authorization > are distinct aspects of security and IPsec makes provisions to > support both, at variable granularities. Yes, all deployments should run a firewall and IDS even on traffic that was IPsec secured. No one should be under the assumption that just because some traffic was secured by IPsec, it is safe. So, all IPsec protected traffic should be subjected to rigorous firewall and IDS if people want serious security. If you hold the above thought, I'll digress a bit here. By the virtue of the attack traffic being secured by IPsec, which has traffic source authentication, it is much easy to react to an attack, because we know with strong cryptographic certainity where the traffic is coming from. There was a scheme that someone was proposing to use IPsec to counter DDOS attacks, based on this premise. This paragraph is a bit of digression from the debate at hand. > > >Secondly, isn't access control and intrusion detection much more than > >looking at src/dst IP address, transport protocol and port? Yes, IPsec > >provides limited access control, but how many deployments deem the access > >control provided by IPsec sufficient, and not run Firewalls and IDS > >systems, on all traffic, including the traffic that arrived/sent on IPsec > >tunnels. The limited access control provided by IPsec may sometimes even > >be regarded as a false sense of security, if people are not running a > >firewall/IDS on the traffic that is protected by IPsec. We often see IPsec > >and firewalls bundled as a single product, because if you want serious > >access control and IDS, you should be running a firewall. > > Access control and IDS can be effected at various layers in the > protocol stack. it is desirable to be able to enforce access control > at more than one layer and when doing this it is often appropriate to > distribute the enforcement to different devices, consistent with the > characteristics of each device. In the case of access controls based > on IP layer data, an IPsec implementation is an ideal location to > enforce such controls, consistent with the secure binding of > authentication data to the traffic, based on the SA via which the > traffic was received (looking) at this from a receiver's > perspective). Transport layer controls might be enforced elsewhere, > but, as with firewalls, it generally is convenient to perform the > enforcement at the same place and at the same time because of the > proximity of the header info. Also, if access controls for these two > closely related layers are enforced at different points in the > system, there is a need for closer coordination of the management of > the access control databases at those different points. > > I think the comments re IDS are irrelevant here. IPsec includes no > IDS provisions and we're not debating that functionality. > > With regard to firewalls, IPsec already provides the functions of a > stateless packet filtering firewall, so putting another one behind an > IPsec device would be redundant. If we enhance IPsec to provide > stateful packet filtering, still at the IP and transport layers, then > the range of redundant configurations is even bigger. I agree that an > IPsec device is not a substitute for an application later proxy > firewall, but your comments above do not specify what flavor of > firewall you are referring to, so it's hard to tell what argument you > are making. If one bundles IPsec and a firewall as a single product, > then a vendor has flexibility in offering the IPsec access controls > within that product; there is no need for redundancy, a topic we have > discussed many times in the past. Although it is desirable to enforce access control at more than one layer, it is not desirable to have layer violations. If IPsec wants to do access control, it should only rely on fields in the IP header, which are limited to IP source and destination address and protocol. IPsec should NOT rely on fields in the trasport layer headers like source and destination ports. I strongly object to this layer violation. I am profoundly concerned about the the degeneration of the IP stack due to all the layer violations, and we must avoid them. All the layer violations pollute the implemenations, and greatly reduces performance. IPsec should limit the packet filtering functionality to only fields in the IP header. In IPv6, even the protocol information is not available most (99.99%) of the time in the IPv6 header. We need to traverse the all the extension headers to get to the transport layer header and even to find out what the transport layer protocol is. So, even the transport layer protocol information isn't easily accessable in IPv6. This is a big drag on the IPv6 IPsec implementations and effect the performance immensely, if we need to do access control on the transport layer protocol information also. Even if the transport layer protocol information is in IPv6 extension header somewhere, it is not available in the IPv6 header almost all the time. So, why not get rid of that requirement too? Afterall the goal of IPv6 was to limit the intermediate gateways to have to look at only the IPv6 header, and as little as possible of the extention headers. We will end up with only having to do packet filtering based on IP source and IP destination address or take an enormous hit in performance if we require that even the transport protocol needs to be considered. > > >If an IPsec tunnel can be implemented in an interoperable manner to look > >like a virtual point-to-point link, it can have a lot of benefits. The > >IPsec secured virtual point-to-point link can be made visible to the > >routing protocols, and we can run routing on that link to automatically > >get the resiliency and all the other benefits provided by routing. No need > >to run keepalives or DPDs, which only provide information of connectivity > >to the IPsec gateways, and provide no information about the connectivity > >to the traffic destination. We can route multicast traffic across the > >point-to-point link too. Yes, we loose the limited access control that > >IPsec provides, but any serious deployment would not soley depend on the > >access control provided by IPsec. > > We obviously differ in our views of whether the access controls > provided gy Ipsec are "limited" or not, and thus whether removing > them entirely, as you suggest, and substituting a simple IP layer > encryption and integrity service would be a good idea. > Access control in IPsec should be limited to ideally only the IP source and destination addresses, and may be to the transport layer protocol in IPv4. I strongly object to any layer violations and hence limit the access control functionality of IPsec. Upper layers can implement their access control mechanisms with the full context available in those layers, and IPsec should not to do the job of access control for the upper layers too. It is redundant, inefficient, confusing and hard to manage if one layer is trying to do the job of all the layers. > >Isn't the simplicity derived from not having to negotiate traffic > >selectors in a key management/establishment protocol and not having to do > >the job of routing (DPD/Keepalive) and other benefits mentioned above > >worth sacrificing the limited access control provided by IPsec? > > No. > > Steve > We should get rid of layer violations. The limited access control provided by just looking at IP source and IP destination should be optional, because it is very limited in nature, and upper layers have more context about the user information etc, and can enforce a much rigourous access control. By claiming access control in IPsec, I think it is creating a false sense of security in the user community, and it is better if we can acknowledge that the access control provided by IPsec is infact limited, and people should run a real firewall if they are serious about access control. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Apr 4 12:35: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 g34KZZm09875; Thu, 4 Apr 2002 12:35:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25961 Thu, 4 Apr 2002 14:59:05 -0500 (EST) Date: Thu, 4 Apr 2002 12:10:41 -0800 (PST) From: Jan Vilhuber To: Tero Kivinen cc: , Paul Hoffman / VPNC Subject: Re: Do we actually need dynamic ports? In-Reply-To: <15532.44528.656396.950623@ryijy.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't mind that. I just had to go re-read ikev2 and realized that you CAN in fact to multiple discontiguous ranges (or ports as well as IP addresses, by simply having multiple 'Traffic Selector Substructure' sections (7.13.1 Traffic Selector Substructure). Cool. I like it. The only minor difference (and I'm not saying it's important) is that you have to go through 'more' computation to delete and add a new SA, rather than adding to it, but that may be minor and not an issue at all. In particular: using up 'precious' entropy by having to come up with new key material, having to create a new SPI (and associated IKE delete payloads), and possibly having to rebuild some internal tree for the SA's (depends on implementation). Simply adding some selectors to an existing SA and keeping keys and SPI, *seems* easier, but may not actually make that much difference. Paul proposed using a semantic where using the same 'SPI' in the proposal means that you are adding to the existing SPI. That could bear a closer look as well, although I think there's room for error there.. Negotiating a new SA, with new SPI, deleting the old one is certainly 'clean' even though it seems to involve a lot of steps. Are we going to try and fold some (not all) of the jenkins rekey-draft into IKEv2, so that rekey behaviour is spelled out precisely? That would certainly help. jan On Thu, 4 Apr 2002, Tero Kivinen wrote: > vilhuber@cisco.com (Jan Vilhuber) writes: > > This is no different than creating a second SA, I suppose. You want > > traffic for the FTP data channel? Create a new SA for > > it. Alternatively, and this is what Pyda's and my draft does, pass an > > indicator that identifies the previous SA, and ADD to it. Saves > > memory, at almost no additional cost. > > Why have a special case for ADD and DELETE, why not simply renegotiate > new SA with new set of selectors (i.e add new selectors, remove the > ones you do not want), and when that new SA is ready, delete the old > SA. I.e simply make ADD and DELETE to be rekey of the existing SA. > > For IKEv1 you could not do that, as there was no way to express the > set of selectors, but with TS we can do that, so now that is an > option. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Apr 4 12:37: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 g34Kbdm09917; Thu, 4 Apr 2002 12:37:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25977 Thu, 4 Apr 2002 15:04:02 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 4 Apr 2002 15:09:29 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: Is TS agreement necessary? Cc: ipsec mailling list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:48 AM -0800 4/4/02, Chinna N.R. Pellacuru wrote: >On Thu, 4 Apr 2002, Stephen Kent wrote: > >> At 6:54 PM -0800 4/3/02, Chinna N.R. Pellacuru wrote: >> >On Wed, 3 Apr 2002, Stephen Kent wrote: >> >> Your descriptions have not yet convinced me, and others, that >> >> interoperability is achieved and at no loss of access control >> >> granularity. >> >> >> > >> >I think we had a similar debate on this list about the access control >> >granularity of IPsec, and what are the concequences of loosing it, when >> >L2TP+IPsec (L2TP secured with IPsec to provide remote access) was >> >discussed on this list a couple of years ago. >> > >> >First, we are talking about a peer that has successfully authenticated to >> >us in phase1(or its equivalent), and we have successfully identified who >> >the peer is. What is the point in someone strongly authenticating to us, >> >and then attacking us using a secured channel which has traffic source >> >authentication? >> >> the answer is that merely because we have authenticated a peer, that >> does not mean that we are prepared to allow that peer to have >> unconstrained access to all resources behind the IPsec >> implementation, whether the implementation is at an enclave perimeter >> or a single machine. what if one of the peers is an organization >> that has just been compromised and thus traffic from that site is no >> longer "friendly?" the point is that authentication and authorization >> are distinct aspects of security and IPsec makes provisions to >> support both, at variable granularities. > >Yes, all deployments should run a firewall and IDS even on traffic that >was IPsec secured. No one should be under the assumption that just because >some traffic was secured by IPsec, it is safe. So, all IPsec protected >traffic should be subjected to rigorous firewall and IDS if people want >serious security. You have not provided any rationale for this statement. Unless you are assuming an IPsec implementation that is not making use of the access control facilities, your reasoning is not at all obviuous. >If you hold the above thought, I'll digress a bit here. By the virtue of >the attack traffic being secured by IPsec, which has traffic source >authentication, it is much easy to react to an attack, because we know >with strong cryptographic certainity where the traffic is coming from. >There was a scheme that someone was proposing to use IPsec to counter DDOS >attacks, based on this premise. This paragraph is a bit of digression from >the debate at hand. I agree that with authenticated traffic sources we're better off. > > >Secondly, isn't access control and intrusion detection much more than > > >looking at src/dst IP address, transport protocol and port? Yes, IPsec >> >provides limited access control, but how many deployments deem the access >> >control provided by IPsec sufficient, and not run Firewalls and IDS >> >systems, on all traffic, including the traffic that arrived/sent on IPsec >> >tunnels. The limited access control provided by IPsec may sometimes even >> >be regarded as a false sense of security, if people are not running a >> >firewall/IDS on the traffic that is protected by IPsec. We often see IPsec >> >and firewalls bundled as a single product, because if you want serious >> >access control and IDS, you should be running a firewall. >> >> Access control and IDS can be effected at various layers in the >> protocol stack. it is desirable to be able to enforce access control >> at more than one layer and when doing this it is often appropriate to >> distribute the enforcement to different devices, consistent with the >> characteristics of each device. In the case of access controls based >> on IP layer data, an IPsec implementation is an ideal location to >> enforce such controls, consistent with the secure binding of >> authentication data to the traffic, based on the SA via which the >> traffic was received (looking) at this from a receiver's > > perspective). Transport layer controls might be enforced elsewhere, >> but, as with firewalls, it generally is convenient to perform the >> enforcement at the same place and at the same time because of the >> proximity of the header info. Also, if access controls for these two > > closely related layers are enforced at different points in the >> system, there is a need for closer coordination of the management of >> the access control databases at those different points. >> >> I think the comments re IDS are irrelevant here. IPsec includes no >> IDS provisions and we're not debating that functionality. >> >> With regard to firewalls, IPsec already provides the functions of a >> stateless packet filtering firewall, so putting another one behind an >> IPsec device would be redundant. If we enhance IPsec to provide >> stateful packet filtering, still at the IP and transport layers, then >> the range of redundant configurations is even bigger. I agree that an >> IPsec device is not a substitute for an application later proxy >> firewall, but your comments above do not specify what flavor of >> firewall you are referring to, so it's hard to tell what argument you >> are making. If one bundles IPsec and a firewall as a single product, >> then a vendor has flexibility in offering the IPsec access controls >> within that product; there is no need for redundancy, a topic we have >> discussed many times in the past. > >Although it is desirable to enforce access control at more than one layer, >it is not desirable to have layer violations. If IPsec wants to do access >control, it should only rely on fields in the IP header, which are limited >to IP source and destination address and protocol. IPsec should NOT rely >on fields in the trasport layer headers like source and destination ports. >I strongly object to this layer violation. I am profoundly concerned about >the the degeneration of the IP stack due to all the layer violations, and >we must avoid them. All the layer violations pollute the implemenations, >and greatly reduces performance. If you strongly object to layer violations, then your employer should never offer "routers" that modify the TOS bits which were defined for end system use only (until we changed the definition), nor which try to classify traffic for diffserv purposes based on examining transport headers, and you should definitelu stop selling routers that implement NAT! I too am a big fan of layering, but firewalls often operate at multiple layers and decided long ago that there were good reasons (some of which I cited above) for providing firewall-style access controls in IPsec. >IPsec should limit the packet filtering functionality to only fields in >the IP header. > >In IPv6, even the protocol information is not available most (99.99%) of >the time in the IPv6 header. We need to traverse the all the extension >headers to get to the transport layer header and even to find out what the >transport layer protocol is. So, even the transport layer protocol >information isn't easily accessable in IPv6. This is a big drag on the >IPv6 IPsec implementations and effect the performance immensely, if we >need to do access control on the transport layer protocol information >also. Even if the transport layer protocol information is in IPv6 >extension header somewhere, it is not available in the IPv6 header almost >all the time. So, why not get rid of that requirement too? Afterall the >goal of IPv6 was to limit the intermediate gateways to have to look at >only the IPv6 header, and as little as possible of the extention headers. > >We will end up with only having to do packet filtering based on IP source >and IP destination address or take an enormous hit in performance if we >require that even the transport protocol needs to be considered. Yes, in the IPv6 environment it takes more effort to locate and process transport layer headers, but the extent of the performance impact will be a function of system design, just as it always is. > > >If an IPsec tunnel can be implemented in an interoperable manner to look > > >like a virtual point-to-point link, it can have a lot of benefits. The > > >IPsec secured virtual point-to-point link can be made visible to the >> >routing protocols, and we can run routing on that link to automatically >> >get the resiliency and all the other benefits provided by routing. No need >> >to run keepalives or DPDs, which only provide information of connectivity >> >to the IPsec gateways, and provide no information about the connectivity >> >to the traffic destination. We can route multicast traffic across the >> >point-to-point link too. Yes, we loose the limited access control that >> >IPsec provides, but any serious deployment would not soley depend on the >> >access control provided by IPsec. >> >> We obviously differ in our views of whether the access controls >> provided gy Ipsec are "limited" or not, and thus whether removing >> them entirely, as you suggest, and substituting a simple IP layer >> encryption and integrity service would be a good idea. >> > >Access control in IPsec should be limited to ideally only the IP source >and destination addresses, and may be to the transport layer protocol in >IPv4. I strongly object to any layer violations and hence limit the access >control functionality of IPsec. Upper layers can implement their access >control mechanisms with the full context available in those layers, and >IPsec should not to do the job of access control for the upper layers too. >It is redundant, inefficient, confusing and hard to manage if one layer >is trying to do the job of all the layers. see comments above. nothing you said here adds anything to your earlier comments. > > >Isn't the simplicity derived from not having to negotiate traffic >> >selectors in a key management/establishment protocol and not having to do >> >the job of routing (DPD/Keepalive) and other benefits mentioned above >> >worth sacrificing the limited access control provided by IPsec? >> >> No. >> >> Steve >> > >We should get rid of layer violations. The limited access control provided >by just looking at IP source and IP destination should be optional, >because it is very limited in nature, and upper layers have more context >about the user information etc, and can enforce a much rigourous access >control. By claiming access control in IPsec, I think it is creating a >false sense of security in the user community, and it is better if we can >acknowledge that the access control provided by IPsec is infact limited, >and people should run a real firewall if they are serious about access >control. I'll make a deal. You get cisco to stop selling products that violate layers in precisely the fashion you describe, a subset of which I gave as examples above, and I'll reconsider what I think is appropriate for IPsec security functionality. Steve From owner-ipsec@lists.tislabs.com Thu Apr 4 13:11: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 g34LBxm11175; Thu, 4 Apr 2002 13:11:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26183 Thu, 4 Apr 2002 15:35:33 -0500 (EST) Date: Thu, 4 Apr 2002 12:43:14 -0800 (PST) From: Jan Vilhuber To: Mike Ditto cc: , Subject: Re: Is TS agreement necessary? In-Reply-To: <200204032234.OAA09939@potomac.incog.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 3 Apr 2002, Mike Ditto wrote: > Stephen Kent wrote: > > we have adopted the selector mechanism, in part, to allow sites to > > make the decision of what granularity of traffic muxing on an SA is > > acceptable. this proposal takes away that capability and tries to > > substitute three options. It is not clear that this reduced > > flexibility will meet all requirements now and going forward. Also, > > I agree. But it's clear that the present model doesn't meet all > requirements now and going forward, Well from what I can tell not everyone agrees with your requirements. If you have a set of requirements that aren't included in http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt (which you of course have read, right?), then please write a new section and post it to the list and let's discuss whether the group agrees to these new requirements. jan > as demonstrated by the need to > make significant changes to IPsec for a new transport protocol. I > think it's a serious design flaw that IPsec standards and > implementations have to be changed to accomodate a new transport > protocol. My proposal would eliminate that dependency. > > > > the suggestion that "session" would be an implementation defined > > concept could pose serious interoperability problems, and it leaves > > prospective users wondering what will happen when their > > implementation interacts with another. > > I don't think so; see below. > > > >This way, if my implementation considers the control connection and the > > >data connections of an FTP session to be one "session", and the other > > >end considers those to be multiple distinct "sessions", there is still > > >interoperability. > > > > How? if the other end wants them to be separate sessions, won't it > > reject data traffic you send over the SA that was established first > > for control traffic? > > No, that's the core of this idea: the receiver trusts the sender to > make segregation decisions. If the peer starts sending you stuff that > your policy allows, but you weren't expecting to arrive on that > particular SA, adjust your expectations to match the sender's choice. > This guarantees interoperability even in the face of very different > implementations and their ideas of service and session. > > Suppose my implementation supports a new transport protocol which is, > say layered on top of UDP port 12345, and I want to segregate my > different sessions within that protocol on different SAs. It would be > nice if I could do that without changing IPsec and IKE and waiting for > the other end to upgrade its implementation. Of course if the other > end doesn't know about my special protocol, it won't do segregation > beyond what it knows (lumping all of UDP port 12345 together), but it > will interoperate and I can at least segregate my outbound traffic. > And if the other end does know about my new transport protocol > (perhaps it's running my implementation too), the desired behavior is > achieved without having to violate or update the IPsec standards. > > > > >It might be a good idea even to allow simple IPsec implementations > > >(e.g. for embedded use) not to implement traffic segregation, falling > > >back to "completely shared" SAs, in a transparently interoperable way. > > > > It's always easy to imagine limited functionality implementations of > > a protocol for restrictive environments that might otherwise have > > some difficulty implementing the full set of required functions for > > the protocol. 20 years ago we saw that in LANs, where some folks > > decided that computing the TCP checkusm was a waste of time for > > traffic that was local to their LAN. Adoption of standards always > > implies compromises; a standard is rarely the optimal way to > > implement a set of functions for the full range of environments in > > which it may be employed. > > Right. That's why I think it's a valuable property of my proposal > that interoperability is maintained without having to negotiate the > use of an optional feature... it just works if one side (or both) > decides to use completely shared SAs. > > > > >Does this meet the requirements of those who strongly believe in the > > >importance of this kind of traffic segregation? I'm not such a strong > > >believer; most of the scenarios I've heard where it's relevant seem to > > >have nearly identical weaknesses with and without traffic segregation, > > >or are better handled by assigning unique identities to the unique > > >users. But I'll take others' word that it's an important capability, > > >and ask such people whether this proposal is sufficient. > > > > In short, no. > > OK, why? Is it becuase you (as a user/policy administrator) really > don't trust the other end to do as much segregation as you want, and > you want it to be strictly enforced by your end? Because there would > be a possibility that the other end's implementation would lump more > things together than you expect? I can understand those complaints, > but to me, some vagueness in the details of traffic segregation is > a small price to pay for increased interoperability, simplicity, and > freedom of implementation choice. > > > -=] Mike [=- > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Apr 4 13:25: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 g34LPWm11662; Thu, 4 Apr 2002 13:25:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26288 Thu, 4 Apr 2002 15:47:21 -0500 (EST) Cc: Michael Thomas , ipsec@lists.tislabs.com, marcovici@lucent.com, Black_David@emc.com Message-Id: <200204041811.NAA00355@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Jari Arkko Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Date: Thu, 4 Apr 2002 13:07:31 -0500 X-Mailer: KMail [version 1.3.2] Original-Cc: Michael Thomas , ipsec@lists.tislabs.com, marcovici@lucent.com, Black_David@emc.com References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <200204031734.MAA27006@nwmail.wh.lucent.com> <3CAB39E1.7090902@kolumbus.fi> In-Reply-To: <3CAB39E1.7090902@kolumbus.fi> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA25217 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday 03 April 2002 12:20, Jari Arkko wrote: > > The description of the problem to solve seemed to be: > > > > 1. IPsec is preferred as protection mechanism, but > > 2. SA is established via IKEv1 and people don't want to pay this > > price. 3. So a lightweight "compact" protocol for establishing SA > > is needed, 4. but it must be defined as two peers must know how to > > negotiate. > > Uri, I'm not sure this was exactly the problem description. I'm > sure lots of people are willing to pay the price. Well, for those who're willing to use "full-power" of IKE (whatever version) - there is no problem, clearly. >The problem was > more about whether those folks who use manual keying would (a) be > vulnerable to replay attacks or (b) the existing application layer > sequence# would be used to protect also against this, even across > reboots. For these folks, perhaps a semi-protocol that does session key establishment might be good. Perhaps something like an "snmpEngineBoots" counter can be kept in NVRAM... 32 bits - not overly high cost even per-node. > While the subject of new key management protocols is very interesting > and even some new work might be useful there, I'm not sure the MIPv6 > case is the right application. There, we'd much rather use whatever > the mainstream internet key management protocol happens to be at any > specific time. I also think it is realistic to assume some folks will > be using manual keys, and could potentially expose themselves to > replay attacks. But that's fine as long those folks have been warned > about it. Point taken. -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Apr 4 13:25: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 g34LPgm11677; Thu, 4 Apr 2002 13:25:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26302 Thu, 4 Apr 2002 15:48:15 -0500 (EST) Cc: Michael Thomas , ipsec@lists.tislabs.com, marcovici@lucent.com Message-Id: <200204041839.NAA06796@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Jari Arkko Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Date: Thu, 4 Apr 2002 13:35:31 -0500 X-Mailer: KMail [version 1.3.2] Original-Cc: Michael Thomas , ipsec@lists.tislabs.com, marcovici@lucent.com References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <200204030446.XAA13831@nwmail.wh.lucent.com> <3CAB122B.8000505@kolumbus.fi> In-Reply-To: <3CAB122B.8000505@kolumbus.fi> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA25437 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday 03 April 2002 09:31, Jari Arkko wrote: > Instead, what the Mobile IPv6 folks wanted to do was to use IPsec > as-is for certain tasks. One of these tasks was protection of BUs > between the MN and the CN. Now, our options in regards to this are as > follows: > > 1. Require IPsec + IKE. No replay problem. > 2. Require at least IPsec, but keep IKE as optional. Don't add > any features for replay protection. Folks who don't use IKE > will suffer from the replay vulnerability. > 3. Require at least IPsec, optional IKE but add an application > layer feature for replay protection to prevent replays if > you happened to not have IKE. This was the DT-recommended > approach. > 4. Require at least IPSec and a TBD light weight key management > scheme, perhaps optional IKE in some cases. No application > layer features. Replay protection works perfectly for everyone. Given the constraints you've described - it looks like option 2 is the only viable choice. Thanks! -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Apr 4 13:29: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 g34LTmm11738; Thu, 4 Apr 2002 13:29:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26287 Thu, 4 Apr 2002 15:47:16 -0500 (EST) Cc: Michael Thomas , Jari Arkko , ipsec@lists.tislabs.com, marcovici@lucent.com, Black_David@emc.com Message-Id: <200204041832.NAA05665@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Michael Thomas Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Date: Thu, 4 Apr 2002 13:29:08 -0500 X-Mailer: KMail [version 1.3.2] Original-Cc: Michael Thomas , Jari Arkko , ipsec@lists.tislabs.com, marcovici@lucent.com, Black_David@emc.com References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF1A4@TNEXVS02.tahoenetworks.com> <200204031734.MAA27006@nwmail.wh.lucent.com> <15531.16691.268161.547825@thomasm-u1.cisco.com> In-Reply-To: <15531.16691.268161.547825@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA25367 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday 03 April 2002 12:51, Michael Thomas wrote: >> I don't think that "interoperability" is quite > the right word here. A mobile node and home agent > which run IPsec/IKE could be interoperable. > However, in practice unless I am part of that > domain, know the right authentication > mechanisms, etc, we might not be able to > mutually authenticate. Hmm, I see your point. But: > This is a deployment > issue, however, not an interoperability issue. Not quite, because if one implementation chose KINK and another - IKE, they won't be able to talk regardless. > Use of IKE, SOI, KINK, manualkey, manualkey+ > are all deployment isses, IMO. I disagree for the reason stated above. Where to get certs may be a deployment issue. Whether certs are supported, clearly is not just deployment... > .....I think it's quite reasonable for MIP to say > that something better than straight manual keys > is needed, but specifying how it's accomplished > shouldn't be a requirement any more than MIP > shouldn't be saying that you must implement IKE > with certs or IKE with pre-shared keys, or IKE > with AAA hacks, or whatever. Saying "must support IKE" implies a whole bunch, including support for certs and pre-shared keys. If you happened to implement IKE (as currently specified) without cert support, you just produced a non-conformant code. > > 1. "Negotiate on paper" - i.e. define most if not all the > > attributes of=20 SA that should satisfy usage criteriae (including > > the crypto suite). 2. Select a simple key agreement protocol (any > > Bellare-Rogaway=20 derivative should do nicely) - such as > > *interlocked* CHAP or AKA. 3. Specify all of the above in a generic > > draft. > > IMO, at the point you have to put a shared key > into both boxes, you might as well put the rest > of the information in there too. At the point > you want to start negotiating stuff, you've > already gone beyond "lightweight" IMHO :-) 1. You have to put something, period - be it a pre-shared key for IKE, or certs for IKE, or pre-shared key for something else. No way around it. Otherwise you won't be able to authenticate. 2. Negotiaton can be limited to auth and derivation of the key - sounds very light-weight to me. > > The above doesn't make sense, because you *have* to have something > > in NVRAM regardless. The question is - exactly what. And a > > simplified approach allows you to "memorize" less than IKE or > > JFK would require. > > You don't need *per node* permanent memory for > IKE/KINK/SOI. That's the difference. And where would you store the secrets that IKE/KINK/SOI require, if not in per-node permanent memory? -- Regards, Uri -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Apr 4 14:32: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 g34MWdm14290; Thu, 4 Apr 2002 14:32:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26821 Thu, 4 Apr 2002 16:53:05 -0500 (EST) Date: 4 Apr 2002 16:56:32 -0500 Message-ID: <000701c1dc23$95ced210$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Paul Hoffman / VPNC'" , " " Subject: RE: Fixing identity and cert-sending 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 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hmmm... no one replied to this message, probably because everyone agrees with it, or everyone disagrees with it, or some combination of both ;-) Since it appears that no one else is going to speak up, I will say that I like this idea, although you did leave out the fact that the old identity types need to be preserved in order to act as "policy matching hints", as we discussed earlier. > For ID types 3 and 4: the URL scheme must be http Does this support directories? If the URL points to a searchable directory that is accessed using a protocol other than HTTP, does the initiator still send the URL in this format and let the responder figure it out? Or would we need more id types (since the responder would have to signal willingness to use those protocols)? 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 Paul Hoffman / VPNC > Sent: Friday, March 29, 2002 1:45 PM > To: ipsec@lists.tislabs.com > Subject: Fixing identity and cert-sending > > > We have an opportunity in successor-to-IKE to fix two major > problems that > have plagued us in IKEv1: a misunderstanding about what is > identity, and > having to send certificates every time because you don't know if the > other party already has your certificate. > > This proposal (which could work in either IKEv2 or JFK) covers both > topics at once because it turns out that they are related. Suggestions > are welcome. > > The discussion below is for the successor-to-IKE proposals. Ignore > everything about today's cert, certrequest, and ID payloads; they will > not be used. > > Messages 1 and 2 MAY include a TrustedRoot payload. The TrustedRoot > payload includes a series of one or more PKIX keyIdentifiers of roots > trusted by the sender. This payload is completely optional and is > used only to inform the recipient of what capabilities the sender has. > > Messages 1 and 2 MUST include exactly one IDAccepted payload. > The payload > holds a series of one or more fields indicating the FullID > types that the > sender will accept. The receiver MUST NOT send any FullID > payloads that > are not listed in the sender's IDAccepted payload. > > Messages 3 and 4 MUST include exactly one FullID payload. The > payload's > format is an ID type followed by content. The ID types are: > > 1 PKIX cert -- A standalone PKIX cert. > 2 Cert bundle -- A simple ASN.1 sequence of PKIX certs. A bundle can > have end-entity certs or cert chains. The first cert > in the bundle > is the sender's preferred identity certificate, but beyond that > there is no meaning to the ordering. > 3 Hash-and-URL of PKIX cert -- The first 20 octets are the SHA-1 of a > certificate; the rest is a URL that resolves to the > cert. This is > described in more detail below. > 4 URL to a PKIX cert bundle -- This is described in more > detail below. > 5 PKIX keyIdentifier -- Identifies a self-signed certificate that the > receiver has already pre-loaded. Note that this is only > useful when > using self-signed certs. > 6 IDForSharedSecret -- This is only for use with shared > secrets. It is an > ASCII string (all octets are 31 < x < 127) of any length. > > For ID types 3 and 4: the URL scheme must be http, although > it can be on > any port, and there might be requirements for how the named > part looks. > The URL might be to a persistent repository, or it might be to the > initiating machine (such as in a remote access client). For > type 3, the > recipient might cache the cert with the hash as an index, or it can be > retrieved from the URL. > > If a system that is using certs knows that it cannot resolve > URLs (because it > is not yet on the Internet), it should use 1 and 2 in its > IDAccepted payload. > If a system can resolve URLs, it should use include type 3 > and 4. All systems > should be able to handle bundles because the other party > might have multiple > identities which have different certificates. > > There will be new error codes: > - Could not get your cert through the URL > - Could not get your cert bundle through the URL > - Bundle was malformed > - Could not find the cert that matches the keyIdentifier > - Could not use your IDForSharedSecret > > The authentication data needs to specify what kind of authentication > is being used (signed or HMACed). > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Thu Apr 4 14:32: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 g34MWdm14289; Thu, 4 Apr 2002 14:32:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26881 Thu, 4 Apr 2002 16:56:38 -0500 (EST) Date: Thu, 4 Apr 2002 14:07:59 -0800 (PST) From: Jan Vilhuber To: Uri Blumenthal cc: Michael Thomas , Jari Arkko , , , Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? In-Reply-To: <200204041832.NAA05665@nwmail.wh.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 4 Apr 2002, Uri Blumenthal wrote: > On Wednesday 03 April 2002 12:51, Michael Thomas wrote: > >> I don't think that "interoperability" is quite > > the right word here. A mobile node and home agent > > which run IPsec/IKE could be interoperable. > > However, in practice unless I am part of that > > domain, know the right authentication > > mechanisms, etc, we might not be able to > > mutually authenticate. > > Hmm, I see your point. But: > > > This is a deployment > > issue, however, not an interoperability issue. > > Not quite, because if one implementation chose KINK > and another - IKE, they won't be able to talk regardless. > And this was the reason whereby Radia finally convinced me that having multiple key negotiation protocols (like we have multiple routing protocols: Different situations require different routing protocols, so why not different keying protocols?) is not such a good thing afterall. For specific point-solutions (IP phones that can only talk to one call-manager, for example) or wherever all devices are under one administrative domain, having special keying protocols is OK. For the internet at large, where you don't necessarily know who you'll be talking to, not knowing what protocol you'll have to use is clearly not a good thing. I doubt MIPv6 falls within the 'under a single administrative domain' rule, so I'm a bit hesitant to declare that it could use a multitude of keying protocols, all up to the user to decide. If MIPv6 does fall into the 'single administrative domain' use, I'll stand corrected :) jan > > Use of IKE, SOI, KINK, manualkey, manualkey+ > > are all deployment isses, IMO. > > I disagree for the reason stated above. Where to get certs > may be a deployment issue. Whether certs are supported, > clearly is not just deployment... > > > .....I think it's quite reasonable for MIP to say > > that something better than straight manual keys > > is needed, but specifying how it's accomplished > > shouldn't be a requirement any more than MIP > > shouldn't be saying that you must implement IKE > > with certs or IKE with pre-shared keys, or IKE > > with AAA hacks, or whatever. > > Saying "must support IKE" implies a whole bunch, including > support for certs and pre-shared keys. If you happened to > implement IKE (as currently specified) without cert support, > you just produced a non-conformant code. > > > > > 1. "Negotiate on paper" - i.e. define most if not all the > > > attributes of=20 SA that should satisfy usage criteriae (including > > > the crypto suite). 2. Select a simple key agreement protocol (any > > > Bellare-Rogaway=20 derivative should do nicely) - such as > > > *interlocked* CHAP or AKA. 3. Specify all of the above in a generic > > > draft. > > > > IMO, at the point you have to put a shared key > > into both boxes, you might as well put the rest > > of the information in there too. At the point > > you want to start negotiating stuff, you've > > already gone beyond "lightweight" IMHO :-) > > 1. You have to put something, period - be it a pre-shared key for IKE, > or certs for IKE, or pre-shared key for something else. No way around > it. Otherwise you won't be able to authenticate. > > 2. Negotiaton can be limited to auth and derivation of the key - sounds > very light-weight to me. > > > > > The above doesn't make sense, because you *have* to have something > > > in NVRAM regardless. The question is - exactly what. And a > > > simplified approach allows you to "memorize" less than IKE or > > > JFK would require. > > > > You don't need *per node* permanent memory for > > IKE/KINK/SOI. That's the difference. > > And where would you store the secrets that IKE/KINK/SOI require, if not > in per-node permanent memory? > -- > Regards, > Uri > -=-=-<>-=-=- > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Apr 4 15:59:44 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 g34Nxhm17077; Thu, 4 Apr 2002 15:59:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27626 Thu, 4 Apr 2002 18:22:40 -0500 (EST) Date: Thu, 4 Apr 2002 15:34:14 -0800 (PST) From: Jan Vilhuber To: Paul Hoffman / VPNC cc: Tero Kivinen , Subject: Re: Do we actually need dynamic ports? 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, 4 Apr 2002, Paul Hoffman / VPNC wrote: > At 12:10 PM -0800 4/4/02, Jan Vilhuber wrote: > >The only minor difference (and I'm not saying it's important) is that > >you have to go through 'more' computation to delete and add a new SA, > >rather than adding to it, but that may be minor and not an issue at > >all. In particular: using up 'precious' entropy by having to come up > >with new key material, having to create a new SPI (and associated IKE > >delete payloads), and possibly having to rebuild some internal tree > >for the SA's (depends on implementation). Simply adding some selectors > >to an existing SA and keeping keys and SPI, *seems* easier, but may > >not actually make that much difference. > > This is an interesting question for IKE implementers: which would > make more sense to you? A bit hard to tell (or maybe not? Let's see what others say).. > - Keep a policy marker around and add or subtract relative to the marker > - Delete the old SA and create a new one when you want to add or subtract > The second doesn't require any new code, really. It reuses existing code (set up SA, delete Sa, send delete notify), but does raise some synchronization issues (which is why I asked about the jenkins-rekey draft). The prior may be less 'work', but more internal machinery. I'll try to find out for our implementation (I don't generally look at the IPsec code much :) jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Apr 4 15:59:44 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 g34Nxim17079; Thu, 4 Apr 2002 15:59:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27671 Thu, 4 Apr 2002 18:25:59 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <000701c1dc23$95ced210$1e72788a@ca.alcatel.com> References: <000701c1dc23$95ced210$1e72788a@ca.alcatel.com> Date: Thu, 4 Apr 2002 15:38:04 -0800 To: andrew.krywaniuk@alcatel.com, ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Fixing identity and cert-sending Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:56 PM -0500 4/4/02, Andrew Krywaniuk wrote: >Since it appears that no one else is going to speak up, I will say that I >like this idea, Thanks > although you did leave out the fact that the old identity >types need to be preserved in order to act as "policy matching hints", as we >discussed earlier. Er, we didn't discuss it in those terms. What I said was that it is completely up to the receiving system to determine the policy matching from the ID that it gets. In the case of a cert, the receiving system picks the ID-for-policy it wants from the identity or identities in the cert. For a shared secret, the receiving system needs some other way to decide how to map the identity to the policy. We could add a "preferred identity" payload for message 3 and 4, but it would be completely voluntary would need to be very clearly worded. > > For ID types 3 and 4: the URL scheme must be http > >Does this support directories? Yes, definitely. See draft-ietf-pkix-certstore-http-02.txt, which is making its way through the PKIX WG. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 4 16:02: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 g3502Fm17159; Thu, 4 Apr 2002 16:02:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27581 Thu, 4 Apr 2002 18:18:04 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 4 Apr 2002 15:29:13 -0800 To: Jan Vilhuber , Tero Kivinen From: Paul Hoffman / VPNC Subject: Re: Do we actually need dynamic ports? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:10 PM -0800 4/4/02, Jan Vilhuber wrote: >The only minor difference (and I'm not saying it's important) is that >you have to go through 'more' computation to delete and add a new SA, >rather than adding to it, but that may be minor and not an issue at >all. In particular: using up 'precious' entropy by having to come up >with new key material, having to create a new SPI (and associated IKE >delete payloads), and possibly having to rebuild some internal tree >for the SA's (depends on implementation). Simply adding some selectors >to an existing SA and keeping keys and SPI, *seems* easier, but may >not actually make that much difference. This is an interesting question for IKE implementers: which would make more sense to you? - Keep a policy marker around and add or subtract relative to the marker - Delete the old SA and create a new one when you want to add or subtract --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 4 16:39:15 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 g350dFm18211; Thu, 4 Apr 2002 16:39:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27979 Thu, 4 Apr 2002 19:06:25 -0500 (EST) Message-Id: <200204050018.g350IBn04632@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Do we actually need dynamic ports? In-reply-to: Your message of "Thu, 04 Apr 2002 12:10:41 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 04 Apr 2002 19:18:10 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jan" == Jan Vilhuber writes: Jan> to try and fold some (not all) of the jenkins rekey-draft into IKEv2, Jan> so that rekey behaviour is spelled out precisely? That would certainly Jan> help. Yes/no. Yes, we need clear rekeying text. I suggest that we should use the "use keys as soon as they negotiated" concept described in draft-spenser-implementation-*. ] 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 NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPKztQIqHRg3pndX9AQEVrgQAoynWtrVAN4neMNQksU4ZbCA0YsFMnbNY B1TXeQJjGJo8kZMmabJ+O+vNppHKeMhAUkeW2jUUd61UDMYlUwUc1ikdDPX58RoC eRnlzTKnuz3DgP6TzsGuAVJJ2zBj0hndN3Fz0gREU9Rq7NaAMz0prAiyM8qbou+O G8Qk3jtVfUU= =WsWC -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Apr 4 17:44: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 g351iKm19743; Thu, 4 Apr 2002 17:44:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28520 Thu, 4 Apr 2002 20:07:56 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B0458F79B@NS-CA> From: Michael Choung Shieh To: "'Jan Vilhuber'" , Tero Kivinen Cc: ipsec@lists.tislabs.com, Paul Hoffman / VPNC Subject: RE: Do we actually need dynamic ports? Date: Thu, 4 Apr 2002 17:18:33 -0800 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 Doing extra IKE to creat a new sa DURING application will introduce extra latency and it may cause packet drop or retransmit. It's probably not preferred if every FTP put/get will delay one or two seconds when passing through IKE. -------------------------------------------- Michael Shieh -------------------------------------------- -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Thursday, April 04, 2002 12:11 PM To: Tero Kivinen Cc: ipsec@lists.tislabs.com; Paul Hoffman / VPNC Subject: Re: Do we actually need dynamic ports? I don't mind that. I just had to go re-read ikev2 and realized that you CAN in fact to multiple discontiguous ranges (or ports as well as IP addresses, by simply having multiple 'Traffic Selector Substructure' sections (7.13.1 Traffic Selector Substructure). Cool. I like it. The only minor difference (and I'm not saying it's important) is that you have to go through 'more' computation to delete and add a new SA, rather than adding to it, but that may be minor and not an issue at all. In particular: using up 'precious' entropy by having to come up with new key material, having to create a new SPI (and associated IKE delete payloads), and possibly having to rebuild some internal tree for the SA's (depends on implementation). Simply adding some selectors to an existing SA and keeping keys and SPI, *seems* easier, but may not actually make that much difference. Paul proposed using a semantic where using the same 'SPI' in the proposal means that you are adding to the existing SPI. That could bear a closer look as well, although I think there's room for error there.. Negotiating a new SA, with new SPI, deleting the old one is certainly 'clean' even though it seems to involve a lot of steps. Are we going to try and fold some (not all) of the jenkins rekey-draft into IKEv2, so that rekey behaviour is spelled out precisely? That would certainly help. jan On Thu, 4 Apr 2002, Tero Kivinen wrote: > vilhuber@cisco.com (Jan Vilhuber) writes: > > This is no different than creating a second SA, I suppose. You want > > traffic for the FTP data channel? Create a new SA for > > it. Alternatively, and this is what Pyda's and my draft does, pass an > > indicator that identifies the previous SA, and ADD to it. Saves > > memory, at almost no additional cost. > > Why have a special case for ADD and DELETE, why not simply renegotiate > new SA with new set of selectors (i.e add new selectors, remove the > ones you do not want), and when that new SA is ready, delete the old > SA. I.e simply make ADD and DELETE to be rekey of the existing SA. > > For IKEv1 you could not do that, as there was no way to express the > set of selectors, but with TS we can do that, so now that is an > option. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Apr 4 17:47: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 g351lem19846; Thu, 4 Apr 2002 17:47:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28616 Thu, 4 Apr 2002 20:17:07 -0500 (EST) Date: Thu, 4 Apr 2002 17:28:44 -0800 (PST) From: Jan Vilhuber To: Michael Choung Shieh cc: Tero Kivinen , , Paul Hoffman / VPNC Subject: RE: Do we actually need dynamic ports? In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B0458F79B@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > Doing extra IKE to creat a new sa DURING application will introduce extra > latency and it may cause packet drop or retransmit. It's probably not > preferred if every FTP put/get will delay one or two seconds when passing > through IKE. > I don't think I'm going to reopen that discussion. We're talking about the option of: a) negotiate an 'update' to an SA or b) negotiate a new (expanded) SA and delete the old one In both cases you need an active phase 1 IKE SA. If you still have one around, no extra expense is incurred. If not, you'll need to add one. Doing this without negotiatiing something wasn't one of the proposed options. jan > -------------------------------------------- > Michael Shieh > -------------------------------------------- > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Thursday, April 04, 2002 12:11 PM > To: Tero Kivinen > Cc: ipsec@lists.tislabs.com; Paul Hoffman / VPNC > Subject: Re: Do we actually need dynamic ports? > > > I don't mind that. I just had to go re-read ikev2 and realized that > you CAN in fact to multiple discontiguous ranges (or ports as well as > IP addresses, by simply having multiple 'Traffic Selector > Substructure' sections (7.13.1 Traffic Selector Substructure). Cool. I > like it. > > The only minor difference (and I'm not saying it's important) is that > you have to go through 'more' computation to delete and add a new SA, > rather than adding to it, but that may be minor and not an issue at > all. In particular: using up 'precious' entropy by having to come up > with new key material, having to create a new SPI (and associated IKE > delete payloads), and possibly having to rebuild some internal tree > for the SA's (depends on implementation). Simply adding some selectors > to an existing SA and keeping keys and SPI, *seems* easier, but may > not actually make that much difference. > > Paul proposed using a semantic where using the same 'SPI' in the > proposal means that you are adding to the existing SPI. That could > bear a closer look as well, although I think there's room for error > there.. > > Negotiating a new SA, with new SPI, deleting the old one is certainly > 'clean' even though it seems to involve a lot of steps. Are we going > to try and fold some (not all) of the jenkins rekey-draft into IKEv2, > so that rekey behaviour is spelled out precisely? That would certainly > help. > > jan > > > > On Thu, 4 Apr 2002, Tero Kivinen wrote: > > > vilhuber@cisco.com (Jan Vilhuber) writes: > > > This is no different than creating a second SA, I suppose. You want > > > traffic for the FTP data channel? Create a new SA for > > > it. Alternatively, and this is what Pyda's and my draft does, pass an > > > indicator that identifies the previous SA, and ADD to it. Saves > > > memory, at almost no additional cost. > > > > Why have a special case for ADD and DELETE, why not simply renegotiate > > new SA with new set of selectors (i.e add new selectors, remove the > > ones you do not want), and when that new SA is ready, delete the old > > SA. I.e simply make ADD and DELETE to be rekey of the existing SA. > > > > For IKEv1 you could not do that, as there was no way to express the > > set of selectors, but with TS we can do that, so now that is an > > option. > > -- > > kivinen@ssh.fi > > SSH Communications Security http://www.ssh.fi/ > > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Apr 4 17:53: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 g351r9m19956; Thu, 4 Apr 2002 17:53:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28676 Thu, 4 Apr 2002 20:22:17 -0500 (EST) Date: Thu, 4 Apr 2002 17:33:55 -0800 (PST) From: Jan Vilhuber To: Michael Richardson cc: Subject: Re: Do we actually need dynamic ports? In-Reply-To: <200204050018.g350IBn04632@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 4 Apr 2002, Michael Richardson wrote: > >>>>> "Jan" == Jan Vilhuber writes: > Jan> to try and fold some (not all) of the jenkins rekey-draft into IKEv2, > Jan> so that rekey behaviour is spelled out precisely? That would certainly > Jan> help. > > Yes/no. > > Yes, we need clear rekeying text. > I suggest that we should use the "use keys as soon as they negotiated" > concept described in draft-spenser-implementation-*. > I agree, which is what the 'some (not all)' was for ;) I like most of the text in tim's draft (and like the philosophy even more, i.e. SPELL IT OUT DAMMIT), but never quite agreed with 'use the old one until it expires'. Are the IKEv2 authors planning on adding a rekey behaviour section? Or should someone suggest some text (probbaly lifted from tim's draft and draft-spenser-implementation)? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Apr 4 17:58: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 g351wUm20061; Thu, 4 Apr 2002 17:58:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28718 Thu, 4 Apr 2002 20:27:08 -0500 (EST) Date: Thu, 4 Apr 2002 17:38:37 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec mailling list Subject: Re: Is TS agreement necessary? 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, 4 Apr 2002, Stephen Kent wrote: > At 11:48 AM -0800 4/4/02, Chinna N.R. Pellacuru wrote: > >On Thu, 4 Apr 2002, Stephen Kent wrote: > > > >> At 6:54 PM -0800 4/3/02, Chinna N.R. Pellacuru wrote: > >> >On Wed, 3 Apr 2002, Stephen Kent wrote: > >> >> Your descriptions have not yet convinced me, and others, that > >> >> interoperability is achieved and at no loss of access control > >> >> granularity. > >> >> > >> > > >> >I think we had a similar debate on this list about the access control > >> >granularity of IPsec, and what are the concequences of loosing it, when > >> >L2TP+IPsec (L2TP secured with IPsec to provide remote access) was > >> >discussed on this list a couple of years ago. > >> > > >> >First, we are talking about a peer that has successfully authenticated to > >> >us in phase1(or its equivalent), and we have successfully identified who > >> >the peer is. What is the point in someone strongly authenticating to us, > >> >and then attacking us using a secured channel which has traffic source > >> >authentication? > >> > >> the answer is that merely because we have authenticated a peer, that > >> does not mean that we are prepared to allow that peer to have > >> unconstrained access to all resources behind the IPsec > >> implementation, whether the implementation is at an enclave perimeter > >> or a single machine. what if one of the peers is an organization > >> that has just been compromised and thus traffic from that site is no > >> longer "friendly?" the point is that authentication and authorization > >> are distinct aspects of security and IPsec makes provisions to > >> support both, at variable granularities. > > > >Yes, all deployments should run a firewall and IDS even on traffic that > >was IPsec secured. No one should be under the assumption that just because > >some traffic was secured by IPsec, it is safe. So, all IPsec protected > >traffic should be subjected to rigorous firewall and IDS if people want > >serious security. > > You have not provided any rationale for this statement. Unless you > are assuming an IPsec implementation that is not making use of the > access control facilities, your reasoning is not at all obviuous. OK. Let me take this oppurtunity to describe what I think a firewall and an Intrusion Detection System(IDS) should be able to do: Firewall- a device that does access control based on certain parameters. Parameters are what service (HTTP, Telnet, etc) and also parameters like direction of traffic, in/out etc. The list of parameters is very extensive. A stateless firewall, as the name suggests does access control based on the parameters, in a stateless way. There used to be some stateless firewalls that were being sold a long time ago, and are obsolete and deemed useless now. Some of the reasons for stateless firewalls becoming obsolete are: - statefull firewalls are orders of magnitude better than stateless firewalls in terms of security, because to prevent a large class of attacks, you need to maintain some state. - stateless firewalls are harder to configure, and manage because all the policies are statically determined, and cannot maintain any state. A statefull firewall can do Context Based Access Control (CBAC), and much easier to deploy. The policy could be as simple as allow only traffic that is initiated from the inside. So, a "hole" is "poked" in the firewall for all traffic that is initiated from the inside. There are "drop-in" (zero config) implementations of statefull firewalls. Intrusion Detection System (IDS) - detects any kind of malicious activity. The different classes of malicious activities are: - reconnaissance activity: Trying to find the network toplogy, what servers are running on which machines, what OS(vendor, version) each of the machine is running, what server implementation (vendor, version) is being used. Based on that information, the attacker can pick an attack that he is sure will work. - Denial of Service (DOS) attacks: TCP SYN flooding, IP fragment based, simple UDP, ICMP flooding, and the worst case Distributed DOS (DDOS), where the typical number of attack machines involved are upto 200,000. Blue Screen of Death (BSOD). - Gaining control and stealing/destroying data etc. The number of attack signatures taht can soley rely on IP source and IP destination is negligible. There are upto 500 signatures that the Cisco IDS solution implements, and some of the signatures are extremely CPU intensive, because most of the algorithms for identifying an attack are heuristic. So, in the grand scheme of things, stateless firewall capability is actually tending towards not having anything at all. If you want to do all this in IPsec, then everything will just grind to a halt. The specialized firewall and IDS boxes are built from the ground up, designed to do the specific job of a firewall and IDS. Bundling IPsec and firewall implementation on an end host does not mean that we can do that in all cases. It does not scale. In order to identify DDOS attacks, the whole network traffic needs to be considered, and the DDOS pattern needs to be picked up by looking all the traffic on the network. > > >If you hold the above thought, I'll digress a bit here. By the virtue of > >the attack traffic being secured by IPsec, which has traffic source > >authentication, it is much easy to react to an attack, because we know > >with strong cryptographic certainity where the traffic is coming from. > >There was a scheme that someone was proposing to use IPsec to counter DDOS > >attacks, based on this premise. This paragraph is a bit of digression from > >the debate at hand. > > I agree that with authenticated traffic sources we're better off. > > > > >Secondly, isn't access control and intrusion detection much more than > > > >looking at src/dst IP address, transport protocol and port? Yes, IPsec > >> >provides limited access control, but how many deployments deem the access > >> >control provided by IPsec sufficient, and not run Firewalls and IDS > >> >systems, on all traffic, including the traffic that arrived/sent on IPsec > >> >tunnels. The limited access control provided by IPsec may sometimes even > >> >be regarded as a false sense of security, if people are not running a > >> >firewall/IDS on the traffic that is protected by IPsec. We often see IPsec > >> >and firewalls bundled as a single product, because if you want serious > >> >access control and IDS, you should be running a firewall. > >> > >> Access control and IDS can be effected at various layers in the > >> protocol stack. it is desirable to be able to enforce access control > >> at more than one layer and when doing this it is often appropriate to > >> distribute the enforcement to different devices, consistent with the > >> characteristics of each device. In the case of access controls based > >> on IP layer data, an IPsec implementation is an ideal location to > >> enforce such controls, consistent with the secure binding of > >> authentication data to the traffic, based on the SA via which the > >> traffic was received (looking) at this from a receiver's > > > perspective). Transport layer controls might be enforced elsewhere, > >> but, as with firewalls, it generally is convenient to perform the > >> enforcement at the same place and at the same time because of the > >> proximity of the header info. Also, if access controls for these two > > > closely related layers are enforced at different points in the > >> system, there is a need for closer coordination of the management of > >> the access control databases at those different points. > >> > >> I think the comments re IDS are irrelevant here. IPsec includes no > >> IDS provisions and we're not debating that functionality. > >> > >> With regard to firewalls, IPsec already provides the functions of a > >> stateless packet filtering firewall, so putting another one behind an > >> IPsec device would be redundant. If we enhance IPsec to provide > >> stateful packet filtering, still at the IP and transport layers, then > >> the range of redundant configurations is even bigger. I agree that an > >> IPsec device is not a substitute for an application later proxy > >> firewall, but your comments above do not specify what flavor of > >> firewall you are referring to, so it's hard to tell what argument you > >> are making. If one bundles IPsec and a firewall as a single product, > >> then a vendor has flexibility in offering the IPsec access controls > >> within that product; there is no need for redundancy, a topic we have > >> discussed many times in the past. > > > >Although it is desirable to enforce access control at more than one layer, > >it is not desirable to have layer violations. If IPsec wants to do access > >control, it should only rely on fields in the IP header, which are limited > >to IP source and destination address and protocol. IPsec should NOT rely > >on fields in the trasport layer headers like source and destination ports. > >I strongly object to this layer violation. I am profoundly concerned about > >the the degeneration of the IP stack due to all the layer violations, and > >we must avoid them. All the layer violations pollute the implemenations, > >and greatly reduces performance. > > If you strongly object to layer violations, then your employer should > never offer "routers" that modify the TOS bits which were defined > for end system use only (until we changed the definition), nor which > try to classify traffic for diffserv purposes based on examining > transport headers, and you should definitelu stop selling routers > that implement NAT! > > I too am a big fan of layering, but firewalls often operate at > multiple layers and decided long ago that there were good reasons > (some of which I cited above) for providing firewall-style access > controls in IPsec. Stateless firewall-style access controls in IPsec are almost useless. We should stop claiming that in the best interest of the user community. If you are a big fan of layering, just go with your gut insticnt, if you don't want to listen to me, just for this time. > > >IPsec should limit the packet filtering functionality to only fields in > >the IP header. > > > >In IPv6, even the protocol information is not available most (99.99%) of > >the time in the IPv6 header. We need to traverse the all the extension > >headers to get to the transport layer header and even to find out what the > >transport layer protocol is. So, even the transport layer protocol > >information isn't easily accessable in IPv6. This is a big drag on the > >IPv6 IPsec implementations and effect the performance immensely, if we > >need to do access control on the transport layer protocol information > >also. Even if the transport layer protocol information is in IPv6 > >extension header somewhere, it is not available in the IPv6 header almost > >all the time. So, why not get rid of that requirement too? Afterall the > >goal of IPv6 was to limit the intermediate gateways to have to look at > >only the IPv6 header, and as little as possible of the extention headers. > > > >We will end up with only having to do packet filtering based on IP source > >and IP destination address or take an enormous hit in performance if we > >require that even the transport protocol needs to be considered. > > Yes, in the IPv6 environment it takes more effort to locate and > process transport layer headers, but the extent of the performance > impact will be a function of system design, just as it always is. > It tremendrously effects scalability and performance. If we don't have to do it, we get a big jump in what data rates can be sustained. Afterall that is the whole idea of IPv6 trying to restrict what fields intermediate routers need to bother about. End hosts or small systems are not effected by it very much, I agree. > > > >If an IPsec tunnel can be implemented in an interoperable manner to look > > > >like a virtual point-to-point link, it can have a lot of benefits. The > > > >IPsec secured virtual point-to-point link can be made visible to the > >> >routing protocols, and we can run routing on that link to automatically > >> >get the resiliency and all the other benefits provided by routing. No need > >> >to run keepalives or DPDs, which only provide information of connectivity > >> >to the IPsec gateways, and provide no information about the connectivity > >> >to the traffic destination. We can route multicast traffic across the > >> >point-to-point link too. Yes, we loose the limited access control that > >> >IPsec provides, but any serious deployment would not soley depend on the > >> >access control provided by IPsec. > >> > >> We obviously differ in our views of whether the access controls > >> provided gy Ipsec are "limited" or not, and thus whether removing > >> them entirely, as you suggest, and substituting a simple IP layer > >> encryption and integrity service would be a good idea. > >> > > > >Access control in IPsec should be limited to ideally only the IP source > >and destination addresses, and may be to the transport layer protocol in > >IPv4. I strongly object to any layer violations and hence limit the access > >control functionality of IPsec. Upper layers can implement their access > >control mechanisms with the full context available in those layers, and > >IPsec should not to do the job of access control for the upper layers too. > >It is redundant, inefficient, confusing and hard to manage if one layer > >is trying to do the job of all the layers. > > see comments above. nothing you said here adds anything to your > earlier comments. > I think I tried to articulate what I think a firewall and IDS is supposed to do, and why I feel the stateless firewall functionality that IPsec provides is useless. > > > >Isn't the simplicity derived from not having to negotiate traffic > >> >selectors in a key management/establishment protocol and not having to do > >> >the job of routing (DPD/Keepalive) and other benefits mentioned above > >> >worth sacrificing the limited access control provided by IPsec? > >> > >> No. > >> > >> Steve > >> > > > >We should get rid of layer violations. The limited access control provided > >by just looking at IP source and IP destination should be optional, > >because it is very limited in nature, and upper layers have more context > >about the user information etc, and can enforce a much rigourous access > >control. By claiming access control in IPsec, I think it is creating a > >false sense of security in the user community, and it is better if we can > >acknowledge that the access control provided by IPsec is infact limited, > >and people should run a real firewall if they are serious about access > >control. > > I'll make a deal. You get cisco to stop selling products that violate > layers in precisely the fashion you describe, a subset of which I > gave as examples above, and I'll reconsider what I think is > appropriate for IPsec security functionality. > > Steve > People do layer violations at their own peril. IETF should not try to recommend that. It should be optional at the worst. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Apr 4 19:28: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 g353Sum22189; Thu, 4 Apr 2002 19:28:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA29303 Thu, 4 Apr 2002 21:42:00 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 4 Apr 2002 18:54:05 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Do we actually need dynamic ports? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:44 PM -0800 4/4/02, Sankar Ramamoorthi wrote: > > -----Original Message----- >> From: Jan Vilhuber [mailto:vilhuber@cisco.com] >> Sent: Thursday, April 04, 2002 5:29 PM >> To: Michael Choung Shieh >> Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC >> Subject: RE: Do we actually need dynamic ports? >> > > >> On Thu, 4 Apr 2002, Michael Choung Shieh wrote: >> >> > >> > Doing extra IKE to creat a new sa DURING application will >> introduce extra >> > latency and it may cause packet drop or retransmit. It's >> probably not >> > preferred if every FTP put/get will delay one or two >> seconds when passing >> > through IKE. >> > >> >> I don't think I'm going to reopen that discussion. We're talking about >> the option of: >> >> a) negotiate an 'update' to an SA >> or >> b) negotiate a new (expanded) SA and delete the old one >> >> In both cases you need an active phase 1 IKE SA. If you still have one >> around, no extra expense is incurred. If not, you'll need to add one. >> >> Doing this without negotiatiing something wasn't one of the proposed >> options. > >proposed where? - I do not see it in the requirements document. >Are u implying the draft from pyada and you? No, in the (a) and (b) list that I proposed above. There has to be some negotiation: it isn't OK for the sender to say "I'm going to open up this port on your box because I want to and you can't do anything about it". >The requirement for minimizing the latency seems a genuine one, >particulary when using service based vpns - since the hit is now >potentially on every new connection. We are not talking about new connections here: we are talking about dynamically changing the policy in an existing SA to include more or fewer ports. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 4 21:22: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 g355Mpm24472; Thu, 4 Apr 2002 21:22:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA29961 Thu, 4 Apr 2002 23:29:21 -0500 (EST) Message-Id: <4.3.2.7.1.20020404203720.00b94e30@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Apr 2002 20:39:28 -0800 To: Mike Ditto , skelly@SonicWALL.com From: Ramana Yarlagadda Subject: Re: Is TS agreement necessary? Cc: ipsec@lists.tislabs.com In-Reply-To: <200204032001.MAA09886@potomac.incog.com> References: <3CAB3CCE.68852E3C@sonicwall.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:01 PM 4/3/02 -0800, Mike Ditto wrote: >"Scott G. Kelly" wrote: > > Suppose, as you suggest, that we allowed negotiation of multiple SAs > > between two peers without specifying TS values. Ultimately, there must > > be *some* policy rule associated with each of these SAs since, as you > > suggest, the point is to somehow segregate traffic between them. That > > is, for a given SA, some traffic is allowed, and some is not. Please > > elaborate upon how we determine which traffic is appropriate for each SA > > once they are established. > >OK. At the time of sending a packet, the SA lookup would work basically >the same as it does currently; the SPD and SAD would determine which SA >is used. I'm not proposing removing selectors from the SAD, I'm just >proposing that the selectors aren't sent explicitly in SA establishment. > >When I initiate SA negotiation, I get to decide what goes in the >selectors on my end, just like current IKE implementations. What's >different is how the selectors are set up for SAs that were requested by >my peer. When my peer asks me to add an SA pair to my SAD, I mark the >SAs as "completely shared", "address unique" or "session unique" as my >peer requests. If it's "completely shared" then I add a completely >wildcarded selector to the outbound SA. If it's one of the "unique" >styles, I don't add any selectors and I will never use the outbound SA >until the peer has sent me some traffic on the inbound one. What will be the Selector values, for incoming SA at this point. At the initiator and at the responder? >Whenever I receive traffic on an inbound SA I add the corresponding >selectors to the matching outbound SA. If the SA (pair) is "address >unique" I add to the outbound SA a destination address selector using >the packet's (inner) source address. If the SA (pair) is "session >unique" then I add to the outbound SA a selector that describes my >concept of a session for that protocol (the easiest definition of >session for RFC2401-style implementations would be to use port numbers). >But the ends don't have to agree on the exact definition of a session. > >An implementation is still able to use selectors on inbound SAs to >efficiently validate inbound traffic. When an inbound packet doesn't >match the inbound SA's selectors, the SPD is checked and if the packet >is allowed, the appropriate selectors are added to the inbound and >outbound SAs. > >The core idea of this proposal, the thing that makes interoperability >possible without agreement on the definition of a session, is that the >sender of each packet is free to choose between multiple equivalent SAs >however it sees convenient to implement, and the receiver accepts the >decision as long as the chosen SA matches the security parameters. When >establishing SAs, the initiator gives an abstract hint to the responder >about the desired granularity of segregation. > > > > As an aside, can you tell us why wildcard TS values do not satisfy your > > requirements in the same way that omitting TS values would? > >I think wildcard TS values would satisfy my requirements if I was >allowed to ignore any non-wildcard selectors sent to me, and if I >didn't want to implement traffic segregation. > From owner-ipsec@lists.tislabs.com Thu Apr 4 22:13: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 g356D1m27369; Thu, 4 Apr 2002 22:13:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA00436 Fri, 5 Apr 2002 00:33:50 -0500 (EST) From: haoward.dev@x263.net To: announce@lists.freeswan.org, ipsec-request@lists.tislabs.com, ipsec@lists.tislabs.com Subject: How IPSec call encryption arithmetic Date: Fri, 5 Apr 2002 13:46:30 +0800 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 X-Mailer: XMail-1.0 Content-Type: text/plain; charset="gb2312" Message-Id: <20020405054600.67BD6503CE@mx01.x263.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id AAA00426 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, Who knows the port where IPSec call its encryption arithmetic? Odyssey_____________________________________________________ 263ÔÚÏß_ÖйúÈ˵ÄÍøÉϼÒÔ° Tel:010-64262631 (c)1998-2002°æȨËùÓÐ 263ÌìÏÂÓÊ·þÎñÈÈÏß 263online@263.net.cn From owner-ipsec@lists.tislabs.com Thu Apr 4 22:19: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 g356JNm27501; Thu, 4 Apr 2002 22:19:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA00526 Fri, 5 Apr 2002 00:44:57 -0500 (EST) Date: Thu, 4 Apr 2002 21:56:35 -0800 (PST) From: Jan Vilhuber To: Sankar Ramamoorthi cc: Michael Choung Shieh , Tero Kivinen , , Paul Hoffman / VPNC Subject: RE: Do we actually need dynamic ports? 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, 4 Apr 2002, Sankar Ramamoorthi wrote: > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Thursday, April 04, 2002 5:29 PM > > To: Michael Choung Shieh > > Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC > > Subject: RE: Do we actually need dynamic ports? > > > > > > On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > > > > > > > Doing extra IKE to creat a new sa DURING application will > > introduce extra > > > latency and it may cause packet drop or retransmit. It's > > probably not > > > preferred if every FTP put/get will delay one or two > > seconds when passing > > > through IKE. > > > > > > > I don't think I'm going to reopen that discussion. We're talking about > > the option of: > > > > a) negotiate an 'update' to an SA > > or > > b) negotiate a new (expanded) SA and delete the old one > > > > In both cases you need an active phase 1 IKE SA. If you still have one > > around, no extra expense is incurred. If not, you'll need to add one. > > > > Doing this without negotiatiing something wasn't one of the proposed > > options. > > proposed where? - I do not see it in the requirements document. > Are u implying the draft from pyada and you? > Proposed by this thread. jan > The requirement for minimizing the latency seems a genuine one, > particulary when using service based vpns - since the hit is now > potentially on every new connection. > > > > > > jan > > > > > > > -------------------------------------------- > > > Michael Shieh > > > -------------------------------------------- > > > > > > -----Original Message----- > > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > > Sent: Thursday, April 04, 2002 12:11 PM > > > To: Tero Kivinen > > > Cc: ipsec@lists.tislabs.com; Paul Hoffman / VPNC > > > Subject: Re: Do we actually need dynamic ports? > > > > > > > > > I don't mind that. I just had to go re-read ikev2 and realized that > > > you CAN in fact to multiple discontiguous ranges (or ports > > as well as > > > IP addresses, by simply having multiple 'Traffic Selector > > > Substructure' sections (7.13.1 Traffic Selector > > Substructure). Cool. I > > > like it. > > > > > > The only minor difference (and I'm not saying it's > > important) is that > > > you have to go through 'more' computation to delete and add > > a new SA, > > > rather than adding to it, but that may be minor and not an issue at > > > all. In particular: using up 'precious' entropy by having to come up > > > with new key material, having to create a new SPI (and > > associated IKE > > > delete payloads), and possibly having to rebuild some internal tree > > > for the SA's (depends on implementation). Simply adding > > some selectors > > > to an existing SA and keeping keys and SPI, *seems* easier, but may > > > not actually make that much difference. > > > > > > Paul proposed using a semantic where using the same 'SPI' in the > > > proposal means that you are adding to the existing SPI. That could > > > bear a closer look as well, although I think there's room for error > > > there.. > > > > > > Negotiating a new SA, with new SPI, deleting the old one is > > certainly > > > 'clean' even though it seems to involve a lot of steps. Are we going > > > to try and fold some (not all) of the jenkins rekey-draft > > into IKEv2, > > > so that rekey behaviour is spelled out precisely? That > > would certainly > > > help. > > > > > > jan > > > > > > > > > > > > On Thu, 4 Apr 2002, Tero Kivinen wrote: > > > > > > > vilhuber@cisco.com (Jan Vilhuber) writes: > > > > > This is no different than creating a second SA, I > > suppose. You want > > > > > traffic for the FTP data channel? Create a new SA for > > > > > it. Alternatively, and this is what Pyda's and my draft > > does, pass an > > > > > indicator that identifies the previous SA, and ADD to it. Saves > > > > > memory, at almost no additional cost. > > > > > > > > Why have a special case for ADD and DELETE, why not > > simply renegotiate > > > > new SA with new set of selectors (i.e add new selectors, > > remove the > > > > ones you do not want), and when that new SA is ready, > > delete the old > > > > SA. I.e simply make ADD and DELETE to be rekey of the existing SA. > > > > > > > > For IKEv1 you could not do that, as there was no way to > > express the > > > > set of selectors, but with TS we can do that, so now that is an > > > > option. > > > > -- > > > > kivinen@ssh.fi > > > > SSH Communications Security http://www.ssh.fi/ > > > > SSH IPSEC Toolkit > > http://www.ssh.fi/ipsec/ > > > > > > > > > > -- > > > Jan Vilhuber > > vilhuber@cisco.com > > > Cisco Systems, San Jose > > (408) 527-0847 > > > > > > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Apr 5 00:00: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 g3580om10795; Fri, 5 Apr 2002 00:00:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01147 Fri, 5 Apr 2002 02:22:45 -0500 (EST) Message-ID: <9D048F4A422CD411A56500B0D0209C5B0458F7A0@NS-CA> From: Michael Choung Shieh To: "'Jan Vilhuber '" , Michael Choung Shieh Cc: "'Tero Kivinen '" , "'ipsec@lists.tislabs.com '" , "'Paul Hoffman / VPNC '" Subject: RE: Do we actually need dynamic ports? Date: Thu, 4 Apr 2002 23:33:22 -0800 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 Option (b) is to "negotiate a new (expanded) SA" and introduce extra lantency. You don't need to reopen any discussion. However, I guess you recognize it adds more or less lantency to both options. Michael Shieh -----Original Message----- From: Jan Vilhuber To: Michael Choung Shieh Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC Sent: 4/4/02 5:28 PM Subject: RE: Do we actually need dynamic ports? On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > Doing extra IKE to creat a new sa DURING application will introduce extra > latency and it may cause packet drop or retransmit. It's probably not > preferred if every FTP put/get will delay one or two seconds when passing > through IKE. > I don't think I'm going to reopen that discussion. We're talking about the option of: a) negotiate an 'update' to an SA or b) negotiate a new (expanded) SA and delete the old one In both cases you need an active phase 1 IKE SA. If you still have one around, no extra expense is incurred. If not, you'll need to add one. Doing this without negotiatiing something wasn't one of the proposed options. jan > -------------------------------------------- > Michael Shieh > -------------------------------------------- > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Thursday, April 04, 2002 12:11 PM > To: Tero Kivinen > Cc: ipsec@lists.tislabs.com; Paul Hoffman / VPNC > Subject: Re: Do we actually need dynamic ports? > > > I don't mind that. I just had to go re-read ikev2 and realized that > you CAN in fact to multiple discontiguous ranges (or ports as well as > IP addresses, by simply having multiple 'Traffic Selector > Substructure' sections (7.13.1 Traffic Selector Substructure). Cool. I > like it. > > The only minor difference (and I'm not saying it's important) is that > you have to go through 'more' computation to delete and add a new SA, > rather than adding to it, but that may be minor and not an issue at > all. In particular: using up 'precious' entropy by having to come up > with new key material, having to create a new SPI (and associated IKE > delete payloads), and possibly having to rebuild some internal tree > for the SA's (depends on implementation). Simply adding some selectors > to an existing SA and keeping keys and SPI, *seems* easier, but may > not actually make that much difference. > > Paul proposed using a semantic where using the same 'SPI' in the > proposal means that you are adding to the existing SPI. That could > bear a closer look as well, although I think there's room for error > there.. > > Negotiating a new SA, with new SPI, deleting the old one is certainly > 'clean' even though it seems to involve a lot of steps. Are we going > to try and fold some (not all) of the jenkins rekey-draft into IKEv2, > so that rekey behaviour is spelled out precisely? That would certainly > help. > > jan > > > > On Thu, 4 Apr 2002, Tero Kivinen wrote: > > > vilhuber@cisco.com (Jan Vilhuber) writes: > > > This is no different than creating a second SA, I suppose. You want > > > traffic for the FTP data channel? Create a new SA for > > > it. Alternatively, and this is what Pyda's and my draft does, pass an > > > indicator that identifies the previous SA, and ADD to it. Saves > > > memory, at almost no additional cost. > > > > Why have a special case for ADD and DELETE, why not simply renegotiate > > new SA with new set of selectors (i.e add new selectors, remove the > > ones you do not want), and when that new SA is ready, delete the old > > SA. I.e simply make ADD and DELETE to be rekey of the existing SA. > > > > For IKEv1 you could not do that, as there was no way to express the > > set of selectors, but with TS we can do that, so now that is an > > option. > > -- > > kivinen@ssh.fi > > SSH Communications Security http://www.ssh.fi/ > > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Apr 5 04:36: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 g35Cagm10234; Fri, 5 Apr 2002 04:36:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA02996 Fri, 5 Apr 2002 06:48:45 -0500 (EST) Message-ID: <000801c1dbd2$7af869c0$ae0510ac@roc.com> From: "Lokesh" To: "IPsec Mailing List" Subject: use of IV Date: Thu, 4 Apr 2002 17:45:56 +0530 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1DC00.93162FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1DC00.93162FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Can anybody would help me in understanding How IV makes cryptanalysis = difficult? It is said, it introduces more degree of randomness in cipher text. But = in ESP,=20 we send IV too along with cipher text, so cryptanalyst can always use it = for cracking cipher text right? can anybody point me to right article or document on internet about this = subject? Thanks Lokesh ------=_NextPart_000_0005_01C1DC00.93162FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
Can anybody would help me in = understanding How IV=20 makes cryptanalysis difficult?
It is said, it introduces more degree = of randomness=20 in cipher text. But in ESP, =
we send IV too along with cipher text, = so=20 cryptanalyst can always use it for cracking cipher text = right?
can anybody point me to right article = or document=20 on internet about this subject?
Thanks
Lokesh
------=_NextPart_000_0005_01C1DC00.93162FA0-- From owner-ipsec@lists.tislabs.com Fri Apr 5 05:11: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 g35DBjm11460; Fri, 5 Apr 2002 05:11:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03314 Fri, 5 Apr 2002 07:33:36 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15533.40060.512443.402524@ryijy.hel.fi.ssh.com> Date: Fri, 5 Apr 2002 15:45:48 +0300 From: Tero Kivinen To: Jan Vilhuber Cc: , Paul Hoffman / VPNC Subject: Re: Do we actually need dynamic ports? In-Reply-To: References: <15532.44528.656396.950623@ryijy.hel.fi.ssh.com> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > The only minor difference (and I'm not saying it's important) is that > you have to go through 'more' computation to delete and add a new SA, > rather than adding to it, but that may be minor and not an issue at > all. In particular: using up 'precious' entropy by having to come up > with new key material, having to create a new SPI (and associated IKE > delete payloads), and possibly having to rebuild some internal tree > for the SA's (depends on implementation). Simply adding some selectors > to an existing SA and keeping keys and SPI, *seems* easier, but may > not actually make that much difference. Adding might be easier in some environments, and impossible or very difficult in some environments (if all SA state is implemented in hardware, and the hardware does not support adding of SPIs). Also add requires changes to the API/protocol etc used between the IKE and the IPsec, where rekeying and delete fit in the current usage already. > Paul proposed using a semantic where using the same 'SPI' in the > proposal means that you are adding to the existing SPI. That could > bear a closer look as well, although I think there's room for error > there.. I tought that too, but as the responder can only select subset of the selectors proposed to it, that could cause more trouble than it is worth... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Apr 5 05:13: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 g35DDWm11501; Fri, 5 Apr 2002 05:13:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03400 Fri, 5 Apr 2002 07:39:38 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15533.40423.56396.303421@ryijy.hel.fi.ssh.com> Date: Fri, 5 Apr 2002 15:51:51 +0300 From: Tero Kivinen To: Michael Choung Shieh Cc: "'Jan Vilhuber'" , ipsec@lists.tislabs.com, Paul Hoffman / VPNC Subject: RE: Do we actually need dynamic ports? In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B0458F79B@NS-CA> References: <9D048F4A422CD411A56500B0D0209C5B0458F79B@NS-CA> X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Choung Shieh writes: > Doing extra IKE to creat a new sa DURING application will introduce extra > latency and it may cause packet drop or retransmit. It's probably not Yes, it requires about one round trip latency. You send IKE QM packet out, and get reply to it. The crypto processing for both packets is simply symmetric decrypt/encrypt and little bit of hashing. > preferred if every FTP put/get will delay one or two seconds when passing > through IKE. If you are doing that over satelite link then it will be one or two seconds (actually two seconds requires more than one satelite link). If you are doing it over normal internet it requires about 10-300 ms (to www.cisco.com from Finland it seems to be about 192 ms now). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Apr 5 05:34: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 g35DYrm11960; Fri, 5 Apr 2002 05:34:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03572 Fri, 5 Apr 2002 07:58:25 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Do we actually need dynamic ports? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 4 Apr 2002 18:44:29 -0800 Message-ID: Thread-Topic: Do we actually need dynamic ports? Thread-Index: AcHcR5H47O8lRinbQL2MQLLWDqVXlgAAPFsg From: "Sankar Ramamoorthi" To: "Jan Vilhuber" , "Michael Choung Shieh" Cc: "Tero Kivinen" , , "Paul Hoffman / VPNC" X-OriginalArrivalTime: 05 Apr 2002 02:44:30.0078 (UTC) FILETIME=[CF3F61E0:01C1DC4B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id VAA29272 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Thursday, April 04, 2002 5:29 PM > To: Michael Choung Shieh > Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC > Subject: RE: Do we actually need dynamic ports? > > > On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > > > > Doing extra IKE to creat a new sa DURING application will > introduce extra > > latency and it may cause packet drop or retransmit. It's > probably not > > preferred if every FTP put/get will delay one or two > seconds when passing > > through IKE. > > > > I don't think I'm going to reopen that discussion. We're talking about > the option of: > > a) negotiate an 'update' to an SA > or > b) negotiate a new (expanded) SA and delete the old one > > In both cases you need an active phase 1 IKE SA. If you still have one > around, no extra expense is incurred. If not, you'll need to add one. > > Doing this without negotiatiing something wasn't one of the proposed > options. proposed where? - I do not see it in the requirements document. Are u implying the draft from pyada and you? The requirement for minimizing the latency seems a genuine one, particulary when using service based vpns - since the hit is now potentially on every new connection. > > jan > > > > -------------------------------------------- > > Michael Shieh > > -------------------------------------------- > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Thursday, April 04, 2002 12:11 PM > > To: Tero Kivinen > > Cc: ipsec@lists.tislabs.com; Paul Hoffman / VPNC > > Subject: Re: Do we actually need dynamic ports? > > > > > > I don't mind that. I just had to go re-read ikev2 and realized that > > you CAN in fact to multiple discontiguous ranges (or ports > as well as > > IP addresses, by simply having multiple 'Traffic Selector > > Substructure' sections (7.13.1 Traffic Selector > Substructure). Cool. I > > like it. > > > > The only minor difference (and I'm not saying it's > important) is that > > you have to go through 'more' computation to delete and add > a new SA, > > rather than adding to it, but that may be minor and not an issue at > > all. In particular: using up 'precious' entropy by having to come up > > with new key material, having to create a new SPI (and > associated IKE > > delete payloads), and possibly having to rebuild some internal tree > > for the SA's (depends on implementation). Simply adding > some selectors > > to an existing SA and keeping keys and SPI, *seems* easier, but may > > not actually make that much difference. > > > > Paul proposed using a semantic where using the same 'SPI' in the > > proposal means that you are adding to the existing SPI. That could > > bear a closer look as well, although I think there's room for error > > there.. > > > > Negotiating a new SA, with new SPI, deleting the old one is > certainly > > 'clean' even though it seems to involve a lot of steps. Are we going > > to try and fold some (not all) of the jenkins rekey-draft > into IKEv2, > > so that rekey behaviour is spelled out precisely? That > would certainly > > help. > > > > jan > > > > > > > > On Thu, 4 Apr 2002, Tero Kivinen wrote: > > > > > vilhuber@cisco.com (Jan Vilhuber) writes: > > > > This is no different than creating a second SA, I > suppose. You want > > > > traffic for the FTP data channel? Create a new SA for > > > > it. Alternatively, and this is what Pyda's and my draft > does, pass an > > > > indicator that identifies the previous SA, and ADD to it. Saves > > > > memory, at almost no additional cost. > > > > > > Why have a special case for ADD and DELETE, why not > simply renegotiate > > > new SA with new set of selectors (i.e add new selectors, > remove the > > > ones you do not want), and when that new SA is ready, > delete the old > > > SA. I.e simply make ADD and DELETE to be rekey of the existing SA. > > > > > > For IKEv1 you could not do that, as there was no way to > express the > > > set of selectors, but with TS we can do that, so now that is an > > > option. > > > -- > > > kivinen@ssh.fi > > > SSH Communications Security http://www.ssh.fi/ > > > SSH IPSEC Toolkit > http://www.ssh.fi/ipsec/ > > > > > > > -- > > Jan Vilhuber > vilhuber@cisco.com > > Cisco Systems, San Jose > (408) 527-0847 > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Fri Apr 5 05:34: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 g35DYum11972; Fri, 5 Apr 2002 05:34:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03573 Fri, 5 Apr 2002 07:58:25 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Do we actually need dynamic ports? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 4 Apr 2002 20:04:42 -0800 Message-ID: Thread-Topic: Do we actually need dynamic ports? Thread-Index: AcHcVMulBzc2jKL4TvG3zRz/3vTs2QAAOY8A From: "Sankar Ramamoorthi" To: "Paul Hoffman / VPNC" , X-OriginalArrivalTime: 05 Apr 2002 04:04:42.0820 (UTC) FILETIME=[03DD8840:01C1DC57] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id WAA29794 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, April 04, 2002 6:54 PM > To: ipsec@lists.tislabs.com > Subject: RE: Do we actually need dynamic ports? > > > At 6:44 PM -0800 4/4/02, Sankar Ramamoorthi wrote: > > > -----Original Message----- > >> From: Jan Vilhuber [mailto:vilhuber@cisco.com] > >> Sent: Thursday, April 04, 2002 5:29 PM > >> To: Michael Choung Shieh > >> Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC > >> Subject: RE: Do we actually need dynamic ports? > >> > > > > >> On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > >> > >> > > >> > Doing extra IKE to creat a new sa DURING application will > >> introduce extra > >> > latency and it may cause packet drop or retransmit. It's > >> probably not > >> > preferred if every FTP put/get will delay one or two > >> seconds when passing > >> > through IKE. > >> > > >> > >> I don't think I'm going to reopen that discussion. We're > talking about > >> the option of: > >> > >> a) negotiate an 'update' to an SA > >> or > >> b) negotiate a new (expanded) SA and delete the old one > >> > >> In both cases you need an active phase 1 IKE SA. If you > still have one > >> around, no extra expense is incurred. If not, you'll need > to add one. > >> > >> Doing this without negotiatiing something wasn't one of > the proposed > >> options. > > > >proposed where? - I do not see it in the requirements document. > >Are u implying the draft from pyada and you? > > No, in the (a) and (b) list that I proposed above. My mistake. > There has to be > some negotiation: it isn't OK for the sender to say "I'm going to > open up this port on your box because I want to and you can't do > anything about it". Was never in disagreement with this. > > >The requirement for minimizing the latency seems a genuine one, > >particulary when using service based vpns - since the hit is now > >potentially on every new connection. > > We are not talking about new connections here: we are talking about > dynamically changing the policy in an existing SA to include more or > fewer ports. Are'nt they interrelated in the case of dynamic port scenario? Any time a new connection is formed with a port that is allocated dynamically, there is a requirement to change the policy in an existing SA to include the new information - similiarly there is a need to delete the port information when a connection using it torn down. One could minimize the overhead by varying the granularity, but the basic problem of additional delay overhead remains. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Fri Apr 5 05:35:24 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 g35DZNm11989; Fri, 5 Apr 2002 05:35:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03583 Fri, 5 Apr 2002 07:59:24 -0500 (EST) Message-ID: <413FBB0BA5AED1119122000083234B1A01FB48D3@alpha.igk.intel.com> From: "Szymanski, Pawel" To: "'ipsec@lists.tislabs.com'" Subject: SPD and SADB per interface Date: Fri, 5 Apr 2002 12:43:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-2" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, RFC2401 says that separate SPD and SADB should be maintained for each network interface on which IPSec is enabled. Does it mean that IK E negotiates IPSec SAs per interface (it is each SA should be used only for one interface) ? If yes, what about gateways which have two or more interfaces leading to the same untrusted network ? A remote peer sending IPSec-ed packets to such gateway does not know which SA it shall use, as it can't predict through which of the interfaces the packets will arrive to the gateway. Thank you in advance Pawel Szymanski Software Engineer at Intel Technology Poland mailto:pawel.szymanski@intel.com From owner-ipsec@lists.tislabs.com Fri Apr 5 07:16: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 g35FG5m17849; Fri, 5 Apr 2002 07:16:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04344 Fri, 5 Apr 2002 09:33:01 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15533.47196.341000.646131@gargle.gargle.HOWL> Date: Fri, 5 Apr 2002 09:44:44 -0500 From: Paul Koning To: paul.hoffman@vpnc.org Cc: vilhuber@cisco.com, ipsec@lists.tislabs.com Subject: Re: Do we actually need dynamic ports? References: X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 4 April 2002) by Paul Hoffman / VPNC: > This is an interesting question for IKE implementers: which would > make more sense to you? > - Keep a policy marker around and add or subtract relative to the marker > - Delete the old SA and create a new one when you want to add or subtract Rekeying is a fine solution if you don't mind the added overhead, provided that the handling of SA changeover gets cleaned up. In IKEv1 it's not well specified; even if you avoid the interop problems it's easy to get packet loss. Tim Jenkins tried to fix that. paul From owner-ipsec@lists.tislabs.com Fri Apr 5 08:14: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 g35GE3m21459; Fri, 5 Apr 2002 08:14:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04816 Fri, 5 Apr 2002 10:34:26 -0500 (EST) From: Charles Lynn To: "Szymanski, Pawel" Cc: "'ipsec@lists.tislabs.com'" Subject: Re: SPD and SADB per interface In-Reply-To: <413FBB0BA5AED1119122000083234B1A01FB48D3@alpha.igk.intel.com> Message-Id: <20020405154556.CE6601648D@wolfe.bbn.com> Date: Fri, 5 Apr 2002 10:45:56 -0500 (EST) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Pawel, > RFC2401 says that separate SPD and SADB should be maintained for each > network interface on which IPSec is enabled. > Does it mean that IK E negotiates IPSec SAs per interface (it is each SA > should be used only for one interface) ? Yes, I believe that is correct. > If yes, what about gateways which have two or more interfaces leading to the > same untrusted network ? A remote peer sending IPSec-ed packets to such > gateway does not know which SA it shall use, as it can't predict through > which of the interfaces the packets will arrive to the gateway. If routing changes so that the packets are delivered to the interface that does not have an SA, they are not delivered, as you have noted. A vendor may, as a market differentiator or additional feature, choose to implement mechanisms that allow interfaces that have some policy rules in common to share SAs. But a (minimal) IPsec implementation is not required to support such a capability. Charlie From owner-ipsec@lists.tislabs.com Fri Apr 5 08:16: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 g35GGUm21577; Fri, 5 Apr 2002 08:16:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04873 Fri, 5 Apr 2002 10:39:18 -0500 (EST) From: Charles Lynn To: "Lokesh" Cc: "IPsec Mailing List" Subject: Re: use of IV In-Reply-To: <000801c1dbd2$7af869c0$ae0510ac@roc.com> Message-Id: <20020405155100.7E32B1648D@wolfe.bbn.com> Date: Fri, 5 Apr 2002 10:51:00 -0500 (EST) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lokesh, Lookup "known plain-text attack" in a security book and note how the IV makes getting started (in a block chaining mode) much harder. Charlie From owner-ipsec@lists.tislabs.com Fri Apr 5 09:03: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 g35H3Pm26130; Fri, 5 Apr 2002 09:03:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05223 Fri, 5 Apr 2002 11:21:05 -0500 (EST) Message-ID: <3CADD10D.ABD71624@colubris.com> Date: Fri, 05 Apr 2002 11:30:05 -0500 From: Martin Gadbois Organization: Colubris Networks X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, design@lists.freeswan.org Subject: Nortel Contivity VPN client and 3rd party IPsec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2002 16:29:45.0453 (UTC) FILETIME=[18B601D0:01C1DCBF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello all, I would like to know what is required to use the Nortel Contivity VPN client with a 3rd party IPsec gateway. I noticed that the Contivity client uses part of http://www.globecom.net/ietf/draft/draft-mamros-pskeyext-00.html as the KEY_ID, but the HASH_R value that the gateware return is not accepted by the client (AUTHENTICATION_FAILURE) Any help is appreciated, -- ============== Martin Gadbois Colubris Networks Inc. From owner-ipsec@lists.tislabs.com Fri Apr 5 10: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 g35IFnm28727; Fri, 5 Apr 2002 10:15:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05722 Fri, 5 Apr 2002 12:29:42 -0500 (EST) Date: Fri, 5 Apr 2002 09:41:17 -0800 (PST) From: Jan Vilhuber To: Michael Choung Shieh cc: "'Tero Kivinen '" , "'ipsec@lists.tislabs.com '" , "'Paul Hoffman / VPNC '" Subject: RE: Do we actually need dynamic ports? In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B0458F7A0@NS-CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > Option (b) is to "negotiate a new (expanded) SA" and introduce extra > lantency. How does it add latency over option a, which is negotiate an update? It will be 1 round-trip in either case. Option b adds a delete notification, but traffic can start flowing before the delete notification, so no latency (over option a) is added. In any case, unless we reopen the discussion I eluded to, you HAVE to negotiate with the other end to widen the selectors, so 1 round-trip is the minimum you can do safely. jan > You don't need to reopen any discussion. > > However, I guess you recognize it adds more or less lantency to both > options. > > Michael Shieh > > -----Original Message----- > From: Jan Vilhuber > To: Michael Choung Shieh > Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC > Sent: 4/4/02 5:28 PM > Subject: RE: Do we actually need dynamic ports? > > On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > > > > Doing extra IKE to creat a new sa DURING application will introduce > extra > > latency and it may cause packet drop or retransmit. It's probably not > > preferred if every FTP put/get will delay one or two seconds when > passing > > through IKE. > > > > I don't think I'm going to reopen that discussion. We're talking about > the option of: > > a) negotiate an 'update' to an SA > or > b) negotiate a new (expanded) SA and delete the old one > > In both cases you need an active phase 1 IKE SA. If you still have one > around, no extra expense is incurred. If not, you'll need to add one. > > Doing this without negotiatiing something wasn't one of the proposed > options. > > jan > > > > -------------------------------------------- > > Michael Shieh > > -------------------------------------------- > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Thursday, April 04, 2002 12:11 PM > > To: Tero Kivinen > > Cc: ipsec@lists.tislabs.com; Paul Hoffman / VPNC > > Subject: Re: Do we actually need dynamic ports? > > > > > > I don't mind that. I just had to go re-read ikev2 and realized that > > you CAN in fact to multiple discontiguous ranges (or ports as well as > > IP addresses, by simply having multiple 'Traffic Selector > > Substructure' sections (7.13.1 Traffic Selector Substructure). Cool. I > > like it. > > > > The only minor difference (and I'm not saying it's important) is that > > you have to go through 'more' computation to delete and add a new SA, > > rather than adding to it, but that may be minor and not an issue at > > all. In particular: using up 'precious' entropy by having to come up > > with new key material, having to create a new SPI (and associated IKE > > delete payloads), and possibly having to rebuild some internal tree > > for the SA's (depends on implementation). Simply adding some selectors > > to an existing SA and keeping keys and SPI, *seems* easier, but may > > not actually make that much difference. > > > > Paul proposed using a semantic where using the same 'SPI' in the > > proposal means that you are adding to the existing SPI. That could > > bear a closer look as well, although I think there's room for error > > there.. > > > > Negotiating a new SA, with new SPI, deleting the old one is certainly > > 'clean' even though it seems to involve a lot of steps. Are we going > > to try and fold some (not all) of the jenkins rekey-draft into IKEv2, > > so that rekey behaviour is spelled out precisely? That would certainly > > help. > > > > jan > > > > > > > > On Thu, 4 Apr 2002, Tero Kivinen wrote: > > > > > vilhuber@cisco.com (Jan Vilhuber) writes: > > > > This is no different than creating a second SA, I suppose. You > want > > > > traffic for the FTP data channel? Create a new SA for > > > > it. Alternatively, and this is what Pyda's and my draft does, pass > an > > > > indicator that identifies the previous SA, and ADD to it. Saves > > > > memory, at almost no additional cost. > > > > > > Why have a special case for ADD and DELETE, why not simply > renegotiate > > > new SA with new set of selectors (i.e add new selectors, remove the > > > ones you do not want), and when that new SA is ready, delete the old > > > SA. I.e simply make ADD and DELETE to be rekey of the existing SA. > > > > > > For IKEv1 you could not do that, as there was no way to express the > > > set of selectors, but with TS we can do that, so now that is an > > > option. > > > -- > > > kivinen@ssh.fi > > > SSH Communications Security http://www.ssh.fi/ > > > SSH IPSEC Toolkit > http://www.ssh.fi/ipsec/ > > > > > > > -- > > Jan Vilhuber > vilhuber@cisco.com > > Cisco Systems, San Jose (408) > 527-0847 > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose (408) > 527-0847 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Apr 5 10:17: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 g35IHbm28928; Fri, 5 Apr 2002 10:17:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05806 Fri, 5 Apr 2002 12:39:52 -0500 (EST) Message-Id: <200204051750.g35Ho6ss011491@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Hoffman / VPNC cc: Jan Vilhuber , Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: Do we actually need dynamic ports? In-Reply-To: Your message of "Thu, 04 Apr 2002 15:29:13 PST." Reply-to: sommerfeld@east.sun.com Date: Fri, 05 Apr 2002 12:50:06 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > - Keep a policy marker around and add or subtract relative to the marker > - Delete the old SA and create a new one when you want to add or subtract I hope you really mean: "create a new one, cut over to it, then delete the old one after a suitable delay to allow packets in flight to land" And, if so, I think this is preferable -- it avoids any ambiguity of interpretation with respect to the ordering of the selector add/delete vs. traffic in flight. - Bill From owner-ipsec@lists.tislabs.com Fri Apr 5 10:21: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 g35ILam29376; Fri, 5 Apr 2002 10:21:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05873 Fri, 5 Apr 2002 12:45:40 -0500 (EST) Date: Fri, 5 Apr 2002 09:57:14 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: Paul Hoffman / VPNC , Tero Kivinen , Subject: Re: Do we actually need dynamic ports? In-Reply-To: <200204051750.g35Ho6ss011491@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 5 Apr 2002, Bill Sommerfeld wrote: > > - Keep a policy marker around and add or subtract relative to the marker > > - Delete the old SA and create a new one when you want to add or subtract > > I hope you really mean: > > "create a new one, cut over to it, then delete the old one after a > suitable delay to allow packets in flight to land" > Yes yes. Picky picky.. ;) > And, if so, I think this is preferable -- it avoids any ambiguity of > interpretation with respect to the ordering of the selector add/delete > vs. traffic in flight. > Well the draft that Pyda wrote changes the payload so that it's NOT ambiguous (it tags each SA with a policy ID, so you always know exactly which traffic-policy you're talking about (even if your SPI's may change), and added an add/remove flag). But I agree that using existing mechanisms (especially the TS payload and its expanded capabilities) seems fine (assuming we clarify rekeying precisely). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Apr 5 10:23: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 g35INfm29664; Fri, 5 Apr 2002 10:23:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05890 Fri, 5 Apr 2002 12:46:50 -0500 (EST) Date: Fri, 5 Apr 2002 09:58:22 -0800 (PST) From: Jan Vilhuber To: Paul Koning cc: , Subject: Re: Do we actually need dynamic ports? In-Reply-To: <15533.47196.341000.646131@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 5 Apr 2002, Paul Koning wrote: > Excerpt of message (sent 4 April 2002) by Paul Hoffman / VPNC: > > This is an interesting question for IKE implementers: which would > > make more sense to you? > > - Keep a policy marker around and add or subtract relative to the marker > > - Delete the old SA and create a new one when you want to add or subtract > > Rekeying is a fine solution if you don't mind the added overhead, There is no added overhead in either suggestion. Each takes one round-trip. Creating new/deleting old requires a little extra bookkeeping and a delete notification, but traffic can start flowing after 1 round-trip in either case. jan > provided that the handling of SA changeover gets cleaned up. In IKEv1 > it's not well specified; even if you avoid the interop problems it's > easy to get packet loss. Tim Jenkins tried to fix that. > > paul > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Apr 5 11:54: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 g35Jsgm03933; Fri, 5 Apr 2002 11:54:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06576 Fri, 5 Apr 2002 14:14:39 -0500 (EST) Date: Fri, 5 Apr 2002 11:26:19 -0800 (PST) From: Jan Vilhuber To: Rajesh Mohan cc: Michael Choung Shieh , Tero Kivinen , , Paul Hoffman / VPNC Subject: RE: Do we actually need dynamic ports? 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 Fri, 5 Apr 2002, Rajesh Mohan wrote: > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Friday, April 05, 2002 9:41 AM > > To: Michael Choung Shieh > > Cc: 'Tero Kivinen '; 'ipsec@lists.tislabs.com '; 'Paul > > Hoffman / VPNC ' > > Subject: RE: Do we actually need dynamic ports? > > > > > > On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > > > > > > > Option (b) is to "negotiate a new (expanded) SA" and introduce extra > > > lantency. > > > > How does it add latency over option a, which is negotiate an update? > > It will be 1 round-trip in either case. Option b adds a delete > > notification, but traffic can start flowing before the delete > > notification, so no latency (over option a) is added. > > > > In any case, unless we reopen the discussion I eluded to, you HAVE to > > negotiate with the other end to widen the selectors, so 1 round-trip > > is the minimum you can do safely. > > > > I think this is proposal is nothing more than a check mark in IKE > marketing brochure saying that IKE could do dynamic ports. I don't > think I will implement it if I have to buffer data traffic in > between a session when my control channel gets me a new session > key. Though there are no other good solutions, it does not mean we > should agree to a impractical solution. You're free to implement whatever you please. No one's holding a gun to your head. To me, it's more than a marketing bullet. I'm not in marketing and plan on keeping it that way. > I wish there was a world with simple ESP which could give me a > secure tunnel between two points and a simple IKE which would take a > identifier and give me session key. I could engineer lot of useful > things using these protocols. All the other things we added could be > pulled in when I have to deal with a hostile enemy. You can implement whatever you want. Just don't expect everything you implement to be reflected in the standard and don't expect to interoperate with everyone. Remember to use vendor-id's. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Apr 5 11:55: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 g35Jtdm03994; Fri, 5 Apr 2002 11:55:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06598 Fri, 5 Apr 2002 14:18:32 -0500 (EST) Message-Id: <200204051928.g35JSgss012325@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: Bill Sommerfeld , Paul Hoffman / VPNC , Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: Do we actually need dynamic ports? In-Reply-To: Your message of "Fri, 05 Apr 2002 09:57:14 PST." Reply-to: sommerfeld@east.sun.com Date: Fri, 05 Apr 2002 14:28:42 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Well the draft that Pyda wrote changes the payload so that it's NOT > ambiguous (it tags each SA with a policy ID, so you always know > exactly which traffic-policy you're talking about (even if your SPI's > may change), and added an add/remove flag). I wasn't thinking of reordering within the KM protocol, but rather reordering between the KM protocol and AH/ESP traffic, especially in the case of selector deletion. If the SPI changes, we reduce selector-set changes to the same [un]solved problem as graceful rekeying ;-) - Bill From owner-ipsec@lists.tislabs.com Fri Apr 5 11:56:15 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 g35JuEm04102; Fri, 5 Apr 2002 11:56:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06534 Fri, 5 Apr 2002 14:09:24 -0500 (EST) 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="iso-8859-1" Subject: RE: Do we actually need dynamic ports? Date: Fri, 5 Apr 2002 11:17:46 -0800 Message-ID: Thread-Topic: Do we actually need dynamic ports? Thread-Index: AcHc027i1rYf9AtCTl6DnWu5B9BTnQAAQKNA From: "Rajesh Mohan" To: "Jan Vilhuber" , "Michael Choung Shieh" Cc: "Tero Kivinen " , , "Paul Hoffman / VPNC " X-OriginalArrivalTime: 05 Apr 2002 19:17:47.0083 (UTC) FILETIME=[91D4A9B0:01C1DCD6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA06531 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Friday, April 05, 2002 9:41 AM > To: Michael Choung Shieh > Cc: 'Tero Kivinen '; 'ipsec@lists.tislabs.com '; 'Paul > Hoffman / VPNC ' > Subject: RE: Do we actually need dynamic ports? > > > On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > > > > Option (b) is to "negotiate a new (expanded) SA" and introduce extra > > lantency. > > How does it add latency over option a, which is negotiate an update? > It will be 1 round-trip in either case. Option b adds a delete > notification, but traffic can start flowing before the delete > notification, so no latency (over option a) is added. > > In any case, unless we reopen the discussion I eluded to, you HAVE to > negotiate with the other end to widen the selectors, so 1 round-trip > is the minimum you can do safely. > I think this is proposal is nothing more than a check mark in IKE marketing brochure saying that IKE could do dynamic ports. I don't think I will implement it if I have to buffer data traffic in between a session when my control channel gets me a new session key. Though there are no other good solutions, it does not mean we should agree to a impractical solution. I wish there was a world with simple ESP which could give me a secure tunnel between two points and a simple IKE which would take a identifier and give me session key. I could engineer lot of useful things using these protocols. All the other things we added could be pulled in when I have to deal with a hostile enemy. -Rajesh M > jan > > > > You don't need to reopen any discussion. > > > > However, I guess you recognize it adds more or less lantency to both > > options. > > > > Michael Shieh > > > > -----Original Message----- > > From: Jan Vilhuber > > To: Michael Choung Shieh > > Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC > > Sent: 4/4/02 5:28 PM > > Subject: RE: Do we actually need dynamic ports? > > > > On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > > > > > > > Doing extra IKE to creat a new sa DURING application will > introduce > > extra > > > latency and it may cause packet drop or retransmit. It's > probably not > > > preferred if every FTP put/get will delay one or two seconds when > > passing > > > through IKE. > > > > > > > I don't think I'm going to reopen that discussion. We're > talking about > > the option of: > > > > a) negotiate an 'update' to an SA > > or > > b) negotiate a new (expanded) SA and delete the old one > > > > In both cases you need an active phase 1 IKE SA. If you > still have one > > around, no extra expense is incurred. If not, you'll need > to add one. > > > > Doing this without negotiatiing something wasn't one of the proposed > > options. > > > > jan > > > > > > > -------------------------------------------- > > > Michael Shieh > > > -------------------------------------------- > > > > > > -----Original Message----- > > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > > Sent: Thursday, April 04, 2002 12:11 PM > > > To: Tero Kivinen > > > Cc: ipsec@lists.tislabs.com; Paul Hoffman / VPNC > > > Subject: Re: Do we actually need dynamic ports? > > > > > > > > > I don't mind that. I just had to go re-read ikev2 and > realized that > > > you CAN in fact to multiple discontiguous ranges (or > ports as well as > > > IP addresses, by simply having multiple 'Traffic Selector > > > Substructure' sections (7.13.1 Traffic Selector > Substructure). Cool. I > > > like it. > > > > > > The only minor difference (and I'm not saying it's > important) is that > > > you have to go through 'more' computation to delete and > add a new SA, > > > rather than adding to it, but that may be minor and not > an issue at > > > all. In particular: using up 'precious' entropy by having > to come up > > > with new key material, having to create a new SPI (and > associated IKE > > > delete payloads), and possibly having to rebuild some > internal tree > > > for the SA's (depends on implementation). Simply adding > some selectors > > > to an existing SA and keeping keys and SPI, *seems* > easier, but may > > > not actually make that much difference. > > > > > > Paul proposed using a semantic where using the same 'SPI' in the > > > proposal means that you are adding to the existing SPI. That could > > > bear a closer look as well, although I think there's room > for error > > > there.. > > > > > > Negotiating a new SA, with new SPI, deleting the old one > is certainly > > > 'clean' even though it seems to involve a lot of steps. > Are we going > > > to try and fold some (not all) of the jenkins rekey-draft > into IKEv2, > > > so that rekey behaviour is spelled out precisely? That > would certainly > > > help. > > > > > > jan > > > > > > > > > > > > On Thu, 4 Apr 2002, Tero Kivinen wrote: > > > > > > > vilhuber@cisco.com (Jan Vilhuber) writes: > > > > > This is no different than creating a second SA, I suppose. You > > want > > > > > traffic for the FTP data channel? Create a new SA for > > > > > it. Alternatively, and this is what Pyda's and my > draft does, pass > > an > > > > > indicator that identifies the previous SA, and ADD to > it. Saves > > > > > memory, at almost no additional cost. > > > > > > > > Why have a special case for ADD and DELETE, why not simply > > renegotiate > > > > new SA with new set of selectors (i.e add new > selectors, remove the > > > > ones you do not want), and when that new SA is ready, > delete the old > > > > SA. I.e simply make ADD and DELETE to be rekey of the > existing SA. > > > > > > > > For IKEv1 you could not do that, as there was no way to > express the > > > > set of selectors, but with TS we can do that, so now that is an > > > > option. > > > > -- > > > > kivinen@ssh.fi > > > > SSH Communications Security http://www.ssh.fi/ > > > > SSH IPSEC Toolkit > > http://www.ssh.fi/ipsec/ > > > > > > > > > > -- > > > Jan Vilhuber > > vilhuber@cisco.com > > > Cisco Systems, San Jose (408) > > 527-0847 > > > > > > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose (408) > > 527-0847 > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Fri Apr 5 12:35: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 g35KZVm09882; Fri, 5 Apr 2002 12:35:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06915 Fri, 5 Apr 2002 14:58:58 -0500 (EST) 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="iso-8859-1" Subject: RE: Do we actually need dynamic ports? Date: Fri, 5 Apr 2002 12:07:14 -0800 Message-ID: Thread-Topic: Do we actually need dynamic ports? Thread-Index: AcHc1130h7OY6/kdSzqRSEe3SkT0EQABGSDA From: "Rajesh Mohan" To: "Jan Vilhuber" Cc: X-OriginalArrivalTime: 05 Apr 2002 20:07:14.0811 (UTC) FILETIME=[7ABC04B0:01C1DCDD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA06912 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It looks like, a english professor will get more work done on this list than a engineer. Anyway, my point is, your proposal does not have my vote, for whatever it is worth. > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Friday, April 05, 2002 11:26 AM > To: Rajesh Mohan > Cc: Michael Choung Shieh; Tero Kivinen; ipsec@lists.tislabs.com; Paul > Hoffman / VPNC > Subject: RE: Do we actually need dynamic ports? > > > On Fri, 5 Apr 2002, Rajesh Mohan wrote: > > > > > > > > -----Original Message----- > > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > > Sent: Friday, April 05, 2002 9:41 AM > > > To: Michael Choung Shieh > > > Cc: 'Tero Kivinen '; 'ipsec@lists.tislabs.com '; 'Paul > > > Hoffman / VPNC ' > > > Subject: RE: Do we actually need dynamic ports? > > > > > > > > > On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > > > > > > > > > > Option (b) is to "negotiate a new (expanded) SA" and > introduce extra > > > > lantency. > > > > > > How does it add latency over option a, which is negotiate > an update? > > > It will be 1 round-trip in either case. Option b adds a delete > > > notification, but traffic can start flowing before the delete > > > notification, so no latency (over option a) is added. > > > > > > In any case, unless we reopen the discussion I eluded to, > you HAVE to > > > negotiate with the other end to widen the selectors, so 1 > round-trip > > > is the minimum you can do safely. > > > > > > > > I think this is proposal is nothing more than a check mark in IKE > > marketing brochure saying that IKE could do dynamic ports. I don't > > think I will implement it if I have to buffer data traffic in > > between a session when my control channel gets me a new session > > key. Though there are no other good solutions, it does not mean we > > should agree to a impractical solution. > > You're free to implement whatever you please. No one's holding a gun > to your head. > > To me, it's more than a marketing bullet. I'm not in marketing and > plan on keeping it that way. > > > I wish there was a world with simple ESP which could give me a > > secure tunnel between two points and a simple IKE which would take a > > identifier and give me session key. I could engineer lot of useful > > things using these protocols. All the other things we added could be > > pulled in when I have to deal with a hostile enemy. > > You can implement whatever you want. Just don't expect everything you > implement to be reflected in the standard and don't expect to > interoperate with everyone. Remember to use vendor-id's. > > jan > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Fri Apr 5 12:41: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 g35Kf9m09982; Fri, 5 Apr 2002 12:41:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07009 Fri, 5 Apr 2002 15:06:22 -0500 (EST) Message-ID: <3CAE0672.E2DF07B3@juniper.net> Date: Fri, 05 Apr 2002 12:17:54 -0800 From: Kalyan Bade Reply-To: kalyan@juniper.net Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: "Chinna N.R. Pellacuru" , ipsec mailling list Subject: Re: Is TS agreement necessary? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > >If an IPsec tunnel can be implemented in an interoperable manner to look > > > >like a virtual point-to-point link, it can have a lot of benefits. The > > > >IPsec secured virtual point-to-point link can be made visible to the > >> >routing protocols, and we can run routing on that link to automatically > >> >get the resiliency and all the other benefits provided by routing. No need > >> >to run keepalives or DPDs, which only provide information of connectivity > >> >to the IPsec gateways, and provide no information about the connectivity > >> >to the traffic destination. We can route multicast traffic across the > >> >point-to-point link too. Yes, we loose the limited access control that > >> >IPsec provides, but any serious deployment would not soley depend on the > >> >access control provided by IPsec. I have seen customers asking for, what Chinna has mentioned above. Treat the IPsec tunnel as a point-to-point interface and let the routing protocols/MPLS uses it as an interface in its code. Infact they want to treat IPsec exactly as an IP-in-IP tunnel or a GRE tunnel (tunnel MPLS packets too, treating them as some transport data). This could always be done by treating the phase-2 identities as 0/0. Any comments on the above approach. Thanks, Kalyan. From owner-ipsec@lists.tislabs.com Fri Apr 5 12:52: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 g35Kq6m10237; Fri, 5 Apr 2002 12:52:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07050 Fri, 5 Apr 2002 15:16:14 -0500 (EST) Date: Fri, 5 Apr 2002 12:27:53 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Kalyan Bade cc: Stephen Kent , ipsec mailling list Subject: Re: Is TS agreement necessary? In-Reply-To: <3CAE0672.E2DF07B3@juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 5 Apr 2002, Kalyan Bade wrote: > > > > >If an IPsec tunnel can be implemented in an interoperable manner to look > > > > >like a virtual point-to-point link, it can have a lot of benefits. The > > > > >IPsec secured virtual point-to-point link can be made visible to the > > >> >routing protocols, and we can run routing on that link to automatically > > >> >get the resiliency and all the other benefits provided by routing. No need > > >> >to run keepalives or DPDs, which only provide information of connectivity > > >> >to the IPsec gateways, and provide no information about the connectivity > > >> >to the traffic destination. We can route multicast traffic across the > > >> >point-to-point link too. Yes, we loose the limited access control that > > >> >IPsec provides, but any serious deployment would not soley depend on the > > >> >access control provided by IPsec. > > I have seen customers asking for, what Chinna has mentioned above. Treat > the IPsec tunnel as a point-to-point interface and let the routing > protocols/MPLS uses it as an interface in its code. Infact they want to > treat IPsec exactly as an IP-in-IP tunnel or a GRE tunnel (tunnel MPLS > packets too, treating them as some transport data). This could always be > done by treating the phase-2 identities as 0/0. Any comments on the > above approach. > > Thanks, > Kalyan. > Infact the majority of what we call "site-to-site" deployments use GRE as a point-to-point virtual link, and use IPsec to protect the GRE tunnel. But, not everybody implements GRE, and this becomes an interoperability issue. I agree, it would be very useful to specify an interoperable way of having an IPsec tunnel be treated as a virtual point-to-point link, and not have to rely on GRE always. GRE has some more benefits like we can encapsulate all kinds of protocols in GRE, and not just IP. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 5 12:59: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 g35KxEm10393; Fri, 5 Apr 2002 12:59:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07137 Fri, 5 Apr 2002 15:22:54 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3CAE0672.E2DF07B3@juniper.net> References: <3CAE0672.E2DF07B3@juniper.net> Date: Fri, 5 Apr 2002 15:33:42 -0500 To: kalyan@juniper.net From: Stephen Kent Subject: Re: Is TS agreement necessary? Cc: ipsec mailling list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:17 PM -0800 4/5/02, Kalyan Bade wrote: > > > > >If an IPsec tunnel can be implemented in an interoperable >manner to look >> > > >like a virtual point-to-point link, it can have a lot of benefits. The >> > > >IPsec secured virtual point-to-point link can be made visible to the >> >> >routing protocols, and we can run routing on that link to automatically >> >> >get the resiliency and all the other benefits provided by >>routing. No need >> >> >to run keepalives or DPDs, which only provide information of >>connectivity >> >> >to the IPsec gateways, and provide no information about the >>connectivity >> >> >to the traffic destination. We can route multicast traffic across the >> >> >point-to-point link too. Yes, we loose the limited access control that >> >> >IPsec provides, but any serious deployment would not soley >>depend on the >> >> >access control provided by IPsec. > >I have seen customers asking for, what Chinna has mentioned above. Treat >the IPsec tunnel as a point-to-point interface and let the routing >protocols/MPLS uses it as an interface in its code. Infact they want to >treat IPsec exactly as an IP-in-IP tunnel or a GRE tunnel (tunnel MPLS >packets too, treating them as some transport data). This could always be >done by treating the phase-2 identities as 0/0. Any comments on the >above approach. > >Thanks, >Kalyan. This is closer to the flavor of what L2TP does with IPsec, in transport mode. The clients you cite appear to want just point-to-point crypto protection and as you noted, you can achieve that by using rather promiscuous selectors. Steve From owner-ipsec@lists.tislabs.com Fri Apr 5 12:59:44 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 g35Kxim10411; Fri, 5 Apr 2002 12:59:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07180 Fri, 5 Apr 2002 15:26:26 -0500 (EST) Message-ID: <3CAE0B27.23100061@juniper.net> Date: Fri, 05 Apr 2002 12:37:59 -0800 From: Kalyan Bade Reply-To: kalyan@juniper.net Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Chinna N.R. Pellacuru" CC: Stephen Kent , ipsec mailling list Subject: Re: Is TS agreement necessary? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Infact the majority of what we call "site-to-site" deployments use GRE as > a point-to-point virtual link, and use IPsec to protect the GRE tunnel. > But, not everybody implements GRE, and this becomes an interoperability > issue. > > I agree, it would be very useful to specify an interoperable way of having > an IPsec tunnel be treated as a virtual point-to-point link, and not have > to rely on GRE always. GRE has some more benefits like we can encapsulate > all kinds of protocols in GRE, and not just IP. I agree that it can done with GRE + IPsec transport mode. But, why in the first place we have to do GRE when we can tunnel it directly through IPsec (talking about IP traffic only). Is the RFC against it ? Am I missing anything here ? Thanks, Kalyan. From owner-ipsec@lists.tislabs.com Fri Apr 5 13:22: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 g35LMTm11368; Fri, 5 Apr 2002 13:22:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07293 Fri, 5 Apr 2002 15:43:58 -0500 (EST) Date: Fri, 5 Apr 2002 12:55:38 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Kalyan Bade cc: Stephen Kent , ipsec mailling list Subject: Re: Is TS agreement necessary? In-Reply-To: <3CAE0B27.23100061@juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 5 Apr 2002, Kalyan Bade wrote: > > Infact the majority of what we call "site-to-site" deployments use GRE as > > a point-to-point virtual link, and use IPsec to protect the GRE tunnel. > > But, not everybody implements GRE, and this becomes an interoperability > > issue. > > > > I agree, it would be very useful to specify an interoperable way of having > > an IPsec tunnel be treated as a virtual point-to-point link, and not have > > to rely on GRE always. GRE has some more benefits like we can encapsulate > > all kinds of protocols in GRE, and not just IP. > > I agree that it can done with GRE + IPsec transport mode. But, why in > the first place we have to do GRE when we can tunnel it directly through > IPsec (talking about IP traffic only). Is the RFC against it ? Am I > missing anything here ? > > Thanks, > Kalyan. > What does any,any mean in an SAD? How do you differentiate between any,any to peer1, from any,any to peer2? If you use the same interface to go out to peer1 and peer2, and the same SAD is being used for all the SAs on that interface, when there is some data traffic, the traffic will hit all the any,any selectors in the SAD. How do you decide which selector to pick, and hence which peer to send the data to? By having an interoperable agreement of what an any,any selector means, the IPsec peers can probably agree to create a virtual tunnel interface for all any,any selectors, so that routing can differentiate between the any,any tunnels, and route the traffic appropriately. Without making that assumption, if we send an any,any to a peer, then that would probably confuse the peer, and make it send ALL traffic to me (atleast all traffic on that interface). Given that routing is way way more efficient and generally highly optimized, compared to packet classification, we can also get a big jump in performance. Eliminating packet classification requirement in the data path brings along with it a lot of other benefits too. I have seen packet classification being one of the biggest bottlenecks in many implementations. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 5 14:04: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 g35M4Lm12323; Fri, 5 Apr 2002 14:04:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07679 Fri, 5 Apr 2002 16:21:34 -0500 (EST) Date: Fri, 5 Apr 2002 13:33:06 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Kalyan Bade cc: Stephen Kent , ipsec mailling list Subject: Re: Is TS agreement necessary? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Kalyan, Thank you for picking up on this conversation. Democracy and majority rule is fine, but we need a bill-of-rights too in this forum. One of the first basic right should be that, all IPsec implementations must not be forced to do inefficient things. Inefficient things should be optional. This would avoid the seemingly majority of "end-host" or "small systems" vendors from crushing the seemingly minority of "large intermediate gateway" vendors. It is no surprise that this particular requirement is coming from Juniper, because the scalability and performance requirements of IPsec in general are going through the roof, and we have to grapple with a very different set of requirements than the "end-host" and "small systems" implementations. thanks, chinna On Fri, 5 Apr 2002, Chinna N.R. Pellacuru wrote: > On Fri, 5 Apr 2002, Kalyan Bade wrote: > > > > Infact the majority of what we call "site-to-site" deployments use GRE as > > > a point-to-point virtual link, and use IPsec to protect the GRE tunnel. > > > But, not everybody implements GRE, and this becomes an interoperability > > > issue. > > > > > > I agree, it would be very useful to specify an interoperable way of having > > > an IPsec tunnel be treated as a virtual point-to-point link, and not have > > > to rely on GRE always. GRE has some more benefits like we can encapsulate > > > all kinds of protocols in GRE, and not just IP. > > > > I agree that it can done with GRE + IPsec transport mode. But, why in > > the first place we have to do GRE when we can tunnel it directly through > > IPsec (talking about IP traffic only). Is the RFC against it ? Am I > > missing anything here ? > > > > Thanks, > > Kalyan. > > > > What does any,any mean in an SAD? How do you differentiate between any,any > to peer1, from any,any to peer2? If you use the same interface to go out > to peer1 and peer2, and the same SAD is being used for all the SAs on that > interface, when there is some data traffic, the traffic will hit all the > any,any selectors in the SAD. How do you decide which selector to pick, > and hence which peer to send the data to? > > By having an interoperable agreement of what an any,any selector means, > the IPsec peers can probably agree to create a virtual tunnel interface > for all any,any selectors, so that routing can differentiate between the > any,any tunnels, and route the traffic appropriately. Without making that > assumption, if we send an any,any to a peer, then that would probably > confuse the peer, and make it send ALL traffic to me (atleast all traffic > on that interface). > > Given that routing is way way more efficient and generally highly > optimized, compared to packet classification, we can also get a big jump > in performance. Eliminating packet classification requirement in the data > path brings along with it a lot of other benefits too. I have seen packet > classification being one of the biggest bottlenecks in many > implementations. > > chinna > > chinna narasimha reddy pellacuru > s/w engineer > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 5 14:09: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 g35M90m12414; Fri, 5 Apr 2002 14:09:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07782 Fri, 5 Apr 2002 16:32:54 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 5 Apr 2002 16:37:32 -0500 To: "Chinna N.R. Pellacuru" From: Stephen Kent Subject: Re: Is TS agreement necessary? Cc: ipsec mailling list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:55 PM -0800 4/5/02, Chinna N.R. Pellacuru wrote: >On Fri, 5 Apr 2002, Kalyan Bade wrote: > >> > Infact the majority of what we call "site-to-site" deployments use GRE as >> > a point-to-point virtual link, and use IPsec to protect the GRE tunnel. >> > But, not everybody implements GRE, and this becomes an interoperability >> > issue. >> > >> > I agree, it would be very useful to specify an interoperable way of having >> > an IPsec tunnel be treated as a virtual point-to-point link, and not have >> > to rely on GRE always. GRE has some more benefits like we can encapsulate >> > all kinds of protocols in GRE, and not just IP. >> >> I agree that it can done with GRE + IPsec transport mode. But, why in >> the first place we have to do GRE when we can tunnel it directly through >> IPsec (talking about IP traffic only). Is the RFC against it ? Am I >> missing anything here ? >> >> Thanks, >> Kalyan. >> > >What does any,any mean in an SAD? How do you differentiate between any,any >to peer1, from any,any to peer2? If you use the same interface to go out >to peer1 and peer2, and the same SAD is being used for all the SAs on that >interface, when there is some data traffic, the traffic will hit all the >any,any selectors in the SAD. How do you decide which selector to pick, >and hence which peer to send the data to? > >By having an interoperable agreement of what an any,any selector means, >the IPsec peers can probably agree to create a virtual tunnel interface >for all any,any selectors, so that routing can differentiate between the >any,any tunnels, and route the traffic appropriately. Without making that >assumption, if we send an any,any to a peer, then that would probably >confuse the peer, and make it send ALL traffic to me (atleast all traffic >on that interface). > >Given that routing is way way more efficient and generally highly >optimized, compared to packet classification, we can also get a big jump >in performance. Eliminating packet classification requirement in the data >path brings along with it a lot of other benefits too. I have seen packet >classification being one of the biggest bottlenecks in many >implementations. > > chinna > >chinna narasimha reddy pellacuru >s/w engineer In general, an any,any IP address pair would not work, since one must usually have a distinct SA per recipient (in the unicast context). But, in the case cited, a single link to a neighbor, and since SPD entries are per interface, there might not be a problem with this selector definition. Steve From owner-ipsec@lists.tislabs.com Fri Apr 5 14:17: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 g35MHOm12651; Fri, 5 Apr 2002 14:17:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07851 Fri, 5 Apr 2002 16:41:42 -0500 (EST) Date: Fri, 5 Apr 2002 13:53:21 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: ipsec mailling list Subject: Re: Is TS agreement necessary? 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 Fri, 5 Apr 2002, Stephen Kent wrote: > At 12:55 PM -0800 4/5/02, Chinna N.R. Pellacuru wrote: > >On Fri, 5 Apr 2002, Kalyan Bade wrote: > > > >> > Infact the majority of what we call "site-to-site" deployments use GRE as > >> > a point-to-point virtual link, and use IPsec to protect the GRE tunnel. > >> > But, not everybody implements GRE, and this becomes an interoperability > >> > issue. > >> > > >> > I agree, it would be very useful to specify an interoperable way of having > >> > an IPsec tunnel be treated as a virtual point-to-point link, and not have > >> > to rely on GRE always. GRE has some more benefits like we can encapsulate > >> > all kinds of protocols in GRE, and not just IP. > >> > >> I agree that it can done with GRE + IPsec transport mode. But, why in > >> the first place we have to do GRE when we can tunnel it directly through > >> IPsec (talking about IP traffic only). Is the RFC against it ? Am I > >> missing anything here ? > >> > >> Thanks, > >> Kalyan. > >> > > > >What does any,any mean in an SAD? How do you differentiate between any,any > >to peer1, from any,any to peer2? If you use the same interface to go out > >to peer1 and peer2, and the same SAD is being used for all the SAs on that > >interface, when there is some data traffic, the traffic will hit all the > >any,any selectors in the SAD. How do you decide which selector to pick, > >and hence which peer to send the data to? > > > >By having an interoperable agreement of what an any,any selector means, > >the IPsec peers can probably agree to create a virtual tunnel interface > >for all any,any selectors, so that routing can differentiate between the > >any,any tunnels, and route the traffic appropriately. Without making that > >assumption, if we send an any,any to a peer, then that would probably > >confuse the peer, and make it send ALL traffic to me (atleast all traffic > >on that interface). > > > >Given that routing is way way more efficient and generally highly > >optimized, compared to packet classification, we can also get a big jump > >in performance. Eliminating packet classification requirement in the data > >path brings along with it a lot of other benefits too. I have seen packet > >classification being one of the biggest bottlenecks in many > >implementations. > > > > chinna > > > >chinna narasimha reddy pellacuru > >s/w engineer > > In general, an any,any IP address pair would not work, since one must > usually have a distinct SA per recipient (in the unicast context). > But, in the case cited, a single link to a neighbor, and since SPD > entries are per interface, there might not be a problem with this > selector definition. > > Steve > I wasn't sure if a general agreement among IPsec implementations that any,any always means a virutal link is sufficient, or it should be specified in an RFC. For example we already specify that if no Quick Mode ID payloads are sent, then the default selector is all traffic from the local IPsec endpoint to the remote IPsec endpoint. thanks, chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 5 14:19:26 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 g35MJPm12726; Fri, 5 Apr 2002 14:19:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07867 Fri, 5 Apr 2002 16:42:37 -0500 (EST) Message-ID: <3CAE1D45.F952F4AA@sonicwall.com> Date: Fri, 05 Apr 2002 13:55:17 -0800 From: "Scott G. Kelly" Organization: SonicWall X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: Jan Vilhuber , ipsec@lists.tislabs.com, Paul Hoffman / VPNC Subject: Re: Do we actually need dynamic ports? References: <15532.44528.656396.950623@ryijy.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2002 21:55:32.0987 (UTC) FILETIME=[9BF2FCB0:01C1DCEC] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tero, Comments below... Tero Kivinen wrote: > > vilhuber@cisco.com (Jan Vilhuber) writes: > > This is no different than creating a second SA, I suppose. You want > > traffic for the FTP data channel? Create a new SA for > > it. Alternatively, and this is what Pyda's and my draft does, pass an > > indicator that identifies the previous SA, and ADD to it. Saves > > memory, at almost no additional cost. > > Why have a special case for ADD and DELETE, why not simply renegotiate > new SA with new set of selectors (i.e add new selectors, remove the > ones you do not want), and when that new SA is ready, delete the old > SA. I.e simply make ADD and DELETE to be rekey of the existing SA. > > For IKEv1 you could not do that, as there was no way to express the > set of selectors, but with TS we can do that, so now that is an > option. After giving this some thought, it strikes me that if we replace the phase 2 SA pair every time the selectors change, then an FTP session with a single GET (file transfer) would take 3 SA negotiations: one for the original command channel, one for the new command + data channel, and one for the removal of a data channel. Leaving the original SA pair intact and negotiating a new one reduces this to 2 SA negotiations, but consumes more memory. In the case of transferring lots of files, we would need something 1 + 2n negotiations for n files if replacing SAs, and 1 + n if we simply add/delete new ones as needed. Scott From owner-ipsec@lists.tislabs.com Fri Apr 5 15:26: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 g35NQim16303; Fri, 5 Apr 2002 15:26:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08425 Fri, 5 Apr 2002 17:46:37 -0500 (EST) Message-ID: <3CAE2BFC.5C8CBC41@juniper.net> Date: Fri, 05 Apr 2002 14:58:04 -0800 From: Kalyan Bade Reply-To: kalyan@juniper.net Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Chinna N.R. Pellacuru" CC: Stephen Kent , ipsec mailling list Subject: Re: Is TS agreement necessary? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > What does any,any mean in an SAD? How do you differentiate between any,any > to peer1, from any,any to peer2? If you use the same interface to go out > to peer1 and peer2, and the same SAD is being used for all the SAs on that > interface, when there is some data traffic, the traffic will hit all the > any,any selectors in the SAD. How do you decide which selector to pick, > and hence which peer to send the data to? > > By having an interoperable agreement of what an any,any selector means, > the IPsec peers can probably agree to create a virtual tunnel interface > for all any,any selectors, so that routing can differentiate between the > any,any tunnels, and route the traffic appropriately. Without making that > assumption, if we send an any,any to a peer, then that would probably > confuse the peer, and make it send ALL traffic to me (atleast all traffic > on that interface). Agreed. This problem arises only when I have an SPD per interface. From a router customer point of view, the customer wants to see IPsec tunneling similar to a GRE tunneling and let the forwarding table decide what packets should be forwarded to IPsec tunnel. Here, the forwarding table is the SPD for me (a global one), not a per interface SPD. Please correct me if I misunderstood the whole IPsec concept as it should be looked at. Thanks, Kalyan. From owner-ipsec@lists.tislabs.com Fri Apr 5 15:39: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 g35Ndbm16556; Fri, 5 Apr 2002 15:39:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08551 Fri, 5 Apr 2002 18:04:15 -0500 (EST) Date: Fri, 5 Apr 2002 15:15:40 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Kalyan Bade cc: Stephen Kent , ipsec mailling list Subject: Re: Is TS agreement necessary? In-Reply-To: <3CAE2BFC.5C8CBC41@juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 5 Apr 2002, Kalyan Bade wrote: > > What does any,any mean in an SAD? How do you differentiate between any,any > > to peer1, from any,any to peer2? If you use the same interface to go out > > to peer1 and peer2, and the same SAD is being used for all the SAs on that > > interface, when there is some data traffic, the traffic will hit all the > > any,any selectors in the SAD. How do you decide which selector to pick, > > and hence which peer to send the data to? > > > > By having an interoperable agreement of what an any,any selector means, > > the IPsec peers can probably agree to create a virtual tunnel interface > > for all any,any selectors, so that routing can differentiate between the > > any,any tunnels, and route the traffic appropriately. Without making that > > assumption, if we send an any,any to a peer, then that would probably > > confuse the peer, and make it send ALL traffic to me (atleast all traffic > > on that interface). > > Agreed. This problem arises only when I have an SPD per interface. The problem actually gets worse if you don't have an SPD per physical interface. If you had only one SPD on the box, then all your any,any selectors will now exist in the single SPD, and hence causing a bigger problem. >From > a router customer point of view, the customer wants to see IPsec > tunneling similar to a GRE tunneling and let the forwarding table decide > what packets should be forwarded to IPsec tunnel. Here, the forwarding > table is the SPD for me (a global one), not a per interface SPD. The routing table effectively becomes the SPD in a sense, or in other words, it decides what selector(virtual IPsec tunnel) needs to be used, based on the routing (network topology) information. There would be only one SA in the SAD of the virtual IPsec tunnel interface, which is any,any selector, and you won't need to have an SAD on the actual physical interface that data will ultimately go through. On the actual physical interface, you will still have an SPD, but the moment someone sends you a any,any selector, we should not include that SA into the SAD of the physical interface, but instead create a virtual interface for that IPsec tunnel, with tunnel endpoints as the local IPsec endpoint and remote IPsec endpoint, and have a single SA with the selector any,any on that virtual IPsec tunnel. Now, when routing decides to forward any outgoing traffic onto any of the IPsec virtual tunnels, the single SA that is on the IPsec virtual tunnel is applied to all that traffic. chinna Please > correct me if I misunderstood the whole IPsec concept as it should be > looked at. > > Thanks, > Kalyan. > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 5 15:52:03 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 g35Nq2m16758; Fri, 5 Apr 2002 15:52:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08713 Fri, 5 Apr 2002 18:18:48 -0500 (EST) Date: Fri, 5 Apr 2002 15:30:29 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Kalyan Bade cc: Stephen Kent , ipsec mailling list Subject: Re: Is TS agreement necessary? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All this is implementation dependant to a large extent, and the only important thing is that IPsec implementations should be able to handle any,any selector, and know that they should create a point-to-point tunnel to the peer when they see any,any selector being proposed by the peer. The same physical interface might be used by multiple VRFs and you could have multiple SPDs, one per VRF on a single physical interface, and hence you have to make sure that the virtual tunnels you create are associated with the right VRF routing table etc. chinna On Fri, 5 Apr 2002, Chinna N.R. Pellacuru wrote: > On Fri, 5 Apr 2002, Kalyan Bade wrote: > > > > What does any,any mean in an SAD? How do you differentiate between any,any > > > to peer1, from any,any to peer2? If you use the same interface to go out > > > to peer1 and peer2, and the same SAD is being used for all the SAs on that > > > interface, when there is some data traffic, the traffic will hit all the > > > any,any selectors in the SAD. How do you decide which selector to pick, > > > and hence which peer to send the data to? > > > > > > By having an interoperable agreement of what an any,any selector means, > > > the IPsec peers can probably agree to create a virtual tunnel interface > > > for all any,any selectors, so that routing can differentiate between the > > > any,any tunnels, and route the traffic appropriately. Without making that > > > assumption, if we send an any,any to a peer, then that would probably > > > confuse the peer, and make it send ALL traffic to me (atleast all traffic > > > on that interface). > > > > Agreed. This problem arises only when I have an SPD per interface. > > The problem actually gets worse if you don't have an SPD per physical > interface. If you had only one SPD on the box, then all your any,any > selectors will now exist in the single SPD, and hence causing a bigger > problem. > > From > > a router customer point of view, the customer wants to see IPsec > > tunneling similar to a GRE tunneling and let the forwarding table decide > > what packets should be forwarded to IPsec tunnel. Here, the forwarding > > table is the SPD for me (a global one), not a per interface SPD. > > The routing table effectively becomes the SPD in a sense, or in other > words, it decides what selector(virtual IPsec tunnel) needs to be used, > based on the routing (network topology) information. There would be only > one SA in the SAD of the virtual IPsec tunnel interface, which is any,any > selector, and you won't need to have an SAD on the actual physical > interface that data will ultimately go through. > > On the actual physical interface, you will still have an SPD, but the > moment someone sends you a any,any selector, we should not include that > SA into the SAD of the physical interface, but instead create a virtual > interface for that IPsec tunnel, with tunnel endpoints as the local IPsec > endpoint and remote IPsec endpoint, and have a single SA with the selector > any,any on that virtual IPsec tunnel. > > Now, when routing decides to forward any outgoing traffic onto any of the > IPsec virtual tunnels, the single SA that is on the IPsec virtual tunnel > is applied to all that traffic. > > chinna > > Please > > correct me if I misunderstood the whole IPsec concept as it should be > > looked at. > > > > Thanks, > > Kalyan. > > > > chinna narasimha reddy pellacuru > s/w engineer > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 5 15:52: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 g35NqPm16772; Fri, 5 Apr 2002 15:52:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08693 Fri, 5 Apr 2002 18:17:21 -0500 (EST) Message-ID: <3CAE3333.50F78DE8@juniper.net> Date: Fri, 05 Apr 2002 15:28:51 -0800 From: Kalyan Bade Reply-To: kalyan@juniper.net Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Chinna N.R. Pellacuru" CC: Stephen Kent , ipsec mailling list Subject: Re: Is TS agreement necessary? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Chinna N.R. Pellacuru" wrote: > > On Fri, 5 Apr 2002, Kalyan Bade wrote: > > > > What does any,any mean in an SAD? How do you differentiate between any,any > > > to peer1, from any,any to peer2? If you use the same interface to go out > > > to peer1 and peer2, and the same SAD is being used for all the SAs on that > > > interface, when there is some data traffic, the traffic will hit all the > > > any,any selectors in the SAD. How do you decide which selector to pick, > > > and hence which peer to send the data to? > > > > > > By having an interoperable agreement of what an any,any selector means, > > > the IPsec peers can probably agree to create a virtual tunnel interface > > > for all any,any selectors, so that routing can differentiate between the > > > any,any tunnels, and route the traffic appropriately. Without making that > > > assumption, if we send an any,any to a peer, then that would probably > > > confuse the peer, and make it send ALL traffic to me (atleast all traffic > > > on that interface). > > > > Agreed. This problem arises only when I have an SPD per interface. > > The problem actually gets worse if you don't have an SPD per physical > interface. If you had only one SPD on the box, then all your any,any > selectors will now exist in the single SPD, and hence causing a bigger > problem. > > From > > a router customer point of view, the customer wants to see IPsec > > tunneling similar to a GRE tunneling and let the forwarding table decide > > what packets should be forwarded to IPsec tunnel. Here, the forwarding > > table is the SPD for me (a global one), not a per interface SPD. > > The routing table effectively becomes the SPD in a sense, or in other > words, it decides what selector(virtual IPsec tunnel) needs to be used, > based on the routing (network topology) information. There would be only > one SA in the SAD of the virtual IPsec tunnel interface, which is any,any > selector, and you won't need to have an SAD on the actual physical > interface that data will ultimately go through. Exactly. > On the actual physical interface, you will still have an SPD, We are talking about a global SPD here, not a per interface SPD. > moment someone sends you a any,any selector, we should not include that > SA into the SAD of the physical interface, but instead create a virtual > interface for that IPsec tunnel, with tunnel endpoints as the local IPsec > endpoint and remote IPsec endpoint, and have a single SA with the selector > any,any on that virtual IPsec tunnel. > > Now, when routing decides to forward any outgoing traffic onto any of the > IPsec virtual tunnels, the single SA that is on the IPsec virtual tunnel > is applied to all that traffic. Exactly. Isn't it simpler solution (atleast from a router point of view) ? Thanks, Kalyan. From owner-ipsec@lists.tislabs.com Fri Apr 5 15:57: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 g35Nvgm16858; Fri, 5 Apr 2002 15:57:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08765 Fri, 5 Apr 2002 18:22:28 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3CAE2BFC.5C8CBC41@juniper.net> References: <3CAE2BFC.5C8CBC41@juniper.net> Date: Fri, 5 Apr 2002 18:29:23 -0500 To: kalyan@juniper.net From: Stephen Kent Subject: Re: Is TS agreement necessary? Cc: ipsec mailling list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:58 PM -0800 4/5/02, Kalyan Bade wrote: > > What does any,any mean in an SAD? How do you differentiate between any,any >> to peer1, from any,any to peer2? If you use the same interface to go out >> to peer1 and peer2, and the same SAD is being used for all the SAs on that >> interface, when there is some data traffic, the traffic will hit all the >> any,any selectors in the SAD. How do you decide which selector to pick, >> and hence which peer to send the data to? >> >> By having an interoperable agreement of what an any,any selector means, >> the IPsec peers can probably agree to create a virtual tunnel interface >> for all any,any selectors, so that routing can differentiate between the >> any,any tunnels, and route the traffic appropriately. Without making that >> assumption, if we send an any,any to a peer, then that would probably >> confuse the peer, and make it send ALL traffic to me (atleast all traffic >> on that interface). > >Agreed. This problem arises only when I have an SPD per interface. From >a router customer point of view, the customer wants to see IPsec >tunneling similar to a GRE tunneling and let the forwarding table decide >what packets should be forwarded to IPsec tunnel. Here, the forwarding >table is the SPD for me (a global one), not a per interface SPD. Please >correct me if I misunderstood the whole IPsec concept as it should be >looked at. > >Thanks, >Kalyan. RFC 2401 is reasonably clear in noting that the SPD is nominally per interface. What sort of management interface is provided to a client is up to the vendor, so long as one can achieve the same effects as a per-interface SPD. Otherwise, the implementation would not be compliant. Steve From owner-ipsec@lists.tislabs.com Fri Apr 5 16:04:35 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 g3604Ym16981; Fri, 5 Apr 2002 16:04:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08815 Fri, 5 Apr 2002 18:30:48 -0500 (EST) Date: Fri, 5 Apr 2002 15:42:25 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Kalyan Bade cc: Stephen Kent , ipsec mailling list Subject: Re: Is TS agreement necessary? In-Reply-To: <3CAE3333.50F78DE8@juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 5 Apr 2002, Kalyan Bade wrote: > "Chinna N.R. Pellacuru" wrote: > > > > On Fri, 5 Apr 2002, Kalyan Bade wrote: > > > > > > What does any,any mean in an SAD? How do you differentiate between any,any > > > > to peer1, from any,any to peer2? If you use the same interface to go out > > > > to peer1 and peer2, and the same SAD is being used for all the SAs on that > > > > interface, when there is some data traffic, the traffic will hit all the > > > > any,any selectors in the SAD. How do you decide which selector to pick, > > > > and hence which peer to send the data to? > > > > > > > > By having an interoperable agreement of what an any,any selector means, > > > > the IPsec peers can probably agree to create a virtual tunnel interface > > > > for all any,any selectors, so that routing can differentiate between the > > > > any,any tunnels, and route the traffic appropriately. Without making that > > > > assumption, if we send an any,any to a peer, then that would probably > > > > confuse the peer, and make it send ALL traffic to me (atleast all traffic > > > > on that interface). > > > > > > Agreed. This problem arises only when I have an SPD per interface. > > > > The problem actually gets worse if you don't have an SPD per physical > > interface. If you had only one SPD on the box, then all your any,any > > selectors will now exist in the single SPD, and hence causing a bigger > > problem. > > > > From > > > a router customer point of view, the customer wants to see IPsec > > > tunneling similar to a GRE tunneling and let the forwarding table decide > > > what packets should be forwarded to IPsec tunnel. Here, the forwarding > > > table is the SPD for me (a global one), not a per interface SPD. > > > > The routing table effectively becomes the SPD in a sense, or in other > > words, it decides what selector(virtual IPsec tunnel) needs to be used, > > based on the routing (network topology) information. There would be only > > one SA in the SAD of the virtual IPsec tunnel interface, which is any,any > > selector, and you won't need to have an SAD on the actual physical > > interface that data will ultimately go through. > > Exactly. > > > On the actual physical interface, you will still have an SPD, > > We are talking about a global SPD here, not a per interface SPD. > > > moment someone sends you a any,any selector, we should not include that > > SA into the SAD of the physical interface, but instead create a virtual > > interface for that IPsec tunnel, with tunnel endpoints as the local IPsec > > endpoint and remote IPsec endpoint, and have a single SA with the selector > > any,any on that virtual IPsec tunnel. > > > > Now, when routing decides to forward any outgoing traffic onto any of the > > IPsec virtual tunnels, the single SA that is on the IPsec virtual tunnel > > is applied to all that traffic. > > Exactly. Isn't it simpler solution (atleast from a router point of view) > ? > > Thanks, > Kalyan. > Yes, along with the simplicity, we also get performance, because we punt the packet classification, and access control problem to the firewall folks. It's their problem anyway, and they do a very good job at that. That is their sole purpose of existance. Atleast IPsec won't be the bottleneck anymore :-) Otherwise if we do limited access control in IPsec, and people generally want more, it is redundant and hence the packet is subjected to packet classification multiple times, in it's life through the box. Once for the incoming firewall inspect, once by IPsec, and one for the outgoing firewall inspect, and it has generally been a big problem of coordinating all these inspection policies with the IPsec policies. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 5 16:26: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 g360QGm17367; Fri, 5 Apr 2002 16:26:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08993 Fri, 5 Apr 2002 18:45:10 -0500 (EST) Message-ID: <3CAE39C2.1683C364@juniper.net> Date: Fri, 05 Apr 2002 15:56:50 -0800 From: Kalyan Bade Reply-To: kalyan@juniper.net Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec mailling list Subject: Re: Is TS agreement necessary? References: <3CAE2BFC.5C8CBC41@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > At 2:58 PM -0800 4/5/02, Kalyan Bade wrote: > > > What does any,any mean in an SAD? How do you differentiate between any,any > >> to peer1, from any,any to peer2? If you use the same interface to go out > >> to peer1 and peer2, and the same SAD is being used for all the SAs on that > >> interface, when there is some data traffic, the traffic will hit all the > >> any,any selectors in the SAD. How do you decide which selector to pick, > >> and hence which peer to send the data to? > >> > >> By having an interoperable agreement of what an any,any selector means, > >> the IPsec peers can probably agree to create a virtual tunnel interface > >> for all any,any selectors, so that routing can differentiate between the > >> any,any tunnels, and route the traffic appropriately. Without making that > >> assumption, if we send an any,any to a peer, then that would probably > >> confuse the peer, and make it send ALL traffic to me (atleast all traffic > >> on that interface). > > > >Agreed. This problem arises only when I have an SPD per interface. From > >a router customer point of view, the customer wants to see IPsec > >tunneling similar to a GRE tunneling and let the forwarding table decide > >what packets should be forwarded to IPsec tunnel. Here, the forwarding > >table is the SPD for me (a global one), not a per interface SPD. Please > >correct me if I misunderstood the whole IPsec concept as it should be > >looked at. > > > >Thanks, > >Kalyan. > > RFC 2401 is reasonably clear in noting that the SPD is nominally per > interface. What sort of management interface is provided to a client > is up to the vendor, so long as one can achieve the same effects as a > per-interface SPD. Otherwise, the implementation would not be > compliant. Well, the point is whether TS agreement is necessary ? IPsec doesn't really need to know about the phase2 selectors as the routing protocols decide what selectors are allowed on a particular IPsec tunnel. It is decided dynamically depending on the topology and I would say we should be able to do an IKE negotiation without any TS. Thanks, Kalyan. From owner-ipsec@lists.tislabs.com Fri Apr 5 16:36: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 g360aKm17549; Fri, 5 Apr 2002 16:36:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09052 Fri, 5 Apr 2002 18:50:19 -0500 (EST) Message-Id: <4.3.2.7.1.20020405160015.00bb7e60@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Apr 2002 16:00:30 -0800 To: "Chinna N.R. Pellacuru" , ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Re: Is TS agreement necessary? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:55 PM 4/5/02 -0800, you wrote: >On Fri, 5 Apr 2002, Kalyan Bade wrote: > > > > Infact the majority of what we call "site-to-site" deployments use GRE as > > > a point-to-point virtual link, and use IPsec to protect the GRE tunnel. > > > But, not everybody implements GRE, and this becomes an interoperability > > > issue. > > > > > > I agree, it would be very useful to specify an interoperable way of > having > > > an IPsec tunnel be treated as a virtual point-to-point link, and not have > > > to rely on GRE always. GRE has some more benefits like we can encapsulate > > > all kinds of protocols in GRE, and not just IP. > > > > I agree that it can done with GRE + IPsec transport mode. But, why in > > the first place we have to do GRE when we can tunnel it directly through > > IPsec (talking about IP traffic only). Is the RFC against it ? Am I > > missing anything here ? > > > > Thanks, > > Kalyan. > > > >What does any,any mean in an SAD? How do you differentiate between any,any >to peer1, from any,any to peer2? If you use the same interface to go out >to peer1 and peer2, and the same SAD is being used for all the SAs on that >interface, when there is some data traffic, the traffic will hit all the >any,any selectors in the SAD. How do you decide which selector to pick, >and hence which peer to send the data to? If i understood correctly, Kalyan's mail, It's just a point to point link so there is no need to distingush the traffic. I mean all the traffic leaving at that interface will be tunneld irrespective of the destiantion beyond the other end of the tunnel. >By having an interoperable agreement of what an any,any selector means, >the IPsec peers can probably agree to create a virtual tunnel interface >for all any,any selectors, so that routing can differentiate between the >any,any tunnels, and route the traffic appropriately. Without making that >assumption, if we send an any,any to a peer, then that would probably >confuse the peer, and make it send ALL traffic to me (atleast all traffic >on that interface). > >Given that routing is way way more efficient and generally highly >optimized, compared to packet classification, we can also get a big jump >in performance. Eliminating packet classification requirement in the data >path brings along with it a lot of other benefits too. I have seen packet >classification being one of the biggest bottlenecks in many >implementations. From owner-ipsec@lists.tislabs.com Fri Apr 5 16:36: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 g360aom17567; Fri, 5 Apr 2002 16:36:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09103 Fri, 5 Apr 2002 18:56:03 -0500 (EST) Date: Fri, 5 Apr 2002 16:07:43 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Ramana Yarlagadda cc: ipsec@lists.tislabs.com Subject: Re: Is TS agreement necessary? In-Reply-To: <4.3.2.7.1.20020405160015.00bb7e60@golf.cpgdesign.analog.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 5 Apr 2002, Ramana Yarlagadda wrote: > At 12:55 PM 4/5/02 -0800, you wrote: > >On Fri, 5 Apr 2002, Kalyan Bade wrote: > > > > > > Infact the majority of what we call "site-to-site" deployments use GRE as > > > > a point-to-point virtual link, and use IPsec to protect the GRE tunnel. > > > > But, not everybody implements GRE, and this becomes an interoperability > > > > issue. > > > > > > > > I agree, it would be very useful to specify an interoperable way of > > having > > > > an IPsec tunnel be treated as a virtual point-to-point link, and not have > > > > to rely on GRE always. GRE has some more benefits like we can encapsulate > > > > all kinds of protocols in GRE, and not just IP. > > > > > > I agree that it can done with GRE + IPsec transport mode. But, why in > > > the first place we have to do GRE when we can tunnel it directly through > > > IPsec (talking about IP traffic only). Is the RFC against it ? Am I > > > missing anything here ? > > > > > > Thanks, > > > Kalyan. > > > > > > >What does any,any mean in an SAD? How do you differentiate between any,any > >to peer1, from any,any to peer2? If you use the same interface to go out > >to peer1 and peer2, and the same SAD is being used for all the SAs on that > >interface, when there is some data traffic, the traffic will hit all the > >any,any selectors in the SAD. How do you decide which selector to pick, > >and hence which peer to send the data to? > > If i understood correctly, Kalyan's mail, > > It's just a point to point link so there is no need to distingush the > traffic. I mean all the traffic leaving at that interface will be > tunneld irrespective of the destiantion beyond the other end of the > tunnel. I was referring to the SAD on the physical interface. If the SA was inserted into the SAD on the physical interface, as is generally done, then all traffic on that interface will suddenly match this new any,any selector, and possibly other selectors too. If traffic starts to match multiple any,any selectors, then we cannot decide what to do. That is why we need an agreement for interoperability. chinna > > > >By having an interoperable agreement of what an any,any selector means, > >the IPsec peers can probably agree to create a virtual tunnel interface > >for all any,any selectors, so that routing can differentiate between the > >any,any tunnels, and route the traffic appropriately. Without making that > >assumption, if we send an any,any to a peer, then that would probably > >confuse the peer, and make it send ALL traffic to me (atleast all traffic > >on that interface). > > > >Given that routing is way way more efficient and generally highly > >optimized, compared to packet classification, we can also get a big jump > >in performance. Eliminating packet classification requirement in the data > >path brings along with it a lot of other benefits too. I have seen packet > >classification being one of the biggest bottlenecks in many > >implementations. > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 5 16:36: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 g360asm17581; Fri, 5 Apr 2002 16:36:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09135 Fri, 5 Apr 2002 18:58:59 -0500 (EST) Message-ID: <3CAE3D01.10001@isi.edu> Date: Fri, 05 Apr 2002 16:10:41 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020329 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Stephen Kent CC: kalyan@juniper.net, ipsec mailling list , Joe Touch Subject: Re: Is TS agreement necessary? References: <3CAE2BFC.5C8CBC41@juniper.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030605000106050205080302" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms030605000106050205080302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen Kent wrote: > RFC 2401 is reasonably clear in noting that the SPD is nominally per > interface. What sort of management interface is provided to a client is > up to the vendor, so long as one can achieve the same effects as a > per-interface SPD. Otherwise, the implementation would not be compliant. As a side note, I misunderstood this for a long time to mean "SPD per PHYSICAL interface", which is not sufficient (because of ambiguities via multiple matching tunnel-mode SAs in the same per-physical-interface SPD). When viewing tunnel mode SAs as virtual interfaces in their own right that have separate SPDs associated with them, these problems dissapear. Maybe that's part of the confusion around tunnel mode... Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms030605000106050205080302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQwNjAwMTA0MVowIwYJKoZIhvcNAQkEMRYEFHCv88/w8V/78mHklil8UHBe2VGSMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCSGtO8iX8UBvBmloFF2ex0CLaCULe7myCmvQuLoQaT4QTa7ro+Ds4N4Mps/Q+HTcGd h0wyxkW2nIwA/w6cyL4piIg9r/2Eq6tcnwkCciHGdXarqCsa4YUzTVat70kWrEYWSjLh3rA1 KsywolsCIA9DYJOcl+T8B2LzfdbVjn+pdAAAAAAAAA== --------------ms030605000106050205080302-- From owner-ipsec@lists.tislabs.com Fri Apr 5 16:36: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 g360asm17580; Fri, 5 Apr 2002 16:36:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09087 Fri, 5 Apr 2002 18:53:38 -0500 (EST) Date: 5 Apr 2002 18:56:54 -0500 Message-ID: <001601c1dcfd$91bca320$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: sommerfeld@east.sun.com, " 'Jan Vilhuber'" Cc: "'Paul Hoffman / VPNC'" , " 'Tero Kivinen'" , " " Subject: dynamic ports vs. rekeying 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: <200204051928.g35JSgss012325@thunk.east.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think dynamic selectors are different from rekeying. Not only does updating the selectors of the existing SA save bits on the wire, but from a robustness point of view, it means that to any synchronization errors between the peers will only affect the new traffic. Imagine there is a race condition between the QM3 (or Create_Child_Sa2) and the data traffic. The most reliable thing to do is to send the old traffic on the old SA for a short while and send the new traffic on the new SA (since the selectors won't match the old SA). Wouldn't it be easier to send send all traffic on the new SA automatically because the new SA is the old SA? If the selectors haven't been updated yet then new traffic will be dropped for a short while. On the subject of rekeying, I agree that using the old phase 1s until they expired (as specified in draft-jenkins) didn't work, but the immediate switch-over in draft-specncer is too hasty. I recommend that an implementation should continue to use its old SA for a short time (e.g. 30 seconds) after the new one is negotiated to account for any lost packets. It should also wait a short time after that before deleting the old SA. ------------------------------------------- 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 Bill Sommerfeld > Sent: Friday, April 05, 2002 2:29 PM > To: Jan Vilhuber > Cc: Bill Sommerfeld; Paul Hoffman / VPNC; Tero Kivinen; > ipsec@lists.tislabs.com > Subject: Re: Do we actually need dynamic ports? > > > > Well the draft that Pyda wrote changes the payload so that it's NOT > > ambiguous (it tags each SA with a policy ID, so you always know > > exactly which traffic-policy you're talking about (even if > your SPI's > > may change), and added an add/remove flag). > > I wasn't thinking of reordering within the KM protocol, but rather > reordering between the KM protocol and AH/ESP traffic, especially in > the case of selector deletion. > > If the SPI changes, we reduce selector-set changes to the same > [un]solved problem as graceful rekeying ;-) > > - Bill > From owner-ipsec@lists.tislabs.com Fri Apr 5 16:39:35 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 g360dZm17614; Fri, 5 Apr 2002 16:39:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09190 Fri, 5 Apr 2002 19:02:43 -0500 (EST) Date: Fri, 5 Apr 2002 16:14:20 -0800 (PST) From: Jan Vilhuber To: Andrew Krywaniuk cc: , "'Paul Hoffman / VPNC'" , "'Tero Kivinen'" , Subject: Re: dynamic ports vs. rekeying In-Reply-To: <001601c1dcfd$91bca320$1e72788a@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 5 Apr 2002, Andrew Krywaniuk wrote: > I think dynamic selectors are different from rekeying. Not only does > updating the selectors of the existing SA save bits on the wire, but from a > robustness point of view, it means that to any synchronization errors > between the peers will only affect the new traffic. > > Imagine there is a race condition between the QM3 (or Create_Child_Sa2) and > the data traffic. The most reliable thing to do is to send the old traffic > on the old SA for a short while and send the new traffic on the new SA > (since the selectors won't match the old SA). Wouldn't it be easier to send > send all traffic on the new SA automatically because the new SA is the old > SA? If the selectors haven't been updated yet then new traffic will be > dropped for a short while. > > On the subject of rekeying, I agree that using the old phase 1s until they > expired (as specified in draft-jenkins) didn't work, but the immediate > switch-over in draft-specncer is too hasty. I recommend that an > implementation should continue to use its old SA for a short time (e.g. 30 > seconds) after the new one is negotiated to account for any lost packets. It > should also wait a short time after that before deleting the old SA. > Is this still an issue in ikev2? Quick mode is no longer 3 messages, so the responder can immediately install all SA's and the initiator can start sending when he receives the reply... jan > ------------------------------------------- > 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 Bill Sommerfeld > > Sent: Friday, April 05, 2002 2:29 PM > > To: Jan Vilhuber > > Cc: Bill Sommerfeld; Paul Hoffman / VPNC; Tero Kivinen; > > ipsec@lists.tislabs.com > > Subject: Re: Do we actually need dynamic ports? > > > > > > > Well the draft that Pyda wrote changes the payload so that it's NOT > > > ambiguous (it tags each SA with a policy ID, so you always know > > > exactly which traffic-policy you're talking about (even if > > your SPI's > > > may change), and added an add/remove flag). > > > > I wasn't thinking of reordering within the KM protocol, but rather > > reordering between the KM protocol and AH/ESP traffic, especially in > > the case of selector deletion. > > > > If the SPI changes, we reduce selector-set changes to the same > > [un]solved problem as graceful rekeying ;-) > > > > - Bill > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Apr 5 16:45: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 g360jhm17734; Fri, 5 Apr 2002 16:45:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09176 Fri, 5 Apr 2002 19:02:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3CAE39C2.1683C364@juniper.net> References: <3CAE2BFC.5C8CBC41@juniper.net> <3CAE39C2.1683C364@juniper.net> Date: Fri, 5 Apr 2002 19:14:21 -0500 To: kalyan@juniper.net From: Stephen Kent Subject: Re: Is TS agreement necessary? Cc: ipsec mailling list Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:56 PM -0800 4/5/02, Kalyan Bade wrote: > > > >> RFC 2401 is reasonably clear in noting that the SPD is nominally per >> interface. What sort of management interface is provided to a client >> is up to the vendor, so long as one can achieve the same effects as a >> per-interface SPD. Otherwise, the implementation would not be >> compliant. > >Well, the point is whether TS agreement is necessary ? IPsec doesn't >really need to know about the phase2 selectors as the routing protocols >decide what selectors are allowed on a particular IPsec tunnel. It is >decided dynamically depending on the topology and I would say we should >be able to do an IKE negotiation without any TS. > >Thanks, >Kalyan. IPsec is implemented in end systems, BITW devices, and security gateways. I'm not convinced that your comment above applies to all of these cases. For example, which routing protocols running in my host are you referring to? The question of the need to exchange TS values in IKE is much broader than the narrow issue that this thread is now focusing on. Steve From owner-ipsec@lists.tislabs.com Fri Apr 5 16:59: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 g360xtm17925; Fri, 5 Apr 2002 16:59:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09356 Fri, 5 Apr 2002 19:23:32 -0500 (EST) Date: Fri, 5 Apr 2002 16:35:13 -0800 (PST) From: "Chinna N.R. Pellacuru" To: Stephen Kent cc: kalyan@juniper.net, ipsec mailling list Subject: Re: Is TS agreement necessary? 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 Fri, 5 Apr 2002, Stephen Kent wrote: > At 3:56 PM -0800 4/5/02, Kalyan Bade wrote: > > > > > > > > >> RFC 2401 is reasonably clear in noting that the SPD is nominally per > >> interface. What sort of management interface is provided to a client > >> is up to the vendor, so long as one can achieve the same effects as a > >> per-interface SPD. Otherwise, the implementation would not be > >> compliant. > > > >Well, the point is whether TS agreement is necessary ? IPsec doesn't > >really need to know about the phase2 selectors as the routing protocols > >decide what selectors are allowed on a particular IPsec tunnel. It is > >decided dynamically depending on the topology and I would say we should > >be able to do an IKE negotiation without any TS. > > > >Thanks, > >Kalyan. > > IPsec is implemented in end systems, BITW devices, and security > gateways. I'm not convinced that your comment above applies to all of > these cases. For example, which routing protocols running in my host > are you referring to? > > The question of the need to exchange TS values in IKE is much broader > than the narrow issue that this thread is now focusing on. > > Steve > Even in end systems, we can differentiate scenarios based on whether it is doing transport mode, or a tunnel mode to a security gateway. If the end host is doing tunnel mode to a security gateway, then how is this scenario different from a Mobile Node having a tunnel to a Home Agent? Even though end-hosts don't run routing protocols, they do routing, most of the time static routing, and with out even static routing capabilities, the end-hosts are not very useful if you want to do IP features like Mobile-IP and IPsec. The mobile node software running on the end host setup the right static routes in the routing table for example if it decides to send all traffic back to the Home Agent or if it wants to just forward the traffic to the corresponding node to the Foriegn agent. Anyway my point is that end hosts can do routing, even if they don't run routing protocols. They don't have to do routing, and as far as I can see, neither do they have to do TS negotiation, if there is a general agreement as to what doing no TS negotiation means. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 5 18:41: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 g362frm19497; Fri, 5 Apr 2002 18:41:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10231 Fri, 5 Apr 2002 20:57:16 -0500 (EST) Message-ID: <3CAE58B9.9060404@isi.edu> Date: Fri, 05 Apr 2002 18:08:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Eggert CC: Stephen Kent , kalyan@juniper.net, ipsec mailling list Subject: Re: Is TS agreement necessary? References: <3CAE2BFC.5C8CBC41@juniper.net> <3CAE3D01.10001@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lars Eggert wrote: > Stephen Kent wrote: > >> RFC 2401 is reasonably clear in noting that the SPD is nominally per >> interface. What sort of management interface is provided to a client >> is up to the vendor, so long as one can achieve the same effects as a >> per-interface SPD. Otherwise, the implementation would not be compliant > > As a side note, I misunderstood this for a long time to mean "SPD per > PHYSICAL interface", which is not sufficient (because of ambiguities via > multiple matching tunnel-mode SAs in the same per-physical-interface > SPD). When viewing tunnel mode SAs as virtual interfaces in their own > right that have separate SPDs associated with them, these problems > dissapear. Maybe that's part of the confusion around tunnel mode... > Lars Hi, Steve, One of the confusions I have is regarding systems that say they use these tunnel mode SAs as virtual interfaces. It seems that the tunnel SA has to be in the SPD of the underlying interface, but they only work if the SA is in the SPD of the virtual interface (i.e., inside the tunnel). That seems self-referential... ?? Joe From owner-ipsec@lists.tislabs.com Fri Apr 5 22:28: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 g366Som23158; Fri, 5 Apr 2002 22:28:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA12154 Sat, 6 Apr 2002 00:42:41 -0500 (EST) Date: Sat, 6 Apr 2002 00:54:17 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: dynamic ports vs. rekeying In-Reply-To: <001601c1dcfd$91bca320$1e72788a@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 5 Apr 2002, Andrew Krywaniuk wrote: > On the subject of rekeying, I agree that using the old phase 1s until they > expired (as specified in draft-jenkins) didn't work, but the immediate > switch-over in draft-specncer is too hasty. I assume you're speaking in the context of rekeying which also plays games with selectors? Without that, we have extensive operational proof that the immediate cutover works just fine... Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Apr 6 03:10: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 g36BADm28598; Sat, 6 Apr 2002 03:10:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA14404 Sat, 6 Apr 2002 05:20:32 -0500 (EST) Message-ID: <20020406103244.48882.qmail@web12805.mail.yahoo.com> Date: Sat, 6 Apr 2002 02:32:44 -0800 (PST) From: SHSM MNSY To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk thanks __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-ipsec@lists.tislabs.com Sat Apr 6 06:12: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 g36ECqm09151; Sat, 6 Apr 2002 06:12:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15978 Sat, 6 Apr 2002 08:32:46 -0500 (EST) Message-Id: <3.0.3.32.20020406054529.01331868@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sat, 06 Apr 2002 05:45:29 -0800 To: Jan Vilhuber , Uri Blumenthal From: Alex Alten Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Cc: Michael Thomas , Jari Arkko , , , In-Reply-To: References: <200204041832.NAA05665@nwmail.wh.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 02:07 PM 4/4/2002 -0800, Jan Vilhuber wrote: >On Thu, 4 Apr 2002, Uri Blumenthal wrote: > >> On Wednesday 03 April 2002 12:51, Michael Thomas wrote: >> >> I don't think that "interoperability" is quite >> > the right word here. A mobile node and home agent >> > which run IPsec/IKE could be interoperable. >> > However, in practice unless I am part of that >> > domain, know the right authentication >> > mechanisms, etc, we might not be able to >> > mutually authenticate. >> >> Hmm, I see your point. But: >> >> > This is a deployment >> > issue, however, not an interoperability issue. >> >> Not quite, because if one implementation chose KINK >> and another - IKE, they won't be able to talk regardless. >> > >And this was the reason whereby Radia finally convinced me that having >multiple key negotiation protocols (like we have multiple routing >protocols: Different situations require different routing protocols, >so why not different keying protocols?) is not such a good thing >afterall. > >For specific point-solutions (IP phones that can only talk to one >call-manager, for example) or wherever all devices are under one >administrative domain, having special keying protocols is OK. For the >internet at large, where you don't necessarily know who you'll be >talking to, not knowing what protocol you'll have to use is clearly >not a good thing. > I agree with this and would go further and keep the number of block ciphers/modes/key lengths to a minimum (AES-ECB-256 & 3DES-ECB). Public key usage should be a rarely used authentication option and then only RSA (because of slowness keys will need to be variable, but 1024 should be the supported default). All key material should be distributed over single IP datagrams without fragmentation (UDP should be an option, especially to help with system debugging). All random material used for keys should come from HW random source, either internal (Intel P4 RNG) or from external source, and use a CRC to detect bit errors during storage retreival or post-flight arrival. Default operation should be with a raw authentication key inside the stack, with optional local-only KIK or password protection when it is stored on disk (for shutdown/reboot). I'd recommend that the WG put out a request for a custom hash, with a keyed option, designed to support IPv4 explicitly. It needs to be much faster than the current iterative hashes (HMAC is massive overkill). In lieu of this, then only use SHA-1 and possibly SHA-2. Policy enforcement should be centralized within an autonomous system to keep host implementations simple and to avoid the overhead of synchronizing too many databases. Goodnight, - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Sun Apr 7 07:38: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 g37Ecam27459; Sun, 7 Apr 2002 07:38:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25393 Sun, 7 Apr 2002 09:28:21 -0400 (EDT) Message-ID: <000801c1de39$9e1409a0$d9551ad4@natasha> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Jan Vilhuber" , "Uri Blumenthal" , "Alex Alten" Cc: "Michael Thomas" , "Jari Arkko" , , , References: <200204041832.NAA05665@nwmail.wh.lucent.com> <3.0.3.32.20020406054529.01331868@mail> Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Date: Sun, 7 Apr 2002 16:39:06 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1DE52.BBDA1240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Disposition-Notification-To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1DE52.BBDA1240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi to All Real life situations have shown the need for multiple key nego. = protocols, rather than depending on D-H only which is what IKE is using. Regards Ahmed alaadas@kaau.edu.sa ----- Original Message -----=20 From: Alex Alten=20 To: Jan Vilhuber ; Uri Blumenthal=20 Cc: Michael Thomas ; Jari Arkko ; ipsec@lists.tislabs.com ; = marcovici@lucent.com ; Black_David@emc.com=20 Sent: Saturday, April 06, 2002 4:45 PM Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? At 02:07 PM 4/4/2002 -0800, Jan Vilhuber wrote: >On Thu, 4 Apr 2002, Uri Blumenthal wrote: > >> On Wednesday 03 April 2002 12:51, Michael Thomas wrote: >> >> I don't think that "interoperability" is quite >> > the right word here. A mobile node and home agent >> > which run IPsec/IKE could be interoperable. >> > However, in practice unless I am part of that >> > domain, know the right authentication >> > mechanisms, etc, we might not be able to >> > mutually authenticate. >> >> Hmm, I see your point. But: >> >> > This is a deployment >> > issue, however, not an interoperability issue. >> >> Not quite, because if one implementation chose KINK >> and another - IKE, they won't be able to talk regardless. >> > >And this was the reason whereby Radia finally convinced me that = having >multiple key negotiation protocols (like we have multiple routing >protocols: Different situations require different routing protocols, >so why not different keying protocols?) is not such a good thing >afterall. > >For specific point-solutions (IP phones that can only talk to one >call-manager, for example) or wherever all devices are under one >administrative domain, having special keying protocols is OK. For the >internet at large, where you don't necessarily know who you'll be >talking to, not knowing what protocol you'll have to use is clearly >not a good thing. > I agree with this and would go further and keep the number of block ciphers/modes/key lengths to a minimum (AES-ECB-256 & 3DES-ECB).=20 Public key usage should be a rarely used authentication option and then only RSA (because of slowness keys will need to be variable, but 1024 should be the supported default). All key material should be distributed over single IP datagrams without fragmentation (UDP should be an option, especially to help with system debugging). All random material used for keys should come from HW random source, either internal (Intel P4 RNG) or from external source, and use a CRC to detect bit errors during storage retreival or post-flight arrival. Default operation should be with a raw authentication key inside the stack, with optional local-only KIK or password=20 protection when it is stored on disk (for shutdown/reboot). I'd recommend that the WG put out a request for a custom hash, with a keyed option, designed to support IPv4 explicitly. It needs to be much faster than the current iterative hashes (HMAC is massive overkill). In lieu of this, then only use SHA-1 and possibly SHA-2. Policy enforcement should be centralized within an autonomous system to keep host implementations simple and to avoid the overhead of synchronizing too many databases. Goodnight, - Alex -- Alex Alten Alten@ATTBI.com ------=_NextPart_000_0005_01C1DE52.BBDA1240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi to All
 
 
Real life situations have shown the = need for=20 multiple key nego. protocols, rather than depending on D-H = only
 
which is what IKE is = using.
 
Regards
 
Ahmed
 
alaadas@kaau.edu.sa
----- Original Message -----
From:=20 Alex = Alten
Cc: Michael Thomas ; Jari=20 Arkko ; ipsec@lists.tislabs.com ; = marcovici@lucent.com ; Black_David@emc.com
Sent: Saturday, April 06, 2002 = 4:45=20 PM
Subject: Re: [mobile-ip] Re: = replacing=20 IPsec's replay protection?

At 02:07 PM 4/4/2002 -0800, Jan Vilhuber = wrote:
>On Thu,=20 4 Apr 2002, Uri Blumenthal wrote:
>
>> On Wednesday 03 = April=20 2002 12:51, Michael Thomas wrote:
>>  = >>   I=20 don't think that "interoperability" is quite
>> =20 >   the right word here. A mobile node and home=20 agent
>>  >   which run IPsec/IKE could be=20 interoperable.
>>  >   However, in practice = unless=20 I am part of that
>>  >   domain, know the = right=20 authentication
>>  >   mechanisms, etc, we = might=20 not be able to
>>  >   mutually=20 authenticate.
>>
>> Hmm, I see your point.=20 But:
>>
>>  >  This is a=20 deployment
>>  >   issue, however, not an=20 interoperability issue.
>>
>> Not quite, because if = one=20 implementation chose KINK
>> and another - IKE, they won't be = able to=20 talk regardless.
>>
>
>And this was the reason = whereby=20 Radia finally convinced me that having
>multiple key negotiation = protocols (like we have multiple routing
>protocols: Different=20 situations require different routing protocols,
>so why not = different=20 keying protocols?) is not such a good=20 thing
>afterall.
>
>For specific point-solutions (IP = phones=20 that can only talk to one
>call-manager, for example) or = wherever all=20 devices are under one
>administrative domain, having special = keying=20 protocols is OK. For the
>internet at large, where you don't = necessarily=20 know who you'll be
>talking to, not knowing what protocol you'll = have to=20 use is clearly
>not a good thing.
>

I agree with = this and=20 would go further and keep the number of block
ciphers/modes/key = lengths to=20 a minimum (AES-ECB-256 & 3DES-ECB).
Public key usage should be = a=20 rarely used authentication option and
then only RSA (because of = slowness=20 keys will need to be variable,
but 1024 should be the supported = default).=20 All key material should
be distributed over single IP datagrams = without=20 fragmentation (UDP
should be an option, especially to help with = system=20 debugging).  All
random material used for keys should come = from HW=20 random source,
either internal (Intel P4 RNG) or from external = source, and=20 use a
CRC to detect bit errors during storage retreival or=20 post-flight
arrival. Default operation should be with a raw=20 authentication
key inside the stack, with optional local-only KIK = or=20 password
protection when it is stored on disk (for=20 shutdown/reboot).

I'd recommend that the WG put out a request = for a=20 custom hash, with
a keyed option, designed to support IPv4=20 explicitly.  It needs to be
much faster than the current = iterative=20 hashes (HMAC is massive
overkill).  In lieu of this, then only = use=20 SHA-1 and possibly SHA-2.

Policy enforcement should be = centralized=20 within an autonomous system
to keep host implementations simple and = to=20 avoid the overhead of
synchronizing too many=20 databases.

Goodnight,

-=20 Alex






--

Alex Alten
Alten@ATTBI.com
------=_NextPart_000_0005_01C1DE52.BBDA1240-- From owner-ipsec@lists.tislabs.com Sun Apr 7 10:56: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 g37Hucm13181; Sun, 7 Apr 2002 10:56:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26431 Sun, 7 Apr 2002 13:13:14 -0400 (EDT) Message-Id: <3.0.5.32.20020407122928.007c2600@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 07 Apr 2002 12:29:28 -0400 To: Joe Touch , Lars Eggert From: Mark Duffy Subject: Re: Is TS agreement necessary? Cc: Stephen Kent , kalyan@juniper.net, ipsec mailling list In-Reply-To: <3CAE58B9.9060404@isi.edu> References: <3CAE2BFC.5C8CBC41@juniper.net> <3CAE3D01.10001@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:08 PM 4/5/02 -0800, Joe Touch wrote: >Lars Eggert wrote: >> Stephen Kent wrote: >> >>> RFC 2401 is reasonably clear in noting that the SPD is nominally per >>> interface. What sort of management interface is provided to a client >>> is up to the vendor, so long as one can achieve the same effects as a >>> per-interface SPD. Otherwise, the implementation would not be compliant >> >> As a side note, I misunderstood this for a long time to mean "SPD per >> PHYSICAL interface", which is not sufficient (because of ambiguities via >> multiple matching tunnel-mode SAs in the same per-physical-interface >> SPD). When viewing tunnel mode SAs as virtual interfaces in their own >> right that have separate SPDs associated with them, these problems >> dissapear. Maybe that's part of the confusion around tunnel mode... >> Lars > >Hi, Steve, > >One of the confusions I have is regarding systems that say they use >these tunnel mode SAs as virtual interfaces. It seems that the tunnel SA >has to be in the SPD of the underlying interface, but they only work if >the SA is in the SPD of the virtual interface (i.e., inside the tunnel). >That seems self-referential... ?? > >Joe I'm not Steve but I'll pipe up anyway :-) It doesn't seem any problem on the outgoing side -- first the forwarding decision selects the outgoing interface (the tunnel). Then the SPD for that virtual interface is consulted (and it has all-wildcard selectors for the single tunnel mode SA). The packet is encapsulated and a new forwarding decision made. When we are the IKE responder, there is some potential ambiguity. To resolve this there needs to be a way to associate the incoming proposal with the SPD associated with the virtual interface. One way to do this is to use the destination IP address in that case to select the right SPD. Mark From owner-ipsec@lists.tislabs.com Sun Apr 7 12:24: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 g37JNxm19720; Sun, 7 Apr 2002 12:23:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26540 Sun, 7 Apr 2002 14:30:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15536.37661.140000.459344@gargle.gargle.HOWL> Date: Sun, 7 Apr 2002 14:42:37 -0400 From: Paul Koning To: Alten@attbi.com Cc: ipsec@lists.tislabs.com Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? References: <200204041832.NAA05665@nwmail.wh.lucent.com> <3.0.3.32.20020406054529.01331868@mail> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What did all that come from? It sure looks like an amazing collection of strange cryptographic notions -- things like ECB, or a "custom hash" on the grounds that HMAC is "massive overkill". Or the notion that hardware RNGs need to be mandated. paul From owner-ipsec@lists.tislabs.com Sun Apr 7 12:51: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 g37Jpam21546; Sun, 7 Apr 2002 12:51:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26580 Sun, 7 Apr 2002 15:14:33 -0400 (EDT) Message-Id: <3.0.3.32.20020407122710.00eeebb0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 07 Apr 2002 12:27:10 -0700 To: Paul Koning From: Alex Alten Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Cc: ipsec@lists.tislabs.com In-Reply-To: <15536.37661.140000.459344@gargle.gargle.HOWL> References: <200204041832.NAA05665@nwmail.wh.lucent.com> <3.0.3.32.20020406054529.01331868@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, That came from direct experience in the trenchs of building secure networking systems (and cryptograpic algorithms). Basically I'm saying "Keep It Simple Stupid". Pick a single mode (either ECB or CBC). Use a minimum set of ciphers and hashes (preferably one each). Don't be afraid to build tools from scratch to meet specific requirements (like my suggestion for a custom hash). And worry about robustness and reliablity of cryptographic materials (thus the need for good RNG's and CRC checking). My observation of this WG is that it has bogged itself down for years in extra complexity which is the enemy of secure networking systems design. But I'm probably wasting my breath giving you this advice, you don't seem to appreciate or understand it. - Alex At 02:42 PM 4/7/2002 -0400, Paul Koning wrote: >What did all that come from? It sure looks like an amazing collection >of strange cryptographic notions -- things like ECB, or a "custom >hash" on the grounds that HMAC is "massive overkill". Or the notion >that hardware RNGs need to be mandated. > > paul > > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Sun Apr 7 17:42: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 g380gWm05296; Sun, 7 Apr 2002 17:42:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28135 Sun, 7 Apr 2002 19:33:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15536.55833.176000.907713@gargle.gargle.HOWL> Date: Sun, 7 Apr 2002 19:45:29 -0400 From: Paul Koning To: Alten@attbi.com Cc: ipsec@lists.tislabs.com Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? References: <200204041832.NAA05665@nwmail.wh.lucent.com> <3.0.3.32.20020406054529.01331868@mail> <3.0.3.32.20020407122710.00eeebb0@mail> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 7 April 2002) by Alex Alten: > Paul, > > That came from direct experience in the trenchs of building > secure networking systems (and cryptograpic algorithms). > Basically I'm saying "Keep It Simple Stupid". Pick a single > mode (either ECB or CBC). Use a minimum set of ciphers and > hashes (preferably one each). Don't be afraid to build tools > from scratch to meet specific requirements (like my suggestion > for a custom hash). And worry about robustness and reliablity > of cryptographic materials (thus the need for good RNG's > and CRC checking). My observation of this WG is that > it has bogged itself down for years in extra complexity which > is the enemy of secure networking systems design. But I'm > probably wasting my breath giving you this advice, you > don't seem to appreciate or understand it. Insulting people is not a good way to convince others that your ideas are worth listening to, especially if you don't have any justification for your comments. Yes, unnecessary complexity is the enemy of security. But necessary complexity is how you get security. Since you mentioned ECB, I wonder if you are aware of the reasons why ECB is NEVER used for any network security protocol. There are good reasons why it isn't, and it helps to know what they are. paul From owner-ipsec@lists.tislabs.com Sun Apr 7 17:43: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 g380hKm05312; Sun, 7 Apr 2002 17:43:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28262 Sun, 7 Apr 2002 19:53:39 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Date: 7 Apr 2002 23:56:57 GMT Organization: University of California, Berkeley Lines: 10 Distribution: isaac Message-ID: References: <200204041832.NAA05665@nwmail.wh.lucent.com> <3.0.3.32.20020406054529.01331868@mail> <3.0.3.32.20020407122710.00eeebb0@mail> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1018223817 21226 128.32.45.153 (7 Apr 2002 23:56:57 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 7 Apr 2002 23:56:57 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten wrote: >Basically I'm saying "Keep It Simple Stupid". Pick a single >mode (either ECB or CBC). You're kidding, right? Using ECB is like playing in traffic to see if drivers will stop for you ... while wearing dark clothing ... at night. I hope I misunderstood you. Anyway, it's a bit late to be talking about changes like this to IPSec. From owner-ipsec@lists.tislabs.com Mon Apr 8 00:51: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 g387pKm09339; Mon, 8 Apr 2002 00:51:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01345 Mon, 8 Apr 2002 02:50:24 -0400 (EDT) Message-Id: <3.0.3.32.20020408000306.00fb5630@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 08 Apr 2002 00:03:06 -0700 To: Paul Koning From: Alex Alten Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Cc: ipsec@lists.tislabs.com In-Reply-To: <15536.55833.176000.907713@gargle.gargle.HOWL> References: <200204041832.NAA05665@nwmail.wh.lucent.com> <3.0.3.32.20020406054529.01331868@mail> <3.0.3.32.20020407122710.00eeebb0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:45 PM 4/7/2002 -0400, Paul Koning wrote: >Insulting people is not a good way to convince others that your ideas >are worth listening to, especially if you don't have any justification >for your comments. > My apologies Paul. I was a little impatient with you. Unfortunately I don't have the time for laborous justification of my comments. Each one of my sentences reflects hard won knowledge and experience, I would hope you will not take them lightly. >Yes, unnecessary complexity is the enemy of security. But necessary >complexity is how you get security. You sound wonderfully Delphic. I agree with you in principle. The problem is following this in practice, especially with the group of smart, opinionated people found in this WG. > Since you mentioned ECB, I wonder >if you are aware of the reasons why ECB is NEVER used for any network >security protocol. There are good reasons why it isn't, and it helps >to know what they are. Never say NEVER. Yes, I'm perfectly aware of the dangers. But to be fair the other side of the coin is rarely heard. ECB can be much faster than CBC, by computing multiple blocks in parallel and by avoiding the memory move of the extra XOR. Complexity is reduced by getting rid of synchronizing the IV between sender and receiver, and because packet re-ordering is no longer an issue. These are the engineering vs security tradeoffs one has to consider while designing a system. As an example, if your commercial customers wanted to do *only* simple privacy for a SANS then a simple AES-ECB encryption of the IO blocks is a really nice way to go. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Apr 8 06:46: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 g38DkCm14061; Mon, 8 Apr 2002 06:46:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03341 Mon, 8 Apr 2002 08:47:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15537.37888.259000.227717@gargle.gargle.HOWL> Date: Mon, 8 Apr 2002 08:58:40 -0400 From: Paul Koning To: Alten@attbi.com Cc: ipsec@lists.tislabs.com Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? References: <200204041832.NAA05665@nwmail.wh.lucent.com> <3.0.3.32.20020406054529.01331868@mail> <3.0.3.32.20020407122710.00eeebb0@mail> <3.0.3.32.20020408000306.00fb5630@mail> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 8 April 2002) by Alex Alten: > At 07:45 PM 4/7/2002 -0400, Paul Koning wrote: > > Since you mentioned ECB, I wonder > >if you are aware of the reasons why ECB is NEVER used for any network > >security protocol. There are good reasons why it isn't, and it helps > >to know what they are. > > Never say NEVER. Yes, I'm perfectly aware of the dangers. But to be > fair the other side of the coin is rarely heard. ECB can be much faster > than CBC, by computing multiple blocks in parallel and by avoiding the > memory move of the extra XOR. Complexity is reduced by getting rid of > synchronizing the IV between sender and receiver, and because packet > re-ordering is no longer an issue. These are the engineering vs security > tradeoffs one has to consider while designing a system. IPsec uses explicit IV, there is NO synchronization of IV between sender and receiver. Nor is there any issue of packet reordering. You may be confused with SSL. As for the performance cost of CBC: in software, the cost is one load instruction per packet (for the IV) and one XOR instruction per 8 bytes. There is no extra memory move. In hardware, CBC forces serialization of the block processing within a packet. That can limit your ultimate performance (though there are chips available that will do single stream CBC at well above 1 Gb/s). But that doesn't limit your performance in practice, certainly not for multiple SAs, and not even for a single SA when there are multiple packets to process if you do a bit more work (as I did in an implementation of IPsec a few years ago). Finally, if you're interested in a mode that doesn't have the serialization properties of CBC and also avoids the security defects of ECB, take a look at counter mode, currently an I-D. paul From owner-ipsec@lists.tislabs.com Mon Apr 8 06:50:44 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 g38Dohm14336; Mon, 8 Apr 2002 06:50:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03550 Mon, 8 Apr 2002 09:05:46 -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="iso-8859-1" Subject: RE: Do we actually need dynamic ports? Date: Fri, 5 Apr 2002 15:01:35 -0800 Message-ID: Thread-Topic: Do we actually need dynamic ports? Thread-Index: AcHc03QWLIBY/elJRqKCpsqTX7KwDQAHAgOw From: "Sankar Ramamoorthi" To: "Jan Vilhuber" , "Michael Choung Shieh" Cc: "Tero Kivinen " , , "Paul Hoffman / VPNC " X-OriginalArrivalTime: 05 Apr 2002 23:01:36.0089 (UTC) FILETIME=[D6245C90:01C1DCF5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA08495 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Friday, April 05, 2002 9:41 AM > To: Michael Choung Shieh > Cc: 'Tero Kivinen '; 'ipsec@lists.tislabs.com '; 'Paul > Hoffman / VPNC ' > Subject: RE: Do we actually need dynamic ports? > > > On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > > > > Option (b) is to "negotiate a new (expanded) SA" and introduce extra > > lantency. > > How does it add latency over option a, which is negotiate an update? > It will be 1 round-trip in either case. Option b adds a delete > notification, but traffic can start flowing before the delete > notification, so no latency (over option a) is added. > > In any case, unless we reopen the discussion I eluded to, I believe I was the initiator of the discussion that is being eluded to - inband signaling seems to be considered taboo by many (personally I am convinced that esp would have benefitted many ways with some provision for control information, like a few flag bits. We never know what the future requirements bring - I feel it would have been prudent to have introduced atleast a few bits for flags and version#. protocols such as IP, TCP have it. As for performance considerations, many IP packets gets processed in the fast path as ESP). My other proposals such as using a reserved spi to encapsulate the original esp packet to indicate the presence of control information was mainly a way to workaround the initial limitation of absence of control bits in the esp header. Having said that, I agree with you if we rule out inband signaling as an option, a minimum of 1 roundtrip overhead is unavoidable - atleast I cannot think of any. The question I have is 200-500ms roundtrip delay (from Tero's observation) acceptable latency for the expected spectrum of dynamic protocols? I found that from talking to some of my team members that for H.323 atleast since this delay will occur only during call-setup time, it is acceptable. Is it the same case for other so called dynamic protocol scenarios? -- sankar -- >you HAVE to > negotiate with the other end to widen the selectors, so 1 round-trip > is the minimum you can do safely. > > jan > > > > You don't need to reopen any discussion. > > > > However, I guess you recognize it adds more or less lantency to both > > options. > > > > Michael Shieh > > > > -----Original Message----- > > From: Jan Vilhuber > > To: Michael Choung Shieh > > Cc: Tero Kivinen; ipsec@lists.tislabs.com; Paul Hoffman / VPNC > > Sent: 4/4/02 5:28 PM > > Subject: RE: Do we actually need dynamic ports? > > > > On Thu, 4 Apr 2002, Michael Choung Shieh wrote: > > > > > > > > Doing extra IKE to creat a new sa DURING application will > introduce > > extra > > > latency and it may cause packet drop or retransmit. It's > probably not > > > preferred if every FTP put/get will delay one or two seconds when > > passing > > > through IKE. > > > > > > > I don't think I'm going to reopen that discussion. We're > talking about > > the option of: > > > > a) negotiate an 'update' to an SA > > or > > b) negotiate a new (expanded) SA and delete the old one > > > > In both cases you need an active phase 1 IKE SA. If you > still have one > > around, no extra expense is incurred. If not, you'll need > to add one. > > > > Doing this without negotiatiing something wasn't one of the proposed > > options. > > > > jan > > > > > > > -------------------------------------------- > > > Michael Shieh > > > -------------------------------------------- > > > > > > -----Original Message----- > > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > > Sent: Thursday, April 04, 2002 12:11 PM > > > To: Tero Kivinen > > > Cc: ipsec@lists.tislabs.com; Paul Hoffman / VPNC > > > Subject: Re: Do we actually need dynamic ports? > > > > > > > > > I don't mind that. I just had to go re-read ikev2 and > realized that > > > you CAN in fact to multiple discontiguous ranges (or > ports as well as > > > IP addresses, by simply having multiple 'Traffic Selector > > > Substructure' sections (7.13.1 Traffic Selector > Substructure). Cool. I > > > like it. > > > > > > The only minor difference (and I'm not saying it's > important) is that > > > you have to go through 'more' computation to delete and > add a new SA, > > > rather than adding to it, but that may be minor and not > an issue at > > > all. In particular: using up 'precious' entropy by having > to come up > > > with new key material, having to create a new SPI (and > associated IKE > > > delete payloads), and possibly having to rebuild some > internal tree > > > for the SA's (depends on implementation). Simply adding > some selectors > > > to an existing SA and keeping keys and SPI, *seems* > easier, but may > > > not actually make that much difference. > > > > > > Paul proposed using a semantic where using the same 'SPI' in the > > > proposal means that you are adding to the existing SPI. That could > > > bear a closer look as well, although I think there's room > for error > > > there.. > > > > > > Negotiating a new SA, with new SPI, deleting the old one > is certainly > > > 'clean' even though it seems to involve a lot of steps. > Are we going > > > to try and fold some (not all) of the jenkins rekey-draft > into IKEv2, > > > so that rekey behaviour is spelled out precisely? That > would certainly > > > help. > > > > > > jan > > > > > > > > > > > > On Thu, 4 Apr 2002, Tero Kivinen wrote: > > > > > > > vilhuber@cisco.com (Jan Vilhuber) writes: > > > > > This is no different than creating a second SA, I suppose. You > > want > > > > > traffic for the FTP data channel? Create a new SA for > > > > > it. Alternatively, and this is what Pyda's and my > draft does, pass > > an > > > > > indicator that identifies the previous SA, and ADD to > it. Saves > > > > > memory, at almost no additional cost. > > > > > > > > Why have a special case for ADD and DELETE, why not simply > > renegotiate > > > > new SA with new set of selectors (i.e add new > selectors, remove the > > > > ones you do not want), and when that new SA is ready, > delete the old > > > > SA. I.e simply make ADD and DELETE to be rekey of the > existing SA. > > > > > > > > For IKEv1 you could not do that, as there was no way to > express the > > > > set of selectors, but with TS we can do that, so now that is an > > > > option. > > > > -- > > > > kivinen@ssh.fi > > > > SSH Communications Security http://www.ssh.fi/ > > > > SSH IPSEC Toolkit > > http://www.ssh.fi/ipsec/ > > > > > > > > > > -- > > > Jan Vilhuber > > vilhuber@cisco.com > > > Cisco Systems, San Jose (408) > > 527-0847 > > > > > > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose (408) > > 527-0847 > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Mon Apr 8 07:57: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 g38EvWm18073; Mon, 8 Apr 2002 07:57:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03931 Mon, 8 Apr 2002 10:00:35 -0400 (EDT) Message-Id: <3.0.3.32.20020408071319.01335670@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 08 Apr 2002 07:13:19 -0700 To: Paul Koning From: Alex Alten Subject: Re: [mobile-ip] Re: replacing IPsec's replay protection? Cc: ipsec@lists.tislabs.com In-Reply-To: <15537.37888.259000.227717@gargle.gargle.HOWL> References: <200204041832.NAA05665@nwmail.wh.lucent.com> <3.0.3.32.20020406054529.01331868@mail> <3.0.3.32.20020407122710.00eeebb0@mail> <3.0.3.32.20020408000306.00fb5630@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:58 AM 4/8/2002 -0400, Paul Koning wrote: >Excerpt of message (sent 8 April 2002) by Alex Alten: >> At 07:45 PM 4/7/2002 -0400, Paul Koning wrote: >> > Since you mentioned ECB, I wonder >> >if you are aware of the reasons why ECB is NEVER used for any network >> >security protocol. There are good reasons why it isn't, and it helps >> >to know what they are. >> >> Never say NEVER. Yes, I'm perfectly aware of the dangers. But to be >> fair the other side of the coin is rarely heard. ECB can be much faster >> than CBC, by computing multiple blocks in parallel and by avoiding the >> memory move of the extra XOR. Complexity is reduced by getting rid of >> synchronizing the IV between sender and receiver, and because packet >> re-ordering is no longer an issue. These are the engineering vs security >> tradeoffs one has to consider while designing a system. > >IPsec uses explicit IV, there is NO synchronization of IV between >sender and receiver. Nor is there any issue of packet reordering. >You may be confused with SSL. > Actually not, I was speaking more generally than IPsec. All IV's require some sort of coordination even if it is a simple logic. >As for the performance cost of CBC: in software, the cost is one load >instruction per packet (for the IV) and one XOR instruction per 8 >bytes. There is no extra memory move. > These two sentences contradict each other, I agree with the first one. >In hardware, CBC forces serialization of the block processing within a >packet. That can limit your ultimate performance (though there are >chips available that will do single stream CBC at well above 1 Gb/s). >But that doesn't limit your performance in practice, certainly not for >multiple SAs, and not even for a single SA when there are multiple >packets to process if you do a bit more work (as I did in an >implementation of IPsec a few years ago). > These are true enough. However to date probably not more than 5% of the hosts have hardware acceleration available to them. Unfortunately, these pipeling techniques will not work when fragmentation reorders the pieces of an incoming packet. >Finally, if you're interested in a mode that doesn't have the >serialization properties of CBC and also avoids the security defects >of ECB, take a look at counter mode, currently an I-D. > Thanks, I'll take a look at it. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Apr 8 11:35: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 g38IZem00846; Mon, 8 Apr 2002 11:35:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05336 Mon, 8 Apr 2002 13:24:30 -0400 (EDT) Message-Id: <5.0.2.1.0.20020408121312.02face88@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 08 Apr 2002 12:24:23 -0400 To: ipsec@lists.tislabs.com From: "G. Noubir" Subject: CFP: Workshop on Wireless Security (in conjunction with MobiCom 2002) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 20, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign From owner-ipsec@lists.tislabs.com Mon Apr 8 14:25:24 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 g38LPOm08891; Mon, 8 Apr 2002 14:25:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06614 Mon, 8 Apr 2002 16:38:38 -0400 (EDT) Date: 8 Apr 2002 16:42:03 -0400 Message-ID: <000001c1df3d$d84a1f60$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Jan Vilhuber'" Cc: ipsec@lists.tislabs.com Subject: RE: dynamic ports vs. rekeying 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Is this still an issue in ikev2? Quick mode is no longer 3 messages, > so the responder can immediately install all SA's and the initiator > can start sending when he receives the reply... It's an issue because of this scenario: Alice and Bob have an SA for TCP connection #1: ports 123-12345 Later on, Alice wants to add a selector for TCP connection #2: ports 234-23456 She sends Create_Child_SA1 for an SA that covers both connections, and Bob replies with Create_Child_SA2, but the packet gets dropped. Now Bob will start sending traffic for connection #1 on the new SA, which Alice hasn't installed yet. A phase 2 message to add selectors doesn't have that problem. I suppose you could work around this problem to a certain extent by having Alice do "Initiator Pre-Setup" (installing the new SA before the negotiation is complete). But this is kind of kludgy, and it certainly doesn't work with PFS (to open up that can of worms again). 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: Friday, April 05, 2002 7:14 PM > To: Andrew Krywaniuk > Cc: sommerfeld@east.sun.com; 'Paul Hoffman / VPNC'; 'Tero Kivinen'; > ipsec@lists.tislabs.com > Subject: Re: dynamic ports vs. rekeying > > > On 5 Apr 2002, Andrew Krywaniuk wrote: > > > I think dynamic selectors are different from rekeying. Not only does > > updating the selectors of the existing SA save bits on the > wire, but from a > > robustness point of view, it means that to any > synchronization errors > > between the peers will only affect the new traffic. > > > > Imagine there is a race condition between the QM3 (or > Create_Child_Sa2) and > > the data traffic. The most reliable thing to do is to send > the old traffic > > on the old SA for a short while and send the new traffic on > the new SA > > (since the selectors won't match the old SA). Wouldn't it > be easier to send > > send all traffic on the new SA automatically because the > new SA is the old > > SA? If the selectors haven't been updated yet then new > traffic will be > > dropped for a short while. > > > > On the subject of rekeying, I agree that using the old > phase 1s until they > > expired (as specified in draft-jenkins) didn't work, but > the immediate > > switch-over in draft-specncer is too hasty. I recommend that an > > implementation should continue to use its old SA for a > short time (e.g. 30 > > seconds) after the new one is negotiated to account for any > lost packets. It > > should also wait a short time after that before deleting the old SA. > > > > Is this still an issue in ikev2? Quick mode is no longer 3 messages, > so the responder can immediately install all SA's and the initiator > can start sending when he receives the reply... > > jan > > > > ------------------------------------------- > > 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 Bill Sommerfeld > > > Sent: Friday, April 05, 2002 2:29 PM > > > To: Jan Vilhuber > > > Cc: Bill Sommerfeld; Paul Hoffman / VPNC; Tero Kivinen; > > > ipsec@lists.tislabs.com > > > Subject: Re: Do we actually need dynamic ports? > > > > > > > > > > Well the draft that Pyda wrote changes the payload so > that it's NOT > > > > ambiguous (it tags each SA with a policy ID, so you always know > > > > exactly which traffic-policy you're talking about (even if > > > your SPI's > > > > may change), and added an add/remove flag). > > > > > > I wasn't thinking of reordering within the KM protocol, but rather > > > reordering between the KM protocol and AH/ESP traffic, > especially in > > > the case of selector deletion. > > > > > > If the SPI changes, we reduce selector-set changes to the same > > > [un]solved problem as graceful rekeying ;-) > > > > > > - Bill > > > > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > From owner-ipsec@lists.tislabs.com Mon Apr 8 14:31:35 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 g38LVYm08977; Mon, 8 Apr 2002 14:31:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06650 Mon, 8 Apr 2002 16:50:30 -0400 (EDT) Date: 8 Apr 2002 16:53:40 -0400 Message-ID: <000601c1df3f$7752bfd0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Henry Spencer'" , " 'IP Security List'" Subject: RE: dynamic ports vs. rekeying 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I assume you're speaking in the context of rekeying which > also plays games > with selectors? Without that, we have extensive operational > proof that > the immediate cutover works just fine... Not at that point in the message, no. Here I was talking about plain old IKEv1 rekeying. I am sure that immediate cutover will work just fine in the vast majority of cases. That's why you have operational evidence to back this up. The problems happen when QM3 gets dropped or when QoS causes packet reordering. I'm sure you don't see this happen much because QoS isn't widely deployed, and QM3 isn't very likely to get dropped in your case (although the probablility is much higher of QM3 getting dropped by a gateway under heavy load). The purpose of rekeying in advance is to avoid traffic loss during the transition. Immediate cutover avoids the 99% chance of traffic loss while an SA is renegotiated. The 30 second delay before switchover avoids the 10% chance of traffic loss when packets get dropped or reordered. (to pull some numbers out of the air) 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 Henry Spencer > Sent: Saturday, April 06, 2002 12:54 AM > To: IP Security List > Subject: Re: dynamic ports vs. rekeying > > > On 5 Apr 2002, Andrew Krywaniuk wrote: > > On the subject of rekeying, I agree that using the old > phase 1s until they > > expired (as specified in draft-jenkins) didn't work, but > the immediate > > switch-over in draft-specncer is too hasty. > > I assume you're speaking in the context of rekeying which > also plays games > with selectors? Without that, we have extensive operational > proof that > the immediate cutover works just fine... > > > Henry Spencer > > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Tue Apr 9 00:19: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 g397J7m08077; Tue, 9 Apr 2002 00:19:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09954 Tue, 9 Apr 2002 02:25:27 -0400 (EDT) Message-ID: <001801c1df91$12bf3f60$ae64a8c0@ranjit> From: "Amol Deshmukh" To: Cc: Subject: SA Lifetime (Soft and Hard) Date: Tue, 9 Apr 2002 12:07:50 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Following is my Interpretation of the Lifetimes (Soft and Hard) for automatic keying as specified in RFC 2401. Could you please correct me incase of any errors. Soft Lifetime: When the soft lifetime of a SA expires, a warning is given to the implementation to initiate an action such as setting up a replacement SA. The SA is still used for further processing. Here setting up replacement SA means refreshing of the Encryption and/or Authentication keys. As soon as the keys are refreshed, this new SA will be used for further processing. I am trying to illustrate this with the help of an example: e.g. SPD1-------àSADB1 (Consider Policy1 points to SADB entry1 in the database). Soft Lifetime: 100 hrs from the created time Hard Lifetime: 1000 hrs from the created time Consider Soft Lifetime of SADB1 expires. A warning is given, an action for key refreshing is initiated. The current processing is done with the old keys. As soon as the keys are refreshed, SADB1 with the refreshed keys is used for packet processing. New Soft Lifetime: 100 hrs from the refreshed time? New Hard Lifetime: 1000 hrs from the refreshed/created time?? Hard Lifetime: Expiration of hard lifetime means the SA currently used should be deleted. Since, the Policies accessing those SAs still exist, they will not point to any SA. e.g. SPD1-------àSADB1 Soft Lifetime: 100 hrs from the created time Hard Lifetime: 1000 hrs from the created time Consider Hard Lifetime of SADB1 expires. The SADB1 entry is deleted. Thus, SPD1--------àNULL Now, how will the new SA be created? Regards, -Amol. From owner-ipsec@lists.tislabs.com Tue Apr 9 08:18: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 g39FI1m21882; Tue, 9 Apr 2002 08:18:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12082 Tue, 9 Apr 2002 10:13:45 -0400 (EDT) Message-ID: <20020409074707.15531.qmail@web14914.mail.yahoo.com> Date: Tue, 9 Apr 2002 00:47:07 -0700 (PDT) From: IP sec Subject: Help on implementing IPSec To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Sir, Subject: Help on implementing IPSec We are a batch of 4 students doing a project on IPSec for Linux, this is an initiative which is taken as a part of the 4 years engineering course. We have gone through the following RFC's - 2401, 2408, 2409. But we have come across a particular problem whose solution it seems is very difficult to find. We hope you can help us out or refer us to a person who can help us. We require verification on the following questions. Q. What is the encoding format for the IKE/ISAKMP? (Binary or Text, if binary is it DER/BER/CER/PER, if text is it BNF/HBNF, or anything else) Q. Please verify this information whether the port number is 500, and are we using UDP as transport protocol for the IPSec. Q. What kind of a Socket Interface are we using, is it PF_INET or AF_INET or PF_KEY, please specify if anything else is used. We would really be obliged to receive any kind of help from you because we have absolutely no guidance on this concept right here. Thanking You, Yours sincerely Pramod, Manjunath, Deepak, Venkat __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-ipsec@lists.tislabs.com Tue Apr 9 22:48: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 g3A5mgm03806; Tue, 9 Apr 2002 22:48:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17069 Wed, 10 Apr 2002 00:52:04 -0400 (EDT) Message-ID: <00ba01c1e04b$50026db0$d7204789@skeisamd01> From: "Suresh Singh K." To: Subject: Re: SA Lifetime (Soft and Hard) Date: Wed, 10 Apr 2002 10:19:37 +0530 Organization: Analog Devices Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 X-MIME-Autoconverted: from 8bit to quoted-printable by nwd2mhb1.analog.com id AAA19221 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id AAA17066 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Hope the following ansver your Question : > SPD1--------àNULL > > Now, how will the new SA be created? > > Initially when IKE is used the policy(SPD) is configured with no SA(SAD) . When an outgoing packet (from host or from network) pass the IPSEC module , the SPD lookup is done with the selectors extrated. If it match one of policies IPSEC gives an indication to IKE to establish a new SA. After establishing a new SA , it's linked with the SPD. New SA's from "soft timer" are also linked to the same list. When "hard timer "occurs , the old SA will be removed and the new SA 'll be used It's like : SPD1 ---------- NULL (no traffic) SPD1 -----------SA1 ( first SA) SPD1------------SA1 , SA 2 ( SA2 is the result of soft expire of SA1 , but only SA1 is used till hard expire) SPD1------------SA2 ( hard expire of SA1 results in SA1 deletion) Cheers ! suresh From owner-ipsec@lists.tislabs.com Wed Apr 10 06:27: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 g3ADRAm24420; Wed, 10 Apr 2002 06:27:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18858 Wed, 10 Apr 2002 08:38:41 -0400 (EDT) Message-ID: <20020410125059.65759.qmail@web11303.mail.yahoo.com> Date: Wed, 10 Apr 2002 05:50:59 -0700 (PDT) From: Steven Rosonina To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello all, Could anyone please tell me if IKE exchanges use the optional 16 Bit UDP checksum. I assume it probably does. I am just having a difficult time confirming. Thanks in advance! ===== Steven Rosonina 634 Arboretum Way Burlington, MA 01803 __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-ipsec@lists.tislabs.com Wed Apr 10 12:20: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 g3AJKjm15684; Wed, 10 Apr 2002 12:20:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20130 Wed, 10 Apr 2002 14:22:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 10 Apr 2002 11:31:52 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: IPsec IANA registry Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you to the people who contributed to the IANA registry work so far. The current proposal for the new registry is at . It is *very important* that all serious IPsec implementers look over the proposal. We have found numerous bugs in the registry, and some were only found by one implementor and not others. There are many Internet Drafts that will hopefully become RFCs soon, and IANA needs the registry to be correct and understandable before those RFCs can be issued. A few important notes: The IANA registry only covers issued RFCs, plus some messages from individuals. IANA tries not to assign numbers used in Internet Drafts. To date, those messages fall into three categories: a) use this value for a defined-but-not-RFC-defined purpose b) reserve this value because some people are using it but there will probably never be an RFC c) use this value for a not-yet-RFC-defined purpose There is only one instance in group (a): TIGER. In group (b), there are values for things that were in Internet Drafts and went into some shipping products, but those drafts are not expected to become RFCs for various reasons. In group (c), there are a bunch of EC numbers from now-expired Internet Drafts that are expected to be re-issued and probably move to RFC. Also in group (c), Marcus Leech reserved values for AES and SHA-2 on the assumption that Internet Drafts and RFCs would follow; so far, that has not happened for some of the values. So, what should we recommend for the items in group (c)? Should IANA go back to not giving numbers for Internet Drafts and we remove these numbers from the IANA registry until the RFCs issue (if ever)? Should we make a special case here? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 10 12:36: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 g3AJa3m17435; Wed, 10 Apr 2002 12:36:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20244 Wed, 10 Apr 2002 14:59:50 -0400 (EDT) Date: Wed, 10 Apr 2002 15:11:36 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: IPsec IANA registry 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 Wed, 10 Apr 2002, Paul Hoffman / VPNC wrote: > In group (c), there are a bunch of EC numbers from now-expired > Internet Drafts that are expected to be re-issued and probably move > to RFC. Also in group (c), Marcus Leech reserved values for AES and > SHA-2 on the assumption that Internet Drafts and RFCs would follow... There is also the infamous group 5, although we can hope that it will "go straight" with draft-ietf-ipsec-ike-modp-groups-04.txt or some immediate descendant thereof. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Apr 10 13:49: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 g3AKnWm22611; Wed, 10 Apr 2002 13:49:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20483 Wed, 10 Apr 2002 16:11:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 10 Apr 2002 13:23:00 -0700 To: Henry Spencer , IP Security List From: Paul Hoffman / VPNC Subject: Re: IPsec IANA registry Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:11 PM -0400 4/10/02, Henry Spencer wrote: >On Wed, 10 Apr 2002, Paul Hoffman / VPNC wrote: >> In group (c), there are a bunch of EC numbers from now-expired >> Internet Drafts that are expected to be re-issued and probably move >> to RFC. Also in group (c), Marcus Leech reserved values for AES and >> SHA-2 on the assumption that Internet Drafts and RFCs would follow... > >There is also the infamous group 5, although we can hope that it will >"go straight" with draft-ietf-ipsec-ike-modp-groups-04.txt or some >immediate descendant thereof. No, the "infamous group 5" was removed from the proposed registry because it had erroneously been listed as part of an RFC. There is no 5 listed there. And, yes, it would be grand if we could move some of the Internet Drafts that are fully baked and simply getting moldy to RFC status. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Apr 10 16:42: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 g3ANglm01172; Wed, 10 Apr 2002 16:42:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20894 Wed, 10 Apr 2002 18:54:29 -0400 (EDT) Message-Id: <200204102305.g3AN5Yi04074@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: handling of ICMP error codes in 2401bis Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Apr 2002 19:05:33 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Steve Kent, I'd like to suggest some changes to a 2401bis. I will be happy to provide a text diff to 2401 if you agree with the spirit. (I'm not clear if you are revising just ESP or 2401 as well) Specifically, I'd like to propose: {From http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec/icmp/node5.html which is part of http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec/icmp/ } Handling ICMP error messages ICMP error messages can be handled in two ways: one way is to handle them like the information messages -- establish selectors and SAs for them. A second, more useful, way is to realize that every error message contains within it some portion of the IP packet which caused the error. It is therefore possible to examine this IP packet, compare it to existing selectors, and insert the ICMP message into an appropriate SA. When doing comparisons, the source and destination designations must be exchanged. This method has the advantage that it inherently works well for per-host, per-port, and whatever future selectors may be created. This method assumes that SAs are created in equivalent pairs. This is the case for IKE negotiated unicast SAs, but would not be the case for multicast SAs, or manually keyed ones in general. At first take it may seem that this technique does not require any negotiation, and can be implemented as a local policy. This is not the case. The receiving end of the SA will do tunnel exit checking, and unless it is also implementing this policy will reject the packet and flag a security violation. It is therefore necessary for an IKE proposal to carry the "ICMP error" processing attribute as part of the proposal. This would require an extension to IKE, likely in the form of a variation of the identity payload, initially in the private payload ID space protected by a vendor ID payload. It would be easy to deploy as even after standarization, it would not require a new ISAKMP version -- vendors that didn't recognize the proposal would simply not select 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 NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPLTFO4qHRg3pndX9AQEYnwP/Ql01LXA/BZGK+w+BLen/wU16PtBGu3/V Gkx7VnWOkcqT5g3nGmrhzjXd4H7TlprX0Dgk0sGA/3zBESc9XCJ2PxLiDlmVK3py AqappSAvuMafFww6JDJ/A2A064ICO7hfEwLshpeBHZ7LvSOTVgAiKqn3yJ/4u3g5 gXr2vJszsW4= =y5ZT -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Apr 10 17:12: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 g3B0Cmm02014; Wed, 10 Apr 2002 17:12:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA21041 Wed, 10 Apr 2002 19:41:01 -0400 (EDT) Date: Wed, 10 Apr 2002 19:52:49 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Martin Gadbois cc: IPsec List , FreeS/WAN Design Subject: Re: [Design] Nortel Contivity VPN client and 3rd party IPsec In-Reply-To: <3CADD10D.ABD71624@colubris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: Martin Gadbois | To: ipsec@lists.tislabs.com, design@lists.freeswan.org | Subject: [Design] Nortel Contivity VPN client and 3rd party IPsec | I would like to know what is required to use the Nortel Contivity | VPN client with a 3rd party IPsec gateway. | I noticed that the Contivity client uses part of | http://www.globecom.net/ietf/draft/draft-mamros-pskeyext-00.html as the | KEY_ID, but the HASH_R value that the gateware return is not accepted by | the client (AUTHENTICATION_FAILURE) Did you compute the pre-shared secret as prf(passphrase, username)? This is what that long-dead-draft specifies. (I have no idea if there is something else that descended from this draft.) Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Thu Apr 11 04:39:44 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 g3BBdhm23793; Thu, 11 Apr 2002 04:39:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22987 Thu, 11 Apr 2002 05:29:42 -0400 (EDT) Message-ID: <002c01c1e13d$00c5c420$ed551ad4@natasha> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: "Steven Rosonina" Cc: References: <20020410125059.65759.qmail@web11303.mail.yahoo.com> Subject: Re: Date: Thu, 11 Apr 2002 12:41:03 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C1E156.2467BD20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Disposition-Notification-To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C1E156.2467BD20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 one would say that the checksum in UDP ( 2 bytes) is used for verifying = the UDP packet (header+data). Since IKE is using The Diffe-Hellman = protocol for key management, I do not see why IKE should use the 2 bytes = of UDP cheksum. After all UDP is not session oriented. Ahmed alaadas@kaau.edu.sa ----- Original Message -----=20 From: Steven Rosonina=20 To: ipsec@lists.tislabs.com=20 Sent: Wednesday, April 10, 2002 3:50 PM Hello all, Could anyone please tell me if IKE exchanges use the optional 16 Bit UDP checksum. I assume it probably does. I am just having a difficult time confirming. Thanks in advance! =3D=3D=3D=3D=3D Steven Rosonina 634 Arboretum Way Burlington, MA 01803 __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ------=_NextPart_000_0029_01C1E156.2467BD20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
one would say that the checksum in UDP = ( 2 bytes)=20 is used for verifying the UDP packet (header+data). Since IKE is using = The=20 Diffe-Hellman protocol for key management, I do not see why IKE should = use the 2=20 bytes of UDP cheksum. After all UDP is not session = oriented.
 
Ahmed
alaadas@kaau.edu.sa
----- Original Message -----
From:=20 Steven Rosonina
Sent: Wednesday, April 10, 2002 = 3:50=20 PM

Hello all,

     Could anyone = please=20 tell me if IKE exchanges use
the optional 16 Bit UDP = checksum.  I=20 assume it
probably does.  I am just having a difficult=20 time
confirming.  Thanks in = advance!

=3D=3D=3D=3D=3D
Steven=20 Rosonina
634 Arboretum Way
Burlington, MA=20 01803

__________________________________________________
Do = You=20 Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
------=_NextPart_000_0029_01C1E156.2467BD20-- From owner-ipsec@lists.tislabs.com Thu Apr 11 09:02: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 g3BG2Dm07106; Thu, 11 Apr 2002 09:02:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24102 Thu, 11 Apr 2002 11:09:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 11 Apr 2002 08:21:55 -0700 To: IP Security List From: Paul Hoffman / VPNC Subject: Re: IPsec IANA registry Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero brought up a good question: At 7:05 PM +0300 4/9/02, Tero Kivinen wrote: >Do key length, rounds, and dictionary size belong there at all, as >they are simply numbers (in bits, rounds, size in log2). He is speaking about sections 7.5, 7.6, and 7.7. I included them because 2407 says that, in each case, zero is "reserved". On the other hand, no one can register any other values, and zero clearly is nonsensical for all three values. Does anyone object if I remove these three sections? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 11 09:04:46 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 g3BG4jm07517; Thu, 11 Apr 2002 09:04:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24153 Thu, 11 Apr 2002 11:22:13 -0400 (EDT) X-Originating-IP: [62.114.81.13] From: "heba aslan" To: ipsec@lists.tislabs.com Subject: Fwd: be the judge (plz take a munite and forward it) Date: Thu, 11 Apr 2002 15:34:01 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1525_12ae_347e" Message-ID: X-OriginalArrivalTime: 11 Apr 2002 15:34:01.0593 (UTC) FILETIME=[4E17F690:01C1E16E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_1525_12ae_347e Content-Type: text/html



>From: "Dr.Hoda Mohamed Abou-Shady"
>To: posta121@yahoo.com, ahlameissa@ieee.org, bmekni@hotmail.com, Hankilany@aol.com, hebaaslan@hotmail.com, maabal@lycos.com, mohyous1@yahoo.com, montassers231@aol.com, wael.aw@alcatel.com.eg, z.xinyu@verizon.net
>Subject: be the judge (plz take a munite and forward it)
>Date: Tue, 09 Apr 2002 09:03:00 +0000
>

Send and receive Hotmail on your mobile device: Click Here
------=_NextPart_000_1525_12ae_347e Content-Type: message/rfc822 Received: from 213.131.66.246 by lw6fd.law6.hotmail.msn.com with HTTP; Tue, 09 Apr 2002 09:03:00 GMT X-Originating-IP: [213.131.66.246] From: "Dr.Hoda Mohamed Abou-Shady" To: posta121@yahoo.com, ahlameissa@ieee.org, bmekni@hotmail.com, Hankilany@aol.com, hebaaslan@hotmail.com, maabal@lycos.com, mohyous1@yahoo.com, montassers231@aol.com, wael.aw@alcatel.com.eg, z.xinyu@verizon.net Subject: be the judge (plz take a munite and forward it) Date: Tue, 09 Apr 2002 09:03:00 +0000 Mime-Version: 1.0 Content-Type: text/html X-Stn-Info: ------=_NextPart_000_1525_12ae_347e-- From owner-ipsec@lists.tislabs.com Thu Apr 11 12:46: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 g3BJkwm18558; Thu, 11 Apr 2002 12:46:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24965 Thu, 11 Apr 2002 14:58:22 -0400 (EDT) Message-Id: <200204111908.g3BJ8css001574@thunk.east.sun.com> From: Bill Sommerfeld To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" cc: "Steven Rosonina" , ipsec@lists.tislabs.com Subject: IKE vs UDP checksum. In-Reply-To: Your message of "Thu, 11 Apr 2002 12:41:03 +0300." <002c01c1e13d$00c5c420$ed551ad4@natasha> Reply-to: sommerfeld@east.sun.com Date: Thu, 11 Apr 2002 15:08:38 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Since IKE is using The Diffie-Hellman protocol for key management, Diffie-Hellman is not a checksum or MAC protocol - it is an unauthenticated key agreement protocol. IKE follows up the DH exchange with an additional authentication step, which among other things verifies a hash of the preceding messages; however, that hash can't be verified until after the exchange is complete. If the UDP checksum were disabled, data corruption due to noise won't be detected until the hash is computed and verified while processing the last pair of messages in main mode. > I do not see why IKE should use the 2 bytes of UDP cheksum. IKE runs over UDP; UDP provides a checksum as a normal part of its operation. Many IKE implementations will never even see the raw UDP header and its checksum, and thus would never "use" the checksum - but the underlying UDP implementation will use it. The UDP checksum (as well as other unkeyed lower-layer checks, such as the ethernet CRC) has value for IKE in that it reduces the chance that a phase 1 exchange will be spuriously aborted due to noise. - Bill From owner-ipsec@lists.tislabs.com Thu Apr 11 14:25:54 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 g3BLPrm23006; Thu, 11 Apr 2002 14:25:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25322 Thu, 11 Apr 2002 16:31:12 -0400 (EDT) Message-ID: <3CB5F56E.1030606@isi.edu> Date: Thu, 11 Apr 2002 13:43:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: Lars Eggert , Stephen Kent , kalyan@juniper.net, ipsec mailling list Subject: Re: Is TS agreement necessary? References: <3CAE2BFC.5C8CBC41@juniper.net> <3CAE3D01.10001@isi.edu> <3.0.5.32.20020407122928.007c2600@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy wrote: > At 06:08 PM 4/5/02 -0800, Joe Touch wrote: > >>Lars Eggert wrote: >> >>>Stephen Kent wrote: >>> >>> >>>>RFC 2401 is reasonably clear in noting that the SPD is nominally per >>>>interface. What sort of management interface is provided to a client >>>>is up to the vendor, so long as one can achieve the same effects as a >>>>per-interface SPD. Otherwise, the implementation would not be compliant >>> >>>As a side note, I misunderstood this for a long time to mean "SPD per >>>PHYSICAL interface", which is not sufficient (because of ambiguities via >>>multiple matching tunnel-mode SAs in the same per-physical-interface >>>SPD). When viewing tunnel mode SAs as virtual interfaces in their own >>>right that have separate SPDs associated with them, these problems >>>dissapear. Maybe that's part of the confusion around tunnel mode... >>>Lars >> >>Hi, Steve, >> >>One of the confusions I have is regarding systems that say they use >>these tunnel mode SAs as virtual interfaces. It seems that the tunnel SA >>has to be in the SPD of the underlying interface, but they only work if >>the SA is in the SPD of the virtual interface (i.e., inside the tunnel). >>That seems self-referential... ?? >> >>Jo > > I'm not Steve but I'll pipe up anyway :-) > It doesn't seem any problem on the outgoing side -- first the forwarding > decision selects the outgoing interface (the tunnel). Then the SPD for > that virtual interface is consulted (and it has all-wildcard selectors for > the single tunnel mode SA). The packet is encapsulated and a new > forwarding decision made. As per other mail to PPVPN, the issue is that the SA of the tunnel appears in the SPD of the tunnel itself. That seems recursive. It seems that the SA of a tunnel should appear in the SPD of the interface (real or virtual) that the tunneled packet will be emitted on. > When we are the IKE responder, there is some potential ambiguity. I'm not speaking about IKE at all, FWIW. Joe From owner-ipsec@lists.tislabs.com Thu Apr 11 15:08: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 g3BM8nm24143; Thu, 11 Apr 2002 15:08:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25543 Thu, 11 Apr 2002 17:29:47 -0400 (EDT) Message-ID: <003401c1e1a1$98edf380$e3551ad4@natasha> From: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" To: Cc: References: <200204111908.g3BJ8css001574@thunk.east.sun.com> Subject: Re: IKE vs UDP checksum. Date: Fri, 12 Apr 2002 00:41:09 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C1E1BA.BD1DD4A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Disposition-Notification-To: "Prof. Ahmed Bin Abbas Ahmed Ali Adas" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C1E1BA.BD1DD4A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bill Thank you, I agree with you and you put it more correctly. Regards Ahmed Message -----=20 From: Bill Sommerfeld=20 To: Prof. Ahmed Bin Abbas Ahmed Ali Adas=20 Cc: Steven Rosonina ; ipsec@lists.tislabs.com=20 Sent: Thursday, April 11, 2002 10:08 PM Subject: IKE vs UDP checksum. > Since IKE is using The Diffie-Hellman protocol for key management,=20 Diffie-Hellman is not a checksum or MAC protocol - it is an unauthenticated key agreement protocol. IKE follows up the DH exchange with an additional authentication step, which among other things verifies a hash of the preceding messages; however, that hash can't be verified until after the exchange is complete. If the UDP checksum were disabled, data corruption due to noise won't be detected until the hash is computed and verified while processing the last pair of messages in main mode. > I do not see why IKE should use the 2 bytes of UDP cheksum.=20 IKE runs over UDP; UDP provides a checksum as a normal part of its operation. Many IKE implementations will never even see the raw UDP header and its checksum, and thus would never "use" the checksum - but the underlying UDP implementation will use it. The UDP checksum (as well as other unkeyed lower-layer checks, such as the ethernet CRC) has value for IKE in that it reduces the chance that a phase 1 exchange will be spuriously aborted due to noise. - Bill ------=_NextPart_000_0031_01C1E1BA.BD1DD4A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 Bill
 
Thank you, I agree with you and you put = it more=20 correctly.
 
Regards
 
Ahmed
 
 
Message -----
From:=20 Bill=20 Sommerfeld
Cc: Steven Rosonina ; ipsec@lists.tislabs.com =
Sent: Thursday, April 11, 2002 = 10:08=20 PM
Subject: IKE vs UDP = checksum.

> Since IKE is using The Diffie-Hellman protocol for = key=20 management,

Diffie-Hellman is not a checksum or MAC protocol - = it is=20 an
unauthenticated key agreement protocol.  IKE follows up the = DH
exchange with an additional authentication step, which among=20 other
things verifies a hash of the preceding messages; however, = that=20 hash
can't be verified until after the exchange is = complete.

If the=20 UDP checksum were disabled, data corruption due to noise won't
be = detected=20 until the hash is computed and verified while processing
the last = pair of=20 messages in main mode.

> I do not see why IKE should use the = 2 bytes=20 of UDP cheksum.

IKE runs over UDP; UDP provides a checksum as = a normal=20 part of its
operation.  Many IKE implementations will never = even see=20 the raw UDP
header and its checksum, and thus would never "use" the = checksum - but
the underlying UDP implementation will use = it.

The=20 UDP checksum (as well as other unkeyed lower-layer checks, such = as
the=20 ethernet CRC) has value for IKE in that it reduces the chance = that
a phase=20 1 exchange will be spuriously aborted due to noise.

-=20 Bill ------=_NextPart_000_0031_01C1E1BA.BD1DD4A0-- From owner-ipsec@lists.tislabs.com Fri Apr 12 05:40: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 g3CCe1m27135; Fri, 12 Apr 2002 05:40:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28397 Fri, 12 Apr 2002 07:50:23 -0400 (EDT) Message-Id: <200204121202.IAA12595@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-nat-t-ike-02.txt Date: Fri, 12 Apr 2002 08:02:40 -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 : Negotiation of NAT-Traversal in the IKE Author(s) : T. Kivinen et al. Filename : draft-ietf-ipsec-nat-t-ike-02.txt Pages : 11 Date : 11-Apr-02 This document describes how to detect one or more NATs between IPsec hosts, and how to negotiate the use of UDP encapsulation of the IPsec packets through the NAT boxes in IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-02.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-nat-t-ike-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020411132858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-t-ike-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020411132858.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Apr 12 05:40: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 g3CCeFm27168; Fri, 12 Apr 2002 05:40:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28408 Fri, 12 Apr 2002 07:52:29 -0400 (EDT) Date: Thu, 11 Apr 2002 19:22:03 -0600 From: Jared Jacobson Subject: Questions about JFK To: ipsec@lists.tislabs.com Message-id: <3CB636BB.8060305@cs.byu.edu> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The answer to this question may be incredibly obvious to the members of the mailing list, but it has been bothering me for some time. I've read through the JFK draft (draft-ietf-ipsec-jfk-02.txt) several times and scoured all the IPsec RFC's I thought may contain some material "assumed" in the JFK draft, and I am still unable to answer it. How does one communicate the IV that one has used in encrypting the various encrypted parts of the exchange? And how does JFK generate sufficient keying material for the encryption key Ke in the case of 3DES (since SHA-1 only produces 20 bytes of data, for example)? IKEv1 and IKEv2 have explicit provision for generating sufficient keying material, but I was unable to find it in the JFK draft. Any help in this regard would be appreciated. Jared From owner-ipsec@lists.tislabs.com Fri Apr 12 08:19: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 g3CFJHm05044; Fri, 12 Apr 2002 08:19:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28999 Fri, 12 Apr 2002 10:34:26 -0400 (EDT) Message-Id: <3.0.5.32.20020412104328.007ec850@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Apr 2002 10:43:28 -0400 To: Joe Touch From: Mark Duffy Subject: Re: Is TS agreement necessary? Cc: Lars Eggert , Stephen Kent , kalyan@juniper.net, ipsec mailling list In-Reply-To: <3CB5F56E.1030606@isi.edu> References: <3CAE2BFC.5C8CBC41@juniper.net> <3CAE3D01.10001@isi.edu> <3.0.5.32.20020407122928.007c2600@email.quarrytech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:43 PM 4/11/02 -0700, Joe Touch wrote: >Mark Duffy wrote: >> At 06:08 PM 4/5/02 -0800, Joe Touch wrote: >> >>>Lars Eggert wrote: >>> >>>>Stephen Kent wrote: >>>> >>>> >>>>>RFC 2401 is reasonably clear in noting that the SPD is nominally per >>>>>interface. What sort of management interface is provided to a client >>>>>is up to the vendor, so long as one can achieve the same effects as a >>>>>per-interface SPD. Otherwise, the implementation would not be compliant >>>> >>>>As a side note, I misunderstood this for a long time to mean "SPD per >>>>PHYSICAL interface", which is not sufficient (because of ambiguities via >>>>multiple matching tunnel-mode SAs in the same per-physical-interface >>>>SPD). When viewing tunnel mode SAs as virtual interfaces in their own >>>>right that have separate SPDs associated with them, these problems >>>>dissapear. Maybe that's part of the confusion around tunnel mode... >>>>Lars >>> >>>Hi, Steve, >>> >>>One of the confusions I have is regarding systems that say they use >>>these tunnel mode SAs as virtual interfaces. It seems that the tunnel SA >>>has to be in the SPD of the underlying interface, but they only work if >>>the SA is in the SPD of the virtual interface (i.e., inside the tunnel). >>>That seems self-referential... ?? >>> >>>Jo >> >> I'm not Steve but I'll pipe up anyway :-) >> It doesn't seem any problem on the outgoing side -- first the forwarding >> decision selects the outgoing interface (the tunnel). Then the SPD for >> that virtual interface is consulted (and it has all-wildcard selectors for >> the single tunnel mode SA). The packet is encapsulated and a new >> forwarding decision made. > >As per other mail to PPVPN, the issue is that the SA of the tunnel >appears in the SPD of the tunnel itself. That seems recursive. The SA that realizes the tunnel is associated with the SPD of the virtual (tunnel) interface. Thee is no recursive consulting of the same SPD. Consider a hypothetical device that has 2 conventional interfaces and also implements an overlay network using IPsec to implement a single virtual interface. The device does not have any IPsec policy (SPD) active on the conventional interfaces (all packets are "pass"). A forwarding decision (e.g. L3 routing) is made in the overlay context to send a particular packet out via the virtual interface. The SPD associated with the virtual interface is consulted and it contains a single entry with wildcard selectors (match all packets) that says apply tunnel mode IPsec to all packets and send them to remote peer p1 (addressed in the non-overlay space). An SA is negotiated using IKE, if it does not already exists. The packet is encapsulated in a tunnel mode IPsec packet whose destination address is p1. That packet is then processed as a "new" packet by the L3 forwarding in the non-overlay context. L3 forwarding selects one of the conventional interfaces as the exit interface and the packet is sent. > It seems >that the SA of a tunnel should appear in the SPD of the interface (real >or virtual) that the tunneled packet will be emitted on. Why? That would defeat the logical separation between the overlay and the underlying network that the overlay is aiming to achieve. > >> When we are the IKE responder, there is some potential ambiguity. > >I'm not speaking about IKE at all, FWIW. OK, but for IPsec to be used in this manner, the IKE side of things needs to work too of course. >Joe > From owner-ipsec@lists.tislabs.com Fri Apr 12 09:28: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 g3CGSSm10189; Fri, 12 Apr 2002 09:28:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29190 Fri, 12 Apr 2002 11:46:45 -0400 (EDT) Message-ID: <3CB7043B.5000902@isi.edu> Date: Fri, 12 Apr 2002 08:58:51 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Mark Duffy CC: Joe Touch , Stephen Kent , kalyan@juniper.net, ipsec mailling list Subject: Re: Is TS agreement necessary? References: <3CAE2BFC.5C8CBC41@juniper.net> <3CAE3D01.10001@isi.edu> <3.0.5.32.20020407122928.007c2600@email.quarrytech.com> <3.0.5.32.20020412104328.007ec850@email.quarrytech.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000900030805020108090609" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms000900030805020108090609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Duffy wrote: > Consider a hypothetical device that has 2 conventional interfaces and also > implements an overlay network using IPsec to implement a single virtual > interface. The device does not have any IPsec policy (SPD) active on the > conventional interfaces (all packets are "pass"). A forwarding decision > (e.g. L3 routing) is made in the overlay context to send a particular > packet out via the virtual interface. The SPD associated with the virtual > interface is consulted and it contains a single entry with wildcard > selectors (match all packets) that says apply tunnel mode IPsec to all > packets and send them to remote peer p1 (addressed in the non-overlay > space). An SA is negotiated using IKE, if it does not already exists. The > packet is encapsulated in a tunnel mode IPsec packet whose destination > address is p1. That packet is then processed as a "new" packet by the L3 > forwarding in the non-overlay context. L3 forwarding selects one of the > conventional interfaces as the exit interface and the packet is sent. In this example the "interface" is a do-nothing pseudo construct that serves no other purpose than holding a tunnel mode SA (see section 3.2 of our ID for a discussion). This approach requires a different pseudo interface for each SA, and each SA associated with such an interface MUST be tunnel mode. Network interfaces are characterized by the encapsulation the perform (e.g. Ethernet, etc.) The pseudo interface you propose does not perform such on operation by itself, but depends on IPsec to perform the required encapsulation, and only functions correctly when restrictions on the contents of its SA are enforced. This seems awfully complicated. Also note that the destinction between tunnel mode and transport mode begins to dissappear, since you tunnel mode SAs MUST be associated with non-encapsulating pseudo-interfaces, while transport mode SA MUST be associated with regular interfaces. Encapsulation is a function of the interface, not one of IPsec. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms000900030805020108090609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQxMjE1NTg1MlowIwYJKoZIhvcNAQkEMRYEFG470xElp3ehTGVzMbfZUDHBx5eOMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCIR5cAQWcnxmpKZTiIh4ZG0WbB2jrswslbs7Pw1Xl0BS5Upl1vm9WzE4FTzLuYiWx8 z376NpsI3EAz5XX+KN6TlaUOZz25iNHj72G82s4mX44eI+l9+bLgE4l9obLeS7V+G9YTe4l+ C00TczPUQR5x3+FfKAcYYioom2HHLzZu0AAAAAAAAA== --------------ms000900030805020108090609-- From owner-ipsec@lists.tislabs.com Fri Apr 12 11:06: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 g3CI6Em13315; Fri, 12 Apr 2002 11:06:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29498 Fri, 12 Apr 2002 13:17:38 -0400 (EDT) Message-Id: <200204121728.g3CHSgt26045@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: terminology of channel numbers Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Apr 2002 13:28:41 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One thing that the FreeSWAN team has discussed introducing to Son-of-IKE is the notion of a channel and channel ID. This is akin to SPI#, but is higher level. This is essentially a 32 or 64 bit blob produced by concatenating a shorter ID present in the proposal by each end. This is a longer lived identifier than SPI#. One uses this ID to identify the set of SAs that currently or have implemented a policy. That is, the entire blob identifies both directions of traffic flow. Rekey's would say "I wish to rekey channel #XXXXXX" Delete's would say "I wish to delete channel #XXXXXX" because I'm turning myself off. {vs "I want to delete SPI#" (because we just rekeyed it)} This makes is very clear what is going on at each end. ] 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 NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Apr 12 11:42: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 g3CIglm16019; Fri, 12 Apr 2002 11:42:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29622 Fri, 12 Apr 2002 14:06:53 -0400 (EDT) Message-Id: <3.0.5.32.20020412141551.0092f7f0@email.quarrytech.com> X-Sender: mduffy@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Apr 2002 14:15:51 -0400 To: Lars Eggert From: Mark Duffy Subject: Re: Is TS agreement necessary? Cc: Joe Touch , Stephen Kent , kalyan@juniper.net, ipsec mailling list In-Reply-To: <3CB7043B.5000902@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Lars, At 11:58 AM 4/12/02 -0400, Lars Eggert wrote: >Mark Duffy wrote: >> Consider a hypothetical device that has 2 conventional interfaces and >also >> implements an overlay network using IPsec to implement a single >virtual >> interface. The device does not have any IPsec policy (SPD) active on >the >> conventional interfaces (all packets are "pass"). A forwarding >decision >> (e.g. L3 routing) is made in the overlay context to send a particular >> packet out via the virtual interface. The SPD associated with the >virtual >> interface is consulted and it contains a single entry with wildcard >> selectors (match all packets) that says apply tunnel mode IPsec to all >> packets and send them to remote peer p1 (addressed in the non-overlay >> space). An SA is negotiated using IKE, if it does not already exists. >The >> packet is encapsulated in a tunnel mode IPsec packet whose destination >> address is p1. That packet is then processed as a "new" packet by the >L3 >> forwarding in the non-overlay context. L3 forwarding selects one of >the >> conventional interfaces as the exit interface and the packet is sent. > >In this example the "interface" is a do-nothing pseudo construct that >serves no other purpose than holding a tunnel mode SA (see section 3.2 >of our ID for a discussion). This approach requires a different pseudo >interface for each SA, and each SA associated with such an interface >MUST be tunnel mode. I understand your words but I don't think I understand your overall point here. The reason we create such a virtual interface, is because *we want to* so that we can represent it as the next hop for IP routes in a forwarding table, and also so we can run an IGP over it. In fact, I think that is the basic problem we are trying to solve here. Question: In the IIPtran implementation, are the IP-in-IP tunnels manifested as virtual interfaces? >Network interfaces are characterized by the encapsulation the perform >(e.g. Ethernet, etc.) The pseudo interface you propose does not perform >such on operation by itself, but depends on IPsec to perform the Whether the IPsec encapsulation is performed by a "separate module" vs whether the ethernet encap is performed by a "separate module" (separate from what, in fact?) seems to me irrelevant from a standards perspective. Either way, some encap gets added. It just varies in size and complexity :-) >required encapsulation, and only functions correctly when restrictions >on the contents of its SA are enforced. This seems awfully complicated. > >Also note that the destinction between tunnel mode and transport mode >begins to dissappear, since you tunnel mode SAs MUST be associated with >non-encapsulating pseudo-interfaces, while transport mode SA MUST be >associated with regular interfaces. Encapsulation is a function of the Ah, this relates to section 3.2 of draft-touch, I believe. And this is a point I have not understood during this discussion. I agree that the virtual interfaces would use tunnel mode, for the needed encapsulation. But I don't see why any other use of IPsec, such as that applied pursuant to SPD policy for each conventional interface, would be restricted in whether it could be tunnel mode or transport mode. Restated, I should think "traditional" use of IPsec based on per-interface SPD is and can continue to be free to use tunnel mode or transport mode. And, quite separate from that, there is an application for IPsec *tunnel mode* cast as a virtual tunnel interface. BTW, IIPtran could equally be used for the virtual tunnel interface. Makes sense? >interface, not one of IPsec. > >Lars >-- >Lars Eggert Information Sciences Institute >http://www.isi.edu/larse/ University of Southern California > From owner-ipsec@lists.tislabs.com Fri Apr 12 11:59: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 g3CIxom16401; Fri, 12 Apr 2002 11:59:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29664 Fri, 12 Apr 2002 14:15:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: terminology of channel numbers Date: Fri, 12 Apr 2002 11:28:39 -0700 Message-ID: <7B8824D690092B4B90B0EF4674750A65022DF5CD@USEXCH3.us.sonicwall.com> Thread-Topic: terminology of channel numbers Thread-Index: AcHiS25nTg90Q/dCSL+wn99ZkoTqbAAAivTQ From: "Ricky Charlet" To: "'Michael Richardson'" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA29661 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, Channel nubmers would be very helpfull from a network operator's perspective for managing a VPN or Remote Access type deployment of IPsec. In both of these cases, network operators have pre-concieved notions of 'tunnels' or 'channels' and would greatly appreciate the ability to track MIB2/RMON type statistics on a per channel basis. These stats gathering capabilities enable the ability to do fault detection, perfomance tuning, and capacity planning at the 'channel' layer. I believe that an iteroperable notion of how to enable fault/capacity/performance management of VPN/RemoteAccess IPsec deployments at the 'channel' layer would noticably improve market acceptance of IPsec. This is just my personal gut-feeling, not a marketing researched backed white paper conslusion or anything like that. -- Ricky Charlet : rcharlet@sonciwall.com : usa (408) 962-8711 > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Friday, April 12, 2002 10:29 AM > To: ipsec@lists.tislabs.com > Subject: terminology of channel numbers > > > > One thing that the FreeSWAN team has discussed introducing > to Son-of-IKE is > the notion of a channel and channel ID. > > This is akin to SPI#, but is higher level. > > This is essentially a 32 or 64 bit blob produced by > concatenating a shorter > ID present in the proposal by each end. > > This is a longer lived identifier than SPI#. One uses this > ID to identify > the set of SAs that currently or have implemented a policy. > That is, the entire blob identifies both directions of traffic flow. > > Rekey's would say "I wish to rekey channel #XXXXXX" > Delete's would say "I wish to delete channel #XXXXXX" > because I'm turning > myself off. > {vs "I want to delete SPI#" (because we just rekeyed it)} > > This makes is very clear what is going on at each end. > > ] 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 NetBSD/notebook using, kernel hacking, > security guy"); [ > > > > > From owner-ipsec@lists.tislabs.com Fri Apr 12 12:13:44 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 g3CJDhm16976; Fri, 12 Apr 2002 12:13:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29715 Fri, 12 Apr 2002 14:32:43 -0400 (EDT) Message-ID: <3CB72B02.1000502@isi.edu> Date: Fri, 12 Apr 2002 11:44:18 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Mark Duffy CC: Joe Touch , Stephen Kent , kalyan@juniper.net, ipsec mailling list Subject: Re: Is TS agreement necessary? References: <3.0.5.32.20020412141551.0092f7f0@email.quarrytech.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060106030205000906010407" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms060106030205000906010407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mark Duffy wrote: >> In this example the "interface" is a do-nothing pseudo construct >> that serves no other purpose than holding a tunnel mode SA (see >> section 3.2 of our ID for a discussion). This approach requires a >> different pseudo interface for each SA, and each SA associated >> with such an interface MUST be tunnel mode. > > I understand your words but I don't think I understand your overall > point here. The reason we create such a virtual interface, is > because *we want to* so that we can represent it as the next hop for > IP routes in a forwarding table, and also so we can run an IGP over > it. In fact, I think that is the basic problem we are trying to > solve here. > > Question: In the IIPtran implementation, are the IP-in-IP tunnels manifested > as virtual interfaces? They are whatever IP tunnel devices you have in the system. They are not virtual in the sense that they perform regular interface functionality (i.e., encapsulation). (But maybe I'm misunderstanding your definition of virtual.) >> Also note that the destinction between tunnel mode and transport >> mode begins to dissappear, since you tunnel mode SAs MUST be >> associated with non-encapsulating pseudo-interfaces, while >> transport mode SA MUST be associated with regular interfaces. >> Encapsulation is a function of the > > > Ah, this relates to section 3.2 of draft-touch, I believe. And this > is a point I have not understood during this discussion. I agree > that the virtual interfaces would use tunnel mode, for the needed > encapsulation. But I don't see why any other use of IPsec, such as > that applied pursuant to SPD policy for each conventional interface, > would be restricted in whether it could be tunnel mode or transport > mode. If you allow tunnel mode SAs on non-virtual interfaces, you again end up with the problem that you can't dynamically route over such a topology. If you allow multiple tunnel mode SAs on a single virtual tunnel interface, you must enforce strong consistency constraints on the SA set. For example, you must enforce that the SAs that match your routing exchanges are exactly the same ones that match all other traffic out that interfaces. As a start, this means that you can't use different encapsulation headers on the two sets. I'm sure there are others constraints. The point is that this becomes really complicated. > Restated, I should think "traditional" use of IPsec based on > per-interface SPD is and can continue to be free to use tunnel mode > or transport mode. And, quite separate from that, there is an > application for IPsec *tunnel mode* cast as a virtual tunnel > interface. BTW, IIPtran could equally be used for the virtual > tunnel interface. Makes sense? I'm not trying to argue that your approach cannot work - it can, and our ID discusses how and when it does. I'm trying to argue that a combination of RFC2003 and a simplified RFC2401 can achieve the same functionality while being significantly simpler. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms060106030205000906010407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDQxMjE4NDQxOVowIwYJKoZIhvcNAQkEMRYEFFI0E6uhVL4/I2+VUmvmsoQ7irOyMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCLpuZ/skDfL0YQCBZ1Ic/rjwl3WdAnG8oL+3CgXXYklZHryxZIRGirRWr1uwVWc3Dc skycnBFQb4lRJuzv6EvXVGtWhRUYs2ismwqFpa56XqgvJauDU1wfCUZWkFaxYfRFShzcbPg5 SHMjD6Wwr+r7NOXNA49CNbfegOhCkxkP7gAAAAAAAA== --------------ms060106030205000906010407-- From owner-ipsec@lists.tislabs.com Fri Apr 12 13:18: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 g3CKI1m21117; Fri, 12 Apr 2002 13:18:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29951 Fri, 12 Apr 2002 15:25:46 -0400 (EDT) From: geir-myrdahl.koien@telenor.com content-class: urn:content-classes:message Subject: RE: terminology of channel numbers Date: Fri, 12 Apr 2002 21:38:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: terminology of channel numbers X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcHiTWiFj5WCbk47Eda9yQCQJx3dOwACvN7Q To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA29948 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This sounds like an excellent idea. It seems to me to have the potential to make rekeying and interoperability easier and more reliable. /Geir Køien -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: 12. april 2002 19:29 To: ipsec@lists.tislabs.com Subject: terminology of channel numbers One thing that the FreeSWAN team has discussed introducing to Son-of-IKE is the notion of a channel and channel ID. This is akin to SPI#, but is higher level. This is essentially a 32 or 64 bit blob produced by concatenating a shorter ID present in the proposal by each end. This is a longer lived identifier than SPI#. One uses this ID to identify the set of SAs that currently or have implemented a policy. That is, the entire blob identifies both directions of traffic flow. Rekey's would say "I wish to rekey channel #XXXXXX" Delete's would say "I wish to delete channel #XXXXXX" because I'm turning myself off. {vs "I want to delete SPI#" (because we just rekeyed it)} This makes is very clear what is going on at each end. ] 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 NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Apr 12 13: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 g3CKVXm21418; Fri, 12 Apr 2002 13:31:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00071 Fri, 12 Apr 2002 15:50:08 -0400 (EDT) Message-ID: <4652644B98DFF34696801F8F3070D3FE02008333@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Joe Touch'" , Mark Duffy Cc: Lars Eggert , Stephen Kent , kalyan@juniper.net, ipsec mailling list Subject: RE: Is TS agreement necessary? Date: Fri, 12 Apr 2002 20:01:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't understand the recursive part from both implementation and standards point. The SPD is used to decide what should go into the tunnel, normally a clear packet, not an IPsec packet. When a clear packet is IPsec processed, it carries protocol number 50 or 51. I think any sane SPD imlementation won't let this packet to loop back to IPsec again, but instead pass it out. Just trying to understand this recursive issue, which I fail to observe in the existing IPsec implementations. -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] Sent: Thursday, April 11, 2002 4:43 PM To: Mark Duffy Cc: Lars Eggert; Stephen Kent; kalyan@juniper.net; ipsec mailling list Subject: Re: Is TS agreement necessary? [text deleted] As per other mail to PPVPN, the issue is that the SA of the tunnel appears in the SPD of the tunnel itself. That seems recursive. It seems that the SA of a tunnel should appear in the SPD of the interface (real or virtual) that the tunneled packet will be emitted on. From owner-ipsec@lists.tislabs.com Fri Apr 12 13:58: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 g3CKwVm21915; Fri, 12 Apr 2002 13:58:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00221 Fri, 12 Apr 2002 16:18:09 -0400 (EDT) Message-ID: <3CB743E2.3020702@isi.edu> Date: Fri, 12 Apr 2002 13:30:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wang, Cliff" CC: Mark Duffy , Lars Eggert , Stephen Kent , kalyan@juniper.net, ipsec mailling list Subject: Re: Is TS agreement necessary? References: <4652644B98DFF34696801F8F3070D3FE02008333@D2CSPEXM001.smartpipes.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wang, Cliff wrote: > I don't understand the recursive part from both implementation and standards > point. It's recursive as in 'self referential', not as in 'packets loop'. Perhaps self-referential would have been more precise. The point is that RFC2401 talks about tunnel SAs being in the SPD of the interface over which the tunneled packets go, not the tunnel itself. I.e., putting the SA in an SPD of a tunnel which exists only because the SA says "please encapsulate these packets" uses an SA that refers to the tunnel (i.e., self-referential). > The SPD is used to decide what should go into the tunnel, normally a clear > packet, not an IPsec packet. Ihe SPD decides only whether a packet already sent to the tunnel by routing is tunneled and IPsec'd; having an SPD on a tunnel deciding what gets tunneled is the self-referential part. Joe From owner-ipsec@lists.tislabs.com Fri Apr 12 16:17: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 g3CNHJm27617; Fri, 12 Apr 2002 16:17:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00706 Fri, 12 Apr 2002 18:25:33 -0400 (EDT) Message-ID: <3CB761BD.7090809@isi.edu> Date: Fri, 12 Apr 2002 15:37:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: Lars Eggert , Stephen Kent , kalyan@juniper.net, ipsec mailling list Subject: Re: Is TS agreement necessary? References: <3CAE2BFC.5C8CBC41@juniper.net> <3CAE3D01.10001@isi.edu> <3.0.5.32.20020407122928.007c2600@email.quarrytech.com> <3.0.5.32.20020412104328.007ec850@email.quarrytech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark Duffy wrote: > At 01:43 PM 4/11/02 -0700, Joe Touch wrote: > >>Mark Duffy wrote: >> >>>At 06:08 PM 4/5/02 -0800, Joe Touch wrote: >>> >>> >>>>Lars Eggert wrote: >>>> >>>> >>>>>Stephen Kent wrote: >>>>> >>>>> >>>>> >>>>>>RFC 2401 is reasonably clear in noting that the SPD is nominally per >>>>>>interface. What sort of management interface is provided to a client >>>>>>is up to the vendor, so long as one can achieve the same effects as a >>>>>>per-interface SPD. Otherwise, the implementation would not be compliant >>>>> >>>>>As a side note, I misunderstood this for a long time to mean "SPD per >>>>>PHYSICAL interface", which is not sufficient (because of ambiguities via >>>>>multiple matching tunnel-mode SAs in the same per-physical-interface >>>>>SPD). When viewing tunnel mode SAs as virtual interfaces in their own >>>>>right that have separate SPDs associated with them, these problems >>>>>dissapear. Maybe that's part of the confusion around tunnel mode... >>>>>Lars >>>> >>>>Hi, Steve, >>>> >>>>One of the confusions I have is regarding systems that say they use >>>>these tunnel mode SAs as virtual interfaces. It seems that the tunnel SA >>>>has to be in the SPD of the underlying interface, but they only work if >>>>the SA is in the SPD of the virtual interface (i.e., inside the tunnel). >>>>That seems self-referential... ?? >>>> >>>>Jo >>> >>>I'm not Steve but I'll pipe up anyway :-) >>>It doesn't seem any problem on the outgoing side -- first the forwarding >>>decision selects the outgoing interface (the tunnel). Then the SPD for >>>that virtual interface is consulted (and it has all-wildcard selectors for >>>the single tunnel mode SA). The packet is encapsulated and a new >>>forwarding decision made. >> >>As per other mail to PPVPN, the issue is that the SA of the tunnel >>appears in the SPD of the tunnel itself. That seems recursive. > > > The SA that realizes the tunnel is associated with the SPD of the virtual > (tunnel) interface. Thee is no recursive consulting of the same SPD. See the recent post in response to Cliff. I was talking 'self referential' more than recursive. I.e., contextually recursive, not a recursion of processing or packet. >> It seems >>that the SA of a tunnel should appear in the SPD of the interface (real >>or virtual) that the tunneled packet will be emitted on. > > Why? That would defeat the logical separation between the overlay and the > underlying network that the overlay is aiming to achieve. Because SPDs are supposed to have both tunnel and transport SAs, as indicated in RFC2401. Making a rule about tunnel SAs excluding other tunnel SAs or transport SAs from an SPD is clearly not in RFC2401. >>>When we are the IKE responder, there is some potential ambiguity. >> >>I'm not speaking about IKE at all, FWIW > > OK, but for IPsec to be used in this manner, the IKE side of things needs > to work too of course. What we end up with may require revision of the setup protocol. IKE is already under revision; it is not productive to require an IKE-compliant solution. Joe From owner-ipsec@lists.tislabs.com Sat Apr 13 08:08: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 g3DF8bm23783; Sat, 13 Apr 2002 08:08:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03695 Sat, 13 Apr 2002 10:15:03 -0400 (EDT) From: qzhang@aber-networks.com X-Sent: 13 Apr 2002 14:26:54 GMT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Is TS agreement necessary? X-Sent-From: qzhang@aber-networks.com Date: Sat, 13 Apr 2002 07:26:50 -0700 (PDT) X-Mailer: Web Mail 5.0.8-8 Message-Id: <20020413072654.6646.c001-h010.c001.wm@mail.aber-networks.com.criticalpath.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk is it the same as the "adjacent SPD"? i.e. a packet got ESPed via SPD entry 1, then AHed via another SPD entry 2 pointed to from the SPD entry 1 ? ----- Original Message ----- From: "Joe Touch" To: "Mark Duffy" Cc: "Lars Eggert" ; "Stephen Kent" ; ; "ipsec mailling list" Sent: Friday, April 12, 2002 3:37 PM Subject: Re: Is TS agreement necessary? > Mark Duffy wrote: > > At 01:43 PM 4/11/02 -0700, Joe Touch wrote: > > > >>Mark Duffy wrote: > >> > >>>At 06:08 PM 4/5/02 -0800, Joe Touch wrote: > >>> > >>> > >>>>Lars Eggert wrote: > >>>> > >>>> > >>>>>Stephen Kent wrote: > >>>>> > >>>>> > >>>>> > >>>>>>RFC 2401 is reasonably clear in noting that the SPD is nominally per > >>>>>>interface. What sort of management interface is provided to a client > >>>>>>is up to the vendor, so long as one can achieve the same effects as a > >>>>>>per-interface SPD. Otherwise, the implementation would not be compliant > >>>>> > >>>>>As a side note, I misunderstood this for a long time to mean "SPD per > >>>>>PHYSICAL interface", which is not sufficient (because of ambiguities via > >>>>>multiple matching tunnel-mode SAs in the same per-physical-interface > >>>>>SPD). When viewing tunnel mode SAs as virtual interfaces in their own > >>>>>right that have separate SPDs associated with them, these problems > >>>>>dissapear. Maybe that's part of the confusion around tunnel mode... > >>>>>Lars > >>>> > >>>>Hi, Steve, > >>>> > >>>>One of the confusions I have is regarding systems that say they use > >>>>these tunnel mode SAs as virtual interfaces. It seems that the tunnel SA > >>>>has to be in the SPD of the underlying interface, but they only work if > >>>>the SA is in the SPD of the virtual interface (i.e., inside the tunnel). > >>>>That seems self-referential... ?? > >>>> > >>>>Jo > >>> > >>>I'm not Steve but I'll pipe up anyway :-) > >>>It doesn't seem any problem on the outgoing side -- first the forwarding > >>>decision selects the outgoing interface (the tunnel). Then the SPD for > >>>that virtual interface is consulted (and it has all-wildcard selectors for > >>>the single tunnel mode SA). The packet is encapsulated and a new > >>>forwarding decision made. > >> > >>As per other mail to PPVPN, the issue is that the SA of the tunnel > >>appears in the SPD of the tunnel itself. That seems recursive. > > > > > > The SA that realizes the tunnel is associated with the SPD of the virtual > > (tunnel) interface. Thee is no recursive consulting of the same SPD. > > See the recent post in response to Cliff. I was talking 'self > referential' more than recursive. I.e., contextually recursive, not a > recursion of processing or packet. > > >> It seems > >>that the SA of a tunnel should appear in the SPD of the interface (real > >>or virtual) that the tunneled packet will be emitted on. > > > > Why? That would defeat the logical separation between the overlay and the > > underlying network that the overlay is aiming to achieve. > > Because SPDs are supposed to have both tunnel and transport SAs, as > indicated in RFC2401. Making a rule about tunnel SAs excluding other > tunnel SAs or transport SAs from an SPD is clearly not in RFC2401. > > >>>When we are the IKE responder, there is some potential ambiguity. > >> > >>I'm not speaking about IKE at all, FWIW > > > > OK, but for IPsec to be used in this manner, the IKE side of things needs > > to work too of course. > > What we end up with may require revision of the setup protocol. IKE is > already under revision; it is not productive to require an IKE-compliant > solution. > From owner-ipsec@lists.tislabs.com Sat Apr 13 10:37: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 g3DHbtm00127; Sat, 13 Apr 2002 10:37:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04241 Sat, 13 Apr 2002 12:56:32 -0400 (EDT) From: "Lars Eggert" To: , Subject: RE: Is TS agreement necessary? Date: Sat, 13 Apr 2002 10:08:51 -0700 Organization: USC Information Sciences Institute MIME-Version: 1.0 Message-ID: <000a01c1e30d$e2de1610$b27ba8c0@isi.edu> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-Type: multipart/signed; boundary="----=_NextPart_000_0005_01C1E2D3.35B3FED0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 In-Reply-To: <20020413072654.6646.c001-h010.c001.wm@mail.aber-networks.com.criticalpath.net> Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1E2D3.35B3FED0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > is it the same as the "adjacent SPD"? i.e. a packet got > ESPed via SPD entry 1, then > AHed via another SPD entry 2 pointed to from the SPD > entry 1 ? I think this is an unrelated issue. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California ------=_NextPart_000_0005_01C1E2D3.35B3FED0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFzCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcN MjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1 KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZ FKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVc CM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx +NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIDaTCCA2UCAQEwgZow gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggIkMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDQxMzE3MDg1MFowIwYJ KoZIhvcNAQkEMRYEFKt22UmL4Bqjec7LezS44SqmN2W5MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwBwYFKw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYT AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMG VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYD VQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJz b25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEBBQAEgYCuC7eaG9TV W3Kzkuf1lqvcxxjcnfwECrrqr/GtA5zG8vQg9LLGjkkYRusQbjxshUIMWFRqVfMF8vXbX168YE6S bewu6GdFvEcCuu19Ya8DgevZfNdjPN6P+qwk1hik3nAD3d6+1DID4ukyMG3n0Ie9vz3ql0wAzpl8 Yfk0Ub1vbwAAAAAAAA== ------=_NextPart_000_0005_01C1E2D3.35B3FED0-- From owner-ipsec@lists.tislabs.com Mon Apr 15 09:11: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 g3FGBKm26422; Mon, 15 Apr 2002 09:11:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12521 Mon, 15 Apr 2002 10:47:10 -0400 (EDT) Message-ID: <3CBAEA80.982BFFD7@thematrix.ncsc.mil> Date: Mon, 15 Apr 2002 10:58:08 -0400 From: "Casimir A. Potyraj" X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: design@lists.freeswan.org, ipsec@lists.tislabs.com, internet-drafts@ietf.org Subject: Re: update to draft-richardson-ipsec-opportunistic.txt References: <200111090459.fA94xET10837@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > A new draft is at: > http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/ > > ID secretary, please publish the version with change bars: > draft-richardson-ipsec-opportunistic-03-change.txt > > Thank you. > > there is a version without change bars: > draft-richardson-ipsec-opportunistic-03.txt > > HTML: > draft-richardson-ipsec-opportunistic.html > > ChangeLog: > > 4.2 the forward reference to section 6.2 has been made more obvious. > > Section 5.6: "Interactions with COPS" has been removed. > > Section 5.7.1, phase 1 IDs, exception clarified. > > Section 6.2, use of TXT record, the following paragraph has been added to > deal with key rollover: > > If there is more than one such TXT record with strongest (lowest > numbered) precedence, one Security Gateway is picked arbitrarily from > those specified in the strongest-preference records. All keys for > that all listed Security Gateways are made available as candidates > for signature checking. This mechanism is required to permit rollover > of signature keys in a seamless fashion. > > Section 6.2.1 has been rewritten to include a note on the KEY record, on > possible future use of the CERT record. > > A section has been added as section 10, "Renewal and Teardown". > It has subsequently been moved to between: "Detailed description of process", > and "Impacts on IKE". > > A section "Failure modes" completed was completed. > > A section "Multihoming" has been expanded. > > added lifetime/lifespan definitions. > moved example from 5B to 5C. > added reference to phase 1 IDs to 5D. > cleared up text in aging section. > added text about delegation of DNSSEC activity to a DNS server. > spelt out DH group names. > added text about ignoring TXT records unless DNSSEC is deployed (somerfeld) > added example of TXT delegation using FQDN. > clarified some text in NAT interaction section. > clarified absense of TXT record need for host implementation > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Finger me for keys > > iQCVAwUBO+tilIqHRg3pndX9AQFddwQAuhTJWap4yJN4/OfoYntqeL3daLJ1eNdD > XmcUWY/gO+AIE2PO1Ys9zJMZlUOKH3j1Hs5NTKeh8Xs6+/VTAnJ1USVEvcAm+lIX > KNhFxDCCVGruCuUWoyvCqPdK2VFfKdbA4tFz77gcrE7t+pm8YQ2o7H/hFrQMbHT7 > UJyQn6M2DtQ= > =j1Zz > -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Apr 16 02:17: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 g3G9HGm25905; Tue, 16 Apr 2002 02:17:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14928 Tue, 16 Apr 2002 04:21:55 -0400 (EDT) Date: Tue, 16 Apr 2002 11:34:17 +0300 Message-Id: <200204160834.LAA24395@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com Subject: Re: handling of ICMP error codes in 2401bis References: <200204102305.g3AN5Yi04074@marajade.sandelman.ottawa.on.ca> In-Reply-To: <200204102305.g3AN5Yi04074@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Few, somewhat delayed comments... First, my view is When an ICMP error message is generated from ESP protected incoming packet, then the *ONLY* valid handling alternatives are 1) do not send the ICMP error 2) apply protection based on the selectors of the received packet (as proposed by Michael Richardson) Doing anything else, may break the security. Just having some policy and IPSEC protection for ICMP errors could be sufficient, if it is the strongest protection in the policy (otherwise, errors occurring in strongly secured flows mignt cause a leak of information). But, I think this will create security pitfalls for unwary administators. However, in the proposal... > At first take it may seem that this technique does not require any > negotiation, and can be implemented as a local policy. This is not > the case. The receiving end of the SA will do tunnel exit > checking, and unless it is also implementing this policy will > reject the packet and flag a security violation. Taking into account the choices (1) and (2), I don't think negotiation is necessary. Either you do the policy check based on the error packet or you drop the ICMP. --- Implementing this logic for IPv4 is fairly simple and easy (I've done it). However, IPv6 and extension headers will cause some implementation difficulties, consider IP ESP DOP EXT TCP ... (e.g. DOP=Destination Option, EXT some other extension header). If ICMP is generated in DOP (unknown options or something), there is a problem with IPSEC finding out the proper selectors from TCP headers, unless it also knows the format of EXT header (otherwise it will just assume EXT as upper layer). Not really unsolvable, just adding some complexity. Adding a new extension header implementation needs to provide a way for IPSEC to skip over it... From owner-ipsec@lists.tislabs.com Tue Apr 16 08:01: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 g3GF1dm29765; Tue, 16 Apr 2002 08:01:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15721 Tue, 16 Apr 2002 10:08:22 -0400 (EDT) Message-Id: <200204161416.g3GEGQ723996@marajade.sandelman.ottawa.on.ca> To: Markku Savela cc: ipsec@lists.tislabs.com Subject: Re: handling of ICMP error codes in 2401bis In-reply-to: Your message of "Tue, 16 Apr 2002 11:34:17 +0300." <200204160834.LAA24395@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Apr 2002 10:16:26 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Markku" == Markku Savela writes: Markku> Few, somewhat delayed comments... Markku> First, my view is Markku> When an ICMP error message is generated from ESP protected incoming Markku> packet, then the *ONLY* valid handling alternatives are Markku> 1) do not send the ICMP error Markku> 2) apply protection based on the selectors of the received packet Markku> (as proposed by Michael Richardson) As I read your message, I thought that you were going to make the point that using a seperate (but differently keyed) SA for ICMP messages introduces some interested new ways to get possible more known plaintext. Or that the ICMP stream could be protected (by accident) by a much weaker cipher. Markku> Implementing this logic for IPv4 is fairly simple and easy (I've done Markku> it). However, IPv6 and extension headers will cause some Markku> implementation difficulties, consider Markku> IP ESP DOP EXT TCP ... Markku> (e.g. DOP=Destination Option, EXT some other extension header). If Markku> ICMP is generated in DOP (unknown options or something), there is a Markku> problem with IPSEC finding out the proper selectors from TCP headers, Markku> unless it also knows the format of EXT header (otherwise it will just Markku> assume EXT as upper layer). Yes, a problem. Worse in IPv6, but the amount of returned header is much larger in v6. Markku> Not really unsolvable, just adding some complexity. Adding a new Markku> extension header implementation needs to provide a way for IPSEC to Markku> skip over it... That's pretty trivial to code. Hardware to do that is also on the market. ] 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 NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPLwyOIqHRg3pndX9AQEFHAQAzR5hE1vk+p0ZR/hkcFt3YvpGVb4bJsyU Vaudms+mlUyBK5AS8el434Pu1p6qr3tVRmAuY79+bjQ4rDBnIg3AISM/XE+FGgqO k6ebkzlhWnfp/yNOPnRvWnVOx3ol8NGsW4T11Xvp1WnGrGbojcYYgvwsBGOtIr8C ZHvNAZHdgws= =Q83f -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Apr 16 10:22: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 g3GHM5m10377; Tue, 16 Apr 2002 10:22:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15969 Tue, 16 Apr 2002 12:21:11 -0400 (EDT) Message-ID: <00e901c1e564$70e487c0$6729660c@riverside> From: "Jin Zhang" To: "ipsec mailling list" References: <4652644B98DFF34696801F8F3070D3FE02008333@D2CSPEXM001.smartpipes.com> <3CB743E2.3020702@isi.edu> Subject: regarding the DELETE payload Date: Tue, 16 Apr 2002 09:33:28 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If peer sends me a DELETE message, and asks me to delete an ESP SA which has SPI = 1000, how can I locate that SA in my SA database ?? I need to locate a SA. However I have no information about the destination IPaddress. It could be my own IPaddress, if peer wants to delete its outbound SA. It also could be peer's IP address, if peer wants to delete an inbound SA. Thanks for your clarification. Jin Zhang Elmic Systems, Inc USA From owner-ipsec@lists.tislabs.com Wed Apr 17 09:31: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 g3HGVcm15159; Wed, 17 Apr 2002 09:31:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19175 Wed, 17 Apr 2002 11:14:45 -0400 (EDT) Message-ID: <20020417152638.741.qmail@web8004.mail.in.yahoo.com> Date: Wed, 17 Apr 2002 16:26:38 +0100 (BST) From: =?iso-8859-1?q?ranjeet=20barve?= Subject: SA Refresh: When Lifetime in Bytes ?? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I had a doubt in the implementation of IPsec SA Lifetime(Hard and Soft) when specified in bytes. Consider following scenario: Current_Bytes /*Number of bytes processed by IPsec*/ Soft_Lifetime_Byte /*holds relative value e.g. 1000bytes. So to check if this is expired you take the current value, if it is greater than or equal to Soft_Lifetime_Byte you say that the Soft Lifetime has expired.*/ Hard_Lifetime_Byte/*holds relative value e.g. 100000 bytes. So to check if this is expired you take the current value, if it is greater than or equal to Hard_Lifetime_Byte you say that the Hard Lifetime has expired.*/ I suppose the major problem with bytes could arise due to the faulty nature of the link which carries IPseced packets. Due to this,(loss of packets on the link) the CURRENT BYTES COUNT(the number of bytes processed by IPsec) at transmitter and responder could differ. This may not lead to a problem with Soft Life Bytes as the one whose CURRENT BYTES COUNT matches the Soft byte count early, would trigger a SA Refresh. Please correct me if I am wrong. But with Hard Life Time the problem would arise when there is a discrepancy of the CURRENT BYTES COUNT at the Responder and Initiator. Suppose at the Initiator, the CURRENT BYTES COUNT reaches the Hard Life (bytes) earlier and deletes it's SAs. But at the Responder the SAs remain active forever as their CURRENT BYTES COUNT would freeze and never reach the Hard Life Bytes value. How do we solve this problem? I appreciate your help in this regard. Thanks and Regards, Ranjeet Barve. M.Tech, IIT Bombay ________________________________________________________________________ For live cricket scores download Yahoo! Score Tracker at: http://in.sports.yahoo.com/cricket/tracker.html From owner-ipsec@lists.tislabs.com Wed Apr 17 14:13:24 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 g3HLDNm03870; Wed, 17 Apr 2002 14:13:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19886 Wed, 17 Apr 2002 16:08:22 -0400 (EDT) Message-ID: <3CBDD917.834B01DE@torrentnet.com> Date: Wed, 17 Apr 2002 16:20:39 -0400 From: James Comen X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 2.2.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IKE lifetime seconds Content-Type: multipart/alternative; boundary="------------E181AAE670B830A24719D4EA" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------E181AAE670B830A24719D4EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit When the ike protection suite lifetime is reached (either in time or kb), the IKE sa is deleted. I've seen nothing that suggests that it should be automatically renegotiated like an ipsec SA. I'm assuming that the IKE sa must be negotiated again via the receipt of a packet which requires ipsec protection. Is this correct, that there should be no automatic renegotiation of the IKE sa? Thanks Jim -- Jim Comen jcomen@torrentnet.com Ericsson IP Infrastructure Voice (919) 472 - 9932 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 Raleigh, NC 27606 --------------E181AAE670B830A24719D4EA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit When the ike protection suite lifetime is reached (either in time or kb),
the IKE sa is deleted.
I've seen nothing that suggests that it should be automatically renegotiated
like an ipsec SA.  I'm assuming that the IKE sa must be negotiated again
via the receipt of a packet which requires ipsec protection.
Is this correct, that there should be no automatic renegotiation of the IKE sa?
Thanks
Jim 
-- 
Jim Comen                           jcomen@torrentnet.com
Ericsson IP Infrastructure          Voice (919) 472 - 9932
920 Main Campus Drive, Suite 544    Fax   (919) 472 - 9999
Raleigh, NC 27606
  --------------E181AAE670B830A24719D4EA-- From owner-ipsec@lists.tislabs.com Wed Apr 17 15:47: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 g3HMlWm07201; Wed, 17 Apr 2002 15:47:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20306 Wed, 17 Apr 2002 18:01:49 -0400 (EDT) Date: 17 Apr 2002 18:04:54 -0400 Message-ID: <000701c1e65b$e896e4a0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'James Comen'" , " " Subject: RE: IKE lifetime seconds MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C1E63A.618544A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3CBDD917.834B01DE@torrentnet.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C1E63A.618544A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Some implementations will automatically rekey the IKE SA and some won't. This issue was never resolved in the RFCs, and it became known as the "continuous channel mode" vs. "dangling sa" debate. The failure to standardize this issue has led to a myriad of interopability bugs. There is some indication that the issue will be resolved in favour of continuous channel mode. This is the recommendation of draft-spencer and it was also proposed in draft-jenkins (an expired draft on rekeying). Also, IKEv2 mandates continuous channel mode. 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 James Comen Sent: Wednesday, April 17, 2002 4:21 PM To: ipsec@lists.tislabs.com Subject: IKE lifetime seconds When the ike protection suite lifetime is reached (either in time or kb), the IKE sa is deleted. I've seen nothing that suggests that it should be automatically renegotiated like an ipsec SA. I'm assuming that the IKE sa must be negotiated again via the receipt of a packet which requires ipsec protection. Is this correct, that there should be no automatic renegotiation of the IKE sa? Thanks Jim -- Jim Comen jcomen@torrentnet.com Ericsson IP Infrastructure Voice (919) 472 - 9932 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 Raleigh, NC 27606 ------=_NextPart_000_0008_01C1E63A.618544A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Some=20 implementations will automatically rekey the IKE SA and some won't. This = issue=20 was never resolved in the RFCs, and it became known as the = "continuous=20 channel mode" vs. "dangling sa" debate. The failure to standardize this = issue=20 has led to a myriad of interopability bugs.
 
There is some indication that the issue will be resolved in = favour of=20 continuous channel mode. This is the recommendation of draft-spencer and = it was=20 also proposed in draft-jenkins (an expired draft on rekeying). Also, = IKEv2=20 mandates continuous channel mode.
 
Andrew
-------------------------------------------=20
There are no = rules, only=20 regulations. Luckily,
history has shown that with time, hard work, =
and lots of love, anyone = can be a=20 technocrat.
 
-----Original Message-----
From:=20 owner-ipsec@lists.tislabs.com = [mailto:owner-ipsec@lists.tislabs.com]On=20 Behalf Of James Comen
Sent: Wednesday, April 17, 2002 = 4:21=20 PM
To: ipsec@lists.tislabs.com
Subject: IKE = lifetime=20 seconds

When the ike protection suite lifetime is = reached=20 (either in time or kb),
the IKE sa is deleted.
I've seen = nothing=20 that suggests that it should be automatically renegotiated
like an = ipsec=20 SA.  I'm assuming that the IKE sa must be negotiated again =
via the=20 receipt of a packet which requires ipsec protection.
Is this = correct, that=20 there should be no automatic renegotiation of the IKE sa?
Thanks =
Jim 
-- 
Jim =
Comen           &n=
bsp;           &nb=
sp;   jcomen@torrentnet.com
Ericsson IP =
Infrastructure          =
Voice (919) 472 - 9932
920 Main Campus Drive, Suite 544    Fax   (919) =
472 - 9999
Raleigh, NC 27606
  ------=_NextPart_000_0008_01C1E63A.618544A0-- From owner-ipsec@lists.tislabs.com Fri Apr 19 05:12: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 g3JCCnb16196; Fri, 19 Apr 2002 05:12:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03786 Fri, 19 Apr 2002 07:10:15 -0400 (EDT) Message-Id: <200204191122.HAA15851@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-jfk-03.txt Date: Fri, 19 Apr 2002 07:22:14 -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 : Just Fast Keying (JFK) Author(s) : W. Aiello, S. Bellovin et al. Filename : draft-ietf-ipsec-jfk-03.txt Pages : Date : 18-Apr-02 This draft discusses JFK, a key management protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-03.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-jfk-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-jfk-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418140811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-jfk-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-jfk-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418140811.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Apr 19 07:40:44 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 g3JEeib24612; Fri, 19 Apr 2002 07:40:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04139 Fri, 19 Apr 2002 10:00:04 -0400 (EDT) X-Originating-IP: [217.144.8.254] From: "rula amer" To: ipsec@lists.tislabs.com Subject: discussing IP Security Working Group (IPsec) Date: Fri, 19 Apr 2002 14:12:05 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 14:12:06.0230 (UTC) FILETIME=[2F9D1760:01C1E7AC] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk discussing the business of the IETF's IP security working group(IPsec), which is an open forum for discussing the standards efforts on IP Security. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ipsec@lists.tislabs.com Fri Apr 19 07:43: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 g3JEhKb24687; Fri, 19 Apr 2002 07:43:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04128 Fri, 19 Apr 2002 09:57:02 -0400 (EDT) X-Originating-IP: [217.144.8.254] From: "rula amer" To: ipsec@lists.tislabs.com Subject: discussing the business of the IETF's Date: Fri, 19 Apr 2002 14:09:00 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 14:09:00.0266 (UTC) FILETIME=[C0C53CA0:01C1E7AB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk discussing the business of the IETF's IP Security Working Group (IPsec), which is an open forum for discussing the standards efforts on IP Security. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ipsec@lists.tislabs.com Fri Apr 19 07:43: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 g3JEhLb24696; Fri, 19 Apr 2002 07:43:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04127 Fri, 19 Apr 2002 09:57:01 -0400 (EDT) X-Originating-IP: [217.144.8.254] From: "rula amer" To: ipsec@lists.tislabs.com Date: Fri, 19 Apr 2002 14:08:42 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 14:08:43.0584 (UTC) FILETIME=[B6D3C400:01C1E7AB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk discussing the business of the IETF's IP Security Working Group (IPsec), which is an open forum for discussing the standards efforts on IP Security. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ipsec@lists.tislabs.com Mon Apr 22 01:15: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 g3M8Exa15755; Mon, 22 Apr 2002 01:14:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA09657 Mon, 22 Apr 2002 03:06:16 -0400 (EDT) Date: Mon, 22 Apr 2002 15:20:59 +0800 From: Jerry Yao Subject: About UDP Encapsulation of IPsec Packets To: ipsec@lists.tislabs.com Message-id: <002401c1e9ce$61e46f60$04a7c6ca@server> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I read the IETF draft "UDP Encapsulation of IPsec Packets" and I have a question about it. If I receive a packet from the communication peer who behind NAT, and the packet is Transport Mode ESP Encapsulation: ------------------------------------------------------------- IPv4 |orig IP hdr | UDP | Non-| ESP | | | ESP | ESP| |(any options)| Hdr | IKE | Hdr | TCP | Data | Trailer |Auth| ------------------------------------------------------------- |<----- encrypted ---->| |<------ authenticated ----->| Now I don't know the original IP address of the communication peer, How can I locate the corresponding sa to decrypt or authenticate the ESP packet? From owner-ipsec@lists.tislabs.com Mon Apr 22 01:32:26 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 g3M8WQa19638; Mon, 22 Apr 2002 01:32:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA09771 Mon, 22 Apr 2002 03:46:19 -0400 (EDT) Date: Mon, 22 Apr 2002 04:04:41 -0400 (EDT) Message-Id: <200204220804.EAA29216@sentry.gw.tislabs.com> From: tytso To: ipsec@lists.tislabs.com Subject: A nice game MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=OUKk15R8NJ19iV3859w7aCd1BKvrI Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --OUKk15R8NJ19iV3859w7aCd1BKvrI Content-Type: text/html; Content-Transfer-Encoding: quoted-printable This is a special nice game
This game is my first work.
You're the first player.
I hope you would like it. --OUKk15R8NJ19iV3859w7aCd1BKvrI Content-Type: text/html; name="setup.exe.htm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="setup.exe.htm" X-NAI-Gauntlet: Attachment removed VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Internet Firewall ® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: setup.exe
Virus name: W32/Klez.gen@MM

Copyright © 1999-2000, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.nai.com

--OUKk15R8NJ19iV3859w7aCd1BKvrI --OUKk15R8NJ19iV3859w7aCd1BKvrI Content-Type: application/octet-stream; name=homeworld_link.jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgEAYABgAAD//gAmRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hv cKggNS4w/+4AIUFkb2JlAGRAAAAAAQMAEAMCAwYAAAAAAAAAAAAAAAD/2wCEAAICAgICAgIC AgIDAgICAwQDAgIDBAUEBAQEBAUGBQUFBQUFBgYHBwgHBwYJCQoKCQkMDAwMDAwMDAwMDAwM DAwBAwMDBQQFCQYGCQ0KCQoNDw4ODg4PDwwMDAwMDw8MDAwMDAwPDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDP/CABEIAOABkAMBEQACEQEDEQH/xAENAAEAAgIDAQEAAAAAAAAAAAAA BQYHCAECBAMJAQEAAwEBAQEAAAAAAAAAAAAAAQIDBAUGBxAAAAUDAQQKAQMEAwEBAAAAAAEC AwQRBQYHEBIXCCAwITITMxQVFjY3QFAxIjQYCUEjNSVCEQACAQIEAgMJCgoDCQoPAAABAgMR BAAhBQYxEkETBxBRYXEiFJQ1CIEy0rPT43WlNnYgMJGhsUIjM7QVQMFS0WJygpPUlbUYUPBT Y8M0RCWFFvGSorLCQ6MkZKRlJhd3KBIAAQMBAwgHBQQJBAMAAAAAAQARAiExQRIgUXGBkbHR AxAwYaEiMnJAUMGSE0KCsjPw4fFSYqLCgwTiI1Nj0nMU/9oADAMBAQIRAxEAAADA/r/ndSAB 7TzxbRry/vfrXUAAAAAAAAAAcnAAOQcAAAAAAG7fr/nfup0RJCV2lJrP6cceSx9AAAAAAAAA AAAAAAAAAAACj11nrZRtOiGKnTptl+a135/gnWXi+l4jQAAAAfeHwmSOTgAA7E6QAAAAAAAA ALDOWwPb81DE+eiusSR8XmEfa+HxNJvL+7606QAAAO5k+jF93U5ODk4Ox1LPMV+J+AAAAAAA AALrfm2m9T4SGLmQoAANJvL+7606R2ODgHYyhne31n2xSfiuIdZxlcOoAJFErKtRPAAAAAAA AALrfm2m9T4SGLmQoAANJvL+7606R3PqZUvlYOfTZTmvU47/AIa+f5pRkTX9KRkzja6m2Rh2 OpdJrTIsODscHBycAAAAAAF1vzbTep8JDFzIUAAGk3l/d9adI5NxqrVnOU+a2Ecr3DZRNubh H3jWFtWuXpTpv5dK4xi3lTbZiIiYgAAAAAAAAAF1vzbTep8JDFzIUFbrrHRcDVrzftua7cGf 8tI+1Mq8c595+6g9vm4y0YMj1Msz5lkivmXrl4gJrT9qwFNINNxmKHEgAAAAAAAAAXW/NtN6 nwkMXMhQav8AB9ZR+b2uEJcHKJQ3Sq1jN6/NvVr99C6vJrs3x/HV7Z5/dCkXTE18nRjXq3+9 Z+ETR1vgAAAAAAdzoAAAXW/NtN6nwkMXMhQax8H1lK5vcmZjyo+x1V2AiLpWa7Rs1wb4m6+a g6TX41kVYu+WOLWmaWqmlZrfH2ZaeOY+yfhFsaRPzAB9j5nUEuRJwAAAAC635tpvU+Ehi5kK DWLg+tjOb279bGnWpLJhYtcst9iebuksZ9XR5eBemtItXqmnJyHmmr50DPaY3xkt8fHydXw1 rJxGY1cE10hon2Vn1Q9SfMeiY+MST0RTrPLKBAAAALrfm2m9T4SGLmQoNbOH6+o83udSaUlo mLU2FpCFrxUXVXta0y1eqa4m6Upb9MoW0+vbKr01646/XSlqiNkEUuVAz1uFdMpxEWjDdUna v3ztNpq9J8l41f2S0KrIAAAXW/NtN6nwkMXMhQaycP13j5vYtakFfP1rQ9ZvuO2R4pZMr4t0 rxaJ2GNbqTethptbrT16/M7SpOO8pnp698b3WLFnvrsiNPUXsmqWpcxlKIkcre6utK2yxlKj TMiRgAAALrfm2m9T4SGLmQoNZOH62tYe374rFTHWI+abNSc3M/jWvqrrVNa490z961XibTTe 7bY/Pbhha61XLWSraX2wseemNKa0iJ4OAD3mV1M481rDM0iba66VpFwAAAAut+bab1PhIYuZ Cg1l4frqPh7fSI6xXrMIT0RtTnTpE9otRdFGvXyHwtWZvl79Kzl8vLLFnL2+is+KV5ytQbK/ LsdQdzsbExW/ZTONOjOsVnVvoQoAAABdb8203qfCQxcyFBq/xfWUfm9rrEcIlIZ1zrmmmNiz tFSr1pqN7Vi6o9nH6s9vmmT1ykr0wpy9sJS45ODMWbHF4hJkAcmYVbvlrkKFdtX2YWwT0Z4w vIAAAF1vzbTep8JDFzIUGr/D9XROb2exk6jajnreaQifHM1q9sJ75xUvI1gtMPMmZ2yltMqT TbHHP0DudAcmV6xQpmEkPsWhHnTkSsXil7NF6DNIm1cGXcAAAAut+bab1PhIYuZCg1d4fq6R zezmOGfqO0ISipTHsmLXF6NelVtFOmfDZ9ZretsOt64Z5e3zQAAAyFWtbtMCmWIo4MhxXajK FIxNpOH9L06XAOx1AALrfm2m9T4SGLmQoNXeH6r18vtZbrFglWk1irzTPhmuU6T5LRQLVhLI u633x+Nq4xx6Y+tuTqcg4AOxZYVmXAhzKQNm+dH6ImzDPREDlPWAA5BwIXW/NtN6nwkMXMhQ YP4fqvfy+37ld3vrvCrWWmjPyvtb4fW+HlTr5fPnrYuzCqnk57TkvBpn+QHx3036f/Y/OzJ4 +rL00td7Re861aJ0j8X0/RpGw/ocn5o/M+1+hv1HiZX1wxTXW2dmFew0hOLozKrB92UFrFd4 tsla4aK/O+xrF4Pp/o59p89ZezCe1pAYaa9eD6WvPg9m03qfCQxcyFBirg+qqfD9BaoncT7L 5rnS3x2z9HNpvc59Lt9Nc/E7tnfQ48szPg2x7+pz4o5tLttEhyWx924+yJt/qef58dsHeJ6n kmLD247YRGj/ADbZ/ikX38+KfN7daPI7tv8A0/Pie7G+897r0ZWijBu01Hn0wn4/o6XfP+rv 39j8/lW1NWvJ9Haz1/NxnTTSn5D19pvU+Ehi5kKDBHB9Vk/m9uhRfcv6357IOueIuLfKHo82 0lM9NLbwtJv9qXCl/pthgTefph0d7ZZc05ojeLThpcu/kiZfmT8t9B+hHrebdunHDMzk/m0x HM484d/T0Vr8sq3z775efg6O3qc8hVas7YhxtkCWGcN9iIpjLeuOaXvlqxGc6NfH+xtN6nwk MXMhQavcP1Xp5vZuJsn9H5EFS2rPheptz9B5Ns6OfIUMe3QtmPcts96Y/nR4/q/on6/l/nT4 nq/of7vkYztaaiOLxN1fnV8z7u/f0XifQ1Z8r0trvW8zBPm92vvB2b7e/wCR5b0+ksG8PZtN 28P5w/P+3d9ct0vc8nwJi5n5yy9y6Yl3oR6zU3xfUqHm32m9T4SGLmQoNXeH6qjc3tD6y9SP XKSmlp0zouW0JWwAAAAAAAAAAAAAAAAF1vzbTep8JDFzIUGrvD9VRub2gABycAAAA5OAAAAA Dk4AAAAAAALrfm2m9T4SGLmQoNXeH6qjc3tAADk4AAABycAAAAAHJwAAAAAAAXW/NtN6nwkM XMhQcV14i4j4vpv5v2vEaAAAAAAAAAAAAAAAAAAAXK/Nsh6nwkQXMgwAATIAAAAAAAAAAAAA AAAAAAAIw//aAAgBAgABBQDpGVSUVD/a1mZCp728dDNRF+2KSSiCv5LvH3FfzsVIUR+qUPVK HqlD1Sh6pQ9UoeqUPVKHqlD1Sh6pQ9UoeqUPVKHqlD1Sh6pQ9UoeqUPVKHqVD1Sh6pQ9Uoeq UPVKHqlD1Sh6pQ9UoeqUPVKHqlD1Sh6pQ9UoeqUPVKHqlBMhRntUmo3e3cKhortc73Vfwr9Y 33upc73TU4SQTxGDdG/vBKyPqD/SN97qXO90DRQluEkKdWY8QyMjMwaQRUFARmQ3v1Tfe6lz vbTMKUYUdQ22pIS2QpQfyDCa7CMq07Nhfpm+90TURDxEjxEjxEhZ1VseWpKUJ3Sn+MbMVK9x KQQqYMjFKjtIJHglvq/j9Q33ujK71ekYUdCW5vvto7RQdhGazCTMEoggyUDKhnsL9O33ujK7 2ygoKCorQ3VlRpuhpSKAioN0qlQUILINJ3UkXYZ/qW+90ZXeqCBbKgzIIIwlJmbaO0kkCQQ3 SBlsIgv+Wf6iX3V1FNlAYqDWQ3xvkCXUbw3x4hDxCMEoj6tvvdGUVVEQMVIb1R2ivbXsMwns BKIbw3iFS2JIeGRmRERKOpH/ACKBJ9riUhtNRukkzOgNXYk+xVSIjIz3v6VEGypsIyPqW+90 ZJ/1AiIEWxQMyM/+DIFUF2CpgiUYJIX2Ez2mRUCjoF0qFkRAy7BvGQ3zG8YM6gyqKFQ6jugl kCIlDdIz6pvvdGT3qbK0FQYNJCiQppNU9pkRAi2qQaiaQadi/wCT2UClV6hR0JRmZ7vZvKIk qr1bfe6Mkv6iB9AzoDWRiqTBHQEsE4N6uxJj+QRBxREW9UVG+YVUgR1LpL/hBVB9odookn2F 29U33ujJP+qu0zoCWazdogyUWwiBJ2NoKii7UgiBnQLWaj6BpoZHXpH/AAmoMqA6ETKd1JH1 Tfe6MrvbFLoDVvA0mN0bphKQQoCIFUV7SBB5XTMqAjr0aAy2KTUkdhF/PUt97oyu8DMUG4QN sEkGVSoE7C2EVQQM90jOvUGQLtLoH/CnDqpYaMjKnVN97oyu8ZigoYoDIERihigJJigoN0wS TIGdCVVR7pig3TG6YoYoYoKChigoKCg3TBkNwyG7UIbMx6Z0GkyFDFBQUG6Y3TFBQN97oyu9 XZC3Wo1z3XIwt6SairbbkttE3vk2owsjShluM+v1BkfY6p2OtD1ERQuSpKnyQyGnUrb8VsOv EROuqaXeo1W7IxutJmksrtGSxKQSYqTYbeZbUnxPCWYkf9aEwo8tanySdHCBuupJJMXA1uEl d9Sk1CHusxWXVPI/rD7hNFdICCbb73Rld5JK32F7xN/2EJ9DzXpWBMkIYbSr+httKj96WQhT DlJkqJpLaPESmKTQUyla1RTqUc2DuBETNtQpxFHQ48pC4y/VME0b7FrYJCbct9bqoJvu7xqW lSTKPulH9+dFul+qK1luOH5ijbMLJJpQytuS8VJF77oL+wUpLMb3wxDdTKZP+uA33ujK71DM F2G3/Y+L6dj39IcUmRGbYUptDvhL9pjrHpmYqTjKkpY/oMn99115o5ciSbaX1b7twqbURKXC JlswZNNHbEk1KN1SDQ8a2ylJdXIeopLqUFZ5NWWaIBWSMYJDEJNrSo1vNJccVMNk3JJPoika pUx5KX3IKJCfZY4efQbcckyWTsccO+HFS8Xgwm+90ZXeLsBCHcmENXC4tOs0EO4soZXeEoSi 5sUK7xiCb1GI039tpz3WJQrkaZh3OFuyrgp+Qq7xFEq+xnVJvUdJe+Rwd6jKD8k3H/eoyh71 GSdunoZUV5jkLjcm3m4U1cRxu8RSI7xFCb1GILvm6pd2iGVxllKftc1EZaLxEQpV5imfvccg d7jmEToSXPeIo95jEPeo4n3I5BN97oyu9sqKjeBLoCdClGf7I33ujK737W33ujK737W33uia SMeGkeGkG0kyUVD/AGdvvfun/9oACAEDAAEFAOkhZoUw4bjf7XHQhQ3EEz4DZuNoZUr9sYeU ysMdxXkJ/uWO4CpVmzMOI9jYHsbA9jYHsbA9jYHsbA9jYHsbA9jYHsbA9jYHsbA9jYHsbA9j YHsbA9jYHsbA9jYHsbAKxsD2NgexsD2NgexsD2NgexsD2NgexsD2NgexsD2NgexsD2NgexsD 2NgexsD2NgexsB+zMtt7WnjbMnj3PUq3kSDSeyH5H6M/0kzyOph+R0yaWoltLQREFF1BnQEX 6SZ5HUw/I6CXiWZqIghKjM4KiaPsCVA+0EdBXpH2n+kmeR1MPyOgQoQUupvSVrFa7COoUQIU Fe0thgv0szyOi2w44Xo3x6N8ejfEZBoa2NJSpSjqaKVkxCaZUfagu30bFXEElSdu+dCBHsL9 NM8jo2IqsboMhQU6JdhPz0uNlUwSTByXTTQUpsWW6EnUiFQfaC/TTPI6NhMvAqN4gayIEsGq uymx1aDSowkLWRkTpkVVBKhUOHvGpQLaR/ppnkdGwlVg07FAgQQkzTcCTW4Nk2g9ijBGCChv U2OGZBsu1AM6mZgl0G+Q3iFRXYZ0FS2GRkC6yZ5HRx8/+gzFSBmkVSFqIxunQiG6QoDIGkEQ oFgxvmRVM1JTun/xUGNwNqWSXlbhuOqdMUIKIVTUk9tDBdhmVermeR0bCR+AZCoP+SBD/wDJ AthgzSKkKiOjfdmoSlJmEJqEEdCIEYI6nQeGkeGkeGQ3BQGR7DMwaVJB1IyKnVzPI6Nh8g+0 t0GghQhQGVBVYJaqGDMGCBCO8TTkt9LgMNmW7UH/AAZhCSFOmZUMEaSM90z6uZ5HRsPkAzBn tMxvFUlCtQZA07DMgoiMEDDaTM9ygoNwhQq9P/lZUBN+GEb6CURl1czyOjYjoxvCu1St0kGa yNJigItq1nVH8GDBEZmhBILokfSP+VoIiIzIHUyUszIj6qZ5HRsfkbTIwRioLt21BqorcKu7 UjBhhHTp0y7B/wAIeUWynVTPI6Nj8jbXYZAuwVBlsrsUqgMwkt4yKnUGQI+iYJG6RfyZnXqp nkdGx+RtptPon/BhKTUEpJP6EiMwYqXVTPI6Nj8imySpa5EJS0viYta5BPOR3DJ1Sd4yCSUp Tjz7BJbWpKt9okLTubzslSmlpQh1x01trQrdUD3iDBLeK1yDUd0fMlORnWyhPeKytbkhxuW4 2taHjSa6BpC3DTLdZDKHFp3qgiMzN16GbfiOJta1KbEpS3JDjam1dobadWcCWpapnkdGx+Qs 07jyN0H/AHshh1tzflCPHcW5JTVx8z3jtjZiXGSwkkm4S1eGhDpukmSaWjWTaPG8VqIdXbhR C99IaJKhLT6d41EzJlu7zyzbMo8ommE/9bLrW4l8jck+0si4RyjldDqGq+nQttJKcbMS3CNm J5Fp7gX/AHyG/Fk+1tiQj0zxFuzpnkdGx+QS90qbyT/vVNeof9nINtmxJlOETrqDdI7i+kKW /IEh9LBvFvMvtmlCWiNqK0bq2SMo8Sniy0LJZkoJMyOcXisE0Tra2vCS4wbBelOq2zW5dmz3 30GpXuUggsn5Z3IyUcV3wmSS46C8VhU3+huA2pTLMlyOPc3g0lannScYe9zfIIS7JW0fizJn kdGx+QZVBiTCcU5DhrbXUS4a3HG4BmpUFyvt0gwdtkGE2mqPbZAOKRse3yCNiKlpr2t8jVan El7bIHtsgHbHzDbZJQdseSZWt5RzYpvJ9tkCDBNk5DCX0LtjxD26SPbJBhq2pSRWx8hGZ8Fu dGU+g7W8oitj6S9ukD26SDhSTT7dJHt0ke2PmIkMmBM8jo2PyNtCG6QNuo8EwlBJ/ZJnkdGx +R+1zPI6Nj8j9rmeR0W33Gy9Y+PWPhE59KmXPER+zzPI/dP/2gAIAQEAAQUAyPI7zDvPEccR xxHHEcQ81uNwF7kS8ktLDCIrP6YiqZlToEVQoiSfW6jjOsvy2BmMTM8xmZq1qLnB4RPzHOoq k3a63FsN3++st/I8hHyPIR8jyEfI8hHyPIR8jyEfI8hHyPIR8jyEfI8hHyPIR8jyEfI8hHyP IR8jyEfI8hHyPIR8jyEfI8hHyPIR8jyEfI8hHyPIR8jyEfI8hHyPIR8jyEfI8hHyPIR8jyEf I8hHyPIR8jyEfI8hHyPIR8jyEfI8hHyPIR8jyEfI8hHyPIRqO25luG6jjUD8mWb8mN/hu7/+ vBaYdEmBEXGPUfMiPiRmQ4kZkOJGZDiRmQ4kZkOJGZDiRmQ4kZkOJGZDiPmQfz/N4yuJGZDi RmIVqNmKT4kZkOJGZDiRmQ4j5kOJGYhGouZrVd82yO2NcSMyHEjMhxIzIcSMyHEjMhxIzIcS MyHEjMhxIzIcSMyHEjMhxIzIcSMyHEjMhxIzIcSMyHEjMhxIzIYjmWU3/Kxkf17Po70uRkFv ky8zhWq4wrmrGJTuIyoM6VeIkSdGjhfe6lO7ureayvDVJNJgjoYIjPYlZp2WRhqIzJkOSXv0 Wm35FGR/Xsj+w7IX/l7V97YlW6Z9p7E0rjGkWXZGl3Rq3Q3YWj1jeOBgNnxd3LdPrhAkKSaT Srd6Nst7tyl5Hc0SXSI1H+i02/IoyP69kf2HZC/8vavv7FGkyjRpEt+HhGP4ynEcLYzGXjWl 2B44s7ni2XTbrbY1tklOlLjKuzkpFxOQZXjG4F5iPYGTJ3K3lAdBpoQURY7aDMzMlGkwgiNR 7DOvXabfkUZH9eyP7Dshf+XtX3thEZjRnDpGDW93EsNvlzspzLNGtuLXmHmt4uVtgNEo3HFt mkW2FHUm9yLam4TmITwmyrvKTaJkGFMmxziye0YnAiLk3m6OXmd+k02/IoyP69kf2HZIy/HL IxxEw0cRMNHETDQo6qJJqBENF9Oiu69WtQbne7tofh6Zb10yZEuffLpIbXlzNzRjjWZX5hWG ZWjIosy7QbEbk+wXidk7Zux55vFEdNK3LtDcWzChSJ8zLnLfbU/pdNvyKMj+vZH9h2ajprmG 6KDdOlDBGaRYYbVyvesCSxSyYxZZGVXDTPGHLDBuFmm2e43Gcy0Uu6x5MT4LbZBWnT9FpnZF abXcpkzGLvDTbpcp5m63I/CruuOx0OM26I1Z2HydJ3rUJ3j6em35FGR/Xsj+w7NQlpTmTLbk h65Yzf7OI9nmSmzsFwSaLWhp7DdN7Ai4a9WXLb89ojp5eIF7nzpFpYu13OUq5xpk5TFnaScm 3xHEORkmWRtXe3qw+4uTnSnLjP26I88TsApQeSthMFbUm45NjJxlOtLaXToMpStSkmStjUdm LCP+eq02/IoyP69kf2HZqI2a8xxVhRZPmMe9wbJai/6CrRxLirjjM/KrRd8Z1HurScX1Gkyr jecugXVNyyq2zccg5bkT6JVwmvsqWazxVlqSi6QErZxqJNt8mZZmnsnkqJu2QpDDarnKiyHM ataXMlyfHETlXbTa7Ke4c3xS2tJMrcTwZy4ya0ezW3OydKr9LnStIMqUVu0kussoulF3Kbcd L8xkO3PDMmtDVzgw7ZE6nTb8ijI/r2R/YdmdqJOYuOoCDW4cC1Xx8jsV6SgmIbTjCf6701b4 91es8aCdoyZMi73iy2eLi1uxm8NtS4M5pJQrmyrFzkGUmQ0qO1MVGKU66drmyaKbSSiKMa28 EZSvObrEioeykrBGt+CsMO3duVCh3WwWiw3fHNT7ZGjR4aZLceZKmemh3BmHbro7b2r7j1zt 7buY3VEa1wLdcr9cclwvIsTV1Gm35FGR/Xsj+w7NRCUWW4Oyw9kmXzWpUCFJkvRSIqNJcduW NWXJLHesqjvxb8b7brjRWyVdHn5jLcdgm4t5s9paW8aVi0TJkK3x5EuQiQ2iOL9LbjRHpipE u2sNzX5KUxVYSaWMyzLJ1Eu55Xe1PN5Tf2Vs5pkjL9p1vy22qn68T7nHLPJT8uHfpEq3E2i+ SpLd4jQ2JzUBd0z+73CGlSknIvF3lxuo02/IoyP69kf2HZqGpacutV3nWWffcqu2RON3WYyj 3e4ApkjfjZ1kkc5D91fbTkN0K32di2WxV9vcPJMLtpqVHfOjDhpJFkiuS4R1jNyiNcm/Rn3b siIkjjtOthLSUoYujNqZyHInJalKNRmRltIMsxkN4t/9mBjtsiv2JuVCdsjsGz3dGV4dIsL/ AFWm35FGR/Xsj+w7NQlmjLzNQM6DsH/PaLFjN6yORaMZuMGyu49OSGN61s5PbbZKszNhmxGn YtwWEWyYkQjmsm4ZrMy/+hkM+LbGU5EhalZFGS38lljEL5aMgXkVhn2C4hS1L2qJJE0W85Z4 8aPituy6PEewbLX8iny4T7OpeRKsc25360O2W4dTpt+RRkf17I/sOzUdVMx3wZ12WezXS/To uk1pxG34bbLpc4qrBcoiZDJxjnX5tspd5ISphvHJeX4jClIgsKNMdlk3npkhmHIvt7lXyZsM uyoxjJ7RkFjvtinY/N6CTMjxS8uS7Z4lqjXbDsqsqcg1Gxq9M6uZ/YkScyy6wOQ4HU6bfkUZ H9eyP7Ds1FVu5iEpNSsZ07lXCRjtrgYnbbbktufN3JWDcXfIjhXW6plMTnXm3lOdsmfFjNO3 eMRN3lLzrW+o4VPU55dCVI2EtRJ2EdBb8mtuVpv9imY9ctjDDshxu2WiyOPZTcnHLDeF5HOg +vbvJTEOP3+7te+xlMSbOfU6bfkUZH9eyP7Ds1I+5Ek1HhGGr9Qy1FhuyXm5702/pjIVf5iT tV2bjzHZKVFf0UeW4QmxXnHZTDfpbTD8RxszJMme1bGJD782R07FeId6i3/H7hj0sNXiTGgm ddmDPpaRhNtLILO3i0G7K1Gs9wsC7Xl0iA0Z121Ld6Om35FGR/Xsj+w7NRyrmWM2FUdVnu3t rz+TWxxy45O84lyY6+qSvxGbaqEwUOemVHuaSfjuroVyNRlBiSCfZYS0m43WNa2rjcpVyf7Q ZqUVDFDFDFNpVIXHJ510s1NtDFsuL9qnLzRdwsEfJJNuRkd4euBXNs5JqSaTp0KGKGKbNNvy KMj+vZH9h2XGxPXrUg8liIaUq1yWtF7NpDi/L3zP4zpavTEnBy6WHSODoxftD9MdbMCu0rlT 0mvjMzBXnclvGi2NNL0I0R1nx/VnJ+WfSbUCDa9CNesTms3BdyLEtBOXDRzTLMuVnULVLC9M 9DMGx3BrlpFqVbvg+MkWAaMaX5pP1GsnKfpJpVzoaSYfp/lPJjpThObXfSDJ+UPXXOtRMXcw 3OMYxDQfQrl91i5YNJs4zVy5cmOMZAyWmrzeRZLy9Ymzm+kOls/CNWcy5adCMiPNdLHmrpmW j8KFP005cuYvTG/2vlb0fn83mA43ptriNArBojinLbj2oGgWWQ/dtJaXTNuU6LK5ouXyw6TO abfkUZH9eyP7DsuJSjyHKL/b7jiszHIDV0jINnkZwzWLQHM9DSickNdRtWtA8b0K5MoiP8bO X/MT0+0hl83Ov84uVHmR1NzrVTkKtEe163eM21/st1NzmDLyPJOUZVx5wsNveO6ha46yXWHl XPFmy1HoPoRq1gWTctvoMPIZZp3JvmknK/PLWzQSUy5q5yJ6V4zcMZ5NuZrEtM8J085sNJ3s i5sMvxy2auc5OlOrEzUXV3R7NLloZycPc4XMU+5yi6+5/rRf+VSOUjQXU6Raov8AsH1Ix7/Y I9nOh9p517RqFy3WZiJlXNWZL1s5+u3mTFor/gFkmsmoWj3Jt/mtzJkNN9Wcs5juW/Ipx3j/ AF96bfkUZH9eyP7Dsvl9kWXPGcVx3I7azjkmLHgs+m5Do2qq+XzlULn41IIZLqmWvXKbyd5V arXy4aTy8a0ylq5VtCku6dN8sPLFeOQG+3aDfXX1Sv8AZFymZxapWbv8ynMHh2Oc22S2zSrC 8tWlPNZmtE6B6Bat4kxy1Hqbm5nf4OqmsmJ8vOoU/RXXRi66c6A8zWL5ppvn2v3LlmjutF00 65mOXy36Y2K/XDSnlZ5AXIN/yHSHKdOmdM1csHL+4rTqby08qVr5e7dPwDlc5ldOndX+cm+W /k7wi8Y9gXLPzBDRXUt/U3lw5up8THtUNe9K9CdddST5S9FCLXDQVvQnkas/A3WrlfTyvaCr FwyTQ7l00N1Nsj+nXIzpt+RRkf17I/sOzUYzTmduziS1GZyj0uIaO81FmwPT7mB5hrZrLYUx EqGgXMNaNI8S1Q5kYucYyxziMTbHN5wdAVqb5tNA4i9TudDPNSJ5/wCwPDk3tjMZ0HOG/wDY Bh0i9ZdmV1zLL7Jz+4rDPTjnJg4sr/Kjl1r/AJTcum9Z+dXSfEUXGcqdc7Vzo4ddsKuvOnhl rwfQbWS66G6iz+bjQC5z+ZPmQma9zsYya84he1c9VnzGN/lRy6hvm60Nth6z802d60XuD/sB xJi55hkTmW5RodqnJ0a1JvPPXhJ2mVzq6bZNYlc0/LopJ80XLiYv3+xzDcnwkuafl0Iv8qOX UROcnR/HHdadcc510yfTb8ijI/r2R/YdmpH3IEdAl51JIuc5Aavs9s4+VvsiJqFBjNXi/wBw vb37Hpt+RRkf17I/sOzUj7l0qH1JJUrrCIz/AEGm35FGR/Xsj+w7NSPuXSJSiLqCMy6wlKIu v02/IoyP69kbVuPIfCtY8K1g2LUY9PaR6e0i62WyXe3GVD/Z9OnG2dQfkePC/wB/sT1iyi/2 JnJfkePD5Hjw+R48PkePD5Hjw+R48OI44jjiOOI44jjiOOI44jjiOOI44jjiOOI44jjiOOI4 4jjiOOI44jjiOOI44jjiOOI44jjiOOI44jjiOOI44jjiOOI44jjiOOI44jjiOOI44jjiOL3q PI9m/9oACAECAgY/AMpkR7sDJrv2onT3IWP7tY9A0/Ao6B8UdfxQ0/A9JFFcrlcrlcrlcrlc rlcrlcrlcrlcrlcrlYFcrlcrlcrlcrlcrlcrlcrlcrlcrkBTJdEZ8g6fdA09UdPWV9sGnqjp ya9GZNb7gGnqjpyKdMzKTiVg/d15bPX2oacqpVoVoVoRPT4Q5WcqQ5HnuJsHbqQjMkyiKk3l P0WBPkY7/ahpytXUt9mA2ylwA71b0u2RT2sacrV1Jl+8X6SnyKp/ahpytWWSb0eoZaOimXYf YhpytWRTrHKplUtReiLZDp0S3QCeinUjTlasqmTRWdD5BboDdNuSyboPQ/VjTlassIgHKYIk 5VOqom6wacrV7K46lzeqJx1g05WrJaLDSrQT2ZT5D5TjqXRAzIABgOrGnK1ewNluOpPWDTla uvfqXGXXrRpytXXV9iqvCH0J8J2FMepGnK1dMJAADDKUizmhZgjI4SQYkEBiYyD16IziAHxG RIctHMj9VsLRkCAxY1al92ZDlwhGJZ2w4pC/xSLAHWrtkeKJLSAzREu4FRlOMc8TEMC1sZA2 EKMb5OQIwBYOQLT2L6fMHhNC8RGUTLyyFzE9qPKl5nZfSgA0WjSOKU5s52XowZpgGQEoAAgV NQTcgYRjESBlIs5aIc0Q5hkIg2YogE6qnXYvzYfL+pDBOEi4GHDa65gnhhGDWRB81+gXqPNw gSBMZNQPcddqPNABnKQjF7O06hVExAkBU4oCIlF64T3qUIBo2jQaqPKDRAwglhIynO7Ve6nL /IiCISYYQz3d5R5YjASiziMMWH1TLB1aNkeKxTYgWnBGQGli47VGTRBDSBiDhnEGtLjn2KIp 4ycIjEGgLXkKp/ljudWktmjEnU0kI8wCQJYSAwyErcMh2i9YIGMQZGMBhB8oFp7ezSuXzAAD KNWsfP0QIAAwmUi2I0P60JxBY2PCIfRVf6YcU/MwsbDKAMX7TElkedy44GLSi7gE2GJzFDTl alZRGq/ty/EEBSQwxEokStjRwQCGK/Kh/PwRjQDCRGIErZWkmQXLj+9CA71MmsTLmSIz4KAH svXh5cANDqbxEZwjiiY0ZlzMNMPMB0Yo13bkA7Pyoj5pqX+NIuG8JOZ6j7smOhf/AGSPihHC Rf8AUHhH6EFRhEtOQIf92/mS1nwKMHfD9YasAKb/AK5/hCjzoREomAjUsQY0Nr0K/Kj80eCH LMREzBYgxNmpA8wuQTy5nsl5TqkzKXLl5pRI/uco4TrMWXLhKyEDKWmefU6kOe+HmgmPYLGH 3cy5HNkKQBE/7ZQmKmsv7nMOGFP4YDF2IcqNnLnGOseI96+pIYgIy5hFxmZMCc7AUVOXyx91 SmYiM4GJeNHBLEHsa5CMbI8zmQ1UlTv4qIFv0+Y2fzFD6Q5YjhHmiXftopCQgS3hwA4sVyIk GM5xOlo+I7VyaN/uTpqGZcn0/HoH/qP4oqXPwiUox5YDh6EBflQ2LHhEXMoSApEjC4cdhqpk /wDFHukR8ENOVq6KBf25fiCHMOIiMYAAHCHkHL6V+WfnPBHmB2lCXhJesWIIdQmA+HlwOwui KMSTF6RnCdoxWODn0Jxy5h/4o8UQBgEgxlIgnDmiIu5NykACPqTxMbRCIYE6bAgP+uHdzFzY DzcqZkO2J8wQwwOM1iX8BDU5hGeIqbnCEo+bnSAj2csHuMrdaF4P1S/3AAg//HP8IUZ4PqDB EBiGBHmBF2eyqryNx+I7e7PQNyzAyLYmF+sqf+LM0m8ddxQIYTJxB6A8yPg5kXuMo4SFzASP qTIiWrhegi/ZF3tqiRZyuYI/dIw6qrmQEojlzPiL+KP70WtJN2fQjzphsIxkfxSDcuOkQ3qc jUxnGUtFhK+hMAkAxYnCJwkcUZRlY4zLyT+aHFYQMESQZORKUsJfDERe3YEDKknlzJDNiYRB zONa5cpOBGM5UoaSNHuL7E05QjK1jKRIfXuRacZRDYjAyEovfUl9Cxl3B+nKttPDKOkWxsXK mT4fqzrsUPqwliiG8JixD6V5OZtjxXM5PLiQOXyyC9ruF9MjFCUYViQCDEM3iIzLyT+aHFCE YswLRfFOUpBhSLsL9y5kT9mEYH1PiI1OxQ05WrphGeKMoOHDEEHO6MIYiZEEmTXXBuiEJ4gY EsYtYbXdE8oyMy1ZAMwuDIkiUCbosYvoNi80/lirZjRGA+CB5cSxIxEl5SGZYcXMwu7Uzuz2 s9WR/wAiIoS7dhtCwg8wRzMLLcIlaAcyHOuBDDMBYFIPzBGVTEM3a2YIGQnExPhIY0sqDSxU lMfdivPP5YoYpcwgEFmjdnR5ooTJ0ZHFEyYyDRMcWcPYsQxmUXwhogYjeWUxzgTHmCrWva6t npwxfavpcrExOKRl5ieCE4axnGZWTh2UlEaBKxWy+WCtmNAiPggOVFoggly8paSiH5mElyKX 1Ie1lLmAMDYpDmAmE4kFrVGT8yWGxwBc1WtzIyBmMRchokPnDqkp/LFeafyxR5glzMRd6RL6 VbL5YKhn8sEfFzNQjF9Yqhy4RwcuNgznOc5Q05Wr3YNOVq92DTlavdg05VQrArArER7oGn3r /9oACAEDAgY/AMoSFoqoyNpAO0e7JGbsA9LbQL9KxF8RJAzUw27TeuXAO5wvZ9oA0p2m17lI nFhABtD2gG5ry1j9nu0TjaOjmen+qKj6pborl/290VzPT/VHorYozeQcA2i/UrZbRwVsto4K 2W0cFbLaOCtltHBWy2jgrZbRwVsto4K2W0cFbLaOCtltHBWy2jgrZbRwVsto4K2W0cFbLaOC tltHBWy2jgrZbRwVsto4K2W0cFbLaOCtltHBWy2jgrZbRwVsto4K2W0cFbLaOCtltHBWy2jg rZbRwVsto4K2W0cFbLaOCtltHBWy2jgrZbRwVsto4K2W0cFKQMnAJuuGjILAF2t7CD8NiwMG rpq3/j3lRkweLdwAD/L3lOAKgBmpQg9+GuevTD0jd7on6Tu6qHpG7qHAJCci3R7fP0nd1UPS N2S0ajPd+vUmtKrsUpy8LXZ/cE/Sd3VQ9I3ZXagQmJfKf2qfpO7KeMSR2AleSWwryS2FeSWw qMTaAB3dPiLD9O8p7FWxR5olEiVwtGnorYnMpAZ8KIBftyMPtU/Sd2UfUdw6oQ+mAwZx04TI tkV9rn6Tuyj6juHUxjEWWnOekMLAiGGQ6b2qfpO7KPqO4ZTUAJFVDlwIIAZxpXLiAGD1Btf3 JP0ndlS9R3D2cggMTrQw1qhKTA9mQyAN6tTKnVz9J3ZR9R3DKtyadIizugwALmzs6HQybFYq ZDpkBSuv9ia/rJ+k7so+o7hlm/MgTHKEjRARLs/f19FVUfrJ+k7so+o7hlV9oogXBxBMDVO1 Orn6Tuyj6juGTenYjT1TKnWgg1Ir2IG9Om6ufpO7KPqO4dW4ycR68IMbLOsn6Tuyj6juHXt7 BToA6ufpO7KPqO4ddRU9hp1k/Sd2UfUdw6TAE3AVa56rASSGLvWoPRgBIoGq1TnTAkmoYmj/ AKFY5TpndhqCrPvPBMJ19RCIcnTaHsIN4RliYDPJkJ4nzMXBA8w0rELGdGQkRfa0RH9axmbx dnEiVGJkXoBVqkm3YsJnUdp4Lz95VZGw2E0bO6jhkXL2lrFKBJN4e1jwNFGAJAZy1uYbTRPK R1Eljc6jM2tVSMZG9qsBEX6zYgIEnELy7H9VqxymQDeThfREftX5neeCaHMrmxEbwjCRJ0s4 LUreEZCRDWklqr8wbTwTfUHzHgvESew1DZwezMjMk0Dyq1r2aEQS7EiuboMATcAHYa9iwy5g f1HgvzO88E8JuRcJV2FfTnUs4Nj53GcXqfpO7KPqO4IVqhRnWsbijKNCSWLiw3MV5/w8UJyL kFyXF1gYKZzE/hChAULRA7MVp00VTLagYksSxBq7rlvfE9zfptT2tM9wTkMTX7zW/ejTSF9A Xmh/gNX1BAM9hIz/ALkf6iFzJWPgOtyDuUNMfijGR+0T2F9doVvceKxUkAQ4qLVijYWkNMbd sUJXP/LOv4nUpC4t8v8AqITQtFJdptB+YLmC96fesRf7VPux82001qJNswTtYAbCvp2WR+6z ltN6tltKjhJYvbWoDgjtQJvjE954qR/ii/cv93GZPVjTUhgxCtcRo19qiLxE95GEbFzfSPip eo9GsbijyySA8jQtV1bLaVERLihD2irW9oQHae8AqfpO7KPqO4IjOiSbG1rWNxRgSHc1Z7KB ef8AlCEHsIqzWg0Uo55EdwUZxtAAOeJj2b9qYgPolwQcWWAAgPnJLUUavgi2stTVboRP8cu+ K5fNFhiAdP2TtR5hIw3hqvfEdhN2pSnKyDv6jb8oop/d3lR0x+KIs8RJoai6ralae/gnkHAq xObUHQ5kbQ0h+mhBnIjSluE+KJa9kCXbttLVMmueTKBvlF9Y8SBAJIsDeE3gk2Br9Cjyomlm oVkdctyg2YgabRuQ5/Lq7GgdpAMxGYjYQmMRslwQxiyyhAD3kncFhjUACOyp2UU2YvIDsqBV PCDg3iID7UDKDPY4i3cAxQIqD4x3ODtoVzIgVwj4qUYsQS9RIHcvKP5uChzZkeKVGzMUeYBV zaCQQau4BVYjZLgsUwwpcQABW+0lCQ7TqbD3sp+k7so+o7h0mcCGLWvQjMyxTIoGDb+gziRU C3szL/cZmNj33leGQOl32i1WjaV5htlxREpOWLMGAdWxsa/Q7WOy+kczK2Omu1rHX0xmrrvV DEtZbqfOhhkDSr5+wheYbZK0bSmJj3nYhHMGTQkGFloLZqJpSDUe0ls1UMJYxLhUIGuSMps7 MGsARhKxeGQO0HW1q8w2yVZDbI/FHEXJDZgB2BWxpp1FrHQg7smiWIII1IxJiAdPdmTAhhR6 gt2svMNslaNpQj4WFlq8w2yXmG2SqR3nudEu8jaeGYKfpO7KPqO4Zdqp7kn6Tuyj6juHuyfp O7KPqO4e7J+k7spoyIHYSF55bSvPLaUDjJbOS29RnY4B2+6J+k7vev8A/9oACAEBAQY/ANe/ 6+vbW0tb26/6VIkccaSN/fAKqgeIDH28+tPncfbz60+dx9vPrT53H28+tPncSeYbtuL7qadb 5vfvLy81ac3JIaVoaYv9C12+u9V0jU4jDfWFxcStHIhzzHNkQQCCMwQCKEYhtYyWjtkWJC2Z IQcorSmeX9HArSvSfwiAwYD9YVp+en47fn/an/K40HRdJ16ezTcu9YtBllleeZLe3uHnJaKK OeDyl6sco5qY1fQRuK5h0zR9swa21ZLh55pptQ8y6sSecKqKFPN7xiSKZVqN8bsl1+V59A1T cVhpVir3KoE0WNGiedzcsZDIX8oKEpTLjl2XWMe6ZDeb61LQ7PUr5hdGKGPVrPzqQxQC8BrG SFHNJnSppWg3FDqGp3d/FbNoj20VxM8qxtINVDlA5IBYItSONB3u5HDDrV/FFEoSKJLmVVVV FAAA1AAOAx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0 qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6 +1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lT fCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2 o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4 WPX2o+lTfCx6+1H0qb4WPX2o+lTfCx6+1H0qb4WNd0rcN3dapZpay3UEc88j9VcQRs0UqczG jKfyioNVJB35/wBqf8rjs8//AGhZ/wDnXWN4/cCx/wBeLjtO+8W+/iYcezz9O7O/1QMboW4m vYUH8hIexkgikr/1xkTcW9yvL4AoNaZ8QbhbPVdegu2jcWs81xp0saSEHkZ410yMuoNCVDqS MuYccEfzYZGn/N4Pk8eth6PB8nj1sPR4Pk8eth6PB8nj1sPR4Pk8eth6PB8nj1sPR4Pk8eth 6PB8nj1sPR4Pk8eth6PB8nj1sPR4Pk8COfUmhmoC0T2sCmhAIOcfSMeth6PB8nj1sPR4Pk8U /m6t4RbwfJ49bD0eD5PHrYejwfJ49bD0eD5PHrYejwfJ49bD0eD5PAVdV5mY0VRbQEkngAOr xb241mR9T5AbwdTamIMcyFAhBy4ceNceth6PB8nj1sPR4Pk8eth6PB8nj1sPR4Pk8eth6PB8 nj1sPR4Pk8eth6PB8nj1sPR4Pk8eth6PB8nj1sPR4Pk8eth6PB8nj1sPR4Pk8eth6PB8nj1s PR4Pk8eth6PB8nj1sPR4Pk8eth6PB8nj1sPR4Pk8bY0K81l47TWtWsrC6khgthIsdzOkTlC0 TAMAxpUEV6O5r30ddfEtjelpbp1lxdSalFBHUDmdzIqipIAqT04tNfXQo9Vi25uOTXNFrquk pbzzR9ekEkinUIpSg63nCnlNQAwpzKda1hNtrLqOt6VbaPLcSato56m2trprykKrqQUNJIRz Fg2SgLy1bm1XakW3mi03Vr7WZtU1CPV9FNw91rCxvcgu2otGpjjaMIoQUXlLBixY7T1d9oQI my7uxvNE0pNX0rzYSadaGzthJXVTK4RSHNZPKYDmqtVOvXF/bR2Xnsmkx2kHnllcyP5sNSMr ctncT8qr16CrUzPcbxn8U1a89RTvUzriNZIov55tsdXDOv72aACvK4pn5PDwjBByI6O5wr3K Dx/k7hpxIIPiOXcm1q7RikNVsF4BpRxetR7zo8OHmkJLOek1oOgZ/wBD2D949K/i4u5r30dd fEtjXvpG6+Obu3/3iu/9WaT+A3jPdBoGANSp4HBPDwd3MV8GIbp7JtI02WjLeXg6tnQ9MUTU ZvAch4cTec6zdTRRtyqiRxROcv753/MDhmlu9QMZUhayRqQ3QcojWnewJ7Oa6dp4jFNK0isj GtfKQoBUdGLm90ZBqOluecQw5zRVzIaLiRXgVrgqwKspoQciCO+McAciM/CKfgx2sXk82csp 4IgzZj4hiHT7QCPT9NXqbeNQB73pagFTXMk9OAACSegf0PYP3j0r+Li7mvfR118S2Ne+kbr4 5u7f/eK7/wBWaT+A3jPdXlFCB5R75xDbWsL3FxO4jggjUs7sxoAqjMk4S97R7+aOZlJt9oaW Ve/kYjyRNIapED0jNvFiWTb2yootNklCIdTuLqWSNVrVgyNEjAVzy497Ed+NGstU1e1jdbhr eRpFgdBzFurklflY0oCBl+fBhsNCuophOwS6keQheWvlMJCwNCM6HCy2t20p5aNaE1VGp0Ze 7mcSwo/LcBSYmNM6dGBaseecqCSBk61pXwFTkRhkDNFdQnyWrQjvEEYhn1KGFruWirfW9I7j mPAd6TxEVwH/AJughz5ueBwwAOWXA+HPAVJvOIW95OFKgkcRSp4dxTUHm6OkePuAEAarq6Bp D0xQnNV8Z4n3MVJqTxrgMpKkcCMj3AGPKCc272P6+4MqUH47YP3j0r+Li7mvfR118S2Ne+kb r45u7f8A3iu/9WaT+A3jPdywN46zYi31bVYglg97GVW1tpM/12QB5fHULl0nEs/8qt9V1W5m e4ZUneVzKx5mYIt2KfkwkR0+PTNKs4+SOFbcRVDGtA3O5PfzOZxaatBpcn8lElwmobjWch7p Js1eeImlU4ZDElhocCQoWJmmUCrGuZr4cMznnJ6TjLj0HE78o84ZyZCPD0jvVxa6Y06rqc6O 8Fv0uqipB7x72LU38fWxafL5zF5RAVgMzQceH5cNc1SOGaXmMJUjIE+5XhTEM2rxQajb5pdQ yRK1C6ULKGBHMDn7hxNCaEKxMbDgyngR4CMU/NiXVtU5f5ZpI6ySNwaTTcY48vDmfAPDi61C 4djJM/7NDwCZ9PR4v6LsH7x6V/FxdzXvo66+JbGvfSN18c3dv9O1TU0tr463c3Pm3JI7CKTT tMRHPIrUDNGwFe8ceuR/kJ/k8euR/kJ/k8euR/kJ/k8MRwJNMUUFjStBnl3LjfGu2XnG29vt W3tpAOru7lM6PU/u4qhmy8o0XPPEmnx3rSWls7NLGSHQSNkQFYECgAFRn09OLPVre2ms1s7V DcvK6ks5YlqMiqVEjj3prRVYV8rDbVudMvreaWXk/mEkf7F1TMurDv4m0+N+S3hYhVU5GnTX w41C/tDLbmKPrYruPo5COYV8QOBXWpljOaySQAg+PEltcun80tP3gTISp0Oo/TiK6vLhYVY8 oi/XcdNF4nx9GBqdr5rJerEIY5sutWOtaVOfTi3tYSI7i7nWhUZmKM80n5QKYuI05hysGVWF DlQ5DxHDSMOYPJWNQMwBUA+6STjzglT1TUTlzPVnoP8AgnFtY2qdZc3cixQpwBZjQVJyA75x a7b0lg8OnqDqF0DXrrgjy2qOivDwU/o2wfvHpX8XF3Ne+jrr4lsa99I3Xxzd3Vj4Lf8Ah48Z dytMuHcyNDTjjR9NnZlg1C+t7aZkIDBJZVRiCQc6HLGmWWjzSaRt3bdsbPTra3uEKzXMgpzy QCjF4VViGc05yDSuGktWEavc22nwPIbfrAJ2oWMbCrEAElwKDpONQu7o3VtPqLhW02WaOSG2 jtwYokh6olacoqSTzE8c8T6pHuq/urawdhFZzlXVhJUFD05VpXDS3EvJ1jGhPSfHiay8+rbX ClJIOYhSG45HBRNZkjiNeWIspCjvCueLfUtP14pNA4blotGXpU58CMSTTX8tpfMPfuTJFn+q AfejxYe4t1W7gjBZri1cGijMkioIpi1nuG55LKJIk5zU+U3OWPHiCMTcjjmnIEYzyZhT8lTj lJBXJUJ41PRhYnHMK1IWoxf36EXF+Q0FjDX92GALO3jBoPBXDmWvOxJYnpPSfxwFQK9JyH4j YP3j0r+Li7mvfR118S2Ne+kbr45u7qwevKRb1oK/9HjpliOCCIyzTuEhiQVZmY0AA8JwBquj XNgWJVDcIUqRxpXI+5jrIzCADQh5UUj3K4WpgIb9ZZVYCnfpXHLfSExgeUttRpCegDnoPz42 1qSxXlzcXFzZ3FrFcSooV1dX5WCBe9wOLGwsdI1C+trSJ5ibZGukM0rVKl1C8vkqvEd/Euta hpd5D5hFVI5oBC/XSKUAUT5MFVmqe/TFzbS3Be5vSDb23Kq9TGo5SfJAFWPlHx4FmpLLE3NM wzrJwJOJYepCQGMhZWYAA+KtcQLNqNnHJACpQyAk55VrTGd9aKFzDQlObL3cM1tchxnVlIIz wL2C6kltgQJI2PNyHoPfocQxXD8yXJaGdRUAh1IoQMajEpMJiJSRa5VRiOnwjA1K7WiRrzQI 3SxyDEfoxJJDIVJFShIplnVajAkdAVAyz4nENsIm6yR0tpVYEBuZqAinGlcsSNEvL0V4YKOK EcfweRiF58lY8Aej8uCCKEGhHep3WuryMtLeIV06E1GVaNMfAKUUdJ8WD+L2D949K/i4u5r3 0ddfEtjXvpG6+Obu6tTvW9fR48aD1bIGS/hYM7BFBVg1SzEAAUxoltr9w098XvZuYyCT9lJL VCGBINaEinRhqZ1OPBhBDQSmVOqLcAwNQTXoxod/d9bLaQa3DMtuxdeYqxag6Apxqd1rFmTe ahePOY0egRAAqIoPeUY1271qxnhhmmQWcCtXlhjBC+6a1OLjzeGeEWlvLPdzPQnqYlqwB6K4 u9f2219pd4l2lpKkkxlQ8wL1o+QqFOJHl1SRzWi1VOH/AIuJeuuXkqhrWn9zCdazOgZeYVzK k5gYm8xLQ2pclInNCADnxxJBN5SXEbK1DU0OWJlljYCGQcrjhkeNfCMap1sDebh2u7ievk0l RXVWr/fVywxVeZJZY0AXOiqCwp+bBaaT9kK9YB74Ke8MBEnURIWMYYBTQBRnnnSnHGhQQkmS 7vYJGZ2rwfnNPcBxMEWhLHmcgLx8eOsjkiHMaKvMoJrn38NDbxeezDMrCyNQeHPLPv4UyGyt JGz83mmbnA6CeRGGfjwOWbTnJ4KJ3r+eMYjvi2mg2sgfy5mZaqfeuOrOR4EHF2bB7CKMyVW2 MshKc4Dcg5YzUAmg8GI+Y2S3Uat51+0lIPJQBv3VQaHMeCvThlm1G3inE7W4iiVpF51UsQXP KAT3sHzqSA2kYdxEXKSydWachyKpzHImpoPDiS5kFjIaUjhhlIVVUeQiAoAAAKDElxf6NcRW sZAe6VeeIE8PLWo8HjxbWrl5NakPW3qgjq7dCByR5V5nNat3uH4rYP3j0r+Li7mvfR118S2N e+kbr45u7qxbh+wH/wAvHjICnAk8MKil2JFIkSre4FH6ML5tpV3J1rFVkCFVNP75uUD3cI08 cdsGLAK91EG8njkHJxIt4HvS4osNvKySK1f7RRg1e9jR47vm8xkaFXVipbkoB0Z1A6aYMNiQ 9ozAo6ufes1ACSBQjGnG3u+va6tjJcoGVxGeb3tVONQjmtB/JJIZ7G5kjIMrhwVYctRl4cPo W12luJJtQW9u/OQImoiuqAcxplzd/DK1uvMWrQSocvcbEsRsbh2AK1jQuK0761wkq6ZcM0TK 6o8LcpKngcNNcr5u7SEvHy8KHhTE4d6yORyDqwBQeHoxIIlQzFgVdhzUU8cuHHpxPLPIXlkj JZ24njTFvaCQUhjDOK0q7jOn6MVdQzAcCAcTOpjEcCSGaJog5IplR/1cbbUVHWXsYYlenqyM gOIxL53zGOMgzxqRzFa58Kge7jUPM7a7j1B7ZzpszNVQ5SpU9JNMhTFxPqQu57SO1DzwQNyF ipAopFTxNTXF4ernNkFra285DT0ZTmA1AxXFxf3ekP1kF4XjNkoS55DQKnMCKjyiSK0xHFpk EmmtBZtPS3VFinLSKpWStCSlK5V44kSG/NykIVnWRjGVLEFacpDCleJxNdswknt3A5YJn6ws 3fZmp36g4OnJCrX8l951JJMzrCXeSpMRArIyoBVVrn042vYxQSMdy2V8i0jhFtJMFPI7sV64 MrcSp7wYUwPPEklSRH6tUpMykHNkqKMBxp0cMaqmlecRJDbm5Mc7Bo0aPlaNloCR5daA0/Nm tnYwPfajds7CMEBnIBdjViBwFeOLQa1p7QJewJPBcRsJYiH/AFDIhKhwRQrWo/E7B+8elfxc Xc176OuviWxr30jdfHN3dXYEgfsBlw/5vHizlvIRcw2MVzeC2dQ6TPawSTJEynIhmUA425qt nYW+jSarYG5uLWzjESrKJZIyw5QDRggI72EM1xLNQnlMjs1PFU44YRYZEhmaT9lM/vQ2dK42 1fXrPPbLfc88bPzRoeUheZhUhSSMGW6tzE0jq7GMl1GdSVJAFDWtMac9vb+a27WvIJG5f2zR k8xHLlWmL6fTrKcZlfPi37EsCahR38sPDZdTfX0jEFWkjRQB0Ek5YSS+mtbKYr+0qS6Bv8I8 o/Jie6h16SeZmLuLUyAE+CtV/Pj9nc3YBIBeWYnI98UxcPbyMWjzWfic2454mSaeWeORLd16 ylVMlSeAHexy1J6weUTmRnliK0JrJOF8kDoFK1xcysAVZqAcclyH6MRwVdA/FUr7mVcXUQt7 mORRLHBBG9YmQkxq8grQkg1xo1wzmI2JMysB+tHExAPgNcXEkdwVdq+8JAIwypqEnKD0hDw4 ZkE46yHVJYZKU54+VDQ9FVAwtyNTeS5SoS5kAZwpFCoY5gHvYYyR212GXlrR4jwpn1bAN7ox Kl5oonupowj3DXAIqCCaAxVAJA4HAmunmt5nPLI0RUIik1AAFMgc88SGUAieVOuZAKK8Y5lY gdEq5g8K1HHFl51GyR6PGLSCCMrySq0nWc3k5gDKtCCW6aY8wMTQosMsVpHLLTzd5RySyRPL 5ThjQ1AUfq1bB1e+84ttI0WIwTwnmcTSsDyRpzqnLWo4A+PF3psUFraWN3zCYJEGldScg0jV OQyFKZYDKSpGYINMR2dzqd1c2cFTFaSTO0a+EITSvhp+J2D949K/i4u5r30ddfEtjXvpG6+O bu6uF97/AO719Hjxb6np0ghvbVi0LlFdcwVYMrAgggkEEYhl1FoOeBOrj6iFIVCVLABEAUAV 6BgRpIqqOHkDApdN4qL/AHMCUyEyA15qDj4qUwim/wCvjVgWWVFao/s1ABp4sSM7edWjRrPp xaRj75akFWrTLvYhjmgl6uGRQ0AQFoieDAgVpQ543Dqdv19wmj6c+oTaVKv7ABmC0ToNWbPC bhttGs9HvRqK2VwbaNI+cCNnqKZ+OmCXYseY0LEn9OJf8H+rB5xVBQuPAOODFDypFMVosjcg KggkV8OJ5CIOtZolgt4n5wqQxkCrGnjxCCOYUSq0rXOuWGlPMttDbhubwr0U4ZmmH51ZHFKm vgrwHjxVZyopTmXJs/CMKFHvxnXOpxLdch667FIpDx6tRTI8MyKmmORXLccycEsak9OM/wAA TXU3MrV5LaEgyNT+0TUIPGK+DD2t/GtpYAotmIvJ5KHKrNzFjXOpOJUjiaS6ectHOrcrDqgI 25sqEDlypl4MLeTWs088IqCJerog8ksWYMAorxPerjqtUt4rm0uU6oksHQNx8h1qKggUYZ4u J7Vxd6WsnKk4ILJU5Bx+TP8AF7B+8elfxcXc176OuviWxr30jdfHN3dYoaEiAe4beOuKnLuV rljLuCDSrGS4ANJbkjlhjHfeQ5D9OLXTbu8gu5beNOWSNWUqVFOUFuIp04PKpYHLKhGeffxJ 57Zvc2t1G9vqNuQwVo2NKioPDGm6Rtq0fT7O3uJbiXrhzsXlAHMeUdFMBAQylyOcgrkOmmdM FRCOrORDdIxUpbAceVog36cKrSRGFagRpEqjvZUwpblOfBq0B8Cjie8MW1eNFGfgBxc3FyFb 9kFhg4GSRjUAeLicM1xaVZyWZ0bp8RwOphkMh/ValAPGDnjJmA4cuVKYfa265vNrK7jZNG1K vK1tcsfIBatKV4Vy6DxxJZ3sZpU+b3QB5JlU050Pj4jo7gLGtBQeId1SrVY++FOGEBFRUVGF lKF6uOYCnMByMeYeEccW+l22gGKwseuRNVMolnJZW5pY4F8tjJXvdOL+z0/RrrS3tFiEU12x iVmMoKpIgAbygjEqMjwJzxQ7ksbvQZ5eaXaF+yvJCeDCK1jDpWoKjhTpqcbj0GSZIHglla5t Z1MciQGrHLh7xgagmmJrNnE8Pv7S5U1WWI+9YEZeA+H8VsH7x6V/FxdzXvo66+JbGvfSN18c 3d1bxW/8PH+BDpuj2MuoXs5pHBCtTmaVJ4KB0k5Yj1bf8lxqN5O6rZbc0mrjmOdJ5qUFOmhp 4TiSO322NsaJbimmiVipkB48sXIp/wAY8ccrsLs1P7TmUnxUFMF50e34FmJKig6PFgrCcuBc 9I8XewwHKB0AAYOXE0yxIsl40bLJRYEWp5eg18OBK9WdVLUbic8q4s6AVlajA9FanEcYbq6n NqVNAM6d7x4W6nPJBZxmWRumgU5eM9GGuriiItVt4VFAiV/Oe+e7WvudyTZW8ve5vt/XD+8g npRUdj0HgCcjwPQcNZ3qe+HPb3C+8ljrk6n9I6PwQRxHDEtkOMClnLAsualRWnDjliyXTdKW 5vL6JpLrUbgusrFaU6kqrUHgHu4sLG8v3EtTFNp7MxYOhHF2A5qVGYyIxpeoW+lXV1pLvbyx ajb25eEF5DNySiLLlDVBJpXE1ybOK+1VbO3e7vAHSITmLlkBUPShP6prlka4e5msI7aaGVRG 9q7NC0b83MeQ15KGnA0/FbB+8elfxcXc176OuviWxr30jdfHN3dXyBqsAz8NvHmO4FUEsTRV GZJPQBiE6ssscUlGSwtyDO445nMIMJHYiPR7Y0EscIErOw6ZZODHxk46gl5XZqRTgIB7q4eN jItDTrKVB/Jh+rmWV4z5R6Vr4MTWxHOkqkEn835MSxSMeaNiKYBbMVzGImLdYqVLU99k1RXx YNwoBdjTm/qxHEoqJTQV7+FNBkagYj8Rr+TCabC3vVV7unf4qp/LU90qD5LEEjwitP0/gNt7 cVtDp0M7gaJdwcwW0YgKqVdmbl8JJ7xxc6ZeBWaB2WO4TNJVBoGU/wC+ndWGCN5pXNEjRSzH xAZ4STccpvbhebm0CykHOGA8kTziqoK8QtW8WLFYersbHTXDWum2q9XEPKqebizk8CzEnBvP NDAtmzRrbJITlOSQFOVaAUo2Rxb2dwbKZLGJljeNJEmjVFBjBDDlNBQNymlRjTok1OZTq0Sx 648N1yNyR0FHAPKpXPF3fapq2o2z3VWS+t5ZFLoiBDzlQQSBSlRi6N+jLp0ltIranJyluQs5 aTmVXct72galTgfidg/ePSv4uLua99HXXxLY176Ruvjm7ureK3+IjwABUk0AGZOLae5jD6lM R5vAw8mAH9Zv76n5MDSrd+qhjo2qXzGjTEcVr0KO8MMbceeCAUQEmO1gQdJPTh0tp1rylJL1 VCZHisC08keHicFIbh1iJIJLZke7gGScdXP5Lmtc+jHMpqDwwtyMutFHPhGDXEsTN5DPzpJw 8YwEjfmlifmkA7xyJwJjUBWqtR3sAAU6DiW9koREjdWh/XenkqO/U4nuZiZJpmaSVvCTUn8R HtzcJDRly9hqbH9pE3LQLzfk4+LAt76IhJlElrOB5MkbcGB/SO55japHac7Mbi8iXlnlDZcj SVqFA6BQd/u6qoHPMqLMsVaFggNcRNcW4s4eWSa8ubhgY4lY5FGFDRugYvpB5oIbdurt5/OF PX8wzqlKoQf1Tjzm0eYiW2YQyRsGAIIFAq1BoOPgxNb3luL+J4TDFRljZQSWKsSjhlYnyhSv hH4FKHmrx6KfhbB+8elfxcXc176OuviWxr30jdfHN3dWHSRb0/yEeItSvUZJR5VtCw96CMnY Hp72EukiD8v9okDPw4M8emh52/e87lkr4sCBnXq1JKWUQ5Y17xYDj7uOeV6noHQPFhlDlK8S MFDcNcThublJJoRniFlHJVRl4cSR/rDylHhGDlQ/14hblJSpDkccxlhTMDyVIz6a9GBwU5cq jAeY9ZK/7q2U+Ue8T3h4cGa4atMo41yVB3gMePABzC8O5wxw/A8WLLSL6lwdPcG2u2zcRgEc pr4/wOGLe+gALwtUxtkrqffI1OgjI4sbaBTZ6Jdcs0aqwKvJHk0chTgy5VU+DLF1PIUezZWu ZYmoSoSlZAta9I4A8Mea3Ae0RypVvLDRyqqtHIpYA8y1DVAzGWHle1eHUVkK3YjQ9VL/AMat MlJPEcDxGKEEHpB/B4Y4d3YP3j0r+Li7mvfR118S2Ne+kbr45u7qzItY9PS3nckVHMIY+QH3 c/cwh1/TpLTnleNL5VLI3KaFuH5aVws9nqKvGRVc60B8GRxuntb7RdlzbxuLLWYtKsdOjlEB JmrVuszNAFOWOybtR7NdqSbVst9wzST6fK3O0UkEjROvWDJgStR4MCmO0/tQ7TdoSbtTactr FaadFL1TStdSCMIWoQoHGuOyTdfY7sdtmXO99Wn0/UYJ3EhhMEnI7dZkpWmY6cHs50/Y+v8A bJu/TJjbarc6WAtt51GCkqwUV3cAgmtKYHVexhuuW3JHLcF5xmegjqsjln3sG63b7IO6tC0l xV9QLyqFIoWNZIuVcj0/3caZ2k9hiX9rY6PrFtZ752bqXK1xbCZlKuAnvo2AOY6cSdmL9gF5 u/XdNhs4+vtLvlkubmeFHKxQqhPFqDHaptPYvZpcdm/a9sbSW1ew0e9dpuuji/epUqpV0yyO WeJrW7Ekmo9cYZY2qXMgPLy08eQx2ZX/AGo9mlx2idpPaahv7PQ45zC8NmGCBzRS1ZGNFX/w Y2z2U6p7MuqbL1TdN0LGO7u7s9ZbPIpKO8LopIBGfgx7RnaDvzZD7q0ns31tNP0jRoX6nnNz O0MaiQ1IC8Tlw4Yk1jY3sRa/uPS4pDHJf21+epDjPl52ULXxHAP+wHuWnAH+ZR9AH9zGsabu /wBkbWezDSrPSbq+O7L+/jktoXgWoV14nmrlTP3K02P2kt2N3G9tH3JqMmmapJaTmAWUsZqw ZmTMsteStAaePG1d09nFt5tsLtD0e31jQYywJRJ1DchAyqteU55kVqejfW8e0yyN7sTs70O4 1bWYl9+3UrzBEPDmkJCCvS3f4W/ZdadhN5s7Ud0Q3UW2tekvPOU86RHkhWSOgycDMjhjc212 jMf8n1Ca3iQmvkKx5c+nLHZ5vjtd7PJt9b37Tb6ZdF0OKdrd47WIis7sy5ipAUKM8dk/Z/2c 7c/7jaxuHS7fXd0xzyc5sLWWMSyRSsoJqiZ1IHDFxsPY/ZFurts1zSGeC41e0oI7qWI9WzxR IjtyA/rdOWFMXsGbvZSAObrLgZtVemKvE+54sLcb+9jXdu0dMnKdXfyyOFUP/fzRABjQ0BNc bc7cOwee+1Ls51/Vo9J3bs7UCiXOnXgIIWi++fjRgACp7xrjbfZxedhWob11/UdC0/UL5oZk Aea+VZRGkJDVOXRXCFPYd3iylFMciLMQ44huYRdPg6MT3+rexHu6ysbUGS6upGuESNB+sW6k UplxxuzeHYvpWpbF3j2fCK53FtfUXSUPZzOFE0EiABhzHlIIr3sdiPZ9uzscuN0a/wBoGk6f d6rrcFz1ItmvpeqUCErVmXInG6tq7UtvM9FsnQ2tv/ZDqG/r7m7O2PtR2NLve507XINJsNMi mELPJcLzAmSh5VUKcsHUds+xduLXbFX5Dd2NzNPHzClRzRxMOjFP9hPeHCnvrrvU/wCBxDpP ab7L27ezOxv36oa0ruZI+YVJVJ40DFeYNka/mxtfePZ7uA7p7Md/2i322NY5aeS1f2bUJoyk EMpzBBxsH7x6V/FxdzXvo66+JbGvfSN18c3d15tOkNvdRXFvJc3HIz8sQt7YK1EzFGJH+NjQ 7GO5Jv7KeZL2zcEctZeYOK9DDGhdUsdok+krMX5qI5dOYPn0nppjd4IHO28LEuRQ8I3AIPeI xsXsu7XtO3NBq3Z7Pc+ZX+jW63EE9vcSNIoYB42BBcjM/wBzB8jfmX/00+H/AOI8BxuHsn7I tG3E2o7w1C3uNV1XWrdbdY47VuYKg5mJNfDjs/1eoD6JNuK6jkA8pWRZSGHRUeHHtJdtOlJG +/otXTR9B1mVVaS1Fz1k0jwkjyXcE1pxpxGBcXPaLqMEymr8shAKjoyI4Y0PYe9dfk3Zs/eY l0vWNJvlE0LxzLyljzVII6COnHtD7CtxzaNGjpDbNTkraXkiRZGuYDd+tMb1vW06C+TaWhXW qBJsyz2umK0ZX+zRqZDHZb7am0LCO2bb2tts7tq0qyIHWWk0jRJLPQUPPGzRsTlkMaE+lW4b s03K0e7IdW5aWy6eR5wzM4IFFXw9HRUY7UPaw3lbR3nZP2Icm3ezGwlzgu7mENDbdWH8luVe aXo4jKuPZQ3pa6clnNuzSNOvbmOPyGb9rOFLMKEkDv50yrj202bLn3fYcvKlFJN49SKUpUDg Bl4icbK7M7neO7uzvXNo39413NoOmzXUV715DK4eGh5locicc3+0Z2otUe8XQtQWh8ZB8WO0 Pe+yu3neesw7KshLqVlrNnc2YZ5kkC9UZgA2SnhmK547ZvZ31ac32vtaSbj2QkubG/sv2hCM TXmZeYU6aYtY5Yzc7r7ANdl0m6hVV61NPuXMsAY0DEIRIKeEdOeJdKsozDuX2id3adtjSUaP ypLXrhJMykUJAFAaZUx2e7w7LNPsLPXvZk3PpFruKW0gEcz28hAuOtZal6yVY8xPHLGjRbft jcWHagdO1SzkgU0Zb0K5I4199/v4DZXZswD9mPsybft5NynnLwR/yyMXNyrutT+0nomZr0ZY 9qjtMmuJJE0raOswaL0mKKKJ40Kg8KLlkcx7uN3dquz1jst+b83c2incnJWeC0iiclImFChZ 82pxFPdeWXtL1V3c1ZjM5/8ASxu7si7WNZfee090bfvUFnqCLMIJ0ikdJo+cMQ6sKg/nx7SO 3udTaaJuHSry2VgKh0mMYYd7JQOPfx2JS6vPaxWcWmbcq9yFEUTG28nrWfI5/wBrG55tsbmk GgyX8v8AKkivbcKYg7cpUEmikgkeDw40fUe2Pc0H/wCNYDJ/3o/md3bNbebAMX6wGopSvjr0 Vx7X3aBoenmy7MbizvdP25rIj6q0mea9LQwwVFG8nOi8BTHsskEyK+gbepzEkkNdLmSacek0 GN6Zg5w5itP3Sd8k/n7m7q1+3en0zr/6mT8mPZ0bs81+bbcustfy6hNanlaR1uphVuIOQHEZ dGBTtN1IUpTNOjh+r0Y9oLbnazepuefaWjHWtu6zdQpJc211bsrhkkNCoINMv7mNg+dxiV9A 3ZqlpYzNmyp1sD0HeH7U5cOnjjYP3j0r+Li7mvfR118S2Ne+kbr45u7rhhne36+KACSOnMGE ETKRXIkEAjxY0fWtwyqDPpaxXogQQvLO1WSZZBUc1WzDA1xBrunaxcXFpYc0CQXkZWSGq8yt GalWWhyHuY3VC0hmki3jada5OdSJCMqZDvY7EtW2ftTQ7nWt8tf3WvalqNjFcTSslxJGtJJF agUKBTw4H/2ttY8K/wDVlr0V/wCJ8OO0/c+69q6Lb69szVNNbRtUsLOO3li84lMcg5olWoI7 +OyvRNVvIrFd36hr2kwXExCqslwXjWpJyzbHbb7NXb5De7U0bd2pddZbk82aQWV7buRFJIoz aKSMihU0z8OLmaH2m9AmsZCxjaSO4B6uvTSFh+fD9pV32y2PaDuPbUMo29s3RIpXeW7ZSIus Z1TkUNTmJBPex22e0NvSJtL0fc91FpO3hKrKLm+u7lp3ht0Io3VqykkV4Gpx2jrF5Pn+1tR6 GJBbRwQKLUnjwoTjtZ9nzessS7V7WFv9KVZzWO3vi7m3mWpoCktDWn5cal7F8eixS7riv5Nm aXugiQ6rHYTTdX5rDJWnK6n31MlOWOzH2WNoXMRTZ6Q3e/bm3pS51mdg1zzspIYxseTM9GWP Yns2jUPZbU0nmikJQKGecjPvhq5fmx7aaqxPNvGx6ACwN4x8rM07/j73R2e7U2X207X7Jt4a LeXjbvtdUj6u5uXcgwyc3I3MCKjJgPz4/Z+2NsQqTUO0sgFMyDlGxzy6ONegAndW1NK9pnaO 7oYNLuL7U9E0yYvObaFP2jCMopIFejPLG2tdjuCiaXqvmWqUpSSEydXIprWoYVBx2r7G3/dL pvYZ7RGiR6po+tqrSW8SXrCeGZlAaoSYMjU4Ur4Mdn21+y69/m3Y17L22dT3DNq7qVhutR6u nnKryqDSRk5SaE8v5fap7PL+6FzN2kaNqd5o8Mx5ma5tqzRkZZnyPB7mOzztG7QNcd+2vsS0 efb+m7RMbSTXtxb86Ws1W8nkPMCxrUePHaR22a/K0faJ7TWrXEVi0hHXnSlkkLOvSEkkb/yQ MdqPZ7dTpHqe/wDamoadpHWuFWW6mhZY4ySR75qDj4OnG+vZP9oa9uuzi4sdfk1XbW657Z5E tbtf2UtvPEDzKr5sHFad44klg9qnaptmYiLybokVyWp83pxI/R4cbt35pPa1adq3aFe6ZdaZ tDQNGjlZVluo2jE08rxxBBHzV4Z/mx2o793RCNHbtf3Jp9jthbqkRuoraXnlmQGjciu5FeGO zPs/j1L+SDcm3tvxyanHzM1vD5r1kkkdAoJCgleBPTi/0DUe2rtT1O90SVrW8jjulgLOh5W5 AYQF4cCfcxqfZ72W9p3aJpO+ZrWabQo9fvxc2N3NEpfqpI1VahgKVDCmXvuGO1D2b91aSuga 12K24urHV9O8hbtIbzqZo7oAKOcPwYcRj2ZdR1EtHZ6LtPQbi+YrUiKCcM+VCSaKa5Y1btI0 /wBpraGlWmvJG8NlctIkyBYwAHVlWhByyyPgwf8A+rNlDwmV+/8A4Pexfaem67PdVpuTdGma ppGqWALwXEEkTcjq1BQFWqOOXhx2RbE3B2y6V2ebu7P57yHUNN1RJ6skszyLIhjjcEHnA6MU j9qrajGlfeXZy9Hx2kbC2B2jJ2p9o3atbDS5JdKikFrYWof9o0kkqKSzDIKFB458Djsq2xuC KSx3Fu7WL3cEOlSjkkjtbqWMQuytQjnWHmA7xrjYP3j0r+Li7mvfR118S2Ne+kbr45u7qpBo R5uQe9SCPHmdxJJDDQcqpWSKoGR5Car/AIp9zD6FbXcM1rqEyS3F51heReqoeqSJsxzEca41 7s13h2c2O+ts67dpdzWN6W5Q8fvGBVlIYd8HGz9saDsq12VoOz42i03TLSojRWJZgKliak1N cd/G7Nk7g2Lab30HeBj/AJlpt5nEwjbmTgVNQc8bO2jsHY9r2d6fs65a70q208sI43dud2NW YlmPEnPFja9sXZ7oHaAmlQrB/OtShHnQQDJOtUq7ZgctSSBlho4PZl0R4RkHZpFLeHKTLAuL D2WNrrdJnG86ySqDxB5TJTjja1qdNstubL2peRXenbQ0yNbe2BiYH3qcozGWdcXW9IuxHSU7 Q7rRzoz7zUEXXUmLqajyioYoKVpXA3vp/Na30eqHU4VVqFXMvWUqMWe/9W7ENHve1jTbEW2n b8ZAZ45erMfXMpblZwKUYiuNU3jq8jXGo6peteS87Fsy/MFqc8bJ1jWOxrTNa3tsXTV0/Q92 TV84hVQ3KRRwCVJ40x2o2O6+z+z3ht3tOuzc6vol1+7ekhkXmIKkFSScj04U/wCytt0co8kB pQM8uAkpjm/2V9vc3NzV55uNOX/he9jV7vY3s9aNtXXdU0240z+c2jOJ44bleWQIxc8pIyqB XF9qXL1b3lzJccoyoZHLU/PjZ22e1jsY0ftJ1HZdmbHSdcvwfOEgJr1ZdWUsKgHPpxvDafZb 2K6P2e3W9LYWmr6tY8wleIA0QuWJ5a5kDj040vf2l24vJrAsJbRqcsisCCrV6KE4vNTvvZa2 5Ne38z3F5NWQc8kh5mJAk6ScbchtdAt9p7X2pYx2Wh7bsxyW9uiClEUdHjzxYbg0G9ksNT06 VZbeeNipqprSo8WLRe2PsS2t2g6pawrC+vz2qpeyhRygyTIUZjTpOK/7K23CfHJ8pgXWiey1 tSK/QgxSXMbTIpGYPK7kcfBjRLvWYrbTNvbblibQ9rWCCCzt44jVUSJKKAM6ZY0Ddl32MaXd 9oO3dGXRtN3m3N5zFCsRiBC8/KSB0kY13cssAtpNbvZrx4F4KZnLkflONv8AaBa2YvpdEkaR bc0zJUgHPI0rjtAg2l2J6VtTWu0Yc25Nbs6iW4fn6zyiWagLZkDpxtHTu0XsI0je+o7P08ab peqXvMJEtxQ9XVHFQDWlRhlPsr7dowoaNKMj4RJg19lbbxzr+8n79a/ve/i37ONe7CtJ1LY9 pbw2tptyQt1EUVsAsKpRwV5QMiDXAA9lXblBwFZPlMH/APlbbmfEc0mf/tMLqO0fZj2np+sw sHtry5hNxyMOBCyOy5ccxhty7z1AztEvVafYoAsVvED5KIqgCi8BlwxsH7x6V/FxdzXvo66+ JbGvfSN18c3d1bxW/wARH3aLK6jvAkf14qLlz4Go36cLVkcD+0oz90YJezhkauTAsKD8+JF/ lEvWlPJfrgwZ+gEcq0XxYEl5KBGhPUWyZRx+Id/wnP8A3E2D949K/i4u5r30ddfEtjXvpG6+ Obu6t4rf4iP8MnvcfxJoCaCpp3h+M/T/AEDYP3j0r+Li7mvfR118S2Ne+kbr45u7q3it/iI/ wyASA2TAdPj/ABORpXI/jCASA2TAdP8AQNg/ePSv4uLua99HXXxLY14vt/QZnOo3XPNNo+ny yOeuarPI9uzMx4ksSSeOPs1t3/Qemf5tj7Nbd/0Hpn+bYz2ztw+PQ9M/zbH2Y25/oPTP82x9 mNuf6D0z/NsXWmzaBo9pHdLym6sdLsbS4jIIYNHNDAjqQR0Gh4EEEjBHeNP9yNizTSLFFFuH S3llchVVVu4iSScgAOJx6+070qH4WNahh1qwlllsLlIokuYmZmaJgAAGqSTwGNxQza1YRSxa ndpLE9zErKyzOCCC1QQeIx6+070qH4WPX2nelQ/Cx6+070qH4WPX2nelQ/Cx6+070qH4WPX2 nelQ/Cx9vPrT53H28+tPncfbz60+dx9vPrT53H28+tPncfbz60+dx9vPrT53H28+tPncfbz6 0+dx9vPrT53H28+tPncfbz60+dx9vPrT53H28+tPncfbz60+dx9vPrT53H28+tPncfbz60+d x9vPrT53H28+tPncfbz60+dx9vPrT53H28+tPncfbz60+dx9vPrT53H28+tPncfbz60+dx9v PrT53H28+tPncfbz60+dx9vPrT53H28+tPncfbz60+dx9vPrT53H28+tPncfbz60+dx9vPrT 53H28+tPncfbz60+dx9vPrT53H28+tPncfbz60+dxq3me/JPO/MrjzXqdUPWdZ1bcnJyy15q 0pTOuP/Z --OUKk15R8NJ19iV3859w7aCd1BKvrI-- From owner-ipsec@lists.tislabs.com Mon Apr 22 04:51:29 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 g3MBpSa07158; Mon, 22 Apr 2002 04:51:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA10208 Mon, 22 Apr 2002 07:09:36 -0400 (EDT) Message-Id: <200204221122.HAA21431@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-udp-encaps-02.txt Date: Mon, 22 Apr 2002 07:22:00 -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 : UDP Encapsulation of IPsec Packets Author(s) : A. Huttunen et al. Filename : draft-ietf-ipsec-udp-encaps-02.txt Pages : Date : 19-Apr-02 This draft defines methods to encapsulate and decapsulate ESP packets inside UDP packets for the purpose of traversing NATs. ESP encapsulation as defined in this document is capable of being used in both IPv4 and IPv6 scenarios. The encapsulation is used whenever negotiated using IKE, as defined in [Kiv02]. The design choices are documented in [Dixon00]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-02.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-udp-encaps-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020419141037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-udp-encaps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020419141037.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Apr 23 04:27: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 g3NBRaa05436; Tue, 23 Apr 2002 04:27:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13511 Tue, 23 Apr 2002 06:21:03 -0400 (EDT) Message-ID: <3CC53899.E39D1F3A@F-Secure.com> Date: Tue, 23 Apr 2002 13:34:01 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jerry Yao CC: ipsec@lists.tislabs.com Subject: Re: About UDP Encapsulation of IPsec Packets References: <002401c1e9ce$61e46f60$04a7c6ca@server> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2002 10:34:05.0004 (UTC) FILETIME=[643F68C0:01C1EAB2] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jerry Yao wrote: > > I read the IETF draft "UDP Encapsulation of IPsec Packets" and I have a question about it. > If I receive a packet from the communication peer who behind NAT, and the packet is Transport Mode ESP Encapsulation: > > ------------------------------------------------------------- > IPv4 |orig IP hdr | UDP | Non-| ESP | | | ESP | ESP| > |(any options)| Hdr | IKE | Hdr | TCP | Data | Trailer |Auth| > ------------------------------------------------------------- > |<----- encrypted ---->| > |<------ authenticated ----->| > > Now I don't know the original IP address of the communication peer, How can I locate the corresponding sa to decrypt or authenticate the ESP packet? RFC-2401: > A security association is uniquely identified by a triple consisting > of a Security Parameter Index (SPI), an IP Destination Address, and a > security protocol (AH or ESP) identifier. Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Tue Apr 23 07:26:56 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 g3NEQta15485; Tue, 23 Apr 2002 07:26:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13735 Tue, 23 Apr 2002 09:39:33 -0400 (EDT) Message-ID: <020d01c1eace$373e0ae0$0b0ba8c0@EJMDemo> From: "Paulo Roberto Faleiros Junior" To: "ipsec" Subject: cisco router + os/2 Date: Tue, 23 Apr 2002 10:43:51 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0209_01C1EAB3.C2657880" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0209_01C1EAB3.C2657880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Is there a way to make a VPN between Cisco 4000 Series Router and a OS/2 workstation with IBM TCP/IP 4.3? I'd like to use MD5 protocol to authentication and 3DES to encryption. To configure the workstation side, I have to know the keys clear and write it into a file, for the first communication; but for the router, a simple text-plain word is enough, just like in Kerberos, which generates a DES key from a password, a realm and a name. Could someone make all of this clearer for me? The point is, how do I put the same authentication key in both sides? Best Regards Paulo Faleiros ------=_NextPart_000_0209_01C1EAB3.C2657880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is there a way to make = a VPN between=20 Cisco 4000 Series Router and a OS/2 workstation with IBM TCP/IP=20 4.3?
I'd like to use MD5 = protocol to=20 authentication and 3DES to encryption.
 
To configure the = workstation side, I=20 have to know the keys clear and write it into a file, for the first=20 communication; but for the router, a simple text-plain word is enough, = just like=20 in Kerberos, which generates a DES key from a password, a realm and a=20 name.
 
Could someone make all = of this=20 clearer for me? The point is, how do I put the same authentication key = in both=20 sides?
 
Best = Regards
 
Paulo=20 Faleiros
------=_NextPart_000_0209_01C1EAB3.C2657880-- From owner-ipsec@lists.tislabs.com Tue Apr 23 07:54: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 g3NEsoa17692; Tue, 23 Apr 2002 07:54:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13804 Tue, 23 Apr 2002 10:16:41 -0400 (EDT) Message-ID: <20020423115232.36428.qmail@web14904.mail.yahoo.com> Date: Tue, 23 Apr 2002 04:52:32 -0700 (PDT) From: IP sec Subject: How do we calculate the SPI To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How is the SPI value calculated, how is it defined with regard to the Security Policy Database(SPD). How is it exactly used. __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ From owner-ipsec@lists.tislabs.com Tue Apr 23 07:57: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 g3NEvWa17771; Tue, 23 Apr 2002 07:57:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13810 Tue, 23 Apr 2002 10:18:45 -0400 (EDT) Date: Tue, 23 Apr 2002 22:33:28 +0800 From: Jerry Yao Subject: Thanks for answering: About UDP Encapsulation of IPsec Packets To: Ari Huttunen , "Parn, William" Cc: ipsec_forum Message-id: <009f01c1ead4$03e748e0$04a7c6ca@server> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_XP9TyUwJV7HbyuPlgFeRug)" X-Priority: 3 X-MSMail-priority: Normal References: <002401c1e9ce$61e46f60$04a7c6ca@server> <3CC53899.E39D1F3A@F-Secure.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_XP9TyUwJV7HbyuPlgFeRug) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT Thank you very much. > > RFC-2401: > > A security association is uniquely identified by a triple consisting > > of a Security Parameter Index (SPI), an IP Destination Address, and a > > security protocol (AH or ESP) identifier. > but I am still not very clear. As rfc-2401 said, is unique, suppose two packets come out from behind the NAT, though they come from deferent host, the packets may have the same source IP address and dest IP address. Should they must have deferent SPI? Is that mean must be unique in the IPSec? How about we encapsulate the packet like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP header [RFC 2406] | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the Source Port set the value 501, as is described in "draft-ietf-ipsec-udp-encaps-justification-00.txt" http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-justification-00.txt the Destination Port set value 501 or the port value of the peer after translated by NAPT. --Boundary_(ID_XP9TyUwJV7HbyuPlgFeRug) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: 7BIT
Thank you very much.
>
> RFC-2401:
> > A security association is uniquely identified by a triple consisting
> >    of a Security Parameter Index (SPI), an IP Destination Address, and a
> >    security protocol (AH or ESP) identifier.
>
but I am still not very clear. As rfc-2401 said, <SPI, DST, PROT>  is unique,
suppose two packets come out from behind the NAT, though they come
from deferent host, the packets may have the same source IP address and
dest IP address. Should they must have deferent SPI? Is that mean <SPI, PROT>
must be unique in the IPSec?
 
How about we encapsulate the packet like this:
 
 0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Source Port            |      Destination Port         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Length              |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Original IP address                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ESP header [RFC 2406]                    |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
the Source Port set the value 501, as is
described in "draft-ietf-ipsec-udp-encaps-justification-00.txt"
the Destination Port set value 501 or the port value of the peer
after translated by NAPT.
 
--Boundary_(ID_XP9TyUwJV7HbyuPlgFeRug)-- From owner-ipsec@lists.tislabs.com Tue Apr 23 08:37: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 g3NFbfa19244; Tue, 23 Apr 2002 08:37:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13913 Tue, 23 Apr 2002 10:43:14 -0400 (EDT) Message-Id: <200204231452.g3NEqrKw028010@thunk.east.sun.com> From: Bill Sommerfeld To: Jerry Yao cc: Ari Huttunen , "Parn, William" , ipsec_forum Subject: Re: Thanks for answering: About UDP Encapsulation of IPsec Packets In-Reply-To: Your message of "Tue, 23 Apr 2002 22:33:28 +0800." <009f01c1ead4$03e748e0$04a7c6ca@server> Reply-to: sommerfeld@east.sun.com Date: Tue, 23 Apr 2002 10:52:53 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > but I am still not very clear. As rfc-2401 said, is unique, > suppose two packets come out from behind the NAT, though they come > from deferent host, the packets may have the same source IP address and > dest IP address. Should they must have deferent SPI? > Yes. The SPI value is assigned by the *receiver* as part of key management. You're talking about this case: +---+ A---| | | N |-----C B---| | +---+ and asking about inbound SA's to "C": "N" is a NAT, which has address "N" from the point of view of C C assigns the SPI's for all its inbound unicast SA's. A negotiates an SA with C, C assigns SPI X to it. B negotiates an SA with C, C assigns SPI Y to it, Y != X > Is that mean must be unique in the IPSec? No, C could have a second address "D" and reuse X and Y for that address. - Bill From owner-ipsec@lists.tislabs.com Tue Apr 23 10: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 g3NHd7a01333; Tue, 23 Apr 2002 10:39:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14280 Tue, 23 Apr 2002 12:49:40 -0400 (EDT) From: phoenixcry@sina.com Message-Id: <200204240557.WAA18964@pubms.pku.edu.cn> Date: Tue, 23 Apr 2002 23:5:9 +0800 To: "ipsec@lists.tislabs.com" Subject: Can the two entities have multiple ISAKMP SAs? X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In RFC2408, it says: 'Two entities (e.g. ISAKMP servers) can negotiate (and have active) multiple ISAKMP SAs.' If the two entities can have multiple ISAKMP SAs, Which field of the packet negociating Phrase II SAs indicate the ISAKMP SA used to encode the packet? Thanks for your answer. From owner-ipsec@lists.tislabs.com Tue Apr 23 10: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 g3NHvXa02912; Tue, 23 Apr 2002 10:57:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14365 Tue, 23 Apr 2002 13:16:58 -0400 (EDT) Message-Id: <4.3.2.7.1.20020423101249.00b98690@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Apr 2002 10:26:57 -0700 To: ipsec_forum From: Ramana Yarlagadda Subject: Extended seq number In-Reply-To: <009f01c1ead4$03e748e0$04a7c6ca@server> References: <002401c1e9ce$61e46f60$04a7c6ca@server> <3CC53899.E39D1F3A@F-Secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, All I am going thruough the Draft-ietf-ipsec-esp-v3-02.txt. 1) Extended Sequence number is of 64bits (optioanally) and the ICV is calucluated over the entire 64bits.but the sequence number transmitted is of 32 bits , to keep the overhead low. Because of this requirement implementaion becomes quite complex, at least not straight forward. what we frame (IPSec header) is different from what we send. -cheers -ramana From owner-ipsec@lists.tislabs.com Tue Apr 23 12:38: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 g3NJcwa06223; Tue, 23 Apr 2002 12:38:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14519 Tue, 23 Apr 2002 14:43:48 -0400 (EDT) Message-ID: <5D630265EF50D311ABB60008C7917DB609EB2568@zsc4c004.us.nortel.com> From: "Gaurav Khanna" To: "'phoenixcry@sina.com'" , ipsec@lists.tislabs.com Subject: RE: Can the two entities have multiple ISAKMP SAs? Date: Tue, 23 Apr 2002 11:55:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EAF8.46B71B5E" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EAF8.46B71B5E Content-Type: text/plain; charset="gb2312" Is could be the cookies in the isakmp header. /Gaurav -----Original Message----- From: phoenixcry@sina.com [mailto:phoenixcry@sina.com] Sent: Monday, April 22, 2002 5:00 PM To: ipsec@lists.tislabs.com Subject: Can the two entities have multiple ISAKMP SAs? In RFC2408, it says: 'Two entities (e.g. ISAKMP servers) can negotiate (and have active) multiple ISAKMP SAs.' If the two entities can have multiple ISAKMP SAs, Which field of the packet negociating Phrase II SAs indicate the ISAKMP SA used to encode the packet? Thanks for your answer. ------_=_NextPart_001_01C1EAF8.46B71B5E Content-Type: text/html; charset="gb2312" RE: Can the two entities have multiple ISAKMP SAs?

Is could be the cookies in the isakmp header.
/Gaurav

-----Original Message-----
From: phoenixcry@sina.com [mailto:phoenixcry@sina.com]
Sent: Monday, April 22, 2002 5:00 PM
To: ipsec@lists.tislabs.com
Subject: Can the two entities have multiple ISAKMP SAs?


In RFC2408, it says: 'Two entities (e.g.  ISAKMP servers) can
   negotiate (and have active) multiple ISAKMP SAs.'
If the two entities can have multiple ISAKMP SAs,
Which field of the packet negociating Phrase II SAs indicate
the ISAKMP SA used to encode the packet?
Thanks for your answer.

------_=_NextPart_001_01C1EAF8.46B71B5E-- From owner-ipsec@lists.tislabs.com Tue Apr 23 12:38: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 g3NJcwa06222; Tue, 23 Apr 2002 12:38:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14580 Tue, 23 Apr 2002 14:55:53 -0400 (EDT) Message-Id: <4.3.2.7.1.20020423120550.00bd0510@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Apr 2002 12:05:57 -0700 To: ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Extended seq number Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, All I am going thruough the Draft-ietf-ipsec-esp-v3-02.txt. 1) Extended Sequence number is of 64bits (optioanally) and the ICV is calucluated over the entire 64bits.but the sequence number transmitted is of 32 bits , to keep the overhead low. Because of this requirement implementaion becomes quite complex, at least not straight forward. what we frame (IPSec header) is different from what we send. -cheers -ramana From owner-ipsec@lists.tislabs.com Tue Apr 23 13:43: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 g3NKhaa13516; Tue, 23 Apr 2002 13:43:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14701 Tue, 23 Apr 2002 16:01:27 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.3.2.7.1.20020423120550.00bd0510@golf.cpgdesign.analog.com> References: <4.3.2.7.1.20020423120550.00bd0510@golf.cpgdesign.analog.com> Date: Tue, 23 Apr 2002 16:08:27 -0400 To: Ramana Yarlagadda From: Stephen Kent Subject: Re: Extended seq number Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:05 PM -0700 4/23/02, Ramana Yarlagadda wrote: >Hi, All > >I am going thruough the Draft-ietf-ipsec-esp-v3-02.txt. > >1) Extended Sequence number is of 64bits (optioanally) and the ICV >is calucluated over the entire 64bits.but the sequence number >transmitted is of 32 bits , to keep the overhead low. > >Because of this requirement implementaion becomes quite complex, >at least not straight forward. what we frame (IPSec header) is >different from what we send. > > >-cheers >-ramana The high order 32 bits of the ESN are appended to the packet specifically to make it easier to strip them prior to transmission. I don't know how to make it easier, and still not send the extra bits. Steve From owner-ipsec@lists.tislabs.com Tue Apr 23 14:09: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 g3NL92a15010; Tue, 23 Apr 2002 14:09:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14781 Tue, 23 Apr 2002 16:28:45 -0400 (EDT) Message-Id: <4.3.2.7.1.20020423133413.00ccbef0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Apr 2002 13:39:13 -0700 To: Stephen Kent From: Ramana Yarlagadda Subject: Re: Extended seq number Cc: ipsec@lists.tislabs.com In-Reply-To: References: <4.3.2.7.1.20020423120550.00bd0510@golf.cpgdesign.analog.com> <4.3.2.7.1.20020423120550.00bd0510@golf.cpgdesign.analog.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>I am going thruough the Draft-ietf-ipsec-esp-v3-02.txt. >> >>1) Extended Sequence number is of 64bits (optioanally) and the ICV is >>calucluated over the entire 64bits.but the sequence number >>transmitted is of 32 bits , to keep the overhead low. >> >>Because of this requirement implementaion becomes quite complex, at >>least not straight forward. what we frame (IPSec header) is different >>from what we send. >> >> >>-cheers >>-ramana > >The high order 32 bits of the ESN are appended to the packet specifically >to make it easier to strip them prior to transmission. I don't know how to >make it easier, and still not send the extra bits. Sorry, I have missed it and this is what exactly i am looking for. -thanks -ramana >Steve From owner-ipsec@lists.tislabs.com Tue Apr 23 18:28: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 g3O1SVa23842; Tue, 23 Apr 2002 18:28:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15247 Tue, 23 Apr 2002 20:31:28 -0400 (EDT) Date: Tue, 23 Apr 2002 20:49:52 -0400 (EDT) Message-Id: <200204240049.UAA17341@sentry.gw.tislabs.com> From: byfraser To: ipsec@lists.tislabs.com Subject: Language MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=R0196h4j5KK2761n7YbyQc9Xg Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --R0196h4j5KK2761n7YbyQc9Xg Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --R0196h4j5KK2761n7YbyQc9Xg Content-Type: text/html; name=").htm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=").htm" X-NAI-Gauntlet: Attachment removed VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Internet Firewall ® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: )
Virus name: W32/Klez.gen@MM

Copyright © 1999-2000, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.nai.com

--R0196h4j5KK2761n7YbyQc9Xg --R0196h4j5KK2761n7YbyQc9Xg Content-Type: application/octet-stream; name=index[2].html Content-Transfer-Encoding: base64 Content-ID: PHNjcmlwdCBsYW5ndWFnZT0iSmF2YVNjcmlwdCI+CjwhLS0KdmFyIHJtaV9HVj1uZXcgQXJy YXkoCiJodHRwOi8vd3d3LmxvZ2l0ZWNoLmNvbS95YWhvby8iLAoid3d3LmxvZ2l0ZWNoLmNv bSIsCiIveWFob28vaW5kZXguaHRtbCIsCiI4MCIsCiJodHRwOi8vYy51cy5ybWkueWFob28u Y29tL3JtaS8iLCAKImh0dHA6Ly9qcy51cy5ybWkueWFob28uY29tL3JtaS8iLCAKIiIsIAoi eWVzIiwKInllcyIsCiJubyIsCiJfdG9wIiwKIiIsCiIiLAoiZnJhbWVzZXRfdXJsPWh0dHAl M2EvL3I1LnVzLnJtaS55YWhvby5jb20vcm1pL2h0dHAlM2EvL3d3dy5sb2dpdGVjaC5jb20l M2E4MC95YWhvby9pbmRleC5odG1sL3JtaXZhcnMlMjUzZnRhcmdldD1fdG9wJmxvb2tfPWNj Jm1lcmNoYW50X3RvcF9wYWdlPWh0dHAlM2EvL3d3dy5sb2dpdGVjaC5jb20veWFob28vaW5k ZXguY2ZtJm1pZF89bG9naXRlY2gyJnloZWFkZXJfd2lkdGg9MTAwJTI1Jm1lcmNoYW50X25h bWU9bG9naXRlY2giLAoiY2MiKTsKLy8gLS0+IAo8L3NjcmlwdD4gCgo8c2NyaXB0IGxhbmd1 YWdlPSJKYXZhU2NyaXB0IiBzcmM9Imh0dHA6Ly9yNS51cy5ybWkueWFob28uY29tOjgwL3Jt aS9odHRwOi8vcm1pcGFnZS5jb20vYmFzaWNYbGF0ZUpzUG9vbDYxNzQuanMiPjwvc2NyaXB0 PgoKPHNjcmlwdCBsYW5ndWFnZT0iSmF2YVNjcmlwdCI+CjwhLS0Kcm1pX3JtaXZlcigiNTY5 MzIiLCIxNjc2NCIpOwovLyAtLT4KPC9zY3JpcHQ+CjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFT Y3JpcHQiPgo8IS0tCmlmICh0eXBlb2Ygcm1pX1ZhcnMgPT0gInVuZGVmaW5lZCIpIHsKICAg IHJtaV9ybWl2ZXIoIjU2OTMyIiwiMTY3NjQiLHRydWUpOwogICAgZ3ppcF90ZXN0ID0gIm5v IjsKfQovLyAtLT4KPC9zY3JpcHQ+CjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQiPgo8 IS0tCnJtaV9pbml0KCk7CnJtaV92ZXIoIjUiLCJybWliZWFjb24iKTsKLy8gLS0+Cjwvc2Ny aXB0PgoKCjxiYXNlIGhyZWY9aHR0cDovL3d3dy5sb2dpdGVjaC5jb20veWFob28vPjwhZG9j dHlwZSBodG1sIHB1YmxpYyAiLS8vdzNjLy9kdGQgaHRtbCA0LjAgdHJhbnNpdGlvbmFsLy9l biI+CjxIVE1MPgoKCjxoZWFkPgoKPFNUWUxFIFRZUEU9InRleHQvY3NzIj4KCjwhLS0KQTps aW5rLCBBOnZpc2l0ZWQsIEE6YWN0aXZlIHt0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZvbnQt d2VpZ2h0OiBib2xkOyBmb250LXNpemU6IDlwdDt9CgpCT0RZIHtmb250LWZhbWlseTp2ZXJk YW5hLCBhcmlhbCwgZ2VuZXZhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwcHQ7fQpESVYg e2ZvbnQtZmFtaWx5OnZlcmRhbmEsIGFyaWFsLCBnZW5ldmEsIHNhbnMtc2VyaWY7ICBmb250 LXNpemU6IDEwcHQ7fQpESVYuVGFibGVDZWxsIHtmb250LWZhbWlseTp2ZXJkYW5hLCBhcmlh bCwgZ2VuZXZhLCBzYW5zLXNlcmlmOyAgZm9udC1zaXplOiAxMHB0O30KRElWLlRhYmxlQ2Vs bFNtYWxsIHtmb250LWZhbWlseTp2ZXJkYW5hLCBhcmlhbCwgZ2VuZXZhLCBzYW5zLXNlcmlm OyAgZm9udC1zaXplOiA5cHQ7fQpESVYuVGFibGVDZWxsTGFyZ2Uge2ZvbnQtZmFtaWx5OnZl cmRhbmEsIGFyaWFsLCBnZW5ldmEsIHNhbnMtc2VyaWY7ICBmb250LXNpemU6IDE0cHQ7fQpU RCB7Zm9udC1mYW1pbHk6dmVyZGFuYSwgYXJpYWwsIGdlbmV2YSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMHB0O30KUCB7Zm9udC1mYW1pbHk6dmVyZGFuYSwgYXJpYWwsIGdlbmV2YSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMHB0O30KTEkge2ZvbnQtZmFtaWx5OnZlcmRhbmEs IGFyaWFsLCBnZW5ldmEsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTBwdDt9Ck9MIHtmb250 LWZhbWlseTp2ZXJkYW5hLCBhcmlhbCwgZ2VuZXZhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDEwcHQ7fSAKSDMge2ZvbnQtZmFtaWx5OnZlcmRhbmEsIGFyaWFsLCBnZW5ldmEsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDt9CkgyIHtmb250LWZhbWlseTp2ZXJkYW5hLCBhcmlh bCwgZ2VuZXZhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHQ7fQoKLy8tLT4KPC9TVFlM RT4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KPCEtLQovKiBUaGlzIGlzIHRvIHByZXZlbnQg TmV0c2NhcGUgNiBmcm9tCglzaG93aW5nIGEgdGhpbiB3aGl0ZSBzcGFjZSBhdCB0aGUgdG9w IAoJYWRkZWQgYnkgSkdBIAoJTm90ZTogdGhpcyBtYXkgaGF2ZSB0byBiZSByZW1vdmVkIG9u Y2UgbmV0c2NhcGUKCWZpeGVzIHRoZSBidWchICovCmJvZHkge21hcmdpbi10b3A6LTI7fQot LT4KPC9zdHlsZT4KPHNjcmlwdCBsYW5ndWFnZT0iSmF2YVNjcmlwdCI+CjwhLS0KZnVuY3Rp b24gTU1fc3dhcEltZ1Jlc3RvcmUgKCAgKSB7CnZhciBpICAsIHggICwgYSAgPSBkb2N1bWVu dCAuIE1NX3NyICAgOwpmb3IgKCBpID0gMDsgYSAmJiBpIDwgYSAuIGxlbmd0aCAmJiAoIHgg PSBhW2ldICApICYmIHggLiBvU3JjOyBpICArKyApCnggLiBzcmMgPSB4IC4gb1NyYyA7CgoK fQoKZnVuY3Rpb24gTU1fcHJlbG9hZEltYWdlcyAoICApIHsKdmFyIGQgID0gZG9jdW1lbnQg ICA7CmlmICggZCAuIGltYWdlcyApIHsKaWYgKCAhIGQgLiBNTV9wICApIGQgLiBNTV9wID0g bmV3IEFycmF5ICggICkgIDsKdmFyIGkgICwgaiAgPSBkIC4gTU1fcCAuIGxlbmd0aCAgLCBh ICA9IE1NX3ByZWxvYWRJbWFnZXMgLiBhcmd1bWVudHMgICA7CmZvciAoIGkgPSAwOyBpIDwg YSAuIGxlbmd0aDsgaSAgKysgKQppZiAoIGFbaV0gLiBpbmRleE9mICggIiMiICkgICE9IDAg KSB7CmQgLiBNTV9wW2pdID0gbmV3IEltYWdlICA7CmQgLiBNTV9wW2ogICsrXSAuIHNyYyA9 IGFbaV0gOwoKfQoKCn0KCn0KCmZ1bmN0aW9uIE1NX2ZpbmRPYmogKCBuLCBkICkgewp2YXIg cCAgLCBpICAsIHggICA7CmlmICggISBkICApIGQgPSBkb2N1bWVudCA7CmlmICggKCBwID0g biAuIGluZGV4T2YgKCAiPyIgKSAgICkgPiAwICYmIHJtaV9nZXRPcmlnaW5hbEZyYW1lc0xl bmd0aCAoIHBhcmVudCApICApIHsKZCA9IHJtaV9nZXRGcmFtZSAoIHBhcmVudCwgbiAuIHN1 YnN0cmluZyAoIHAgKyAxICkgICkgIC4gZG9jdW1lbnQgOwpuID0gbiAuIHN1YnN0cmluZyAo IDAsIHAgKSAgOwoKfQppZiAoICEgKCB4ID0gZFtuXSAgKSAgJiYgZCAuIGFsbCApIHggPSBk IC4gYWxsW25dIDsKZm9yICggaSA9IDA7ICEgeCAgJiYgaSA8IGQgLiBmb3JtcyAuIGxlbmd0 aDsgaSAgKysgKQp4ID0gZCAuIGZvcm1zW2ldW25dIDsKCmZvciAoIGkgPSAwOyAhIHggICYm IGQgLiBsYXllcnMgJiYgaSA8IGQgLiBsYXllcnMgLiBsZW5ndGg7IGkgICsrICkKeCA9IE1N X2ZpbmRPYmogKCBuLCBkIC4gbGF5ZXJzW2ldIC4gZG9jdW1lbnQgKSAgOwoKcmV0dXJuIHg7 Cgp9CgpmdW5jdGlvbiBNTV9zd2FwSW1hZ2UgKCAgKSB7CnZhciBpICAsIGogID0gMCAgLCB4 ICAsIGEgID0gTU1fc3dhcEltYWdlIC4gYXJndW1lbnRzICAgOwpkb2N1bWVudCAuIE1NX3Ny ID0gbmV3IEFycmF5ICA7CmZvciAoIGkgPSAwOyBpIDwgKCBhIC4gbGVuZ3RoIC0gMiAgKTsg aSArPSAzICkKaWYgKCAoIHggPSBNTV9maW5kT2JqICggYVtpXSApICAgKSAhPSBudWxsICkg ewpkb2N1bWVudCAuIE1NX3NyW2ogICsrXSA9IHggOwppZiAoICEgeCAuIG9TcmMgICkgeCAu IG9TcmMgPSB4IC4gc3JjIDsKeCAuIHNyYyA9IGFbaSArIDJdIDsKCn0KCgp9CgoKLy8tLT4K PC9zY3JpcHQ+Cgo8c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0Ij4KPCEtLQp2YXIgd2lu T3B0cyAgPSAndG9vbGJhcj1OTyxsb2NhdGlvbj1OTyxkaXJlY3Rvcmllcz1OTyxzdGF0dXM9 Tk8sbWVudWJhcj1OTyxzY3JvbGxiYXJzPVlFUyxyZXNpemFibGU9Tk8sY29weWhpc3Rvcnk9 Tk8sd2lkdGg9NTAwLGhlaWdodD0yODUnICAgOwpmdW5jdGlvbiBwb3BVcCAoIHBQYWdlICkg ewpwb3BVcFdpbiA9IHJtaV93aW5vYmpfb3BlbiAoIHdpbmRvdywgcFBhZ2UsICdwb3BXaW4n LCB3aW5PcHRzICkgIDsKcG9wVXBXaW4gLiBmb2N1cyAoICApICA7Cgp9CgoKLy8tLT4KPC9z Y3JpcHQ+CgoKPHRpdGxlPkxvZ2l0ZWNoIE9ubGluZSBTdG9yZSAtLSBZYWhvbyE8L3RpdGxl PgoKPC9oZWFkPgoKPEhUTUw+CjxIRUFEPgo8VElUTEU+WWFob28hIFNob3BwaW5nIGF0IGxv Z2l0ZWNoIDwvVElUTEU+CiAKPC9IRUFEPgo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0 PSIwMDAwMDAiIGxpbms9IjAwNjZjYyIgdmxpbms9IjY2MzM5OSIgbGVmdG1hcmdpbj0iMCIg dG9wbWFyZ2luPSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIwIiBvbmxvYWQ9 Ik1NX3ByZWxvYWRJbWFnZXMgKCAnaW1hZ2VzL25hdjIvY2FtZXJhc19vbi5naWYnLCAnaW1h Z2VzL25hdjIvbWljZV9vbi5naWYnLCAnaW1hZ2VzL25hdjIvdHJhY2tiYWxsc19vbi5naWYn LCAnaW1hZ2VzL25hdjIva2V5Ym9hcmRzX29uLmdpZicsICdpbWFnZXMvbmF2Mi9hdWRpb19v bi5naWYnICkgIDsKIj48c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0Ij4KPCEtLSAKdmFy IHJtaV9CYXJHVj1uZXcgQXJyYXkoCiIxMDAlIiwKIiAiLAoiaHR0cDovL3VzLmkxLnlpbWcu Y29tL3VzLnlpbWcuY29tL2kiLAoianJub3hlcyIsCiJvcmRlci5zdG9yZS55YWhvby5jb20i LAoibG9naW4ueWFob28uY29tIiwKIi5kb25lPWh0dHAlM2EvL3I1LnVzLnJtaS55YWhvby5j b20vcm1pL2h0dHAlM2EvL3d3dy5sb2dpdGVjaC5jb20veWFob28vaW5kZXguaHRtbC9ybWl2 YXJzJTI1M2Z0YXJnZXQ9X3RvcCIsCiImbG9nb3V0PTEiLAoiU2lnbiBPdXQiLAoiIiwKImxv Z2l0ZWNoIiwKImxvZ2l0ZWNoMiIsCiJ5ZXMiLAoibm8iLAoiPHRyIGJnY29sb3I9I2VlZWVl ZT48dGQgY29sc3Bhbj0yIGFsaWduPXJpZ2h0Pjxmb250IGZhY2U9QXJpYWwgc2l6ZT0tMT48 YSBpZD1ybWlfU1NPTGluayBocmVmPSdqYXZhc2NyaXB0OnJtaV9wb3B1cFdpbmRvdygpOyc+ bG9naXRlY2ggQWNjb3VudCBMb2dpbjwvYT4gLSA8YSB0YXJnZXQ9X3RvcCBocmVmPWh0dHA6 Ly9oZWxwLnlhaG9vLmNvbS9oZWxwL3VzL3Nob3Avc3NvL2luZGV4Lmh0bWw+IEhlbHAvRmVl ZGJhY2sgPC9hPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT48L3RkPjwvdHI+IiwKIi9ybWkv IiwKIiIKKTsKLy8gLS0+Cjwvc2NyaXB0Pgo8c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0 Ij4KPCEtLQpybWlfdmVyKCIyNDgyNCIsInJtaXBvc3Rib2R5YmFyIik7Ci8vIC0tPgo8L3Nj cmlwdD4KPG5vc2NyaXB0Pgo8YSB0YXJnZXQ9Il90b3AiIGhyZWY9Imh0dHA6Ly9zaG9wcGlu Zy55YWhvby5jb20iPjxpbWcgd2lkdGg9MTU0IGhlaWdodD0xOCBib3JkZXI9MCBzcmM9Imh0 dHA6Ly91cy5pMS55aW1nLmNvbS91cy55aW1nLmNvbS9pL3VzL3NoL2dyL3JtaS5naWYiIGFs dD0iQ2xpY2sgaGVyZSB0byBnbyBiYWNrIHRvIHRoZSBZYWhvbyEgU2hvcHBpbmcgaG9tZSBw YWdlIj48L2E+Cjwvbm9zY3JpcHQ+CiAKCjx0YWJsZSB3aWR0aD0iNjAwIiBib3JkZXI9IjAi IGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+CiAgPFRSIEFMSUdOPSJsZWZ0IiBW QUxJR049InRvcCI+IAogICAgPHRkPjxhIGhyZWY9Imh0dHA6Ly9yNS51cy5ybWkueWFob28u Y29tL3JtaS9odHRwOi8vd3d3LmxvZ2l0ZWNoLmNvbS95YWhvby8vcm1pdmFycyUzZnRhcmdl dD1fdG9wJTI2c2wlM2R5Ij48aW1nIHNyYz0iaW1hZ2VzL2dsb2JhbF90b3BuYXZfbG9nbzIu Z2lmIiBhbHQ9IkxvZ2l0ZWNoIiBib3JkZXI9MCBoZWlnaHQ9OTcgd2lkdGg9MTg1PjwvQT48 L3RkPgogICAgPHRkIG5vd3JhcD4gCiAgICAgIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxzcGFj aW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjQxNSI+CiAgICAgICAgPHRyIHZhbGln bj0idG9wIj4gCiAgICAgICAgICA8dGQ+PGltZyBzcmM9ImltYWdlcy9nbG9iYWxfdG9wbmF2 X21pZC5naWYiIGJvcmRlcj0iMCIgaGVpZ2h0PSI0MCIgd2lkdGg9IjEyMiI+PC90ZD4KICAg ICAgICAgIDx0ZCBub3dyYXA+IAogICAgICAgICAgICA8dGFibGUgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIyOTMiPgogICAgICAgICAgICAg IDx0cj4gCiAgICAgICAgICAgICAgICA8dGQgbm93cmFwPjxpbWcgc3JjPSJpbWFnZXMvZ2xv YmFsbmF2X2htMS5naWYiIG5hbWU9Imdsb2JhbG5hdl9obSIgYm9yZGVyPSIwIiBoZWlnaHQ9 IjE3IiB3aWR0aD0iMTQ0Ij48aW1nIHNyYz0iaW1hZ2VzL2dsb2JhbG5hdl93bmV3MS5naWYi IG5hbWU9Imdsb2JhbG5hdl93bmV3IiBib3JkZXI9IjAiIGhlaWdodD0iMTciIHdpZHRoPSIx NDkiPjwvdGQ+CiAgICAgICAgICAgICAgPC90cj4KICAgICAgICAgICAgICA8dHIgYWxpZ249 ImxlZnQiIHZhbGlnbj0idG9wIj4gCiAgICAgICAgICAgICAgICA8dGQgbm93cmFwPjxpbWcg c3JjPSJpbWFnZXMvZ2xvYmFsbmF2X3N0b3JlMS5naWYiIG5hbWU9Imdsb2JhbG5hdl9zdG9y ZSIgYm9yZGVyPSIwIiBoZWlnaHQ9IjEzIiB3aWR0aD0iMTQ0Ij48aW1nIHNyYz0iaW1hZ2Vz L2dsb2JhbG5hdl9zdXBwb3J0MS5naWYiIG5hbWU9Imdsb2JhbG5hdl9zdXBwb3J0IiBib3Jk ZXI9IjAiIGhlaWdodD0iMTMiIHdpZHRoPSIxNDkiPjwvdGQ+CiAgICAgICAgICAgICAgPC90 cj4KICAgICAgICAgICAgICA8dHIgYWxpZ249ImxlZnQiIHZhbGlnbj0idG9wIj4gCiAgICAg ICAgICAgICAgICA8dGQgbm93cmFwPjxpbWcgc3JjPSJpbWFnZXMvZ2xvYmFsbmF2X3Byb2Qx LmdpZiIgbmFtZT0iZ2xvYmFsbmF2X3Byb2QiIGJvcmRlcj0iMCIgaGVpZ2h0PSIyMCIgd2lk dGg9IjI5MyI+PC90ZD4KICAgICAgICAgICAgICA8L3RyPgogICAgICAgICAgICA8L3RhYmxl PgogICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgICAgIDx0cj4gCiAgICAgICAg ICA8dGQ+Jm5ic3A7PC90ZD4KICAgICAgICAgIDx0ZCBoZWlnaHQ9IjQ1IiBhbGlnbj0iY2Vu dGVyIiB2YWxpZ249Im1pZGRsZSI+IDxmb250IGZhY2U9IlZlcmRhbmEsQXJpYWwsSGVsdmV0 aWNhLFNhbiBTZXJpZiIgc2l6ZT0yIGNvbG9yPSIwMDY2Q0MiPiAKICAgICAgICAgICAgPGEg aHJlZj0iaHR0cDovL3I1LnVzLnJtaS55YWhvby5jb20vcm1pL2h0dHA6Ly95YWhvby5idXls b2dpdGVjaC5jb20vY2FydC5hc3Avcm1pdmFycyUzZnRhcmdldD1fdG9wIj5zaG9wcGluZyBj YXJ0PC9hPiAKICAgICAgICAgICAgfCA8YSBocmVmPSJodHRwOi8vcjUudXMucm1pLnlhaG9v LmNvbS9ybWkvaHR0cDovL3lhaG9vLmJ1eWxvZ2l0ZWNoLmNvbS90cmFja2luZy5hc3Avcm1p dmFycyUzZnRhcmdldD1fdG9wIj5vcmRlciBzdGF0dXM8L2E+IAogICAgICAgICAgICB8IDxh IGhyZWY9Imh0dHA6Ly9yNS51cy5ybWkueWFob28uY29tL3JtaS9odHRwOi8veWFob28uYnV5 bG9naXRlY2guY29tL2VkaXRhY2NvdW50bG9naW4uYXNwL3JtaXZhcnMlM2Z0YXJnZXQ9X3Rv cCI+ZWRpdCAKICAgICAgICAgICAgYWNjb3VudDwvYT48YnI+CiAgICAgICAgICAgIDxhIGhy ZWY9Imh0dHA6Ly9yNS51cy5ybWkueWFob28uY29tL3JtaS9odHRwOi8veWFob28uYnV5bG9n aXRlY2guY29tL3NlcnZpY2UuYXNwL3JtaXZhcnMlM2Z0YXJnZXQ9X3RvcCI+c3RvcmUgRkFR czwvYT4gCiAgICAgICAgICAgIHwgPGEgaHJlZj0iaHR0cDovL3I1LnVzLnJtaS55YWhvby5j b20vcm1pL2h0dHA6Ly95YWhvby5idXlsb2dpdGVjaC5jb20vY29weXJpZ2h0LmFzcC9ybWl2 YXJzJTNmdGFyZ2V0PV90b3AiPnQmYzwvYT4gfCA8YSBocmVmPSJodHRwOi8vcjUudXMucm1p LnlhaG9vLmNvbS9ybWkvaHR0cDovL3lhaG9vLmJ1eWxvZ2l0ZWNoLmNvbS9jb250YWN0LmFz cC9ybWl2YXJzJTNmdGFyZ2V0PV90b3AiPmNvbnRhY3QgCiAgICAgICAgICAgIHVzPC9hPjwv Zm9udD48L3RkPgogICAgICAgIDwvdHI+CiAgICAgIDwvdGFibGU+CiAgICA8L3RkPgogIDwv dHI+CjwvdGFibGU+Cjx0YWJsZSB3aWR0aD0iNDclIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSIwIiBjZWxscGFkZGluZz0iMCIgaGVpZ2h0PSIxMyI+CiAgPHRyPiAKICAgIDx0ZD4gCiAg ICAgIDxkaXYgYWxpZ249ImNlbnRlciI+PGJyPgogICAgICAgIEdlcm1hbiBDdXN0b21lcnMg LS0gPGEgaHJlZj0iaHR0cDovL3I1LnVzLnJtaS55YWhvby5jb20vcm1pL2h0dHA6Ly95YWhv by5idXlsb2dpdGVjaC5jb20vcmVmZXJyZXIuYXNwL3JtaXZhcnMlM2Z0YXJnZXQ9X3RvcD9y PWV1ci1kZTMiPkNsaWNrIAogICAgICAgIGhlcmU8L2E+ISA8YnI+CiAgICAgIDwvZGl2Pgog ICAgPC90ZD4KICA8L3RyPgo8L3RhYmxlPgo8dGFibGUgd2lkdGg9IjYwMCIgYm9yZGVyPSIw IiBjZWxsc3BhY2luZz0iMiIgY2VsbHBhZGRpbmc9IjUiPgogIDxUUiBBTElHTj0ibGVmdCIg VkFMSUdOPSJ0b3AiPiAKICAgICAgICAgIAogICAgPFREIENPTFNQQU49IjIiIEFMSUdOPSJj ZW50ZXIiIFZBTElHTj0idG9wIj4gCiAgICAgIDxoMj5HZXQgYSBXZWJjYW0gZm9yIFlhaG9v ISBNZXNzZW5nZXIgPGJyPgogICAgICA8L2gyPgogICAgPC9URD4KICAgICAgICA8L3RyPgog ICAgICAgIDx0cj4KICAgICAgICAgIAogICAgPFREIENPTFNQQU49IjIiIFZBTElHTj0idG9w IiBoZWlnaHQ9Ijc2Ij48Rk9OVCBGQUNFPSJWZXJkYW5hLEFyaWFsLEhlbHZldGljYSxTYW4g U2VyaWYiIFNJWkU9IjIiPiAKICAgICAgPHA+Tm93IHlvdXIgZnJpZW5kcyAmIGZhbWlseSBj YW4gYWN0dWFsbHkgU0VFIFlPVSBvbiB0aGUgV2ViIHRocm91Z2ggCiAgICAgICAgICAgICAg WWFob28hIENoYXQsIE1lc3NlbmdlciBhbmQgR2VvQ2l0aWVzISBJdCdzIGEgc25hcCEgQW5k LCBhIGNvb2wgbmV3IHdheSB0byBzdGF5IGNvbm5lY3RlZCEgQnV5IHlvdXIgV2ViY2FtIHRv ZGF5IGFuZCBtZWV0IGZhY2UtdG8tZmFjZSE8L3A+CiAgICAgIDwvZm9udD4gPC9URD4KICAg ICAgICA8L3RyPgogIDx0cj4KICAgIDxURCBXSURUSD0iMjE0IiBWQUxJR049InRvcCI+IAog ICAgICA8cCBhbGlnbj0icmlnaHQiPjxiPjxGT05UIEZBQ0U9IlZlcmRhbmEsQXJpYWwsSGVs dmV0aWNhLFNhbiBTZXJpZiIgU1RZTEU9ImZvbnQtZmFtaWx5OnZlcmRhbmEsIGFyaWFsLCBn ZW5ldmEsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPjxpbWcgc3JjPSJpbWFnZXMv ZXhwcmVzcy5naWYiIHdpZHRoPSIxNDUiIGhlaWdodD0iMTMzIj4gCiAgICAgICAgPC9mb250 PjwvYj48L3A+CiAgICAgIDwvVEQ+CiAgICA8VEQgV0lEVEg9IjM2MCIgVkFMSUdOPSJ0b3Ai PiA8YnI+CiAgICAgIDx0YWJsZSB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxsc3BhY2lu Zz0iMCIgY2VsbHBhZGRpbmc9IjAiPgogICAgICAgIDx0cj4KICAgICAgICAgIDx0ZCB3aWR0 aD0iNTglIj48Yj48Zm9udCBmYWNlPSJWZXJkYW5hLEFyaWFsLEhlbHZldGljYSxTYW4gU2Vy aWYiIHN0eWxlPSJmb250LWZhbWlseTp2ZXJkYW5hLCBhcmlhbCwgZ2VuZXZhLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDEycHQ7Ij5RdWlja0Nhba4gCiAgICAgICAgICAgIEV4cHJlc3M8 L2ZvbnQ+PC9iPjwvdGQ+CiAgICAgICAgICA8dGQgd2lkdGg9IjQyJSI+Jm5ic3A7PC90ZD4K ICAgICAgICA8L3RyPgogICAgICAgIDx0cj4gCiAgICAgICAgICA8dGQgd2lkdGg9IjU4JSI+ PGI+PGZvbnQgZmFjZT0iVmVyZGFuYSxBcmlhbCxIZWx2ZXRpY2EsU2FuIFNlcmlmIiBzaXpl PSIyIiBjb2xvcj0iI0ZGMzMzMyI+PGEgaHJlZj0iaHR0cDovL3I1LnVzLnJtaS55YWhvby5j b20vcm1pL2h0dHA6Ly95YWhvby5idXlsb2dpdGVjaC5jb20vcmVmZXJyZXIuYXNwL3JtaXZh cnMlM2Z0YXJnZXQ9X3RvcD9yPWNhbS15MTQiPjxmb250IGNvbG9yPSIjRkYzMzMzIj5VU0Qg CiAgICAgICAgICAgIDQ5Ljk1PC9mb250PjwvYT48L2ZvbnQ+PC9iPjwvdGQ+CiAgICAgICAg ICA8dGQgd2lkdGg9IjQyJSI+IDxhIGhyZWY9Imh0dHA6Ly9yNS51cy5ybWkueWFob28uY29t L3JtaS9odHRwOi8veWFob28uYnV5bG9naXRlY2guY29tL3JlZmVycmVyLmFzcC9ybWl2YXJz JTNmdGFyZ2V0PV90b3A/cj1jYW0teTE0Ij48aW1nIHNyYz0iaW1hZ2VzL2J1eW5vdy5naWYi IHdpZHRoPSI4OCIgaGVpZ2h0PSIyMyIgYm9yZGVyPSIwIiBhbHQ9IkJ1eSBOb3chIj48L2E+ PC90ZD4KICAgICAgICA8L3RyPgogICAgICA8L3RhYmxlPgogICAgICA8cD5IYXZlIGZ1biB3 aXRoIGluc3RhbnQgdmlkZW8gbWVzc2FnaW5nIE9SIGVtYWlsIHN0aWxscyBhbmQgdmlkZW8g aW4gb25lIAogICAgICAgIGNsaWNrISBJdCdzIGEgc2ltcGxlIHdheSB0byBnZXQgY2xvc2Vy ISA8YSBocmVmPSJqYXZhc2NyaXB0OnBvcFVwICggJ2NhbWVyYV9leHByZXNzLmh0bWwnICkg IDsKIj5tb3JlIAogICAgICAgIGluZm88L2E+PC9wPgogICAgICAgICAgICAgIDwvVEQ+CiAg PC90cj4KPC90YWJsZT4KICAKPHRhYmxlIHdpZHRoPSIzNSUiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4KICA8dHI+CiAgICA8dGQ+PGltZyBzcmM9Imlt YWdlcy9uYXYyL3NwYWNlci5naWYiIHdpZHRoPSI1NCIgaGVpZ2h0PSIxNDQiPjwvdGQ+CiAg ICA8dGQ+PGEgaHJlZj0iaHR0cDovL3I1LnVzLnJtaS55YWhvby5jb20vcm1pL2h0dHA6Ly93 d3cubG9naXRlY2guY29tL3lhaG9vL2NhbWVyYS5odG1sL3JtaXZhcnMlM2Z0YXJnZXQ9X3Rv cCIgb25tb3VzZW91dD0iTU1fc3dhcEltZ1Jlc3RvcmUoKSIgb25tb3VzZW92ZXI9Ik1NX3N3 YXBJbWFnZSgnY2FtZXJhcycsJycsJ2ltYWdlcy9uYXYyL2NhbWVyYXNfb24uZ2lmJywxKSI+ PGltZyBuYW1lPSJjYW1lcmFzIiBib3JkZXI9IjAiIHNyYz0iaW1hZ2VzL25hdjIvY2FtZXJh c19vZmYuZ2lmIiB3aWR0aD0iNzMiIGhlaWdodD0iMTQ0Ij48L2E+PC90ZD4KICAgIDx0ZD48 YSBocmVmPSJodHRwOi8vcjUudXMucm1pLnlhaG9vLmNvbS9ybWkvaHR0cDovL3d3dy5sb2dp dGVjaC5jb20veWFob28vbWljZV90Yi5odG1sL3JtaXZhcnMlM2Z0YXJnZXQ9X3RvcCIgb25t b3VzZW91dD0iTU1fc3dhcEltZ1Jlc3RvcmUoKSIgb25tb3VzZW92ZXI9Ik1NX3N3YXBJbWFn ZSgnbWljZScsJycsJ2ltYWdlcy9uYXYyL21pY2Vfb24uZ2lmJywxKSI+PGltZyBuYW1lPSJt aWNlIiBib3JkZXI9IjAiIHNyYz0iaW1hZ2VzL25hdjIvbWljZV9vZmYuZ2lmIiB3aWR0aD0i NzQiIGhlaWdodD0iMTQ0Ij48L2E+PC90ZD4KICAgIDx0ZD48YSBocmVmPSJodHRwOi8vcjUu dXMucm1pLnlhaG9vLmNvbS9ybWkvaHR0cDovL3d3dy5sb2dpdGVjaC5jb20veWFob28vbWlj ZV90Yi5odG1sL3JtaXZhcnMlM2Z0YXJnZXQ9X3RvcCN0YiIgb25tb3VzZW91dD0iTU1fc3dh cEltZ1Jlc3RvcmUoKSIgb25tb3VzZW92ZXI9Ik1NX3N3YXBJbWFnZSgndHJhY2tiYWxscycs JycsJ2ltYWdlcy9uYXYyL3RyYWNrYmFsbHNfb24uZ2lmJywxKSI+PGltZyBuYW1lPSJ0cmFj a2JhbGxzIiBib3JkZXI9IjAiIHNyYz0iaW1hZ2VzL25hdjIvdHJhY2tiYWxsc19vZmYuZ2lm IiB3aWR0aD0iMTE3IiBoZWlnaHQ9IjE0NCI+PC9hPjwvdGQ+CiAgICA8dGQ+PGEgaHJlZj0i aHR0cDovL3I1LnVzLnJtaS55YWhvby5jb20vcm1pL2h0dHA6Ly93d3cubG9naXRlY2guY29t L3lhaG9vL2t5YmRfc3Brci5odG1sL3JtaXZhcnMlM2Z0YXJnZXQ9X3RvcCIgb25tb3VzZW91 dD0iTU1fc3dhcEltZ1Jlc3RvcmUoKSIgb25tb3VzZW92ZXI9Ik1NX3N3YXBJbWFnZSgna2V5 Ym9hcmRzJywnJywnaW1hZ2VzL25hdjIva2V5Ym9hcmRzX29uLmdpZicsMSkiPjxpbWcgbmFt ZT0ia2V5Ym9hcmRzIiBib3JkZXI9IjAiIHNyYz0iaW1hZ2VzL25hdjIva2V5Ym9hcmRzX29m Zi5naWYiIHdpZHRoPSIxMjciIGhlaWdodD0iMTQ0Ij48L2E+PC90ZD4KICAgIDx0ZD48YSBo cmVmPSJodHRwOi8vcjUudXMucm1pLnlhaG9vLmNvbS9ybWkvaHR0cDovL3d3dy5sb2dpdGVj aC5jb20veWFob28va3liZF9zcGtyLmh0bWwvcm1pdmFycyUzZnRhcmdldD1fdG9wI3Nwa3Ii IG9ubW91c2VvdXQ9Ik1NX3N3YXBJbWdSZXN0b3JlKCkiIG9ubW91c2VvdmVyPSJNTV9zd2Fw SW1hZ2UoJ2F1ZGlvJywnJywnaW1hZ2VzL25hdjIvYXVkaW9fb24uZ2lmJywxKSI+PGltZyBu YW1lPSJhdWRpbyIgYm9yZGVyPSIwIiBzcmM9ImltYWdlcy9uYXYyL2F1ZGlvX29mZi5naWYi IHdpZHRoPSIxMTQiIGhlaWdodD0iMTQ0Ij48L2E+PC90ZD4KICA8L3RyPgo8L3RhYmxlPgo8 VEFCTEUgV0lEVEg9IjYwMCIgQUxJR049ImxlZnQiPjx0cj4KICAgIDx0ZD48aW1nIHNyYz0i aW1hZ2VzL3doaXRlX3NwYWNlci5naWYiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIGJvcmRlcj0i MCIgYWx0PSIiPjwvdGQ+CiAgPC90cj4KCTxUUj4KICAgIDxURCBBTElHTj0iY2VudGVyIj4g CiAgICAgIDxwIGFsaWduPSJsZWZ0Ij4mbmJzcDs8L3A+CiAgICAgIDxwPjxGT05UIFNUWUxF PSJmb250LXNpemUgOiA4cHQiPjxhIGhyZWY9Imh0dHA6Ly9yNS51cy5ybWkueWFob28uY29t L3JtaS9odHRwOi8veWFob28uYnV5bG9naXRlY2guY29tL3NlcnZpY2UuYXNwL3JtaXZhcnMl M2Z0YXJnZXQ9X3RvcD9zZWN0aW9uPTEiPllvdXIgCiAgICAgICAgUHJpdmFjeSAmYW1wOyBT ZWN1cml0eTwvYT4gfCA8YSBocmVmPSJodHRwOi8vcjUudXMucm1pLnlhaG9vLmNvbS9ybWkv aHR0cDovL3lhaG9vLmJ1eWxvZ2l0ZWNoLmNvbS9jb3B5cmlnaHQuYXNwL3JtaXZhcnMlM2Z0 YXJnZXQ9X3RvcCIgdGFyZ2V0PSJfbmV3Ij4gCiAgICAgICAgVGVybXMgb2YgVXNlPC9hPjxC Uj4KICAgICAgICBDb3B5cmlnaHQgJmNvcHk7IDIwMDEgTG9naXRlY2guIEFsbCByaWdodHMg cmVzZXJ2ZWQuPC9GT05UPjwvcD4KICAgICAgPC9URD48L1RSPjwvVEFCTEU+Cgo8c2NyaXB0 IGxhbmd1YWdlPSJKYXZhU2NyaXB0Ij4KPCEtLQp2YXIgd3RsX1NJRCAgPSAiMDA1LTAxLTgt MTUtMjMzODYwLTk3MTE5IiAgIDsKdmFyIFcgID0gInRhZ3Zlcj0zJlNpdGVJZD05NzExOSZT aWQ9MDA1LTAxLTgtMTUtMjMzODYwLTk3MTE5JlR6PS04MDAmZmlyc3R3a2RheT1zdW5kYXkm RWRpdGlvbj1lY29tbWVyY2UiICAgOwoKLy8tLT4KPC9zY3JpcHQ+CjxzY3JpcHQgbGFuZ3Vh Z2U9IkphdmFTY3JpcHQiIHNyYz0iaHR0cDovL2MudXMucm1pLnlhaG9vLmNvbS9ybWkvaHR0 cDovL2pzLnVzLnJtaS55YWhvby5jb20vcm1pL2h0dHA6Ly9jcnMuYWthbWFpLmNvbS9jcnMv Tktadk5pYVhkbXVOMjJIU2ZRd1NjLmpzL3JtaWpzIj4KCjwvU0NSSVBUPgo8Tk9TQ1JJUFQ+ CjxJTUcgQk9SREVSPSIwIiBXSURUSD0iMSIgSEVJR0hUPSIxIiBTUkM9Imh0dHA6Ly9zdGF0 c2Uud2VidHJlbmRzbGl2ZS5jb20vMDA1LTAxLTgtMTUtMjMzODYwLTk3MTE5L2J1dHRvbjMu YXNwP3RhZ3Zlcj0zJlNpdGVJZD05NzExOSZTaWQ9MDA1LTAxLTgtMTUtMjMzODYwLTk3MTE5 JlR6PS04MDAmZmlyc3R3a2RheT1zdW5kYXkmRWRpdGlvbj1lY29tbWVyY2UmdGl0bGU9Tk8l MjBTQ1JJUFQmdXJsPWh0dHA6Ly9ub3NjcmlwdCZqYXZhT0s9Tm8mIj4KPC9OT1NDUklQVD4K CjwvYm9keT4KPC9odG1sPgo8c2NyaXB0IGxhbmd1YWdlPSJqYXZhc2NyaXB0Ij4KPCEtLQpp ZiAoIHR5cGVvZiBybWlfeGxhdGVBbGxGaW5hbGx5ID09ICJmdW5jdGlvbiIgKSBybWlfeGxh dGVBbGxGaW5hbGx5KCk7CmlmICggdHlwZW9mIHJtaV9oYW5kbGVEaHRtbCA9PSAiZnVuY3Rp b24iICkgcm1pX2hhbmRsZURodG1sKDIpOwppZiAoIHR5cGVvZiBybWlfdGFnUGFzc3dvcmRz ID09ICJmdW5jdGlvbiIgKSBybWlfdGFnUGFzc3dvcmRzKCk7CmlmICggdHlwZW9mIHJtaV90 cmFjayA9PSAiZnVuY3Rpb24iICkgcm1pX3RyYWNrKCk7Ci8vIC0tPgo8L3NjcmlwdD4KIAoK PHNjcmlwdCBsYW5ndWFnZT0iSmF2YVNjcmlwdCI+CjwhLS0Kcm1pX3ZlcigiMjU4NjgiLCJx YVdhbGxldFVybHMiKTsKLy8gLS0+Cjwvc2NyaXB0PgoKPHNjcmlwdCBsYW5ndWFnZT0iamF2 YXNjcmlwdCI+CjwhLS0KCgpybWlfd2FsbGV0UWEoKTsKLy8gLS0+Cjwvc2NyaXB0Pg=9 --R0196h4j5KK2761n7YbyQc9Xg-- From owner-ipsec@lists.tislabs.com Wed Apr 24 04:41:24 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 g3OBfNa16596; Wed, 24 Apr 2002 04:41:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA17211 Wed, 24 Apr 2002 06:33:50 -0400 (EDT) From: juha.ollila@nokia.com 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="iso-8859-1" Subject: Status of SCTP Date: Wed, 24 Apr 2002 13:45:24 +0300 Message-ID: Thread-Topic: Status of SCTP Thread-Index: AcHrfSOUojRSIWioStGTv1KG4e8bLQ== To: X-OriginalArrivalTime: 24 Apr 2002 10:45:24.0762 (UTC) FILETIME=[23D3FFA0:01C1EB7D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id GAA17208 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello! What is the status of draft-ietf-ipsec-sctp? Will it be submitted as Draft Standard in October? Is it planned to add support for SCTP in IKEv2 or JFK? Best Regards, Juha Ollila From owner-ipsec@lists.tislabs.com Wed Apr 24 08:19: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 g3OFJba11308; Wed, 24 Apr 2002 08:19:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18287 Wed, 24 Apr 2002 10:28:09 -0400 (EDT) Message-ID: <3CC6C3C2.204326CF@torrentnet.com> Date: Wed, 24 Apr 2002 10:40:02 -0400 From: James Comen X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 2.2.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipseclist Subject: Test tools for IKE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, We're working on an IKE implementation and trying to do interoperability testing. Does anyone know of any test tools which we can test our IKE implementation against? It would be great if we could find a tool which would allow us to monitor the skeyid{_*} creation process on the remote side to compare against our side. Does such a tool exist? How does one verify the correctness of their skeyid's? (other than attempting an IKE negotiation with an off the shelf product) Thanks Jim -- Jim Comen jcomen@torrentnet.com Ericsson IP Infrastructure Voice (919) 472 - 9932 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 Raleigh, NC 27606 From owner-ipsec@lists.tislabs.com Wed Apr 24 08:52:03 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 g3OFq3a12229; Wed, 24 Apr 2002 08:52:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18465 Wed, 24 Apr 2002 11:02:25 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Tue Apr 23 19:54:07 2002 From: phoenixcry@sina.com Message-Id: <200204240557.WAA18964@pubms.pku.edu.cn> Date: Tue, 23 Apr 2002 23:5:9 +0800 To: "ipsec@lists.tislabs.com" Subject: Can the two entities have multiple ISAKMP SAs? X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In RFC2408, it says: 'Two entities (e.g. ISAKMP servers) can negotiate (and have active) multiple ISAKMP SAs.' If the two entities can have multiple ISAKMP SAs, Which field of the packet negociating Phrase II SAs indicate the ISAKMP SA used to encode the packet? Thanks for your answer. From owner-ipsec@lists.tislabs.com Wed Apr 24 08:54: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 g3OFsqa12683; Wed, 24 Apr 2002 08:54:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18464 Wed, 24 Apr 2002 11:02:25 -0400 (EDT) Mime-Version: 1.0 X-Sender: listmast@mail.gw.tislabs.com (Unverified) Message-Id: Date: Wed, 24 Apr 2002 11:09:54 -0400 To: ipsec@lists.tislabs.com From: Listmaster Subject: Viruses on lists Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We have just finished putting into place some measures to keep the recent virus attacks from continuing. We are monitoring the lists closely to see if they work and don't affect proper use of the lists. -NAILabs' Majordomo Listmaster From owner-ipsec@lists.tislabs.com Wed Apr 24 09:15: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 g3OGFAa15566; Wed, 24 Apr 2002 09:15:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18521 Wed, 24 Apr 2002 11:24:35 -0400 (EDT) Message-ID: <001401c1eba5$da214830$0a3193cc@verisign.com> From: "Jedi" To: References: Subject: Dead Peer Detection (DPD) Date: Wed, 24 Apr 2002 11:36:49 -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 X-OriginalArrivalTime: 24 Apr 2002 15:36:04.0791 (UTC) FILETIME=[BEE53C70:01C1EBA5] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can anyone tell me what is the RFC for DPD, if there is one? Thanx in advance. From owner-ipsec@lists.tislabs.com Wed Apr 24 11:04: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 g3OI4Xa21070; Wed, 24 Apr 2002 11:04:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18804 Wed, 24 Apr 2002 13:20:29 -0400 (EDT) Message-Id: <4.3.1.0.20020424123056.0317def8@email.quarrytech.com> X-Sender: ccook@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 24 Apr 2002 12:34:34 -0400 To: ipsec@lists.tislabs.com From: "Christopher R. Cook" Subject: IPsec Monitoring Mib Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Any status on Tim Jenkins's IPsec Tunnel monitoring Mib ... Initial draft was to expire April 4, 2002 .... Are there any current WG's addressing monitoring for IPsec... Thanks From owner-ipsec@lists.tislabs.com Wed Apr 24 11:05: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 g3OI5Ra21096; Wed, 24 Apr 2002 11:05:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18803 Wed, 24 Apr 2002 13:20:29 -0400 (EDT) From: phoenixcry@sina.com Message-Id: <200204250533.WAA15239@pubms.pku.edu.cn> Date: Wed, 24 Apr 2002 22:41:10 +0800 To: "ipsec@lists.tislabs.com" Subject: Re: Re: Can the two entities have multiple ISAKMP SAs? X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can you show me the detail of the using cookie to indicate ISAKMP SA? I mean:two entities (e.g. ISAKMP servers) can negotiate (and have active) multiple ISAKMP SAs,so the message used for negotiating SAs in Prase 2 should be encoded by one of ~~~~~~~ ISAKMP SAs. I know in phrase 1 it uses cookies to indicate which ISAKMP SA is negotiating now. Does the cookie in Phrase 2 indicate the selected ISAKMP SA? If it is,do you mean that we can use some bits of the cookie in Phrase 2 to select ISAKMP SA? thanks /phoenixcry >The cookie. > >rwt >--- >Robert Tashjian >rwt@netopia.com >----- Original Message ----- >From: >To: >Sent: Tuesday, April 23, 2002 12:00 AM >Subject: Can the two entities have multiple ISAKMP SAs? > > >> In RFC2408, it says: 'Two entities (e.g. ISAKMP servers) can >> negotiate (and have active) multiple ISAKMP SAs.' >> If the two entities can have multiple ISAKMP SAs, >> Which field of the packet negociating Phrase II SAs indicate >> the ISAKMP SA used to encode the packet? >> Thanks for your answer. >> > > > >. From owner-ipsec@lists.tislabs.com Wed Apr 24 11:33: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 g3OIXJa22619; Wed, 24 Apr 2002 11:33:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18863 Wed, 24 Apr 2002 13:52:45 -0400 (EDT) Message-ID: <80B684C5E29FD211AA8000A0C9CDD9190C752F11@il0015exch005u.ih.lucent.com> From: "Kopeikin, Roy A (Roy)" To: James Comen , ipseclist Subject: RE: Test tools for IKE Date: Wed, 24 Apr 2002 13:04:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Have you looked at www.spirent.com ? or try 800-927-2660 and ask for VPN test Overview. there might be others out there with VPN testers also. Roy Kopeikin -----Original Message----- From: James Comen [mailto:jcomen@torrentnet.com] Sent: Wednesday, April 24, 2002 9:40 AM To: ipseclist Subject: Test tools for IKE Hi, We're working on an IKE implementation and trying to do interoperability testing. Does anyone know of any test tools which we can test our IKE implementation against? It would be great if we could find a tool which would allow us to monitor the skeyid{_*} creation process on the remote side to compare against our side. Does such a tool exist? How does one verify the correctness of their skeyid's? (other than attempting an IKE negotiation with an off the shelf product) Thanks Jim -- Jim Comen jcomen@torrentnet.com Ericsson IP Infrastructure Voice (919) 472 - 9932 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 Raleigh, NC 27606 From owner-ipsec@lists.tislabs.com Wed Apr 24 11:41: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 g3OIfpa22785; Wed, 24 Apr 2002 11:41:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18910 Wed, 24 Apr 2002 13:59:50 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15558.62812.263836.248212@ryijy.hel.fi.ssh.com> Date: Wed, 24 Apr 2002 21:11:40 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Small clarification to the draft-ietf-ipsec-nat-t-ike-02.txt X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is small typo in the draft-ietf-ipsec-nat-t-ike-02.txt. The Vendor ID hex and the string specified in the draft-ietf-ipsec-nat-t-ike-02.txt does not match exactly. This is because when I calculated the md5 hash of the string I accidently appended newline character to the string. This means that if you are using the md5 of the string use "draft-ietf-ipsec-nat-t-ike-02\n". This will give out the hex string given in the document. If you are using the hex string given in the document there is no need to do anything. As this string and the hex value of it will change when the document goes out as an RFC, I don't think we need to issue new draft just to fix that typo. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Apr 24 11:51:15 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 g3OIpEa22913; Wed, 24 Apr 2002 11:51:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18946 Wed, 24 Apr 2002 14:11:54 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Test tools for IKE Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EBB7.BA88EF7A" Date: Wed, 24 Apr 2002 13:44:48 -0400 Message-ID: Thread-Topic: Test tools for IKE Thread-Index: AcHrsCIRjEO79gomRqKgySbDG7XkxgABBnyA From: "Peter Gingras" To: "James Comen" , "ipseclist" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1EBB7.BA88EF7A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Check out the "Researched National Institute of Standards and Technology" website for IPsec interoperability test tools and platform support. =20 http://csrc.nist.gov/ipsec/=20 Contact NIST and requested copies of the following Linux code: - Cerberus - adds IP communications security to the system=20 - PlutoPlus - conducts secret key negotiations and management Hopefully you will have better luck than I did. The code is currently not available via WWW download so you must request a distribution of the NIST IPsec Reference Implementation (Cerberus) and IKE Reference Implementation (PlutoPlus) on a floppy. I put my request in two months age; I received confirmation of my request but have yet to receive the software. Peter ------------------------------------------------------------------------ ------------------------ Peter Gingras pgingras@avianwireless.com Avian Communications 67 Forest St., Marlborough, MA (v) 508-597-0674 ------------------------------------------------------------------------ ------------------------ -----Original Message----- From: James Comen [mailto:jcomen@torrentnet.com]=20 Sent: Wednesday, April 24, 2002 10:40 AM To: ipseclist Subject: Test tools for IKE Hi, We're working on an IKE implementation and trying to do interoperability testing. Does anyone know of any test tools which we can test our IKE implementation against? It would be great if we could find a tool which would allow us to monitor the skeyid{_*} creation process on the remote side to compare against our side. Does such a tool exist? How does one verify the correctness of their skeyid's? (other than attempting an IKE negotiation with an off the shelf product) Thanks Jim --=20 Jim Comen jcomen@torrentnet.com Ericsson IP Infrastructure Voice (919) 472 - 9932 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 Raleigh, NC 27606 ------_=_NextPart_001_01C1EBB7.BA88EF7A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Test tools for IKE

Check out the "Researched National Institute of = Standards and Technology" website for IPsec interoperability test = tools and platform support.   

http://csrc.nist.gov/ipsec/

Contact NIST and requested copies of the following Linux code:
- Cerberus - adds IP communications security to the system
- PlutoPlus - conducts secret key negotiations and management

Hopefully you will have better luck than I did.  The code is = currently not available via WWW download so you must request a = distribution of the NIST IPsec Reference Implementation (Cerberus) and = IKE Reference Implementation (PlutoPlus) on a floppy.  I put my = request in two months age; I received confirmation of my request but = have yet to receive the software.

Peter

-------------------------------------------------------------------------= -----------------------
Peter Gingras           =         = pgingras@avianwireless.com
Avian Communications    =         67 Forest St., Marlborough, = MA
(v) 508-597-0674
-------------------------------------------------------------------------= -----------------------

 -----Original Message-----
From:   James Comen [mailto:jcomen@torrentnet.com] Sent:   Wednesday, April 24, 2002 10:40 AM
To:     ipseclist
Subject:        Test tools for = IKE

Hi,
We're working on an IKE implementation and trying to do = interoperability
testing.
Does anyone know of any test tools which we can test our IKE
implementation against?

It would be great if we could find a tool which would allow us to
monitor the skeyid{_*}
creation process on the remote side to compare against our side.

Does such a tool exist?
How does one verify the correctness of their skeyid's? (other than
attempting an IKE negotiation
with an off the shelf product)

Thanks
Jim

--
Jim = Comen           &n= bsp;           &nb= sp;   jcomen@torrentnet.com
Ericsson IP = Infrastructure          = Voice (919) 472 - 9932
920 Main Campus Drive, Suite 544    Fax   (919) = 472 - 9999
Raleigh, NC 27606

------_=_NextPart_001_01C1EBB7.BA88EF7A-- From owner-ipsec@lists.tislabs.com Wed Apr 24 13:37: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 g3OKbVa25055; Wed, 24 Apr 2002 13:37:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19341 Wed, 24 Apr 2002 15:43:42 -0400 (EDT) Message-ID: <3CC70D8D.9057C25F@verio.net> Date: Wed, 24 Apr 2002 13:54:53 -0600 From: "Chuck Sellers" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Comen CC: ipseclist Subject: Re: Test tools for IKE References: <3CC6C3C2.204326CF@torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is a test tool I have used in the past. The site is also back up. http://ipsec-wit.antd.nist.gov/ Chuck Sellers Manager, Product Engineering Global IPVPN James Comen wrote: > > Hi, > We're working on an IKE implementation and trying to do interoperability > testing. > Does anyone know of any test tools which we can test our IKE > implementation against? > > It would be great if we could find a tool which would allow us to > monitor the skeyid{_*} > creation process on the remote side to compare against our side. > > Does such a tool exist? > How does one verify the correctness of their skeyid's? (other than > attempting an IKE negotiation > with an off the shelf product) > > Thanks > Jim > > -- > Jim Comen jcomen@torrentnet.com > Ericsson IP Infrastructure Voice (919) 472 - 9932 > 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 > Raleigh, NC 27606 From owner-ipsec@lists.tislabs.com Thu Apr 25 01:47: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 g3P8lba06459; Thu, 25 Apr 2002 01:47:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA20886 Thu, 25 Apr 2002 03:44:01 -0400 (EDT) Message-ID: From: Goeman Stefan To: "'ipsec@lists.tislabs.com'" Subject: IPsec and Java Date: Thu, 25 Apr 2002 09:51:41 +0200 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 Hello, Does anybody know if there exists a Java IPsec implementation? (And if it is open source/) Greetings, Stefan. From owner-ipsec@lists.tislabs.com Thu Apr 25 08:15: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 g3PFFda27731; Thu, 25 Apr 2002 08:15:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21765 Thu, 25 Apr 2002 09:28:57 -0400 (EDT) Message-ID: <231417CB271FD61197020002A593077F2E0905@CAT01S2C> From: Tim Jenkins To: "'Christopher R. Cook'" , "'ipsec@lists.tislabs.com'" Subject: RE: IPsec Monitoring Mib Date: Thu, 25 Apr 2002 09:13:31 -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 Here's my view. Some time ago, Ted asked if there were any deployments/interest/implementations of the series of MIB document written by John Shriver and me, in an attempt to take them to last call. The only response I recall was from the authors of another MIB. This lead to a debate/discussion where it was suggested that that MIB replace the series first mentioned. Nothing was resolved. The bottom line is that there was little response on the mailing list, even though I have received numerous private emails; none of those people posted on the list to say that they were looking at/implementating/considering or whatever the MIB. I have also sent Ted emails asking him what his opinion of the status is, and I've heard nothing back. As far as changes to the documents themselves go, they are ready for last call. Tim > -----Original Message----- > From: Christopher R. Cook [mailto:ccook@quarrytech.com] > Sent: Wednesday, April 24, 2002 12:35 PM > To: ipsec@lists.tislabs.com > Subject: IPsec Monitoring Mib > > > Any status on Tim Jenkins's IPsec Tunnel monitoring Mib ... > > Initial draft was to expire April 4, 2002 .... > > Are there any current WG's addressing monitoring for IPsec... > > Thanks > From owner-ipsec@lists.tislabs.com Thu Apr 25 08:23: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 g3PFMxa27941; Thu, 25 Apr 2002 08:22:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21833 Thu, 25 Apr 2002 09:54:16 -0400 (EDT) Message-Id: <200204251405.g3PE5oVm018169@kebe.east.sun.com> Subject: Re: IPsec and Java In-Reply-To: from Goeman Stefan at "Apr 25, 2002 09:51:41 am" To: Goeman Stefan Date: Thu, 25 Apr 2002 10:05:50 -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 > Does anybody know if there exists a Java IPsec implementation? > (And if it is open source/) Not that I'm aware of... I'm assuming you mean a Java implementation of the IPsec protocols, plus a policy engine of some kind. I am not aware of any such implementation, but don't let that sun.com address fool you - I'm no Java wizard. There may be one out there, I'm not just aware of any. Or do you mean something like extensions to Java sockets so that they can protect network traffic with IPsec? I am also not aware of any such implementation, but I am _very_ interested in at least getting Solaris-style IP_SEC_OPT functionality out to Java, if not something (much) better. Dan From owner-ipsec@lists.tislabs.com Thu Apr 25 11:12: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 g3PIC5a04914; Thu, 25 Apr 2002 11:12:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22228 Thu, 25 Apr 2002 13:16:49 -0400 (EDT) Date: Thu, 25 Apr 2002 10:28:31 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: Goeman Stefan cc: "'ipsec@lists.tislabs.com'" Subject: Re: IPsec and Java In-Reply-To: <200204251405.g3PE5oVm018169@kebe.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think Java runs at the application layer, and you can write applications or protocols sometimes in or mostly above layer 4 using Java. It probably won't be pretty to implement IPsec (which is somewhat in and all around layer 3, the IP layer,) using Java. I suppose you could do funky things with raw sockets, static routing, loopback interfaces and somehow process all IP packets that are going out and coming in. It should be straight forward to implement IKE in Java though, because IKE runs over UDP. Ofcourse, my above assumptions are based on my understanding of "Java" as it existed some years ago, and I am not sure if the fundamental layering of "Java" changed since then. chinna On Thu, 25 Apr 2002, Dan McDonald wrote: > > Does anybody know if there exists a Java IPsec implementation? > > (And if it is open source/) > > Not that I'm aware of... > > I'm assuming you mean a Java implementation of the IPsec protocols, plus a > policy engine of some kind. I am not aware of any such implementation, but > don't let that sun.com address fool you - I'm no Java wizard. There may be > one out there, I'm not just aware of any. > > Or do you mean something like extensions to Java sockets so that they can > protect network traffic with IPsec? I am also not aware of any such > implementation, but I am _very_ interested in at least getting Solaris-style > IP_SEC_OPT functionality out to Java, if not something (much) better. > > Dan > _____ chinna narasimha reddy pellacuru From owner-ipsec@lists.tislabs.com Thu Apr 25 12:16:56 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 g3PJGta06332; Thu, 25 Apr 2002 12:16:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22382 Thu, 25 Apr 2002 14:28:18 -0400 (EDT) Message-Id: <5.1.0.14.2.20020425142046.031dfe20@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 14:40:10 -0400 To: ipsec@lists.tislabs.com From: "Housley, Russ" Subject: Let's pick an AES mode Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All: I think that we should pick an AES mode. As everyone probably knows, I am an advocate for AES-CTR, but I know that there are also advocates for AES-CBC. There may be advocates for other modes. Russ From owner-ipsec@lists.tislabs.com Thu Apr 25 12:17: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 g3PJH1a06347; Thu, 25 Apr 2002 12:17:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22390 Thu, 25 Apr 2002 14:30:18 -0400 (EDT) From: "Casey Carr" To: "Tim Jenkins" , "'Christopher R. Cook'" , Subject: RE: IPsec Monitoring Mib Date: Thu, 25 Apr 2002 14:40:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <231417CB271FD61197020002A593077F2E0905@CAT01S2C> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We are interested in implementing an IPSec monitoring MIB but without one being on standards track it is hard to justify the effort. We were waiting to see what came out of the disagreement on how to move forward because of the competing MIBs. Has anyone implemented any of these MIBs? If so, how much of it? Casey -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tim Jenkins Sent: Thursday, April 25, 2002 9:14 AM To: 'Christopher R. Cook'; 'ipsec@lists.tislabs.com' Subject: RE: IPsec Monitoring Mib Here's my view. Some time ago, Ted asked if there were any deployments/interest/implementations of the series of MIB document written by John Shriver and me, in an attempt to take them to last call. The only response I recall was from the authors of another MIB. This lead to a debate/discussion where it was suggested that that MIB replace the series first mentioned. Nothing was resolved. The bottom line is that there was little response on the mailing list, even though I have received numerous private emails; none of those people posted on the list to say that they were looking at/implementating/considering or whatever the MIB. I have also sent Ted emails asking him what his opinion of the status is, and I've heard nothing back. As far as changes to the documents themselves go, they are ready for last call. Tim > -----Original Message----- > From: Christopher R. Cook [mailto:ccook@quarrytech.com] > Sent: Wednesday, April 24, 2002 12:35 PM > To: ipsec@lists.tislabs.com > Subject: IPsec Monitoring Mib > > > Any status on Tim Jenkins's IPsec Tunnel monitoring Mib ... > > Initial draft was to expire April 4, 2002 .... > > Are there any current WG's addressing monitoring for IPsec... > > Thanks > From owner-ipsec@lists.tislabs.com Thu Apr 25 12:17: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 g3PJH1a06346; Thu, 25 Apr 2002 12:17:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22381 Thu, 25 Apr 2002 14:28:17 -0400 (EDT) From: rks@cisco.com Date: Thu, 25 Apr 2002 11:39:58 -0700 (PDT) To: Goeman Stefan cc: "'ipsec@lists.tislabs.com'" Subject: Re: IPsec and Java In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are two implementations of IPsec based on Conduits using Java http://www.tml.hut.fi/Tutkimus/IPSEC/toc.html and at http://www.glue.ch/~hueni/conduits/SIGBEER-mai.html. A year ago, I came across an interesting description of a similar implementation done by University of Tokyo. Unfortunately I do not have the link handy. Rk x77309 On Thu, 25 Apr 2002, Goeman Stefan wrote: > Hello, > > Does anybody know if there exists a Java IPsec implementation? > (And if it is open source/) > > > Greetings, > > Stefan. > > From owner-ipsec@lists.tislabs.com Thu Apr 25 22:03: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 g3Q53qa17827; Thu, 25 Apr 2002 22:03:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA23483 Fri, 26 Apr 2002 00:03:26 -0400 (EDT) From: "Amit Chitale" To: Subject: RE: IPsec Monitoring Mib Date: Fri, 26 Apr 2002 09:45:26 +0530 Message-ID: <000801c1ecd8$ff7d3010$2864a8c0@apachi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with the view that Casey has shared on the list. We have only identified the MIB variables we want to attempt but haven't moved on to the implementation as yet. I hope with Tim's reply interested people might just reply. With Regards, Amit Chitale -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Casey Carr Sent: Friday, April 26, 2002 12:11 AM To: Tim Jenkins; 'Christopher R. Cook'; ipsec@lists.tislabs.com Subject: RE: IPsec Monitoring Mib We are interested in implementing an IPSec monitoring MIB but without one being on standards track it is hard to justify the effort. We were waiting to see what came out of the disagreement on how to move forward because of the competing MIBs. Has anyone implemented any of these MIBs? If so, how much of it? Casey -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tim Jenkins Sent: Thursday, April 25, 2002 9:14 AM To: 'Christopher R. Cook'; 'ipsec@lists.tislabs.com' Subject: RE: IPsec Monitoring Mib Here's my view. Some time ago, Ted asked if there were any deployments/interest/implementations of the series of MIB document written by John Shriver and me, in an attempt to take them to last call. The only response I recall was from the authors of another MIB. This lead to a debate/discussion where it was suggested that that MIB replace the series first mentioned. Nothing was resolved. The bottom line is that there was little response on the mailing list, even though I have received numerous private emails; none of those people posted on the list to say that they were looking at/implementating/considering or whatever the MIB. I have also sent Ted emails asking him what his opinion of the status is, and I've heard nothing back. As far as changes to the documents themselves go, they are ready for last call. Tim > -----Original Message----- > From: Christopher R. Cook [mailto:ccook@quarrytech.com] > Sent: Wednesday, April 24, 2002 12:35 PM > To: ipsec@lists.tislabs.com > Subject: IPsec Monitoring Mib > > > Any status on Tim Jenkins's IPsec Tunnel monitoring Mib ... > > Initial draft was to expire April 4, 2002 .... > > Are there any current WG's addressing monitoring for IPsec... > > Thanks > From owner-ipsec@lists.tislabs.com Fri Apr 26 07:17: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 g3QEHWa04708; Fri, 26 Apr 2002 07:17:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24888 Fri, 26 Apr 2002 09:29:30 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Thu Apr 25 17:39:44 2002 Message-ID: <231417CB271FD61197020002A593077F2E0905@CAT01S2C> From: Tim Jenkins To: "'Christopher R. Cook'" , "'ipsec@lists.tislabs.com'" Subject: RE: IPsec Monitoring Mib Date: Thu, 25 Apr 2002 09:13:31 -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 Here's my view. Some time ago, Ted asked if there were any deployments/interest/implementations of the series of MIB document written by John Shriver and me, in an attempt to take them to last call. The only response I recall was from the authors of another MIB. This lead to a debate/discussion where it was suggested that that MIB replace the series first mentioned. Nothing was resolved. The bottom line is that there was little response on the mailing list, even though I have received numerous private emails; none of those people posted on the list to say that they were looking at/implementating/considering or whatever the MIB. I have also sent Ted emails asking him what his opinion of the status is, and I've heard nothing back. As far as changes to the documents themselves go, they are ready for last call. Tim > -----Original Message----- > From: Christopher R. Cook [mailto:ccook@quarrytech.com] > Sent: Wednesday, April 24, 2002 12:35 PM > To: ipsec@lists.tislabs.com > Subject: IPsec Monitoring Mib > > > Any status on Tim Jenkins's IPsec Tunnel monitoring Mib ... > > Initial draft was to expire April 4, 2002 .... > > Are there any current WG's addressing monitoring for IPsec... > > Thanks > From owner-ipsec@lists.tislabs.com Fri Apr 26 07:17: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 g3QEHWa04709; Fri, 26 Apr 2002 07:17:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24889 Fri, 26 Apr 2002 09:29:35 -0400 (EDT) Message-Id: <4.3.1.0.20020425204902.02aedec8@email.quarrytech.com> X-Sender: ccook@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 25 Apr 2002 20:56:39 -0400 To: "Casey Carr" , "Tim Jenkins" , From: "Christopher R. Cook" Subject: RE: IPsec Monitoring Mib In-Reply-To: References: <231417CB271FD61197020002A593077F2E0905@CAT01S2C> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The question is ' How bad do you need to manage it..'. If your deploying in production environments then all of a sudden management becomes a real problem to solve. I don't care much about the disagreements... What I need is clearly defined in the Tim Jenkins Draft IPsec Tunnel Monitoring Mib... All I'm looking for are the SA table definitions and the stats ... I'll probably just use the same/similar approach in my enterprise extensions.... But yes, I agree, I would much rather be able to implement this via a standard mib..... At 02:40 PM 4/25/2002 -0400, Casey Carr wrote: >We are interested in implementing an IPSec monitoring MIB but without one >being on standards track it is hard to justify the effort. We were waiting >to see what came out of the disagreement on how to move forward because of >the competing MIBs. > >Has anyone implemented any of these MIBs? If so, how much of it? > >Casey > >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tim Jenkins >Sent: Thursday, April 25, 2002 9:14 AM >To: 'Christopher R. Cook'; 'ipsec@lists.tislabs.com' >Subject: RE: IPsec Monitoring Mib > > >Here's my view. > >Some time ago, Ted asked if there were any >deployments/interest/implementations of the series of MIB document written >by John Shriver and me, in an attempt to take them to last call. > >The only response I recall was from the authors of another MIB. This lead to >a debate/discussion where it was suggested that that MIB replace the series >first mentioned. Nothing was resolved. > >The bottom line is that there was little response on the mailing list, even >though I have received numerous private emails; none of those people posted >on the list to say that they were looking at/implementating/considering or >whatever the MIB. > >I have also sent Ted emails asking him what his opinion of the status is, >and I've heard nothing back. > >As far as changes to the documents themselves go, they are ready for last >call. > >Tim > > > -----Original Message----- > > From: Christopher R. Cook [mailto:ccook@quarrytech.com] > > Sent: Wednesday, April 24, 2002 12:35 PM > > To: ipsec@lists.tislabs.com > > Subject: IPsec Monitoring Mib > > > > > > Any status on Tim Jenkins's IPsec Tunnel monitoring Mib ... > > > > Initial draft was to expire April 4, 2002 .... > > > > Are there any current WG's addressing monitoring for IPsec... > > > > Thanks > > From owner-ipsec@lists.tislabs.com Fri Apr 26 07:17:46 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 g3QEHka04746; Fri, 26 Apr 2002 07:17:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24942 Fri, 26 Apr 2002 09:38:30 -0400 (EDT) From: juha.ollila@nokia.com 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="iso-8859-1" Subject: RE: Status of SCTP Date: Fri, 26 Apr 2002 16:50:33 +0300 Message-ID: Thread-Topic: Status of SCTP Thread-Index: AcHrfSOUojRSIWioStGTv1KG4e8bLQBpkYbg To: X-OriginalArrivalTime: 26 Apr 2002 13:50:34.0577 (UTC) FILETIME=[569EBC10:01C1ED29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA24939 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello! I'm sorry about the stupid questions. I should have remembered "RTFM first" ;-) draft-ietf-ipsec-jfk-03 specifies in section 5: JFK supports two different address types: a list of IPv4 address ranges, and a list of IPv6 address ranges. A single address is a range where the starting and ending elements are the same. Subnets are converted to range format. The notion of "all addresses" is expressed as the pair (0, 0xFFFFFFFF) for IPv4; v6 is handled similarly. and draft-ietf-ipsec-ikev2-01 specifies in section 2.9: IKEv2 is more flexible than IKEv1. IKEv2 allows sets of ranges of both addresses and ports, and allows the Responder to choose a subset of the requested traffic rather than simply responding "not acceptable". It seems that both JFK and IKEv2 support SCTP's set of addresses (multihoming) feature. What about the draft-ietf-ipsec-sctp draft? Is it already submitted to the IESG? I didn't find any information about the draft-ietf-ipsec-sctp on the home page of the IESG. Best Regards, Juha Ollila > -----Original Message----- > From: Ollila Juha (NET/Oulu) > Sent: 24 April, 2002 13:45 > To: ipsec@lists.tislabs.com > Subject: Status of SCTP > > > Hello! > > What is the status of draft-ietf-ipsec-sctp? Will it be > submitted as Draft Standard in October? > > Is it planned to add support for SCTP in IKEv2 or JFK? > > Best Regards, > Juha Ollila > From owner-ipsec@lists.tislabs.com Fri Apr 26 07:18: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 g3QEI8a04774; Fri, 26 Apr 2002 07:18:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24925 Fri, 26 Apr 2002 09:34:30 -0400 (EDT) Message-Id: <200204261213.IAA00560@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-ikev2-02.txt Date: Fri, 26 Apr 2002 08:13:42 -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 : Propsal for the IKEv2 Protocol Author(s) : D. Harkins, C. Kaufman et al. Filename : draft-ietf-ipsec-ikev2-02.txt Pages : 70 Date : 25-Apr-02 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE performs mutual authentication and establishes an IKE security association that can be used to efficiently establish SAs for ESP, AH and/or IPcomp. This version greatly simplifies IKE by replacing the 8 possible phase 1 exchanges with a single exchange based on either public signature keys or shared secret keys. The single exchange provides identity hiding, yet works in 2 round trips (all the identity hiding exchanges in IKE v1 required 3 round trips). Latency of setup of an IPsec SA is further reduced from IKEv1 by allowing setup of an SA for ESP, AH, and/or IPcomp to be piggybacked on the initial IKE exchange. It also improves security by allowing the Responder to be stateless until it can be assured that the Initiator can receive at the claimed IP source address. This version also presents the entire protocol in a single self-contained document, in contrast to IKEv1, in which the protocol was described in ISAKMP (RFC 2408), IKE (RFC 2409), and the DOI (RFC 2407) documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-02.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-ikev2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020425133831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020425133831.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Sat Apr 27 12:11:03 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 g3RJB3a17289; Sat, 27 Apr 2002 12:11:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27520 Sat, 27 Apr 2002 14:09:10 -0400 (EDT) Message-ID: <3CCAEC60.3090906@nomadiclab.com> Date: Sat, 27 Apr 2002 21:22:24 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020420 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rks@cisco.com Cc: Goeman Stefan , "'ipsec@lists.tislabs.com'" Subject: Re: IPsec and Java References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk rks@cisco.com wrote: > using Java http://www.tml.hut.fi/Tutkimus/IPSEC/toc.html FYI: The HUT implementation is a very old one, and it has never been updated. Thus, you may want to study it for academic fun, but its not suitable for anything serious. --Pekka Nikander A member of the original implementation team From owner-ipsec@lists.tislabs.com Mon Apr 29 08:03: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 g3TF3xa07119; Mon, 29 Apr 2002 08:03:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15385 Mon, 29 Apr 2002 09:50:11 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Fri Apr 26 15:31:37 2002 Message-Id: <4.3.1.0.20020425204902.02aedec8@email.quarrytech.com> X-Sender: ccook@email.quarrytech.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 25 Apr 2002 20:56:39 -0400 To: "Casey Carr" , "Tim Jenkins" , From: "Christopher R. Cook" Subject: RE: IPsec Monitoring Mib In-Reply-To: References: <231417CB271FD61197020002A593077F2E0905@CAT01S2C> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The question is ' How bad do you need to manage it..'. If your deploying in production environments then all of a sudden management becomes a real problem to solve. I don't care much about the disagreements... What I need is clearly defined in the Tim Jenkins Draft IPsec Tunnel Monitoring Mib... All I'm looking for are the SA table definitions and the stats ... I'll probably just use the same/similar approach in my enterprise extensions.... But yes, I agree, I would much rather be able to implement this via a standard mib..... At 02:40 PM 4/25/2002 -0400, Casey Carr wrote: >We are interested in implementing an IPSec monitoring MIB but without one >being on standards track it is hard to justify the effort. We were waiting >to see what came out of the disagreement on how to move forward because of >the competing MIBs. > >Has anyone implemented any of these MIBs? If so, how much of it? > >Casey > >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tim Jenkins >Sent: Thursday, April 25, 2002 9:14 AM >To: 'Christopher R. Cook'; 'ipsec@lists.tislabs.com' >Subject: RE: IPsec Monitoring Mib > > >Here's my view. > >Some time ago, Ted asked if there were any >deployments/interest/implementations of the series of MIB document written >by John Shriver and me, in an attempt to take them to last call. > >The only response I recall was from the authors of another MIB. This lead to >a debate/discussion where it was suggested that that MIB replace the series >first mentioned. Nothing was resolved. > >The bottom line is that there was little response on the mailing list, even >though I have received numerous private emails; none of those people posted >on the list to say that they were looking at/implementating/considering or >whatever the MIB. > >I have also sent Ted emails asking him what his opinion of the status is, >and I've heard nothing back. > >As far as changes to the documents themselves go, they are ready for last >call. > >Tim > > > -----Original Message----- > > From: Christopher R. Cook [mailto:ccook@quarrytech.com] > > Sent: Wednesday, April 24, 2002 12:35 PM > > To: ipsec@lists.tislabs.com > > Subject: IPsec Monitoring Mib > > > > > > Any status on Tim Jenkins's IPsec Tunnel monitoring Mib ... > > > > Initial draft was to expire April 4, 2002 .... > > > > Are there any current WG's addressing monitoring for IPsec... > > > > Thanks > > From owner-ipsec@lists.tislabs.com Mon Apr 29 09:49: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 g3TGnIa11969; Mon, 29 Apr 2002 09:49:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15784 Mon, 29 Apr 2002 11:56:10 -0400 (EDT) Importance: Normal Subject: L2TP Protocol To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Pal Sundquist" Date: Mon, 29 Apr 2002 18:07:51 +0200 X-MIMETrack: Serialize by Router on NSVAS1/SE/Nynas(Release 5.0.8 |June 18, 2001) at 2002-04-29 18:07:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Is there anybody who knows about a limitation about hops and the L2TP protocol? I have a problem with a router not connecting from Brisbane to Sweden with 30 hops or more. "Too many hops" ??? / Pal From owner-ipsec@lists.tislabs.com Tue Apr 30 06:49: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 g3UDnma06909; Tue, 30 Apr 2002 06:49:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18533 Tue, 30 Apr 2002 08:39:33 -0400 (EDT) From: annelies.van_moffaert@alcatel.be Subject: Re: Please send me your GSEC presenation slides To: kent@bbn.com Cc: ipsec@lists.tislabs.com Date: Tue, 30 Apr 2002 14:51:22 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/30/2002 14:51:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steven and all, I read the new IP Authentication Header I-D and I have a small question or remark about the multicast SAs. I saw that these are identified by the destination IP address and the SPI value and optionally, the protocol ID. I'm not sure whether this rules out all possible ambiguity for SSM. For SSM the IP destination address does not need to be unique (if I remember correctly). A group session is in SSM identified by the pair (Source IP, Destination IP) and it is possible that 2 different sources choose the same SSM group address as Destination IP address. The group controller of each will pick independently an SPI number. It's of course very unlikely but I think that it is then strictly speaking possible to have the same (SPI, Destination IP) pair for 2 different SSM sessions. In this case the receiver cannot differentiate between two different SAs since they have the same identification pair (Destion IP, SPI). Is this correct or did I overlook something? Kind regards, Lies ___________________ Annelies Van Moffaert \ / _______________________________________________ \ /____ \ ALCATEL / Security Technologies Network Strategy Group DF1 Francis Wellesplein 1 Tel : +32 (0)3 240 83 58 B-2018 Antwerpen Belgium Fax : +32 (0)3 240 48 88 \ / ______________________________________________________\ /___________ \/ From owner-ipsec@lists.tislabs.com Tue Apr 30 18:18: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 g411IZa23658; Tue, 30 Apr 2002 18:18:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20033 Tue, 30 Apr 2002 20:07:12 -0400 (EDT) Message-Id: <200205010010.g410A7C04437@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: ike-modp-groups-04 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 30 Apr 2002 20:10:07 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Is there some reason this document has not been published yet? ] 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 NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPM8yXYqHRg3pndX9AQF4WwQAxrUMMyFVPHA/zJeoHJ2o7r626+LQ+UYx SWosLDzzA6GbwXNpeWa93Pefyh/nLt/MgpseVnBdA5CX3dwoFT4Y6B3jctikMoFt ZYEkrnx//eYqvJzhw0Df3yISWHYdQr1u1lAS5Z0sK+EXgyx0t+ESL9eTK/azVBfY zngnFDIiYIA= =qm44 -----END PGP SIGNATURE-----