Hi all, I would like to thank Thomas for asking me an explanation of my point of view (from the previous discussion Re: Proposal to change aspects of Neighbor Discovery)).
But, I wasn't really hoping an IPv6 WG action on this issue, in fact. Not because I think it is an L2 problem (Hesham doesn't agree). Because the problem is too difficult to solve before we actually see it. Thanks, pars Selon Pars Mutaf <[EMAIL PROTECTED]>: > Hello, > > On Wed, 2006-09-06 at 08:25 -0400, Thomas Narten wrote: > > Pars Mutaf <[EMAIL PROTECTED]> writes: > > > > > Thanks. But I still believe that a host should be able to test > > > if it is reachable in dormant mode (reachable, or reachable within > > > reasonable delay). This is good for dormant mode security. > > > > Why? This is a problem statement you are asserting. Rather than > > discuss possible solutions, I think it is important to first establish > > whether this is an actual problem people think we need to solve. > > > > OK. > > When the host is dormant, it is reachable through a different > set of links. Because, the dormant mode state must be checked > somewhere in the system, etc. There is also the paging channel. > (different, and time-slotted). Paging has a complex architecture. > It is more complicated than active mode support. An IP-layer > solution can check all of these and detect failure: From AR > to the host, everything between the two will be tested. > > IMHO, we should not assume that the cellular system is perfectly > managed. (Take the municipal networks, for example, think of > WiMax, it supports paging). > > In addition, there is a performance/security problem with > paging and dormant mode in general (for which the commercial > operator does not have a solution). The paging system is easily > congested. There are two potential reasons: > > 1/ Flash crowd: Many hosts are called simultaneously. The > incoming packets trigger link-layer paging. Paging messages, > hence the IP packets are queued in the system. This is a > well-known problem. There is no solution. If the paging > system is congested, you should wait. The call setup delay > may be very long. > > Nobody tells you that (at the link layer). > > 2/ Attack: Attacker (anywhere in the Internet) sends many > packets to different mobile hosts in the same area. Most of > the hosts are dormant. Consequently, the above scenario is > artificially created. The results can be more serious than > a flash crowd. > > You may want to take a look at: > ipmon.sprint.com/publications/uploads/wise06_paging.pdf > (Wireless Security Workshop, with Mobicom'06, Sept. 29, 2006) > > In both cases, 1/ and 2/, the problem is the same: > IP packets don't reach the hosts. They are delayed or lost. > The loss is *not* caused by increased BER (bit error rate). > The physical conditions may be perfect. The problem is that > the link is congested. IP packets are waiting or being lost > somewhere (between the AR and the hosts). > > The host can detect these problems at the IP layer and employ > an IP-layer solution: The IP-layer can be told to move to > another (parallel) subnet. This is the only solution. > > > > Personally, I'm skeptical. If a node is dormant, why does it want to > > expend resources (like waking up) if the link (at the IP layer) isn't > > working -- given that it is dormant? It's far from clear that a > > dormant node should monitor link status with the same aggressiveness > > it would if it was awake, especially if that has impact on battery > > life. > > I'm not sure if the host needs to be aggressive. The test > interval can be set longer (than active mode NUD). > > Or, the host can check its dormant mode reachability before > entering dormant mode. > > This has an additional energy cost, yes I agree. This is the > cost of reliability. NUD (standard) also a has a cost. But it > is necessary. > > pars > > > > > It may well be that it wants to maintain the liveness of the paging > > channel when it is in dormant mode, but my initial reaction would be > > that that would be an L2 issues exclusively, and not something that > > needs to be visible to IP. > > > > Thomas > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
