Subject: RE: [mobile-ip] Mipv6 issue #192: Authz in SPD or in MIPv6?

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 3 Jan 2003 15:50:01 -0800

> 
> Mohan Parthasarathy wrote:
> 
> >>      - Address spoofing of HOTIs can't be checked (but this isn't
> >>        considered very dangerous given that HOTs are routed 
> >>correctly).
> >>
> > 
> > Could you elaborate this a bit more ? I am not sure which 
> address spoofing
> > you are talking about here.
> 
> Spoofing of home addresses. A malicious MN, MN 1, sends a 
> tunneled HOTI
> to the home agent using its own SA but MN 2's home address. 
> If the tunnel
> decapsulation at the home agent is done without any check of 
> the IP addresses,
> then there is no way we can prevent this.
> 
> Note that the difference between the two solutions is that in the
> current solution we deal with the IP address checks in the SPD.
> In Mike's solution this is left for the application. However, the
> "application" is easily available when we process MH packets but
> not when we are doing IP forwarding or generic tunnel decapsulation.
> That's why in Mike's solution we need to skip the tunnel authz
> check, or do it in some other manner.
> 

This is the SPD entry specific to RR (HOTI) message processing on Home
agent(taken from your other email) : 

	home agent SPD OUT:
          - IF source = any & destination = home_prefix_1/64 & proto = MH
            THEN CREATE ESP TUNNEL SA
	   (gateway set by APIs to current care-of address)

        home agent SPD IN:
          - IF source = home_prefix_1/64 & destination = any & proto = MH
            THEN CREATE ESP TUNNEL SA
	   (gateway set by APIs to current care-of address)

I am assuming you still have this entry in the SPD for the Mike's case.
You need to have it for you to establish an IPsec SA for HOTI message.
This means when the packet gets decrypted and decapsulated, the above SPD
IN will match and the policy checks will happen. For all other MH traffic,
you need another set of SPD/SA entry. What am i missing here ?

> >>Note also that the authorization checks can only be performed when
> >>some message actually comes to the Mobile IPv6 module. This is the
> >>case for MH packets terminated to the home agent, for 
> instance. But it
> >>is not the case for traffic tunneled through the home agent.
> >>
> > 
> > The last point is a bit confusing. This should not require 
> any changes
> > to the IPsec implemenation itself. It happens as a result of the SPD
> > configuration. Is that correct ?
> 
> Yes, if we do things in the SPD then its fine. But if we do not,
> then something else has to do it. For MH reception such checks
> can be easily added. For tunnel decapsulation it is harder.
> 
> This may not matter, however, since spoofing HOTIs does not
> help the attacker much.
> 
I guess this will become clearer once the above is cleared up.
> >>        home agent MIP ID TABLE:
> >>          - user_1 has home_address_1
> >>
> > 
> > Is the same check done during Phase II exchange also ? I 
> saw this mentioned in
> > the draft. If so, it implies that a change is required in 
> IKE. Or the check is
> > done only much later when MH packets are received by MIPv6 module.
> 
> In the current solution, this check is done in Phase II only. This may
> or may not require changes to your IKE implementation; RFC 
> 2409 is pretty
> vague on the authorization step. A good implementation should let you
> do this already, but your mileage varies.
> 
Correct, the mileage varies. I just noticed that this is mentioned in
the "Implementation consideration" section. That should be good enough
i guess.
 
> In Mike's solution you'd basically leave the IPsec/IKE free 
> to do whatever
> it wants, and then check the authz step in MH processing. So 
> instead of
> a Phase II check you'd have a check in MH processing.
> 

> Jari
-mohan

---

From: Jari Arkko <[email-masked]>
Date: Sat, 04 Jan 2003 12:08:30 +0200

> you need another set of SPD/SA entry. What am i missing here ?

In the ha-mn draft -01, these entries were specific to MN and HA. In the
above they are specific just to the home prefix. This allows one MN
to spoof another MN's home address and HOTI message. But again, this
may not matter at least for HOTIs. I haven't thought about payload
traffic in detail, there it may matter more.

Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sat, 4 Jan 2003 11:19:43 -0800

> traffic in detail, there it may matter more.
Ok, i did not read that closely :-) But there is still one SA per MN's home
address.
We just save on the SPD's here as mentioned in your other mail. If you read
section 4.4.3 of RFC2401 :

   For each of the selectors defined in Section 4.4.2, the SA entry in
   the SAD MUST contain the value or values which were negotiated at the
   time the SA was created.  For the sender, these values are used to
   decide whether a given SA is appropriate for use with an outbound
   packet.  This is part of checking to see if there is an existing SA
   that can be used.  For the receiver, these values are used to check
   that the selector values in an inbound packet match those for the SA
   (and thus indirectly those for the matching policy).  For the
   receiver, this is part of verifying that the SA was appropriate for
   this packet.

So, if the SA was created for a specific home address, then wouldn't these
checks
happen ? I know of implementations that implicitly looks up the SA
matching the source address also if the SA was negotiated for a single
address.

-mohan