Subject: [IPsec] IPsec maintenance/extensions WG?

From: <[email-masked]>
Date: Tue, 22 Apr 2008 11:59:39 +0300

Hi,

During the Philadelphia meeting, several folks expressed interest
in forming a working group for IPsec maintenance and extensions.

Since IKEv2 is included in, for example, various US Government IPv6
profiles, we'll probably see a number of new IKEv2 implementations
during the next couple of years.  Having a working group would
provide a forum for discussing implementation questions, and
ensuring that results from, e.g., interoperability workshops are
actually written down in the specifications (which didn't happen
for IKEv1).

While some maintenance work has already been done (RFC 4718,
draft-hoffman-ikev2bis), and the ipsec mailing list still exists,
finding those has been difficult for non-insiders. Also, the
maintenance work has so far focused largely on the "remote access
VPN" (client-to-gateway) use case, which exercises slightly
different parts of the specs than host-to-host and
gateway-to-gateway IPsec.

At the same time, there has been interest in standardizing small
improvements and extensions that were not included in the IKEv2
base specifications (just search for drafts containing "-ikev2-" 
or "-ipsec-"). Some of those extensions could benefit from wider
participation that having a working group would bring.

To actually form a WG, we would need to agree on the initial
charter scope, and have enough people to work on all the items
we decide to take on. 

My current thinking is that the WG charter should describe a small
number of specific work items and reasonable timelines for
completing them, as opposed to including everything related to
IPsec and planning to have the WG around forever.

To get some discussion started, please send your opinions on 
whether having a WG would be a good idea, your thoughts on what 
the charter should look like, and what you'd consider to be the 
most important work items.

(If you've talked with me about this topic earlier, please
still post your opinions on the list for others to see.)

Best regards,
Pasi
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Chinh Nguyen <[email-masked]>
Date: Tue, 22 Apr 2008 08:56:03 -0400

IKEv2 is also used in other standards. In some cases, these look to be 
subtly different than the current IKEv2 standard. 3gpp and 3gpp2 comes 
to mind. Perhaps the WG can also survey the IKEv2 "landscape" so that 
IKEv2 implementors are aware of these issues, especially those that 
deviate from the norm.

Chinh

--
http://www.certicom.com

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Apr 2008 08:24:45 -0700

At 11:59 AM +0300 4/22/08, <[email-masked]> wrote:
>during the next couple of years.

Quite right. There are a few commercial VPN gateways with IKEv2, but 
only a few. There are many more OEM kits that contain IKEv2.

>Having a working group would

This seems useful if (and only if) it doesn't cause people to think 
"hey, I should start something because there is a WG". That is, the 
WG should work on deployable extensions and corrections to the 
current IKEv1 and IKEv2 base, but not encourage people to develop 
things that are not widely needed.

>IPsec and planning to have the WG around forever.

Yay! Now if you could just get your co-AD to feel the same way about PKIX...

>most important work items.

I'm happy to have the infrequently-updated draft-hoffman-ikev2bis as 
part of the WG. Your draft-eronen-ipsec-ikev2-ipv6-config should 
certainly be there as well. In fact, it would be grand if the WG 
spent a fair amount of time making sure that IKEv1 and IKEv2 worked 
as well as possible with IPv6, both from a standards and from an 
operations standpoint.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andreas Steffen <[email-masked]>
Date: Tue, 22 Apr 2008 20:03:12 +0200

Hi,

we also advocate the creation of an IPsec maintainance and extensions WG
because we would like to have a constructive feedback on our recent
IKEv2 mediation extension proposal (draft-brunner-ikev2-mediation)
which handles those NAT Traversal cases where both endpoints are hidden
behind Network Address Port Translation (NAPT) devices and therefore
need a mediation service in order to establish a peer-to-peer IPsec
connection.

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: "Snyder, Guy" <[email-masked]>
Date: Tue, 22 Apr 2008 18:31:06 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> [email-masked]
> Sent: Tuesday, April 22, 2008 5:00 AM
> To: [email-masked]
> Subject: [IPsec] IPsec maintenance/extensions WG?
> 
> Hi,
> 

I agree that it would be good to have a group to discuss issues raised
from our bakeoffs.  We also have run into issues in our IKEv2 testing
that probably need further definition and/or clarification.

> gateway-to-gateway IPsec.

I also feel that a WG would provide more focus on current drafts that
otherwise would not get widespread attention.
 
> IPsec and planning to have the WG around forever.

I agree on the small number of current work items.  Although we don't
want to stifle creativity, we also do not want everyone to jump on a
bandwagon of creating drafts.

> most important work items.

Hopefully we will have some good feedback for this potential WG from the
upcoming bakeoff for IKEv2.

--Guy Snyder, VPN Programs Manager
--ICSA Labs
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Chinh Nguyen <[email-masked]>
Date: Tue, 22 Apr 2008 16:01:21 -0400

Hi,

