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

Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com> Sat, 30 October 2004 00:36 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29575 for <mip6-web-archive@ietf.org>; Fri, 29 Oct 2004 20:36:40 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNhSv-0006d1-Ot for mip6-web-archive@ietf.org; Fri, 29 Oct 2004 20:51:34 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNhAL-0007Tu-AZ; Fri, 29 Oct 2004 20:32:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNgwB-0007wZ-U7 for mip6@megatron.ietf.org; Fri, 29 Oct 2004 20:17:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28279 for <mip6@ietf.org>; Fri, 29 Oct 2004 20:17:42 -0400 (EDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNhAY-0006IM-Uq for mip6@ietf.org; Fri, 29 Oct 2004 20:32:35 -0400
Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9U0Hf7q020472 for <mip6@ietf.org>; Fri, 29 Oct 2004 17:17:41 -0700 (PDT)
Received: from shubho (shubho.SFBay.Sun.COM [129.146.73.85]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with SMTP id i9U0Hf45860559; Fri, 29 Oct 2004 17:17:41 -0700 (PDT)
Message-Id: <200410300017.i9U0Hf45860559@jurassic.eng.sun.com>
Date: Fri, 29 Oct 2004 17:17:18 -0700
From: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
To: mip6@ietf.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset="us-ascii"
Content-MD5: qf+93+oAcWA/u3q4v5S4VQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_54 SunOS 5.10 sun4u sparc
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: samita.chakrabarti@sun.com
Subject: [Mip6] Last Call Comments: draft-ietf-mip6-firewalls-00.txt
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b

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
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6