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

>
> Le 2012-04-11 à 15:44, Maoke a écrit :
>
>
> postpone other parts, but focus on the checksum issue.
> 2012/4/11 Rémi Després [e-mail]
>
>>
>> 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4
>> message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But
>> this integrity can be ensured at tunnel exit by checking that CNPs do
>> preserve checksum neutrality. This can be clarified by a complement in the
>> 4rd-u security section.
>>
>>
>
> 1. this introduces another new semantics/logic of protocol stack
> processing at exit CE. it is really hard to call it either IPv4 or IPv6.
>
>
> How it is called is IMHO secondary, what is a fact is that it ensures
> address security.
>
>
> 2. even though this CNP works for the address integrity,
>
>
> (which was the listed point)
>
> unfortunately, however, the checksum still provides integrity protection
> for packet length and payload protocol type in both IPv4/ICMPv4 pair and
> IPv6/ICMPv6 pair. they are involved either in IPv4 header checksum or in
> ICMPv6 checksum, which covers the pseudo-header of IPv6.
>
>
>
> how could CNP protect these?
>
>
> No way, of course.
> (Are we now in the technical discussion, or still in deliberate
> controversy?).
>
>
technical discussion results in problem understanding instead of certainly
a support for or an objection to a work politically. so i don't understand
what is the so-called "deliberate controversy" here. i suppose my draft is
written very neutral. as you raised a new solution regarding a
concern while i found it not complete, i surely need to confirm if
you would design a more comprehensive solution for that issue, and if the
already-designed mechanism has had the functionality but i was not aware of
that.

> thanks for mentioning CNP here.
>
>
> i need to modify the concern for "address integrity" to the concern for
> "integrity of addresses, packet length and payload protocol type".
>
>
> - Addresses have been covered AFAIAC.
> - No test scenario I can imagine can reveal an ICMPv4 security problem
> concerning protocol type or packet length. (A simulated hardware failure
> would AFAIK be needed, and with that, many other security problems can be
> considered to exist.)
>

> => Unless you come up with new facts, end of this subject for me.
>
>

i don't think it is needed to provide new facts here, at this stage. the
test scenario is the next step. the draft is purposed on clarifying these
semantics and their direct impact. judgment on the severity of the impacts
is remained to the readers.

i don't think 4rd-u is scoped within networks with reliable L2 links, isn't
it? then, in a generic physical environment, one may think only address
checksum is enough, one may think it is not enough, one may think checksum
is anyway too weak to provide so-called protection, etc. --- all of these
sort of asserts of severity judgment are out of the scope the draft (sec 5
para 1).

fine to close this subject for me too because you have clarified "no way".
that's enough. a refined statement on this issue will appear in the
revision.

tomorrow let me clarify another.

thanks,
maoke


>
>
> RD
>
>
>