Subject: [mobile-ip] How to process HAO

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 25 Apr 2002 18:45:05 +0900 (JST)

Hi,

May I ask a question about processing a HAO?  I think the processing
is difficult to implement.  I will try to explain why it is difficult.

The latest discussion concludes that a HAO must not be processed
without a valid BCE.  Also, the BU/BA for the home registration must
be protected by the ESP.

1. The home registration.

The BU/BA for home registration must be protected by the ESP.  To do
this, the HA and the MN must have the SA and the SPD properly.  For
example,

On HA:	SA1: HA, MN_HoA, ESP
	SA2: MN_HoA, HA, ESP
	SPD: HA -> MN_HoA, MH, ESP

On MH:	SA1: HA, MN_HoA, ESP
	SA2: MN_HoA, HA, ESP
	SPD: MN_HoA -> HA, MH, ESP

Since we use a MN_HoA as a endpoint of the SA and the SPD, the BU/BA
for the home registration packet must include a HAO.

2. Dropping a packet which contains a HAO without a valid BCE.

The CN must drop packets which contain a HAO without a valid BCE.  The
HA is also a CN.  When processing a BU from a MN, a HA first encounts
a HAO.  Since the HA doesn't have a BCE for the MN, the BU is dropped.

Conclusion: the home registration never be processed.

Condideration:

- Using MN_CoA as an endpoint of the SA/SPD:

Using MN_CoA makes it possible to remove a HAO from a BU.  But, if we
use a MN_CoA, the SA entry and the SPD entry must be updated at each
time when the MN moves.  In addision, it requires some SA
establishment mechanism because the HA never know the new CoA that the
MN gets on the newly visited foreign network.  It seems unrealistic.

- Introduce a flag that indicates 'I saw a HAO'.

Instead of dorpping the packet which contains a HAO without a valid
BCE immediately, just set a flag that means this packet has a HAO.
After all extension headers are processed, check the BCEs.  If we have
no BCE corresponding to the HAO, we drop the packet.

This method works except one inappropliate behaviour.  If the packet
has other exthdr/DOs after a HAO, the exthdr/DOs are processed.
Obviously, those exthdrs/DOs must not be processed because the packets
that has a HAO without a valid BCE must be dropped.

How do you think about this?

If I am missing something, please correct me.

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Francis Dupont <[email-masked]>
Date: Thu, 25 Apr 2002 17:07:14 +0200

without a valid BCE.

=> I disagree: it must not be processed if it is not verified and
there are at least two ways to verify a HAO:
 - BCE check
 - IPsec (the idea is if the HAO is fake the IPsec processing will
   reject the whole packet, look at my ID about IPsec and Mobile IPv6).

   Also, the BU/BA for the home registration must be protected by the ESP.
   
=> so the HAO will be verified and as soon as the next header type is ESP
the BCE check is no more necessary. Unfortunately the SA pair would be used
only for the protection of BU/BA exchange: a waste but it *is* secure!
(this comment is only for the home registration and when the only direct
traffic between the MN and the HA is the mobility signaling).

   ... for the home registration packet must include a HAO.
   
=> note that the situation is very different for ordinary BUs because
the home address is usable at any moment, including before the processing
of the BU.

   The CN must drop packets which contain a HAO without a valid BCE.

=> add "if there is no other way to verify it" and you are saved.

=> I am not convinced the home registration is really completely handled
in last documents. Your message won't change my opinion (:-).
   
   Condideration:

=> NO, you should use MN_HoA!

   It seems unrealistic.
   
=> because it is!

=> too complex. Try my IPsec stuff.

=> help me for the next version of my ID (:-)?

Regards

[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 25 Apr 2002 10:54:05 -0700

hi Keiichi,

There was a discussion between Erik Normark and myself. I think
we concluded on something similar to the following. (correct me
if missed something, Erik).

HAO is processed if

  - if there is a BCE with CoA = IPv6 src and HoA = HAO content
  - if there is a home registration BCE with HoA = HAO content
  - if packet contains BU and satisfies the security policy
    between MN and HA 
  - if packet contains AH or ESP header and satisfies the security
    policy check between MN and HA.

The last two bullets could be combined into one. And then it 
becomes the IPsec check that Francis is talking about.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 25 Apr 2002 10:57:09 -0700

And of course, assuming the SPD/SAD uses MN's HoA always.

Vijay

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Fri, 26 Apr 2002 15:05:20 +0900 (JST)

Hi Vijay,

From: Vijay Devarapalli <[email-masked]>

>   - if there is a BCE with CoA = IPv6 src and HoA = HAO content

fine.

>   - if there is a home registration BCE with HoA = HAO content

fine.

>     policy check between MN and HA.

To check if the packet has a BU or not, we must chase all the exthdrs
before processing a HAO because a BU is included in a MH which is the
last exthdr.  Also, to check if the packet satisfies the security
policy, we must process the ESP header before processing a HAO...
Hmm..

I tend to agree with the Francis's idea to process a HAO if the next
header value of the destination option header which contains a HAO is
ESP.  This makes it simple to implement a HAO processing.

---
Keiichi SHIMA

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Fri, 26 Apr 2002 15:10:49 +0900 (JST)

Hi Francis,

From: Francis Dupont <[email-masked]>

>    reject the whole packet, look at my ID about IPsec and Mobile IPv6).

