Subject: [seamoby] Re: [seamoby-paging] ICMP destination dormant

From: James Kempf <[email-masked]>
Date: Fri, 20 Jul 2001 15:25:47 -0700 (PDT)

Pars,

Please don't use the seamoby-paging list. It is now defunct.

Regarding your suggestion, for multicast, I can't see any reason
for returning anything. Reliable multicast protocols have
floundered on this issue.

Regarding unicast, it might perhaps be useful to return some
indication that the mobile node is dormant if the packet
was rejected due to a filter. 

		jak

>Delivered-To: [email-masked]
>Date: Fri, 20 Jul 2001 19:06:33 +0200
>From: Pars MUTAF <[email-masked]>
>CC: [email-masked]
>Subject: [seamoby-paging] ICMP destination dormant
>
>
>Hello all,
>
>The IP PAging Requirement "4.3. Control of Broadcast/
>Multicast/Anycast" requires a filtering mechanism for not
>awakening dormant mode hosts unnecessarily  (completely agreed
>with that).
>
>So, in those cases where a packet should not active a page,
>Should the paging agent return an ICMP destination uncreachable
>message? Or, the packet should be silently discarded?
>
>I had a look at the rfc on ICMPv6. Possible ICMP destination
>uncreachable codes are:
>
>0- no route to destination
>1- communication with destination administratively prohibited
>    (e.g., by a firewall)
>
>I think if we use one of those codes, the client may have a wrong
>idea about the situation. This may block his/her further attempts
>to reach the destination.
>
>So, a new code "destination dormant" or something like that
>would not be useful?
>
>Comments? Thank you...
>
>Regards,
>pars
>
>
>
>
>

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Fri, 20 Jul 2001 19:06:54 -0400

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 20, 2001 6:25 PM
Subject: [seamoby] Re: [seamoby-paging] ICMP destination dormant

> floundered on this issue.

Actually, RFC 1122, page 39, states that error messages for IP broadcast and
IP multicast are disallowed to prevent "broadcast storms".

But since in IP paging, Multicast is used to deliver a "unicast" message,
the actual AR to which the MN is attached is not covered by the RFC 1122
restriction after it looks at the unicast message and realizes that the MN
is indeed attached.

Therefore, all of the ARs that the MN is NOT attached cannot send an error
message as this would certainly create a "broadcast storm" condition.

But, the AR that the MN IS attached is not creating a "broadcast storm"
condition, by responding with an error message, because it is the _only_ AR
that can respond.

In this instance, the reception of an error does not voilate intent of RFC
1122.

Further, RFC 2463, page 7, states that error code 3 (address unreachable)
should be used for stituations where the router entry is valid (MN is
attached), but for some other reason the packet cannot be forwarded.

RFC 2463:

"If the reason for the failure to deliver is lack of a matching entry
   in the forwarding node's routing table, the Code field is set to 0
   (NOTE: this error can occur only in nodes that do not hold a "default
   route" in their routing tables).

   If the reason for the failure to deliver is administrative
   prohibition, e.g., a "firewall filter", the Code field is set to 1.

   If there is any other reason for the failure to deliver, e.g.,
   inability to resolve the IPv6 destination address into a
   corresponding link address, or a link-specific problem of some sort,
   then the Code field is set to 3."

Therefore, the same error code ( error code = 3 ) can be returned for both
multicast and unicast.

- Kulwinder.

> >unc

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 20 Jul 2001 20:27:05 -0400

At Fri, 20 Jul 2001 19:06:54 -0400,
> restriction after it looks at the unicast message and realizes that the MN

First, I don't think there is a requirement for using multicast to
deliver a unicast message.

> condition, by responding with an error message, because it is the _only_ AR

If there are multiple dormant hosts joins the same multicast, a sender
will still result in receiving multiple ICMP errors for each multicast
packet.  This is not desirable.

Yoshihiro Ohba

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Fri, 20 Jul 2001 22:42:57 -0400

----- Original Message -----
From: "Yoshihiro Ohba" <[email-masked]>
To: "Kulwinder Atwal" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, July 20, 2001 8:27 PM
Subject: Re: [seamoby] Re: [seamoby-paging] ICMP destination dormant

> packet.  This is not desirable.

Not for every dormant host that joins the same multicast,  _only_ for the
small subset
that do not wish to be awakened.

It is not a "broadcast storm" if the message is sent at the time the Host
becomes dormant, instead of when a multicast packet is recieved.  Different
Hosts will become dormant asynchronously with respect to each other.

- Kulwinder.

---

From: Pars MUTAF <[email-masked]>
Date: Mon, 23 Jul 2001 17:05:42 +0200

James, Kulwinder, Yoshihiro, all;

Thanks for your precious comments.

However, the replies were too multicast-centered. Have I
missed something? This is already a requirement?

Secondly, I don't understand why broadcast storms is an issue.
I suggest that an "agent" filters the correspondent node's
packet and returns an appropriate ICMP message. In this case
the packet is filtered before the page is initiated. As a result,
the ARs comprised in the paging area do not receive any page
packet.

For example, in HMIPv6HP such filtering can be done by the
PMAP. On the other hand, in LH-DMHA, this is the
"Paging Server".

Now, I formulate my question differently. Please take the
following scenario:

I'm pinging (ICMP echo) a dormant peer (in fact I don't know
whether it is dormant or not). A PMAP, Paging Server, or
whatever you call it, receives this packet. I'll call it a
"paging agent" in this e-mail.

