[Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with reference to draft-chen-mip6-gprs-02.txt)

["James Kempf" <[e-mail]>]

I believe this draft is in last call at the moment. It seems to have been a
"stealth" WG draft, since it was never listed on the WG Web page until
recently. I also personally cannot recall having seen a concensus call on
the mailing list to make it a WG draft, but perhaps that might be due to a
lapse of memory on my part or an over-eager spam filter on my laptop's. In
any case, the draft does deal with a problem that needs attention for
successful deployment. In fact, draft-chen-mip6-gprs-02.txt represents a
specific instantiation in GPRS of the general problem discussed in
draft-ietf-mip6-firewalls.

As a general comment, I believe draft-ietf-mip6-firewalls-00.txt is lacking
precision in its description of the problem. One need only look at
draft-chen-mip6-gprs-02.txt for an excellent example of how to more
precisely describe the interaction between firewalls and MIPv6 packets, the
firewall in that case being a GGSN. draft-chen goes through a few cases in
very specific detail. The description, to be sure, is very specific to GPRS
but draft-chen does a much better job of describing the problem than
draft-ietf-mip6-firewalls.

One way this draft could be made more readable is to organize it more like
draft-chen, including all the cases of placement of the MN, HA, and CN. The
current draft-ietf-mip6-firewalls has specific sections in 3.1, where the MN
is outside and stays outside, and 3.2 in which the MN is inside and stays
inside. Even for those cases the discussion is made somewhat vague by lack
of specific description of the addresses involved and what state is
established (or not) in the firewall when, something that draft-chen does
very well. However, in draft-ietf-mip6-firewalls the discussion of the more
complex case when an MN moves from outside a firewall to inside is somewhat
muddied and vague in Section 3.2.2. This case is especially in need of very
explict consideration of addresses and firewall state, and very clear
explanation of the problem.

Specific comments:

Section 3.2.2, starting about Paragraph 3: the description of why packets
forwarded between the HA and MN might get dropped is not very clear. The
problem seems to be that when a MN roams into an area of network topology
controlled by a stateful firewall, there is no state in the firewall
corresponding to (HA src addr, MN  CoA dest addr). But this is never
specifically articulated.

Section 3.2.2, Paragraph 8: This point is true for any case where a session
is initiated from outside the firewall, for example, an incoming VoIP call
started by SIP. Why is MIPv6 any different?

Section 3.2.2, Paragraph 10: The discussion doesn't consider the distinction
between a TCP and UDP session. Earlier in the text, the description of the
state maintained in the firewall implies a distinction. But if a MIPv6 host
is receiving TCP packets tunneled from the HA, then the firewall state will
be for UDP (presuming it is set up at all). The firewall timers for UDP may
interact negatively with the MN's TCP timeouts, and there may be other
problems.

Section 3.2.3, Paragraph 5: This paragraph is not only true of RR packets
but also of BU packets if the MN chooses to use ESP encryption for them as
well. Consequently, it should be discussed in a separate section not
specifically devoted to RR.

Section 3.2.3, Paragraph 7: This paragraph is implying that the problem may
be due to the lack of ability to detect firewalls. IPsec can deal with NATs
because they can be detected. Why not simply come out and say this? Having
the ability to detect and negotiate with a firewall is something that the
IETF has (in my opinion) been needing for some time, and MIP only makes the
case stronger.

In summary, I believe this draft needs a lot of work before it is ready to
be sent to the IESG. I'd suggest the authors may want to talk to the authors
of draft-chen about merging the two.


                jak






_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6