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

From: Brian Haley USG <[email-masked]>
Date: Wed, 13 Feb 2002 11:29:08 -0500

> 2.4. ALLOW HAOS ONLY WITH EXISTING BINDINGS

I guess I could live with this, performance will suffer of course,
but...

> A HAO with no matching BCE entry generates an ICMP error
> message. The message is sent to the source of the packet,
> i.e. the CoA. This guarantees that there will be no additional
> reflection problems because of this.

Don't a lot of firewalls today drop ICMP packets?  How is the MN
supposed to know the CN even got the packet if it's behind one,
it might just keep retrying, until it eventually stops trying to
communicate (figures the CN is dead), or falls-back to reverse-tunneling
through its HA.

-Brian

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 13 Feb 2002 18:38:52 +0200

> communicate (figures the CN is dead), or falls-back to reverse-tunneling

Good point, we didn't think of this! Do you have an understanding
how widespread that practise is?

Also, do we have other functionality where connectivity depends on
ability to get through ICMP packets? For instance, with v4, fragmentation was
handled by routers but in v6 we have e2e fragmentation and
ICMP Packet Too Big. This would appear to have a similar problem,
i.e. you wouldn't get anywhere that has a 1280 byte MTU if your local
link was 1500 bytes. Anything else similar, and do we have experience
on how well or bad this works in practise?

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?

Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 23:32:53 +0100

In your previous mail you wrote:

=> far too much! (BTW my dictionary says practice (noun), practise (verb))

   Also, do we have other functionality where connectivity depends on
   ability to get through ICMP packets?

=> mobile to mobile communication with simultaneous movement
(BUs never reach peers until a fallback path though a HA is used).

   For instance, with v4, fragmentation was
   handled by routers but in v6 we have e2e fragmentation and
   ICMP Packet Too Big. This would appear to have a similar problem,
   i.e. you wouldn't get anywhere that has a 1280 byte MTU if your local
   link was 1500 bytes.

=> path MTU discovery is a very well known victim of ICMP filtering
madness. Just ask any IPsec VPN implementer/user.

   Anything else similar, and do we have experience
   on how well or bad this works in practise?
   
=> very bad in practice (what does happen to ICMPs with NATs?).
Supposed to be better for IPv6...

   As an alternative we could also specify a MIPv6 specific message
   to say the same thing as the ICMP ;-)

=> a binding nack?

   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?
   
=> this is a job for binding (negative) acknowledges, we have just
to define some new status (perhaps not so new, the status list
has a long history with 16 steps :-).

Regards

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 17:24:58 +0100 (CET)

> > communicate (figures the CN is dead), or falls-back to reverse-tunneling

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.
Of course, if the CN crashes and reboots it will loose the BCE,
and in that error the ICMP error would be sent.

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?

> 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?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 18:38:15 +0100 (CET)

> (BUs never reach peers until a fallback path though a HA is used).

This can actually be avoided as is examplified by BU3WAY - the BU/RR
related packets by-pass any binding cache entry on the sending node.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Feb 2002 16:06:01 -0800 (PST)

> communicate (figures the CN is dead), or falls-back to reverse-tunneling

Brian --

In my draft draft-thomas-mobileip-bu-sec-00 which
describes a RR only solution, I stayed away from
ICMP mainly so that it was a self contained
protocol which was either permitted across
firewalls or denied. What you point out is yet
another reason why bifurcation of route
optimiztion into two protocols is probably not a
good idea.

	 Mike

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 16:31:09 +0100

=> I agree my comment only applies for route optimized BUs, but
BUs are critical so we'd like to put them on the fastest path.
In fact, this is only an other argument in the mobile-to-mobile
special case (for security, I don't argue for special BUs).

Regards