Re: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Tue, May 07, 2019 at 12:42:45PM +0000, Konda, Tirumaleswar Reddy wrote:
> > -----Original Message-----
> > From: Dots <[e-mail]> On Behalf Of Benjamin Kaduk
> > Sent: Monday, May 6, 2019 10:21 PM
> > To: [e-mail]
> > Cc: [e-mail]; Adam Roach
> > <[e-mail]>; [e-mail]; Liang Xia
> > <[e-mail]>; The IESG <[e-mail]>; dots-
> > [e-mail]
> > Subject: Re: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31:
> > (with DISCUSS and COMMENT)
> > 
> > This email originated from outside of the organization. Do not click links or
> > open attachments unless you recognize the sender and know the content is
> > safe.
> > 
> > On Thu, May 02, 2019 at 09:12:01AM +0000,
> > [e-mail] wrote:
> > > Re-,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Adam Roach via Datatracker [mailto:[e-mail]] Envoyé :
> > > > jeudi 2 mai 2019 07:01 À : The IESG Cc :
> > > > [e-mail]; Liang Xia; dots-
> > > > [e-mail]; [e-mail]; [e-mail] Objet :
> > > > Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with
> > > > DISCUSS and COMMENT)
> > > >
> > > > Adam Roach has entered the following ballot position for
> > > > draft-ietf-dots-signal-channel-31: Discuss
> > > >
> > > > When responding, please keep the subject line intact and reply to
> > > > all email addresses included in the To and CC lines. (Feel free to
> > > > cut this introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to
> > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/
> > > >
> > > >
> > > >
> > > > --------------------------------------------------------------------
> > > > --
> > > > DISCUSS:
> > > > --------------------------------------------------------------------
> > > > --
> > > >
> > > > Thanks for all the work everyone put into this document. I think
> > > > it's great to have a solution defined for automating these kinds of
> > > > operations, and look forward to widespread deployment of this
> > > > technology. I do have a small number of comments that I think we
> > > > need to close on prior to publication, and a handful of other
> > > > suggestions of varying (but lesser) importance.
> > > >
> > > > --------------------------------------------------------------------
> > > > -------
> > > >
> > > > This is a discuss because the current document attempts to override
> > > > normative language in an external document.
> > > >
> > > > §4.3:
> > > >
> > > > >  In reference to Figure 4, the DOTS client sends two TCP SYNs and
> > > > > two  DTLS ClientHello messages at the same time over IPv6 and IPv4.
> > > >
> > > > This is problematic for the reason described in RFC 8305 §5 ("In
> > > > order to avoid unreasonable network load, connection attempts SHOULD
> > > > NOT be made simultaneously").
> > > >
> > >
> > > [Med] I would agree with you if the text in 8305 is using MUST NOT.
> > >
> > > It is completely fine to send requests sequentially when not attack is
> > ongoing, but if a connection is to be established during attack time (e.g.,
> > redirect), sending the requests simultaneously would be appropriate so that
> > an attack mitigation is placed as ASAP.
> > 
> > Violating a SHOULD NOT still requires some analysis and justification.
> > Blatantly violating it (i.e., a 4x factor rather than 2x) probably requires a
> > stronger justification still.
> 
> My understanding is RFC 8305 suggests SHOULD NOT because it will be used by endpoints, and if every endpoint initiates connection attempts simultaneously to every domain the end user visits, it would introduce network load. However for DOTS signal channel, connection attempts will only be initiated by DOTS client (typically co-located on the network security services like DDoS mitigator, firewall, IPS). I don't think unreasonable network load would be introduced by a really small number of DOTS clients making connection attempts to the DOTS server. 

Perhaps, but if everyone thinks that their protocol is a "special
exception", we still end up in a bad place.  So I'd like to hear more from
Adam/Mirja/etc. on this.  (Well, or maybe on Suresh's ballot thread, where
Med already put some good discussion in.)

> > 
> > >
> > > > To be clear, my discuss is only on the fact that this document
> > > > violates a normative statement in RFC 8305. The following comments
> > > > are merely my thoughts on the best way to resolve this issue.
> > > >
> > > > It's also worth noting that RFC 8305 is geared towards getting users
> > > > the fastest possible response to a user action, while the text in
> > > > DOTS implies that the selection of the "most preferred" connection
> > > > is significantly more important
> > >
> > > [Med] Yes.
> > >
> > > > (e.g., it talks about migrating from TCP to UDP, and performing
> > > > periodic checks to enable such a migration). This factor, combined
> > > > with the fact that this is not a transaction that involves user
> > > > interactivity requirements, would seem to increase, rather than
> > > > decrease, the desire to space out checks across the various
> > > > transport/address-family pairs.
> > > >
> > > > My strong recommendation would be remove the specific description of
> > >
> > > [Med] This is not that straightforward because of specifics to the DOTS case,
> > e.g., probing, caching, no need to cancel other connections if a first one wins,
> > etc.
> > >
> > > > happy-eyeballs-like behavior from this document, and to instead
> > > > defer all such specification to the text in RFC 8305. I would
> > > > further recommend specification of a "Connection Attempt Delay" (as
> > > > that term is defined in RFC 8305) that is substantially larger than
> > > > those used for interactive connections: something on the order of 2
> > > > to 5 seconds would be my suggestion.
> > > >
> > > > Of course, be sure to adjust the example to match the specified handling.
> > > >
> > > >
> > > > --------------------------------------------------------------------
> > > > -------
> > > >
> > > > This is a discuss because it impacts interoperability.
> > > >
> > > > §4.4.1:
> > > >
> > > > >  target-uri:   A list of Uniform Resource Identifiers (URIs) [RFC3986]
> > > > >     identifying resources under attack.
> > > >
> > > > This definition needs to be clearer about what parts of the URI are
> > > > used for what purposes.
> > >
> > > [Med] The text does not define any restriction. All parts may be included..
> > >
> > > The text focuses on the host part as this is sensitive:
> > >
> > >       The same validation checks used for 'target-fqdn' MUST be followed
> > >       by DOTS servers to validate a target URI.
> > >
> > > How other parts are used is trivial, IMO.
> > 
> > If we call out one part for special handling, we should at least mention that
> > the other parts can still be used.
> 
> We can add the following the line:
> The IP addresses to which DNS domain name portion of URI resolves represent the scope of the mitigation. The mitigation technique used by the DDoS mitigation provider based on the URI is implementation specific (e.g. Puzzles, Reverse Turning tests etc.). 

I don't think this is really helping.  Recall that the URI has five
components: scheme, authority (user/host/port), path, query, and fragment.
The current (-31) text is talking about the host part of the authority
component, but I think Adam is noting that the scheme (both in the form of
the target-protocol and the scheme's default port), and the port part of
the authority component, are also potentially of use in identifying the
attack target we're trying to mitigate.  In this sense, we could consider
target-uri as a shorthand for all three of target-protocol, target-fqdn,
and target-port-range, but since the -31 text only makes a connection to
target-fqdn, the reader is left unclear about whether we should or should
not be able to use target-uri to cover the target-protocol and
target-port-range attributes.

-Ben