Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt

[Rémi Després <[e-mail]>]

Maoke,

We haven't reached common understanding on "tunnel and transparency"  yet.
Please see below.


2012-04-12  03:13, Maoke:

> second point, on tunnel and transparency.  
> 
> 2012/4/11 Rémi Després <[e-mail]>
> 6. The statement that "double translation is also a sort of tunneling in general sense" is IMHO confusing in view of its lack of IPv4 end-to-end transparency.
> 
> limited to the definition of "a source route that circumvents conventional routing mechanisms", IMHO, it has no business with the end-to-end transparency and therefore not confusing with explictly specifying "in general sense".

Your draft says "General-sense tunnel can be a one-hop virtual link or a multi-hop participant in the delivery path", and doesn't say that it MAY MODIFY packets .
I still consider that calling "tunnel" a mechanism whereby packets may be modified (DF, ICMPv4, UDP checksums) should be avoided.
This is however a minor issue compared to (1) below.


> The statement that "It needs further investigation to ensure if 4rd-U is qualified to be called as a tunnel in the narrow sense" expresses a doubt without substance to justify it.
> 
> because 4rd-u draft calls itself a "tunnel". the commentary identifies it is surely a general-sense tunnel. the commentary tries to understand whether it is also a narrow-sense tunnel but did not yet concluded at the time of writing. now it looks we can conclude that 4rd-u is hard to be called as a tunnel in the narrow sense. see below, regarding the transparency. 

You draft says "Narrow-sense tunnel, in architecture, behaves as a one-hop virtual link".
This is the case with 4rd-u tunnels. 

>  
> 4rd-U only claims that IPv4 packets traverse ISP domains transparently (unless they have IPv4 options in which case the domain signals it doesn't support them).
> 
> now we have clearified the checksum end-to-end transparency covering payload length and payload protocol type is lost for IPv4/ICMPv4 datagrams in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work will continue, to reflect this understanding too, by explicitly claiming that

> 4rd-u keeps end-to-end transparency for most of IPv4 fields but checksum covering payload length and payload protocol type (instead of only mentioning options) when the payload is ICMPv4, less than the transparency provided by encapsulation.

(1)
I already made the point that it is impossible to run a test that would show, "when the payload is ICMPv4", that a received "checksum covering payload length and payload protocol type" has been modified. 

This would need a simulated hardware failure, i.e. an open door to proving anything.

If we don't agree on this, lets first understand why.

(2)
If one would assume that packets can be corrupted at L2 without being discarded (which you seem to assume), then RFC6145 could translate a corrupted IPv4 packet having no UDP checksum into a corrupted packet having corrupted data and valid checksum. 
This would be much worse, as far as security is concerned, than ICMPv4 packets whose data would have been corrupted. 
  
> commentary document will include this understanding in next revision, without judging how severe this concern is in practice.

Before point 1 above is clarified, including what you said above in the next version of your draft would be AFAIK misleading.

Regards,
RD

 
>  
> 
> if no further significant dissent, this subsubject is closed. 
> 
> - maoke