Re: [MEXT] WGLC for firewall drafts

Yuri Ismailov <yuri@ismailov.eu> Mon, 01 February 2010 16:25 UTC

Return-Path: <yuri@ismailov.eu>
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 6D5CA28C1AA for <mext@core3.amsl.com>; Mon, 1 Feb 2010 08:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 8OyEUa9RwDOX for <mext@core3.amsl.com>; Mon, 1 Feb 2010 08:24:59 -0800 (PST)
Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.12]) by core3.amsl.com (Postfix) with ESMTP id 146A63A6975 for <mext@ietf.org>; Mon, 1 Feb 2010 08:24:55 -0800 (PST)
Received: from [213.159.189.30] (unknown [213.159.189.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id 31820576AF0; Mon, 1 Feb 2010 17:25:29 +0100 (CET)
Message-ID: <4B67006D.3010006@ismailov.eu>
Date: Mon, 01 Feb 2010 17:25:17 +0100
From: Yuri Ismailov <yuri@ismailov.eu>
User-Agent: Thunderbird 2.0.0.23 (X11/20091002)
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
References: <4B5EAB2A.9030404@it.uc3m.es>
In-Reply-To: <4B5EAB2A.9030404@it.uc3m.es>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: mext <mext@ietf.org>
Subject: Re: [MEXT] WGLC for firewall drafts
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: Mon, 01 Feb 2010 16:25:00 -0000

Hi,
I reviewed the draft draft-ietf-mext-firewall-admin-02.
The document looks quite solid and addresses all important issues.

However, there is one issue, in my opinion, which was left aside in the
draft.
I think that the section 6.2 should be completed with the recommendations
about letting specific ICMPv4 error messages to pass through firewalls.
This has
to do with the path MTU discovery. Because this draft is concerned the
firewall traversal, there is no need to talk about MTU tuning, however,
I believe that firewall traversal is worth while mentioning.
There is a reference to RFC 4890 at the end, which is concerned with
ICMPv6 only.
When using DSMIPv6 with NAT traversal, ICMPv4 error messages regarding
MTU size
could be sent as well. Thus the suggestion is to additionally refer the
specifications
RFC1191 and RFC1981, specifying path MTU discovery for IPv4 and IPv6
correspondingly.

I suggest to add some text (see proposal below) at the end of the
section 6.2, which specifically addresses data packets for DSMIPv6.
Signaling packets probably not that important as MTU sizes will not be
exceeded,
or in case it will happen, the result will be anyway ICMPv4 error
messages as
signaling will be UDP encapsulated as well.

Proposed text at the end of the section 6.2

When using DSMIPv6 with NAT traversal, the MTU sizes and correspondingly
Maximum
Segment Size (MSS) for TCP will have to be reduced due to the number
of encapsulation headers in the data and signaling packets. This creates
a need
for path MTU discovery (RFC1191, RFC1981) to be supported in the
infrastructure
for visited networks and HA as well. As DSMIPv6 NAT traversal mechanism
suggests
using IPv4/UDP encapsulation of packets, the above mentioned path MTU
discovery
procedure may involve ICMPv4 "Destination Unreachable, fragmentation
needed and DF set"
(RFC792) message to be returned to the sender. This message may be sent
by any node
along the path including mobile node itself. In the case mobile node
resides behind
firewall, the firewall should let this type of packet (ICMP type 3, code
4) through,
in order the messages could reach the sender. The same recommendation
applies to the
firewalls in mobile's node Home Network.


Regards
Yuri


marcelo bagnulo braun wrote:
> This is the WGLC for the two drafts related to firewall and MIPv6 i.e.
> draft-ietf-mext-firewall-admin-02.txt and
> draft-ietf-mext-firewall-vendor-02.txt.
>
> Please review the documents and send comments until Feb 15.
>
> For you convenience, the drafts can be found at:
>
> http://www.ietf.org/id/draft-ietf-mext-firewall-admin-02.txt
> http://www.ietf.org/id/draft-ietf-mext-firewall-vendor-02.txt
>
> Regards, marcelo
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>