Subject: [arch-d] Chaff in protocols

From: "Martin Thomson" <[email-masked]>
Date: Thu, 27 Jun 2019 14:12:54 +1000

Esteemed colleagues,

The IAB is looking for historical examples of deliberate additions to a protocol that are added not to enable new behaviour, but to test that the ability to do so remains viable.

This comes up in the context of assessing the concept of "grease" (see draft-ietf-tls-grease), a practice of adding meaningless extension points to messages in the hope that it will reveal, and perhaps prevent, intolerance toward real extensions.  This is a practice we have seen deployed with some success in TLS.  That has produced some enthusiasm about the practice.  I think that it would be fair to say that the IAB maintains some reservations about the general applicability of the technique.

Are there protocols (in either specification or deployment) that have experimented with this sort of thing in the past?

The concept of fuzzing software isn't new (see https://en.wikipedia.org/wiki/Fuzzing) and testing for resilience to unusual behaviour is similarly well-established (e.g., https://github.com/Netflix/chaosmonkey).  But are there cases of this in network protocols prior to its use in TLS?

Regards,
Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Jun 2019 11:41:01 +1200

On 27-Jun-19 16:13, Martin Thomson wrote:
 
> Esteemed colleagues,
> 
> The IAB is looking for historical examples of deliberate additions to
> a protocol that are added not to enable new behaviour, but to test
> that the ability to do so remains viable.
> 
> This comes up in the context of assessing the concept of "grease" (see
> draft-ietf-tls-grease), a practice of adding meaningless extension
> points to messages in the hope that it will reveal, and perhaps
> prevent, intolerance toward real extensions.  This is a practice we
> have seen deployed with some success in TLS.  That has produced some
> enthusiasm about the practice.  I think that it would be fair to say
> that the IAB maintains some reservations about the general
> applicability of the technique.
> 
> Are there protocols (in either specification or deployment) that have
> experimented with this sort of thing in the past?

This isn't exactly what you're describing, but https://tools.ietf.org/html/rfc7872 (Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World) seems relevant. IMHO, IPv6 extension headers are an *unintentional* form of chaff by their design.

Recent proposals for piggy-backed OAM options seem to be continue this. See draft-ioametal-ippm-6man-ioam-ipv6-options, draft-ioametal-ippm-6man-ioam-ipv6-deployment.
  "In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly
   enabled per interface on every node within the IOAM domain.  Unless a
   particular interface is explicitly enabled (i.e. explicitly
   configured) for IOAM, a router MUST drop packets which contain
   extension headers carrying IOAM data-fields."

Whoops, there's another limited domain protocol. All limited domain protocols become potential chaff outside their domain.

Apart from that, I wonder whether you don't need to dive into the history of formal OSI conformance testing to find examples. All I recall personally is a converse example: the anecdote of an OSI TP4 implementation that passed a conformance test with flying colours because whatever it received, it sent back a RESET, which according to the standard was allowed at any time. No doubt it would still have passed even in the presence of undefined extensions.

   Brian

> 
> The concept of fuzzing software isn't new (see
> https://en.wikipedia.org/wiki/Fuzzing) and testing for resilience to
> unusual behaviour is similarly well-established (e.g.,
> https://github.com/Netflix/chaosmonkey).  But are there cases of this
> in network protocols prior to its use in TLS?
> 
> Regards,
> Martin
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>