Document: draft-ietf-mip4-vpn-problem-statement-02
Reviewer: Scott Brim
Date: March 17, 2004

REVIEWER: Scott Brim

This draft is on the right track but has open issues.

Problem statements tend to frame people's thinking, so they require a
little care even though they're "informational".  This draft doesn't say
anything particularly wrong, but imho it's not well organized, it's
ambiguous, and it leaves things out.  Ignoring editorial stuff and
issues already brought up by the IESG ...

* I have trouble with some of the phrasing.  For example,
  "Unfortunately, the current MIP standards fall short of this promise
  for an important customer segment, corporate users behind VPN
  gateways."  The users aren't behind the VPN gateway, the home network
  is.  Unexpected word choices like this are frequent, and can confuse
  readers from outside the WG.  I like even problem statements to be
  clear and unambiguous.  I would go through the whole thing and edit it
  for clarity.  I can give other examples if needed.

* It mentions MOBIKE as justification for not considering some other
  problems.  There are other implicit assumptions about problem areas
  that do not need to be covered.  The boundaries of the problem
  statement should be very clear.  It should explicitly call out other
  technologies it is assuming, and specifically what it expects from
  them.

* It goes through 5 different scenarios, discussing them in detail, and
  then revals that 2.2 and 2.4 are special cases of 2.1 ... and 2.3 and
  2.5 are not going to be addressed.  If that's true, then say so up
  front.  I suggest making 2.2-2.5 relatively brief subsections of 2.1.

* "Secondly, when the MN is communicating with the VPN-GW, an explicit
  bypass policy for MIP packets is required, so that the MN can hear FA
  advertisements and send and receive MIP registration packets.
  Although not a problem in principle, there may be practical problems
  when VPN and MIP clients from different vendors are used."

  There is no discussion of security issues here, even though it looks
  like a nice place for them.  It makes me want more on security
  overall.  

* "5.1 Preservation of existing infrastructure" -- this section should
  be eliminated.  The real criteria for the first bullet are already in
  other sections.  The second bullet should be moved.  As Ted Hardie
  noted, some of these requirements aren't really requirements, or have
  implications that go beyond simple requirements.

* "The solution MUST be able to leverage the existing MIPv4 and IPsec
  NAT traversal solutions [RFC3519][IPSEC-NAT][IKE-NAT]."

  This particular one precludes parts of the solution space, and is not
  a fundamental requirement.  Maybe my problem is just the use of the
  word "leverage" -- if so, see my first point above.
   
* "The solution MUST NOT introduce any new vulnerabilities to the MIPv4
  or IPsec as specified in related RFCs."

  First, new security vulnerabilities would likely be in the system as a
  whole, i.e. in interactions between components, not in a particular
  protocol -- that issue does not seem to be addressed.  Second -- and I
  haven't thought this through enough -- this absolute prohibition on
  new vulnerabilities in MIPv4 precludes a lot of possible solution
  approaches, which may be most appropriate in certain situations.

Nuf said ... Scott