Re: [IPsec] IPsec Digest, Vol 68, Issue 49
Keith Welter writes: > A recognized (old) notify type like NO_PROPOSAL_CHOSEN may be used > as a hint to do something special like try again later, a notion the > RFC 4718 authors exploited because they didn't have the luxury of > introducing new notify types. So, sending a new notify type to a > peer that does not recognize it could be viewed as preventing the > peer from making the most informed decision. The RFC4718 didn't give any specific instructions what to do when implementation receives those notify types. Also when telling which error to send it uses terms like: "... thus failing the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems like a reasonable approach." "In both cases, NO_PROPOSAL_CHOSEN is probably fine." "... replying with NO_PROPOSAL_CHOSEN is probably reasonable:" "Our proposal is as follows: if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-open" state (currently being created or rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host receives a request to create or rekey a CHILD_SA after it has started rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS." "Our recommendation is that if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-closed" state (currently being closed), it should reply with NO_PROPOSAL_CHOSEN." "At this point, host B should probably reply with NO_PROPOSAL_CHOSEN, and host A should reply as usual, close the IKE_SA, and stop retransmitting req1." All these uses terms where NO_PROPOSAL_CHOSEN is given out more like and example than specific error. The summary section does not use "probably / such as / our proposal / our recommendation" anymore, it summarizes what has been said in other sections before. As the RFC4718 didn't give any instructions what to do when you receive any of those error notifications, I assumed it expected the normal non-fatal (to IKE SA) error notification processing, i.e. it really does not matter what non-fatal error notification you use, as it should cause the exchange to fail which is the only meaning for sending that error notification. That was the reason I wanted to have new notification, so we can actually define some other processing to happen when those are received. I.e. we can say "When a peer receives a TEMPORARY_FAILURE notification, it MUST NOT immediately retry the operation...". That kind of behavior cannot be specified for NO_PROPOSAL_CHOSEN and that kind of behavior is NOT specified for it. On the other hand as only behavior which is defined for NO_PROPOSAL_CHOSEN is the generic non-fatal error notification behavior, meaning the exchange failed, but nothing else, that means any new error notification will get same behavior from complient implementations. If implementation do add some extra handling for the NO_PROPOSAL_CHOSEN error notifications, that is their own decision and it is not required or specified in the standard. > > > If the minor number was changed an implementation could check the > > > minor version and send the new notify types when the minor version > > > was 1 and send the notify types recommended in RFC 4718 if the minor > > > number was 0. > > > > There is no point of supporting old RFC4718 error notifications after > > you implement IKEv2bis as new error notifications are backward > > compatible with old ones. > I think there is a point to supporting the old notifies. If you have a > deployed implementation then you have to consider patching it to at least > recognize the new notification types. This is something you can do, i.e. if you already support old NO_PROPOSAL_CHOSEN notifications and recognize them based on the current state to be caused by exchange collisions you can (and should) still do that. On the other hand new implementations does not need to do that. For them it should be enough to do special processing for TEMPORARY_FAILURE only, for all other non-fatal error notifications they can do default processing (which will still take care of the RFC4718 way of doing things, as the default processing is to make that exchange fail). > If you have an undeployed implementation in development you still > might have to interoperate with unpatched peers. Regadless what error notification you use, you WILL interoperate with unpatched peers (unless they did something against RFC4306). Note, that there are implementations out there which do not implement RFC4718 exchange collisions at all, which means you still need to make sure you handle those cases too if you really want optimal processing with all implementations out there.. > On the other hand, if ikev2bis increments the minor version number > then you may code the ikev2bis implementation to not send the new > notify types to down-level peers rather than patching already > deployed implementations. There is no need for that, as someone might have already disagr
Re: [IPsec] Traffic visibility - consensus call
> > Do you support [the decision to include the WESP header in the ICV > > calculation]? > > . . . > > Do you support [the decision to allow the use of WESP for encrypted > > ESP flows]? > > Yes to both. > > Regardless of what the original work item specified, WESP as it is now > is an alternative to ESP. In the long run it makes no sense to have > them both, so one will get obsoleted (just as AH is getting there). > > I see no benefit in crippling WESP to either keep the old ESP > unchanged or to keep some functionality (like encryption) as ESP-only. No to both, considering the initial scope of what this was trying to do. I don't think we have warrant for inventing a complete replacement to ESP and I haven't yet seen any hypothetical proposals for the use of WESP that convince me there is a strong case for scuttling and replacing ESP. However, if the ayes have it, then I think two things are advisable. First, it would be wise to rewind the clock a bit and think about designing a cleaner WESP. WESP would look different if it had started out as a complete replacement for ESP. (For example, we've missed the opportunity to move the encrypted protocol byte up to the front.) Second, because there is a deep divide over whether a full-featured WESP has value or will be embraced, it may be wise to change this from a standards-track document to an individual draft or to experimental. Alternatively, we could really rewind the clock and try to establish real warrant and consensus for a complete replacement to ESP. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yoav Nir To: Yaron Sheffer Cc: "ipsec@ietf.org" Date: 01/05/2010 02:56 AM Subject: Re: [IPsec] Traffic visibility - consensus call On Jan 5, 2010, at 12:27 AM, Yaron Sheffer wrote: > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus. > > - The current draft ( http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision? > > - The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision? > > Thanks, > Yaron Yes to both. Regardless of what the original work item specified, WESP as it is now is an alternative to ESP. In the long run it makes no sense to have them both, so one will get obsoleted (just as AH is getting there). I see no benefit in crippling WESP to either keep the old ESP unchanged or to keep some functionality (like encryption) as ESP-only. ___ 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] Traffic visibility - consensus call
Yaron Sheffer writes: > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP > header. This has been done to counter certain attacks, but it > means that WESP is no longer a simple wrapper around ESP - ESP > itself is modified. Do you support this design decision? No. > - The current draft allows WESP to be applied to encrypted ESP > flows, in addition to the originally specified ESP-null. This was > intended so that encrypted flows can benefit from the future > extensibility offered by WESP. But arguably, it positions WESP as > an alternative to ESP. Do you support this design decision? No. If we really want to make WESP as specified in the charter, it would be much better to make it so it can be added incrementally to the ESP processing, i.e. just like UDP encapsulation for NAT-traversal can be do. This would mean that the WESP processing could be applied after the normal ESP processing, and WESP would simply add extra header to the beginning, and nothing else. The current draft already makes sure all the fields in the WESP header are verified by the IPsec recipient thus there is really no need to add ICV to cover them (if extensions are added then ICV needs cover them, which makes it impossible to implement WESP as incremental change to ESP). On the other hand if WESP is going be ESPv4, then it would be better to modify the ESP directly, i.e make the required modifications to the ESP header itself. Now WESP has bad attributes from both. It cannot be implemented as extra step after normal ESP processing, but it does not benefit from the fact that it could be modifying ESP header. I myself has always not cared that much of WESP, as I always planned NOT to implement it ever, but just refer people who want it to my heuristics draft, and say that there is no need for WESP. Now if people really start to talk WESP as a new ESPv4, and talking about obsoleting old ESP so that only WESP would stay, then the situation is quite different. If that would have been clear from the beginning I myself would have concentrated much more on the WESP work. I assume there are other people who feel the same. Thats why I think it is inappropriate to even consider WESP as something that would be replacing ESP ever. If that is wanted, then much more discussion is needed. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
On Tue, Jan 05, 2010 at 02:52:55PM +0200, Tero Kivinen wrote: > If we really want to make WESP as specified in the charter, it would > be much better to make it so it can be added incrementally to the ESP > processing, i.e. just like UDP encapsulation for NAT-traversal can be > do. This would mean that the WESP processing could be applied after > the normal ESP processing, and WESP would simply add extra header to > the beginning, and nothing else. The current draft already makes sure > all the fields in the WESP header are verified by the IPsec recipient > thus there is really no need to add ICV to cover them (if extensions > are added then ICV needs cover them, which makes it impossible to > implement WESP as incremental change to ESP). Yes -- this would allow WESP to be an attribute one adds to an ESP SA. Not unlike NAT-Traversal, it could be negotiated by IKE. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 12:27 AM +0200 1/5/10, Yaron Sheffer wrote: Hi, We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision? My previous message describing why I think the current design is seriously flawed provided the rationale for my NO response to this question. WESP as a modular, separate, nested protocol would be preferable. - The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision? I am concerned about the wording of the penultimate sentence above. Several folks argued against applying WESP to encrypted traffic and they cited various reasons for why this might be inappropriate. You did not choose to cite those reasons, which I think may bias responses. I think the two major issues cited re the extension of WESP to encrypted traffic are: - it is formally outside the charter - no good WESP extensions have been proposed for encrypted traffic Even if WESP is approved for use with encrypted traffic, that does not mean that it will supplant ESP. ESP still has a smaller header than WESP, so for environments where there is no intent to accommodate middlebox snooping, ESP is still preferable. So, NO to this question as well. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
Yes to both, based on arguments already discussed numerous times in the WG via presentations, 12 iterations of the draft and multiple WG last calls + AD reviews! The main motivation for extending the ICV was to counter some of the issues originally raised by Steve Kent - malicious entities modifying portions of the WESP header to bypass legitimate parsing of the packet by Trusted Intermediary (TI) devices such as IDS/IPS/etc. This can be addressed by the recipient explicitly validating the WESP header before accepting the packet or implicitly by including the WESP header as part of the ICV check. The motivation for allowing WESP to be used for encrypted data was brought up as a consistency argument and also allows for future extensibility in a uniform manner. I agree that this was not part of the original charter, as shown in the earlier revisions of the WESP drafts. BUT, this was discussed numerous times within the WG (including an open ticket on scope) and it was agreed that this would be a useful bit to include in the flags, hence introduced in the latter revisions of the draft. Note that this does not mandate using WESP for encrypted traffic, but allows it as optional and can be dictated as part of the session setup based on local policy. Another benefit may be that in running mixed mode environments (encrypted + ESP_NULL traffic), it allows for an explicit distinction from the packet that certain traffic is encrypted and other traffic is not. Otherwise, one would use ESP and WESP in these mixed mode environments and to be absolutely sure if ESP traffic is encrypted or not, would need to fall back to heuristics, which somewhat defeats the object of having this spec. I am certainly not a fan of heuristics, as it is complex, non-deterministic, will require updates for new algorithms added into ESP, as well as other arguments already cited numerous times, so would like to see a consistent deterministic way to identify the traffic. Thanks, - Ken >-Original Message- >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >Of Yaron Sheffer >Sent: Monday, January 04, 2010 2:27 PM >To: ipsec@ietf.org >Subject: [IPsec] Traffic visibility - consensus call > >Hi, > >We have had a few "discusses" during the IESG review of the WESP draft. >To help resolve them, we would like to reopen the following two >questions to WG discussion. Well reasoned answers are certainly >appreciated. But plain "yes" or "no" would also be useful in judging the >group's consensus. > >- The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme- >traffic-visibility-11) defines the ESP trailer's ICV calculation to >include the WESP header. This has been done to counter certain attacks, >but it means that WESP is no longer a simple wrapper around ESP - ESP >itself is modified. Do you support this design decision? > >- The current draft allows WESP to be applied to encrypted ESP flows, in >addition to the originally specified ESP-null. This was intended so that >encrypted flows can benefit from the future extensibility offered by >WESP. But arguably, it positions WESP as an alternative to ESP. Do you >support this design decision? > >Thanks, > Yaron >___ >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] Traffic visibility - consensus call
Yes to both questions. But I'd also like to question the process being followed. We've discussed these points numerous times in f2f meetings, on the mailing list, at virtual interims, etc. So I'm surprised to see the already established consensus being questioned all over again. Some of the arguments claim lack of attention, whereas they have been intense and prolific discussions on WESP, and thankfully so (e.g., including but not limited to spawning of Tero's heuristics draft and the motivation for the modified ICV coverage to address Steve's comment). But even if folks had not paid attention, that is no excuse for derailing the process. I disagree that WESP encryption is out of scope. It certainly is. There is a need per the charter for a mechanism to "easily and reliably" determine the type of traffic. Within an organization, it would be much easier to use WESP encryption as an alternative to ESP. If one sees ESP packets, then one would have to run heuristics with all the pertaining issues as explained in Manav's recent message, and higher cost associated (particularly, in stateless high aggregation points). WESP with encryption support would allow an organization to simplify rules and inspection devices. Sure, the WESP header adds more bytes, but the tradeoff is that there is no need for costly heuristics throughout the network. Without WESP encryption, the charter item does not have a complete solution. Just to be clear: I'm not saying that WESP is a general replacement for ESP. As Steve Kent points out, where there are no trusted intermediary inspection devices (i.e., outside of medium to large organizations) there is no need for end-nodes to collaborate with the inspecting infrastructure, hence no need for WESP. ESP is fine. Perhaps this is the disconnect that is happening: traditionally, the focus of the IPsec WG has been on such external applications (VPN), whereas WESP and future potential extensibility is more valuable within organizations. Such value may not be as obvious to VPN folks. Gabriel - Original Message > From: "Grewal, Ken" > To: Yaron Sheffer ; "ipsec@ietf.org" > Sent: Tue, January 5, 2010 10:14:43 AM > Subject: Re: [IPsec] Traffic visibility - consensus call > > Yes to both, based on arguments already discussed numerous times in the WG > via > presentations, 12 iterations of the draft and multiple WG last calls + AD > reviews! > > The main motivation for extending the ICV was to counter some of the issues > originally raised by Steve Kent - malicious entities modifying portions of > the > WESP header to bypass legitimate parsing of the packet by Trusted > Intermediary > (TI) devices such as IDS/IPS/etc. This can be addressed by the recipient > explicitly validating the WESP header before accepting the packet or > implicitly > by including the WESP header as part of the ICV check. > > The motivation for allowing WESP to be used for encrypted data was brought up > as > a consistency argument and also allows for future extensibility in a uniform > manner. I agree that this was not part of the original charter, as shown in > the > earlier revisions of the WESP drafts. > BUT, this was discussed numerous times within the WG (including an open > ticket > on scope) and it was agreed that this would be a useful bit to include in the > flags, hence introduced in the latter revisions of the draft. Note that this > does not mandate using WESP for encrypted traffic, but allows it as optional > and > can be dictated as part of the session setup based on local policy. Another > benefit may be that in running mixed mode environments (encrypted + ESP_NULL > traffic), it allows for an explicit distinction from the packet that certain > traffic is encrypted and other traffic is not. Otherwise, one would use ESP > and > WESP in these mixed mode environments and to be absolutely sure if ESP > traffic > is encrypted or not, would need to fall back to heuristics, which somewhat > defeats the object of having this spec. > > I am certainly not a fan of heuristics, as it is complex, non-deterministic, > will require updates for new algorithms added into ESP, as well as other > arguments already cited numerous times, so would like to see a consistent > deterministic way to identify the traffic. > > Thanks, > - Ken > > > >-Original Message- > >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > >Of Yaron Sheffer > >Sent: Monday, January 04, 2010 2:27 PM > >To: ipsec@ietf.org > >Subject: [IPsec] Traffic visibility - consensus call > > > >Hi, > > > >We have had a few "discusses" during the IESG review of the WESP draft. > >To help resolve them, we would like to reopen the following two > >questions to WG discussion. Well reasoned answers are certainly > >appreciated. But plain "yes" or "no" would also be useful in judging the > >group's consensus. > > > >- The current draft (http://tools.iet
Re: [IPsec] Traffic visibility - consensus call
At 11:08 AM -0800 1/5/10, gabriel montenegro wrote: >But I'd also like to question the process being followed. And I would like to answer. In short: the IESG is responsible for the output of the IETF. This is one such output. The IESG chartered the WG for a particular item, and there is a question about whether what we produced matches that charter, and if it doesn't, is it still OK. >We've discussed these points numerous times >in f2f meetings, on the mailing list, at virtual interims, etc. So I'm >surprised to see the already >established consensus being questioned all over again. The IESG was not part of those discussions; they are reviewing the work that this WG sent to them. >But even if folks had not paid attention, that is no excuse for derailing the >process. A consensus call is not "derailing the process": it is just the opposite. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
I fully agree that a consensus call is an integral part of the IETF process. But what we're seeing here is not one but a plurality of consensus calls. I would have expected the response to the IESG to be: yes, this was the consensus arrived in the WG at time X, here are further details, etc. What we're seeing is: oh, ok, let's do it all over again. - Original Message > From: Paul Hoffman > To: gabriel montenegro ; "ipsec@ietf.org" > > Sent: Tue, January 5, 2010 11:14:36 AM > Subject: Re: [IPsec] Traffic visibility - consensus call > > At 11:08 AM -0800 1/5/10, gabriel montenegro wrote: > >But I'd also like to question the process being followed. > > And I would like to answer. In short: the IESG is responsible for the output > of > the IETF. This is one such output. The IESG chartered the WG for a particular > item, and there is a question about whether what we produced matches that > charter, and if it doesn't, is it still OK. > > >We've discussed these points numerous times > >in f2f meetings, on the mailing list, at virtual interims, etc. So I'm > surprised to see the already > >established consensus being questioned all over again. > > The IESG was not part of those discussions; they are reviewing the work that > this WG sent to them. > > >But even if folks had not paid attention, that is no excuse for derailing > >the > process. > > A consensus call is not "derailing the process": it is just the opposite. > > --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, 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 > > > > 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 > > > > sen
Re: [IPsec] Traffic visibility - consensus call
At 11:25 AM -0800 1/5/10, gabriel montenegro wrote: >I fully agree that a consensus call is an integral part of the IETF process. > >But what we're seeing here is not one but a plurality of consensus calls. The two questions that Yaron asked are related to the questions from the IESG. >I would have expected the response to the IESG to be: yes, this was the >consensus arrived >in the WG at time X, here are further details, etc. The IESG fully understands that there was rough consensus; that's not what they are asking. They want to know if there was a strong consensus, and did we see that we were straying from the charter. >What we're seeing is: oh, ok, let's do it all over again. That is one possibility; another is "OK, that's fine". But it is the IESG that gets to make that determination, not the WG. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
Yes to both. To elaborate on what Ken said, here's an explicit scenario that requires the encrypted bit for WESP, fully within the current charter of enabling ESP-NULL inspection. Transport policies for within an organization that want to enable intermediary inspection of ESP-NULL non-heurisitically. Organization has a mix of version of systems. Sample policy: When talking to/from non-WESP capable machines: must do ESP-NULL only When both peers are WESP capable: do WESP/ESP-NULL most places. However, where policy requires encryption, do WESP/ESP. Only with the WESP encrypt bit can intermediaries distinguish what is going on here, and still enable the uplevel systems to do full encryption where needed. I.e. if they see ESP, it must be ESP-NULL. If they see WESP, then they must leverage the encrypt bit to see what to do. Hence we need to keep the encrypted bit to satisfy the current WESP charter item. bs -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Monday, January 04, 2010 2:27 PM To: ipsec@ietf.org Subject: [IPsec] Traffic visibility - consensus call Hi, We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision? - The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision? Thanks, Yaron ___ 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] Traffic visibility - consensus call
Yes and Yes. We see a lot of value in taking advantage of the extensibility of the protocol as it stands in the WESP today. Allowing WESP to not be simply a wrapper, and enabling encryption support are both fundamental for the future extensibilities. So we express our support of the these design decisions. Mark -Original Message- Date: Tue, 5 Jan 2010 00:27:26 +0200 From: Yaron Sheffer Subject: [IPsec] Traffic visibility - consensus call To: "ipsec@ietf.org" Hi, We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus. - The current draft (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines the ESP trailer's ICV calculation to include the WESP header. This has been done to counter certain attacks, but it means that WESP is no longer a simple wrapper around ESP - ESP itself is modified. Do you support this design decision? - The current draft allows WESP to be applied to encrypted ESP flows, in addition to the originally specified ESP-null. This was intended so that encrypted flows can benefit from the future extensibility offered by WESP. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision? Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
Gabriel: This is being discussed to resolve the concerns that I raised in IESG Evaluation. When this work was chartered, I expected as simple wrapper. The charter says: > - 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. I think the chartering discussion would have been very different had the charter said that the proposed WG would develop an alternative to ESP. Russ On 1/5/2010 2:08 PM, gabriel montenegro wrote: But I'd also like to question the process being followed. We've discussed these points numerous times in f2f meetings, on the mailing list, at virtual interims, etc. So I'm surprised to see the already established consensus being questioned all over again. ___ 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 see that it was no longer a neatly-la
Re: [IPsec] Traffic visibility - consensus call
Hi Russ, Some of us believe that allowing WESP to carry encrypted packets is within the charter (there's some recent messages today to this effect). Unfortunately, there's been wording along the lines that the working group realized it was going off-charter, but no such conclusion has been arrived at (and some of us don't share it). Without this capability, there is not a complete solution for the charter item as one might still have to use heuristics which has some limitations and cost (e.g., per Manav's recent message). Additionally, allowing WESP to carry encrypted packets does not (at least in my mind) make it a general alternative for ESP. WESP has certain applicabilities, and when cooperating with intermediaries is not an issue (e.g., outside of organizational deployments) one could use encrypted ESP packets instead. thanks, Gabriel - Original Message > From: Russ Housley > To: gabriel montenegro > Cc: "ipsec@ietf.org" > Sent: Tue, January 5, 2010 1:11:19 PM > Subject: Re: [IPsec] Traffic visibility - consensus call > > Gabriel: > > This is being discussed to resolve the concerns that I raised in IESG > Evaluation. > > When this work was chartered, I expected as simple wrapper. The charter says: > > > - 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. > > I think the chartering discussion would have been very different had the > charter > said that the proposed WG would develop an alternative to ESP. > > Russ > > On 1/5/2010 2:08 PM, gabriel montenegro wrote: > > But I'd also like to question the process being followed. We've discussed > these points numerous times in f2f meetings, on the mailing list, at virtual > interims, etc. So I'm surprised to see the already established consensus > being > questioned all over again. > > ___ > 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] Traffic visibility - consensus call
I'll resend my message from earlier today that gives a concrete scenario for why the WESP encryption bit is in charter. To satisfy the existing charter item, we need a deployable solution, which entails working with legacy systems that don't support this functionality yet. Here's an explicit scenario that requires the encrypted bit for WESP, fully within the current charter of enabling ESP-NULL inspection. Transport policies for within an organization that want to enable intermediary inspection of ESP-NULL non-heurisitically. Organization has a mix of version of systems. Sample policy: When talking to/from non-WESP capable machines: must do ESP-NULL only When both peers are WESP capable: do WESP/ESP-NULL most places. However, where policy requires encryption, do WESP/ESP. Only with the WESP encrypt bit can intermediaries distinguish what is going on here, and still enable the uplevel systems to do full encryption where needed. I.e. if they see ESP, it must be ESP-NULL. If they see WESP, then they must leverage the encrypt bit to see what to do. Hence we need to keep the encrypted bit to satisfy the current WESP charter item. bs -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of gabriel montenegro Sent: Tuesday, January 05, 2010 1:32 PM To: Russ Housley Cc: ipsec@ietf.org Subject: Re: [IPsec] Traffic visibility - consensus call Hi Russ, Some of us believe that allowing WESP to carry encrypted packets is within the charter (there's some recent messages today to this effect). Unfortunately, there's been wording along the lines that the working group realized it was going off-charter, but no such conclusion has been arrived at (and some of us don't share it). Without this capability, there is not a complete solution for the charter item as one might still have to use heuristics which has some limitations and cost (e.g., per Manav's recent message). Additionally, allowing WESP to carry encrypted packets does not (at least in my mind) make it a general alternative for ESP. WESP has certain applicabilities, and when cooperating with intermediaries is not an issue (e.g., outside of organizational deployments) one could use encrypted ESP packets instead. thanks, Gabriel - Original Message > From: Russ Housley > To: gabriel montenegro > Cc: "ipsec@ietf.org" > Sent: Tue, January 5, 2010 1:11:19 PM > Subject: Re: [IPsec] Traffic visibility - consensus call > > Gabriel: > > This is being discussed to resolve the concerns that I raised in IESG > Evaluation. > > When this work was chartered, I expected as simple wrapper. The charter says: > > > - 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. > > I think the chartering discussion would have been very different had the > charter > said that the proposed WG would develop an alternative to ESP. > > Russ > > On 1/5/2010 2:08 PM, gabriel montenegro wrote: > > But I'd also like to question the process being followed. We've discussed > these points numerous times in f2f meetings, on the mailing list, at virtual > interims, etc. So I'm surprised to see the already established consensus > being > questioned all over again. > > ___ > 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] Traffic visibility - consensus call
Gabriel: Some of us believe that allowing WESP to carry encrypted packets is within the charter (there's some recent messages today to this effect). Unfortunately, there's been wording along the lines that the working group realized it was going off-charter, but no such conclusion has been arrived at (and some of us don't share it). I see the discussion, but so far, I am not convinced by it. I'm still listening ... Additionally, allowing WESP to carry encrypted packets does not (at least in my mind) make it a general alternative for ESP. WESP has certain applicabilities, and when cooperating with intermediaries is not an issue (e.g., outside of organizational deployments) one could use encrypted ESP packets instead. It is a replacement (as opposed to a wrapper) if the portions of the packet that are covered by the ICV are different. Russ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
Yaron, On Tue, Jan 5, 2010 at 3:57 AM, Yaron Sheffer wrote: > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To > help resolve them, we would like to reopen the following two questions to WG > discussion. Well reasoned answers are certainly appreciated. But plain "yes" > or "no" would also be useful in judging the group's consensus. > > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines > the ESP trailer's ICV calculation to include > the WESP header. This has been > done to counter certain attacks, but it means that WESP is no longer a simple > wrapper around > ESP - ESP itself is modified. Do you support this design > decision? I had brought this up on the mailing list some time back that WESP now is not a mere "wrapper" over the ESP and is almost like a new protocol, which it anyways was designed to be. I dont see an issue with that. I dont hold a very strong opinion on whether we should include the WESP protocol header inside the ESP calculation or not and am also fine with the end nodes just doing a sanity check to ensure that things look alright when they receive the WESP protocol packets. > > - The current draft allows WESP to be applied to encrypted ESP flows, in > addition to the originally specified ESP-null. This was intended so that > encrypted flows can benefit from the future extensibility offered by WESP. And i strongly agree with this. It would be severely limiting to see WESP being only used for ESP-NULL cases. I see absolutely no harm in using WESP for encrypted traffic too. I agree with others on the list that by having WESP do encryption we provide the middle boxes with an easy/deterministic way to discriminate between integrity protected and encrypted packets, which is what we were chartered to do. I am not a big fan of flow based devices as these get really too hot to handle in scaled up networks and heuristics seems like a juvenile attempt at solving the problem. There have been various mails in the past about the issues in that scheme and i dont intend to rehash them here, so i'll this here. > But arguably, it positions WESP as an alternative to ESP. > It does not. ESP still has its own place and i dont see how having WESP ship ESP encrypted packets makes it a substitute of ESP. WESP will be required in the environments wherever we require deep inspection while ESP will continue where its not. > Do you support this design decision? Yes, i do. Jack > > Thanks, > Yaron > ___ > 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] Traffic visibility - consensus call
Gabriel Montenegro wrote: > Just to be clear: I'm not saying that WESP is a general replacement for ESP. > As Steve Kent points out, where there are no trusted intermediary inspection > devices (i.e., outside of medium to large organizations) there is no need > for end-nodes to collaborate with the inspecting infrastructure, hence no > need for WESP. ESP is fine. Perhaps this is the disconnect that is happening: > traditionally, the focus of the IPsec WG has been on such external > applications > (VPN), whereas WESP and future potential extensibility is more valuable > within > organizations. Such value may not be as obvious to VPN folks. This sounds like an argument for being able to strip off the internal network WESP header at a perimeter intermediate system. That same perimeter box can apply Tero's heuristics and then add the header for so the intermediate systems don't need to. Voila, instant upgrade value for the VPN folks. Which, of course, would not be possible with the ICV over the WESP header. On the other hand, I don't really buy the 'slippery slope' arguments. I have read the charter for this work item over a couple of times and WESP with encryption still looks consistent to me. So, here's my opinion: - YES on allowing use of WESP when using ESP with encryption - NO on including the WESP header in the ICV calculation, the endpoints have to deal with attacks in any case. By the way, WESP extension drafts that propose arbitrary new mutable fields for use with ESP just reinforce that NO. Thanks, --Joe ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
> Even if WESP is approved for use with encrypted traffic, that does not mean > that it will supplant ESP. ESP still has a smaller header than WESP, so for > environments where there is no intent to accommodate middlebox snooping, ESP > is still preferable. I agree with Steve here that extending WESP to support encryption does not mean that it will be replacing ESP. The latter would still get used, as i noted in my earlier email, in environments where there is no need for deep packet inspection. Jack ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
> There is a need per the charter for a mechanism to > "easily and reliably" determine the type of traffic. Within an organization, > it would be much easier to use > WESP encryption as an alternative to ESP. If one sees ESP packets, then one > would have to run heuristics > with all the pertaining issues as explained in Manav's recent message, and > higher cost associated > (particularly, in stateless high aggregation points). WESP with encryption > support would allow an > organization to simplify rules and inspection devices. Sure, the WESP header > adds more bytes, but the > tradeoff is that there is no need for costly heuristics throughout the > network. Without WESP encryption, > the charter item does not have a complete solution. I agree. I, like others, and unlike the authors of heuristics, would never like to see heuristics implemented in a network, because it is not going to work. Period. It requires too much from the devices to do, and its simply not practical (refer to past mails in the WG list). One can clearly gauge the interest in heuristics vis-a-vis WESP by the amount of mails and the review comments that have been sent/exchanged. WESP provides a simple, clean, deterministic way to disambiguate between encrypted and unencrypted traffic and i would like to see it this way. > > Just to be clear: I'm not saying that WESP is a general replacement for ESP. > As Steve Kent points out, > where there are no trusted intermediary inspection devices (i.e., outside of > medium to large organizations) > there is no need for end-nodes to collaborate with the inspecting > infrastructure, hence no need for > WESP. ESP is fine. I agree and would like to stress that WESP is not a replacement for ESP. I repeat for the benefit of others that extending WESP to carry encrypted packets does not mean that it is replacing ESP. Jack ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
Russ, > > It is a replacement (as opposed to a wrapper) if the portions of the packet > that are covered by the ICV are different. Would it help if WESP is renamed to something else? Since we're discussing the fundamental principles of the protocol, i see no reason why we cant change the name, if that helps. I think its the "Wrapped" in the WESP thats causing most heart burn, lets change that to something else .. something thats appeases everyone. Jack ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
Hi Russ, > > - 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. > > I think the chartering discussion would have been very > different had the > charter said that the proposed WG would develop an alternative to ESP. I don't think WESP is in any sense an alternative to ESP and I believe we did stick to the charter, which was to provide a *deterministic* way to disambiguate different ESP packets. I understand that the word "deterministic" is missing from the charter text, but it was obvious to everyone working in IPSec that WESP was to be a *deterministic* solution. Now, assume that we limit WESP for only ESP-NULL. If this is done, how can a middle box deterministically know that the ESP packet that it sees is an encrypted ESP packet or an ESP packet carrying ESP-NULL payload. The middleboxes will now be forced to apply heuristics just to be sure that the packet is indeed an encrypted ESP packet. This would defeat the purpose of having WESP in the network. So, when including the encryption bit in the WESP header we never thought that it was out of the charter (as others have also noted in the mailing list) as it was really being used to provide a deterministic answer to whether the packet was encrypted or not. We really don't have a complete solution if we don't include the encryption bit in the WESP header. Cheers, Manav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
Russ, I think we agree here: the end nodes need to validate the WESP header info. As I noted before, one could do this by modifying the ICV or by explicitly checking those WESP fields at the end nodes. I think there has been enough feedback to the effect that modifying the ICV is overkill and has some down sides. So, ok, I think in the next rev of the draft we should go back to *not* modifying the ICV (i.e., not including the WESP header fields in the ICV). This would leave WESP as a wrapper (as it started). The other threads and messages are hopefully addressing your other concerns. thanks, Gabriel - Original Message > From: Russ Housley > To: gabriel montenegro > Cc: "ipsec@ietf.org" > Sent: Tue, January 5, 2010 2:52:24 PM > Subject: Re: [IPsec] Traffic visibility - consensus call > > Gabriel: > > > Some of us believe that allowing WESP to carry encrypted packets is within > > the > charter > > (there's some recent messages today to this effect). Unfortunately, there's > been wording along the lines > > that the working group realized it was going off-charter, but no such > conclusion has been > > arrived at (and some of us don't share it). > > I see the discussion, but so far, I am not convinced by it. I'm still > listening > ... > > > Additionally, allowing WESP to carry encrypted packets does not (at least > > in > my mind) > > make it a general alternative for ESP. WESP has certain applicabilities, > > and > when > > cooperating with intermediaries is not an issue (e.g., outside of > organizational deployments) > > one could use encrypted ESP packets instead. > > It is a replacement (as opposed to a wrapper) if the portions of the packet > that > are covered by the ICV are different. > > 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] Traffic visibility - consensus call
Yes to both. Zhen China Mobile On Tue, Jan 5, 2010 at 6:27 AM, Yaron Sheffer wrote: > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To > help resolve them, we would like to reopen the following two questions to WG > discussion. Well reasoned answers are certainly appreciated. But plain "yes" > or "no" would also be useful in judging the group's consensus. > > - The current draft ( > http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) > defines the ESP trailer's ICV calculation to include the WESP header. This > has been done to counter certain attacks, but it means that WESP is no > longer a simple wrapper around ESP - ESP itself is modified. Do you support > this design decision? > Yes, we need to protect the message integrity while offering traffic visibility. > > - The current draft allows WESP to be applied to encrypted ESP flows, in > addition to the originally specified ESP-null. This was intended so that > encrypted flows can benefit from the future extensibility offered by WESP. > But arguably, it positions WESP as an alternative to ESP. Do you support > this design decision? > Yes, future extensibility is a feature that will benefit traffic control for operators and other entities. > Thanks, > Yaron > ___ > 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 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
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] Traffic visibility - consensus call
> Would it help if WESP is renamed to something else? Since we're > discussing the fundamental principles of the protocol, i see no reason > why we cant change the name, if that helps. I think its the "Wrapped" > in the WESP thats causing most heart burn, lets change that to > something else .. something thats appeases everyone. I agree. How about VESP - "Visible ESP" ? Its phonetically the same as WESP. :) I agree that WESP should not be clipped to only support ESP-NULL; it should be able to carry encrypted packets as well. Without this the middle boxes would never know whether the ESP packet thats passing is encrypted or not. One way could be to deprecate the use of ESP-NULL in ESP, which would mean that if someone sees an ESP packet then it MUST be an encrypted packet. This is as i understand impossible, so the only option left is to let WESP also carry encrypted packets. Sriram ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
