Subject: Re: [arch-d] Chaff in protocols

From: Guntur Wiseno Putra <[email-masked]>
Date: Wed, 17 Jul 2019 13:31:33 +0700

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

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Sun, 21 Jul 2019 19:51:01 +0700

Dear architecture-discuss,

Forgive me if I missed things: the paper below supposedly planned a thing
more or less similar with the one I mentioned above --with different
nuances-- as it concerned with an analytical consideration on "Complex
Systems" and "Behaviors of Elements":

arXiv:nlin/0312026 <https://arxiv.org/abs/nlin/0312026>  [pdf
<https://arxiv.org/pdf/nlin/0312026>, ps <https://arxiv.org/ps/nlin/0312026>
, other <https://arxiv.org/format/nlin/0312026>]
nlin.AO cond-mat.dis-nn
doi10.1002/cplx.20045  <https://doi.org/10.1002/cplx.20045>

On the emergence of complexsystems on the basis of the coordination of
complex behaviors of their elements

Authors: Fatihcan M. Atay
<https://arxiv.org/search/?searchtype=author&query=Atay%2C+F+M>, Jürgen Jost
<https://arxiv.org/search/?searchtype=author&query=Jost%2C+J>

Abstract: We argue that the coordination of the activities of individual
complex agents enables a system to develop and sustain complexity at a
higher level. We exemplify relevant mechanisms through computersimulations
of a toy system, a coupled map lattice with transmission delays. The
coordination here is achieved through the synchronization of the chaotic
operationsof the individual elements, and on the basis of this, regular
behavior at a longer temporal scale emerges that is inaccessible to the
uncoupled individual dynamics.

Regard,
Guntur Wiseno Putra

Pada Rabu, 17 Juli 2019, Guntur Wiseno Putra <[email-masked]> menulis:

> 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

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Tue, 23 Jul 2019 12:32:14 +0700

Dear architectur-discuss,

To those papers I mentioned above --which were about "complex systems",
"behaviors of elements", and "protocol coding"--, this one seems to relate
closely as ut is about "complex system engineering":

arXiv:cs/0603127 <https://arxiv.org/abs/cs/0603127>  [pdf
<https://arxiv.org/pdf/cs/0603127>]

cs.MA

Complex Systems + SystemsEngineering = Complex SystemsEngineeri

Authors: Russ Abbott
<https://arxiv.org/search/?searchtype=author&query=Abbott%2C+R>

Abstract: One may define a complex system as asystem in which phenomena
emerge as a consequence of multiscale interaction among thesystem's components
and their environments. The field of Complex Systems is the study of such
systems--usually naturally occurring, either bio-logical or social.
Systems Engineering
may be understood to include the conceptualising and building of systems that
consist of a large number of concurrently operating and interacting
components--usually including both human and non-human elements. It has
become increasingly apparent that the kinds of systems that systemsengineers
build have many of the same multiscale characteristics as those of
naturally occurring complex systems. In other words, systemsengineering is
the engineering of complexsystems. This paper and the associated panel will
explore some of the connections between the fields of complex systems and
systemsengineering. △ Less

Regard,
Guntur Wiseno Putra

Pada Minggu, 21 Juli 2019, Guntur Wiseno Putra <[email-masked]> menulis:

> <https://arxiv.org/pdf/nlin/0312026>, ps
> <https://arxiv.org/ps/nlin/0312026>, other
> <https://arxiv.org/format/nlin/0312026>]
> nlin.AO cond-mat.dis-nn
> <https://arxiv.org/search/?searchtype=author&query=Atay%2C+F+M>, Jürgen
> Jost <https://arxiv.org/search/?searchtype=author&query=Jost%2C+J>
>
>>    Protocol Coding through Reordering of User Resources: Applications
>>    and Capacity Results
>>
>>    Authors: Petar Popovski
>>    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...
>>
>>> 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
>>>
>>> >