Subject: Re: [IPsec] Issue #131: Returning TEMPORARY_FAILURE: MUST or SHOULD?

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 Jan 2010 17:13:30 -0800

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

---

From: Keith Welter <[email-masked]>
Date: Tue, 12 Jan 2010 14:03:14 -0800

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-masked]>
> Subject: Re: [IPsec] Issue #131: Returning TEMPORARY_FAILURE: MUST or
>    SHOULD?
> To: IPsecme WG <[email-masked]>
> Message-ID: <p06240804c7702b9454ff@[10.20.30.158]>
> Content-Type: text/plain; charset="us-ascii"
> 
> ------------------------------
> 
> Message: 6
> Date: Sun, 10 Jan 2010 17:15:54 -0800
> From: Paul Hoffman <[email-masked]>
> Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06
>    (yes, IKEv2-bis!)
> To: Yaron Sheffer <[email-masked]>, "[email-masked]"
>    <[email-masked]>
> Message-ID: <p06240805c7702c147313@[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-masked]>
> Subject: Re: [IPsec] Traffic visibility - consensus call
> To: Yaron Sheffer <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> 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-masked] [mailto:[email-masked]
> <javascript:main.compose('new', 't=[email-masked]')> ] On Behalf 
Of
> Yaron Sheffer
> Sent: Tuesday, January 05, 2010 6:27 AM
> To: [email-masked]
> 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-masked]
> 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-masked]>
> Subject: Re: [IPsec] Traffic visibility - consensus call
> To: <[email-masked]>
> Cc: [email-masked]
> Message-ID:
> 
<[email-masked]>
> 
> 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-masked]>
> Subject: Re: [IPsec] Traffic visibility - consensus call
> To: "[email-masked]" <[email-masked]>,
>    "[email-masked]"   <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Message-ID:
> 
<[email-masked]>
> 
> 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-masked] [mailto:[email-masked]] 
> > On Behalf Of [email-masked]
> > Sent: Monday, January 11, 2010 1.59 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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-masked]
> > https://www.ietf.org/mailman/listinfo/ipsec
> > 
> 
> ------------------------------
> 
> Message: 10
> Date: Mon, 11 Jan 2010 01:23:48 -0800 (PST)
> From: "Dan Harkins" <[email-masked]>
> Subject: Re: [IPsec] Traffic visibility - consensus call
> To: "Bhatia, Manav (Manav)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,   "[email-masked]"
>    <[email-masked]>,   "[email-masked]" 
<[email-masked]>
> Message-ID:
>    <[email-masked]>
> 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-masked] [mailto:[email-masked]]
> >> On Behalf Of [email-masked]
> >> Sent: Monday, January 11, 2010 1.59 PM
> >> To: [email-masked]
> >> Cc: [email-masked]
> >> 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-masked]
> >> https://www.ietf.org/mailman/listinfo/ipsec
> >>
> > _______________________________________________
> > IPsec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> End of IPsec Digest, Vol 69, Issue 31
> *************************************