Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Gabriel, ... One may argue whether that consistency check is best served by extending the ICV to include the WESP header fields (per the current WG consensus as expressed in the existing draft), or whether that is best done by the end nodes checking the fields explicitly. My reply to Ken addresses the issue you raise about the need for consistency checks. I don't think there is a misunderstanding here. The I-D calls for such checks and I agree that they are the right thing to do. What is at issue, in part, is whether the ESP ICV should have been extended to cover the WESP header. My view, and that of several other folks, is that it should not have been done, for the reasons I cited previously. This aspect of the current I-D could be fixed by having WESP have NO ICV, of by having WESP include its own ICV, which would call for nested processing by hosts. As I explained in my reply to Ken, extending the ESP ICV does not achieve the same effect, so this is not an "either or" situation. On a broader note, as Paul and Russ noted, the IESG gets to decide whether a WG-approved I-D will be published as an RFC (modulo appeals to the IAB, etc.). The IETF last allows anyone, even members of the WG that approved an I-D, to raise questions that the IESG will consider as part of the approval process. I've had over 15 years of experience as a WG chair (opening for Paul to make a snide comment :-)) and I have had WG members raise questions during IETF LC, after WG consensus has been achieved. This is how our process works. Also, even in the face of WG consensus, an AD may request changes to a document. This is not uncommon. when this has happened in the PKIX context, the Wg chairs and document authors have discussed the requested changes with the AD and we have almost always made the changes. Sometimes this has required another WGLC. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Kind-of wearing my co-chair hat: At 9:16 AM +0530 1/6/10, Bhatia, Manav (Manav) wrote: >I currently don't see applications that may need this kind of expedited >processing, but the WESP design should not preclude development of such >applications/features. We have heard a number of statements like this. Please note that WESP was designed for one purpose (making ESP-NULL easier to find) and then the WG realized that we could make it extensible. The latter may be nice, but it should not drive our work unless there is a use case that has stronger-than-rough WG consensus. Nothing precludes us from having both WESP and adding an extensibility mechanism later when there are agreed-on needs. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Hi Russ, > My point is that the end system does not need the information in the > WESP header to properly handle the packet for the supported > application. The additional information is being exposed to allow > middle boxes to make various checks. The end system can > ensure that the > exposed information was correct so that middle boxes were not > spoofed. > An extended ICV is not necessary to perform this type of check if the > information is limited to the payload offset and such. An > ICV is only > needed if WESP carries information that cannot be easily checked by a > process that knows the crypto algorithms that are in use. I'm > challenging the need for such information. One use case could be when you want to prioritize processing certain ESP-NULL packets (most routing applications for instance mandate the use of ESP-NULL as routing is not concerned with confidentiality) over the other. The HW computes the ICV, determines everything is correct and hands over the packet to the IPSec engine. The IPSec engine, briefly inspects the WESP header (and it knows its correct because it passed the preliminary ICV validation check) and looks at the right offsets and depending upon the kind of packet it is, places it in the appropriate queue. With WESP the HW knows the exact offsets it has to look at to figure out the information it needs and can be done in the fast path. OTOH, if we don't include the WESP header in the ICV, then the IPSec engine has to process each packet completely, verify that the WESP header is indeed correct and matches with whats carried inside the packet, before it can do any further processing. This can take up some time, which may be an issue for applications that need faster processing (a protocol like BFD for instance). I currently don't see applications that may need this kind of expedited processing, but the WESP design should not preclude development of such applications/features. However, if folks feel very strongly about not including WESP fields in the ICV, then I would take a back seat and grudgingly concede to it .. Cheers, Manav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Gabriel: My point is that the end system does not need the information in the WESP header to properly handle the packet for the supported application. The additional information is being exposed to allow middle boxes to make various checks. The end system can ensure that the exposed information was correct so that middle boxes were not spoofed. An extended ICV is not necessary to perform this type of check if the information is limited to the payload offset and such. An ICV is only needed if WESP carries information that cannot be easily checked by a process that knows the crypto algorithms that are in use. I'm challenging the need for such information. Russ On 1/5/2010 2:32 PM, gabriel montenegro wrote: Hi Russ, I'd like to comment on your assumption below that: ...the ICV protection imposes a requirement that the end system check the WESP information that it does not need, and then discard the packet if the attacker altered it to the potential detriment of the middlebox" The underlying assumption seems to be that the end nodes do not need to carry out any consistency checks. This contradicts the operating assumption we've been operating under, as expressed by Steve Kent last May 12: http://www.ietf.org/mail-archive/web/ipsec/current/msg04359.html: If we elect to keep the next header field, to help middle boxes quickly locate header fields of interest to them, then we MUST require the recipient of each message to do a (well-defined) consistency check on the packet, for the reasons I cited in SF. and as discussed in San Francisco minutes at: http://tools.ietf.org/wg/ipsecme/minutes?item=minutes74.html One may argue whether that consistency check is best served by extending the ICV to include the WESP header fields (per the current WG consensus as expressed in the existing draft), or whether that is best done by the end nodes checking the fields explicitly. Gabriel - Original Message From: Russ Housley To: "Bhatia, Manav" Cc: ipsec@ietf.org; i...@ietf.org Sent: Tue, December 29, 2009 6:32:54 AM Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Manav: I am unconvinced. If a malicious attacker is willing to alter packets to fool middleboxes, this ICV does not help the middlebox and it harms the end system. The middlebox cannot validate the ICV, and the end system does not need the WESP header information. The end system does not need the pointer data in the WESP header to process the packet correctly; it already knows the size of the IV and other values associated with the algorithms in use. Thus, the ICV protection imposes a requirement that the end system check the WESP information that it does not need, and then discard the packet if the attacker altered it to the potential detriment of the middlebox. Russ At 09:36 PM 12/28/2009, Bhatia, Manav (Manav) wrote: Yes, this was discussed in the WG (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this: We could have some malicious entity that could modify the offsets to ensure that the intermediaries don't parse a portion of the payload (which could contain malicious content) or inspect it differently than what it would have done otherwise. A way to protect against such attacks is to let the end node validate the WESP header by including this as a part of the ESP ICV. If the computed ICV does not match, the packet is dropped (usual IPSec processing). This does not completely eliminate the vulnerability, but it does raise the bar, because now the malicious routers would have to also position themselves both before and after the middle boxes in order to have a chance to revert the packet back to its original form before the end node verifies integrity over the packet. We have also discussed this in the Security Considerations section of the draft. We did informally speak to HW guys who are interested in implementing WESP, and they confirmed that increasing the integrity protection of ESP to now cover the WESP header is trivial. Cheers, Manav -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Jack Kohn Sent: Tuesday, December 29, 2009 6.17 AM To: Stephen Kent Cc: ipsec@ietf.org; Russ Housley; i...@ietf.org; Dan McDonald Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Are you suggesting that ESP ICV should not cover the WESP fields? I think, and my memory could be failing me, that this was discussed in the WG before this got added to the draft. Jack On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote: Yaron, I hate to admit it, but I lost track of the details of WESP as it progressed through WG discussions and briefings at IETF meetings. When I read the I-D in detail, I was very surprised to
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Hi Russ, I'd like to comment on your assumption below that: > ...the ICV protection > imposes a requirement that the end system check the WESP information that it > does not need, and then discard the packet if the attacker altered it to the > potential detriment of the middlebox" The underlying assumption seems to be that the end nodes do not need to carry out any consistency checks. This contradicts the operating assumption we've been operating under, as expressed by Steve Kent last May 12: http://www.ietf.org/mail-archive/web/ipsec/current/msg04359.html: If we elect to keep the next header field, to help middle boxes quickly locate header fields of interest to them, then we MUST require the recipient of each message to do a (well-defined) consistency check on the packet, for the reasons I cited in SF. and as discussed in San Francisco minutes at: http://tools.ietf.org/wg/ipsecme/minutes?item=minutes74.html One may argue whether that consistency check is best served by extending the ICV to include the WESP header fields (per the current WG consensus as expressed in the existing draft), or whether that is best done by the end nodes checking the fields explicitly. Gabriel - Original Message > From: Russ Housley > To: "Bhatia, Manav" > Cc: ipsec@ietf.org; i...@ietf.org > Sent: Tue, December 29, 2009 6:32:54 AM > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > Manav: > > I am unconvinced. If a malicious attacker is willing to alter packets to > fool > middleboxes, this ICV does not help the middlebox and it harms the end > system. > The middlebox cannot validate the ICV, and the end system does not need the > WESP > header information. The end system does not need the pointer data in the > WESP > header to process the packet correctly; it already knows the size of the IV > and > other values associated with the algorithms in use. Thus, the ICV protection > imposes a requirement that the end system check the WESP information that it > does not need, and then discard the packet if the attacker altered it to the > potential detriment of the middlebox. > > Russ > > At 09:36 PM 12/28/2009, Bhatia, Manav (Manav) wrote: > > Yes, this was discussed in the WG > (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this: > > > > We could have some malicious entity that could modify the offsets to ensure > that the intermediaries don't parse a portion of the payload (which could > contain malicious content) or inspect it differently than what it would have > done otherwise. A way to protect against such attacks is to let the end node > validate the WESP header by including this as a part of the ESP ICV. If the > computed ICV does not match, the packet is dropped (usual IPSec processing). > > > > This does not completely eliminate the vulnerability, but it does raise the > bar, because now the malicious routers would have to also position themselves > both before and after the middle boxes in order to have a chance to revert > the > packet back to its original form before the end node verifies integrity over > the > packet. > > > > We have also discussed this in the Security Considerations section of the > draft. > > > > We did informally speak to HW guys who are interested in implementing WESP, > and they confirmed that increasing the integrity protection of ESP to now > cover > the WESP header is trivial. > > > > Cheers, Manav > > > > > -Original Message- > > > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > > > On Behalf Of Jack Kohn > > > Sent: Tuesday, December 29, 2009 6.17 AM > > > To: Stephen Kent > > > Cc: ipsec@ietf.org; Russ Housley; i...@ietf.org; Dan McDonald > > > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > > > > > Are you suggesting that ESP ICV should not cover the WESP fields? > > > > > > I think, and my memory could be failing me, that this was discussed in > > > the WG before this got added to the draft. > > > > > > Jack > > > > > > On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote: > > > > Yaron, > > > > > > > > I hate to admit it, but I lost track of the details of WESP > > > as it progressed > > > > through WG discussions and briefings at IETF meetings. When > > > I read the I-D > > > > in detail, I was very surprised to see that it was no longer a > > > > neatly-layered wrapper, as originally proposed. The fact > > > that it now calls > &
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
At 6:17 AM +0530 12/29/09, Jack Kohn wrote: Are you suggesting that ESP ICV should not cover the WESP fields? I think, and my memory could be failing me, that this was discussed in the WG before this got added to the draft. Jack I am suggesting that WESP should be cleanly layered, in one of two ways: - do not interfere with the ESP ICV computation (be unauthenticated, for the reasons already noted by Tero and Russ) - incorporate the necessary info from the ESP header and not replicate the ESP structure, i.e., become a full-fledged alternative to ESP-NULL (not for ESP when confidentiality is employed) when end systems are configured to expose encapsulated header info to middle boxes. The current design is a hybrid that imposes undue complexity on IPsec implementations. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Manav: I am unconvinced. If a malicious attacker is willing to alter packets to fool middleboxes, this ICV does not help the middlebox and it harms the end system. The middlebox cannot validate the ICV, and the end system does not need the WESP header information. The end system does not need the pointer data in the WESP header to process the packet correctly; it already knows the size of the IV and other values associated with the algorithms in use. Thus, the ICV protection imposes a requirement that the end system check the WESP information that it does not need, and then discard the packet if the attacker altered it to the potential detriment of the middlebox. Russ At 09:36 PM 12/28/2009, Bhatia, Manav (Manav) wrote: Yes, this was discussed in the WG (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this: We could have some malicious entity that could modify the offsets to ensure that the intermediaries don't parse a portion of the payload (which could contain malicious content) or inspect it differently than what it would have done otherwise. A way to protect against such attacks is to let the end node validate the WESP header by including this as a part of the ESP ICV. If the computed ICV does not match, the packet is dropped (usual IPSec processing). This does not completely eliminate the vulnerability, but it does raise the bar, because now the malicious routers would have to also position themselves both before and after the middle boxes in order to have a chance to revert the packet back to its original form before the end node verifies integrity over the packet. We have also discussed this in the Security Considerations section of the draft. We did informally speak to HW guys who are interested in implementing WESP, and they confirmed that increasing the integrity protection of ESP to now cover the WESP header is trivial. Cheers, Manav > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of Jack Kohn > Sent: Tuesday, December 29, 2009 6.17 AM > To: Stephen Kent > Cc: ipsec@ietf.org; Russ Housley; i...@ietf.org; Dan McDonald > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > Are you suggesting that ESP ICV should not cover the WESP fields? > > I think, and my memory could be failing me, that this was discussed in > the WG before this got added to the draft. > > Jack > > On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote: > > Yaron, > > > > I hate to admit it, but I lost track of the details of WESP > as it progressed > > through WG discussions and briefings at IETF meetings. When > I read the I-D > > in detail, I was very surprised to see that it was no longer a > > neatly-layered wrapper, as originally proposed. The fact > that it now calls > > for the ESP ICV to be computed in a new fashion means that > it really is > > replacing ESP, when used to mark ESP-NULL packets. > > > > From a protocol design perspective, the current version > makes no sense to > > me. Why keep the ESP header when ESP processing is now changed in a > > significant way. The WESP header cannot be processed > (completely) by > > itself, because of the dependence on the ESP ICV. So it > makes little or no > > sense to retain the ESP header in this context. I see no > strong backward > > compatibility motivation for this format, given that ESP > processing must > > change to accommodate WESP (as defined). > > > > The issue of using WESP for marking encrypted traffic is a > separate topic. I > > believe the rationale you cited was to enable WESP > extensions, but I may > > have missed other arguments put forth for this. Since most > of the WESP > > extension proposals discussed so far have proven to be > questionable, I am > > not enthusiastic about that rationale. Others have noted > that using WESP > > with encrypted traffic is not consistent with the scope of > the WG charter > > item that authorized work on WESP. Unless Pasi approves a > WESP extension WG > > item as part of re-chartering, I think it is inappropriate > to have a flag to > > mark a WESP payload as encrypted. > > > > Steve > > ___ > > 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 > ___ 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] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Bhatia, Manav (Manav) writes: > Yes, this was discussed in the WG > (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea > was this: > > We could have some malicious entity that could modify the offsets to > ensure that the intermediaries don't parse a portion of the payload > (which could contain malicious content) or inspect it differently > than what it would have done otherwise. A way to protect against > such attacks is to let the end node validate the WESP header by > including this as a part of the ESP ICV. If the computed ICV does > not match, the packet is dropped (usual IPSec processing). As all current fields in the WESP header for ESP-NULL traffic is already verified by the recipient to be matching their authenticated values, there is no need to extend ESP ICV to cover WESP header. Fo example the Next Header field in the WESP header is copy of the Next Header field in the ESP header, and the current draft already mandates that "The receiver MUST ensure that the Next Header field in the WESP header and the Next Header field in the ESP trailer match when using ESP in the Integrity only mode. The packet MUST be dropped if the two do not match." This same goes with HdrLen and TrailerLen etc fields. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Yes, this was discussed in the WG (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this: We could have some malicious entity that could modify the offsets to ensure that the intermediaries don't parse a portion of the payload (which could contain malicious content) or inspect it differently than what it would have done otherwise. A way to protect against such attacks is to let the end node validate the WESP header by including this as a part of the ESP ICV. If the computed ICV does not match, the packet is dropped (usual IPSec processing). This does not completely eliminate the vulnerability, but it does raise the bar, because now the malicious routers would have to also position themselves both before and after the middle boxes in order to have a chance to revert the packet back to its original form before the end node verifies integrity over the packet. We have also discussed this in the Security Considerations section of the draft. We did informally speak to HW guys who are interested in implementing WESP, and they confirmed that increasing the integrity protection of ESP to now cover the WESP header is trivial. Cheers, Manav > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of Jack Kohn > Sent: Tuesday, December 29, 2009 6.17 AM > To: Stephen Kent > Cc: ipsec@ietf.org; Russ Housley; i...@ietf.org; Dan McDonald > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > Are you suggesting that ESP ICV should not cover the WESP fields? > > I think, and my memory could be failing me, that this was discussed in > the WG before this got added to the draft. > > Jack > > On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote: > > Yaron, > > > > I hate to admit it, but I lost track of the details of WESP > as it progressed > > through WG discussions and briefings at IETF meetings. When > I read the I-D > > in detail, I was very surprised to see that it was no longer a > > neatly-layered wrapper, as originally proposed. The fact > that it now calls > > for the ESP ICV to be computed in a new fashion means that > it really is > > replacing ESP, when used to mark ESP-NULL packets. > > > > From a protocol design perspective, the current version > makes no sense to > > me. Why keep the ESP header when ESP processing is now changed in a > > significant way. The WESP header cannot be processed > (completely) by > > itself, because of the dependence on the ESP ICV. So it > makes little or no > > sense to retain the ESP header in this context. I see no > strong backward > > compatibility motivation for this format, given that ESP > processing must > > change to accommodate WESP (as defined). > > > > The issue of using WESP for marking encrypted traffic is a > separate topic. I > > believe the rationale you cited was to enable WESP > extensions, but I may > > have missed other arguments put forth for this. Since most > of the WESP > > extension proposals discussed so far have proven to be > questionable, I am > > not enthusiastic about that rationale. Others have noted > that using WESP > > with encrypted traffic is not consistent with the scope of > the WG charter > > item that authorized work on WESP. Unless Pasi approves a > WESP extension WG > > item as part of re-chartering, I think it is inappropriate > to have a flag to > > mark a WESP payload as encrypted. > > > > Steve > > ___ > > 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 > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Are you suggesting that ESP ICV should not cover the WESP fields? I think, and my memory could be failing me, that this was discussed in the WG before this got added to the draft. Jack On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote: > Yaron, > > I hate to admit it, but I lost track of the details of WESP as it progressed > through WG discussions and briefings at IETF meetings. When I read the I-D > in detail, I was very surprised to see that it was no longer a > neatly-layered wrapper, as originally proposed. The fact that it now calls > for the ESP ICV to be computed in a new fashion means that it really is > replacing ESP, when used to mark ESP-NULL packets. > > From a protocol design perspective, the current version makes no sense to > me. Why keep the ESP header when ESP processing is now changed in a > significant way. The WESP header cannot be processed (completely) by > itself, because of the dependence on the ESP ICV. So it makes little or no > sense to retain the ESP header in this context. I see no strong backward > compatibility motivation for this format, given that ESP processing must > change to accommodate WESP (as defined). > > The issue of using WESP for marking encrypted traffic is a separate topic. I > believe the rationale you cited was to enable WESP extensions, but I may > have missed other arguments put forth for this. Since most of the WESP > extension proposals discussed so far have proven to be questionable, I am > not enthusiastic about that rationale. Others have noted that using WESP > with encrypted traffic is not consistent with the scope of the WG charter > item that authorized work on WESP. Unless Pasi approves a WESP extension WG > item as part of re-chartering, I think it is inappropriate to have a flag to > mark a WESP payload as encrypted. > > Steve > ___ > 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] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Yaron, I hate to admit it, but I lost track of the details of WESP as it progressed through WG discussions and briefings at IETF meetings. When I read the I-D in detail, I was very surprised to see that it was no longer a neatly-layered wrapper, as originally proposed. The fact that it now calls for the ESP ICV to be computed in a new fashion means that it really is replacing ESP, when used to mark ESP-NULL packets. From a protocol design perspective, the current version makes no sense to me. Why keep the ESP header when ESP processing is now changed in a significant way. The WESP header cannot be processed (completely) by itself, because of the dependence on the ESP ICV. So it makes little or no sense to retain the ESP header in this context. I see no strong backward compatibility motivation for this format, given that ESP processing must change to accommodate WESP (as defined). The issue of using WESP for marking encrypted traffic is a separate topic. I believe the rationale you cited was to enable WESP extensions, but I may have missed other arguments put forth for this. Since most of the WESP extension proposals discussed so far have proven to be questionable, I am not enthusiastic about that rationale. Others have noted that using WESP with encrypted traffic is not consistent with the scope of the WG charter item that authorized work on WESP. Unless Pasi approves a WESP extension WG item as part of re-chartering, I think it is inappropriate to have a flag to mark a WESP payload as encrypted. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
And in case there are no extensions for using WESP with encrypted traffic, then we will continue to use WESP for ESP-NULL only. Jack On Mon, Dec 21, 2009 at 6:54 PM, Yaron Sheffer wrote: > Hi Tero, > > Allowing the more generic, encrypted WESP (as per the current I-D) would let > vendors experiment with different extensions. Yes, they might play with some > extensions that you and I find ugly or even insecure. But crippling WESP > today would mean that any such extensions are (1) limited to IKE and (2) > invisible to the middleboxes. > > Thanks, > Yaron > > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Tero Kivinen > Sent: Monday, December 21, 2009 13:36 > To: Jack Kohn > Cc: ipsec@ietf.org; Russ Housley > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > Jack Kohn writes: >> Alternatively, since we seem to be >> having unlimited bandwidth for discussions, we might as well argue >> whether we need heuristics also or not, as there are very few people >> in IPSecMe WG who feel the need for it. > > My personal feelings is that this inspecting ESP-NULL packets is not > needed at all, as everything will be encrypted ESP anyways, so there > is even no point of trying to inspect any of that ESP-NULL traffic > (either using WESP or heuristics). > > The reason I am in favor of heuristics instead of WESP, is that > heuristics requires changes only on the middleboxes, we do not need to > make new extension that will affect all the end nodes supporting > IPsec. > > Also heuristics is not harmful, as it does not harm others, it is > simply internal matter inside the middlebox. I do consider WESP a bit > harmful, as it adds extra bytes to all packets, and does not offer > that much which cannot already be done by other means, but requires > all IPsec end nodes to be updated (and also every single firewall > needs to be reconfigured to allow also this new protocol number > through not just proto 50 and 51). > > But those are my personal feelings, and I agreed that as rest of the > WG seemed to want to work on WESP, that is fine, but I still wanted > push the heuristics forward just as middlebox only alternative to > WESP. > >> Strangely, its that same set of people who are against the idea of >> using null NULL ciphers for WESP. Is it because by supporting >> encryption in WESP we make it more generic, and thereby increasing >> the chances of its widespread implementation as against the other >> proposal (heuristics)? > > Using non-NULL ciphers for WESP takes it out from its intended use, > and unless there is some more extensions done for WESP (which there > currently isn't), there is no point of doing that, as using WESP for > encrypted ESP we are just wasting bytes for extra WESP header. > > Meaning that before we see any extensions that would require WESP and > encrypted ESP I do not think there is any point of sending encrypted > ESP traffic using WESP. > > And yes, making WESP more generic would mean that I would perhaps some > day need to implement it (which I do not want to) if there is too much > customer demand for it in the future. > -- > kivi...@iki.fi > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
+1 > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of Brian Swander > Sent: Tuesday, December 22, 2009 4.43 AM > To: Yaron Sheffer; Tero Kivinen; Jack Kohn > Cc: ipsec@ietf.org; Russ Housley > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > I took Russ' comments about "being in the rough" to imply > that we're re-opening the consensus discussion. I'm not sure > why we're reopening this, since we already got consensus on > this when it came up the first time. Since many of our > internal guys are already out for the holidays, I can't see > meaningful consensus occurring until the new year. > > bs > > > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of Yaron Sheffer > Sent: Monday, December 21, 2009 5:25 AM > To: Tero Kivinen; Jack Kohn > Cc: ipsec@ietf.org; Russ Housley > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > Hi Tero, > > Allowing the more generic, encrypted WESP (as per the current > I-D) would let vendors experiment with different extensions. > Yes, they might play with some extensions that you and I find > ugly or even insecure. But crippling WESP today would mean > that any such extensions are (1) limited to IKE and (2) > invisible to the middleboxes. > > Thanks, > Yaron > > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of Tero Kivinen > Sent: Monday, December 21, 2009 13:36 > To: Jack Kohn > Cc: ipsec@ietf.org; Russ Housley > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > Jack Kohn writes: > > Alternatively, since we seem to be > > having unlimited bandwidth for discussions, we might as well argue > > whether we need heuristics also or not, as there are very few people > > in IPSecMe WG who feel the need for it. > > My personal feelings is that this inspecting ESP-NULL packets is not > needed at all, as everything will be encrypted ESP anyways, so there > is even no point of trying to inspect any of that ESP-NULL traffic > (either using WESP or heuristics). > > The reason I am in favor of heuristics instead of WESP, is that > heuristics requires changes only on the middleboxes, we do not need to > make new extension that will affect all the end nodes supporting > IPsec. > > Also heuristics is not harmful, as it does not harm others, it is > simply internal matter inside the middlebox. I do consider WESP a bit > harmful, as it adds extra bytes to all packets, and does not offer > that much which cannot already be done by other means, but requires > all IPsec end nodes to be updated (and also every single firewall > needs to be reconfigured to allow also this new protocol number > through not just proto 50 and 51). > > But those are my personal feelings, and I agreed that as rest of the > WG seemed to want to work on WESP, that is fine, but I still wanted > push the heuristics forward just as middlebox only alternative to > WESP. > > > Strangely, its that same set of people who are against the idea of > > using null NULL ciphers for WESP. Is it because by supporting > > encryption in WESP we make it more generic, and thereby increasing > > the chances of its widespread implementation as against the other > > proposal (heuristics)? > > Using non-NULL ciphers for WESP takes it out from its intended use, > and unless there is some more extensions done for WESP (which there > currently isn't), there is no point of doing that, as using WESP for > encrypted ESP we are just wasting bytes for extra WESP header. > > Meaning that before we see any extensions that would require WESP and > encrypted ESP I do not think there is any point of sending encrypted > ESP traffic using WESP. > > And yes, making WESP more generic would mean that I would perhaps some > day need to implement it (which I do not want to) if there is too much > customer demand for it in the future. > -- > kivi...@iki.fi > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > ___ > 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 > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Tero, > The reason I am in favor of heuristics instead of WESP, is that > heuristics requires changes only on the middleboxes, we do not need to > make new extension that will affect all the end nodes supporting > IPsec. > > Also heuristics is not harmful, as it does not harm others, it is > simply internal matter inside the middlebox. I do consider WESP a bit > harmful, as it adds extra bytes to all packets, and does not offer I think heuristics is a good solution, but contrary to your thinking I don't think it's a panacea to all our problems. Heuristic solution is not an exclusive alternative, but a complement to the deterministic approach in providing an interim solution using a subset of devices that are capable and willing to consume the heuristics overheads. Few of us, long time back, had done some work on the issues with heuristics and I post a summary of what we had discussed. Claiming that heuristics requires only modification of the network entities is somewhat misleading, as the nature of the modifications is very different. Such changes would imply a radical change in architectures of devices that currently do not have the capability to run complex code with the corresponding memory requirements. Furthermore, those changes are ongoing as heuristics has to continuously change to accommodate changing traffic patterns and algorithms (e.g. leveraging new, future cryptographic algorithms for ESP, which have different IV/ICV length requirements). From the point of view of testing and compliance, such complexity is in itself an issue which compounded with the potential for incorrect determination is perhaps a deployment blocker. Heuristics are applicable to only some (not all) stateful devices. Even within stateful devices, not all of them are expected to be able to handle heuristics, particularly as they grow to handle 100K-400K flows. Heuristics will NOT work for high speed, high aggregation, stateless devices. These devices provide services such as stateless statistics, QoS markings or stateless firewalls (which provide basic access control functions in filtering unwanted network traffic). Stateless devices by definition do not maintain dynamic, per-flow state (although they typically have fixed, static rules) and hence employing any heuristics-based solution would require a radical architecture change for these devices. This would be in the form of incorporating state into the device or the ability to execute the heuristics engine at line rate for every packet, which would require a pure hardware-based solution. Heuristics are not a good match for short-lived flows. Measurements of Enterprise traffic patterns reveal that a significant portion is represented by UDP and short-lived flows. UDP traffic has been measured at 25% of the total. The concept of "flows" which heuristics uses to amortize the initial cost of parsing and analysis is not as applicable here. Handling such cases (e.g., VoIP) via heuristics is very costly and may end up becoming the bottleneck for the services offered. The heuristics draft itself concedes that UDP checks will be more expensive, as it does not contain immutable fields (such as those available in TCP flows) that can be used as part of the heuristics algorithm to increase the probability of drawing the correct conclusions. Heuristics requires a proper cache flushing mechanism. Heuristics based approach recommends executing the heuristics engine in software and subsequently caching the results in hardware by using the packet attributes (e.g. IP addresses, SPI). However, it does not provide a clean solution for cache management and specifically eviction of a given cache entry, if and when a given flow is no longer needed. The proposed approaches for cache management recommend simple Least Recently Used (LRU) type algorithms, which will unnecessarily flush legitimate cache entries for legitimate, but intermittent traffic patterns or an approach of binding TCP flow analysis with the appropriate cache entry, which may work for stateful protocols, but is ineffective for stateless protocols such as UDP. Additionally, the engine will have no idea about short and long-lived security associations and may prematurely remove cache entries, even though the SA is still active. This will require further iter ations using the heuristics engine, when a subsequent packet for that security association is seen. Furthermore, the cache will likely be of a finite size and any of the above approaches will cause a 'cache trash' resulting in performance degradation, as well as unnecessary CPU consumption in re-execution of the heuristics engine. This provides a new DoS attack vector for potential adversaries by forcing cache add/remove harmonics by simply replaying packets at well-chosen intervals. It is hard or costly to handle quick route changes via heuristics. Heuristics works best in the presence of long-lived TCP sessi
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
I took Russ' comments about "being in the rough" to imply that we're re-opening the consensus discussion. I'm not sure why we're reopening this, since we already got consensus on this when it came up the first time. Since many of our internal guys are already out for the holidays, I can't see meaningful consensus occurring until the new year. bs -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Monday, December 21, 2009 5:25 AM To: Tero Kivinen; Jack Kohn Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Hi Tero, Allowing the more generic, encrypted WESP (as per the current I-D) would let vendors experiment with different extensions. Yes, they might play with some extensions that you and I find ugly or even insecure. But crippling WESP today would mean that any such extensions are (1) limited to IKE and (2) invisible to the middleboxes. Thanks, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, December 21, 2009 13:36 To: Jack Kohn Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Jack Kohn writes: > Alternatively, since we seem to be > having unlimited bandwidth for discussions, we might as well argue > whether we need heuristics also or not, as there are very few people > in IPSecMe WG who feel the need for it. My personal feelings is that this inspecting ESP-NULL packets is not needed at all, as everything will be encrypted ESP anyways, so there is even no point of trying to inspect any of that ESP-NULL traffic (either using WESP or heuristics). The reason I am in favor of heuristics instead of WESP, is that heuristics requires changes only on the middleboxes, we do not need to make new extension that will affect all the end nodes supporting IPsec. Also heuristics is not harmful, as it does not harm others, it is simply internal matter inside the middlebox. I do consider WESP a bit harmful, as it adds extra bytes to all packets, and does not offer that much which cannot already be done by other means, but requires all IPsec end nodes to be updated (and also every single firewall needs to be reconfigured to allow also this new protocol number through not just proto 50 and 51). But those are my personal feelings, and I agreed that as rest of the WG seemed to want to work on WESP, that is fine, but I still wanted push the heuristics forward just as middlebox only alternative to WESP. > Strangely, its that same set of people who are against the idea of > using null NULL ciphers for WESP. Is it because by supporting > encryption in WESP we make it more generic, and thereby increasing > the chances of its widespread implementation as against the other > proposal (heuristics)? Using non-NULL ciphers for WESP takes it out from its intended use, and unless there is some more extensions done for WESP (which there currently isn't), there is no point of doing that, as using WESP for encrypted ESP we are just wasting bytes for extra WESP header. Meaning that before we see any extensions that would require WESP and encrypted ESP I do not think there is any point of sending encrypted ESP traffic using WESP. And yes, making WESP more generic would mean that I would perhaps some day need to implement it (which I do not want to) if there is too much customer demand for it in the future. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ___ 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] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Hi Tero, Allowing the more generic, encrypted WESP (as per the current I-D) would let vendors experiment with different extensions. Yes, they might play with some extensions that you and I find ugly or even insecure. But crippling WESP today would mean that any such extensions are (1) limited to IKE and (2) invisible to the middleboxes. Thanks, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, December 21, 2009 13:36 To: Jack Kohn Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Jack Kohn writes: > Alternatively, since we seem to be > having unlimited bandwidth for discussions, we might as well argue > whether we need heuristics also or not, as there are very few people > in IPSecMe WG who feel the need for it. My personal feelings is that this inspecting ESP-NULL packets is not needed at all, as everything will be encrypted ESP anyways, so there is even no point of trying to inspect any of that ESP-NULL traffic (either using WESP or heuristics). The reason I am in favor of heuristics instead of WESP, is that heuristics requires changes only on the middleboxes, we do not need to make new extension that will affect all the end nodes supporting IPsec. Also heuristics is not harmful, as it does not harm others, it is simply internal matter inside the middlebox. I do consider WESP a bit harmful, as it adds extra bytes to all packets, and does not offer that much which cannot already be done by other means, but requires all IPsec end nodes to be updated (and also every single firewall needs to be reconfigured to allow also this new protocol number through not just proto 50 and 51). But those are my personal feelings, and I agreed that as rest of the WG seemed to want to work on WESP, that is fine, but I still wanted push the heuristics forward just as middlebox only alternative to WESP. > Strangely, its that same set of people who are against the idea of > using null NULL ciphers for WESP. Is it because by supporting > encryption in WESP we make it more generic, and thereby increasing > the chances of its widespread implementation as against the other > proposal (heuristics)? Using non-NULL ciphers for WESP takes it out from its intended use, and unless there is some more extensions done for WESP (which there currently isn't), there is no point of doing that, as using WESP for encrypted ESP we are just wasting bytes for extra WESP header. Meaning that before we see any extensions that would require WESP and encrypted ESP I do not think there is any point of sending encrypted ESP traffic using WESP. And yes, making WESP more generic would mean that I would perhaps some day need to implement it (which I do not want to) if there is too much customer demand for it in the future. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Jack Kohn writes: > Alternatively, since we seem to be > having unlimited bandwidth for discussions, we might as well argue > whether we need heuristics also or not, as there are very few people > in IPSecMe WG who feel the need for it. My personal feelings is that this inspecting ESP-NULL packets is not needed at all, as everything will be encrypted ESP anyways, so there is even no point of trying to inspect any of that ESP-NULL traffic (either using WESP or heuristics). The reason I am in favor of heuristics instead of WESP, is that heuristics requires changes only on the middleboxes, we do not need to make new extension that will affect all the end nodes supporting IPsec. Also heuristics is not harmful, as it does not harm others, it is simply internal matter inside the middlebox. I do consider WESP a bit harmful, as it adds extra bytes to all packets, and does not offer that much which cannot already be done by other means, but requires all IPsec end nodes to be updated (and also every single firewall needs to be reconfigured to allow also this new protocol number through not just proto 50 and 51). But those are my personal feelings, and I agreed that as rest of the WG seemed to want to work on WESP, that is fine, but I still wanted push the heuristics forward just as middlebox only alternative to WESP. > Strangely, its that same set of people who are against the idea of > using null NULL ciphers for WESP. Is it because by supporting > encryption in WESP we make it more generic, and thereby increasing > the chances of its widespread implementation as against the other > proposal (heuristics)? Using non-NULL ciphers for WESP takes it out from its intended use, and unless there is some more extensions done for WESP (which there currently isn't), there is no point of doing that, as using WESP for encrypted ESP we are just wasting bytes for extra WESP header. Meaning that before we see any extensions that would require WESP and encrypted ESP I do not think there is any point of sending encrypted ESP traffic using WESP. And yes, making WESP more generic would mean that I would perhaps some day need to implement it (which I do not want to) if there is too much customer demand for it in the future. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Hi Russ, If we are not willing to ever extend WESP then we might as well debate the alternative scheme that i had reviewed long time back (which was shot down citing WESP being more extensible). I see that we are going through the discussions that we've already had in the WG, things that had been decided by majority consensus, approved by everyone in the WG. With this being the case we might as well debate on whether we really want a new protocol type for WESP (again discussed long time back) or if we can just hijack one of the SPI values and treat all packets with that as ESP-NULL. Alternatively, since we seem to be having unlimited bandwidth for discussions, we might as well argue whether we need heuristics also or not, as there are very few people in IPSecMe WG who feel the need for it. Strangely, its that same set of people who are against the idea of using null NULL ciphers for WESP. Is it because by supporting encryption in WESP we make it more generic, and thereby increasing the chances of its widespread implementation as against the other proposal (heuristics)? Jack On Sat, Dec 19, 2009 at 11:19 PM, Russ Housley wrote: > Ken: > >> [Ken] I think this is the whole point. All the work on ESP/IPsec this far >> has been considering a two party interaction (outside the multicast >> context!). Now there is a third party - the middle box, which would like to >> gain some additional information in order to provide valuable network >> services. The end boxes already know what is being negotiated, so just >> making changes to IKE to add additional capability is insufficient in >> certain scenarios (while perfectly sufficient in others). We need to provide >> additional information in the data path, hence the need for WESP. > > I do not agree with your assessment of the situation. I agree with Tero's > thoughts. > > The IPsecME charter includes this work item: > > A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system, to easily and reliably > determine whether an ESP packet is encrypted with the NULL cipher; and > if it is, determine the location of the actual payload data inside the > packet. The starting points for this work item are > draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-protocol. > > Nothing in this description prepared me for WESP processing of ESP packets > with a non-NULL-cipher. It suggests making it easy for the middlebox to > gain access to data that is already plaintext. It does not suggest making > information available to the middlebox that was previously unavailable to > it. > > Further, based on the discussion that has happened since I posted my DISCUSS > position, other IPsecME WG participants are uncomfortable with the direction > that WESP has taken. As the discussion progresses, if I can see that these > people and myself are in the rough, then I will clear. So far, that does > not seem to be the case. > > Russ > ___ > 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] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Ken: [Ken] I think this is the whole point. All the work on ESP/IPsec this far has been considering a two party interaction (outside the multicast context!). Now there is a third party - the middle box, which would like to gain some additional information in order to provide valuable network services. The end boxes already know what is being negotiated, so just making changes to IKE to add additional capability is insufficient in certain scenarios (while perfectly sufficient in others). We need to provide additional information in the data path, hence the need for WESP. I do not agree with your assessment of the situation. I agree with Tero's thoughts. The IPsecME charter includes this work item: A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-protocol. Nothing in this description prepared me for WESP processing of ESP packets with a non-NULL-cipher. It suggests making it easy for the middlebox to gain access to data that is already plaintext. It does not suggest making information available to the middlebox that was previously unavailable to it. Further, based on the discussion that has happened since I posted my DISCUSS position, other IPsecME WG participants are uncomfortable with the direction that WESP has taken. As the discussion progresses, if I can see that these people and myself are in the rough, then I will clear. So far, that does not seem to be the case. Russ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Grewal, Ken writes: > >It does make more complexity for the middle boxes as they need to cope > >with both encrypted WESP and ESP-NULL WESP, thus they still cannot use > >just the WESP protocol number to indicate this packet is clear text. > >Now they also need to check the bit in the header, and if we add more > >extensions to WESP, they need to start doing even more processing etc, > >and quite soon WESP is more complex than what AH is now. > > [Ken] I do not think that checking one more bit adds too much > additional complexity, compared with extracting the offsets and > protocol Information from the header. It does provide compatibility > for both encrypted and unencrypted traffic. But without adding even more extensions there is no reason to ever use encrypted WESP instead of ESP. WESP just adds extra header without any benefit compared to normal encrypted ESP. > If we add more extensions to WESP, then those need to be evaluated > based on the cost / complexity Vs. benefit and that will be a > separate debate. The question is how many extensions we have which are such that they need to be understood by the middle boxes. Extensions for the end hosts can be done using standard ESP. > [Ken] I think this is the whole point. All the work on ESP/IPsec > this far has been considering a two party interaction (outside the > multicast context!). Yes, I and I think IPsec will stay that way... For example I do not think our OEM toolkit will include WESP as I do not really see any need for it. > Now there is a third party - the middle box, which would like to > gain some additional information in order to provide valuable > network services. The end boxes already know what is being > negotiated, so just making changes to IKE to add additional > capability is insufficient in certain scenarios (while perfectly > sufficient in others). We need to provide additional information in > the data path, hence the need for WESP. I am not sure WESP is right solution for that problem. It would be much better to provide authenticated protocol where the middlebox could connect to the end node and query the required parameters from the end node and the end node can give that information out without needing to waste extra bytes on each packet. Also that way end node could control who gets the information and who does not. There is no need that additional information needs to be on the data path, and in clear text, it could also be communicated using some other out of band method instead of WESP. Depending on what kind of additional information needs to be transmitted, the solutions can be quite different. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
FWIW, I would personally rather see WESP do exactly what it is supposed to do, reveal the packet, and not handle other kinds of functionality (encrypted packets etc) Jari ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Some comments inline... >It does make more complexity for the middle boxes as they need to cope >with both encrypted WESP and ESP-NULL WESP, thus they still cannot use >just the WESP protocol number to indicate this packet is clear text. >Now they also need to check the bit in the header, and if we add more >extensions to WESP, they need to start doing even more processing etc, >and quite soon WESP is more complex than what AH is now. [Ken] I do not think that checking one more bit adds too much additional complexity, compared with extracting the offsets and protocol Information from the header. It does provide compatibility for both encrypted and unencrypted traffic. If we add more extensions to WESP, then those need to be evaluated based on the cost / complexity Vs. benefit and that will be a separate debate. >ESP is extensible, but it just requires out of band communication to >negotiate those extensions. We currently already have ESP extensions >like extended sequence numbers (ESN), Explicit Congestion Notification >(ECN), Traffic Flow Confidentiality (TFC), and Combined mode >algorithms. > >Those were added after initial ESP was created, and they are >negotiated using IKEv2 (or some other method). > >ESP does not offer extensibility that can be done without out of band >communication, and as that out of band communication is normally >encrypted (inside IKEv2) that means middle boxes cannot process it. > [Ken] I think this is the whole point. All the work on ESP/IPsec this far has been considering a two party interaction (outside the multicast context!). Now there is a third party - the middle box, which would like to gain some additional information in order to provide valuable network services. The end boxes already know what is being negotiated, so just making changes to IKE to add additional capability is insufficient in certain scenarios (while perfectly sufficient in others). We need to provide additional information in the data path, hence the need for WESP. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Agreed. Thanks, Ken >-Original Message- >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >Of Jack Kohn >Sent: Wednesday, December 16, 2009 3:33 PM >To: Russ Housley >Cc: ipsec@ietf.org; i...@ietf.org >Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > >My two bits on this and I'll let the authors/chairs explain in detail .. > >On Thu, Dec 17, 2009 at 4:29 AM, Russ Housley >wrote: >> Discuss: >> The primary motivation for this work is to allow a middlebox to peek >> into integrity protected (but not encrypted) IPsec packets. Some >> integrity-check algorithms use an IV, a middlebox cannot alway know >> where the payload starts. Unlike the IPsec peer that negotiated the >> algorithm in the IKE exchange, the middlebox does not know which >> integrity-check algorithm is in use, and thus doe s not know if an IV >> is present or how long it might be. >> >> The document allows the encapsulation of encrypted IPsec traffic. >> Why? I cannot see the justification for the use if WESP at all if >> the IPsec traffic is encrypted. > >This was discussed and i think the idea was not to limit WESP for just >ESP-NULL. One does not lose anything by defining WESP for encrypted >packets (besides the additional bytes in the header). However, by >keeping provisions for this, we are free to define other extensions >which might later work for encrypted packets. > >I think its a good idea to keep WESP flexible and see how it evolves >in the wild. In the worst case, no one would use it for encrypted >packets .. > >Jack >> >___ >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] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Yaron Sheffer writes: > I agree with you regarding some of the proposals that have been > floating around re: exposing bits and pieces of encrypted data. I am really concerned about some of those late proposals for WESP extensions, and if someone would have mentioned any of those earlier when we were discussing whether WESP should allow encrypted ESP also, I would have been even more against allowing encrypted WESP. > I disagree though that WESP should not be used for encrypted data: > > - It is simpler for implementations and architecturally cleaner for > WESP to support both flavors. It does make more complexity for the middle boxes as they need to cope with both encrypted WESP and ESP-NULL WESP, thus they still cannot use just the WESP protocol number to indicate this packet is clear text. Now they also need to check the bit in the header, and if we add more extensions to WESP, they need to start doing even more processing etc, and quite soon WESP is more complex than what AH is now. > - WESP provides for (secure) extensibility, which unfortunately we > have not had with ESP. Indeed we should be wise about picking such > extensions. ESP is extensible, but it just requires out of band communication to negotiate those extensions. We currently already have ESP extesions like extended sequence numbers (ESN), Explicit Congestion Notification (ECN), Traffic Flow Confidentiality (TFC), and Combined mode algorithms. Those were added after initial ESP was created, and they are negotiated using IKEv2 (or some other method). ESP does not offer extensibility that can be done without out of band communication, and as that out of band communication is normally encrypted (inside IKEv2) that means middle boxes cannot process it. I do not think WESP should be used as generic extensible ESP. That was not what the ipsecme wg was chartered to do. We were chartered to do: - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Hi Dan I agree with you regarding some of the proposals that have been floating around re: exposing bits and pieces of encrypted data. I disagree though that WESP should not be used for encrypted data: - It is simpler for implementations and architecturally cleaner for WESP to support both flavors. - WESP provides for (secure) extensibility, which unfortunately we have not had with ESP. Indeed we should be wise about picking such extensions. Thanks, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan McDonald Sent: Thursday, December 17, 2009 4:35 To: Russ Housley Cc: ipsec@ietf.org; i...@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility On Wed, Dec 16, 2009 at 02:59:45PM -0800, Russ Housley wrote: > The document allows the encapsulation of encrypted IPsec traffic. > Why? I cannot see the justification for the use if WESP at all if > the IPsec traffic is encrypted. Because THE MAN told 'em to do it! :) Seriously though, I agree with Russ -- it makes little to no sense to expose privacy-protected fields. If you're worried about traffic shaping, just put all ESP/WESP/whatever packets in the lowest priority bucket. Any other reason that springs to mind simply defeats the purpose of privacy-protection. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
On Wed, Dec 16, 2009 at 02:59:45PM -0800, Russ Housley wrote: > The document allows the encapsulation of encrypted IPsec traffic. > Why? I cannot see the justification for the use if WESP at all if > the IPsec traffic is encrypted. Because THE MAN told 'em to do it! :) Seriously though, I agree with Russ -- it makes little to no sense to expose privacy-protected fields. If you're worried about traffic shaping, just put all ESP/WESP/whatever packets in the lowest priority bucket. Any other reason that springs to mind simply defeats the purpose of privacy-protection. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
As I recall, folks expressed that if one were to use WESP for ESP-NULL, it would be good to be able to use it for encryption as well to be able to use a consistent packet format. This was issue 84: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/84 Discussed at IETF 74 and 75 as well as on the list: http://tools.ietf.org/wg/ipsecme/minutes?item=minutes74.html http://tools.ietf.org/wg/ipsecme/minutes?item=minutes75.html And (just saw Jack's other message), yes "wrapped" does not correctly describe it any more given changes to the ICV calculation. Gabriel - Original Message > From: Jack Kohn > To: Russ Housley > Cc: ipsec@ietf.org; i...@ietf.org > Sent: Wed, December 16, 2009 3:33:14 PM > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > My two bits on this and I'll let the authors/chairs explain in detail .. > > On Thu, Dec 17, 2009 at 4:29 AM, Russ Housley wrote: > > Discuss: > > The primary motivation for this work is to allow a middlebox to peek > > into integrity protected (but not encrypted) IPsec packets. Some > > integrity-check algorithms use an IV, a middlebox cannot alway know > > where the payload starts. Unlike the IPsec peer that negotiated the > > algorithm in the IKE exchange, the middlebox does not know which > > integrity-check algorithm is in use, and thus doe s not know if an IV > > is present or how long it might be. > > > > The document allows the encapsulation of encrypted IPsec traffic. > > Why? I cannot see the justification for the use if WESP at all if > > the IPsec traffic is encrypted. > > This was discussed and i think the idea was not to limit WESP for just > ESP-NULL. One does not lose anything by defining WESP for encrypted > packets (besides the additional bytes in the header). However, by > keeping provisions for this, we are free to define other extensions > which might later work for encrypted packets. > > I think its a good idea to keep WESP flexible and see how it evolves > in the wild. In the worst case, no one would use it for encrypted > packets .. > > Jack > > > ___ > 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] DISCUSS: draft-ietf-ipsecme-traffic-visibility
> > > So, in fact, WESP is not an optional encapsulation of ESP. It is an > alternative to ESP with some duplicated fields (such as Next Header) > and pointers into the actual integrity-protected payload. > Actually, the name "Wrapped ESP" (WESP) is a misnomer. :) It may have been envisaged as a wrapper over ESP, but given how it has evolved (computing ICV, etc) , its more than just a mere wrapper and is actually an alternative to ESP (as you rightly point out). However, i see no issues with this. In fact, i see this as another reason why the spec should allow WESP to be used for encryption also. Jack ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
My two bits on this and I'll let the authors/chairs explain in detail .. On Thu, Dec 17, 2009 at 4:29 AM, Russ Housley wrote: > Discuss: > The primary motivation for this work is to allow a middlebox to peek > into integrity protected (but not encrypted) IPsec packets. Some > integrity-check algorithms use an IV, a middlebox cannot alway know > where the payload starts. Unlike the IPsec peer that negotiated the > algorithm in the IKE exchange, the middlebox does not know which > integrity-check algorithm is in use, and thus doe s not know if an IV > is present or how long it might be. > > The document allows the encapsulation of encrypted IPsec traffic. > Why? I cannot see the justification for the use if WESP at all if > the IPsec traffic is encrypted. This was discussed and i think the idea was not to limit WESP for just ESP-NULL. One does not lose anything by defining WESP for encrypted packets (besides the additional bytes in the header). However, by keeping provisions for this, we are free to define other extensions which might later work for encrypted packets. I think its a good idea to keep WESP flexible and see how it evolves in the wild. In the worst case, no one would use it for encrypted packets .. Jack > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Discuss: The primary motivation for this work is to allow a middlebox to peek into integrity protected (but not encrypted) IPsec packets. Some integrity-check algorithms use an IV, a middlebox cannot alway know where the payload starts. Unlike the IPsec peer that negotiated the algorithm in the IKE exchange, the middlebox does not know which integrity-check algorithm is in use, and thus doe s not know if an IV is present or how long it might be. The document allows the encapsulation of encrypted IPsec traffic. Why? I cannot see the justification for the use if WESP at all if the IPsec traffic is encrypted. The document says: > > ... by preserving the body of the existing ESP packet format, a > compliant implementation can simply add in the new header, without > needing to change the body of the packet. > The figures in Section 2.2.1 and 2.2.2 show otherwise. The ESP ICV is replaced by a WESP ICV. ESP processing is changed, and I cannot see the justification for it. This is explained by: > > In the diagrams below, "WESP ICV" refers to the ICV computation as > modified by this specification. Namely, the ESP ICV computation is > augmented to include the four octets that constitute the WESP header. > Otherwise, the ICV computation is as specified by ESP [RFC4303]. > So, in fact, WESP is not an optional encapsulation of ESP. It is an alternative to ESP with some duplicated fields (such as Next Header) and pointers into the actual integrity-protected payload. When talking about IKEv2 negotiation, the document says: > > The notification, USE_WESP_MODE (value TBD) MAY be included in a > request message that also includes an SA payload requesting a > CHILD_SA using ESP. > USE_WESP_MODE MUST be included if one wants to use WESP, right? The use of MAY here leads me to think that there are other ways to select the use of WESP in the IKEv2 exchange. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
