Subject: [IPsec] IPsec maintenance/extensions WG, summary so far

From: <[email-masked]>
Date: Wed, 7 May 2008 13:19:09 +0300

So far, we've had ~20 people who've expressed some form of support 
for creating a WG. This is good -- many current WGs have less than 20
people who regularly post to the WG mailing list.

However, by my count, we've also had ~20 proposals for work items.
That obviously does not add up.

I agree with Paul's comment about the WG scope: the WG should work 
on things where having a WG is really needed, and we actually have a
*group* of people interested on participating.

Having a WG should not encourage people to develop extensions that
would not have happened in the absence of a WG (this usually indicates
they're not widely needed). For some work items that have been
proposed, an individual draft is IMHO a more appropriate process
mechanism, and forming a WG would not automatically prevent
publication of non-WG documents the WG decided not to take.

To get some idea on what work items we have most interest in, I've
collected those proposed so far (with some things vendors are known to
do in proprietary ways thrown in).

Please select the items you think the WG should work on (less than
ten, please), order them most important first, and for each item,
indicate what you're willing to do:

  [E]dit: you're willing to edit the draft corresponding to the work
  item (note: even if we use an individual draft as a starting point,
  this does not automatically determine the editor of the WG item)

  [C]ontribute: you're willing to propose non-trivial amounts of 
  text for the document during its development

  [R]eview: you're willing to review new revisions of the draft 
  regularly (not just during WGLC)

For example, 

  [CR] AEAD algorithms in IKEv2
  [R] IPsec document roadmap update

would mean that AEAD algorithms is your first priority, and you
volunteer to contribute and review; and IPsec document roadmap is 
your second priority, and you volunteer to review.

You can also propose a work item that isn't on my list.
However, for the time being, I think PF_KEY work does not fit 
within the scope of the possible WG charter.

List follows:

o  Update to IKEv2 base specification (possible starting point:
   draft-hoffman-ikev2bis)

o  IPsec document roadmap update (possible starting point: RFC 2411)

o  Using AEAD algorithms in IKEv2 (possible starting point:
   draft-black-ipsec-ikev2-aead-modes)

o  Redirecting a VPN client from one gateway to another
   (in a cluster of gateways)

o  IPsec "secure beacon", or detecting whether you need VPN or 
   not (possible starting point: draft-sheffer-ipsec-secure-beacon)

o  Detecting crashed peers faster (possible starting point:
   draft-nir-ike-qcd)

o  IKEv2 session resumption / optimizing IKEv2 handshake when 
   connecting again to same peer/cluster of peers (possible 
   starting point: draft-sheffer-ipsec-failover)

o  Authentication-only IPsec that simplifies packet inspection
   (possible starting points: draft-hoffman-esp-null-protocol,
   draft-grewal-ipsec-traffic-visibility)

o  Better IPv6 configuration payloads (possible starting point:
   draft-eronen-ipsec-ikev2-ipv6-config)

o  Other work for making sure IKEv1 and IKEv2 work as well as 
   possible with IPv6, both from standards and operations standpoint
   (please specify more details if you select this one)

o  Running IPsec over TCP (so your VPN works even if the coffee
   shop Wi-Fi has stupid packet filtering)

o  GSS-API (or Kerberos) authentication for IKEv2

o  Non-EAP-based one-time password authentication (possible 
   starting point: draft-sunabhi-otp-ikev2)

o  Using GRE "key" header field as IPsec traffic selector (possible 
   starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps)

o  Authentication with Cryptographically Generated Addresses (CGA)
   (possible starting point: draft-laganier-ike-ipv6-cga)

o  Guidelines for Mandating the Use of IPsec, for RFC430x IPsec
   (possible starting point: draft-bellovin-useipsec)

o  Labeled IPsec for RFC 430x IPsec

o  IKEv1/IKEv2 co-existence and transition (please specify more
   details if you select this one)

o  Setting up GRE tunnels with IKE (possible starting point:
   draft-wu-l3vpn-ipsec-gre-00)

o  Connecting IKEv2 peers behind NATs via a "mediation server"
   (possible starting point: draft-brunner-ikev2-mediation)

o  Anything that may be needed from IKE/IPsec with respect to 
   routing protocol security (please specify more details if
   you select this one)

o  Documenting differences in IPsec usage in IETF vs. 3GPP vs.
   3GPP2 vs. WiMAX vs. vendors etc. (please specify more details
   if you select this one)
  
o  IKEv2 CAPTCHA
   (possible starting point: draft-mutaf-spikev2-01.txt)

Please reply (on the mailing list) within a week or so -- I will 
then summarize what we have.

Best regards,
Pasi

---

P.S. It's good to note that we currently have several other WGs
working on IPsec:

o  BMWG: benchmarking IPsec devices

o  BTNS: unauthenticated or leap-of-faith IPsec, channel bindings,
   IPsec APIs for applications (not key management daemons like 
   PF_KEY)

o  MEXT: interaction between IPsec and Mobile IP, Mobile IP 
   specific extensions to IPsec

o  MSEC: multicast IPsec

o  ROHC: header compression in IPsec tunnel mode SAs

o  SOFTWIRE: IPsec tunnels as a softwire, setting those up 
   based on BGP etc.

These WGs will continue as-is, and e.g. any changes to their charters
are not in the scope of this discussion. Future work items could be
considered case-by-case, but the intent is *not* to collect all
IPsec-related work to one WG.

---

P.P.S. Acknowledgement: if you followed how Julien Laganier and
Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll
notice I have stolen some ideas from them :-)
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 07 May 2008 13:33:30 +0200

