[MEXT] Review of I-Ds draft-ietf-mext-firewall-vendor and draft-ietf-mext-firewall-admin

<Basavaraj.Patil@nokia.com> Thu, 04 June 2009 20:58 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5EE3A6C7B for <mext@core3.amsl.com>; Thu, 4 Jun 2009 13:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level:
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuFJUHLZVjuD for <mext@core3.amsl.com>; Thu, 4 Jun 2009 13:58:29 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B80D93A68AD for <mext@ietf.org>; Thu, 4 Jun 2009 13:58:28 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n54KwMfQ025132; Thu, 4 Jun 2009 23:58:23 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 23:58:25 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 23:58:24 +0300
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 4 Jun 2009 22:58:24 +0200
From: Basavaraj.Patil@nokia.com
To: mext@ietf.org
Date: Thu, 04 Jun 2009 22:58:33 +0200
Thread-Topic: Review of I-Ds draft-ietf-mext-firewall-vendor and draft-ietf-mext-firewall-admin
Thread-Index: AcnlVziGcMjns67IIEO/VQFRZu1/3g==
Message-ID: <C64D9FA9.29C45%basavaraj.patil@nokia.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jun 2009 20:58:24.0812 (UTC) FILETIME=[33A4BEC0:01C9E557]
X-Nokia-AV: Clean
Cc: Gabor.Bajko@nokia.com
Subject: [MEXT] Review of I-Ds draft-ietf-mext-firewall-vendor and draft-ietf-mext-firewall-admin
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2009 20:58:30 -0000

My review comments about the following two I-Ds are below:

1. draft-ietf-mext-firewall-vendor-01
2. draft-ietf-mext-firewall-admin-01

The scope of the above I-Ds is restricted to Mobile IPv6 (RFC3775)
only. It would be much more useful to specify the guidelines for
firewall administrators and firewall implementers for the DSMIP6
protocol
(http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-10.txt
)
instead. DSMIP6 is much more practical in terms of real-world
deployments and hence the WG is better off specifying the firewall
considerations for DSMIP6. IMO it is time better spent and the
document much more useful if it were to include the rules for the
firewalls w.r.t DSMIP6.

1. draft-mext-firewall-vendor:

- The intent of this I-D is to simply specify the implications of
  Mobile IPv6 signaling and user data on firewalls. The statement :
  "This document describes how to implement stateful packet filtering
  capability for MIPv6" needs to be modified accordingly.

- The draft notes that signaling messages can be encrypted. However it
  does not capture the details of RFC4877 which explains the security
  for the signaling messages using ESP in transport and tunnel
  modes. The I-D needs to consider both these approaches in terms of
  the rules at the firewall.

- The I-D does not consider the DHAAD signaling messages. For
  completeness it should be included. (Use of DHAAD is an ogoing
  discussion in the context of 3775bis).

- The firewall rules in the case of DSMIP6 where the signaling and
  user data are encapsulated in IPv4 (and using UDP encapsulation in
  the case where the MN is behind a NAT) should be covered. The packet
  format as seen by the FW in various scenarios should be specified
  with the associated processing details.

- The I-D does not mention any rules to allow IKEv2 signaling between
  the MN and HA. Would be good to specify these rules as well. It is
  however covered in the fw-admin I-D.

- In the security considerations the I-D states:
  "In a typical enterprise environment, an administrator cannot
   distinguish Mobile IPv6 capable nodes from other nodes.  In such a
   situation any node in the protected network may end up receiving
   unsolicited packets from outside the firewall."
   With the proper FW rules packets would only be forwarded to the
  HA. I dont see how this vulnerability would exist. Can you elaborate
  further on this? Would'nt there be another firewall between the HA
  and the hosts in the enterprise domain as well with enterprise
  specific rules?

- It would be useful to have some figures which show the FWs that
  could be encountered between an MN-HA-CN. Rules which would apply to
  different FWs need to be specified explicitly.
  For example in the case of RO, the FW in front of an HA only needs
  to handle the RO signaling messages. But the FWs that are in the MN
  or CNs access networks may need to create pinholes for the RO
  traffic between the MN and CN.

2. draft-ietf-mext-firewall-admin-01

- Would be good to consider DSMIP6 as the baseline protocol for
  firewalls to deal with

- Again, the I-D needs to consider the transport and tunnel mode ESP
  options for signaling

- If the user data is also secured with IPsec, what are the rules at
  the FW?

-Basavaraj