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

From: Jérôme François <[email-masked]>
Date: Wed, 08 Feb 2017 10:17:41 +0100

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, we understand that it can create problems and
should maybe use packet encapsulation.

Best regards,

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Feb 2017 00:29:40 +1100

On 8 Feb. 2017 20:18, "Jérôme François" <[email-masked]> wrote:

Dear all,

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
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2017 09:26:10 +1300

Jérôme,

I can't do better than what we wrote in RFC7045:

2.2.  Hop-by-Hop Options

   The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.  Designers
   planning to use a hop-by-hop option need to be aware of this likely
   behaviour.

   As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options
   header, if present, must be first.

If the HbH option type is 'may change en-route', you can rewrite its
contents, but you can't change its length. And as you have understood,
most people believe that RFC 2460 says you must not insert one.

Regards
   Brian

On 08/02/2017 22:17, Jérôme François wrote:
> .

---

From: Jérôme François <[email-masked]>
Date: Fri, 10 Feb 2017 23:35:34 +0100

Thanks Mark

Le 08/02/2017 14:29, Mark Smith a écrit :
>
>
> On 8 Feb. 2017 20:18, "Jérôme François" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     (https://tools.ietf.org/html/draft-francois-dots-ipv6-signal-option-01
>     <https://tools.ietf.org/html/draft-francois-dots-ipv6-signal-option-01>)
>
> 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.
> 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.
>
> 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
>     [email-masked] <mailto:[email-masked]>
>     Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 12 Feb 2017 21:32:10 +0000

Jérôme,

I am sure that you know about draft-brockners-inband-oam-transport-02.

The common sense dictates that a node should not act on a HbH extension header which cannot be trusted (obvious DoS) but I see no problem when a node SELECTIVELY and on purpose (as opposed to 'by default') acts on HbH extension headers. (I fully agree with Fred's expired draft-ietf-6man-hbh-header-handling-03)

Hope this helps

Bien à toi,

-éric

On 08/02/17 10:17, "ipv6 on behalf of Jérôme François" <[email-masked] on behalf of [email-masked]> wrote:

    Dear all,

    
    
    Best regards,

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 12 Feb 2017 21:32:36 +0000

Jérôme,

Hope this helps

Bien à toi,

-éric

    Dear all,

    
    
    Best regards,