Subject: [Mip6] Bootstrapping on the home link

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 6 Apr 2006 12:25:29 -0700

All,
Currently, none of the bootstrapping documents seem to address the
scenario of bootstrapping of the MN on the home link. Here is the
scenario: 

MN powers up on the home link. It has no means of knowing it is on the
home link. Hence, it configures an IP address that it thinks is a CoA
(say, statelessly). It then goes about doing IKEv2 and trying to get a
home address, at which point, it realizes that the home prefix is the
same as the prefix on which it just got an IP address. MN and HA
behavior in this scenario needs to be addressed. 

There are multiple ways in which this could work. I walked through a few
different options and here is one that I think would probably work best:

1. MN configures CoA
2. MN performs IKEv2 - HA realizes from the CoA that the MN is home
3. If the CoA is acceptable as HoA, HA returns the same address in the
CFG_REPLY. 
4. If not, HA proposes a HoA in the INTERNAL_IP6_ADDRESS attribute of
the CFG_REPLY. 
5. Either way, MN realizes it is home, based on prefix matching
6. If the CoA was accepted as the HoA, MN uses that. If not, it gives up
the CoA and uses the HA proposed address as the HoA. 
7. MN may send BU to de-register (so that other things like DNS updates,
etc. can happen and doesn't need to wait till handoff time). 

If this behavior is already discussed somewhere, please point me to it -
apologies in advance for not doing my homework in that case :)

If it is not described anywhere, thoughts on this? 

Regards,
Vidya

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

---

From: "Giaretta Gerardo" <[email-masked]>
Date: Sun, 9 Apr 2006 11:56:58 +0200

Hi Vidya,

some comments on this, inline. One more general comment: this scenario
seems not applicable to the split scenario document since the base
assumption is that there is not relationship between access service and
mobility service. It may be in the scope of the integrated scenario, as
a local HA assignment case.

> home link. 

We cannot say that the MN is on the home link or not until a HA
assignment is performed. I think you are addressing the case of a HA in
the same link of the MN and the MN tries to bootstrap with that HA. In
this scenario, based on RFC3775, the HA sends RAs with H bit set and
therefore the DNS discovery may not be performed, but this is already
defined in rfc3775. 

> Hence, it configures an IP address that it thinks is a CoA

Ideally, the MN does not need any SA if it is still in the home link.
The IPsec SA is needed only when the MN hands over to a foreign link. 
I guess there are two options here:
- the MN performs IKEv2 and establishes an IPsec SA even if it is in the
home link. Note that this may be useless (since the MN may always remain
in the home link) and this SA must not be used until the MN moves to
another link
- the MN does not perform IKev2 as soon as it stays in the home link. At
the time of the first handover, it runs IKEv2. This has one drawback
since it implies a higher handover latency for the first handover.
Another issue to be considered is that the HoA assigned in IKEv2
exchange must be the same used before by the MN in the home link. 

> 2. MN performs IKEv2 - HA realizes from the CoA that the MN is home

As mentioned, the MN itself should realize it is at home based on H bit
set in the Router Advertisements. Moreover the MN technically does not
need an IPsec SA while at home.

> 3. If the CoA is acceptable as HoA, HA returns the same address in the

The possibility to ask for an explicit address is already present in the
current specification.

> 5. Either way, MN realizes it is home, based on prefix matching

If it is performing bootstrapping with a specific HA, it has already
realized it is at home, IMO.

> If it is not described anywhere, thoughts on this? 

One more thought: there are no current deployments of MIP (3GPP2, WiMAX)
where this scenario can occur. The home links are always virtual links.
Are there real deployments where this may occur? Or are we mainly
considering an academic issue?

Regards,
--Gerardo

> Vidya
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 10 Apr 2006 19:26:38 -0700

Hi Gerardo,
This is not an academic exercise. It is true that today, the home link
is always virtual in 3gpp2 and other places. However, I am not sure that
it should remain that way as networks evolve and that is the case under
study. 
 
Having said that, I definitely do not want the IKEv2 SA establishment at
handoff time - that latency must only be added to bootstrapping times.
So, while I realize that there isn't a need for an IKEv2 and IPsec SA on
the home link, I do want those to be established at bootstrapping time,
regardless of whether the MN is on the home link or not. 
 
Also, I was not assuming that the MN knows its HA while powering up at
home. Sure, that could be solved partially with the 'H' bit - although,
it still doesn't solve the SA establishment part. This is more the case
where the MN knows nothing at power up - acquires an IP address which it
thinks is the CoA and then, when it gets an HA assigned, it happens to
be "home". So, at the time of receiving an RA with the 'H' bit set, it
has no idea that it is home - but, learns later after HA assignment
(also, I'm not limiting HA assignment via DNS - the HA assignment may
happen via other means, but that should be irrelevant to the problem
under discussion). 
 
