Subject: Re: [MEXT] [RFC3775 changes] New Issue on HA behaviour upon MN returning Home

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 16 Jul 2008 19:04:36 -0400

Vijay,

> 
> Well, if SeND is not being used, does it make sense for the home agent
> to allow the mobile node to claim its address, until the mobile node
> de-registers with a secure binding update? What if a misbehaving
mobile
> node on the home link tries to claim the legitimate mobile node's home
> address while the home agent is defending the address?

[RKo:>] The Home Agent is *not* trying to improve the default ND
security here. It is only proxying an address within the confines of
*existing* ND security. The level of MIP security is limited to setting
up a BCE, maintaining it (e.g., refresh), forwarding packets and
de-registration of BCE.

Beyond that, for the scenario you mention above, unsolicited NA from a
bogus node does not result in NCE in a state other than STALE, which
forces other nodes to probe (i.e., send NS) first before forwarding
packets. The MN can reclaim the address. Anyway, this behavior is not
specific to MIP. So, it is not a good argument here IMO.

> > The proposal to fix this issue is to let the MN use DAD/oDAD over
the
> > Home Link with its Home Address. A proxy would defend the address
> > without the O bit,
> 
> This would modify the existing behavior. For unsolicited neighbor
> advertisements, the Home Agent sets the 'O' bit. See section 10.4.1.
> 

[RKo:>] The Proxy (i.e., HA) sets the 'O' bit only when sending
unsolicited NA. 24/4861 allowed this (with a MAY); it is not clear why.
It could have been lot cleaner to have 'P'roxy bit instead. Response to
DAD probe is a solicited NA, and the Proxy must not set the 'O' bit.

-Rajeev

>  > and the MN would ignore it, and upon DAD completion,
> > NA(Override) its address. The HA would be allowed to set the
override
> > bit only within a binding flow, when it knows synchronously that it
> > represents the live MN.
> 
> I lost you. What does "within a binding flow" mean?
> 
> Vijay
> 
> > That would enable new HA to take over old HA
> > when the MN looses states away from home. That would also enable MN
to
> > make before break a tunnel with new HA.
> >
> > Still it would still be beneficial to clear the binding properly so
we
> > can still SHOULD or MUST it, but whether that flow works properly or
> > not, the MN would get its address back.
> >
> > What do you think?
> >
> > Pascal
> >
> >>> From: Vijay Devarapalli [mailto:[email-masked]]
> >>> Sent: Fri 7/11/2008 10:52 AM
> >>> To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave);
> >>> Koodli, Rajeev
> >>> Cc: [email-masked]; [email-masked]
> >>> Subject: RE: [MEXT] [mext] #11: De-registration when
> >>> returning home[VijayDevarapalli <[email-masked]>]
> >>>
> >>>
> >>>
> >>> Sri, Pascal, Rajeev,
> >>>
> >>> I suggest you guys open a separate issue on whether a mobile node
can
> >>> claim its address without first sending a de-registration BU when
it
> >>> returns to the home link.
> >>>
> 

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Jul 2008 08:52:37 +0200

>DAD probe is a solicited NA, and the Proxy must not set the 'O' bit.
I agree. Inferring is not as good as knowing. This definition belongs to
proxy ND but RFC4389 only discusses P bit in RAs... 

Pascal

>-----Original Message-----
>From: Koodli, Rajeev [mailto:[email-masked]]
>Sent: jeudi 17 juillet 2008 01:05
>To: Vijay Devarapalli; Pascal Thubert (pthubert)
>Cc: [email-masked]; [email-masked]; Sri Gundavelli (sgundave)
>Subject: RE: [RFC3775 changes] New Issue on HA behaviour upon MN
returning Home
>"This email message and any attachments are confidential information of
Starent Networks, Corp. The
>information transmitted may not be used to create or change any
contractual obligations of Starent
>Networks, Corp.  Any review, retransmission, dissemination or other use
of, or taking of any action
>in reliance upon this e-mail and its attachments by persons or entities
other than the intended
>recipient is prohibited. If you are not the intended recipient, please
notify the sender immediately
>-- by replying to this message or by sending an email to
[email-masked] -- and
>destroy all copies of this message and any attachments without reading
or disclosing their contents.
>Thank you."