Subject: [savi] IKEv2 address assignment method and SAVI

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 10 Nov 2009 03:20:47 +0100

Hi,

as promised yesterday, here is an email regarding IKEv2 address
assignment method and SAVI interaction. The scenario I have in mind is
concerning Mobile IPv6 bootstrapping [RFC5026] where the Home Agent
(HA) is providing the Home Address (HoA) to the Mobile Node (MN) via
IKEv2.

I assume the following architecture where the HA is the default router
(and also a SAVI device) and the MN is on a Foreign Network (i.e. out
of its Home Network).

	Internet-----MN
	  |
	+----+
	| HA |
	+----+
	  |
    --------------------------- Home Network
			|
       	             Node

In this scenario, the HA will provide the HoA to the MN even if the MN
is outside of its Home Network (the HoA is linked to the Home Network,
i.e. the network prefix of the HoA is advertised on the Home Network).
Unlike SLAAC or DHCP address assignment methods, there is no signaling
on the Home Network (i.e. all the exchanges are done via IKEv2
directly between the HA and the MN) and there is no DAD process.

The HA, as a SAVI device, should be able to block any flow coming from
a Node on the Home Network that tries to spoof the MN's HoA and
present proposals (i.e. FCFS, DHCP, SEND, etc.) may not be applied
(worse, IMHO, FCFS mechanism may corrupt the SAVI policy database)
because there is no signaling on the Home Network.

Comments are welcome.

Thanks in advance.

Best regards.

JMC.

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 10 Nov 2009 13:36:56 +0900

Hi, JMC

I really think this is an important scenario. And as a minor supplement, not
only the HA should filter spoofing of HoA, but also the MN MUST permit the
packets with source HoA(with no DAD or DHCP, either).

I think this scenario should be included in the framework.

Pre-registered address(static address, HoA), should have the highest
priority. This means it cannot be hijacked using any other kind of
mechanism, but only manual configuration on SAVI device.

Best regards,
Guang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jean-Michel Combes
> Sent: Tuesday, November 10, 2009 11:21 AM
> To: [email-masked]
> Subject: [savi] IKEv2 address assignment method and SAVI
> 
> Hi,
> 
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: Alberto García <[email-masked]>
Date: Tue, 10 Nov 2009 13:37:49 +0100

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
Jean-
|  Michel Combes
|  Enviado el: martes, 10 de noviembre de 2009 3:21
|  Para: [email-masked]
|  Asunto: [savi] IKEv2 address assignment method and SAVI
|  
|  Hi,
|  
|  as promised yesterday, here is an email regarding IKEv2 address
|  assignment method and SAVI interaction. The scenario I have in mind is
|  concerning Mobile IPv6 bootstrapping [RFC5026] where the Home Agent
|  (HA) is providing the Home Address (HoA) to the Mobile Node (MN) via
|  IKEv2.
|  
|  I assume the following architecture where the HA is the default router
|  (and also a SAVI device) and the MN is on a Foreign Network (i.e. out
|  of its Home Network).
|  
|  	Internet-----MN
|  	  |
|  	+----+
|  	| HA |
|  	+----+
|  	  |
|      --------------------------- Home Network
|  			|
|         	             Node
|  
|  In this scenario, the HA will provide the HoA to the MN even if the MN
|  is outside of its Home Network (the HoA is linked to the Home Network,
|  i.e. the network prefix of the HoA is advertised on the Home Network).
|  Unlike SLAAC or DHCP address assignment methods, there is no signaling
|  on the Home Network (i.e. all the exchanges are done via IKEv2
|  directly between the HA and the MN) and there is no DAD process.

I assume that RFC5026 is heavily relying in DHCP assignment, although it is
weakly expressed in the specification: "The Home Agent could consult a DHCP
server on the home link for the actual home address allocation."
Note that DHCPv6 recommends "The client SHOULD perform duplicate address
detection [17] on each of the addresses in any IAs it receives in the Reply
message before using that address for traffic."

If it does not check for duplicates and the address was in use by other host
in the network, there is going to be some trouble, isn't it? 
Are you saying that the HA assigns an address without caring about if it is
duplicated or not? 
This is a problem that may exceed SAVI scope.

|  
|  The HA, as a SAVI device, should be able to block any flow coming from
|  a Node on the Home Network that tries to spoof the MN's HoA and
|  present proposals (i.e. FCFS, DHCP, SEND, etc.) may not be applied
|  (worse, IMHO, FCFS mechanism may corrupt the SAVI policy database)
|  because there is no signaling on the Home Network.

If the address is supposed to be unique (I understand that is the assumption
of RFC5026, although I don't fully understand why, if DAD is not performed),
and the HA is also a SAVI device, then 
(1)- it could be specified that the HA created the SAVI binding when a MIPv6
binding is created, and 
(2)- it should defend it as specified in FCFS, sending DAD NADV if someone
sends a DAD NSOL

Condition (2) is the natural result of a HA with a MIPv6 binding: the HA
acts as a proxy ND and defends the HoA of a registered MN by sending DAD
NADV when required. Condition (1) should be specifically stated in SAVI for
this case (and the requirement for the HA to be a SAVI device if RFC5026 is
used).

Does this make sense?

Regards,
Alberto

|  
|  Comments are welcome.
|  
|  Thanks in advance.
|  
|  Best regards.
|  
|  JMC.
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 20 Nov 2009 11:01:22 +0100

Hi Alberto,

at first sorry for the delayed reply and thanks for your comments.

> server on the home link for the actual home address allocation."

That may be a solution but the IKEv2 implementation could also use an
internal address pool (e.g. IIRC this is the case for IKEv2 StrongSwan
implementation).

> message before using that address for traffic."

In the case where IKEv2 uses a DHCP server to get the HoA for the MN, I agree.

> Are you saying that the HA assigns an address without caring about if it is

In the case where an internal address pool is used, there is no DAD
for the assigned address.
In the case where the assigned address is provided by a DHCP server, I
would say the HA should do a DAD as a DHCP client.

> this case (and the requirement for the HA to be a SAVI device if RFC5026 is

IMHO, the problem is more complex. Explanations:
- When the MN is not in its Home Network, all the flows where the src
addr is the MN's HoA should be blocked
- When the MN is in its Home Network, all the flows where the src addr
is the MN's HoA and are going through a trusted anchor should be
allowed
A potential solution would be to update the SAVI policy in using the
Binding Update messages.

Now we can extend the issue when the SAVI device is not collocated with the HA:

       Internet-----MN
         |
       +----+
       | HA |
       +----+
         |
      +-------+
      | SAVI |
      +-------+
         |

In this case, a potential solution would be to update the SAVI policy
in the Binding Update (BU) AND Binding Acknowledgment (BA) messages
because the SAVI device is not able to check whether the BU messages
are correctly secured or not (i.e. the IPsec SA are set up between the
HA and the MN). If the SAVI sees a BA message from the HA replying to
a BU message, it may assume that the BU message was correct.

Comments?

Best regards.

JMC.

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 20 Nov 2009 11:03:15 +0100

Hi Guang,

at first, sorry for the delayed reply and thanks for your comment.

> packets with source HoA(with no DAD or DHCP, either).

Sorry, but I don't understand your point here :(

Best regards.

JMC.