Subject: [IPsec] Call for agenda items

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Oct 2012 07:38:42 -0700

Greetings again. We have a 2-hour time slot in Atlanta, which is way more than we asked for. We don't need to be talking about draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and is being sent to the AD for review. This is a call for agenda items. Strong preference is given to those which are in the WG charter.

draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully there will be more discussion of it before the meeting

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 17 Oct 2012 16:52:32 +0200

A quick correction: the latest version of the now-finished draft has 
been renamed draft-ietf-ipsecme-ad-vpn-problem ("auto-discovery VPN", 
http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00).

Thanks,
	Yaron

On 10/17/2012 04:38 PM, Paul Hoffman wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Oct 2012 07:54:55 -0700

On Oct 17, 2012, at 7:52 AM, Yaron Sheffer <[email-masked]> wrote:

> A quick correction: the latest version of the now-finished draft has been renamed draft-ietf-ipsecme-ad-vpn-problem ("auto-discovery VPN", http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00).

Whoops, yes. An artifact of my sometimes-too-helpful personal document tracking system.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Oct 2012 17:09:42 +0200

On Oct 17, 2012, at 4:38 PM, Paul Hoffman wrote:

> Greetings again. We have a 2-hour time slot in Atlanta, which is way more than we asked for. We don't need to be talking about draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and is being sent to the AD for review. 

Are we going to have a contest for a solution document, similar to the one they had at httpbis?

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Oct 2012 08:30:12 -0700

> Are we going to have a contest for a solution document, similar to the one they had at httpbis?

Not in Atlanta, no, but maybe afterwards. To the best of my understanding, none of the proposals that we heard earlier have updated their drafts to say how they cover or don't cover what's in the requirements and scenarios document.

--Paul Hoffman

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 17 Oct 2012 17:32:15 -0700 (PDT)

On Wed, October 17, 2012 7:38 am, Paul Hoffman wrote:
> Greetings again. We have a 2-hour time slot in Atlanta, which is way more
> than we asked for. We don't need to be talking about
> draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and is
> being sent to the AD for review. This is a call for agenda items. Strong
> preference is given to those which are in the WG charter.

  I would be happy to discuss IKEv3. Please let me know if you'll put me
on the agenda and I'll prepare some slides to talk to.

  Dan.

> draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully
> there will be more discussion of it before the meeting
>
> --Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 18 Oct 2012 16:31:06 +0300

Paul Hoffman writes:
> Greetings again. We have a 2-hour time slot in Atlanta, which is way
> more than we asked for. We don't need to be talking about
> draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC
> and is being sent to the AD for review. This is a call for agenda
> items. Strong preference is given to those which are in the WG
> charter.

draft-ietf-ipsecme-p2p-vpn-problem?

I assume you mean draft-ietf-ipsecme-ad-vpn-problem-00?

I did send quite a lot of comments to the draft at 2012-09-10, and I
have not seen those taken into the draft yet. Also as I noted in my
email I am quite sure we are still missing some requirements, but as
the current document is bit hard to read with the terminology of
different nodes, hubs, endpoints etc so it is bit hard to understand
if all requirements are there or not.

http://www.ietf.org/mail-archive/web/ipsec/current/msg07910.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg07914.html

I myself do think that the draft-ietf-ipsecme-ad-vpn-problem-00 is NOT
yet ready, I have been waiting for the next version of the document
before rereading it.

> draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and
> hopefully there will be more discussion of it before the meeting

My draft-kivinen-ipsecme-ikev2-minimal-01 will be moving to the lwig
WG, so there is no need to discuss it here, and the
draft-kivinen-ipsecme-oob-pubkey-01 would need the straw poll of which
option we are going to do and we need to do that on the email list
anyways, so there is no point of discussing that in the meeting
(unless people are unsure what the options are, and what they mean). 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Oct 2012 19:30:58 -0700

> yet ready, I have been waiting for the next version of the document

You did ask for changes during WG Last Call, and the authors agreed on many of them, but then did not produce the -01 draft (and I did not notice this). I *really* hope they produce a new version before the submission cutoff on Monday; we can then either continue the discussion or send the document to IETF Last Call.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Oct 2012 19:35:00 -0700

> on the agenda and I'll prepare some slides to talk to.

It would be good if you put together a short (less than 15 minutes) presentation on your motivations for the new protocol. That is, we don't need a presentation on what is in the document, but what isn't there: what are the problems that are to be solved.

Tero: even though you are taking draft-kivinen-ipsecme-ikev2-minimal to the LWIG WG, could you do a similar presentation on the problems that your document solves for the IPsecME WG? Yaron and I suspect that there is overlap, and having good lists of the similarities and differences behind the documents would help the two WGs decide what should be in them.

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Fri, 19 Oct 2012 09:21:44 +0200

Hi,

