Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header.

From: [email-masked]
Date: Thu, 16 May 2002 11:10:55 +0530

From: [email-masked]

> I think in draft nowhere it is mentioned that MN will send BU when it
> receives packet without routing header. MN will send BU when it receives
> tunneled packet, right ?

Yes.  I think the following two are same.

- check if the packet is tunneled like below or not.
  [src:HA][dst:MNCoA]([src:HA][dst:MNHoA](payload))

- check if the packet doesn't have a mip6 routing header like below or not.
  [src:HA][dst:MNHoA](payload)

If the MN receives a packet sent from some address to its home address
without routing header, we can conclude that the peer doesn't have a
binding.  The original idea of this algorithm is presented by Hesham
Soliman on the mobile-ip mailing-list
<[email-masked]>

> And as BA is send to the source address of the BU message and source
> address of the BU message is the COA, so for COA there will be no any
> binding exist in the Binding Cache as key for searching Binding Cache is
> the Home address, so CN will not add routing header.....

A BU is sent with a HAO.  It looks that the packet is logically sent
from the home address of the MN.  Since the source address of the BU
is the home address of the MN, the HA will send a BA to the home
address of the MN.  At this point, the HA has a valid binding cache
entry for the MN.  As a result, a routing header will be inserted as a
normal outgoing packet processing.

==>>
when MN sends Binding Update to HA, it sends with HAO, but when MN sends
Binding Update to CN it will not include HAO. refer section 9.4.1 Receiving
binding Update in "Mobile ip Draft- 17". so if we send BA to the source
address of BU, then BA will be sent without routing header, and if type 2
routing header is to be added we have to take Home address of MN from the
Home Address field of BU Message and then send BA with destination address
as a home address.
an I right.. ?

Arvind

---

From: Francis Dupont <[email-masked]>
Date: Thu, 16 May 2002 19:48:18 +0200

when MN sends Binding Update to HA, it sends with HAO, but when MN sends
   Binding Update to CN it will not include HAO. refer section 9.4.1

=> until this I-D 17 it MUST include HAO. Someone of the Disaster Team
has reversed this but next I-D should get an even number and MUST again...

Regards

[email-masked]

PS: of course it MUST include a HAO if one'd like to protect it by IPsec.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 May 2002 23:30:25 +0300

> PS: of course it MUST include a HAO if one'd like to protect it by IPsec.

I'm the guilty party for this change.

The reason for the change was that per the HAO reflection attack discussion,
we didn't want HAOs to be accepted unless there was a BCE entry. Clearly there
might not be a BCE entry at the time the BU is sent, so there was a chicken-and-egg
problem. The alternative solutions were (a) not use HAO in the BU or (b) special
processing of the HAO for certain messages i.e. allowing them for BUs.

But you are right of course in your IPsec comment above, and that wasn't
considered in making the change. I wonder if alternative (b) would have been
the right approach instead. Lets see... we'll assume the CN has an IPsec policy
that drops all other traffic except that which comes from the MN's home address.
And this traffic needs to use IPsec. For solution (a) we could not have sent
a BU at all to the CN. For solution (b), we can include the HAO and have even
this packet pass the policies. Does (b) create any new reflection problems?
It does not, if the BA is delivered directly to the MN. Can we always know
if special processing is needed? Hmm... we can't if the message is encrypted.
But if the message is encrypted, then we have an SA and we should trust HAOs
when an SA exists... So, my first thought is that alternative (b) would work
better. What do you think?

Jari

---

From: Francis Dupont <[email-masked]>
Date: Fri, 17 May 2002 11:09:38 +0200

The reason for the change was that per the HAO reflection attack discussion,
   we didn't want HAOs to be accepted unless there was a BCE
   entry. Clearly there might not be a BCE entry at the time the BU is
   sent, so there was a chicken-and-egg problem.
   The alternative solutions were (a) not use HAO in the BU or (b) special
   processing of the HAO for certain messages i.e. allowing them for BUs.
   
=> (c) there is a third solution (c): perform the HAO verification at
the right time.

   But you are right of course in your IPsec comment above, and that wasn't
   considered in making the change. I wonder if alternative (b) would have been
   the right approach instead. Lets see... we'll assume the CN has an IPsec
   policy that drops all other traffic except that which comes from
   the MN's home address.

=> this is right but for IPsec the HAO is transparent (this is why it must
be before any IPsec header).

   And this traffic needs to use IPsec. For solution (a) we could not have sent
   a BU at all to the CN. For solution (b), we can include the HAO and have
   even this packet pass the policies. Does (b) create any new reflection
   problems?
   It does not, if the BA is delivered directly to the MN. Can we always know
   if special processing is needed? Hmm... we can't if the message is
   encrypted.
   But if the message is encrypted, then we have an SA and we should trust HAOs
   when an SA exists... So, my first thought is that alternative (b) would work
   better. What do you think?
   
=> the best is to wait to have the "upper layer" header to perform the
verification (BCE check, IPsec, BU, ...). I don't believe there are DoS
vulnerabilities (because the HAO processing is very light) but for
reflection ICMP error stuff should be careful so I propose:
 - a HAO processed flag
 - a HAO verified flag
 - verification routine uses IPsec results or BCE check or any other
   good mechanism
 - "upper layer" processing should check the first flag and call the
   verification routine
 - same for ICMP error triggered by something between HAO and "upper layer"
etc.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Fri, 17 May 2002 16:46:36 +0300

>  - same for ICMP error triggered by something between HAO and "upper layer"

Works for me.

Jari