Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr
Hi Yoav, If check for mandatory payloads per exchange type is MUST, if it fails we MUST return INVALID_SYNTAX, why we are not saying it explicitly in the draft ? Putting it clearly in the draft make more sense and avoids many confusions. Thanks, Raj On Wed, May 6, 2009 at 7:24 PM, Yoav Nir wrote: > Hi Michael > > > Let me suggest a situation where perhaps I would like to > > bring up an IKE_SA and not a CHILD_SA: it might be for just > > sending initial contact, and perhaps even a DELETE. > > > > I sometimes move quickly from being "outside" my IPsec > > gateway/firewall (such as being on wireless), to being wired > > behind the gateway, where I do not need IPsec. The DPD > > doesn't kick off fast enough, and my traffic goes to where I > > am no longer. It would be nice to bring up the IKE_SA (or... > > haha, resume it), just so that I can send a delete and/or > > initial_contact. > > A far more common situation is when I'm "outside", not moving anywhere, and > I want to connect. I haven't even opened my mail client yet, or launched > the browser (because those thing hate it when the VPN client changes routing > to addresses they are trying to reach). > > The reason I want to connect before everything else, is that connecting > involves some effort (typing the PKCS#12 password, entering a username and > password, copying the OTP from the cellphone to the computer...). I want to > get this over with, but there's still no packet to derive selectors from. > > With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can't > do Main Mode without attempting Quick Mode. > > > Seems like to do this, once needs to include a > > known-to-be-unacceptable CHILD_SA proposal. > > Actually it doesn't have to be acceptable, as the IKE_AUTH will succeed > even if the piggy-backed CHILD_SA fails. > > Now I would never suggest that anyone use a traffic selectors type from the > private range (241-255) which is almost guaranteed to fail... > > Yoav > Email secured by Check Point > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Next Header field in WESP header
I agree in the most part. From other comments, it appears that the Next Header is providing a useful function and if we are keeping it anyway, then the Next Header value of zero also provide a useful function (i.e. payload protocol is opaque, hence data is encrypted). I also agree that the text for packet handling by intermediate nodes and ultimate recipients could be improved and we need explicit verbiage (with MUSTs) to describe the behavior. Perhaps it would be useful to get an early next rev of the draft out with these changes to ensure that we have the correct verbiage in place... I will send out a separate summary of where we are with the open ticket items. >Yaron Sheffer writes: >> I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted >WESP. >> So yes, we use WESP for encrypted traffic to get: >> >> - Extensibility (with the 8-bit Flags field). > >This is future extensibility, which is needed only after we define >some future extensions using this. When we define those future >extensions we can also define that encrypted traffic can be used. > >I would rather keep this for future extension, i.e. only define the >use after we find out what we want to do, as all the end nodes needs >to be updated anyways before those new extensions can be used (and the >intermediate nodes too perhaps). > >The current document is not very clear what to do if reserved bits are >set. It says "On receiving a packet, these values must be checked to >ensure that they are as indicated above.". This does not specify >whether this is only for the final receiver (i.e. the node talking >IPsec), or also all intermediate nodes, or only those intermediate >nodes who actually look inside the WESP or what. It also does not >specify what needs to be done if those fields are not as specified. > >I.e. we need more text for that, i.e. specific processing rules for a) >intermediate nodes who parse WESP header, b) end IPsec entity. In some >cases the dropping / passbying the packet depends on the policy. On >the other hand if flags is set or version number does not match then >that usually means that the format of the WESP header might be >different thus it might be that intermediate nodes cannot parse header >any further. > >> - A single protocol that can do both cases. > >By wasting extra 4 bytes and using protocol which might not be >supported by other end. I think it is better to use plan normal ESP >for encrypted traffic, but I agree that we should probably define the >WESP header so that if Next Header in WESP header is 0 then contents >is encrypted, and intermediate nodes MUST NOT try to parse it. > >I would still recommend using normal ESP for encrypted traffic... >-- >kivi...@iki.fi >___ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] One question for IKE/IPsec
At 10:07 PM +0800 5/14/09, Hui Deng wrote: >Tunnel waitting for traffic means that all traffic have to go through >this tunnel anyhow. Correct. >the scenario I described is that after IKE procedure, but all the >traffic will not go through this Ipsec tunnle since they are point to >point connection. I am deeply confused. Why would point-to-point traffic not go through a tunnel that has the appropriate traffic selectors? Where else would the traffic go? --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] One question for IKE/IPsec
Thanks Paul and Yoav, excuse me for late reply. Tunnel waitting for traffic means that all traffic have to go through this tunnel anyhow. the scenario I described is that after IKE procedure, but all the traffic will not go through this Ipsec tunnle since they are point to point connection. Many thanks for your advice. -Hui 2009/5/14 Paul Hoffman : > At 6:53 PM +0300 5/13/09, Yoav Nir wrote: >>Paul Hoffman wrote: >>> >>> At 8:56 PM +0800 5/13/09, Hui Deng wrote: >>> >Dear IPsec forks, >>> > >>> >May I consult one question here: >>> > >>> >Whether we could still do IKEv2 negotiation >>> (Authenticaiton), but not >>> >use IPsec tunnel? >>> >>> You never need to use a tunnel, regardless of how it was >>> brought up. The tunnel can just sit there, feeling lonely and >>> abandoned, waiting for traffic. >> >>Yes, but you can't rely on the peer not having a policy that says "all >>tunnels that are idle for 30 seconds get deleted" > > Of course, but that's not what Hui asked. In his scenario, he should assume > that the tunnel will get nuked by one side or the other either due to disuse > or an active management choice. > > --Paul Hoffman, Director > --VPN Consortium > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RFC 4869 questions
Yoav Nir writes: > I guess the best thing is to do as in RFC 4308: > " ...The initiator of this >exchange MAY include a new Diffie-Hellman key; if it is included, it >MUST be of type..." That makes sense philosophically, but I would like to get the RFC updated or clarified rather than assume that. > As for lifetimes, at least our implementation has a separate configuration for it. > Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to actually > specify it in the RFC. But that equivocates on the notion of what constitutes a "suite" when compared to RFC 4308, and it also doesn't make sense considering that lifetime and lifesize are represented alongside algorithm choice in the IKEv1 proposal. So this creates problems for implementations like ours (unlike yours) that take the natural approach of including lifetime and lifesize in their notion of a reusable suite object. We now must implement some sort of partially-defined suite object as a kind of abstract class that leaves the lifetime and lifesize undefined. That's not an elegant approach to workaround what I am hoping is just an oversight in the RFC. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yoav Nir To: Scott C Moonen/Raleigh/i...@ibmus, "ipsec@ietf.org" Date: 05/13/2009 04:53 PM Subject: RE: [IPsec] RFC 4869 questions Scott C Moonen wrote: > > I'm reviewing RFC 4869 and it seems to under-specify the attributes that > are needed to achieve real interoperability: it doesn't specify whether to > do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor > does it specify IKEv1 lifetime and lifesize values. So I am left having to > guess at what are appropriate values to use for these attributes. And > once I do choose particular values for PFS and lifesize, is it still correct > for me to use the RFC's suite names in reference to them? Interesting. I hadn't noticed that. I guess the best thing is to do as in RFC 4308: " ...The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST be of type..." IOW it's up to the initiator whether or not to do PFS, and both configurations are OK to use the suite name. As for lifetimes, at least our implementation has a separate configuration for it. Lifetimes in IKEv1 are negotiated, so I don't believe it's necessary to actually specify it in the RFC. But you are right. Especially since this is a followup to RFC 4869, they should have included these parameters. Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] another RFC 4869 question
RFC 4869 makes some statements like: The authentication method used with IKEv1 MAY be either pre-shared key [RFC2409] or ECDSA-256 [RFC4754]. That seems to me like an empty statement, since it doesn't require any particular set of choices nor does it proscribe any choice. Is it intended to proscribe the use of non-ECDSA digital signatures such as RSA, and therefore limit the options to pre-shared key and ECDSA-256? I wonder if it should read "MUST" instead? Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Next Header field in WESP header
Yaron Sheffer writes: > I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP. > So yes, we use WESP for encrypted traffic to get: > > - Extensibility (with the 8-bit Flags field). This is future extensibility, which is needed only after we define some future extensions using this. When we define those future extensions we can also define that encrypted traffic can be used. I would rather keep this for future extension, i.e. only define the use after we find out what we want to do, as all the end nodes needs to be updated anyways before those new extensions can be used (and the intermediate nodes too perhaps). The current document is not very clear what to do if reserved bits are set. It says "On receiving a packet, these values must be checked to ensure that they are as indicated above.". This does not specify whether this is only for the final receiver (i.e. the node talking IPsec), or also all intermediate nodes, or only those intermediate nodes who actually look inside the WESP or what. It also does not specify what needs to be done if those fields are not as specified. I.e. we need more text for that, i.e. specific processing rules for a) intermediate nodes who parse WESP header, b) end IPsec entity. In some cases the dropping / passbying the packet depends on the policy. On the other hand if flags is set or version number does not match then that usually means that the format of the WESP header might be different thus it might be that intermediate nodes cannot parse header any further. > - A single protocol that can do both cases. By wasting extra 4 bytes and using protocol which might not be supported by other end. I think it is better to use plan normal ESP for encrypted traffic, but I agree that we should probably define the WESP header so that if Next Header in WESP header is 0 then contents is encrypted, and intermediate nodes MUST NOT try to parse it. I would still recommend using normal ESP for encrypted traffic... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Next Header field in WESP header
Hi Tero, I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP. So yes, we use WESP for encrypted traffic to get: - Extensibility (with the 8-bit Flags field). - A single protocol that can do both cases. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Tero Kivinen > Sent: Thursday, May 14, 2009 12:02 > To: gabriel montenegro > Cc: ipsec@ietf.org; Bhatia, Manav (Manav); Stephen Kent > Subject: Re: [IPsec] Next Header field in WESP header > > gabriel montenegro writes: > > Perhaps we need more details on what exactly we mean by "the > > endpoint thus must verify the sanity of the WESP header before accepting > > the packet"? And the action to drop the offending packet? > > Yes. I think we need very specific rules with MUSTs in them to say > that packet MUST be dropped if ESP-NULL packet has Next header field > in WESP header which do not match the real Next Header field in the > end. Also final recipient MUST check that the HdrLen or TrailerLen > fields in the WESP header match the negotiate SA and MUST drop the > packet if they do not match. > > Next question is what values are used for HdrLen and TrailerLen if > encrypted ESP is used. If we use real values we do leak out > information, but on the other hand there is no point of giving that > information out as middle nodes cannot do anything with it. > > Actually what are we trying to do if we send encrypted ESP with WESP > wrapper. If we are just making so that we can extend the WESP header > in the future, isn't the version bits enough for that? I mean if we do > not know why someone would want to use WESP encoding for encrypted ESP > now, why do we allow it? > -- > kivi...@iki.fi > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Next Header field in WESP header
gabriel montenegro writes: > Perhaps we need more details on what exactly we mean by "the > endpoint thus must verify the sanity of the WESP header before accepting > the packet"? And the action to drop the offending packet? Yes. I think we need very specific rules with MUSTs in them to say that packet MUST be dropped if ESP-NULL packet has Next header field in WESP header which do not match the real Next Header field in the end. Also final recipient MUST check that the HdrLen or TrailerLen fields in the WESP header match the negotiate SA and MUST drop the packet if they do not match. Next question is what values are used for HdrLen and TrailerLen if encrypted ESP is used. If we use real values we do leak out information, but on the other hand there is no point of giving that information out as middle nodes cannot do anything with it. Actually what are we trying to do if we send encrypted ESP with WESP wrapper. If we are just making so that we can extend the WESP header in the future, isn't the version bits enough for that? I mean if we do not know why someone would want to use WESP encoding for encrypted ESP now, why do we allow it? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