Hi,

<[email-masked]> writes:

> <snip>
> <snip>

Sorry for joigning the discussion a little bit late. I should have
posted to make a proposal for some work on MIPv6/IPsec/IKE interactions
as WG items before.

The IPsec-related elements you cite in your P.S. for MEXT were *not*
taken as Working Group items during the recent recharter (decision of
the chairs) even if there were people interested by working on it. Some
other functionalities have been preferred.

At the moment, even if MIPv6 specification expects interactions between
IPsec stack and MIPv6 module for IPSec to survive movement, no interface
is defined. The 2 proposals I am aware of on that topic:

- draft-sugimoto-mip6-pfkey-migrate-04
- draft-qi-mip6-ikev2-interfacing-01

are still now simple external documents. 

IMO, the main issue here is that the topic crosses different WG or is
related to different subjects (IPsec, MIPv6, IKE, PF_KEY). As you wrote
for the IPsec WG "the intent is *not* to collect all IPsec-related work
to one WG".

What is happening in practice is that IPsec and MIPv6 will be
*separately* added new features (probably useful in a sense) but will
not or badly work together. 

Where should associated efforts and discussions be handled?

Thanks,

a+

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 May 2008 14:20:29 +0200

Pasi,

The ones that I actually personally care about:

> [R] o  Update to IKEv2 base specification (possible starting point:
>    draft-hoffman-ikev2bis)
>
> [CR] o  Better IPv6 configuration payloads (possible starting point:
> [R] o  Guidelines for Mandating the Use of IPsec, for RFC430x IPsec

The following were also mildly interesting, I wouldn't mind if the WG

>    draft-wu-l3vpn-ipsec-gre-00)
Then again, much of the above is extensions, rather than fixing bugs &
revising brokenness. The latter should have priority. Is IKEv2 the only
thing that has issues in that regard?

Jari

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 7 May 2008 11:14:01 -0700 (PDT)

Hi Pasi,

  [CR] IKE session resumption
  [ECR] AEAD modes for IKE (and a better one than 4309 for IPsec)
  [ECR] non-EAP-based password authentication for IKEv2
  [R] VPN client redirection

  regards,

  Dan.

---

From: Charlie Kaufman <[email-masked]>
Date: Wed, 7 May 2008 11:15:51 -0700

>publication of non-WG documents the WG decided not to take.

While I agree that there are cases where individual drafts are a more
appropriate process mechanism, there are a lot of cases where we
could use an IPsec WG to focus review and collection of comments.
Small but important changes (like specifying use of a new cryptographic
algorithm with ESP or IKE) might not have the energy behind them to
motivate forming a WG but would nonetheless be more appropriately done
as an additional work item in an existing WG than as an individual
submission.

While a tightly scoped charter is always a good idea, I don't think
we should send the message that "this is the last train for five years...
if you think you're going to want anything in IPsec ever, lobby to
get it into the charter now or forever hold your peace." We should
start with the highest priority non-controversial and mostly completed
items with the expectations that there will be time at meetings to
present proposals for less-well-known extensions and have a decision made
then as to whether to accept them as working group items, suggest they
be the basis of a new working group, suggest they be individual
submissions, or suggest they go away.

        --Charlie

[charliek:]

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Wed, 7 May 2008 11:30:31 -0700

Hi Pasi,

I have one more. Sorry for not posting this earlier.

There was a proposal coming out of the former MIP6 WG to use IKEv2 to
re-direct a mobile node to another home agent. The Binding
Update/Binding Acknowledgement exchange between the mobile node and
the home agent is always preceded by an IKEv2 exchange for mutual
authentication, home address configuration and setting up the required
security associations for protecting Mobile IPv6 signaling messages.
It was felt that it would be desirable for the home agent to tell the
mobile node to go another home agent before the IKEv2 exchange
completes. Otherwise the mobile node would have do the IKEv2 exchange
with the new home agent all over.

