Subject: [IPsec] Question on CP payload

From: "Raghunandan P (raghup)" <[email-masked]>
Date: Wed, 19 Nov 2008 18:15:28 +0530

Hi,
I was going through the draft draft-ietf-ipsecme-ikev2bis-01 and have
the following questions on CP payload.
 
1. The CP payload can be exchanged as part of the AUTH_EXCHANGE and can
also be sent separately as part of informational message. Is that
correct? Can we have a scenario where CP payload is sent as part of the
AUTH_EXCHANGE and also separately as an informational message (in both
the exchanges)?
 
2. Suppose there is a scanario where CP payload has been exchanged as
part of XAUTH exchange and suppose the config mode reply has pushed an
IP address of 3.3.3.3. Now, suppose Tsi agrred upon is 1.1.1.1 and Tsr
agrred upon is 2.2.2.2 which means that any traffic from 1.1.1.1 to
2.2.2.2 needs to be NATed to 3.3.3.3 and protected by the child SA.
Hence, a child SA will be setup with 3.3.3.3 to 2.2.2.2. Is that
correct? 
Assuming above is true, both IKE SA and child SA have been set up. Now,
suppose a CP payload is exchanged as part of informational exchange and
a new IP address is pushed to the client as part of this message. Is
this possible? If yes, what would happen to the existing IPsec SA. Will
it be deleted and new child SA set up? OR will a new child SA be set up?
OR existing child SA modified?
 
3. Suppose we have the normal SA_INIT and AUTH_EXCHANGE which create an
IKE SA and a child SA without any configuration messages exchanged
during these exchanges. After this is done, now suppose the CP payloads
are exchanged as part of the informational exchange and the peer pushes
a new IP address to the client. What would happen to the existing child
SA? Will it be modified to take into account the new pushed address or
will the existing child SA be deleted and a new one set up?
 
Thanks
Raghu
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 Nov 2008 22:07:25 +0200

> AUTH_EXCHANGE and also separately as an informational message (in both

Yes, Configuration payloads can be sent as separate INFORMATIONAL
exchange after the IKE_AUTH. Some reason to do it after IKE_AUTH as
INFORMATIONAL exchange is if the client wants to get another address,
for example it originally only requirested IPv4 address, and now wants
to get IPv6 address too.

> part of XAUTH exchange and suppose the config mode reply has pushed an
	  ^^^^^
XAUTH? I assume you mean IKE_AUTH?

> Hence, a child SA will be setup with 3.3.3.3 to 2.2.2.2. Is that

I am not sure what you are asking here. There isn't any NATs there
in general case. Normally the client proposes the TSi of any to the
responder and responder will then assign the address (3.3.3.3 in this
case), and it will then narrow down the proposal initiator make to
that.

> this possible?

Yes.

> If yes, what would happen to the existing IPsec SA. Will

Nothing will happen to the existing IPsec SAs. The original addresses
assigned to the client are still valid, so there is no point of doing
anything to them. Existing SAs are not deleted and they are not
modified.

> SA?

Nothing will happen to them. They stay there and can be used as
before. 

> Will it be modified to take into account the new pushed address or

They are not modified, and are not automatically deleted. If the
client wants to use the new IP-address it has been pushed to it most
likely needs to create new IPsec SA that allows that traffic also, as
the SAs created before most likely do not allow that traffic.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "V Jyothi" <[email-masked]>
Date: Thu, 20 Nov 2008 09:39:19 +0530

Hi,

In IKEv2 RFC, there was an INTERNAL_ADDRESS_EXPIRY attribute to specify the expiry life time of address issue.
Client can send CP payload in informational exchanges after address expiry.
 INTERNAL_ADDRESS_EXPIRY  attribute is removed in draft-ietf-ipsecme-ikev2bis-01.

thanks
jyothi

-----Original Message-----
From: [email-masked] on behalf of Tero Kivinen
Sent: Thu 11/20/2008 1:37 AM
To: Raghunandan P (raghup)
Cc: [email-masked]
Subject: [IPsec]  Question on CP payload

	  ^^^^^

Yes.

---

From: "Raghunandan P (raghup)" <[email-masked]>
Date: Fri, 21 Nov 2008 15:35:24 +0530

Hi Tero,
Thanks for the information. Please see my response/clarifications below.

Regards
Raghu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tero Kivinen
Sent: Thursday, November 20, 2008 1:37 AM
To: Raghunandan P (raghup)
Cc: [email-masked]
Subject: [IPsec] Question on CP payload

Raghunandan P (raghup) writes:
> 1. The CP payload can be exchanged as part of the AUTH_EXCHANGE and
> can also be sent separately as part of informational message. Is that
> correct? Can we have a scenario where CP payload is sent as part of
> the AUTH_EXCHANGE and also separately as an informational message (in
> both the exchanges)?

>>>Start 
A) Thanks for the info. In case the client gets an IPv6 address in the
informational exchange response, will a new IPSec IPv6 SA be established
with this IPv6 pushed address that would be used for IPv6 traffic? I
assume that the ipsec ipv4 SA would still be there for the previously
obtained IPv4 pushed address. Correct?

