Re: [arch-d] Chaff in protocols

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

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 <[e-mail]> menulis:

> 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
>>
>