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

[Maoke <[e-mail]>]

a summary:

1. on the IPv6/ICMPv4 checksum issue, yes i talk about hardware failure
essentially. surely the paper i cited "also" contains other sources of
bit-error like host software. i suppose that the 4rd-u box can deal with
that before doing the header processing. regarding the IPv6/ICMPv4 checksum
issue, the main concern is hardware error in IPv6 routers.

2. on the null checksum, again the checksum because of hardware error in
IPv6 routers

(btw, IMC'07 paper argued that the DF=MF=1 was a software failure due to
poor implementation of IP stack. i really want to say software failure is
out of scope but i won't  ;-) - a btw fyi but out of service of this topic)
so the key dissent between you and me is: you think hardware failure is out
of scope but i think it is essential, because CRC in link layer is not
enough to deal with that and because a lot of error has happened before the
data is put into the physical link, and checksum is an important way to
detect such kind of failure. Stone and Partridge concluded: what TCP
checksum cannot detect are only 1 of 10 billion about, reflecting how
important the checksum is. unless 4rd-u co-authors makes out a statistics
on ICMPv6 checksum error rate is definitely below a low-enough level (e.g.,
10^-6 among ICMPv6 messages) in a test with multihop environment with high
workload and sometimes working in high temporature or in high radioactive
environment, the statement "4rd-u can keep transparency as the same as
MAP-E" would be AFAIK a misleading, at least irresponsible statement!

or, may you please gently say 4rd-u doesn't concern any environment where
IPv6 routers may have any hardware error, as you think hardware error is
out of scope. though i doubt you are really want to make a protocol for
Internet use. and i really think further discussion might be very hard, if
we are in totally different understandings regarding the most essential
assumption about the Internet.

i prepared further reply to your comments but it looks not significant now.
because all of them are related to this or that of errors, that could be
out-of-scoped by you.

- maoke

2012/4/12 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.pdfinstead, 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
>
>
>