Re: [arch-d] Chaff in protocols

[Guntur Wiseno Putra <[e-mail]>]

Dear architecture-disxuss,

If it makes an interest:

The concept of "grease" mentioned in the earlier messages regarded with
situations of protocols --their possibilities, their directions/paths --in
relation with extensions, thus with changed systems.

In such a matter I find this paper proposed an initiative for situations of
protocols --which was about a practice having a potential to generate
additional value of systems already operating:



   1.

   arXiv:1011.5739 <https://arxiv.org/abs/1011.5739>

   cs.IT cs.NI

   Protocol Coding through Reordering of User Resources: Applications and
   Capacity Results

   Authors: Petar Popovski
   <https://arxiv.org/search/?searchtype=author&query=Popovski%2C+P>, Zoran
   Utkovski
   <https://arxiv.org/search/?searchtype=author&query=Utkovski%2C+Z>

   Abstract: While there are continuous efforts to introduce new
   communicationsystems and standards, it is legitimate to ask the
   question: how can one send additional bits by minimally changing the
   systems that are already operating? This is of a significant practical
   interest, since it has a potential to generate additional value of the
   systems through, for example, introduction of new devices and only a
   software update of the access points or base stations, without incurring
   additional cost for infrastructure hardware installation. The place to look
   for such an opportunity is the communication protocol and we use the term
   *protocol coding* to refer to strategies for sending information by using
   the degrees of freedom available when one needs to decide the actions taken
   by a particular communication protocol. In this paper we consider protocol
   coding that gives a rise to *secondary communication channels*, defined by
   combinatorial ordering of the user resources (packets, channels) in a
   primary (legacy) communication system...

   Submitted 1 February, 2012; v1 submitted 26 November, 2010; originally
   announced November 2010.

   Comments: Replaced with a two-part paper



Regard,
Guntur Wiseno Putra

Pada Minggu, 30 Juni 2019, Brian E Carpenter <[e-mail]>
menulis:

> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> >
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>