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

Thanks Mark

Le 08/02/2017 14:29, Mark Smith a écrit :
>
>
> On 8 Feb. 2017 20:18, "Jérôme François" <jerome.francois@inria.fr
> <mailto: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
>     <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.
>
Our initial idea is to force that exit routers are in charge of removing
the EH to every leaving packets. Of course, this supposes that all of
them properly implements this process.
>
>     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.)
>
Is there a document or report which have evaluated the oevrhead precise
? In our context, the network already suffers from a DDoS attacks.
Adding overhead may amplify the problem but it is somehow a last chance
to inform the mitigator about the attack (whatever it will cost letting
the attack continuing is worst in terms of overhead).

Best regards,
jerome
> Regards,
> Mark.
>
>
>
>     Best regards,
>
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
>
>