What should be the behavior there? I think this behavior should be
captured. 
 
Thoughts? 

Regards,
Vidya

________________________________

	From: Giaretta Gerardo
[mailto:[email-masked]] 
	Sent: Sunday, April 09, 2006 2:57 AM
	To: Narayanan, Vidya
	Cc: [email-masked]
	Subject: RE: [Mip6] Bootstrapping on the home link

	Hi Vidya,
	
	some comments on this, inline. One more general comment: this
scenario
	seems not applicable to the split scenario document since the
base
	assumption is that there is not relationship between access
service and
	mobility service. It may be in the scope of the integrated
scenario, as
	a local HA assignment case.

	We cannot say that the MN is on the home link or not until a HA
	assignment is performed. I think you are addressing the case of
a HA in
	the same link of the MN and the MN tries to bootstrap with that
HA. In
	this scenario, based on RFC3775, the HA sends RAs with H bit set
and
	therefore the DNS discovery may not be performed, but this is
already
	defined in rfc3775. 
	
	> behavior in this scenario needs to be addressed. 
	
	Ideally, the MN does not need any SA if it is still in the home
link.
	The IPsec SA is needed only when the MN hands over to a foreign
link. 
	I guess there are two options here:
	- the MN performs IKEv2 and establishes an IPsec SA even if it
is in the
	home link. Note that this may be useless (since the MN may
always remain
	in the home link) and this SA must not be used until the MN
moves to
	another link
	- the MN does not perform IKev2 as soon as it stays in the home
link. At
	the time of the first handover, it runs IKEv2. This has one
drawback
	since it implies a higher handover latency for the first
handover.
	Another issue to be considered is that the HoA assigned in IKEv2
	exchange must be the same used before by the MN in the home
link. 
	
	> 2. MN performs IKEv2 - HA realizes from the CoA that the MN is
home
	
	As mentioned, the MN itself should realize it is at home based
on H bit
	set in the Router Advertisements. Moreover the MN technically
does not
	need an IPsec SA while at home.
	
	> 3. If the CoA is acceptable as HoA, HA returns the same
address in the
	
	The possibility to ask for an explicit address is already
present in the
	current specification.
	
	> 5. Either way, MN realizes it is home, based on prefix
matching
	
	If it is performing bootstrapping with a specific HA, it has
already
	realized it is at home, IMO.
	
	> If it is not described anywhere, thoughts on this? 
	
	One more thought: there are no current deployments of MIP
(3GPP2, WiMAX)
	where this scenario can occur. The home links are always virtual
links.
	Are there real deployments where this may occur? Or are we
mainly
	considering an academic issue?
	
	Regards,
	--Gerardo

--------------------------------------------------------------------
	CONFIDENTIALITY NOTICE
	This message and its attachments are addressed solely to the
persons
	above and may contain confidential information. If you have
received
	the message in error, be informed that any use of the content
hereof
	is prohibited. Please return it immediately to the sender and
delete
	the message. Should you have any questions, please contact us by
	replying to [email-masked]
<mailto:[email-masked]> .
	        Thank you
	                                        www.telecomitalia.it
<http://www.telecomitalia.it>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 11 Apr 2006 18:12:15 -0700

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]] 

> Having said that, I definitely do not want the IKEv2 SA 
> establishment at handoff time - that latency must only be 
> added to bootstrapping times. So, while I realize that there 
> isn't a need for an IKEv2 and IPsec SA on the home link, I do 
> want those to be established at bootstrapping time, 

well, when the MN is at home, it is supposed to be
on its own. no help from the HA.

> Also, I was not assuming that the MN knows its HA while 
> powering up at home. 

it is supposed to know the HA's FQDN.

> Sure, that could be solved partially 
> with the 'H' bit - although, it still doesn't solve the SA 
> establishment part. 

typically the IPsec SA setup is triggered by the MN 
wanting to send a BU. if the MN does not send a BU 
while at home, IPsec SA setup wont get triggered.

one could still configure the mobile node to create
an IPsec SA while at home. the IPsec SA is not tied
to the existence of a binding cache entry at the
home agent. but thats just configuration on the 
mobile node. not a protocol issue.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 12 Apr 2006 15:55:35 -0700

Right, I understand that per RFC3775, the MN is supposed to be on its
own when it is at home and hence doesn't need an IKEv2/IPsec SA. But, in
the interest of reducing handoff latency, don't we want to recommend
that the MN set up the SA even if it detected being at home? Actually,
there are a few things to mention here: 

