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

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

Le 2012-04-11 à 17:54, Maoke a écrit :

> 
> 
> 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 supposed it was evident to you too that CNP cannot protect protocol and/or packet length.
Then, asking how it would do that sounded to me as a non technical question.
Sorry if this wasn't the case.  

> i suppose my draft is written very neutral.

Full of good level technical analysis, I am pleased to acknowledge.
Although I believe anyone asked to guess whether you are in favor of 4rd or MAP would easily find the answer, I can also acknowledge that the draft is neutral to a good enough extent.


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

OK.

> the draft is purposed on clarifying these semantics and their direct impact. judgment on the severity of the impacts is remained to the readers.

OK.

> i don't think 4rd-u is scoped within networks with reliable L2 links, isn't it?

It is scoped under the common assumption that: (1) L2 isn't reliable in that it can loose packets; (2) L2 is reliable in that it never delivers corrupted packets without corruption being detected.
AFAIK, IPv6 has been specified under this assumption.

RD


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