I would certainly like clarifications on IKEv2 Transport Mode 
negotiation when one or both peers are behind NAT. There are no 
discussions in the IKEv2 standard or clarification. I do not think it 
can be done using simple selectors (i.e., TSi = peerA, TSr = peerB) but 
am willing to be corrected.

I have sent to this list a way to do Transport Mode behind NAT using 
complex selectors but there could be a more elegant/obvious way.

Regards,

Chinh

--
http://www.certicom.com

---

From: Dan McDonald <[email-masked]>
Date: Tue, 22 Apr 2008 16:17:04 -0400

> am willing to be corrected.

If one peer is behind NAT, the concept of NAT-OA should take care of that --
at least that's how it works in IKEv1.  (So long as the initiator is behind
the NAT.)

As for both being behind NAT, there's a strongswan guy who may have a
solution there.

Dan

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Apr 2008 16:04:29 -0400

Pasi,

I agree that there could be benefit to a WG that exists to coordinate 
responses to questions and to clarify the IPsec/IKE specs.

Steve

---

From: Dan McDonald <[email-masked]>
Date: Tue, 22 Apr 2008 17:29:32 -0400

After my PF_KEY reply, I did forget to say that...

> responses to questions and to clarify the IPsec/IKE specs.

I agree with Pasi, Steve, and others who've said the above.

Dan

---

From: "fan zhao" <[email-masked]>
Date: Tue, 22 Apr 2008 16:06:59 -0700

Hi, Pasi,

I fully support this idea. IMHO, besides a few topics listed already,
the new WG can
also work on solving issues and supporting specific scenarios arising
when IPSec/IKE
is deployed, e.g. by other standard fora, as well as developing
extensions for optimizing
the use of IPSec/IKE. Such work items should be specific and expected
to be completed in
a reasonable time frame.

One work item that IMHO can be picked up by the WG is to define an
IKEv2 payload that
can be used by an IPSec gateway to indicate to an IPSec remote access client
the "right" IPSec gateway to be connected with, during the IPSec SA
establishment
procedure. This is useful in case that there are multiple IPsec
gateways deployed for pursposes,
such as load balancing.

Best regards,
fan

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 22 Apr 2008 23:53:20 -0700 (PDT)

Hi Pasi,

