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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Tuesday, May 7, 2019 9:52 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>
> Cc: [e-mail]; draft-ietf-dots-signal-
> [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)
> 
> 
> 
> 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.  

I don't get the problem. For example, https://tools.ietf.org/html/rfc8421 does not use the timing recommendations in RFC8305, instead ICE pacing is used (default value of Ta is 5ms).

> 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.

Thanks for the clarification, will update text as follows:

The IP addresses to which DNS domain name portion of URI resolves represent the 'target-prefix', URI scheme represents the 'target-protocol', the port subcomponent of authority component represents the 'target-port'. If the optional port 
information is not present in the authority component,  the default port defined for the URI scheme represents the 'target-port'.

Cheers,
-Tiru

> 
> -Ben