At this point the paging agent should make a decision:
Should I page the dormant node for a ping packet? I think the
answer is CERTAINLY NOT. Paging a dormant node is costly
in terms of network bandwidth and battery power (i.e., wakes up
a mobile node). Ping is a diagnostic tool thus it should not call
for battery consumption on the destination node.

So the paging agent doesn't page the destination dormant node
for my ping packets (i.e., filters them). At that point the paging
agent has the following alternatives:

A. Silently discard the packet.
B. Return an ICMP destination unreachable message.

Clearly, A is not acceptable. In this case my diagnostic tool ping
will not work. So, B: the paging agent should return an ICMP dest.
unreachable message. The following codes are available:

CODE 0- no route to destination: this would be PREMATURE,
i.e., we can't know that before paging the dormant node. There
are possibly other routers between the paging agent and the AR to
which the dormant host is attached.

CODE 1- communication with destination administratively
prohibited: this would be FALSE, because communication is not
prohibited. Other packets can pass. In fact, security is out of scope.
Ping is not an attack tool.

CODE 2- not assigned.

CODE 3- address unreachable: this again would be PREMATURE.
Such a message is returned when there is a route to the destination
link but the host attached to that link cannot be reached. For
example, its L2 address cannot be resolved etc... Again, we can't
know that before paging the dormant node.

CODE 4- port unreachable: Has nothing to do here.

Note that all codes described above are typically
used to report a network failure.

However, in our case we don't know about such a
failure. The destination host is in dormant mode (which
is quite normal) and we don't want to disturb it. I don't see
any network failure (hard or soft) here.

So, the paging agent should return an ICMP destination
dormant code? In this case I (the pinger) would have
a correct diagnosis and the dormant host (the pingee)
would not consume battery for nothing.

I hope that I've made myself clear.

Comments? Thank you...

pars

------------------------------------------
PS: I used the "ping" example for simplicity. This can be
generalized.

---

From: Erik Anderlind <[email-masked]>
Date: Mon, 23 Jul 2001 14:00:08 -0400

Hi Pars,
I think that in your scenario the paging server should not report an
error.
The route is routable to the paging server and since the paging sever 
locally makes the decision that it does not want to wake up the 
mobile, the paging server is currently the final destination of this
route.
(It acts as an agent on behalf of the mobile.)

From a corresponednt node' perspective, the path to the mobile is
routeable. When the 
dormant mobile needs to be wakened it can be determined if the 
mobile is still reachable on the segment mobile-to-paging_server.

I am not even sure a moible user would even want the correspondent node
to know
it is possibly using IP paging. (Privacy issues)
...Erik

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 23 Jul 2001 14:53:35 -0700

> "paging agent" in this e-mail.

I'd like to know how the IP packet destined for a dormant peer was
received by the PMAP, which initiates your paging example.

PatC

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Mon, 23 Jul 2001 20:12:28 -0400

----- Original Message -----
From: "Pars MUTAF" <[email-masked]>
To: "Yoshihiro Ohba" <[email-masked]>
Cc: "Kulwinder Atwal" <[email-masked]>; "James Kempf"
<[email-masked]>; <[email-masked]>
Sent: Monday, July 23, 2001 11:05 AM
Subject: Re: [seamoby] ICMP destination dormant

> which the dormant host is attached.

It is not necessary to page the dormant node, this communication (or
communication error) is only between ARs.  It can be known if it is known
that the node was unreachable for the last page and had been 'unregistered'
for this paging area.  (That is until it re-associates with an AR).

This could happen if its battery died.

> know that before paging the dormant node.

1. Again, this communication is between ARs only.  There is no need to wake
the dormant node.  The AR to which the node is atached can respond with this
error code.

2. Also, the AR to which the node is attached can notify the Paging Agent
that a particular node is now dormant.

> used to report a network failure.

Even if they are typically used in a slightly different manner, what is
important is whether they will cause a behaviour that is appropriate for IP
paging.

If equating Dormant Mode to Address Unreachable causes the network to behave
in a manner that we like, then it is just a matter of changing some ICMP
terminology to match our thinking.

- Kulwinder.

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 24 Jul 2001 14:42:26 +0200

Hi Erik,

Thanks for your comments. So, you agree that the dormant
node should not be paged for an ICMP echo request?

You suggest that the paging agent silently discards the ping
packets? But, in this case we can't differentiate an operational mode
(where the dest. is simply dormant) from congestion or another
network problem. Am I wrong?

