[arch-d] Chaff in protocols

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

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

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