Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

From: <[email-masked]>
Date: Mon, 2 Mar 2009 21:04:09 +0100

<not wearing any hats>

I have one somewhat substantial concern with the document: it needs to
be much clearer about what information is updated by the received
REDIRECT messages, and what is not.

While selecting the right peer when a new ESP/AH SA needs to be
created is not specified in RFC 4301 (see RFC 4555 Appendix A.2 for
some discussion), PAD definitely is in scope, and redirect could
interact with PAD in multiple ways.

For example, suppose the client decides that the right peer for the
ESP/AH SA is gw1.example.com. If after doing a DNS lookup and
contacting gw1.example.com it receives IDr/CERT payloads for
gw2.foobar.example, the client would report error and abort (at least
unless "the right peer for the SA" is actually a set of possible
peers, and gw2 happens to be in that set).

Now, suppose contacting gw1.example.com results in REDIRECT to
gw2.foobar.example (GW Identity Type=FQDN). When the client contacts
gw2, and receives IDr/CERT for gw2.foobar.example, does it accept it?

One possible answer would be that REDIRECT is interpreted just as data
received from DNS, so all the gateways (redirecting among each other)
would send same IDr value.

Another possible answer would be that if gw2.foobar.example is already
in client's local "set of right peers for this SA", then it would be
accepted (and the client would have accepted IDr/CERT with
gw2.foobar.example also in the beginning, before it got the redirect),
otherwise not. (And the client will also accept IDr/CERT
gw1.example.com even after the redirect, when contacting gw2 ---that
would be the sensible behavior if the redirect was with GW Identity
Type=IPv4/6.)

(Other answers than these two might be possible, too -- I have
not explored this in detail.)

Now, it's quite obvious the intent was to do redirect securely, but we
need to spell out what the correct behavior is: do all the gateways
have a single identity (IDr), or do they have distinct PAD entries?

(In the latter case, IKE_SA creation (with or without redirects)
succeeds only if the IDr has an entry in the PAD, and the peer is
successfully authenticated as required by the PAD. If the client
accepts IDr/CERT gw2.foobar.example, it would have also accepted it in
the first place (when trying to contact the IP address found by doing
DNS lookup for gw1.example.com, before it got any redirects). However,
in general there's no guarantee that the CHILD_SA authorization data
for the PAD entries "gw1.example.com" and "gw2.foobar.example" is
exactly the same, so although setting up the IKE_SA succeeds, creating
CHILD_SA with the intended selectors might not -- so by sending a
redirect, the gateway really assumes that the client has identical
CHILD_SA authorization data for the target.)

The situation gets tricker when we consider Mobile IPv6, though,
because we're also updating some data outside IPsec. What exactly is
being updated by the received REDIRECT, and is this secure?  Also, the
SPD entries in RFC 4877 contain the HA address -- are we updating SPD
entries based on unauthenticated REDIRECT?

