Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-08.txt

[Christian Huitema <[e-mail]>]

On 7/12/2022 9:03 PM, Brian E Carpenter wrote:
> On 13-Jul-22 15:46, Bernard Aboba wrote:
>>> On Jul 12, 2022, at 20:03, Brian E Carpenter 
>>> <[e-mail]> wrote:
>>> People writing fault-tolerant software will draw their own conclusions.
>>
>> [BA] Looking at the document examples there are several cases of 
>> poorly written specifications. The Robustness Principle doesn’t 
>> condone that, nor does it preclude rejecting nonconformant inputs 
>> when there are good reasons to do so (e.g. security). If the spec is 
>> vague in places, if there are known interop issues, by all means fix 
>> it. It’s the Robustness principle, not the Don’t Worry Be Happy 
>> principle.
>>
>> There is another thing that bothers me, which is the problem of 
>> untested code paths. Greasing alone cannot solve this. The Robustness 
>> Principle mostly applies to expected conditions. Many security 
>> vulnerabilities fall into these unexpected cracks. The best tool I 
>> have seen us a formal state machine analysis to identify attack 
>> vectors. Robustness Principle doesn’t preclude that either.
>
> Would a state machine analysis detect possible race conditions? These 
> are not mentioned in the draft, and I think they're the sort of corner 
> case that the robustness principle should help with.


You need to distinguish between testing communication protocols and 
testing software. The "untested code paths" that Bernard mentions are 
more often software coding issues than protocol design issues.

If you are concerned that a succession of transitions drives the 
protocol state into untested territory, then it is much safer to stop 
sooner, e.g., close the connection with a "local error" diagnostic when 
things start looking iffy. The opposite would be to tolerate operation 
in modes that have not been tested yet, and that's exactly when bad 
stuff happens.

-- Christian Huitema