Re: Evaluation: draft-ietf-mobileip-ipv6 - Mobility Support in IPv6 to Proposed Standard

["Steven M. Bellovin" <smb@research.att.com>]

In message <200302282056.PAA13057@ietf.org>, IESG Secretary writes:
>
>Last Call to expire on: 2003-2-6
>
>	Please return the full line with your position.
>
>                    Yes    No-Objection  Discuss *  Abstain  
>
>Steve Bellovin      [   ]     [   ]       [ X ]      [   ] 

For a spec of this length, complexity, and security sensitivity, I'm 
remarkably happy with it.  I have some issues, but I suspect that most 
can be resolved pretty easily.  It was a delight to be able to delete 
some of my notes as I progressed through the document.  Furthermore,
given the length and complexity of the spec, I could easily be wrong 
about many of these points.  I'd be delighted if that were the case.

5.1	In my opinion, IKE support should be a SHOULD, not a MAY.  I
	have problems with the replay protection (see below).

5.2.5   The figure shows the Home Test Init message going from the
        mobile->home agent->correspondent.  The text says that
        it goes from the mobile->correspondent.  Which is it?

	There are a number of HMAC'd fields floating around.  Some, at
	least, seem to have a distinguishing type value, such as 0 in 
	the home keygen token.  The Binding Update takes a parameter
	with a BU in the last byte.  Is that intended to serve the same
	purpose?  I don't see a value for BU defined anywhere -- is that
	the '5' in Section 14?  If so, the 0 and 1 shouldn't overlap
	that type space, and there should be an explicit statement about
	the reserved values in Section 14, so that no future IANA
	assignments conflict with them.  I'd also like the authors to
	verify that all HMAC'd fields have such such type code that is
	never used elsewhere.

6.1.7	The text here (and in 6.1.8 and 6.1.9) should note that the
	authorization option is mandatory.  It says so later, but not
	that clearly.

6.2.6   Should Mobility Data include the home address?  The option
        doesn't seem to protect other data, including things like
        lifetime, sequence #, etc.

7.5     Those advertisement frequencies scare me -- they're quite high.
        Worse yet, the most likely place they're needed -- microcells --
        have limited bandwidth.

7.6     Which link is this link-local local to?  The home network?

9.5.1   If there's no IPsec-level replay protection, this sequence number
        just won't do the trick.  A wireless mobile node could very
        easily generate enough binding updates per day that an enemy
        could replay old ones that appeared to be in the window.

10.3.1  Has the IPsec wg verified that K=1 really works?  I'm not
        convinced of it, since some cookies are address-dependent.
        Beyond that, the SPD and the SADB will need to change as the
        source and destination IP addresses change.

10.4.5  In the absence of ESP -- and why would it be omitted? --
        how can the home agent reliably verify that the source address
        in the tunnel IP header is legitimate?  I'd say that reverse-
        tunneled packets MUST be discard unless ESP-protected.  (I'm
        astonished that it isn't even a SHOULD.)

11.3.5  Should some sort of timeout be associated with the fact that
        a certain destination address can't accept Mobility Headers?

11.7.2  Same comment about sequence number processing


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)