Subject: RE: [Mip6] WGLC: Reviewofdraft-ietf-mip6-bootstrapping-integrated-dhc-02

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 5 Mar 2007 19:48:36 -0800

Hi Kuntal, 

> -----Original Message-----
> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Friday, March 02, 2007 8:53 PM
> To: Alper Yegin; Narayanan, Vidya; Mobile IPv6 Mailing List
> Subject: RE: [Mip6] WGLC: 
> Reviewofdraft-ietf-mip6-bootstrapping-integrated-dhc-02
> 
> 
> 
> > -----Original Message-----
> > From: Alper Yegin [mailto:[email-masked]]
> > Sent: Friday, March 02, 2007 5:26 AM
> > To: 'Narayanan, Vidya'; 'Mobile IPv6 Mailing List'
> > Subject: RE: [Mip6] WGLC: Reviewofdraft-ietf-mip6-bootstrapping-
> > integrated-dhc-02
> > 
> > >
> > > 5. I noticed a discussion based on Kilian's comments to 
> include the
> HoA
> > > allocation via DHCP as a possible option. If we decide to include
> that,
> > > it would be important to talk about how that HoA gets 
> tied to the SA 
> > > created between the MN and HA. If the HoA is assinged via IKEv2,
> IKEv2
> > > takes care of such a binding. If not, we need to describe how the 
> > > address is bound to the SA. The use of DHCP to assign anything
> requiring
> > > particular security values is tricky to handle and I 
> suggest that we 
> > > don't get into that in this draft.
> > 
> > I'll leave this to Kuntal.
> > 
> [KC>] Well, I don't understand what is tricky in getting an 
> IPv6 address assigned from DHCP server and using it in the 
> IKEv2 CFG_REQUEST as
> *requested* INTERNAL_IP6_ADDRESS. This is clearly allowed in RFC 4306.
> Even mip6-ikev2 spec talks about this:
> 
> "
>    The mobile node could suggest a home address that it wants 
> to use in
>    the CFG_REQUEST.  For example, this could be a home address that it
>    was allocated before or could be an address the mobile node auto-
>    configured from the IPv6 prefix on the home link.  The Home Agent
>    could let the mobile node use the same home address by setting the
>    INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same
>    home address.  If the home agent wants the mobile node to use a
>    different home address, it sends a new home address in the
>    INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload.  
> The Mobile
>    Node MUST stop using its old home address and start using the newly
>    allocated home address.
> "
> 

Yes, requesting a certain address to be assigned in IKEv2 is certainly
allowed. However, RFC4306 does not cover the case where the client,
outside the IKEv2 exchange, uses DHCP to obtain an IP address and then
request that address to be assigned. This has the following
implications: 

- since the MN doesn't really indicate that the IP address was obtained
via DHCP, does the HA (IKEv2 responder function, really) know that that
was the case? 

- if the HA is also using a DHCP server to assign addresses, does it
check to see if the address is available? If the DHCP pool management is
done right, it should be the same server from which the MN obtained its
HoA to begin with (having two servers managing the same prefix would be
a problem). However, if that is the case, is the DHCP server going to
say that the address is taken? How does it know that the address was
taken by the same MN? 

- does the HA know the lease parameters of the DHCP-assigned HoA of the
MN? RFC4306 states "INTERNAL_ADDRESS_EXPIRY - Specifies the number of
seconds that the host can use the internal IP address.  The host MUST
renew the IP address before this expiry time." This behavior will allow
the HA to ensure that the MN is never capable of redirecting traffic for
another node by continuing to use the SA with that IP address even after
that address expires. If the DHCP process was done outside of IKEv2, it
is not clear how that is feasible and how the HA can keep track of that.

It doesn't look like the HIOPT draft addresses such issues either. We
can discuss those issues in the context of the HIOPT draft, but, for
now, I think not referring to this is a good way to move forward with
this draft. 

Hope that helps. 

Regards,
Vidya

> -Kuntal
>  
> 
> 
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
> 

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

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 6 Mar 2007 17:19:38 -0500

Hi Vidya,

Please see my comments inline....

Thanks,
Kuntal

> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Monday, March 05, 2007 9:49 PM
> To: Chowdhury, Kuntal; Alper Yegin; Mobile IPv6 Mailing List
[KC>] Note that in the integrated scenario, the HoA is obtained by the
MN (DHCP Client) NOT as IA_NA/IA_TA options, but as an IP config option
as carried in Home Network Information Option sub-opt-code = 3. The
NAS/DHCP server receives this address as part of the Home Network
Information received from the MSA (AAA server). So, there is no state in
the DHCP server for this parameter.

The case when the MN is trying to use an IPv6 address which it obtained
via DHCPv6 IA_NA/IA_TA options as the HoA (INTERNAL_IP6_ADDRESS), is
also possible. Nothing prevents it from doing that. But, that scenario
is outside the scope of the integrated scenario solution.

> via DHCP, does the HA (IKEv2 responder function, really) know that
that
[KC>] No it does not. I don't think IKEv2 responder cares how the MN
obtained the INTERNAL_IP6_ADDRESS hint.

> say that the address is taken? How does it know that the address was
[KC>] The address is assigned by the MSA (AAA server returns the address
to the NAS at the time of access auth/authz). The IKEv2 responder
authorizes the MN to use that address (that is requested by the IKEv2
initiator) by interacting with the AAA server in the MSA. If the
authorization fails, the IKEv2 responder may suggest/assign a different
INTERNAL_IP6_ADDRESS address to the MN. This address can be obtained by
the IKEv2 responder out of band (DHCP is one possible option).

> is not clear how that is feasible and how the HA can keep track of
that.
[KC>] The scenario that you are describing here is applicable when the
MN obtains an IPv6 address via stateful DHCPv6 operation (use IA_NA/TA
options). This case is outside the scope of the integrated scenario
solution, but as I mentioned, it is possible since nothing prevents it
from happening. In such case, the Home Agent / IKEv2 responder need not
know the DHCP lease time for the address that the MN requested/hinted in
INTERNAL_IP6_ADDRESS. It can set the INTERNAL_ADDRESS_EXPIRY field with
a value that it is configured to support. I don't think this value needs
to be coordinated with the DHCP lease time. The DHCP client in the MN
will ensure lease renewal based on DHCP lease timer as per RFC 3315. The
IKEv2 implementation in the MN will ensure the IKEv2/IPsec session is
renewed as per RFC 4306.

> now, I think not referring to this is a good way to move forward with
[KC>] N0, HIOPT I-D is not defining stateful DHCP IP address assignment
behavior. So, it should not have to describe these scenarios.

> Hope that helps.
[KC>] Your comments do bring up some good points that should be
clarified in the integrated solution I-D. Again, thanks for your
comments.