1. The MN may first obtain an IP address and then discover it is home,
after HA discovery/assignment. 
2. If it wants to set up the IKEv2 SA, it must request the configured IP
address to be its home address. 
3. If the HA assigned a different HoA for whatever reason, the MN must
use that and may release the address it configured earlier. 
4. The IKEv2 SA in this case can be created with the HoA - hence, the
address on that SA may not change when the MN hands off. 

It would be good to capture these in the document. 

Regards,
Vidya

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, April 11, 2006 6:12 PM
> To: Narayanan, Vidya; Giaretta Gerardo
> Cc: [email-masked]
> establishment 
> > at handoff time - that latency must only be added to bootstrapping 
> > times. So, while I realize that there isn't a need for an IKEv2 and 
> > IPsec SA on the home link, I do want those to be established at 
> > bootstrapping time, regardless of whether the MN is on the 
> home link 
> > or not.
> 
> well, when the MN is at home, it is supposed to be on its 
> own. no help from the HA.
> 
> powering up at 
> > home.
> typically the IPsec SA setup is triggered by the MN wanting 
> to send a BU. if the MN does not send a BU while at home, 
> IPsec SA setup wont get triggered.
> 
> one could still configure the mobile node to create an IPsec 
> SA while at home. the IPsec SA is not tied to the existence 
> of a binding cache entry at the home agent. but thats just 
> configuration on the mobile node. not a protocol issue.
> 
> Vijay
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 12 Apr 2006 16:11:56 -0700

> that the MN set up the SA even if it detected being at home? 

its a configuration issue on the mobile node.
it can setup an IPsec SA with the home agent
if it wants to. since the IPsec SA is not tied
to the existence of a binding cache entry, the
HA wouldnt reject the MN's request to setup an
IPsec SA.

> Actually,

this is standard behavior. in a typical IKEv2
implementation, the initiator can propose an 
address in the INTERNAL_IP6_ADDRESS attribute. 
the responder can honor that or propose a new 
address. if there is a new address in the 
config reply, the initiator starts using the
new address.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 12 Apr 2006 16:36:10 -0700

> > own when it is at home and hence doesn't need an 
> IKEv2/IPsec SA. But, 
> > in the interest of reducing handoff latency, don't we want to 
> > recommend that the MN set up the SA even if it detected 
> being at home?
> 
> it can setup an IPsec SA with the home agent if it wants to. 
> since the IPsec SA is not tied to the existence of a binding 
> cache entry, the HA wouldnt reject the MN's request to setup 
> an IPsec SA.
> 

How is this just a configuration issue? This is about the MN triggering
the set up of an IKEv2 and IPsec SA even when it knows it is home from a
MIP6 perspective - are you saying that MIP6 implementations must allow
configuration of this behavior? There is not clear guidance to
implementors on what triggers the set up of IKEv2/IPsec SA at the MN
with the HA - for one, it could be that the need for sending a BU is
what does that, which would preclude setting up the SA while at home. 

> > 2. If it wants to set up the IKEv2 SA, it must request the 
> configured 
> > IP address to be its home address.
> >
> this is standard behavior. in a typical IKEv2 implementation, 
> the initiator can propose an address in the 
> INTERNAL_IP6_ADDRESS attribute. 
> the responder can honor that or propose a new address. if 
> there is a new address in the config reply, the initiator 
> starts using the new address.
> 

I understand standard IKEv2 behavior. This is about a recommended
behavior for the MN when it is home - an implementation may be
implemented such that it *never* proposes an address in the
INTERNAL_IP6_ADDRESS attribute - in this case, the MN benefits from
requesting the configured address, due to the fact that it realized it
is home. 

Vidya

> > > well, when the MN is at home, it is supposed to be on its own. no 
> > > help from the HA.
> > > 
> > > > Sure, that could be solved partially with the 'H' bit - 
> although, 
> > > > it still doesn't solve the SA establishment part.
> > > 
> wanting to send 
> > > a BU. if the MN does not send a BU while at home, IPsec SA setup 
> > > wont get triggered.
> > > 
> > > one could still configure the mobile node to create an IPsec SA 
> > > while at home. the IPsec SA is not tied to the existence of a 
> > > binding cache entry at the home agent. but thats just 
> configuration 
> > > on the mobile node. not a protocol issue.
> > > 
> > > Vijay
> > > 
> > 
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 12 Apr 2006 17:41:43 -0700

> what does that, which would preclude setting up the SA while at home. 

the mobile node as a regular IPv6 host can 
setup any number of IPsec SAs it wants. it is 
a matter of configuring the mobile node to 
setup an IPsec SA for protecting protocol 135, 
mh type 6 to the HA as soon as it boots up or 
as soon as it configures a home agent. you can 
do this for any protocol in your stack.

> requesting the configured address, due to the fact that it realized it

