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

[Maoke <[e-mail]>]

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.

(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.


>
>
>
>> 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? 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? if you argue this, i may shut up as soon
as possible.

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.

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.


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

A. native IPv4: if corrupted packet having no UDP checksum arrives at
destination, the destination anyway accepts the corrupted data;
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;
   B.2 if corruption happens in the IPv6 domain, the translation with
checksum provides a certain extent of protection.

RFC6145 don't make B.1 worse than A while improves B.2. don't you think it
is a pros instead of a cons?


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

- maoke