Re: [Dots] New Version Notification for draft-francois-ipv6-dots-signal-option-00.txt

Hi, 
Thanks for the feedback. Comments inline: 

IPv6 Extensions Headers, themselves, are often rate-limited or dropped entirely, reference 
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops 
https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-in-real-world 
http://www.iepg.org/2014-03-02-ietf89/fgont-iepg-ietf89-eh-update.pdf 

Thanks for the references, we will go through them and clarify this issue in the draft. 

<blockquote>

While there might be agreement to not drop such packets over a link or over an ISP access network, some DOTS deployment models have the DOTS server on the Internet (e.g., cloud-based DDoS mitigation) where such agreements don't (can't) exist. 

</blockquote>

If the DOTS server (or a Relay) and client are located in the same administrative domain, piggybacking the proposed option in the packets could be done in a straight forward way, while considering that an agreement exists to avoid dropping or rate limiting of IPv6 extension headers. However, yes it becomes more difficult when the server is on the Internet. Such deployment model needs more thought. 
We will clarify and discuss the different deployment models when updating the draft. 

<blockquote>

While using v6 for this sort of piggybacked DOTS message is admirable, it is limited to networks where the DOTS client, DOTS server, intervening network, and user traffic (on which to piggyback) are all using IPv6 during the attack. 

</blockquote>

We mainly consider that an IPv6 traffic exists during the attack (it could be any type of IPv6 packets since the proposed mechanism is opportunistic) to be able to make use of the proposed piggybacking mechanism. 

<blockquote>

Finally, such piggybacked messages seem difficult to authenticate. 

</blockquote>

We are also looking to this issue to make use of an authentication token in the piggybacked option. We will detail and make a proposition to tackle this issue. 

Best, 

<blockquote>

-d 

<blockquote>

Thanks, 
Jérôme 

-------- Message transféré -------- Sujet : 	New Version Notification for draft-francois-ipv6-dots-signal-option-00.txt 
Date : 	Mon, 21 Mar 2016 10:55:51 -0700 
De : 	internet-drafts@ietf.org 
Pour : 	Jerome Francois <jerome.francois@inria.fr> , Abdelkader Lahmadi <abdelkader.lahmadi@loria.fr> 

A new version of I-D, draft-francois-ipv6-dots-signal-option-00.txt
has been successfully submitted by Jerome Francois and posted to the
IETF repository.

Name:		draft-francois-ipv6-dots-signal-option
Revision:	00
Title:		IPv6 DOTS Signal Option
Document date:	2016-03-21
Group:		Individual Submission
Pages:		13
URL: https://www.ietf.org/internet-drafts/draft-francois-ipv6-dots-signal-option-00.txt Status: https://datatracker.ietf.org/doc/draft-francois-ipv6-dots-signal-option/ Htmlized: https://tools.ietf.org/html/draft-francois-ipv6-dots-signal-option-00 Abstract:
   This document describes a delivery mechanism based on the IPv6 Hop-
   by-Hop options extension header type to carry a DOTS client signal
   message over a congested network due to a DDoS attack. The specified
   mechanism allows the DOTS client signal message to be included using
   an opportunistic way in outgoing IPv6 packets traveling then through
   the network to reach a DOTS server or relay.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org .

The IETF Secretariat 

_______________________________________________ 
Dots mailing list 
Dots@ietf.org 
https://www.ietf.org/mailman/listinfo/dots 

</blockquote>

</blockquote>