I would also like to have a slot to present our ongoing work on IPsec and
Multiple Interfaces. One of the document is also presented in MIF. I will
update the document presented to MIF by end of next week.

Best Regards,

Daniel

On Fri, Oct 19, 2012 at 4:35 AM, Paul Hoffman <[email-masked]> wrote:

> It would be good if you put together a short (less than 15 minutes)
> presentation on your motivations for the new protocol. That is, we don't
> need a presentation on what is in the document, but what isn't there: what
> are the problems that are to be solved.
>
> Tero: even though you are taking draft-kivinen-ipsecme-ikev2-minimal to
> the LWIG WG, could you do a similar presentation on the problems that your
> document solves for the IPsecME WG? Yaron and I suspect that there is
> overlap, and having good lists of the similarities and differences behind
> the documents would help the two WGs decide what should be in them.
>
> --Paul Hoffman

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Oct 2012 14:01:33 +0300

Paul Hoffman writes:
> Tero: even though you are taking draft-kivinen-ipsecme-ikev2-minimal
> to the LWIG WG, could you do a similar presentation on the problems
> that your document solves for the IPsecME WG? Yaron and I suspect
> that there is overlap, and having good lists of the similarities and
> differences behind the documents would help the two WGs decide what
> should be in them. 

Sure.
-- 
[email-masked]

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 22 Oct 2012 23:55:23 +0000

Hi Paul,

One thing that deserves to be on the agenda is a discussion of the need to
update the ESP and AH crypto requirements, which have not been updated
since 2007, and to provide guidance on how to use ESP and AH to achieve
security goals.   I have a draft proposing what that could look like,
draft-mcgrew-ipsec-me-esp-ah-reqts-00.   This is off-charter, but I
believe that it is something that many people would agree is worth doing.

Of course, comments on the detailed requirements are welcome as well.

David

On 10/17/12 10:38 AM, "Paul Hoffman" <[email-masked]> wrote:

>draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and
>is being sent to the AD for review. This is a call for agenda items.
>Strong preference is given to those which are in the WG charter.
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Oct 2012 17:32:01 -0700

> believe that it is something that many people would agree is worth doing.

You may be overstating that "many people" agree that it is worth doing, but it is certainly worth discussing.

> Of course, comments on the detailed requirements are welcome as well.

Your listing of TripleDES as "SHOULD NOT" without any cryptographic justification might raise some eyebrows.

--Paul Hoffman

---

From: "Will Liu (Shucheng)" <[email-masked]>
Date: Tue, 23 Oct 2012 06:40:20 +0000

Hi Chair,

We'd like to ask for a time slot to present our draft draft-zhang-ipsecme-multi-path-ipsec-02. Thanks.

Regards,
Will

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Wednesday, October 17, 2012 10:39 PM
> To: IPsecme WG
> Subject: [IPsec] Call for agenda items
> 
> draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully there
> will be more discussion of it before the meeting
> 
> --Paul Hoffman

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 23 Oct 2012 12:37:08 +0000

>justification might raise some eyebrows.

The issue is that 3DES has a 64-bit block instead of a 128-bit block;
please see draft-irtf-cfrg-cipher-catalog-01 Section 2.2.3.   (In
retrospect, there should have been a citation in the draft.)

David

---

From: daniel migault <[email-masked]>
Date: Thu, 25 Oct 2012 10:06:41 +0200

>> differences behind the documents would help the two WGs decide what
I just noticed the ipsecme and lwig are both on monday afternoon 17:40 - 
19:40. Wouldn't it better these session do not occur at the same time?

BR
Daniel

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Oct 2012 14:05:25 +0300

> 19:40. Wouldn't it better these session do not occur at the same time?

Especially as I might need to be in LWIG, as they are considering the
draft-kivinen-ipsecme-ikev2-minimal to be accepted as WG draft. I
think LWIG was originally on friday but got moved because it was
overlapping core or something.
-- 
[email-masked]

---

From: "Black, David" <[email-masked]>
Date: Fri, 26 Oct 2012 16:32:34 -0400

> >but it is certainly worth discussing.

I'm definitely interested in that discussion, as I'm in the midst of
an update to the IPsec requirements for iSCSI.

> retrospect, there should have been a citation in the draft.)

That suggests that an explanation of the birthday bound concern
along with a discussion of transmission rate and rekeying concerns
would be appropriate for the ESP and AH requirements draft, as
opposed to a blanket "SHOULD NOT" statement for 3DES.

A 1 Gbit/sec link running encrypted at line rate can get to the 4
Gigabyte birthday bound stated in the cfrg draft fairly quickly, but
a much slower throughput rate may take much longer before rekeying
becomes necessary, if ever (e.g., a remote access session's entire
traffic may be measured in 10s of Megabytes or less).