This proposal for re-directing the mobile node to another home agent
during the IKE_SA_INIT exchange was in a ex-MIP6 WG document. There
were some issues raised during the IESG review for the IKEv2 re-direct
mechanism. So the mechanism was taken out and the rest of the document
was published as RFC 5026. One of the concerns expressed was that it
could be generic extension to IKEv2 rather than being something
specific to Mobile IPv6.

So I would like to propose to add another work item to the new IPsec
WG charter to work on a IKEv2 re-direct mechanism during the
IKE_SA_INIT exchange. Much of the details have already been worked out
(by the ex-MIP6 WG and then some discussions offline), it is just a
matter of writing up a draft. I am in the process of writing up this
draft. This is coming a bit late. I hope it can be included in the
IPsec re-chartering process.

Regards,
Vijay

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Wed, 7 May 2008 11:33:17 -0700

oops.. I just noticed that you did have the following in the list.

Is this the same? Or did someone else propose this?

Vijay

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 May 2008 14:20:10 -0500

On Wed, May 07, 2008 at 01:19:09PM +0300, [email-masked] wrote:

> o  GSS-API (or Kerberos) authentication for IKEv2

seems unnecessary.  Keep in mind that I once thought the opposite.  But
let's consider:

 - IPsec w/ Kerberos V -> KINK
 - IPsec w/ PSK, PKI, EAP -> IKEv2

So what existing, planned or potential GSS-API mechanisms might one want
to use with IPsec which isn't covered via KINK or IKEv2?

Now, perhaps there is dissatisfaction with KINK.  Or perhaps there's a
desire to mix Kerberos V and whatnot in one KE.  If so, let's hear it.
If not, let's drop this.

>    (possible starting point: draft-bellovin-useipsec)

Primarily because I think that applications shouldn't use IPsec without
IPsec APIs, and IPsec APIs is something that I'm collaborating on in the
BTNS WG.

Nico
--

---

From: Dan McDonald <[email-masked]>
Date: Thu, 8 May 2008 16:53:15 -0400

> That obviously does not add up.
<SNIP!>

Here are proposals for which I have actual interest:

[RC] Running IPsec over TCP (so your VPN works even if the coffee
     shop Wi-Fi has stupid packet filtering)

     Note 1:  cisco has done stuff like this with their proprietary vpn
	      client.

     Note 2:  I need to dig deep into my memory, but folks I knew in grad
	      school had fun using the x-kernel to construct an arbitrary
	      datagram protocol on top of TCP (RAT == Record-Accessed TCP).
	      Such work might be useful for any "TCP encapsulation" for
	      NAT-Traversal. 

     Note 3:  Make sure you include "IKE" as running over TCP.

[R]  IPsec document roadmap update (possible starting point: RFC 2411)

[]  Update to IKEv2 base specification (possible starting point:
    draft-hoffman-ikev2bis)
   
