Subject: RE: [Mip6] Last Call Comments: draft-ietf-mip6-firewalls-00.txt

From: [email-masked]
Date: Wed, 3 Nov 2004 09:08:03 -0600

Hello Samita,

Thank you for all your comments and suggestions. I will report them on the issue tracker and we will incorporate them in the next version of the internet draft to clarify it.

Thank you again,

Franck

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Samita Chakrabarti
> Sent: 29 October, 2004 07:17 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Mip6] Last Call Comments: draft-ietf-mip6-firewalls-00.txt
> 
> 
> Here are some comments for the mip6-firewalls draft:
> 
> - RRT is mentioned several places in the document, please define this
>   term in the begining
>   
> - In the section 2.1 , it would be good to clarify the three areas of
>   firewall packet filtering this document is addressing - such as
>   addresses (src, dst), ports and protocols.
>   
>   
> - Section 2.2 talks about packet filtering problem in 3G networks, but
>   I don't see much relevance of that in this document. This document
>   structure may be modeled after that- this paragraph may be moved to
>   appendix or to a different section toward the end ( to show 
> that similar
>   deployment problem exists in 3G networks).
>   
>   
> - section 3.1.1 "Return Routability Test sp"  -- what is sp? typo?
>    This section could be shorter with some more editing. It might be
>    effective to point out the issue (COTI, but not HOTI) in 
> the beginiing
>    of the paragraph. It seems fig 2. could be replaced by fig 
> 3- thus fig2
>    may be redundant.
>    
> - section 3.1.2 last paragraph " Requiring the stateful 
> inspection ...network"
>    I am not sure if I understand the problem here. How does 
> BU come into the
>    picture? Previously it talks about COTI. I assume, the 
> same problem applies
>    to BU/BA between CN (within firewall) and MN (external) 
> when RR is used.
>    Also, if the firewall checks for MIP6 nexthdr and type 
> (COTI, BU, BA), then
>    it would not be a big issue- becuase the validity checks 
> are supposed to
>    happen at CN anyway. For DOS attack, I agree it is easier than
>     sending packets for a particular port and upperlayer 
> proto, but DOS attacks
>     are hard to prevent. I guess we are going into solution 
> space here- let's
>     just state the issues. 
>     
> - section 3.2  Scenario when the inner node is a Mobile Node
>  I think this section needs to discuss the two cases:
>      1) when MN moves within the same Firewalled network
>      2) when MN moves into the firewalled network from 
> external network
>      
>  - section 3.2.1 
>     Issue with ESP and Firewall:
>        -- Firewall dropping ESP packets is a IPsec issue - 
> which is not
>           MIP6 problem. It should be solved though for 
> deployment for MIP6.
>           
>        -- ESP protecting mobility header in transport mode or 
> tunnel mode
>            could be a problem if we want to allow MIP6 BU/BA 
> between MN-HA
>            in the firewall.
>         You may want to clarify these two cases. 
>           
> -- section 3.2.2
> 
>     This section discusses about state life time issue- but it is not
>     clear to me how CN-MN come into question given that we 
> were talking
>     about MN-HA states. Is it talking about problem with IP-n_IP IPsec
>     tunnel where the ESP header sits above the internal IPv6 header (
>     MN(HOA)-->HAA) ? This can be clarified by giving the 
> packet sequence
>     as described in RFC3776.
>     
>     
>  -- section 3.2.3
>     This section needs editing for concise description. Also 
> it needs to
>     separate issues in subsections such as HOTI/HOT under ESP 
> tunnel or
>     COTI/COT or BU to the CN. This section is again trying to 
> indicate 
>     some solutions - it may be good idea not to suggest that 
> in this doc.
>     
> -- section 3.2.4 ==> this really belongs to section 3.2 as one of the
>    configurations.
>    
> -- section 3.2.5 
>     Please clarify two cases (without and with RR).
>     If RR is not used then it is no different (wrt the new FW and MN)
>      than external MN is moving into firewalled network as MN 
>      needs to rebuild a new tunnel to HA assuming its COA changes.
>     
> BTW, it is good to see this document which discusses the 
> real-life issues.
> 
> Thanks,
> -Samita
>     
>   
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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