Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team recommendation

From: Brian Haley USG <[email-masked]>
Date: Thu, 14 Feb 2002 12:42:37 -0500

> > > Don't a lot of firewalls today drop ICMP packets?
> 
> Good point.
> But this ICMP error is to handle error cases. If a CN accept a BU with
> a 2 minute lifetime it should keep it around for that long.

It should, but it doesn't have to.

> Of course, if the CN crashes and reboots it will loose the BCE,
> and in that error the ICMP error would be sent.

Right, this was the case that came to mind - my CN either crashed or
decided to throw-out my binding to create another one.  I guess if
packets seem to be getting blackholed, the MN just starts reverse-tunneling
again, and when it finally gets a response from the CN through the HA-MN
tunnel, it knows it needs to send a BU again.

Let's document this issue exists with HAOs if the consensus stays
on this track of requiring BCEs.

> So if the ICMP error is only used to signal more or less catastrophic state
> loss and the maximum lifetime for a binding created using RR-security
> is a few minutes (in order to minimize the exposure to future bombing attacks)
> then it seems like we might be able to live with the risk of the firewall
> blocking the ICMP error?

Short-lived bindings would certainly lower the risk of this happening.

> > As an alternative we could also specify a MIPv6 specific message
> > to say the same thing as the ICMP ;-) which sounds a bit like the
> > arguments in the RH case. Except this time the fear is ICMP, not
> > RH. Could Binding Request be used for this purpose, with some flag?
> 
> Or, instead of overloading the request, specify a new binding nak/reject/error
> message for MIPv6?

In this case we weren't sending a BU in the packet, just a HAO, so
a BNak doesn't seem appropriate.  Even a BR doesn't seem right, since
it's just another form of the redirect attack.

-Brian