Subject: Re: [mobile-ip] Re: MIPv6 Internet Draft

From: Erik Nordmark <[email-masked]>
Date: Sat, 23 Mar 2002 19:10:23 +0100 (CET)

> Also, I think it was Erik who wondered if we might actually have a field
> in the [HC]OT message to describe the expected (or committed?) lifetime of
> the cookie, helping the MN decide whether it should redo something later or
> not. This would bring some additional complexity though, and the MN has no
> assurance in any case that the cookies really can be used anyway so perhaps
> we should just have a recommendation and allow MNs to optimistically try
> these things within those recommended limits. Or what do you think?

The motivation for this was to give the MN hits to help it when retransmitting
in the face of packet loss (an issue I didn't get to in the meeting - it's in
the slides).

Basically if the MN doesn't receive a HoT or CoT it needs to retransmit
the HoTI and CoTI, respectively.
And if it doesn't receive a BA (when the BU had the A bit set) it needs
to retransmit the BU.
For these reasons the cookies used to form the authenticator in the BU
might be old. If they are too old the CN will reject it
with an error. But it would see very useful to give the MN a hint
for how long time it can retransmit using the old cookies.

I think a time around 20-30 seconds would be reasonable. THis would allow
several retransmissions with binary exponential backoff.
When this time has expired, or a BA with a "too old home nonce index" or
"too old care-of nonce index" error is received, the MN would need
to start over with the CoTI/HoTI.

An observation is that this also allows the MN to reuse the home cookie
during frequent movement for this time period, which would be a useful
optimization that Charlie and Jari M. suggested.

  Erik

---

From: Tom Hiller <[email-masked]>
Date: Sun, 24 Mar 2002 16:44:42 -0600

Hi,

The draft states: 

> 14.3. Security for the Binding Updates to the Correspondent Nodes

>    [..]  For this reason, this specification limits
>    the validity of RR authorized bindings to a maximum of five minutes
>    after the last RR check has been performed.

In cdma2000 spectrum is expensive and quite a lot of attention is given to
minimizing control/signaling overhead, not to mention compressing packet
headers. Having to send the RR check messages every five minutes is an issue.
Also, after mobile sends data it stays active some number of seconds (like
20-30) beyond the last bit sent.  The five minute requirement implies that
mobiles using the RR check would be active 5-10% of the time even when they have
nothing to send because they have to wake up every five minutes just to do the
RR check.  That's a problem.

If the CN is a voice gateway or conference bridge that is owned by the same
carrier that owns the HA, and the route between the HA and CN resides within the
carrier, the risk of an attacker being able to monitor the CN-HA route could be
zero for practical purposes.  Another case would be if the mobile runs TLS above
MIPv6. It doesn't seem that frequent RRs buy very much.

Is it really necessary to mandate a five minute lifetime for all applications?  

thanks,
Tom Hiller

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Mar 2002 07:40:14 -0800 (PST)

> RR check.  That's a problem.

   Let us not forget that route optimization is an
   _optimization_. A mobile node can be as
   selective as it likes about which streams it
   cares enough to straighten out triangular
   routing. For an RTP stream, this may be
   a completely reasonable tradeoff as the amount
   of RO signaling vs RTP streams @20ms
   packetization is miniscule. For other streams,
   it may not be worth it at all. Casual web
   browsing, IMO, probably wouldn't want to use
   RO at least until you hit some fairly large
   threshold of bandwidth or RTT.

   Also: you already need to be up to send and
   receive RTCP. Worse, the net is littered with
   stray packets that make the assumption of 
   complete dormancy -- especially while the unit
   is active -- a tough assumption to make. I know
   that isn't 

 > Is it really necessary to mandate a five minute lifetime for all applications?  

   The problem is that the MN has absolutely no
   way to know for certain. A better option may be
   to use strong authentication (ipsec) in that case. I
   haven't read the current draft, but inital RR
   covered by strong authentication could relax
   the refresh period requirement, IMO.

	       Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Mar 2002 09:16:39 -0800 (PST)

>    is active -- a tough assumption to make. I know

   ... a brain fart. What I meant to say is that this
   isn't going to be especially popular with the 
   connection oriented crowd, but reality is,
   well, reality; IP isn't connection oriented.

		  Mike

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Mon, 25 Mar 2002 19:08:21 +0100

Hi,

	There was one question posed on backward compatibility for the
NAT traversal during the Mobile IP sesssion in Minneapolis. I'd like
to explore the details of that, but I didn't catch the name of the
questioner. Would you be kind enough to send me a mail on or off list?

	Best regards,
		Henrik

---

From: Milind Kulkarni <[email-masked]>
Date: Wed, 27 Mar 2002 10:47:27 -0800

Hi Henrik,

It was me. I had a doubt in backward compatibility for the
draft. The scenario I am considering is similar to first
item in section 4.6.1. Consider HA doesn't support NAT draft and 
skips the UDP Tunnel Request Extension with U bit set. HA will 
accept the registration assuming authentication etc. is good. 
So there is ambiguity in following places which I think should
be addressed in the draft.

(1) Per Sec 3.1.1: Since HA accepted the RRQ, MN is expecting UDP 
    Reply extension, but the HA never sent one. MN's behavior should 
    be made clear in this case. HA will not send failed RRQ with 
    code 129.

(2) If MN is not behind a NAT, HA will set proper tunnel and Mobile 
    IP will work. Hence MN should work in this case also. 

(3) Sec. 3.2 - Description of F flag: Will this flag be set only
    when U bit was set and NAT was not detected? How about NAT was
    detected and U bit was set? This flag will not be set in this
    case? In other words, is this flag set in response to U bit 
    in RRQ, irrespective of NAT detection?

Thanks,
Milind