Subject: Re: [MOBILE-IP] Deregistration question...

From: Jonathan Khoo <[email-masked]>
Date: Fri, 16 Jun 2000 08:54:32 SGT

Hi Steven,

Thanks for your clarification. I think another way would be as what you have
suggested earlier, that is to have a buffer to collect the packets at the FA
when the MN moves away. In this case, there is absolutely no need for the MN
to gratutious ARP first before the deregistration as the packets can be
delivered after successful deregistration. Of course, this would then have
an effect on delay sensitive data. Then again, anyone has any idea what's
the timeframe of the deregistration process? 1 sec (max)? Probably it's not
that important after all.... :P

Cheers,
Jonathan

>From: Steven Glass - Solaris Software <[email-masked]>
>Reply-To: Steven Glass - Solaris Software <[email-masked]>
>To: Jonathan Khoo <[email-masked]>
>CC: [email-masked]
>Subject: Re: [MOBILE-IP] Deregistration question...
>Date: Thu, 15 Jun 2000 14:35:27 -0400 (EDT)
>
> > Hi there,
> >
> > Thanks for the reply. Is there anyway to prevent traffic from going to a
> > bogus MN after it has sent it's gratutious ARP and deregistration fails?
>
> > Jonathan
>
>     According to the way 2002-bis is written, no.  The HA would have to
>reclaim the address after the unsucessful dereg, which isn't allowed.  This
>is
>done to make things no worse than they would be without mobile ip.  Any
>other
>node can gratuitous arp for the mobile's IP address, thereby stealing the
>traffic.  If *whomever* fails the dereg (bad nonce, whatever) it's better
>for
>the HA to not take the MN's IP address back, thereby potentially stealing
>the
>traffic from a legitimate mobile node (no different than a node stealing
>the
>address, but which wouldn't be likely to attempt to deregister), rather
>than
>taking the address back and stealing the traffic.  If the HA gets another
>registration request from the mobile node, though, it should absolutely
>take
>the address (gratuitous ARP).
>
>     Perhaps a better strategy may be if the MN fails authentication the HA
>should gratuitous arp the address back, but any other error the HA
>shouldn't.
>Anyone have a good reason why this isn't done?
>
>                               Cheers,
>                                   Steve
>
>
> > >     This is also probably where the disclaimer normally goes that
> >this
> > >use of ARP doesn't make the network less secure or chaotic than >in the
> > >non-mobile case; anyone can gratuitous arp an address if they >so
>choose.
> > >
> > >                               Cheers,
> > >                                   Steve
> >
> > ________________________________________________________________________
> > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> >
>
>

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

---

From: Marc Hasson <[email-masked]>
Date: Tue, 20 Jun 2000 11:37:35 -0700

Steve,

 > > An ARP packet sent via IP-in-IP tunnel is going to be rejected for an
 > > invalid IP header checksum (most likely).
 >
 >     Hmmm...  I didn't think about the checksum issues, then again if there was
 > an ARP-in-IP type, it would probably specify checksum the arp (as generic
 > payload).

Actually an IP-in-IP decapsulator would probably throw out an unflagged
ARP packet due to it not having the IP version or header length fields
correct before it even got to doing IP header checksumming.

Anyway, I think we now have the point that an ARP packet can't be
simply tunneled without *some* way of distinguishing ARP packets from
IP packets.  An ARP-in-IP type would do it, along with a description as
to whether the ARP packet's link-layer headers/checksum were included
as well so that the decapsulator understands the packet format.

 >
 >
 > > I like best the idea of a registration revocation and not getting into
 > > this business of sending ARPs back and forth through these *IP* tunnels
 > > to "defend" or be notified of an addressing conflict.  Such revocation
 > > messages could be authenticated in the mobile IP protocol and I think
 > > there are multiple termination reasons besides this address conflict
 > > that would be useful for a HA to convey to its MNs.  Since the
 > > revocation mechanism is probably useful for multiple things anyway it
 > > might be nice to avoid having an additional "tunnel ARP within IP"
 > > mechanism to serve this purpose, even if its fairly simple.
 >
 >     I like it, too!  I'm not sure an ARP-in-IP mechanism is a case of "build
 > it and they'll come", but it was an interesting thought.
 >
 >                               Cheers,
 >                                   Steve

Agreed.  I think I can exit this discussion for now, pending either a
strong view on the list that ARP-in-IP is required or further
developments in the registration revocation proposal.

Thanks for your time.

   -- Marc --