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

["Bless, Roland (TM)" <[e-mail]>]

Hi Eric,

see inline.

On 15.07.22 at 02:46 Eric Rescorla wrote:
> Suppose we have a protocol that consists of a set of tag-length-values
> fields. A message consists of a length field followed by a list of
> TLVs.  The protocol defines the following requirements for how a
> message is constructed:
>
> 1. A given tag MUST only appear once
> 2. TLVs MUST appear in ascending tag order (this can help
>    detect violations of the previous condition)
>
> Question 1: How should implementations behave upon receiving the
> following messages, absent any other spec guidance?
>
> - Tags: 1, 2, 2  [Violates rule 1]
> - Tags: 1, 3, 2  [Violates rule 2]
>
Obviously, the sender violated the spec and thus did not apply
the conservative/strict sending rule of the Robustness Principle.
Depending on the rest of the protocol spec, one could either return
meaningful error messages (if defined and applicable for such cases)
or silently discard these malformed messages. I would probably
recommend to silently discard in order to avoid amplification attacks
(but this depends on the ratio of the message lengths).

I think the Robustness Principle on the receiver side is more about
cases when the overall length field does not match the sum of the TLV 
objects
lengths and/or individual TLV length fields extending beyond the end of the
message. An implementation should robustly handle these kinds of issues
(among many others). But how should implementations react to messages
where only one TLV is malformed? Should one drop the complete message
or process the rest of the message normally? This probably also depends
on the context (e.g., is the TLV optional or necessary etc.). Ideally, 
the spec
should also give guidance here.

> Question 2: Should we provide specification guidance for how to handle
> these rule violations, and if so, how?

IMHO, the protocol spec should give guidance for handling such
"malformed" messages to avoid the ambiguity of sending error messages
back or silently discard the messages (and probably log the error locally).

> Question 3: Do you think the answers depend on other properties of the
> protocol? If so, what are they?
>
See above. I don't think that the Robustness Principle is required
to define a useful reaction. Whether it is useful to send error messages
back may actually depend on the message type and context etc.

Regards,
  Roland


> On Tue, Jul 12, 2022 at 4:44 PM Brian E Carpenter 
> <[e-mail]> wrote:
>
>     I still find it hard to accept that there is community consensus for
>     this document as it stands. Most of what its says is correct but it
>     still seems to unreasonably claim universal scope.
>
>     Some suggestions:
>
>     Title: The Robustness Principle May Have Harmful Consequences
>
>     Last sentence of Abstract:
>     For some types of protocol that are actively maintained, the
>     robustness principle can, and should, be avoided.
>
>     And a few changes in the main text such as:
>     OLD:
>     Time and experience shows that negative consequences to
>     interoperability accumulate over time if implementations apply the
>     robustness principle.
>
>     NEW:
>     Time and experience shows that negative consequences to
>     interoperability sometimes accumulate over time if implementations
>     apply the robustness principle.
>
>     Even with changes like this, I'm not sure everyone will agree.
>
>     Regards
>         Brian Carpenter
>
>     On 12-Jul-22 10:30, [e-mail] wrote:
>     >
>     > A New Internet-Draft is available from the on-line
>     Internet-Drafts directories.
>     > This draft is a work item of the Internet Architecture Board
>     IETF of the IETF.
>     >
>     >          Title           : The Harmful Consequences of the
>     Robustness Principle
>     >          Authors         : Martin Thomson
>     >                            David Schinazi
>     >    Filename        : draft-iab-protocol-maintenance-08.txt
>     >    Pages           : 15
>     >    Date            : 2022-07-11
>     >
>     > Abstract:
>     >     The robustness principle, often phrased as "be conservative
>     in what
>     >     you send, and liberal in what you accept", has long guided
>     the design
>     >     and implementation of Internet protocols.  The posture this
>     statement
>     >     advocates promotes interoperability in the short term, but can
>     >     negatively affect the protocol ecosystem over time. For a
>     protocol
>     >     that is actively maintained, the robustness principle can, and
>     >     should, be avoided.
>     >
>     >
>     > The IETF datatracker status page for this draft is:
>     > https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/
>     >
>     > There is also an HTML version available at:
>     >
>     https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-08.html
>     >
>     > A diff from the previous version is available at:
>     > https://www.ietf.org/rfcdiff?url2=draft-iab-protocol-maintenance-08
>     >
>     >
>     > Internet-Drafts are also available by rsync at
>     rsync.ietf.org::internet-drafts
>     >
>     > 
>