Subject: RE: [Ipsec] Need clarification on IKEv2 CP vs. MIPv4 IP addressassignment

From: [email-masked]
Date: Tue, 12 Jul 2005 11:02:13 +0300

Hi,

I don't see any conflict between the two excerpts...?

It says that supporting CPs is not required (this kind of
implementation never sends any CPs and silently ignores any 
CPs it receives). The requirement "CP(CFG_REQUEST) MUST contain 
at least an..." applies only to implementations that send
CP(CFG_REQUEST)s.

About FAILED_CP_REQUIRED: the responder sends this only
when its local policy says so, so presumably 3GPP2 can
say that "3GPP2-WLAN interworking gateways must not use
a policy that causes this error to be sent" (or something
like that).

(BTW, if you're doing address assignment outside IKEv2 but
inside the IPsec tunnel created by IKEv2, that's going to be a
bit complicated. You first need to create IPsec SAs with traffic
selectors matching the address assignment packets, then do the
address assignment, and only after that create additional IPsec 
SAs with traffic selectors containing the newly assigned address. 
Something like RFC 3456 probably.)

Best regards,
Pasi

> -----Original Message-----
> From: Dondeti, Lakshminath
> Sent: Tuesday, July 12, 2005 7:31 AM
> To: [email-masked]
> Subject: [Ipsec] Need clarification on IKEv2 CP vs. MIPv4 IP 
>   addressassignment
> 
> Hi,
>
> I was told that this issue came up in a 3GPP2-WLAN
> Interworking discussion and is related to a conflict between
> IKEv2-CP address assignment vs. MIPv4 IP address assignment.
> The IKEv2 spec seems to say different things at different
> places, so a clarification might help (perhaps in the
> ikev2-clarifications I-D).

> Some details below: In interpreting the CP requirements, the
> following two excerpts from IKEv2 seem to take differing
> precedence for different people.
>
> Section 2.19, Page 34 of ikev2-17 says: "CP(CFG_REQUEST) MUST
> contain at least an INTERNAL_ADDRESS attribute (either IPv4 or
> IPv6) but MAY contain any number of additional attributes the
> initiator wants returned in the response."
>
> Section 4, Page 85 says:
>
> "Implementations are not required to support requesting
> temporary IP addresses or responding to such requests. If an
> implementation does support issuing such requests, it MUST
> include a CP payload in message 3 containing at least a field
> of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All
> other fields are optional. If an implementation supports
> responding to such requests, it MUST parse the CP payload of
> type CFG_REQUEST in message 3 and recognize a field of type
> INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports
> leasing an address of the appropriate type, it MUST return a
> CP payload of type CFG_REPLY containing an address of the
> requested type. The responder SHOULD include all of the other
> related attributes if it has them."
>
> In case of MIPv4, if a VPN gateway is also a FA, assuming all
> address assignment is taken care of within MIPv4, can other
> protocol specifications (e.g., 3GPP2 specs) using IKEv2 assume
> that compliant implementations do not have to support CP-based
> address assignment?
>
> I am also concerned about a RAS sending a FAILED_CP_REQUIRED
> to a client that wants to use MIPv4 based address assignment
> and not the CP-based address assignment.
>
> Thoughts and comments welcome.  Thanks in advance.
>
> best regards,
> Lakshminath

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 12 Jul 2005 12:35:53 -0400

Hi Pasi,

Thanks.  The conflict is a bit subtle in that one could use one of the 
following excerpts from ikev2-17 to claim that if there is address 
assignment it MUST be done using CP and the other to say that CP is 
optional, period.  The FAILED_CP_REQUIRED is also an area of concern if 
an implementation is not MIPv4 address assignment sensitive.  I am still 
exploring this topic and your thoughts are quite helpful!

best regards,
Lakshminath