[]  Using AEAD algorithms in IKEv2 (possible starting point:
    draft-black-ipsec-ikev2-aead-modes) (ESPECIALLY including any suggestions
    Dan H. may have about 4309 improvement or the AES-GCM equivalent to
    4309... 41xx, for xx I can't remember).
   
[] IKEv2 session resumption / optimizing IKEv2 handshake when
   connecting again to same peer/cluster of peers (possible  
   starting point: draft-sheffer-ipsec-failover)

Dan

---

From: "fan zhao" <[email-masked]>
Date: Fri, 9 May 2008 10:43:01 -0700

Hi Vijay,

I also support this work item.

Sincerely,
fan

---

From: "fan zhao" <[email-masked]>
Date: Fri, 9 May 2008 10:40:19 -0700

Hi Pasi,

The following is my list.
>
> [CR] o  Update to IKEv2 base specification (possible starting point:
>   draft-hoffman-ikev2bis)
>
> [ECR] o  Redirecting a VPN client from one gateway to another

Thanks.

Sincerely,
fan

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 09 May 2008 14:57:44 -0400

Hi Pasi,
   Here is my ordered list

> o  [R] Update to IKEv2 base specification (possible starting point:
>    draft-hoffman-ikev2bis)
> 
> o  [ECR] Redirecting a VPN client from one gateway to another
> o  [ECR] Detecting crashed peers faster (possible starting point:
>    draft-nir-ike-qcd)
> 
> o  [CR] Better IPv6 configuration payloads (possible starting point:
> o  [ECR] Guidelines for Mandating the Use of IPsec, for RFC430x IPsec
> o  [ECR] IPsec document roadmap update (possible starting point: RFC 2411)
> 
> o  [CR] Using GRE "key" header field as IPsec traffic selector (possible 
> o  [CR] Authentication with Cryptographically Generated Addresses (CGA)
> o  [CR] IPsec "secure beacon", or detecting whether you need VPN or 

Thanks
Suresh

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 09 May 2008 12:20:42 -0700

I will probably review the NAT related stuff as well, and in general 
might review most of the documents chartered anyway.  Will contribute at 
least to the failover related stuff.  At some point I was interested in 
the "use-IPsec" type of work, but I am not so sure it is really useful. 
  The work on documenting differences in IPsec usage says something 
about this already.  :)

regards,
Lakshminath

> List follows:

[R]  Update to IKEv2 base specification (possible starting point:
     draft-hoffman-ikev2bis)
[R]  Using AEAD algorithms in IKEv2 (possible starting point:
     draft-black-ipsec-ikev2-aead-modes)
[R]  Redirecting a VPN client from one gateway to another
    (in a cluster of gateways)
> o  Detecting crashed peers faster (possible starting point:
[ECR]  IKEv2 session resumption / optimizing IKEv2 handshake when
    connecting again to same peer/cluster of peers (possible
    starting point: draft-sheffer-ipsec-failover)
[R]  Authentication-only IPsec that simplifies packet inspection
>    routing protocol security (please specify more details if
[CR]  Documenting differences in IPsec usage in IETF vs. 3GPP vs.
    3GPP2 vs. WiMAX vs. vendors etc. (please specify more details

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 12 May 2008 13:31:55 +0800

Thanks Pasi's charter discussion,

Here is my list:
[ECR] o  Using GRE "key" header field as IPsec traffic selector (possible
  starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps)

[ECR] o  Setting up GRE tunnels with IKE (possible starting point:
  draft-wu-l3vpn-ipsec-gre-00)

[ECR] o  IKEv2 session resumption / optimizing IKEv2 handshake when
  connecting again to same peer/cluster of peers (possible
  starting point: draft-sheffer-ipsec-failover)

Thanks,

-Hui

---

From: Andreas Steffen <[email-masked]>
Date: Mon, 12 May 2008 09:00:47 +0200

Hello Pasi,

here the is the list of the strongSwan team:

[ECR] Connecting IKEv2 peers behind NATs via a "mediation server"
       (possible starting point: draft-brunner-ikev2-mediation)

[R]   Detecting crashed peers faster (possible starting point:
       draft-nir-ike-qcd)

[R]   IKEv2 session resumption / optimizing IKEv2 handshake when
       connecting again to same peer/cluster of peers (possible
       starting point: draft-sheffer-ipsec-failover)

[R]   Running IPsec over TCP (so your VPN works even if the coffee
       shop Wi-Fi has stupid packet filtering)

Best regards

Andreas

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Kumar, Sunil" <[email-masked]>
Date: Mon, 12 May 2008 17:21:26 +0530

Hi Pasi,

We really support the idea of Working Group towards the IPSec and really
want to contribute as well.

Here are proposals for which I am interested:

[ECR] Redirecting a VPN client from one gateway to another
    (in a cluster of gateways)

Thanks n Regards,
Sunil Kumar

SafeNet Infotech Pvt. Ltd.
Noida- 201301
India

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andreas Steffen
Sent: Monday, May 12, 2008 12:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far

Hello Pasi,

Best regards

Andreas

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec
The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.

---

From: "Grewal, Ken" <[email-masked]>
Date: Mon, 12 May 2008 09:38:17 -0700

Hi Pasi, 
I will be interested in the following topics.

[ECR] o  Authentication-only IPsec that simplifies packet inspection
   (possible starting points: draft-hoffman-esp-null-protocol,
   draft-grewal-ipsec-traffic-visibility)

[ECR] o  Running IPsec over TCP (so your VPN works even if the coffee
   shop Wi-Fi has stupid packet filtering)
 
[RC] o  IKEv2 session resumption / optimizing IKEv2 handshake when
   connecting again to same peer/cluster of peers (possible
   starting point: draft-sheffer-ipsec-failover)

[R] o  Redirecting a VPN client from one gateway to another
   (in a cluster of gateways)

[R] o  Connecting IKEv2 peers behind NATs via a "mediation server"
   (possible starting point: draft-brunner-ikev2-mediation)

Thanks, 
- Ken

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 May 2008 13:32:46 +0300

>    Note 1:  cisco has done stuff like this with their proprietary vpn

So have others. Sometimes I think this is the whole point of so-called  
"SSL VPN"
>    Note 3:  Make sure you include "IKE" as running over TCP.

A few years ago I suggested just IKE over TCP. That proposal was shot  
down because "using fragments, you can get UDP packets up to 65K",  
which should be good for IKE. So your Wi-Fi router with stupid packet  
filtering is considered "broken". The IETF usually takes the position  
that broken implementations should be fixed, not circumvented.

At the time I tried to justify IKE over TCP because routers sometimes  
lost fragments and some packet filtering firewalls dropped packets.  
The answer was "(1) If a router can't handle fragments then it's  
broken and (2) If you're going to send messages over a lossless  
connection, use SCTP".  <vent>like the stupid packet filter that can't  
handle UDP fragments is going to handle SCTP</vent>

But here's another couple of notes for you:
     Note 4:  Since the Wi-Fi has stupid packet filtering, the only  
TCP connection that's going to work is to port 443. Some of those  
stupid filters try allow only ports 80 and 443, and they scan port 80  
to make sure there's valid HTTP in there

     Note 5:  Some of them are getting so smart, they look at the  
traffic in port 443 to make sure it's really TLS.  Which brings us  
back to the point about "SSL VPN"

---

From: Yoav Nir <[email-masked]>
Date: Sat, 10 May 2008 23:30:52 +0300

On May 7, 2008, at 1:19 PM, <[email-masked]> <[email-masked] 
 > wrote:
> [CR]  IPsec "secure beacon", or detecting whether you need VPN or
> [EC]  Detecting crashed peers faster (possible starting point:
>   draft-nir-ike-qcd)
>
> [R]  Better IPv6 configuration payloads (possible starting point:
> [CR] Running IPsec over TCP (so your VPN works even if the coffee
> [R]  Connecting IKEv2 peers behind NATs via a "mediation server"

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 12 May 2008 19:34:58 +0300

Hi,

Here's my priority list with some annotations:

[R] Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis)

[R] Detecting crashed peers faster (possible starting point: draft-nir-ike-qcd)

[ECR] IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover)

[ERC] Anything that may be needed from IKE/IPsec with respect to routing protocol security - this is a placeholder, since the ongoing discussion on routing security is both important and likely to benefit from using IKE, instead of an ad hoc key management solution (or none). So I'd rather have it in the charter from day one, even if we don't yet have concrete drafts.

[?]  Redirecting a VPN client from one gateway to another (in a cluster of gateways) - this can be easily folded into the "session resumption" work, and probably should.

[ECR]  IPsec "secure beacon", or detecting whether you need VPN or not (possible starting point: draft-sheffer-ipsec-secure-beacon)

[ECR] Authentication-only IPsec that simplifies packet inspection (possible starting points: draft-hoffman-esp-null-protocol, draft-grewal-ipsec-traffic-visibility)

[R]  Better IPv6 configuration payloads (possible starting point: draft-eronen-ipsec-ikev2-ipv6-config)

[R] Connecting IKEv2 peers behind NATs via a "mediation server" (possible starting point: draft-brunner-ikev2-mediation) - but I'd like to see a less IKE-specific solution here.

Pasi, thanks for facilitating this discussion!

	Yaron

> within the scope of the possible WG charter.
[deleted]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 May 2008 14:20:40 +0300

Sorry, last time I sent it I forgot to sort them by priority.  Here  
goes again

[ECR]  Preventing DoS attacks by using a puzzle mechanism (no draft
  yet, but I'm interested in whether the proposed WG would like
  something like that, given that there may be IPR claims)

---

From: Yoav Nir <[email-masked]>
Date: Sat, 10 May 2008 23:19:40 +0300

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 May 2008 07:58:25 -0400

> So have others. Sometimes I think this is the whole point of so-called  

This can also be done using RFC 3093.

--RLB

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 May 2008 16:18:40 +0300

On May 13, 2008, at 2:58 PM, Richard Barnes wrote:

>> So have others. Sometimes I think this is the whole point of so- 
>> called  "SSL VPN"
>

Actually, RFC 3093 only specifies TCP/IP/HTTP/TCP/IP.

It specifies neither UDP/IP/HTTP/TCP/IP nor ESP/IP/HTTP/TCP/IP, which  
makes it unsuitable for either IKE or IPsec. :-)

I know there is a general sentiment in the IETF against circumventing  
defective equipment, but vendors like Cisco (and Check Point) have to  
get our products working even in said coffee shop. It's a shame that  
this IETF sentiment prevents us from doing so in an interoperable  
manner.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 May 2008 09:02:02 -0500

> this IETF sentiment prevents us from doing so in an interoperable  

FWIW, in the several years that I have been using an IPsec-based VPN
I've not have had any trouble with hotel or coffee shop wifi filtering
out IPsec.

OTOH, in the several years before that when I used an IPsec-VPN-over-TCP
solution I had many problems where bits would stop moving.  I don't know
if that was a function of flow control issues (hmmm, TCP over TCP...),
lousy client software, or what.  But I do know that I never have such
issues now with straight IPsec.

I have had some strange road warrior problems with _IP_ though.  The
most interesting one being a hotel wifi network whose DHCP server handed
out addresses with a /32 netmask: my Solaris laptop then would then
reject the default route from the DHCP server since the router wasn't
on-link (going by the netmask) and there was no other route to it.  I
was able to make this work (and once it did so did IPsec, of course).

All that said, I do find it might odd that there isn't an option for
running IKE over TCP/SCTP.

Nico

---

From: Cheryl Madson <[email-masked]>
Date: Tue, 13 May 2008 09:26:11 -0700

Pasi,

1) I'm actually interested in more than these, but until I
better understand the background/issues, I'm not comfortable
volunteering as of yet.

2) (E) means that I'm willing to help edit if necessary

3) The priorities are a bit arbitrary

+ [ECR] IKEv1/IKEv2 working better with IPv6
+ [ECR] IKEv1/v2 coexistence/transition
+ [(E)CR] Updated to IKEv2 base specification
+ [ECR] Authentication-only IPsec
+ [(E)CR] document roadmap update
+ [ECR] Using GRE key header field as a traffic selector
+ [CR] Setting up GRE tunnels with IKE
+ [CR] Better IPv6 configuration payloads

thx - C

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 May 2008 14:45:22 -0500

On Tue, May 13, 2008 at 10:33:52PM +0300, Yoav Nir wrote:
> On May 13, 2008, at 5:02 PM, Nicolas Williams wrote:
> >
> I've never had that in coffee shops, but I have had that in hotels and  
> airports, mostly in Europe.  You usually find this kind of mandatory  
> proxy where they want to charge you for using the Wifi.

Well, yes, but if there's any way to get VPN to work without paying then
presumably that's a bug in the hotel/airport/whatever wifi.  So this is
a non-issue for IPsec.

> >OTOH, in the several years before that when I used an IPsec-VPN-over-
> >TCP solution I had many problems where bits would stop moving.  I
> >don't  know if that was a function of flow control issues (hmmm, TCP
> >over TCP...), lousy client software, or what.  But I do know that I
> >never have such issues now with straight IPsec.
> 
> TCP over TCP is fun, and an experiment showed that two TCPs over the  
> same TCP is even more fun. UDP over TCP is also fun (think VoIP going  
> silent until that lost packet/segment gets retransmitted). But still,  
> when nothing else works, it lets you read your mail.