It seems some of this problem is already present in current MIP6
bootstrapping documents (if we e.g. discover Home Agent IPv6 address
by DNS query, somehow the SPD entries must get there, based on usually
unauthenticated DNS response), and it's possible we could refer to
that work. But "treat REDIRECT just as it would have come from DNS"
is not without security issues, since MN might not use DNS to get the
HA address (we could be overwriting manually configured data known
to be secure), the DNS reply could have been protected by DNSSEC, or 
the attacker might be on MN<->GW1 path (and can spoof redirects) but 
not on MN/DNS server paths (so can't spoof the DNS reply).

Minor clarifications and nits:

- Section 4 says "If an anycast address is returned in response to DNS
resolution of an FQDN, the IKEv2 transaction between the VPN client
and the VPN gateway is slightly modified." It seems the transaction is
actually *not* modified at all -- it's exactly identical to the
unicast case (and VPN client can't tell which case occurred)?

- Section 5: I don't think treating REDIRECT+"sufficient time period"
as implicit delete is a good idea. RFC 4306 requires sending delete
payloads whenever possible, and if the VPN GW wants to close the
IKE_SA, it could include the Delete payload in the same message as the
REDIRECT notification...

- Section 6.1/6.2/6.3: should say that Protocol ID is set to zero.

- Section 6.2 says this message is included in IKE_SA_INIT response; 
also INFORMATIONAL request, right?

- Section 7: I'm a bit skeptical if this actually works. The rest of
the document certainly does not describe how it would work, and in
many places, assumes the client-gateway case (e.g. Section 6.1 says
REDIRECT_SUPPORTED is only sent in initial IKE_SA_INIT request, so the
responder can't actually tell the initiator it supports this feature,
etc.) Also, the "what is actually updated by REDIRECT and what is not"
may get even more complex in peer-to-peer case.  My personal
preference would be to restrict the scope to client-gateway unless
someone really has the energy needed to specify how the peer-to-peer
case works in detail.

Best regards,
Pasi

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Mar 2009 19:37:09 -0500

Pasi,

I agree with your observations/concerns.  Any host/SG to which one is 
redirected needs to be subject to the same controls as an initial SA 
target.  I see this as a PAD (and SPD) issue. I would suggest that 
maybe the only safe approach is to reevaluate the redirected target 
against the PAD entry for the initial target.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Mar 2009 17:30:13 +0200

> REDIRECT messages, and what is not.

Never really thought that issue. I myself assumed that both GWs are
identical, i.e. they return same ID, and use same authentication data
(i.e. if PSK, both use same PSK, if certs, both authenticate against
same trust anchor and use same identity in cert, but not necessarely
same private key).

> would send same IDr value.

I think this is the easiest way to make sure redirect is secure.

> IKE_SA, it could include the Delete payload in the same message as the

I think it said that it can delete it without client sending any
packets, but that delete is not implicit, it is explicit, and gateway
will then send delete payload to delete the IKE SA. The sufficient
time is used when the client has been talking to the gateway for
longer already, and has multiple IPsec SAs up and in use. Then when
gateway decides to redirect client somewhere else it sends N(REDIRECT)
and client acks that. After that client starts recreating existing IKE
SA and Child SAs with the new gateway, and after finishing that the
client will delete the IKE SA with delete payload. If server runs out
of resources before that it can send delete payload even before client
finishes its redirection process but as that causes disruption of the
flow of packets (if client didn't have time to set up new Child SAs),
server should allow some time for that.

I agree that the text could be written in more clear way, i.e.
explictly say that the "delete the securition association" does mean
the normal IKEv2 way, i.e. sending delete payload. 

> someone really has the energy needed to specify how the peer-to-peer

Also the current text says

"the responder MUST NOT respond to re-direct message from the
initiator, if it has already decided to re-direct the initiator."

and that is impossible with IKEv2. If node receives some request, it
must reply with response, it cannot leave that response out, as if he
does that then the IKE SA will be teared down when the other end times
out the exchange.

I think the original idea was that even when we talk about VPN client
and gateway, this could be used as building block for other things
too, and even this document uses terms like "VPN client" and "VPN
gateway", this could also be used even when the IKE peers are not VPN
client/gateway. This includes cases where for example SIP/MobileIP
client connects to SIP/MobileIP server using IPsec.

I do not think this can be used as generic gateway to gateway
redirection mechinism (MOBIKE can be used for that too). 

I.e. I would simply change the section 7. to contain:
----------------------------------------------------------------------
7.  Use of the Redirect Mechanism between IKEv2 Peers

   The Re-direct mechanism described in this document is mainly intended
   for use in client-gateway scenarios.  However, the mechanism can also
   be used between any two IKEv2 peers, but this protocol is
   asymmetric, meaning that only the responder can redirect initiator
   to some other server.
----------------------------------------------------------------------

And leave everything else out, including changing the protocol so it
can be used in both directions. 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Mar 2009 07:57:00 -0800

<without hats>

>same trust anchor and use same identity in cert, but not necessarely

I think both views are reasonable, but the document must be much clearer about which is being discussed. If it is the former, the doc should also explicitly say that the latter is an acceptable setup.

>I think this is the easiest way to make sure redirect is secure.

I initially didn't agree with this idea, but I can see how it would make the security properties much easier to define. However, I don't think that was the intention of the current document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 5 Mar 2009 17:26:03 -0800

Hi Pasi,

Responding to the minor comments first...

> unicast case (and VPN client can't tell which case occurred)?

Fixed this. What I wanted to say was that the IKE_SA_INIT might get
routed to a different VPN gateway that is part of the anycast group.
The client is of course not aware of this.

> IKE_SA, it could include the Delete payload in the same message as the

The draft currently requires the client to delete the SA once it
receives the REDIRECT message from the gateway. I do not want the
gateway to delete the SA right away. The gateway should allow the
client to setup the necessary security associations with the new
gateway before deleting the SA with the existing gateway, if that is
what the client wants to do. The current text is to handle the case
where for some reason the gateway does not receive the DELETE payload
from the client. Note that this shouldn't happen normally. The gateway
garbage collects the SA after a certain time period. I don't think the
gateway needs to send a DELETE payload at this point.

> - Section 6.1/6.2/6.3: should say that Protocol ID is set to zero.

Fixed.

> also INFORMATIONAL request, right?

Thanks for catching. This is from the initial versions where the
REDIRECT was only happening during the IKE_SA_INIT exchange. Fixed
this.

> etc.)

I am fine with restricting the scope as Tero suggested. My interest
has always been in client-gateway scenarios anyway. I am cc'ing Rich
Graveman who wanted this feature. Rich?

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 6 Mar 2009 09:00:35 +0200

Hi,

I have a slight preference to keeping the protocol symmetric. But even if we choose not to do that, I think Tero's text (quoted below) leaves too much room for interpretation.

---

---

The protocol supports using an Informational exchange for redirect at any time during the SA lifetime, and this is inherently symmetric. And of course, following an IKE SA rekey, the initiator/responder roles might change. If we go for the restricted option, the new text should cover both of these issues.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Vijay Devarapalli
> Sent: Friday, March 06, 2009 3:26
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
> 
> Hi Pasi,
> 
[snip]
> _______________________________________________
> 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.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 6 Mar 2009 15:43:05 +0200

> gateway needs to send a DELETE payload at this point.

I disagree with that. If gateway decides to delete the IKE SA, it
needs to send DELETE payload in that case. The only case where you do
not send DELETE payload is when you delete the IKE SA because some
exchange over the IKE SA timed out (i.e. other end didn't respond). In
that timeout case there is no point of sending DELETE payload, as most
likely that will not reach the other end any better than the original
exchange, thus it will also timeout.

In this redirect case the client might just be slow, or it might be
that the gateway where client was redirected to does not respond, and
client does not delete the old IKE SA before it gets new one up and
running. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 6 Mar 2009 15:52:00 +0200

Yaron Sheffer writes:
> I have a slight preference to keeping the protocol symmetric. But
> even if we choose not to do that, I think Tero's text (quoted below)
> leaves too much room for interpretation.

Redirect is not really symmetric ever. If it would be used in
symmetric way, then each end would simply create the connection using
the address they want whenever they want. I.e. if server wanted to
redirect client to somewhere else later, it would simply inform that
new gateway to make connection to the client and close the local
connection. That new gateway would then simply initiate new connection
to the client and move traffic to there.

The reason we cannot do that is that client-server connections are
very often asymmetric, i.e. we are using EAP, or client is behind NAT
or similar problems. 

> The protocol supports using an Informational exchange for redirect
> at any time during the SA lifetime, and this is inherently
> symmetric.

No, it does not make it symmetric. If the original initiator wants to
use other local address when connecting, he will simply switch to that
new address and initiate new connection. Original responder cannot do
that, as most likely the connection using new address does not work
because of NATs or because of asymmetric authentication type used
(EAP).

> And of course, following an IKE SA rekey, the
> initiator/responder roles might change. If we go for the restricted
> option, the new text should cover both of these issues.

I should have used "original responder" and "original initiator".
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 6 Mar 2009 18:34:34 +0200

Hi Tero,

We are thinking of different use cases.

You are thinking VPN client - VPN server (and similar client/server cases). I agree that client-side redirect is useless in this case. MOBIKE takes care very well of the multihomed case (one address on WLAN, another on GPRS). So I don't care if the current draft doesn't work for that case.

I am thinking of symmetric IKE peers (gateways, or endpoints using transport mode ESP; no EAP, rarely any NAT). Is there any reason why the current draft cannot support this case in a symmetric manner?

Thanks,
	Yaron

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Friday, March 06, 2009 15:52
> To: Yaron Sheffer
> Cc: Vijay Devarapalli; [email-masked]; [email-masked];
> [email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 06 Mar 2009 15:23:17 -0800

> client does not delete the old IKE SA before it gets new one up and

The timeout on the gateway can be quite large. The gateway should give 
sufficient time for the client to delete the SA. If the client does not 
for some reason, (note that the client is required to delete the SA), 
the SAs are just removed. The gateway has already sent a REDIRECT 
message to the client. Sending yet another INFORMATIONAL message with 
the DELETE payload after a certain time period, is just an overhead, IMHO.

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 8 Mar 2009 14:48:17 +0200

Hi Vijay,

I'd rather be consistent with IKE, i.e. send an explicit DELETE.

I suggest to change the -04 text:

Once the client sends an acknowledgement to the gateway, it SHOULD delete
the existing security associations with the old gateway by sending an
Informational message with a DELETE payload.  The gateway MAY also decide to
delete the security associations without any signaling from the client.

To:

Once the client sends an acknowledgement to the gateway, it SHOULD delete
the existing security associations with the old gateway by sending an
Informational message with a DELETE payload.  The gateway MAY also decide to
delete the security associations without any signaling from the client,
again by sending an Informational message with a DELETE payload.

Thanks,
	Yaron

> Sent: Saturday, March 07, 2009 1:23
> To: Tero Kivinen
> Cc: [email-masked]; [email-masked]; [email-masked]; Vijay
> Devarapalli

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 9 Mar 2009 15:10:38 +0200

Yaron Sheffer writes:
> I am thinking of symmetric IKE peers (gateways, or endpoints using
> transport mode ESP; no EAP, rarely any NAT). Is there any reason why
> the current draft cannot support this case in a symmetric manner? 

Why do you need any protocol for that. Why does not normal IKEv2 be
enough for that.

I.e. if node A wants the node B to move to use some other location, it
can simply connect to node B using that new location, and remove the
old IKE SA.

I.e. if scenario is really symmetric, there is no need to have any
IKEv2 redirect protocol at all, everything can be done by the node by
directly connecting using new location.

It is quite hard to explain this thing as I have no idea what kind of
scenario you are talking about. Can you give real example, what the
nodes are and why do they want to redirect other end.

MOBIKE is not restricted to the VPN client <-> VPN server situation,
but is limited that node must stay same. I.e. it is moving between
multiple addresses of node A and moving between multiple address of
node B. It cannot ask node B to move from node A to node C.

But if node A wants node B to use node C instead of node A, it can
simply inform node C to make connection to B and delete its own IKE
SA. It can also do this by just changing the back end routing or
similar, so that return packets go to node C instead of node A and
then node C will initiate connection to node B immediately when first
packet arrives (if the situation is really symmetric).

If we are talking about client and server situations where server
wants to redirect client to some other server, then situation is no
longer symmetric.
-- 
[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 09 Mar 2009 14:24:12 -0800

> I'd rather be consistent with IKE, i.e. send an explicit DELETE.

Ok, I made this change, since there seems to be consensus for an 
explicit message when the gateway decides to remove the SA.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 9 Mar 2009 17:57:30 -0400

Hi Pasi,

I spent about three days thinking about this, but still couldn't
conclude on anything. I am cc'ing Jari, since I thought he would
interested in this topic and have some comments.

As you observed, Mobile IPv6 does allows the mobile node to discover a
Home Agent dynamically (See RFC 5026, RFC 4877 and
draft-ietf-mip6-bootstrapping-integrated-dhc) and then create the
corresponding PAD and SPD entries. We obviously do not convey what sort
of authentication mechanism should be used with the gateway. It is
assumed that the mobile node knows which authentication mechanism to use
(based on the deployment) and store this information in the newly
created PAD entry. 

The use of DNS and DHCPv6 is allowed for discovering a home agent's
address/FQDN. The discovery mechanisms based on DNS and DHCPv6 can be
secured, but the secure form of these mechanisms might not be used
always. So it is possible that you do end up with an insecure discovery
mechanism creating new PAD and SPD entries on the mobile node. I never
considered this a big deal, since the mobile node does authenticate the
newly discovered home agent anyway. I also think the policy on the
mobile node should be such that this discovery of a home agent should
not modify existing PAD/SPD entries created using manual configuration,
or some other configuration that results in persistent config state on
the mobile node.

I don't agree with the restriction that the original gateway and the new
gateway should have the same IDr. That is too restrictive. For example,
it should be possible for gw1 to redirect the client to gw2, with the
two gateways having two distinct FQDNs.

It is okay with me to recommend similar authentication mechanisms for
the original and new gateways. But I would prefer not use a 'MUST' here.
There could be scenarios where a different gateway means a different
authentication mechanism. We should of course add some text in the
security considerations section warning about REDIRECTs resulting in
lower security with the new gateway. 

Note that gateway-initiated redirect (section 5) is protected by the
IKEv2 SA. It is not the same as the REDIRECT message that the client
receives in the IKE_SA_INIT response. So we can't say that all REDIRECT
messages are insecure. 

I will not be able to resolve this in the version I am going to be
submitting in the next couple of hours. I hope we can resolve this in
the next few days. I will post another temporary version of the draft
once we conclude on this issue.

Regards,
Vijay

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Monday, March 02, 2009 12:04 PM
> To: [email-masked]

---

From: <[email-masked]>
Date: Tue, 10 Mar 2009 14:00:27 +0100

> > - Section 6.1/6.2/6.3: should say that Protocol ID is set to zero.

One nit: the text in version -05 says "Protocol ID should be 
set to 0". I think this should be just "is set to 0" (or
perhaps "MUST be set to 0")

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 10 Mar 2009 14:14:20 +0100

Tero Kivinen wrote:

> > I have one somewhat substantial concern with the document: it
> > needs to be much clearer about what information is updated by the
> > received REDIRECT messages, and what is not.
> 
> identical, i.e. they return same ID, and use same authentication
> data (i.e. if PSK, both use same PSK, if certs, both authenticate
> against same trust anchor and use same identity in cert, but not
> necessarely same private key).

I think that's roughly what I initially assumed, too. In this case,
the REDIRECT payload is redirecting the VPN client from one IP address
to another, but within the same "responder identity" (not from one
responder identity to another) . 

(Here "responder identity" can be single physical box with several 
addresses, or multiple physical boxes configured to "look like 
one" -- the client doesn't have to know which.)

> > One possible answer would be that REDIRECT is interpreted just as
> > data received from DNS, so all the gateways (redirecting among
> > each other) would send same IDr value.
> 

I agree -- and if we settle on this approach, we might want to rename
the "New Responder GW Identity" field (in REDIRECT payload) to
something like "New Responder Transport Address" -- since the IKE
identity is not changed, only the address used for transporting IKE
messages.

I spent some time in trying to figure out how to specify the other
approach (redirect to different "responder identity") securely, but
couldn't really come up with anything that would work and be
consistent with the RFC 4301 model... so at the very least, taking
that approach will mean more work before we're done.

Best regards,
Pasi

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 10 Mar 2009 11:06:51 -0800

> perhaps "MUST be set to 0")

Changed it to "... MUST be set to 0 ..."

Vijay

---

From: <[email-masked]>
Date: Wed, 11 Mar 2009 12:44:26 +0100

Vijay Devarapalli wrote:

> I don't agree with the restriction that the original gateway and the
> new gateway should have the same IDr. That is too restrictive.  For
> example, it should be possible for gw1 to redirect the client to
> gw2, with the two gateways having two distinct FQDNs.

Right... but if the client does not have a PAD entry for gw2's IDr,
then the IKE negotiation will fail. (I guess we're not considering
updating the PAD based on REDIRECTs.)

(BTW, note that "having same IDr" is not exactly the same thing as
"having same FQDN" -- gw1.example.com and gw2.foobar.example are
clearly distinct FQDNs from DNS-point-of-view, but they might or might
not be distinct "principals" from IPsec PAD point of view.)

> It is okay with me to recommend similar authentication mechanisms
> for the original and new gateways. But I would prefer not use a
> 'MUST' here.

I think this needs to be phrased in terms of the RFC 4301 PAD 
(and possibly the "selecting right peer for SA function").

Best regards,
Pasi

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Mar 2009 14:26:19 +0200

[email-masked] wrote:
> > example, it should be possible for gw1 to redirect the 
> client to gw2, 
> > with the two gateways having two distinct FQDNs.
> 
> Right... but if the client does not have a PAD entry for 
> gw2's IDr, then the IKE negotiation will fail. (I guess we're 
> not considering updating the PAD based on REDIRECTs.)

I agree that we have to assume that gw2 is in the PAD. It could be the same entry as gw1, or it could be different, but it has to be in the PAD.  If gw1 redirects the client to a gateway that is not in the PAD, then the client must log or report, and fail.

> (BTW, note that "having same IDr" is not exactly the same 
> thing as "having same FQDN" -- gw1.example.com and 
> gw2.foobar.example are clearly distinct FQDNs from 
> DNS-point-of-view, but they might or might not be distinct 
> "principals" from IPsec PAD point of view.)
> 

RFC 4301 does not require that each SPD entry be associated with a single PAD entry. It's a many-to-many relationship. The section on named SPDs specifically says that an SPD entry may have multiple names.  Section 4.4.3.3 says that "If the entry indicates that child SAs traffic selectors are to be used, then an additional data element is required, in the form of IPv4 and/or IPv6 address ranges." It does not say that two entries cannot have the same IDs.

This works fine if two gateways (at different addresses) protect the same networks (an example would be two geographically distinct sites, each with its own gateway, and an MPLS link between them).

If the redirect-to gateway is in the PAD, but either does not protect the same networks at all, or has a partial overlap in protected networks, then we have a problem, because if the client is setting up a child SA in order to reach host A, protected by gw1 but not by gw2, then it's not clear what selectors should be used with gw2, and whether the whole exercise has any value.

Perhaps instead of requiring "having the same Idr" we need to require "having the same SPD entries", except maybe SPDs that cover the gateways themselves.

Yoav

Email secured by Check Point

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Mar 2009 12:35:36 -0700

>updating the PAD based on REDIRECTs.)

Co-chair-hat on:

Right, we are not considering that currently. If we do consider it, it is a significant change to the document and we would want to do (at least) another WG last call.

Co-chair-hat off:

Right, and we should not consider that, given the difficulty of bounding the security considerations if we do so.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan McDonald <[email-masked]>
Date: Wed, 11 Mar 2009 15:45:39 -0400

> At 12:44 PM +0100 3/11/09, <[email-masked]> wrote:

<SNIP!>

> >updating the PAD based on REDIRECTs.)

<SNIP!>

> the security considerations if we do so.

I agree with Paul regardless of which hat he's wearing, but my reason for
agreeing with him is more along the lines of his sans-hat look.  :)

Dan

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 11 Mar 2009 13:01:28 -0800

> updating the PAD based on REDIRECTs.)

