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

[[e-mail]]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6