Again, if this is about getting VPN to work on non-free access points,
well, I have no sympathy (sure, I want free access too, but I don't
think resorting to VPN over TCP is the right answer here).

> IKE-over-TCP works well, and allows for sending certificates and CRLs  

But really, we should all be using OCSP instead of CRLs...

> within Main Mode / Authentication exchange.  It also allows large  
> proposals in IKEv1 and large config payloads in IKEv2. When I proposed  
> to write a draft about it, it was shot down because IKE is message- 
> oriented while TCP is stream. SCTP sounds better, but the packet  
> filters would balk, and also it's harder to implement because  
> operating systems don't have native support.

I think the "IKE is message-oriented while TCP is stream" argument is
bunk.  There's no reason that enough framing can't be provided to make
it work.  We (the IETF) have lots of experience running message-oriented
protocols over TCP (DNS, NFS, LDAP, HTTP/1.1, SSHv2, TLS, ...); one
might even say that most protocols that run over TCP are message
oriented.  Sure, SCTP is here now and all that, but, so what?  If middle
boxes make SCTP deployment harder then we should make SCTP MUST-
implement and TCP SHOULD-implement.

One good reason for supporting IKE over TCP is that NAT boxes are much
nicer with TCP than UDP traffic, mostly because they can maintain
connection state more accurately for longer due to TCP's connection
oriented nature.