Thats exactly what I am suggesting. :)

This would be similar to a Mobile IPv6 mobile node creating a PAD entry 
for the home agent that it discovers using IETF-standardized mechanisms. 
  I don't think we should require a Mobile IPv6 mobile node or a VPN 
client or a 3GPP client that uses I-WLAN and discovers a PDG [*] to have 
PAD entries configured for all the home agents/gateways/PDGs that it 
might attach to before hand.

(* Apologies for using 3GPP terminology in the above. Pasi knows what I 
am talking about. If anyone wants to know more about this, please let me 
know. You might regret it later though. :)

> not be distinct "principals" from IPsec PAD point of view.)

If you put the FQDN in the PAD entry, you do have an issue, right?

> (and possibly the "selecting right peer for SA function").

Ok. Once we agree on a way forward, I can propose some text.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 11 Mar 2009 13:07:37 -0800

> Right, and we should not consider that, given the difficulty of bounding the security considerations if we do so.

There are environments where the client (e.g, Mobile IPv6 MN, 3GPP 
I-WLAN client) always discovers the gateways they need to attach to. 
They might get assigned different gateways based on what service they 
want to access, what their subscription profile is, etc.. In such 
environments, the PAD entries are created dynamically, but of course 
bound by the configuration on the mobile node. I think the REDIRECT 
mechanism is of limited use if you can only redirect to another gateway 
for which the mobile node already has a PAD entry.

