Subject: RE: [mobile-ip] observation on the mip/ipsec draft

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 28 Oct 2002 23:56:52 +0100

Jari,

  >     ... using the same home agent. This MUST be achieved by checking
  >     that the given home address has been used with the right
  >     security association. Such a check can be provided in
  >     IPsec processing, by having the security policy database entries
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   
  >     unequivocally identify a single security association for any
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  >     given home address and home agent. The check may also be
  >     provided as a part of Mobile IPv6 processing, if information
  >     about the used security association is available in there. In
  >     any case, it is necessary that the home address of the mobile
  >     node is visible in the Binding Updates and Acknowledgements.
  > 
  > Note that I have chosen to _require_ the check above, even if you
  > are right that in theory there might be some organizations that
  > don't need it in their network. But I'm not sure I like making
  > it optional.

=> Note the underlined lines. I don't think the check will be 
in the SPD. The check will be as follows: 

- IPsec processing verifies the packet
- MIPv6 module receives the packet from IPsec. 
- MIPv6 module checks the SPI used for this SA
- If (SPI == this_HoA_SPI) accept BU;
so the MIPv6 module needs to know the SPI - HoA mapping
a priori.

Hesham

  > 
  > Is this all? Assuming of course that the number-of-sas issue
  > is kept orthogonal to authorization. By the way, I'm not sure
  > I fully understand in what situations you can reduce the number
  > of SAs. Can you do it even if you don't protect regular
  > payload traffic but still need protection for BUs, prefix discovery,
  > and HOTI? Does the Mobile IPv6 code need to be able also *control*
  > the use of SA, and not just observe what SAs got used?
  > 
  > Jari
  >

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Oct 2002 01:09:11 +0200

> so the MIPv6 module needs to know the SPI - HoA mapping

Yes, but the text I suggested tried to allow for either
implementation technique. That is, either in the SPD or
in the MIPv6 module.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 28 Oct 2002 21:21:50 -0800

Jari,

Is there any advantage in using the SPD?

            jak

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Oct 2002 15:26:32 +0200

> Is there any advantage in using the SPD?

Well, one advantage is that you might have an
implementation that doesn't provide an API but
can track addresses in the SPD.

As long as this is not visible on the wire, I think
we should allow any implementation technique. In this
case we are requiring a match (hoa - sa), but not
mandating that it is done in the SPD or in MIPv6.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 29 Oct 2002 09:57:27 -0800

> Is there any advantage in using the SPD?

if you keep aside the philosophical auth-in-app stuff, the
advantages are

1. current standard practice.

2. HA receiving a tunneled HoTi.

from section 14.5 of
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txt

> When receiving
>    tunneled traffic the home agent verifies the outer IP address
>    corresponds to the current location of the mobile node.  This
>    prevents attacks where the attacker is controlled by ingress
>    filtering.  It also prevents attacks when the attacker does not know
>    the current care-of address of the mobile node.  Attackers who know
>    the care-of address and are not controlled by ingress filtering could
>    still send traffic through the home agent.  This includes attackers
>    on the same local link as the mobile node is currently on.  But such
>    attackers could also send spoofed packets without using a tunnel.

in the auth-in-app solution, by the time the MIPv6 module gets 
the packet, the decapsulation is done. the outer header is lost. 
how does the MIPv6 module perform the check?

with the check in SPD, it was easy.

3. again take the tunneled HoTi.

with the check in SPD, when the HA receives a tunneled HoTi
message, it goes through IPsec processing and then onto
the forwarding code. it does not go into the MIPv6 module.

with auth-in-app approach, it needs to go through the MIPv6
module (because it needs to check if the tunnel CoA matches
the CoA in the binding cache entry).

this issue becomes more significant when you have reverse
tunneled IPsec protected payload traffic. the HA has to do 
the check for every packet.

regards
Vijay