As for the privacy concerns, you are right this can be important.
But, in cellular systems mobiles are in dormant mode during ~90%
of time for saving battery. This quite normal. So I don't see any
private information here.

Another issue is security. You could say that an attacker can profit
from that information (ICMP host dormant message) to launch
attacks (as described in the paging-requirements draft). But my
answer would be the same as above: the proportion of dormant nodes
is very high. If I was an attacker I'd simply prefer to sent 100000s of
packets to a destination network without checking whether the
destinations are dormant or not.

regards,
pars

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 24 Jul 2001 14:46:15 +0200

Hello,

I'm not the author of HMIPv6HP draft but I would
say just like in HMIPv6. I'm sorry if a made a mistake.

regards,
pars

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 24 Jul 2001 15:27:37 +0200

Hello Kulwinder;

> for this paging area.  (That is until it re-associates with an AR).

I'm not sure if we can make such assumptions about the network's
state.

> the dormant node.  The AR to which the node is atached can respond with this

But, if the packet is filtered by the paging agent we can avoid an unnecessary
page, hence consumption of precious bandwidth.

> that a particular node is now dormant.

The paging agent already knows that. I'm missing something?

> terminology to match our thinking.

But, in my opinion there is big difference between a failure (covered by
current ICMP messages) and an operational mode (but dormant).

regards,
pars

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 24 Jul 2001 06:41:03 -0700

> say just like in HMIPv6. I'm sorry if a made a mistake.

Ah, well perhaps I need to read that draft, but I am uncomfortable
with imposing that all packets in the network traverse through a *specific*
router in the network. Networks are built to be resilient, and enforcing
a single point of failure seems like a bad idea to me.

What's that?!? Incoming flames....

PatC

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Tue, 24 Jul 2001 10:06:30 -0400

----- Original Message -----
From: "Pars MUTAF" <[email-masked]>
To: "Kulwinder Atwal" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 24, 2001 9:27 AM
Subject: Re: [seamoby] ICMP destination dormant

> The paging agent already knows that. I'm missing something?

I think it is that requirement 4.3 does not state which entity will preform
the filtering.  Whetther it will be just the Paging Agent, or a combination
of the Paging Agent and the AR to which the node is attached.

> current ICMP messages) and an operational mode (but dormant).

How does the behaviour at the other end of the network differ (at the
sender)?

What would the sender do differently, if it were to recieve a different
code?

- Kulwinder.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Jul 2001 11:33:27 -0400

> What would the sender do differently, if it were to recieve a different

That would be useful in terms of diagnostics especially for remote
management of devices that are connected to network and capable of
being dormant.  If an ICMP error with "dormant unreachable" is
received then both the network and dormant device are working
correctly and no special action would be taken.  If other ICMP error
such as "no route to destination" is received, an action to recover
connectivity would be taken.

I'm still doing security analysis for Pars' proposal (so far 
it seems ok).

Yoshihiro Ohba

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 24 Jul 2001 17:03:40 +0200

Hello Kulwinder;

> What would the sender do differently, if it were to recieve a different

I think this question doesn't make sense. Let me explain. Your
reasoning could apply to currently available ICMP message codes
as well.

So, we could ask,  why we have different messages for "host
unreachable" and "no route to host", etc. ?

This would be senseless.

The motivation here is to have a correct idea about the network's mode of
operation...

Thanks,
pars

---

From: Pars MUTAF <[email-masked]>
Date: Tue, 24 Jul 2001 17:12:15 +0200

Hi,

Well, I'm not promoting HMIPv6  :-)  here.
I think the discussion is completely independent.
I mean the other IP paging proposal LH-DMHA
is also subject of the discussion... In fact this
is generic...

regards,
pars

---

From: "Kulwinder Atwal" <[email-masked]>
Date: Tue, 24 Jul 2001 18:43:21 -0400

----- Original Message -----
From: "Pars MUTAF" <[email-masked]>
To: "Kulwinder Atwal" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 24, 2001 11:03 AM
Subject: Re: [seamoby] ICMP destination dormant

> unreachable" and "no route to host", etc. ?

With "no route to host" the network can try an alternate route.

But, with "Address Unreachable" as far as I can tell, it has two choices:

1. Give up now.

2. Set Timer. Try again when Timer runs out.  Give up when some other Timer
runs out.
Here Multicast Listener Discovery, RFC 2710, might be useful for ARs to know
how long other ARs will wait for node to come out of dormant mode.

If you add a new code, can you describe a choice 3, and how it differs from
the functionality provided by Multicast Listener Discovery?

Thanks, Kulwinder.

---

From: Pars MUTAF <[email-masked]>
Date: Thu, 26 Jul 2001 11:29:37 +0200

Hi Kulwinder,

Sorry for the late reply. I think the answer of Yoshihiro
(to your question below) was superior to mine. Thanks
for helping clarify that.

We will post a more detailed description of DMHA filters,
along with a detailed discussion on ICMP host dormant
message. This way we can refer to a well organized text
and see whether this is important or not.

I hope to have more comments then.

Thank you,

regards,
pars