Note that Mobile IPv6 already allows the mobile node to discover home 
agents dynamically and then create PAD and SPD entries. These are 
already standards track documents.

On starting another WG last call for the document if we make this 
change, I am fine with it.

Vijay

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Mar 2009 13:20:45 -0700

At 1:07 PM -0800 3/11/09, Vijay Devarapalli wrote:
>There are environments where the client (e.g, Mobile IPv6 MN, 3GPP I-WLAN client) always discovers the gateways they need to attach to. They might get assigned different gateways based on what service they want to access, what their subscription profile is, etc.. In such environments, the PAD entries are created dynamically, but of course bound by the configuration on the mobile node.

Of course. I was proposing that we do not add this mechanism to the list, but instead have it reflect the settings that were made by the other mechanisms.

>I think the REDIRECT mechanism is of limited use if you can only redirect to another gateway for which the mobile node already has a PAD entry.

Hmm. That was not clear to me from the document, but I could have missed it. What do others think about this statement?

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Mar 2009 09:39:50 +0200

Paul Hoffman wrote: 
> >There are environments where the client (e.g, Mobile IPv6 
> MN, 3GPP I-WLAN client) always discovers the gateways they 
> need to attach to. They might get assigned different gateways 
> based on what service they want to access, what their 
> subscription profile is, etc.. In such environments, the PAD 
> entries are created dynamically, but of course bound by the 
> configuration on the mobile node.
> 
> Of course. I was proposing that we do not add this mechanism 
> to the list, but instead have it reflect the settings that 
> were made by the other mechanisms.
> 
> >I think the REDIRECT mechanism is of limited use if you can 
> only redirect to another gateway for which the mobile node 
> already has a PAD entry.
> 
> Hmm. That was not clear to me from the document, but I could 
> have missed it. What do others think about this statement?

