IETF Logo Mail Archive

Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> Fri, 14 October 2011 23:58 UTC

Return-Path: <achatz@forthnetgroup.gr>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADA721F8C7A for <v6ops@ietfa.amsl.com>; Fri, 14 Oct 2011 16:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.356
X-Spam-Level:
X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5qQIjgjrdto for <v6ops@ietfa.amsl.com>; Fri, 14 Oct 2011 16:58:57 -0700 (PDT)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 5674C21F8C78 for <v6ops@ietf.org>; Fri, 14 Oct 2011 16:58:57 -0700 (PDT)
Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9ENwuX8017074; Sat, 15 Oct 2011 02:58:56 +0300
Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9ENwtL9014402; Sat, 15 Oct 2011 02:58:55 +0300
Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9ENwj8K003809; Sat, 15 Oct 2011 02:58:46 +0300
Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN)
Message-ID: <4E98CCB2.2050100@forthnetgroup.gr>
Date: Sat, 15 Oct 2011 02:58:42 +0300
From: Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>
Organization: Forthnet S.A.
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1
MIME-Version: 1.0
To: "Hemant Singh (shemant)" <shemant@cisco.com>
References: <4E974F1A.2030008@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3030A4156@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303130390@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303130390@XMB-RCD-109.cisco.com>
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2011 23:58:58 -0000



    

    Hemant Singh (shemant) wrote on 15/10/2011 01:05:
    

      
      
      
      

        
Tassos,

        
 

        

          

            
From:
                v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
                  Behalf Of Hemant Singh (shemant)

                Sent: Thursday, October 13, 2011 8:18 PM

                To: Tassos Chatzithomaoglou; v6ops@ietf.org;
                draft-ietf-v6ops-6204bis@tools.ietf.org

                Subject: Re: [v6ops] new draft:
                draft-ietf-v6ops-6204bis

          

        

        
 

        


          >>Lastly, i would also like
          to have the following under "4.5. Security Considerations".
          Unless we are leaving this functionality to the AFTR/BR >(although i couldn't find
          anything relevant; PCP?).

          

          >>S-3:  The IPv6 CE router MUST
              support the configuration of a common filtering behavior,
              regardless of the >interface type that traffic is
              coming through >>(native or through a
              transition/tunneling technology).

          

          >Will have to think about this one. 
            S-2 already mentions ingress filtering.  We could modify S-2
            to include some text from your suggestion above.   

        
 

        
How
            can the  device have a common filtering behavior for
            tunneled traffic vs. native traffic?    The rfc6204bis
            document already references RFC 6092 that discusses copious
            security for native and tunneled transport.  One key
            recommendation for security related to tunnels is prescribed
            in RFC 6169 which is to have tunneled traffic not cross
            border routers.  Both 6rd and DS-Lite tunnels terminate
            within the boundary of the SP secured domain.   Thus I don’t
            see a need for adding any other text related to security in
            the rfc 6204bis document yet.

        
 

        
Thanks,

        
 

        
Hemant

      

    

    Hemant,

    

    Since the CPE is also a tunnel endpoint, i believe ingress filtering
    of tunneled traffic should be implemented after the
      decapsulation of the traffic, before reaching the LAN.

    i.e. in case of DS-Lite, in the ingress direction, after the IPv6
    tunnel header is removed, IPv4 traffic should be inspected like it
    would be if it was coming from an IPv4 native interface. Unless the
    IPv6 firewall can inspect IPv4inIPv6 packets too....or maybe i'm
    asking too much from the CPE vendors.

    PS: I guess we won't need to worry about this, if we leave it to the
    PCP server on the AFTR.

    

    Regards,

    Tassos

    

  


      
    

    

      
    


 




            


        



      
 


      

        
      

          
    
 

    


 

    



    






    

    


    
  
    
  

      
v2.23.0 | Report a Bug | By Email