Re: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt)

"James Kempf" <kempf@docomolabs-usa.com> Tue, 26 October 2004 17:30 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 NAA26667 for <mip6-web-archive@ietf.org>; Tue, 26 Oct 2004 13:30:36 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVNJ-0000GQ-77 for mip6-web-archive@ietf.org; Tue, 26 Oct 2004 13:44:49 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUuH-0004tQ-FN; Tue, 26 Oct 2004 13:14:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUlH-0001kZ-3P for mip6@megatron.ietf.org; Tue, 26 Oct 2004 13:05:31 -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 NAA23501 for <mip6@ietf.org>; Tue, 26 Oct 2004 13:05:27 -0400 (EDT)
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUyx-0007k0-Li for mip6@ietf.org; Tue, 26 Oct 2004 13:19:40 -0400
Message-ID: <010301c4bb7e$1e0edb20$656115ac@dcml.docomolabsusa.com>
From: James Kempf <kempf@docomolabs-usa.com>
To: Franck.Le@nokia.com, mip6@ietf.org
References: <57A26D272F67A743952F6B4371B8F811017CA9BD@daebe007.americas.nokia.com>
Subject: Re: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt)
Date: Tue, 26 Oct 2004 10:06:15 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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: 10ba05e7e8a9aa6adb025f426bef3a30
Content-Transfer-Encoding: 7bit

Franck,

Some responses.

For the description of the problem (e.g. mismatch between the firewall
states and incoming packets), we tried to explicitely describe them. As an
example, to quote section 3.1.1: "The state created by the stateful
inspection packet filter protecting A is therefore initially based on the IP
address of A(IP A) and the home address of the node B (IP HoA B)." then "The
Care of Test Init message is sent using the new CoA of B as the source
address. Such a packet does not match any entry in the firewall protecting A
and as described in Section 2, the CoTi message will thus be dropped by the
firewall."

If you want to make it clearer, would you have any suggestion?

jak>> Draft-chen takes each individual case and examines it in detail. For
example, Section 4.1.1.1:

           The IP datagrams sent from A to B use the (reverse) tunnel from
A's
           current CoA to its HA. IP datagrams exit the tunnel at A's home
agent
           and transmit to B using  A's home address as the source address.
Upon
           arriving at the GGSN, the IP datagrams' source address matches
the
           IPv6 source address (A's home address) recorded in one of the TFT
           filters and, if other filtering parameters are matched as well,
the
           IP datagrams will be delivered to B through the PDP Context
           corresponding to the TFT. No specific issues are identified for
this
           case.

This only applies to the Home Agent tunneling case when the MN is under the
GGSN and the HA and CN are outside. Draft-ietf-mip6-firewalls segues from
the text you've cited above from Section 3.1.1 which is a relatively precise
description of a single case into a more vaguely worded description of the
problem involving route optimization.

I think it would be more helpful for readers to understand the problem if
each case (MN inside behind firewall and HA outside, MN outside and HA
inside, etc.) were analyzed individually to the same level of detail as in
draft-chen and Section 3.1.1.
jak>>>(end)


For the other scenarios you pointed out, I agree with you. They are not in
the scope of the document. We described some of the issues, and specifically
focused on the basic ones. I will add an explicit statement in the document
to explain that the scenarios you mentioned are not included.

jak>>> I'm not clear what you mean. Is this document intended to be a
comprehensive exploration of the problems involved in firewall interaction
with MIPv6 or not? If not, then we clearly need another document that
explores the problems this one doesn't.

> Section 3.2.2, Paragraph 10: The discussion doesn't consider
> the distinction
> between a TCP and UDP session. Earlier in the text, the
> description of the
> state maintained in the firewall implies a distinction. But
> if a MIPv6 host
> is receiving TCP packets tunneled from the HA, then the
> firewall state will
> be for UDP (presuming it is set up at all). The firewall
> timers for UDP may
> interact negatively with the MN's TCP timeouts, and there may be other
> problems.

Can you please clarify what you mean?

jak>>> Sorry, I wasn't thinking clearly here. Obviously, the firewall will
step over the IP packet header and set up the proper state for TCP. There's
only an issue if a UDP tunnel is used, such as would be the case for IPsec,
and even in that case, it's not clear how serious the problem would be.
jak>>>(end)

jak>> Hope that helps.

            jak



_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6