Strongly disagree.  The REDIRECT in the Initial exchange is unauthenticated. The mobile node has not idea where this message has come from. I don't think it makes any sense to alter the PAD based on an unauthenticated notification. If we allow this, then REDIRECT says "go to this address on the Internet, and give them your user name and password". A fake REDIRECT could lead you to the attacker's gateway. You will accept any IDr it presents (because you don't have a PAD entry to authenticate that gateway). That gateway can then mount a MitM attack with the real gateway.

No. I would hesitate to change the PAD based on an authenticated message from a trusted peer. I would never alter the PAD based on an unauthenticated message.  gw2 MUST be in the PAD (either the same entry or a different one)
Email secured by Check Point

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Mar 2009 14:24:34 +0200

Paul Hoffman writes:
> >I think the REDIRECT mechanism is of limited use if you can only
> >redirect to another gateway for which the mobile node already has a
> >PAD entry. 
> 
> Hmm. That was not clear to me from the document, but I could have
> missed it. What do others think about this statement? 

I didn't get that from the draft. The current draft does not mention
anything about PAD, and doing dynamic updates to PAD (or SPD) is
something that must be explicitly mentioned if such things are
supposed to happen, as they have lots of security implications
(overwriting existing rules, to which location dynamic rules are added
in the ordered PAD/SPD, what information is exactly put there).

On the other hand I do not think the REDIRECT mechanism will be that
much in limited use, even if the PAD entries must be configured.

The mobile node requires PAD entry for the first gateway anyways, and
if that PAD entry identifies the group of peers instead that one peer,
and provides authentication data for each peer (for example say that
they are authenticated using certificates signed by CA X).

Depending on the configuration this can still be done quite easily.
Example could be that PAD define ID must be *.sgw.example.com. and the
peer must authenticate itself using certificate signed by CA X. Then
first gateway can provide ID sgw1.sgw.example.com and it can redirect
client to server, which then will use ID sgw2.sgw.example.com, and
that will still match the same PAD entry. Both gateways will use
certificates provided by the same CA so their authentication
information is same.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 12 Mar 2009 22:41:16 +0200

Hi Tero,

Apologies for my late reply.

My interpretation of redirect is that Gateway A is telling Client C: "go
talk to Gateway B instead of me. I am overloaded, or going down for
maintenance, and Gateway B can do the same things that I can do." Which in
particular means that routing was configured so that GW B can *really* act
like GW A. A and B are not "the same gateway", they do not share state, so
MOBIKE cannot be used.

The exact same thing applies to the gateway-to-gateway situation. Suppose
Gateway C initiated an IKE SA with gateway A. Two hours later GW C goes into
maintenance, so it asks GW A to redirect into Gateway D. GW A cannot just
initiate a connection to D, because it doesn't know that it needs to until
told by GW C. And it doesn't matter who initiated the SA in the first place.

Yes, there is some routing/tunneling magic going on "behind" the gateways,
but why should we rely on it to initiate the IKE redirection, when we have
the mechanism defined in the current draft?

Thanks,
	Yaron

> Sent: Monday, March 09, 2009 15:11
> To: Yaron Sheffer
> Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04
> 
> Yaron Sheffer writes:

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 Mar 2009 14:06:28 +0200

> told by GW C. And it doesn't matter who initiated the SA in the first place.

When C goes to the maintenance, it will also change routing so that
packets which used to come to him, will go to D. Immediately when
first such packet gets to D, the D will initiate connection to A, so C
can simply change the routing, and then delete all IKE SAs. 

> the mechanism defined in the current draft?

Mostly because redirections gets very complicated if both ends can
move at will... For example what happens if the gateway A is rebooted,
while C is still down. Now C will not reply with redirect to D, thus
we still need to rely on some other external mechanism to redirect
stuff from C to D, i.e. most likely both of them are configured in the
configuration, so A will know that it can connect either C or D.

When we were writing MOBIKE, we noticed that things gets very
complicated very quickly if such scenarios are allowed, and in that
case you cannot really expect the systems to just work, you still need
to write new document profiling how nodes should be configured and
used in such cases.

If we are going to need such profile anyways to get usable protocol,
we can write protocol extension at the same time which profiles
redirect to be used in gw-gw scenarios and also extends and defines
how it should be used in that case.

We have way too many protocols already where the actual protocol
document does not provide interoperability. The documents are so wide
open, that nobody implements all the optional things (or not even all
the mandatory to implement things), thus you cannot just take two
implementations and assume they work together on your specific
scenario. In those cases you need to write profile that tells what
features are required, and then you might get interoperability
(provided you will find any implementations fulfilling those
requirements).

My proposal was to say that we do not define that usage in this
document, but it is not explicitly forbidden either, so we assume that
if such usage is needed, new document extending this one will be written.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 14:22:35 +0100

Vijay Devarapalli wrote:

> This would be similar to a Mobile IPv6 mobile node creating a PAD
> entry for the home agent that it discovers using IETF-standardized
> mechanisms.  I don't think we should require a Mobile IPv6 mobile
> node or a VPN client or a 3GPP client that uses I-WLAN and discovers
> a PDG [*] to have PAD entries configured for all the home
> agents/gateways/PDGs that it might attach to before hand.

Why not? As Tero already commented, this specification could simply
assume that if the discovery mechanism creates a PAD entry, it can
also create a wildcard PAD entry (that matches e.g. all gateways that
have certificate issued by CA X).

> (* Apologies for using 3GPP terminology in the above. Pasi knows
> what I am talking about. If anyone wants to know more about this,
> please let me know. You might regret it later though. :)
> 
> > clearly distinct FQDNs from DNS-point-of-view, but they might or
> > might not be distinct "principals" from IPsec PAD point of view.)
> 

Well... the FQDN in the PAD entry can be a wildcard (but the FQDN sent
in DNS query obvious can't).

Best regards,
Pasi

---

From: <[email-masked]>
Date: Sat, 21 Mar 2009 19:35:14 +0100

Yoav Nir wrote:

> If the redirect-to gateway is in the PAD, but either does not
> protect the same networks at all, or has a partial overlap in
> protected networks, then we have a problem, because if the client is
> setting up a child SA in order to reach host A, protected by gw1 but
> not by gw2, then it's not clear what selectors should be used with
> gw2, and whether the whole exercise has any value.
> 
> Perhaps instead of requiring "having the same Idr" we need to
> require "having the same SPD entries", except maybe SPDs that cover
> the gateways themselves.

Hmm -- something along these lines might work; but should it
be "having same Child SA Authorization Data in the PAD"?

Best regards,
Pasi