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

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

2012-04-12 à 12:33, Maoke:

> 
> 
> 2012/4/12 Rémi Després <[e-mail]>
> Maoke,
> 
> We haven't reached common understanding on "tunnel and transparency"  yet.
> Please see below.
> 
> ok. 
>  
> 
> 
> 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 .
> 
> it doesn't say it MAY NOT. 
>  
> I still consider that calling "tunnel" a mechanism whereby packets may be modified (DF, ICMPv4, UDP checksums) should be avoided.
> 
> for the narrow-sense "tunnel", it is correct. but on the other hand, it should be a strict "no-modification" instead of only no-modification on the selected fields. 

Are you claiming that 4rd-u can modify ICMPv4 packets that are tunneled?
If yes, could you please be kind enough provide a scenario that supports the claim?


> (well, i think we may stop this philosophical debate here because the 'general sense', 'narrow sense', ... are only my definition with "let's call it" within this very specific draft)
>  
> 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. 
> 
> no. with the TTL preserver, 4rd-u reaches the one-hop but not all the virtual link behaviors. details are related to other parts and let me postponse this topic. 

OK, let's wait and see but, at least, there is no identified problem so far.

In any case, the goal of 4rd is IPv4 transparency, not support of some "virtual link" having more implications than transparency.


>> 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.
> 
> in logic,
> 
> first of all, do you also mean it is impossible to run a test that would show any checksum has been modified unless simulated hardware failure is introduced?

Yes, I mean that an ICMPv4 packet that is tunneled across a 4rd-u domain has its ICMP checksum unchanged.
Evidence of the contrary would be new to me.

> and, (because it is impossible to run this),

> do you plan to claim that checksum covering payload length and protocol type is actually a useless design in ICMPv6/TCP/UDP?

No.

(BTW, note that in the pdf presentation you suggest below I should read deals not only with hardware failures but also with "end-host software errors". These are out of scope for 4rd, but well in scope for UDP/TCP) 

> if you argue this, i may shut up as soon as possible. 

No need, since I haven't argued this.

(BTW, this sounds like suspicion that trying to understand what I mean, and explain why I am wrong if I am, isn't worth the effort.
I have had my share of that. Disappointed to see your seeming to join this view.)


> second, you argued no matter how it is minor, a tunnel solution should cover it. test scenario having not repeat the checksum error doesn't mean it never happens.

> it might be strange to me that you attach special importance to the trasparency of DF=MF=1 but think checksum transparency is not a concern. 

Yet, a test that shows that DF=MF=1 becomes DF=1/MF=0 after double RFC6145 translation is trivial, with 100% guaranteed success.
The same for a test that No UDP checksum is translated into a computed UDP checksum.


> in practice,
> 
> unfortunately, nobody can do such a conclusion to say them useless, either nobody can say the checksum error is "minor". even on the Earth rather than the spacecraft, there are a lot reason causing bit-errors not yet well-protected by link layer. you might be interested in a paper published in SIGCOMM'00: http://dl.acm.org/citation.cfm?id=347561&bnc=1 it is basically about TCP/UDP checksum error statistics while i believe you do agree the understanding is also applicable for the IPv4/ICMPv6 case. the checksum error happens with the frequency between 1/1100 ~ 1/32000, and reaches 1/400 in some circumstances, even though the link layer CRC is there. 
> 
> to save your time, you may read http://elf.cs.pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdf instead, for a quick understanding on why protocol needs to include its own checksum even if the link layer has had CRC mechanism. 

The only router induced errors I saw in this presentation are due to
- buggy network interfaces
- memory errors
- bus malfunctions 
All of these are hardware failures.

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

> this talk is limited to the case where corruption happens inside in the UDP protocol data unit. 

Right.

> A. native IPv4: if corrupted packet having no UDP checksum arrives at destination, the destination anyway accepts the corrupted data; 

Yes, but in native IPv4 (and across 4rd-u tunnels) destination hosts know there is no checksum.

> B. acrossing IPv6 RFC6145 domain: 
>    B.1 if corruption happens before entering the IPv6 domain, yes,

> corrupted data with valid checksum is generated, and delivered to destination, which will accept the corrupted data;

The point is that corrupted data are accepted with the supposed guarantee that they were protected by a checksum.

>    B.2 if corruption happens in the IPv6 domain, the translation with checksum provides a certain extent of protection. 

Not the subject (and in any case possible only with a supposed hardware failure).

> RFC6145 don't make B.1 worse than A while improves B.2.

- Receiving erroneous data with a checksum that assures they are valid is WORSE than receiving corrupted data with a warning that they haven't been verified.

I hope you can agree on this.


> don't you think it is a pros instead of a cons? 

Neither pro nor con, because the implied assumption of hardware failure remains AFAIAC out of scope.

>  
> This would be much worse, as far as security is concerned, than ICMPv4 packets whose data would have been corrupted.  
> 
> (on the other hand, if you would like to make a commentary for RFC6145 detailed behavior,

No wish to comment RFC6145 other than in the context of double translation.

> i'd love to offer assistance as i happend to make some humble observations on it too, but this is not the scope of this thread.)
>  
>   
>> 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.
> 
> in the term of stating the semantic changes with leaving judgement to readers, i don't think there will be any misleading. i only write the fact and the concern. some of them might be significant and severe, some of them might be only trivial FUD. but even FUD, we are obliged to let the community know it. 

Let's then see what you will write, hopefully with preliminary consideration of the above.

Regards,
RD

> 
> - maoke 
>