Re: [MEXT] WGLC for firewall drafts

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

Re: [MEXT] WGLC for firewall drafts

Hi Yuri,
   Thanks for your comments.

Cheers
Suresh

On 10-02-01 11:25 AM, Yuri Ismailov wrote:
> Hi,
> I reviewed the draft draft-ietf-mext-firewall-admin-02.
> The document looks quite solid and addresses all important issues.

Sounds good.

> 
> 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.

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.

> 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

[MEXT] Draft Review

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

Suresh Krishnan wrote:
> Hi Yuri,
>   Thanks for your comments.
> 
> Cheers
> Suresh
> 

Re: [MEXT] Draft Review

Hi Yuri,

On 10-02-01 04:32 PM, Yuri Ismailov wrote:
> 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?

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

[MEXT] I-D Action:draft-ietf-mext-binary-ts-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Traffic Selectors for Flow Bindings
	Author(s)       : G. Tsirtsis, et al.
	Filename        : draft-ietf-mext-binary-ts-03.txt
	Pages           : 19
	Date            : 2010-02-09

This document defines binary formats for IPv4 and IPv6 traffic
selectors to be used in conjunction with flow bindings for Mobile
IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binary-ts-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext

[MEXT] I-D Action:draft-ietf-mext-flow-binding-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Flow Bindings in Mobile IPv6 and NEMO Basic Support
	Author(s)       : H. Soliman, et al.
	Filename        : draft-ietf-mext-flow-binding-05.txt
	Pages           : 37
	Date            : 2010-02-09

This document introduces extensions to Mobile IPv6 that allow nodes
to bind one or more flows to a care-of address.  These extensions
allow multihomed nodes to instruct home agents and other Mobile IPv6
entities to direct inbound flows to specific addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
MEXT mailing list
MEXT <at> ietf.org
https://www.ietf.org/mailman/listinfo/mext

[MEXT] flow binding draft send to IESG

Thanks for the good work everyone and special thanks to George for 
taking care of the last comments.

Regards, marcelo

[MEXT] A new draft for firewall issue

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

----- Original Message ----- 
From: "marcelo bagnulo braun" <marcelo <at> it.uc3m.es>
To: "mext" <mext <at> ietf.org>
Sent: Tuesday, January 26, 2010 4:43 PM
Subject: [MEXT] WGLC for firewall drafts

> 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.

[MEXT] rfc3775bis ticket #7: "DSMIPv6 BU format and RFC 3775" --- close?

Hello folks,

I have reviewed the issue and following discussion.
There has not been any new discussion on the mailing
list in a long time.  You can see the discussion
on the issue tracker web page:
     http://trac.tools.ietf.org/wg/mext/trac/ticket/7

Almost all of the discussion centered around likely
problems with DSMIPv6 wording.  There was some
relevance to rfc3775bis, but I don't think there
was very persuasive argument for making any changes
to rfc3775bis.

In preparation for submitting another revision of
rfc3775bis for publication this week, I recommend
closing this issue without change to the document.

Regards,
Charlie P.

[MEXT] rfc3775bis ticket #18: "Issues regarding Home Address Option & ICMP / Binding errors" --- resolutions accepted, so should close.

Hello folks,

Last summer there was some discussion on
rfc3775bis ticket #18.  The discussion can
be reviewed on the web page:
     http://trac.tools.ietf.org/wg/mext/trac/ticket/18

This ticket actually describes three generally
different issues, each of which received individual
attention on the mailing list and which had
independent resolutions.  Pertinent discussion
is condensed and shown on the above-mentioned
web page.

Since then, there has been no discussion, and
noone has objected to the proposed resolutions
to the three separate issues.  The text of
the proposed resolutions has been included
in draft-ietf-mext-rfc3775bis-05, so the issue
should have been closed already.

I'll do that soon.

Regards,
Charlie P.