Re: Feedback on the use of Hop-by-Hop options extension header (draft-francois-dots-ipv6-signal-option-01)

On 8 Feb. 2017 20:18, "Jérôme François" <jerome.francois@inria.fr> wrote:

Dear all,

We are working on a DOTS draft about using the Hop-by-Hop option header
to encapsulated DDoS signaling  within network to enabel a kind of
epidemic propagation
(https://tools.ietf.org/html/draft-francois-dots-ipv6-signal-option-01)

Some comments have been raised considering the real use of the
Hop-by-Hop option. We would like to ask you your feedback about using it
for very specific signaling among trusted parties. In particular, do you
know any reference to a particular use of Hop-by-Hop in a real case.

We have also followed the mailing list discussion about header insertion,
which obviously concerns our approach since we are extracting and inserting
some info in headers on the paths. Even if this is is limited to specific
routers in a single domain,

The only place it will be guaranteed to be limited to a single domain is
the specification. It is not possible to make and rely on that guarantee in
implementations, as implementations can be imperfect.

If the packet leaks out of the insertion domain, the inserter won't know
it, because they'll suffer no, no obvious and/or no immediate consequences,
and the receiver who does suffer consequences with have no ability to
easily identify who inserted the EH or even if one was added by an
intermediary while the packet was in flight.

we understand that it can create problems and
should maybe use packet encapsulation.

That would be best. It clearly delineates between what was the original
packet and what was added, and adds another set of source and destination
addresses that identify what domain/device added the information, and what
destination device within that domain that  the added information was
intended for.

Encapsulation has a higher per-packet overhead, however it provides
attribution of the addition and prevents misinterpretation of the
additional information if it gets sent somewhere it shouldn't (an
encapsulated packet leaking out of an encapsulation domain should be sent
back towards it because of the encapsulation destination address, or will
be dropped because the encapsulation destination address is unreachable
outside the domain.)

Regards,
Mark.

Best regards,

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------