In short: I don't buy the arguments for VPN-over-TCP (if nothing else
the second order flow-control issues are a big deal), but I agree that
IKE should support running over TCP.

Nico

---

From: "Yingzhe Wu" <[email-masked]>
Date: Tue, 13 May 2008 14:52:29 -0700

Hello Pasi,
Here is my ordered list:

[R] o  Better IPv6 configuration payloads (possible starting point:
   draft-eronen-ipsec-ikev2-ipv6-config)

thanks,
Yingzhe

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 May 2008 22:33:52 +0300

> TCP

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 May 2008 09:37:26 +0300

> presumably that's a bug in the hotel/airport/whatever wifi.  So this  

The issue is not to avoid paying.  The airport has an HTTP/HTTPS proxy  
and the wifi has a policy that says:
  - Allow DNS
  - Allow port 80 to the proxy
  - Allow port 443 to the proxy
  - Drop everything else

The proxy is needed, so that the first time you try to access anything  
it redirects you to the billing page. Once you've paid, you still  
can't get anything out unless it's through the proxy, so what the VPN  
client does, is route IKE and IPsec over a TCP connection that looks  
like HTTPS and goes through the proxy.  It's tough to get straight  
IPsec to run through an HTTP proxy.

---

From: <[email-masked]>
Date: Wed, 14 May 2008 12:31:39 +0300

My own list (not wearing any hats):

[CR] Update to IKEv2 base specification 
[ECR] Better IPv6 configuration payloads
[CR] IPsec document roadmap update 
[CR] IKEv2 session resumption
[R] Redirecting a VPN client from one gateway to another
[R] Running IPsec over TCP
[R] Using AEAD algorithms in IKEv2

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 14 May 2008 13:30:22 +0300

