Subject: RE: [mobile-ip] Issue #23 and Issue #30

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 21 May 2002 17:42:11 +0200

> Using RFC 3041 temporary addresses for the CoA doesn't 
  > really hide the
  > location - you could still easily see which ISP the CoA is 
  > delegated to.
  > 
  > I could imagine MNs that want to use RFC 3041 home 
  > addresses for communication
  > they originate where the MN wants more anonymity, while the 
  > MN retains
  > a stable home address at which it can be contacted.

=> I fully agree. We should not assume that the SA between
the MN and the HA will be forever static. New security mechanisms
can come out and allow the MN to configure a Home address dynamically, 
for privacy reasons. At least for the connections it initiates. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 22 May 2002 13:55:08 +0200

Francis, 

I might be missing something, but I'm not 
sure that your steps below will work.

  >    > => which source address the MN should use to send the 
  > deregistration
  >    > message?
  >    
  >    the global unicast home address.
  > 
  > => this address is always protected by the HA: it is the 
  > worst choice.
  > 
  >    the deregistration BU is unicast to the HA. this works.
  > 
  > => with an old draft or with my proposal:
  >  - the MN has just been attached to the home link
  >  - it builds its link-local address and performs DAD for it
  >  - (perhaps in parallel) its sends a RtSol to get prefixes and
  >    a default router
  >  - it gets a RtAdv from any routers on the home link (by application
  >    of the Murphy's law, the first router to answer is never the HA).
  >  - it finds a home prefix in the RtAdv and discovers it is at home
  >  - it builds its addresses from the prefixes:
  >    * if it performs DAD, it fails for the home address
  >    * if it doesn't perform DAD (it was the case when I try 
  > 4 years ago),
  >      see after
  >  - it tries to send a BU to the HA
  >  - as the HA address is not in the neighbor cache it sends 
  > a NbSol with:
  >    * the home address as the source
  >    * the solicited-node multicast of the HA address as the 
  > destination
  >    * the HA address at the target
  >  - the HA receives the NbSol and does a stupid thing with it,
  >    in my case it sends a NbAdv to the previous care-of 
  > address of the MN
  >    with a RH.
  >  - the MN retries
  >  - the MN retries
  >  ...
  > 
  > Conclusion: it does not work. My fix was simple: I modify the code
  > to always send the BU from the link-local address. It always works
  > until someone has the bad idea to use S=0 or a previous equivalent.

=> If the HA does not defend the MN's link-local address
while it's away, how can you send a dereg if 
someone else took the MN's link-local address?

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 29 May 2002 13:15:13 +0200

Charlie, 

  > My model may be different than yours.
  > 
  > My assumptions:
  > 1) The mobile node owns its home address until the lifetime expires.
  > 2) The home agent proxies for the mobile's home address while
  >    it has a valid binding.
  > 3) The mobile node knows how long the home address is valid.
  > 4) The mobile node does not have to reconfigure its home address
  >    if it's valid (its lifetime has not expired).
  > 5) The home agent defends the mobile node's link-local address
  >    while the mobile node is away from home.
  > 
  > Under these circumstances, the mobile node does not have to do
  > DAD when it returns to the home network.  It just has to inform
  > the home agent that it has arrived back on its home network.
  > 
  > Before going into other cases, please let me know if this much
  > is agreeable to you.
  > 

=> I agree with these assumptions. I don't 
see big issues with this, provided that the 
HA removes 'proxying for the MN' upon reception
of the BU and before sending a BA. 

Hesham