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 >
- [MEXT] WGLC for firewall drafts marcelo bagnulo braun
- Re: [MEXT] WGLC for firewall drafts Yuri Ismailov
- Re: [MEXT] WGLC for firewall drafts Suresh Krishnan
- [MEXT] Draft Review Yuri Ismailov
- Re: [MEXT] Draft Review Suresh Krishnan
- [MEXT] A new draft for firewall issue Xiangsong Cui