OK.  I agree with you.

> traffic between the MN and the HA is the mobility signaling).

This seems simple and effective.

One question.  We should check a framgmenation header (and the nxthdr
value in the fragmentation header) after a destination options header
which contains a HAO, shouldn't we?

---
Keiichi SHIMA

---

From: Markku Savela <[email-masked]>
Date: Fri, 26 Apr 2002 09:13:32 +0300

> ESP.  This makes it simple to implement a HAO processing.

Hmm.. just to protect dest option (and HAO) from prying eyes, I would
much more like to put ESP *before* destination options.

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Fri, 26 Apr 2002 15:40:20 +0900 (JST)

> much more like to put ESP *before* destination options.

I think we cannot put ESP before HAO unless we use a MN_CoA as an
endpoint of the SA between the HA and the MN.  Once the MN encrypts
its MN_HoA, the HA can't decrypt it because it doesn't have a SA
between HA_addr and MN_CoA.

---
Keiichi SHIMA

---

From: Francis Dupont <[email-masked]>
Date: Fri, 26 Apr 2002 11:35:30 +0200

=> as I have asked at the last IETF meeting, the ID 16 uses the
Charlie Perkins' "verified HOA" term. Unfortunately it is done
only in the section 13.2 and the ID suggests the only way to
verify a HOA is the BCE check. This is one of the many cases
the ID doesn't take IPsec into account, my principal concern
aboit it (with the traditional stupid proposal to unicast a NS
to the HA in order to get its link-layer address).

Regards

PS: the verification by a convenient IPsec transform is 100% safe
because it provides a proof of the origin of the packet (by a
secret sharing or, better, by crypto checksum in the case of AH).

---

From: Francis Dupont <[email-masked]>
Date: Fri, 26 Apr 2002 12:05:26 +0200

=> there is no choice for the SPD because SPD selector are traffic selectors
for inner addresses.  The SAD case is more complex but as the HOA must
be before the IPsec header so is processed before for incoming packets
only the HoA works. Note tehre are many other reasons to use the HoA
and the only drawback is more complexity in SA establishment for
home registration (again, look at draft-dupont-ipsec-mipv6-00.txt).

I use the occasion to fix the issue of not doing any check for the CoA
when a BU is protected by a convenient IPsec SA:
 - the possible attack (authentified BU with a bad CoA, i.e. an attack
   from the MN itself) uses reflection and doesn't hide the identity
   of the attacker at all
 - IPsec SA establishment checks strong authentication + authorization
   (so the issue doesn't exist for the HoA)
 - verification of the CoA can be impossible for home registration
   (i.e. when the CN is the HA, the only solution I can see is AAA
    with AAA infrastructure as in draft-le-aaa-mipv6-requirements-00.txt)
So I suggest to interpret the term authorization as to trust (or not)
the MN to give its real CoA. So this will become a special case for
the IPsec security policy, as to use a self-signed certificate or
a CGA is enough for mobility but not for all other purposes...
 Fortunately now the mobility signaling is a "protocol" which can
be properly handled in SPD, so this proposal is trivial to implement.
 Note this issue is only for BUs, for a regular packet to an ordinary
CN with a HOA, a convenient IPsec transform is enough and gives back
the triangular routing...

Thanks

PS: I use the term convenient because, for instance, an ESP transform
alone with null authentication is not enough for mobility (and in fact
for any) purpose.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 26 Apr 2002 14:54:37 +0200

=> Thanks!

=> I agree but with standard header positions it should be enough...

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Fri, 26 Apr 2002 14:59:34 +0200

=> for many reasons (some already explained by Keiichi) the HAO MUST
be before the ESP. For instance in order to give back the triangulat
routing when there is a convenient IPsec SA...

Regards

PS: by definition, the only thing non-mobility entities
want to know in a correspondent node is the home address!

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 26 Apr 2002 10:07:10 -0700

> ESP.  This makes it simple to implement a HAO processing.

cool... fine with me.

Vijay