WiMAX Forum / 3GPP2 Proxy Mobile IPv4
draft-leung-mip4-proxy-mode-10

Three of the comments below are blocking (process issues and the EAP
keying framework issue) in the sense that I would like to see them
resolved before the IESG approves this spec according to RFC 3932
criteria. Given the small importance of those three issues, I am
assuming that the authors are willing to do this. 

There is a fair number of other comments, which are not blocking
but could affect interoperability, correctness of behaviour, or
clarity of the specification. I am hoping that the authors are
willing to revise the specification one more time in order to
address these.

Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, get MIP4 WG to publish the GRE
keying spec, or reword the text to make clear that GRE keying is not 
a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 4.3 explanation of IPsec usage is sketchy. Please
provide a complete explanation of how IPsec is used, what
policies will match on, etc. See draft-bellovin-useipsec.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

Section 10 mentions that the relevant keys will be "derived by the
EAP keying framework". This seems incorrect in a number of ways.
First, EAP keying framework (RFC 5247) is not a mechanism that
can be applied, it is an explanation of the properties and
requirements for the security of EAP keys. Perhaps saying
something along the lines of "... derived from EAP authentication
as specified in [WIMAX-DOC]" would be better. This resolves
the issue for this document, but really hope that the Wimax
specification employs MSK or draft-ietf-hokey-emsk and does not
use EMSK directly.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

There is no discussion of the implications of using Mobile IPv4
as defined and Proxy Mobile IPv4 for the same nodes. Perhaps this
should be raised as an issue, declared something not supported,
or properly explained. It seems clear that per-MN security would
be hard to support in any proper way, for instance. Wouldn't that
require sharing the MN - HA secret with FAs as well?

I understand the behaviour of this spec over Ethernet-like interfaces.
IP stacks attempt to verify that their IP address is still valid.
However, if you run this over PPP, bringing down the previous PPP
connection and creating a new one would appear to cause the host
to lose the IP address (and consequently, all ongoing sessions).
There is no "confirm my address is valid" operation in PPP.

The document does not at all discuss the role of the various
identifiers (interface ID, device ID, subscriber ID, authentication
NAI) and the access technology type. Note that RFC 5213 includes
similar identifiers, but spends an extremely big part of the
document in explaining what kind of logic rules are used to
decide the behaviour of the PMIP nodes when faced with different
situations. Is this not needed in PMIPv4 at all? Or is the
document underspecified? Please clarify/extend the specification.
In particular, it is unclear what happens when hosts have
multiple interfaces. Note that RFC 5213 was built to be safe
in these situations, is PMIPv4 safe? The document is silent
on this and I cannot tell, but I suspect that the same
issues apply.

Section 3 claims IPv6 will work with PMIPv4 merely by the
use of PMIPv4 and DSMIPv4 together. I find this hard to
believe. To cite two examples where additional behavior
might be needed: similar to RFC 5213, wouldn't MTU changes
in the tunnel have to result in sending RAs with changed
MTU options? And what about carrying the link-local address
of the router? Or maybe that does not apply given that
PMIPv4 supports only L2 LMAs? In any case, the document
is too silent on this.

Process issues:

For full disclosure, I think it would be useful to mention
somewhere that there exists an IETF standard proxy mobile,
RFC 5213.

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.

The last sentence of the first paragraph in Section 4.1.4 does not read well.