Nicolas Williams wrote:

> seems unnecessary.  Keep in mind that I once thought the 
> opposite.  But let's consider:
> 
> So what existing, planned or potential GSS-API mechanisms might one
> want to use with IPsec which isn't covered via KINK or IKEv2?
> 
> Now, perhaps there is dissatisfaction with KINK.  Or perhaps there's
> a desire to mix Kerberos V and whatnot in one KE.  If so, let's hear
> it.  If not, let's drop this.

One potential reason I can think of is desire to use various IKEv2
features, either current (IP address configuration, MOBIKE) or
proposed (AEAD ciphers, session resumption, gateway redirect, 
quick crash detection, etc.) with Kerberos authentication.

(Adding these features to KINK would be a big effort.)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 14 May 2008 13:30:22 +0300

Charlie Kaufman wrote:

> we should send the message that "this is the last train for five
> years...  if you think you're going to want anything in IPsec ever,
> lobby to get it into the charter now or forever hold your peace." We
> should start with the highest priority non-controversial and mostly
> completed items with the expectations that there will be time at
> meetings to present proposals for less-well-known extensions and
> have a decision made then as to whether to accept them as working
> group items, suggest they be the basis of a new working group,
> suggest they be individual submissions, or suggest they go away.

My intention was not to say that this is the last train for five
years, or anything like that -- certainly *after* the initial work 
items are completed, new work and rechartering can be considered.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 14 May 2008 13:30:21 +0300

Arnaud Ebalard wrote:

> posted to make a proposal for some work on MIPv6/IPsec/IKE
> interactions as WG items before.
> 
> taken as Working Group items during the recent recharter (decision
> of the chairs) even if there were people interested by working on
> it. Some other functionalities have been preferred.
> 
> At the moment, even if MIPv6 specification expects interactions
> between IPsec stack and MIPv6 module for IPSec to survive movement,
> no interface is defined. The 2 proposals I am aware of on that
> topic:
> 
> IMO, the main issue here is that the topic crosses different WG or
> is related to different subjects (IPsec, MIPv6, IKE, PF_KEY). As you
> wrote for the IPsec WG "the intent is *not* to collect all
> IPsec-related work to one WG".
> 
> *separately* added new features (probably useful in a sense) but
> will not or badly work together.
> 

When I mentioned Mobile IP specific extensions to IPsec, I meant
things like RFC 5026.

As I wrote in my email, I think PF_KEY work does not fit within 
the scope of the possible WG charter (at least not now). 

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 14 May 2008 13:29:26 +0300

Yoav Nir wrote:

> same TCP is even more fun. UDP over TCP is also fun (think VoIP
> going silent until that lost packet/segment gets retransmitted).
> But still, when nothing else works, it lets you read your mail.

The behavior of VoIP-over-TCP vs. TCP-over-TCP can actually be quite
different: the VoIP application doesn't increase its sending rate
until it gets packet loss. 

Here's an article that tested VoIP with various SSL VPN products,
and found that it actually works quite OK with packet loss rates
you'd usually expect to see:

http://www.networkworld.com/reviews/2006/022006-ssl-voip-test.html

Best regards,
Pasi

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 14 May 2008 13:30:22 +0300

Richard Barnes wrote:

> > So have others. Sometimes I think this is the whole point 
> > of so-called "SSL VPN"
> 

Well, I doubt that Mark and Scott thought back in April 1st, 2001 
that people would actually ship products implementing that one.

But today, VPN products *do* implement something that's very similar
to RFC 3093, and this does provide value to some users. The question 
isn't anymore whether the joke was funny or not, but whether we care 
about interoperability of these products...

Best regards,
Pasi

---

From: Richard Barnes <[email-masked]>
Date: Wed, 14 May 2008 09:01:36 -0400

So your real goal is still to circumvent the provider's policy; this is 
the same use case that RFC 3093 addresses for TCP.  (Note that 
poorly-designed equipment is indistinguishable from poorly-chosen 
policy.)  While I appreciate that you want to be able to connect 
securely, these networks don't allow it; the solution is simply to use 
networks that allow IPsec, not to hack IPsec to run over whatever 
pinhole is available.

Note also that if you're running something non-HTTP through port 80 or 
443, the proxy can see that through deep packet inspection and deny it 
(I have no doubt that firewall vendors would sell this as a feature), so 
there's no real net gain to running IPsec over 80/443 anyway.

But the DNS port is still open, and allowed to go to any host on the 
Internet, not just to a proxy.  Maybe we could run IPsec over that?

--RLB

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 May 2008 16:47:35 +0300

On May 14, 2008, at 4:01 PM, Richard Barnes wrote:

