Subject: RE: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt)

From: [email-masked]
Date: Mon, 25 Oct 2004 15:02:16 -0500

Hello James,

Thank you for your suggestions. Please find some comments below,

> 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.

For the description of the problem (e.g. mismatch between the firewall states and incoming packets), we tried to explicitely describe them. As an example, to quote section 3.1.1: "The state created by the stateful inspection packet filter protecting A is therefore initially based on the IP address of A(IP A) and the home address of the node B (IP HoA B)." then "The Care of Test Init message is sent using the new CoA of B as the source address. Such a packet does not match any entry in the firewall protecting A and as described in Section 2, the CoTi message will thus be dropped by the firewall."

If you want to make it clearer, would you have any suggestion?

For the other scenarios you pointed out, I agree with you. They are not in the scope of the document. We described some of the issues, and specifically focused on the basic ones. I will add an explicit statement in the document to explain that the scenarios you mentioned are not included.
 
> 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.

Thank you for your comment. I will try to make it clearer in the next version of the document.

> 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?

Sorry if that section is not clear. MIPv6 is not different. What we wanted to say is that while MIPv6 has been designed to allow reachability even when the MN roams (thanks to the HoA and HA), firewalls may present issues to this property. I will try to clarify our intent in this section.

> 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.

Can you please clarify what you mean?

> 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.

The problem with IPsec is described in section 3.2.1. We can add a reference.

> 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.

The ability to detect firewalls could help to solve the issue. We will mention it in the next version of the draft.

> 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.

We are aware of the draft-chen but draft-ietf-mip6-firewalls is more generic and applicable to firewalls in general. Xiabao's I-D is focused on GPRS aspects.

Thanking you again for your comments,

Franck

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Oct 2004 10:06:15 -0700

Franck,

Some responses.

For the description of the problem (e.g. mismatch between the firewall
states and incoming packets), we tried to explicitely describe them. As an
example, to quote section 3.1.1: "The state created by the stateful
inspection packet filter protecting A is therefore initially based on the IP
address of A(IP A) and the home address of the node B (IP HoA B)." then "The
Care of Test Init message is sent using the new CoA of B as the source
address. Such a packet does not match any entry in the firewall protecting A
and as described in Section 2, the CoTi message will thus be dropped by the
firewall."

jak>> Draft-chen takes each individual case and examines it in detail. For
example, Section 4.1.1.1:

           The IP datagrams sent from A to B use the (reverse) tunnel from
A's
           current CoA to its HA. IP datagrams exit the tunnel at A's home
agent
           and transmit to B using  A's home address as the source address.
Upon
           arriving at the GGSN, the IP datagrams' source address matches
the
           IPv6 source address (A's home address) recorded in one of the TFT
           filters and, if other filtering parameters are matched as well,
the
           IP datagrams will be delivered to B through the PDP Context
           corresponding to the TFT. No specific issues are identified for
this
           case.

This only applies to the Home Agent tunneling case when the MN is under the
GGSN and the HA and CN are outside. Draft-ietf-mip6-firewalls segues from
the text you've cited above from Section 3.1.1 which is a relatively precise
description of a single case into a more vaguely worded description of the
problem involving route optimization.

I think it would be more helpful for readers to understand the problem if
each case (MN inside behind firewall and HA outside, MN outside and HA
inside, etc.) were analyzed individually to the same level of detail as in
draft-chen and Section 3.1.1.
jak>>>(end)

For the other scenarios you pointed out, I agree with you. They are not in
the scope of the document. We described some of the issues, and specifically
focused on the basic ones. I will add an explicit statement in the document
to explain that the scenarios you mentioned are not included.

jak>>> I'm not clear what you mean. Is this document intended to be a
comprehensive exploration of the problems involved in firewall interaction
with MIPv6 or not? If not, then we clearly need another document that
explores the problems this one doesn't.

jak>>> Sorry, I wasn't thinking clearly here. Obviously, the firewall will
step over the IP packet header and set up the proper state for TCP. There's
only an issue if a UDP tunnel is used, such as would be the case for IPsec,
and even in that case, it's not clear how serious the problem would be.
jak>>>(end)

jak>> Hope that helps.

            jak