that would be an implementation limitation. any
IKEv2 implementation should be have this 
configurable on the initiator. the initiator can 
either a propose an address or request an address.
there is nothing to recommend. it is one of the
things that should be left configurable.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 13 Apr 2006 12:13:49 -0700

Vijay,
The bootstrapping documents specify some MUSTs for MIP6 bootstrapping
and also specify recommended behavior of DNS or IKEv2 as applicable for
MIP6. If we go by the same argument that we can "configure the MN to set
up an SA as soon as it gets an HA assigned", then, there are other parts
of the document that should receive similar treatment. For instance,
going by your argument, what value does the following statements in
section 9.5 of draft-ietf-mip6-bootstrapping-split add - 

"A security association is required even if the DNS server is in the
same administrative domain as the Home Agent. The security association
SHOULD be separate from the security associations used for other
purposes, such as AAA."

One can claim that HA can be configured to say that the SA with the DNS
server is a separate one. But, the statement is there because we believe
it is good recommended behavior and hence, should really be part of the
implementation and not a configuration. 

Please see some specific comments inline below. 

> > > since the IPsec SA is not tied to the existence of a 
> binding cache 
> > > entry, the HA wouldnt reject the MN's request to setup an 
> IPsec SA.
> > > 
> > 
> > How is this just a configuration issue? This is about the MN 
> > triggering the set up of an IKEv2 and IPsec SA even when it 
> knows it 
> > is home from a
> the mobile node as a regular IPv6 host can setup any number 
> of IPsec SAs it wants. it is a matter of configuring the 
> mobile node to setup an IPsec SA for protecting protocol 135, 
> mh type 6 to the HA as soon as it boots up or as soon as it 
> configures a home agent. you can do this for any protocol in 
> your stack.
> 

As for configuring the MN to set up an IKEv2 SA for protocol 135 upon HA
assignment, it makes a lot more sense to me that a MIP6 implementation
should trigger the IKEv2 SA set up upon HA assignment, without a need
for this being a configuration. 

> > > this is standard behavior. in a typical IKEv2 implementation, the 
> > > initiator can propose an address in the INTERNAL_IP6_ADDRESS 
> > > attribute.
> there is a 
> > > new address in the config reply, the initiator starts 
> using the new 
> > > address.
> > > 
> > 
> IKEv2 implementation should be have this configurable on the 
> initiator. the initiator can either a propose an address or 
> request an address.
> there is nothing to recommend. it is one of the things that 
> should be left configurable.
> 

This is not a blanket configuration. In this case, the MN would request
an IP address in the attribute when it is on the home link, but not
while bootstrapping on a visited link, for instance. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 13 Apr 2006 14:54:15 -0700

This discussion seems to be missing the point - nevertheless, some
points below.

> > and also specify recommended behavior of DNS or IKEv2 as applicable 
> > for MIP6. If we go by the same argument that we can 
> "configure the MN 
> > to set up an SA as soon as it gets an HA assigned", then, there are 
> > other parts of the document that should receive similar 
> treatment. For 
> > instance, going by your argument, what value does the following 
> > statements in section 9.5 of 
> draft-ietf-mip6-bootstrapping-split add -
> > 
> > One can claim that HA can be configured to say that the SA with the 
> > DNS server is a separate one. But, the statement is there 
> because we 
> > believe it is good recommended behavior and hence, should really be 
> > part of the implementation and not a configuration.
> 
> in this case a MUST is required because it would be a bad 
> idea for the HA to perform a DNS update without 
> authenticating itself to the DNS server.
> otherwise any malicious node in the home network or a mobile 
> node through the tunnel to its HA can send a DNS update on 
> behalf of another mobile node.
> therefore the 'MUST' is required for securing the DNS update 
> between the HA and the DNS server. it is not a configuration 
> issue on the HA in this case.
> 

I wasn't referring to the fact that an SA is needed (not at all
questioning the "MUST have an SA" part). I'm referring to the fact that
the draft talks about the fact that the SA *SHOULD* be a *separate* one
for DNS. And, this was *one* example I pulled up from the draft - if I
didn't consider the exercise a waste of time, I could pull up other text
in the document (and other MIP6 documents) along the same lines. 

> why? it could just be a security policy which 
> triggers this. 
> 

Why is this a security policy? If hosts actually supported such
configuration granularity, it would be a nightmare for admins. 

> > implementation, the 
> if you want to do this, just configure your MN 
> to always request an IP address when it is on 
> the home link but not while it is bootstrapping 
> from a visited link. or the other way around.
> 

I don't understand your motivation for saying this, when we specify such
behavior in many other places in many other documents. We need to try
and avoid a configuration mess for implementors and admins where we can.
And, of course, it doesn't seem like you are consistent with this
philosophy either, so, that doesn't allow us to make much progress. 

Vidya