Aside - there may be a math error in the draft.
For a block size (w) of 64 (i.e., 2^6):

	- w * 2^(w/2) bits = 2^6 * 2^32 bits = 2^38 bits
	- 2^38 bits is 2^35 bytes (byte contains 8=2^3 bits)
	- 2^35 bytes is 2^5 gigabytes (gigabyte contains 2^30 bits).

That would be 32 gigabytes, but this aside doesn't change the
above discussion, as a 1 Gbit/sec rate will get there in a few
minutes, and a 10 Gbit/sec rate will get there in under a minute.
Moreover the draft warns (with good reason) that getting close
to the birthday bound is not a good idea.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> David McGrew (mcgrew)
> Sent: Tuesday, October 23, 2012 8:37 AM
> To: Paul Hoffman
> Cc: IPsecme WG; [email-masked]
> Subject: Re: [IPsec] updating ESP and AH requirements (was: Call for agenda
> items)
> 
> 
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 26 Oct 2012 23:15:40 +0200

> an update to the IPsec requirements for iSCSI.

Me too (interested in that discussion, not updating an iSCSI document)

> to the birthday bound is not a good idea.

The minutes figure is enough to not warrant a SHOULD NOT. Any machine that's capable of sustained 1 Gb/s IPsec should also be capable of rekeying child SAs every minute. In fact, our QA people regularly run a load like that with 1-minute lifetimes for a week just to check if anything bad happens.

So it might be appropriate to say how often you need to rekey with the various algorithms, and it may be correct to say that for extreme cases (a single SA that carries 10 Gb/s sustained rate) 3DES is not appropriate, but this is a far cry from a blanket SHOULD NOT.

I have another issue with this recommendation. It leaves only AES variants as MUST and SHOULD. I would like to have some other algorithm widely implemented, so that if we get some really bad (or good - depends on your perspective) cryptographic result against AES, there is something interoperable to fall back on. As long as we don't have a new algorithm, I'd rather see 3DES remain a SHOULD.

Yoav

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 26 Oct 2012 21:29:01 +0000

> opposed to a blanket "SHOULD NOT" statement for 3DES.

Would a "MAY-" be more appropriate?

> Gigabyte birthday bound stated in the cfrg draft fairly quickly,

The problem is that the "birthday bound" is not a hard boundary, where you're perfectly safe if you stay below it, and becomes a concern only if you cross it.  Instead, it's the pointer where the probability where you leak some data (specifically, the value of the exclusive-or of two 8 bytes segments of plaintext) is fairly good.  However, this leakage can occur (with significantly lower probability) considerably before that.

> but

If we consider a 50Megabyte remote access session encrypted with 3DES, there's approximately a 1 in a million probability that there will be some leakage (that is, someone going through the transcript will be able to deduce of value of the exclusive-or of two 8 byte segments).  How bad would it be if someone could deduce that comparatively small amount of information?  Is that probability low enough to be acceptable?

Well, I don't know if we (the working group) can answer either question; they're far too dependent on what is being protected, and the security goals of the system.  At the best, we could try to document the issues.

On the other hand, what are the arguments for keeping 3DES?  Ten years ago, that was the one cipher that everyone implemented, and so it was necessary for interoperability.  However, nowadays, AES-128 appears to fill that role (and also doesn't have the above potential security concern); what reason would someone now have to implement 3DES rather than AES?

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 Oct 2012 14:46:46 -0700

> Would a "MAY-" be more appropriate?

In my mind, yes.

> Well, I don't know if we (the working group) can answer either question; they're far too dependent on what is being protected, and the security goals of the system.  At the best, we could try to do…

Indeed.

> On the other hand, what are the arguments for keeping 3DES?  Ten years ago, that was the one cipher that everyone implemented, and so it was necessary for interoperability.  However, nowadays, AES-…

It is not a question of implementing new: *all* new systems coming into the VPNC lab have AES-CBC, and have for a few years. However, if those implementations want to interoperate with older implementations, they need to also have 3DES. Thus, a "MAY" for 3DES with a clear explanation why it is inappropriate in high-volume implementations would be valuable.

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 26 Oct 2012 23:56:44 +0200

The need to interoperate with older implementations, as well as Yoav's 
justification of having a widely implemented algorithm as a backup for 
AES, both seem to argue for keeping 3DES as a MAY or MAY-.

I suggest to include a concrete recommendation on rekeying. We could 
argue the numbers forever, but I think a 1/1,000,000 probability for a 
single collision is good enough. So we could RECOMMEND a rekey once 
every 50 MB sent.

Thanks,
     Yaron

--

It is not a question of implementing new: *all* new systems coming into 
the VPNC lab have AES-CBC, and have for a few years. However, if those 
implementations want to interoperate with older implementations, they 
need to also have 3DES. Thus, a "MAY" for 3DES with a clear explanation 
why it is inappropriate in high-volume implementations would be 
valuable. --Paul Hoffman