B) Would there be a possibility of the client getting a new IPv4 address
in the informational exchange response different from the IPv4 address
obtained in the AUTH_EXCHANGE. If yes, under what scenarios is this
possible? Since the INTERNAL_ADDRESS_EXPIRY is no longer supported as an
attribute type in the CP payload (as per the draft),  the case of client
requesting for an address due to a lifetime expiry is ruled out.

If the above is true, how should we handle the new IPv4 address
obtained? Would we delete the older IPsec SA that was constructed with
the previously obtained pushed address and create a new IPSec SA for the
new address? Or Have both the IPSec SAs? (I dont think this is possible
as client would not know which IPSec SA to use).  If we are deleting the
older SA, which one of the below methods is used?

    b1) First create the new ipsec SA and then delete the older ipsec SA
under the same IKE SA.  OR

    b2) Delete the IPSec SA which will also delete the IKE SA since that
was the last IPSec SA. Now construct a new IKE SA and a new IPSec SA
using the newly pushed address.

>>>End

          ^^^^^

>>>Yes, I meant IKE AUTH_EXCHANGE.

> Hence, a child SA will be setup with 3.3.3.3 to 2.2.2.2. Is that

I am not sure what you are asking here. There isn't any NATs there in
general case. Normally the client proposes the TSi of any to the
responder and responder will then assign the address (3.3.3.3 in this
case), and it will then narrow down the proposal initiator make to that.

>>> Yes, NAT is purely implementation dependent. Its not applicable in
this case.

> Assuming above is true, both IKE SA and child SA have been set up.
> Now, suppose a CP payload is exchanged as part of informational
> exchange and a new IP address is pushed to the client as part of this
> message. Is this possible?

Yes.

> If yes, what would happen to the existing IPsec SA. Will it be deleted
> and new child SA set up? OR will a new child SA be set up?

> 3. Suppose we have the normal SA_INIT and AUTH_EXCHANGE which create
> an IKE SA and a child SA without any configuration messages exchanged
> during these exchanges. After this is done, now suppose the CP
> payloads are exchanged as part of the informational exchange and the
> peer pushes a new IP address to the client. What would happen to the
> existing child SA?

Nothing will happen to them. They stay there and can be used as before.

> will the existing child SA be deleted and a new one set up?

They are not modified, and are not automatically deleted. If the client
wants to use the new IP-address it has been pushed to it most likely
needs to create new IPsec SA that allows that traffic also, as the SAs
created before most likely do not allow that traffic.
--
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 21 Nov 2008 17:29:46 +0200

Raghunandan P (raghup) writes:
> with this IPv6 pushed address that would be used for IPv6 traffic?

