Subject: [IPsec] New PAKE Criteria draft posted

From: "Dan Harkins" <[email-masked]>
Date: Sat, 24 Apr 2010 02:48:10 -0700 (PDT)

A new PAKE criteria draft has been posted to the I-D repository at:

      http://www.ietf.org/id/draft-harkins-ipsecme-pake-criteria-00.txt

It describes a different approach to selection criteria and considerations
than that provided by the other similarly-named I-D.

  Please take a look and comment.

  regards,

  Dan.

---

From: Jitender Arora <[email-masked]>
Date: Sat, 24 Apr 2010 10:09:31 -0400

Hi All,

A new version of I-D, draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txt has been posted to the IETF repository.

Filename:	 draft-arora-ipsecme-ikev2-alt-tunnel-addresses
Revision:	 00
Title:		 Alternate Tunnel Addresses for IKEv2

Regards,
Jitender

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 24 Apr 2010 20:59:33 +0300

Hi everyone,

I read Dan's draft and I am OK with holding the working group's
discussion of alternative PAKE solutions based on this draft. In
particular, I am glad that Dan proposes a way for rational analysis of
the related IPR issues.

Given my own involvement as a coauthor of the HUSH (EKE) draft, it will
be Paul who will lead the discussion.

Thanks,
	Yaron

On Sat, 2010-04-24 at 02:48 -0700, Dan Harkins wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 25 Apr 2010 12:21:55 +0300

Hi Jitender,

this is certainly an interesting approach to the
high-availability/load-balancing issue that we are just starting to
tackle, as a group. I would appreciate your inputs to the discussion on
draft-ietf-ipsecme-ipsec-ha.

Below are a few initial comments on your draft:

- I suggest moving Sec. 5.1 to the front (or at least pointing to it
from the Introduction) so that the motivation becomes clear before the
protocol details are presented.
- Of course, if there are additional usage scenarios, it would be nice
to include them.
- Essentially ignoring the issue of NAT severely hurts the applicability
of this protocol. Even saying something like "use STUN/TURN" is better
than limiting the protocol to closed networks.
- The security considerations never discuss the issue that the peer can
now claims ownership of ANY IP address. I *think* this is just a
denial-of-service issue, but it certainly needs to be analyzed. Which
leads to the main issue with this proposal:
- This is not just a change to IKEv2, it is a rather major change to the
IPsec architecture. So I would expect some discussion of RFC 4301
entities. See the last 2 paragraphs of
http://tools.ietf.org/html/rfc5685#section-3 for an example.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Sun, 25 Apr 2010 14:34:16 +0300

I agree. And whatever we may think of the particular solution, it does present a problem that can and should be in the problem statement draft.

So how about adding teh following sub-section:

3.7.  Different IP addresses for IKE and IPsec

   In many implementations there are separate IP addresses for the
   cluster, and for each member.  While the packets protected by tunnel
   mode child SAs are encapsulated in IP headers with the cluster IP
   address, the IKE packets originate from a specific member, and carry
   that member's IP address.  For the peer, this looks weird, as the
   usual thing is for the IPsec packets to come from the same IP address
   as the IKE packets.

   One obvious solution, is to use some fancy capability of the IKE host
   to change things so that IKE packets also come out of the cluster IP
   address.  This can be achieved through NAT or through assigning
   multiple addresses to interfaces.  This is not, however, possible for
   all implementations.

   [ARORA] discusses this problem in greater depth, and proposes another
   solution, that does involve protocol changes.

On Apr 25, 2010, at 12:21 PM, Yaron Sheffer wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Apr 2010 14:29:15 +0300

>    usual thing is for the IPsec packets to come from the same IP address

Normally all ESP packets also have the members IP address as their
outer address, so there is no problem. Both IKE and ESP packets have
same address (provided the IKE and Child SAs are located on the same
cluster member).

If the ESP packets have special handling that will change their outer
source address to match cluster's IP address instead of individual
member's IP address, then the same mechanims can easily be used for
IKE SA too.

>    multiple addresses to interfaces.  This is not, however, possible for

