[MEXT] Draft Review

[Yuri Ismailov <[e-mail]>]

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
> 
> 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
>> 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.
> 
> OK.
> 
>>
>> 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.
> 
> Looks good. Will add the text.
> 
> Thanks
> Suresh
> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
>