Subject: Re: [MEXT] WGLC for firewall drafts

From: Yuri Ismailov <[email-masked]>
Date: Mon, 01 Feb 2010 17:25:17 +0100

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 1 Feb 2010 16:03:02 -0500

Hi Yuri,
   Thanks for your comments.

Cheers
Suresh

> The document looks quite solid and addresses all important issues.

Sounds good.

> about letting specific ICMPv4 error messages to pass through firewalls.

You are right. We did not think about this as DSMIPv6 was a late 
addition to this document. It makes sense to add these recommendations.

> RFC1191 and RFC1981, specifying path MTU discovery for IPv4 and IPv6

OK.

> firewalls in mobile's node Home Network.

Looks good. Will add the text.

Thanks
Suresh

---

From: Yuri Ismailov <[email-masked]>
Date: Mon, 01 Feb 2010 22:32:18 +0100

Hi,
After sending comment about path MTU I just thought that things could be
more serious than that.This is not related to the draft for FW
traversal, but I want to share my concerns here.with the group.

Assume that infrastructure works as it should and path MTU discovery
implemented and functional in all nodes. Firewalls are opened for
necessary traffic to path through.

However, when using DSMIPv6 with NAT traversal, the outer header
contains source IP address, which is HA IPv4 address. Any intermediary
node, in case of less MTU along the next hop will send ICMP Host
Unreachable to the HA. Basically, the ICMP will never reach CN, which
will keep sending packets with the same MTU, exceeding the required one.
This has bad consequences. For example TCP connection will be
established (SYN exchange uses small packets) but data packets will not
get through

Is that correct understanding?

Regards
Yuri

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 2 Feb 2010 01:30:38 -0500

Hi Yuri,

> Is that correct understanding?

Not really. The HA will need to discover and remember the path MTU on 
its tunnel interface. If it gets an incoming packet from the CN larger 
than the tunnel MTU, it will send a dest unreachable code 4 message 
towards the CN.

Cheers
Suresh

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 11 Feb 2010 15:51:38 +0800

Dear Marcelo and all,

I have read the drafts and I think the drafts are in good shape.

Additionally, I think the trouble we are facing is the incompatibility
of firewall and mobility messages, or the conflict between firewall filter
and mobility management (e.g. care-of address).

These two drafts resolve the trouble by firewall enhancement and 
configuration, this is really an effective approach.

On the other hand, I am thinking can we extend the procedure of
mobility management to resolve this incompatibility?
I submitted a draft for this approach, 
http://tools.ietf.org/id/draft-cui-mext-firewall-traversing-00.txt
Is that considerable?

Any comment is appreciated!

Xiangsong