Client needs to create new IPsec SAs for those IPv6 traffic, i.e.
after getting the IPv6 address it can simply do create child sa
exchange with traffic selectors matching the IPv6 address and create
new IPsec SA for that use.

> I assume that the ipsec ipv4 SA would still be there for the
> previously obtained IPv4 pushed address. Correct?

Yes.

> obtained in the AUTH_EXCHANGE.

Yes, that would be possible. 

> If yes, under what scenarios is this possible?

I am not sure if there is real scenarios where this can happen, as it
does require the client to do start informational exchange to request
new IP-address, but perhaps it could be possible in cases where client
realizes after the initial IKE_AUTH that he needs multiple IPv4
addresses, and requests more of them. This is something that is not
that well defined, i.e. can server return just the same address it did
last time, or what? I.e. does the client need to ask for 2 addresses,
and prefilling one with the address it already has, so server can give
2 addresses, where one is new and one is the same old one client
already had.

But as long as we do not have any real scenario where this would be
needed, I do not think we need to waste our time to specify exactly
how it is supposed to work... 

> Since the INTERNAL_ADDRESS_EXPIRY is no longer supported as an

Yes.

> new address?

As the old IPv4 address is still valid until the IKE SA is deleted
(ikev2bis text), then there is no need to delete or do anything for
the old IPsec SAs. 

> Or Have both the IPSec SAs? (I dont think this is possible as client
> would not know which IPSec SA to use).

As it was the client who requested the get the another IP-address,
client should have some way to know why it wanted it and it needs to
have some kind of method to know which of them is used for which
traffic. 

> If we are deleting the older SA, which one of the below methods is
> used?

No need to delete it.

> under the same IKE SA.  OR

This is one way of doing it.

> using the newly pushed address.

Deleting last IPsec SA DOES NOT delete the IKE SA. IKE SA can exists
even without any IPsec SAs, so you can delete the IPsec SA, and then
recreate the IPsec SA using the same IKE SA, even when the deleted
IPsec SA was last in the IKE SA.

You can also just delete the IKE SA and start over and create new IKE
SA and ask new addresses in the configuration payload of the IKE_AUTH,
but in that case it would be no need to do configuration payload in
the INFORMATIONAL exchange before deleting IKE SA, if you are going to
delete IKE SA anyways. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Raghunandan P (raghup)" <[email-masked]>
Date: Wed, 26 Nov 2008 11:23:30 +0530

Hi,
I was going through the IKEv2 draft and needed a clarification on the
following:

The section 3.15.2 clearly explains the use of INTERNAL_IP4_SUBNET in
the CFG_REPLY and how the peer can convey the subnet behind it which
would be carried in both the CFG_REPLY payload and Tsr payload. However,
I wanted more clarification on the below line:

Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in
   CFG_REQUESTs is unclear, they cannot be used reliably in
   CFG_REQUESTs.

If the client itself wants to announce subnets behind it as part of
CFG_REQUEST, cant this be taken care by the peer so that it can send the
Tsi back to the client  accordingly having the information contained in
the CFG_REQUEST payload? (just like the peer sends same information in
TSr and CFG_REPLY payloads). Any plan to add more clarity on this and
how this scenario needs to be handled?

Thanks
Raghu

---

From: <[email-masked]>
Date: Wed, 26 Nov 2008 12:20:42 +0200

Hi Raghu,

INTERNAL_IP4/6_SUBNET, like the other configuration payloads currently
defined, is meant for client-to-VPN-gateway use (e.g. remote access
from laptop to corporate intranet), not gateway-to-gateway use.

(If the client itself has subnets behind it, it would be a gateway.)

Best regards,
Pasi

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of ext Raghunandan P (raghup)
> Sent: 26 November, 2008 07:54
> To: [email-masked]
> Subject: [IPsec] Meaning of INTERNAL_IP4_SUBNET
> 
> Hi,