The "MUST return TEMPORARY_FAILURE" wording was not in the text proposed by the issue #22 design team. The original wording was "will return TEMPORARY_FAILURE". Had the team carefully considered a SHOULD versus MUST in this case I suspect we would have picked "SHOULD". Anyway, my vote is for "SHOULD return TEMPORARY_FAILURE" in section 2.8.2
> Message: 5 > Date: Sun, 10 Jan 2010 17:13:30 -0800 > From: Paul Hoffman <[email protected]> > Subject: Re: [IPsec] Issue #131: Returning TEMPORARY_FAILURE: MUST or > SHOULD? > To: IPsecme WG <[email protected]> > Message-ID: <p06240804c7702b945...@[10.20.30.158]> > Content-Type: text/plain; charset="us-ascii" > > At 2:29 PM -0800 12/16/09, Paul Hoffman wrote: > >Section 2.8.2 Simultaneous IKE SA Rekeying states: > > > > If only one peer detects a simultaneous rekey, redundant SAs > > are not created. In this case, when the peer that did not notice the > > simultaneous rekey gets the request to rekey the IKE SA that it has > > already successfully rekeyed, it MUST return TEMPORARY_FAILURE > > because it is an IKE SA that it is currently trying to close (whether > > or not it has already sent the delete notification for the SA). > > > >Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states: > > > > If a peer receives a request to close an IKE SA that it is > > currently trying to close, it SHOULD reply as usual, and forget about > > its own close request. > > > >Based on the text in Section 2.25.2 it seems that perhaps the MUST in > >Section 2.8.2 is really a SHOULD. Or, based on the text in 2.8.2, the > >SHOULD in 2.25.2 should be a MUST. > > This got no response; does anyone have an opinion? > > --Paul Hoffman, Director > --VPN Consortium > > > ------------------------------ > > Message: 6 > Date: Sun, 10 Jan 2010 17:15:54 -0800 > From: Paul Hoffman <[email protected]> > Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 > (yes, IKEv2-bis!) > To: Yaron Sheffer <[email protected]>, "[email protected]" > <[email protected]> > Message-ID: <p06240805c7702c147...@[10.20.30.158]> > Content-Type: text/plain; charset="us-ascii" > > At 11:04 AM +0200 12/10/09, Yaron Sheffer wrote: > >This is to begin a 4 week working group last call for draft-ietf-ipsecme- > ikev2bis-06. The target status for this document is Proposed Standard, obsoleting > RFC 4306 and RFC 4718. > > > >Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to this message. > > We hae overshot that by a bit, and there are still three open issues. Please send > in any last-minute WG LC comments in the next day or two, if you would. > > --Paul Hoffman, Director > --VPN Consortium > > > ------------------------------ > > Message: 7 > Date: Mon, 11 Jan 2010 14:37:48 +0800 > From: Min Huang <[email protected]> > Subject: Re: [IPsec] Traffic visibility - consensus call > To: Yaron Sheffer <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > YES to both. > > The WESP header provides a kind of rapid *deterministic* detection method > for ESP_NULL packet. The heuristics method is too complex and it calls for > more computing resource and computing time. I doubt the middle box whether > will support the heuristics method for ESP_NULL detection. Although > including the WESP header into ESP ICV calculation seems modifying ESP, it > is necessary to check the WESP header integrity for counter certain attacks. > The explicit WESP integrity calculation is OK for me, too. > > I support WESP for encrypted ESP flow. WESP has the capacity to provide > more functions by future extensibility than just traffic visibility for > ESP_NULL. Nowadays ESP is used much more widely for encrypted flow than > ESP_NULL flow. It is meaningful for middle detection machines to have the > ability to detecting encrypted traffic. And then WESP could provide this > kind of traffic visibility for both encrypted flow and unencrypted flow in > future. > > regards, > Min > > > -----Original Message----- > From: [email protected] [mailto:[email protected] > <javascript:main.compose('new', '[email protected]')> ] On Behalf Of > Yaron Sheffer > Sent: Tuesday, January 05, 2010 6:27 AM > To: [email protected] > 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) > <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 > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> > > > > > ------------------------------ > > Message: 8 > Date: Mon, 11 Jan 2010 09:28:38 +0100 > From: <[email protected]> > Subject: Re: [IPsec] Traffic visibility - consensus call > To: <[email protected]> > Cc: [email protected] > Message-ID: > <808fd6e27ad4884e94820bc333b2db775840f4b...@nok-eumsg-01.mgdnok.nokia.com> > > Content-Type: text/plain; charset="us-ascii" > > Ken Grewal wrote: > > > The either-or on using an ICV or explicitly checking the WESP header > > on the recipient was based on the assumption that the threat does > > not come from the sender and only from some other malicious entity > > after the packet has been sent. > > > > This was the reason for simplifying the header check by using the > > ICV, instead of explicitly checking every field. > > Note that the current draft *does* explicitly check ever field. > Are you proposing removing those checks? > > Best regards, > Pasi > (not wearing any hats) > > > ------------------------------ > > Message: 9 > Date: Mon, 11 Jan 2010 14:32:55 +0530 > From: "Bhatia, Manav (Manav)" <[email protected]> > Subject: Re: [IPsec] Traffic visibility - consensus call > To: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]> > Message-ID: > <7c362eef9c7896468b36c9b79200d8350ab34bb...@inbansxchmbsa1.in.alcatel-lucent.com> > > Content-Type: text/plain; charset="us-ascii" > > I believe Ken is alluding to removing the WESP header from the ICV calculation, and > relying on explicitly checking the WESP header at the endnodes. > > Cheers, Manav > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > On Behalf Of [email protected] > > Sent: Monday, January 11, 2010 1.59 PM > > To: [email protected] > > Cc: [email protected] > > Subject: Re: [IPsec] Traffic visibility - consensus call > > > > Ken Grewal wrote: > > > > > The either-or on using an ICV or explicitly checking the WESP header > > > on the recipient was based on the assumption that the threat does > > > not come from the sender and only from some other malicious entity > > > after the packet has been sent. > > > > > > This was the reason for simplifying the header check by using the > > > ICV, instead of explicitly checking every field. > > > > Note that the current draft *does* explicitly check ever field. > > Are you proposing removing those checks? > > > > Best regards, > > Pasi > > (not wearing any hats) > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > > > ------------------------------ > > Message: 10 > Date: Mon, 11 Jan 2010 01:23:48 -0800 (PST) > From: "Dan Harkins" <[email protected]> > Subject: Re: [IPsec] Traffic visibility - consensus call > To: "Bhatia, Manav (Manav)" <[email protected]> > Cc: "[email protected]" <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain;charset=iso-8859-1 > > > Manav, > > So let's say the normal (removed WESP header) ICV calculations by > ESP are correct but something doesn't match between the (now unprotected) > WESP header and the rest of the packet. Why should the recipient care? > WESP is for middleboxes. The end node has an assurance that the > _meaningful_ portion of the frame was sent by the claimed sender and > was not modified in transit. Any decisions made by a middlebox that > might've involved an improperly modified WESP header are over and done > with. He doesn't care if the packet was properly handled by middleboxes > or not, he got it and it's correct. > > You trust the end nodes to negotiate WESP and encapsulate their ESP > packets in WESP but you don't trust the content they put into those > packets. Is that the trust model you're operating on? > > The more I think of this problem the more worthless WESP becomes. > > Dan. > > On Mon, January 11, 2010 1:02 am, Bhatia, Manav (Manav) wrote: > > I believe Ken is alluding to removing the WESP header from the ICV > > calculation, and relying on explicitly checking the WESP header at the > > endnodes. > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] > >> On Behalf Of [email protected] > >> Sent: Monday, January 11, 2010 1.59 PM > >> To: [email protected] > >> Cc: [email protected] > >> Subject: Re: [IPsec] Traffic visibility - consensus call > >> > >> Ken Grewal wrote: > >> > >> > The either-or on using an ICV or explicitly checking the WESP header > >> > on the recipient was based on the assumption that the threat does > >> > not come from the sender and only from some other malicious entity > >> > after the packet has been sent. > >> > > >> > This was the reason for simplifying the header check by using the > >> > ICV, instead of explicitly checking every field. > >> > >> Note that the current draft *does* explicitly check ever field. > >> Are you proposing removing those checks? > >> > >> Best regards, > >> Pasi > >> (not wearing any hats) > >> _______________________________________________ > >> IPsec mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > ------------------------------ > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > > End of IPsec Digest, Vol 69, Issue 31 > *************************************
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
