Subject: [IPsec] WESP questions

From: Dan McDonald <[email-masked]>
Date: Wed, 18 Feb 2009 11:48:58 -0500

Some quick/dirty WESP questions.

1.) Can I use WESP with IKEv1 also?  I don't see why not, but maybe we are
    using WESP as an incentive to move people to IKEv2?

2.) Is it permitted to use non-NULL encryption with WESP?  I'm hoping the
    answer is NO, but I didn't see any such language in the November 2008
    draft.

Thanks,
Dan

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Feb 2009 22:05:26 +0200

Note: personal opinions below.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dan McDonald
> Sent: Wednesday, February 18, 2009 18:49
> To: [email-masked]
> Subject: [IPsec] WESP questions
> 
I don't believe in this kind of incentives. IKEv2 has to win its market share based on its own merits. That said, the WG should definitely focus on IKEv2. So we should now consider WESP in the context of IKEv2 only, and if needed (maybe not), publish a short IKEv1 document later.

>     answer is NO, but I didn't see any such language in the November 2008
I previously commented on the current draft that WESP had better support both null and non-null encryption. Much of the value in WESP is the extensibility it adds to ESP.

[Co-chair hat on:] The authors of this draft are kindly requested to start using our issue tracking application to track issues.

> Thanks,
> Dan
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.
> 
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point

---

From: Dan McDonald <[email-masked]>
Date: Wed, 18 Feb 2009 15:17:28 -0500

> Note: personal opinions below.

Understood...

> I don't believe in this kind of incentives. IKEv2 has to win its market
> share based on its own merits. That said, the WG should definitely focus on
> IKEv2. So we should now consider WESP in the context of IKEv2 only, and if
> needed (maybe not), publish a short IKEv1 document later.

Okay.

> I previously commented on the current draft that WESP had better support
> both null and non-null encryption. Much of the value in WESP is the
> extensibility it adds to ESP.

I missed that thread -- sorry.

To be honest, it's not a BIG deal either way, but I do think it should be
clarified in the document to prevent confusion.  I'm thinking about the
implementation issues as I ask.  In particular, when this gets build I want
to update the ipsec(7p) and ipsecesp(7p) man pages to document how insecure
your packets become using WESP with encryption.

> [Co-chair hat on:] The authors of this draft are kindly requested to start
> using our issue tracking application to track issues.

Don't look at me!  :)

Dan

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 18 Feb 2009 13:47:23 -0700

Agree with Yaron. 
IKEv2 will be the target for negotiating WESP. Unless there is a demand for IKEv1 support also, it probably doesn't make sense to retro-fit this in IKEv1, even though it will be a minor change. 

We did have a small discussion around supporting null and non-null (a.k.a. integrity bit in the original WESP draft) and can continue this discussion on the mailing list.  

I will start logging these items using the issue tracking system.

Thanks, 
- Ken

>Sent: Wednesday, February 18, 2009 12:17 PM
>To: [email-masked]
>Subject: Re: [IPsec] WESP questions
>

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 18 Feb 2009 23:00:26 +0200

[snip]
> your packets become using WESP with encryption.
Insecure why? There MUST be no security degradation when we're done with this draft.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Feb 2009 15:08:32 +0200

>     using WESP as an incentive to move people to IKEv2?

I do not see any point of standardizing anything to already obsoleted
protocol, so I would say IKEv2 only.

I also personally do not see any way I would be ever implementing WESP
negotiation to our IKEv1 library...

Also the current draft refers to RFC4303 (ESP) and RFC 4302 (AH) which
are for RFC4301 and IKEv2.

Also knowing how long it will take before this will be used widely, I
do not think limiting it to IKEv2 only is going to cause problems.  

>     answer is NO, but I didn't see any such language in the November 2008

As the draft includes second unencrypted copy of the next header
field, I myself assumed it is not limited to ESP-NULL. If it is
limited to ESP NULL, then it would be better to only use one next
header field.

It also says the next header field in the WESP header might be zero
for "security concerns"...
-- 
[email-masked]

---

From: Dan McDonald <[email-masked]>
Date: Thu, 19 Feb 2009 09:29:03 -0500

> Insecure why? There MUST be no security degradation when we're done with this draft.

My bad.  I didn't see this text during my first read-through:

	Note: For security concerns, this value may optionally be set to
	zero, in which case the next header an be extracted from the ESP
	trailer.

So for encrypted packets, I would recommend this value MUST be zero.

Pardon my panic,
Dan

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 19 Feb 2009 17:52:56 +0200

This is worthy of a TRAC issue.

	Yaron

> From: Dan McDonald [mailto:[email-masked]]
> Sent: Thursday, February 19, 2009 16:29
> To: Yaron Sheffer
> Cc: [email-masked]