> So your real goal is still to circumvent the provider's policy; this  
> is the same use case that RFC 3093 addresses for TCP.  (Note that  
> securely, these networks don't allow it; the solution is simply to  
> use networks that allow IPsec, not to hack IPsec to run over  
> whatever pinhole is available.

Their policy is that everyone pays and everything except DNS goes  
through the proxy.  We don't circumvent either of these "rules".  In a  
corporate setting, where the rules are actually there to prevent stuff  
they can't inspect, it really is circumventing the policy.

>
> Note also that if you're running something non-HTTP through port 80  
> or 443, the proxy can see that through deep packet inspection and  
> deny it (I have no doubt that firewall vendors would sell this as a  
> feature), so there's no real net gain to running IPsec over 80/443  
> anyway.

Of course firewall vendors sell this as a feature. There's a whole  
arms race around this:
- first things like IPsec clients and Skype went over port 80, but the  
firewalls learned to spot this irregular HTTP.
- Then they went over port 443, because firewalls don't try to  
decipher SSL, but the firewalls learned to stop connections with an  
invalid Client Hello
- Some (like Skype) returned to port 80, but made their connection  
look like real HTTP (That's pretty much what you have in RFC 3093)
- Others made a better effort with port 443, and sent regular TLS  
handshakes, but then they didn't need IPsec anymore, and SSL VPN was  
born.

> Internet, not just to a proxy.  Maybe we could run IPsec over that?

I actually saw this demonstrated by some hacker.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 16 May 2008 00:17:09 +0800

thanks Pasi's elaboration, see inline with ==>
Please allow me to cc MEXT,

> When I mentioned Mobile IP specific extensions to IPsec, I meant
==> So here you mean that it will be in the scope of Mobile IP WG?
after that, it need Security review for this kind of work?

thanks

-Hui

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 May 2008 12:06:14 -0500

> (Adding these features to KINK would be a big effort.)

Ah, good point.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 May 2008 12:08:09 -0500

> IPsec to run through an HTTP proxy.

I've never had this problem.  To be fair I never use airport wifi.  But
I've used plenty of hotel and coffee shop wifis and never, ever ran into
this.  (Before paying or clicking through the registration page, of
course, IPsec bits don't move, but afterwards they do.)

Nico

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 15 May 2008 20:18:09 +0200

Hi,

2008/5/7, [email-masked] <[email-masked]>:

[R] o  IKEv2 session resumption / optimizing IKEv2 handshake when
connecting again to same peer/cluster of peers (possible starting
point: draft-sheffer-ipsec-failover)

By the way, what do you mean by a "same peer/cluster of peers"? Same
administrative domain? Security gateways from a same constructor?

[R] o  Redirecting a VPN client from one gateway to another (in a
cluster of gateways)

[R] o Authentication with Cryptographically Generated Addresses (CGA)
(possible starting point: draft-laganier-ike-ipv6-cga)

Best regards.

JMC.

---

From: <[email-masked]>
Date: Thu, 15 May 2008 23:00:10 +0300

Hui Deng wrote:

> >> The IPsec-related elements you cite in your P.S. for MEXT were
> >> *not* taken as Working Group items during the recent recharter
> >> (decision of the chairs) even if there were people interested by
> >> working on it. Some other functionalities have been preferred.
> >>
> >> is related to different subjects (IPsec, MIPv6, IKE, 
> >> PF_KEY). As you wrote for the IPsec WG "the intent is *not* to 
> >> collect all IPsec-related work to one WG".
> >>

I'm not taking any opinion on whether these drafts should be in 
the scope of MEXT WG or not. (But as I said earlier, nothing in the
IPsec maintenance/extensions WG discussion is intended to prevent 
other WGs from working on IPsec-related topics, if they choose 
to do so.)

Best regards,
Pasi

---

From: Julien Laganier <[email-masked]>
Date: Wed, 21 May 2008 09:43:24 +0200

Hi Pasi,

Below is my list:

[CR]  Better IPv6 configuration payloads 

[ECR] Other work for making sure IKEv1 and IKEv2 work as well as
possible with IPv6, both from standards and operations standpoint
(please specify more details if you select this one)
=> Use of DHCPv6 within an IPsec tunnel to configure an address, DNS, 
etc.

[R]   IPsec "secure beacon", or detecting whether you need VPN or not

[R]   Authentication with Cryptographically Generated Addresses (CGA)
=> as it's been discussed already, a CGA does not 
provide 'authentication', the IKE and IPsec SA would be 
unauthenticated, but proof-of-ownership of the CGA could be verified. 
Thus, this item might fit better in the Better-Than-Nothing-Security 
WG, which develop exactly that: unauthenticated mode of IPsec.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 21 May 2008 14:18:22 +0200

Sorry for posting twice...

> => Use of DHCPv6 within an IPsec tunnel to configure an address, DNS,

and DHCPv6 Prefix Delegation.

--julien