> actually written down in the specifications (which didn't happen

  Well it wasn't for lack of trying! If you recall the draft that became
IKEv1 was limited to only 7 revisions due to a desire to send all IPsec-
related drafts out to the RFC editor en masse. Everyone knew it still
needed work and the feedback from the bakeoffs was good but there was
a time limit. (Contrast this with IKEv2 which went through 17 revisions,
had another draft to "clarify" it that went through 9, and now we're on
the 3rd rev of an IKEv2-bis draft).

  If there are feedback from IKEv2 bakeoffs it would seem worthwhile to
have a forum to ensure that it gets into the -bis work.

  regards,

  Dan.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Apr 2008 12:03:20 +0200

I support the idea of a maintenance WG for IPsec and related
specifications. There are issues that we need to clarify. In some of the
recent specs in particular, and I think there's a window of opportunity
to affect what implementations actually do. Lets act and keep our specs
as up to date as possible. We could do this without a WG, too, but I
think we could gather more eyes to look at the clarifications, more
energy, and be more open by having a WG.

Having said that, I think the charter needs to be rather tight and the
chairs be chosen appropriately so that they can prevent this from
becoming a fun discussion club that lasts forever or something that
starts to develop many unnecessary extensions.

Jari

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Apr 2008 13:33:19 +0300

Hi

I agree with the many responders who have supported the creation of an  
IPsec extension/maintenance WG.

I do not agree though, that such a group would be limited in time and  
scope. Paul's comparison with the PKIX WG is apt, and an IPsec WG will  
probably have to stick around as long as anybody's using IPsec. There  
have been some responses along the lines of "tight charter" and not  
being a place to "develop many unnecessary extenstions". The fact is  
that many of the extensions that have been added since RFC 4306 and  
several others which haven't are entirely necessary for a successful  
deployment of IKEv2, especially for remote access.  The great number  
of drafts published with extensions are proof of that.

I don't advocate accepting any draft that anybody wrote as a WG item,  
but I think there are legitimate concerns that need to be addressed by  
new standards, and they need to be discussed within a real WG, not the  
ghost mailing list of a defunct WG.

Yoav

---

From: Chinh Nguyen <[email-masked]>
Date: Wed, 23 Apr 2008 09:03:43 -0400

Hi,

I don't want to hijack this thread for detailed discussion about other 
issues either so let me be brief. (Check out my message dated March 12, 
2008).

NAT-OA isn't an issue since it's merely for efficient incremental 
checksum (re-computation). The double NAT from strongSwan is to allow 
two NAT-ed peers to do IKE (presumably because there's no static NAT 
mapping on the NAT device so one of the peer can be reached.)

My problem is that I do not see how you can negotiate simple traffic 
selectors that will match the actual data packets to be encrypted.

Consider 1 single NAT-ted peer:

X -- N[at] -- Y

X can negotiate TSi=(X), TSr=(Y). This is no good for Y since it will be 
sending data addressed to N. That is, the security policy (SP) generated 
from selectors (X,Y) by Y will not match Y's outgoing packets with 
addresses (Y,N).

Alternatively, X can negotiate TSi=(N), TSr=(Y) if it somehow knows the 
address of NAT device or perhaps it can send TSi=(*), TSr=(Y) and Y can 
reply with TSi=(N), TSr=(Y). This is good for Y but now, the selectors 
(N,Y) that are used by X will not match packets coming out of X, which 
have addresses (X,Y).

Perhaps I'm missing something completely obvious here?

Chinh
--
http://www.certicom.com

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 23 Apr 2008 16:44:50 +0300

> starts to develop many unnecessary extensions.

I do support creating the IPsec maintenance/extensions WG, and one of
the reasons I want it created is to LIMIT the number of unnecessary
extensions and modifications to the IPsec. Current it is very easy to
publish extension to the IPsec, you just make some stealth draft
somewhere, and then submit it for publication. It gets few reviews,
and then it is through as long as there is no real security problem or
similar in the document.

If we have working group for IPsec maintenance/extensions then all
those extensions will come to there, and it can act as filter to see
which one of them are really needed, and also force much wider review
of the document. I myself find very much problems following individual
submissions, so I do not usually even try. That is the reason I have
not reviewed those IPsec extensions documents.

If there is working group which adopts the document as work item then
I know it is something I should pay attention to, it has been filtered
out to be useful for me to read and comment. If on the other hand
someone makes draft which gets bounced out from the IPsec
maintenance/extensions WG because it was not seen important enough or
usuful enough that should give much more feedback for authors and ADs
and such whether such document is useful or not.

So one of the roles I see that this working group should have is to
provide filtering out IPsec related documents, and send them to
correct destionation (i.e. either this WG, some other WG, to the
trashcan, to BOF to create new WG etc). Because of this I think it
should most likely be long lived working group, but its charter could
be empty after initial set of extensions have been prosessed. It could
also be used by the other WGs to come ask help, i.e. they could come
in and present "this is how we felt we should be using IPsec in our
protocol XXX", and then this WG could give input back and tell if that
is ok, or completely wrong way, or whether more work is needed (and
also help other WGs to do the work if needed).
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Wed, 23 Apr 2008 09:44:20 -0400

On Wed, Apr 23, 2008 at 09:03:43AM -0400, Chinh Nguyen wrote:

<SNIP!>

> from selectors (X,Y) by Y will not match Y's outgoing packets with 

Y doesn't know about X save for NAT-OA - and as you point out, that only
helps the checksums.  Y talking to X is governed by Y's rules for talking
with N.  That's just how it works, welcome to the world of NAT.  :-P

> (N,Y) that are used by X will not match packets coming out of X, which 

Y will see TSi(X), but knows, because of NAT-D/NAT-OA, that there's a NAT in
betweeen and it must treat (X) as (N) for purposes of its local IPsec policy.

> Perhaps I'm missing something completely obvious here?

You're merely seeing that NATs are f*cked-up constructs that should all be
burned into the ground.  ;)

Seriously though, a NAT effectively limits the amount of end-to-end
communication that can occur between nodes.  Y can only see N and act upon N.

If you have, for example, a policy on Y that states a port-only policy, it
gets even trickier.  If you also have A, B, and C behind N, TS(X,p) may
collide with TS(A,p) because N will treat those as TS(N,p).  Ephemeral port
selection on the behind-the-NAT clients combined with "unique SA" derivation
(what 4301 calls PFP) usuall sorts these issues out.

Because a NAT can have arbitrary nodes behind it, you cannot possibly map out
transport mode selectors in a manner that will guarantee things to work.  In
these cases, the best approach is to use per-port selectors, combined with
PFP/unique-SA policies.

Dan

---

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Apr 2008 09:44:49 +0200

+1

[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Jeffrey Sun <[email-masked]>
Date: Tue, 22 Apr 2008 14:05:43 -0700

All,
If one peer is behind NAT, than the first Traffic Selector in TSi is 
effectively the NAT-OA Payload (for the Initiator) in IKEv1.  This may 
require it's own dedicated thread, but I'm curious to why Chinh does not 
believe that simple selectors don't work for Transport Mode negotiation 
in a NAT'ed environment.  Transport Mode is designed typically in the 
context of single IPsec host connection (not several hosts fronted by an 
IPsec gateway); in other words, you shouldn't need any additional selectors.

Regarding double NATs, as mentioned by Andreas Steffen in this email 
thread, you may want to take a look at their draft 
(draft-brunner-ikev2-mediation).
- Jeff Sun

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 28 Apr 2008 22:57:37 +0800

we also advocate the creation of an IPsec maintainance and extensions WG
since currently we are working on extending IKE/IPsec to support GRE key
exchanging and as traffic selector.

This is aimed to solve the problem where there are multiple IPsec SAs to
protect different GRE tunnels between the same pair of IPsec peers.

These scenario does exist when operator has some security
consideration for some ICPs.

-Hui