Re: TSVDIR review of draft-ietf-intarea-shared-addressing-issues-02

[Joe Touch <[e-mail]>]

On 2/2/2011 1:55 PM, Masataka Ohta wrote:
> Joe Touch wrote:
>
>>> 9. ICMP
>>>
>>> ICMP does not carry any port information and is consequently
>>> problematic for address sharing mechanisms.
>>
>> ICMP messages are specifically intended to include enough of the
>> transport header to enable port demuxing at the end receiver.
>
> I think it says ICMP information messages such as echo request
> do not have port numbers.

I quoted the start of the section. The first sentence, without further 
qualification, is inaccurate, IMO.

ICMP messages do not themselves have port numbers, but they are intended 
to *carry* port numbers of the messages that caused their generation (if 
they report errors).

> However, ID and sequence number field of echo request can be
> used (overridden) as source and destination port numbers,
> respectively.

This is relevant to the generation of new ICMPs that are not the result 
of errors - e.g., echo request. The section is written so generally as 
to include ICMPs that are responses to errors too, typically as 
generated by packet arrivals.

> As the fields are copied as is from echo request to echo reply,
> ID and sequence number field of echo request must be
> used as destination and source (reversed) port numbers,
> respectively.
>
> It's implemented for end to end NAT and is working with "ping"
> and "traceroute".
>
>>> 11. Fragmentation
>>>
>>> When a packet is fragmented, transport-layer port information (either
>>> UDP or TCP) is only present in the first fragment. Subsequent
>>> fragments will not carry the port information and so will require
>>> special handling.
>>
>> ?INT? The ID will be incorrect too; it may not be unique as required
>> when viewed from the outside.
>
> Port based redirection MUST be done after fragmentation reassembly.
>
> That's all and is no special.

IMO, any device that initiates packets MUST verify that the IDs emitted 
follow spec. Once a packet's address(es) are rewritten, the NAT is 
responsible for ensuring that the IDs are unique across the 
src/dst/proto triple.

I'm not aware of NATs that do this; they typically copy the ID field, 
and this can easily cause reassembly errors later - even if the packet 
is reassembled at the NAT itself.

See draft-ietf-intarea-ipv4-id-update for more a discussion of this 
issue and the proposed requirements to address it.

Joe