I would expect this to be one of those very basic systems provided by
the cluster, so if cluster implementationdoes not offer such setup,
then it most likely does not offer that for Child SAs either, thus
there is no problem, as both ESP and IKE will use same IP (i.e.
member's own IP). 

We already have standard track mechanims for updating the outer
address for both Child SAs and IKE (MOBIKE), so even when the
cluster's outer IP address is used in normal case, the failover to
another cluster member (using different IP address) is easy to do
provided both the cluster member's share the same SA state.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Apr 2010 14:56:16 +0300

This is why we need multiple vendors to look at this draft.

> same address (provided the IKE and Child SAs are located on the same

Actually, in our implementation, all packets (IKE and ESP) have the cluster IP address, so the peer doesn't notice a failover, and also the peer can't tell which member is "active" or which member it is working with.

> member's IP address, then the same mechanims can easily be used for

Not really. The IPsec stack constructs the ESP header and encapsulating IP header for tunnel mode SAs. It can put whatever external IP address it wants in there. IKE is handled by a user space process that opens a regular UDP socket and sends packets. To get those packets to have the cluster IP address, we need some special OS feature that allows you to override the IP stack, or a NAT mechanism to change the packets.

> there is no problem, as both ESP and IKE will use same IP (i.e.

Again, for ESP, your code constructs the external source IP address, or it is a property of the child SA that the IKE process created.

> provided both the cluster member's share the same SA state.

MOBIKE was intended for mobile clients such as laptops and phones. It would be weird to use that for the enterprise gateway that uses clustering to improve scalability or availability. But in any case, at the moment we are only dealing with a problem statement. Solutions are yet to come.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Apr 2010 15:56:55 +0300

Yoav Nir writes:
> Actually, in our implementation, all packets (IKE and ESP) have the
> cluster IP address, so the peer doesn't notice a failover, and also
> the peer can't tell which member is "active" or which member it is
> working with. 

Yes, that is also one way doing it, but in that case there is no
problem, as IKE and ESP uses same address.

> Not really. The IPsec stack constructs the ESP header and
> encapsulating IP header for tunnel mode SAs. It can put whatever
> external IP address it wants in there. IKE is handled by a user
> space process that opens a regular UDP socket and sends packets. To
> get those packets to have the cluster IP address, we need some
> special OS feature that allows you to override the IP stack, or a
> NAT mechanism to change the packets. 

In userspace you can still use the normal bind operation to bind the
source IP to specific IP address. You do not need special OS features,
those features are usually present in most of the operating systems
available, so you just need standard OS features... 

> MOBIKE was intended for mobile clients such as laptops and phones.

That is one use.

Another use for for gateways to provide high-availability when you
have multiple connections to the internet, i.e. multiple ISPs. 

> It would be weird to use that for the enterprise gateway that uses
> clustering to improve scalability or availability.

I would expect to see it in all environments where the gateway
supports redundant intenet connections, i.e. same box has two
connections to the internet using different ISPs (and of course using
completely different IP-addresses).

> But in any case, at the moment we are only dealing with a problem
> statement. Solutions are yet to come.

I have not read the draft you mentioned, but I assumed it was also
solution document, not problem statement document. I do not know how
it relates to MOBIKE, or to anything else, but I think MOBIKE is one
of the solutions we are going to be using where it is applicable. 
-- 
[email-masked]

---

From: Jitender Arora <[email-masked]>
Date: Mon, 26 Apr 2010 22:23:35 -0400

Hi Yaron,

     Thanks for the feedback. I will definitely read the draft-ietf-ipsecme-ipsec-ha and will get back to you.

 Here are my answers to your suggestions:

1.  I will point the section 5.1 in the introduction itself that way the purpose and applications of the draft are clear.

2.  We did discuss the NAT scenarios and were of the opinion that if we take care of the NAT scenario's then it will change the IKEv2 protocol in a major way.

Here is how we were planning to solve the NAT issues:

We were thinking that once the IKE_AUTH exchange is completed and the different tunnel addresses are specified by the VPN client or the Gateway, each side can send the informational IKEv2 message containing the NAT_DETECTION_SOURCE_IP and the NAT_DETECTION_DESTINATION_IP payloads (they will have to send this informational message using the tunnel addresses as the IKEv2 peer addresses) to see if there are NAT devices between them or not. If they determine that there is a NAT device, they can always use NAT addresses as the tunnel address.

Using this approach the client or the gateway can determine whether there is a NAT device in the ESP traffic path or not. But using this approach requires that the Client and the gateway also to be able to listen for the IKE packets on the tunnel addresses and also these IKE packets will be protected by the IKE-SA negotiated on the IKE addresses.

So this will require a lot of changes in the current implementation, but this is certainly possible.
3. The tunnel addresses are negotiated during the IKE-AUTH or the CREATE_CHILD_SA exchanges. These exchanges are protected using the IKE-SA and also the users are being authenticated by each side before the tunnel addresses are accepted. So once the users are authenticated, the Security Associations will be setup using the tunnel addresses as the tunnel src and the tunnel destination addresses, so the traffic will protected using these SA's. Should not this be enough for the case you mentioned below? 

Also as in our case all the IKEv2 signaling will be handled by the same gateway (load balancer will just act as a pass-through for IKEv2 traffic and will just choose the gateway), so I am not sure how the sections you mentioned in the RFC 5685 will be applicable.

Thanks,
Jitender

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Sunday, April 25, 2010 5:22 AM
To: Jitender Arora
Cc: [email-masked]
Subject: Re: [IPsec] New draft posted

Hi Jitender,

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Apr 2010 14:19:51 +0300

Jitender Arora writes:
> 1.  I will point the section 5.1 in the introduction itself that way
> the purpose and applications of the draft are clear.

After I read the section 5.1 (I skipped most of the other draft as I
needed to know first WHY this is needed before I care about HOW it is
implemented), and I do not really see enough text there to cause me to
read the HOW part.

So I would need better and more text about WHY this extension is
needed. Why it is important that the IKEv2 SA and Child SA uses
different outer addresses? Who is supposed to terminate the IKEv2 SA
and who is supposed to terminate the Child SAs. Is this assuming that
IKEv2 SA and Child SA are still on the same machine or what? If so,
why not just use the IP address of that host for both IKEv2 SA and
Child SA?

So I think the usage scenarios (WHY part) is much more important than
the actual protocol (HOW part), and it should be clear from the
beginning.

Currently this draft mostly assumes there is problem, but it does not
explain why you think the problem actually exists or what the problem
is. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 27 Apr 2010 15:27:09 +0300

Hi Jitender,

regarding your point #3: I am not sure that if I trust a gateway to
connect to, I also trust it to say that all ESP traffic from an
arbitrary IP address should be treated as a Child SA of this gateway. I
cannot see a concrete attack based on this assumption, but it can surely
result in interesting configuration issues. Just think of two IKE
gateways that (possibly because of misconfiguration) share one IPsec
box.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Tue, 27 Apr 2010 16:17:42 +0300

Or think of a single IKE gateway that sets up IPsec SAs for multiple IPsec boxes.  Like the key server in MSEC.