Subject: RE: [mobile-ip] comments on MIPv6 draft-17

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 3 Jun 2002 18:12:55 +0200

=> Sure, but this falls into the 'CN-HA path
vulnerability' domain. 

  > 
  > Yes. So, if I'm on your home LAN or on the CN-hA
  > path for a small amount of time and there is no
  > limit on the BCE lifetimes, I'll install a BCE
  > that redirects your traffic to, say, my server
  > at some other location.
  > 

=> Sure, what you're saying though is that on top
of being on the CN-HA path, the attacker will also 
have an associate somewhere else that will get
the COT message (and send COTI perhaps) then receive
the HOT message contents and sends the BU. 
It's certainly possible if you're on the 
CN-HA path. A bit of a long shot but possible.

So it seems like 2 things should be done:

1. Agree on the seriousness of these attacks

2. Decide whether 5 min is an appropriate value. 
   Personally I see little difference between 5
   and 10 min (in terms of the seriousness of the
   attack) but better performance gains. 
   There is more danger, I think, in allowing more
   BUs during the 5 min.

  > > => I'm not sure I understand what you mean. 
  > > My concern was that there will be overlapping
  > > lifetimes for the nonces and the CN's keys
  > > for the different BCEs. So it wasn't a question
  > > of lack of memory, but rather the frequency
  > > of generating new keys and remembering which
  > > keys are valid for which BCE. But after  I 
  > > thought about it some more, I realised that 
  > > it's probably not a big issue. 
  > 
  > 
  > If you have a suggestion on how this could be made
  > clearer for implementers, it would be very useful.

=> OK, I'll try to send some text. Cycles are a problem
   this week.

  > > => Yes it is for the benefit of the MN. It
  > > makes the protocol more secure. Especially
  > > against attackers on the MN's link. 
  > > But I don't understand the relation between
  > > 'good for the MN only and not other nodes'
  > > and the 'SHOULD'. I might just need some 
  > > coffee :) but it sounds like you're saying
  > > that being good for the MN alone does not 
  > > justify a MUST.
  > 
  > 
  > Something that prevents bad things from happening
  > to other nodes would be a sufficient condition for
  > a MUST. There might of course be other reasons to
  > make something a MUST, such as a security advantage
  > for the node in question. I suppose it's a judgement
  > call in this case. The earlier debate showed that
  > people had different opinions about this particular
  > situation.

=> I think I missed that debate :(, anyway FWIW, I think
   all RR messages must be encrypted by the HA. 

  > > => Well, I suppose create if it doesn't already
  > > have it. I guess, except for the IP address
  > > of the MN, everything else can be copied, right?
  > 
  > 
  > I'm a bit uneasy on spending too much effort on us
  > creating lots of IPsec SAs in some dynamic fashion.
  > Could be easier to just require that these SAs exist,
  > and have been manually configured.

=> It is more flexible to have dynamic creation, for 
   renumbering/multihoming ...etc. The HA has to 
   create SAs/policies dynamically anyway for the CoA.

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 03 Jun 2002 13:49:05 -0700

Samita Chakrabarti wrote:

> Agree. Without having ESP tunnel mode for both
> HOT/HOTI, the HOA is prone to hijacking. I am
> not able to understand the logic behind having
> optional ESP tunnel mode for HOT message.
> This leaves a security hole in the protocol. If a MN can send
> HOTI message in ESP tunnel mode, then it should
> be able to process incoming HOT message in
> ESP tunnel mode.
> 
> Besides, making it optional means more complicated
> implemenation on MN (and HA) and more lines of unnecessary code.
> 
> I am not able to see any merrit of having ESP tunnel
> mode optional in HOT path. Making ESP tunnel bidirectional
> for both HOTI/HOT seems simple, secure and reasonable
> from the protocol perspective.

lets assume there is a link layer encryption between the MN
and the access router/access point. having an ESP header in
this situation is an overhead. the assumption here is that 
the MN's public link is the most vulnerable.

the spec currently says MUST implement. this takes care of
interop issues. but the MN/HA can chose not to use it when 
the MN visits certain environments.

for easier implementation, I did suggest a flag in the home
registration BU. the MN, through this flag could turn on/off
the ESP tunnel whenever it wants. but others in the list felt
that it is best done through the IPsec SPD (which was fine
with me).

Vijay

ps: I hope we dont start opening issues that are already 
closed. what we are discussing here is issue #14. please see 
the discussion on issue #14.