Subject: Re: [Mip6] one question about Return Routability procedure

From: QIU Ying <[email-masked]>
Date: Fri, 18 Nov 2005 10:17:01 +0800

Hi,

I don't think that the RR can be run in parallel with the home registration. 
The HoTI/HoT messages must go through the secure tunnel MN-HA. Therefore, 
the messages must wait till the tunnel is ready and SA is updated SA in HA.

Regards
Qiu Ying

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Nov 2005 05:30:29 +0200

QIU Ying wrote:

> I don't think that the RR can be run in parallel with the home 
> registration. The HoTI/HoT messages must go through the secure tunnel 
> MN-HA. Therefore, the messages must wait till the tunnel is ready and 
> SA is updated SA in HA.

Well, RFC 3775 seems to say that you can do it in parallel:

   After the mobile node has sent a Binding Update to its home agent,
   registering a new primary care-of address (as described in Section
   11.7.1), the mobile node SHOULD initiate a correspondent registration
   for each node that already appears in the mobile node's Binding

Of course, running things in parallel is somewhat optimistic,
packet loss or reordering can make it so that the tunneled data
packets containing HOTIs arrive at the home agent before the
BU, and are dropped. Nevertheless, packet loss would also have
an impact even if you didn't do things optimistically, and in any
case the mobile nodes need to be prepared for the possible loss
of these packets.

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Fri, 18 Nov 2005 08:53:02 +0100

Jari,

are you sure that the HoTI would be dropped if it is sent from a care-of 
address different than the one the HA has in its binding?  RFC3775 has 
no such rule, neither has RFC3776.  It might be an implementation issue, 
though.  (See also thread starting at [1].)

RFC3775, section 10.4.6, also only talks about the importance of the 
care-of address when packets are sent by the HA through the tunnel.

Maybe, the issue comes with step 1 in section 6.6, RFC3776, if the 
care-of address does not match with parameters for SPI == spi_c?  OTOH, 
the SAD entry in the home agent for incoming RR packets does not 
explicitly mention the care-of address:

   From RFC3776, section 5.2.2:
      home agent SAD:
        - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
          source = any & destination = home_address_1 & proto = MH
        - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
          source = home_address_1 & destination = any & proto = MH

- Christian

[1]  http://www1.ietf.org/mail-archive/web/monami6/current/msg00383.html

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Nov 2005 09:40:25 +0100

In your previous mail you wrote:

   are you sure that the HoTI would be dropped if it is sent from a care-of 
   address different than the one the HA has in its binding?

=> as it is protected by IPsec which provides source origin authentication
there is no reason to drop it more than spurious implementation constraints.

Regards

[email-masked]

PS: note this issue is a return routability one, i.e., when you can send
directly the BU to the CN you don't even need a working HA...

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 18 Nov 2005 17:49:28 +0900

Hi Christian,

On Fri, 18 Nov 2005 08:53:02 +0100

> though.  (See also thread starting at [1].)

When it comes to the receiving/sending HoTI/HoT over IPsec tunnel,
I think it's general IPsec issue.  Let me expand it more:

Assuming that MN and HA establish IPsec tunnel and MN performs
movement changing its care-of address from CoA1 to CoA2.  MN in
parallel initiates RR (somehow home keygen token is expired)
by sending HoTI to its CN over the IPsec tunnel (endpoint is
updated with CoA2).  Suppose BU is dropped on the fly by accident.
Should HA drop the HoTI received from the uknown CoA ?

I think the answer is No.  To my knowledge, there is no reason
for HA to deny incoming packet (HoTI) as far as there is correct
SA (even outer source address does not match with the address
stored in SA).  But we should note that HA will forward the HoT
to the wrong place, namley the old CoA of the MN (CoA1).
So, RR will be incomplete.

But this does not necessarily mean that we should not perform
optimization (=perform RR in parallel) of course.  In most of
the cases, we can benefit from the optimization, I think.

Regards,
Shinta

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Nov 2005 10:58:19 +0200

>there is no reason to drop it more than spurious implementation constraints.
Right. This would not apply for the IPsec case, but I was thinking
of the case when the tunnel protection is turned off. I seem
to recall we had a rule that said in that case we need to check
the source address. Let me check... yes, Section 5.5.

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Fri, 18 Nov 2005 11:33:27 +0100

> of the case when the tunnel protection is turned off.  [...]

Ok, but section 5.5 only talks about payload packets.  I was thinking 
about the case where a HoTI passes the BU on the way to the HA.  Such a 
HoTI should NOT be dropped, AFAIK.  I.e., I don't see RFC3775 menion a 
source-address check for the HoTI---unless HoTIs are considered one type 
of "payload" packet, in which case section 5.5 would apply.

In any case, there is an issue with reverse-tunneled payload packets. 
If such a payload packets passes the BU on the way to the HA, the HA 
will drop it.  But that's similar to the MN-CN case (Route 
Optimization):  The CN also drops payload packets from a registered home 
address, but an unknown care-of address.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 18 Nov 2005 11:39:16 +0100

>            But we should note that HA will forward the HoT

Not really.  If the BU was not lost, but just passed by the HoTI, it may 
arrive at the HA before the HoT comes back from the CN.

- Christian

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Nov 2005 13:10:22 +0200

Christian Vogt wrote:

> I.e., I don't see RFC3775 menion a source-address check for the 
> HoTI---unless HoTIs are considered one type of "payload" packet, in 
> which case section 5.5 would apply.

I thought that was the case. But I'll admit that this would
be open to interpretation.

--Jari