Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (1st Part)

From: <[email-masked]>
Date: Wed, 16 Jan 2019 07:59:53 +0000

Hi Ben, 

Thank you for the detailed review.

Please see inline a first set of replies. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : mercredi 16 janvier 2019 01:14
> À : [email-masked]
> Cc : [email-masked]
> Objet : AD review of draft-ietf-dots-signal-channel-25
> 
> AD review of -25.  (Note that -26 is out already, but to preserve my
> sanity I am still using the section numbers from the -25.  I took a
> quick look at the diff, and tried to remove comments that are no longer
> applicable, but probably missed some.
> 
> This review is pretty long, but I think the document is actually in
> pretty good shape -- the length of review comments is just a normal
> frequency of rough edges multiplied by a long document.
> 
> I will make a github pull request with some changes that I think are
> just editorial (but feel free to bring them up as discussion items if
> you are not sure that they are editorial, disagree with the changes,
> etc.)
> 
> We should probably introduce (or avoid) the concept of "peace-time"
> (sometimes spelled without the hyphen) and perhaps the corresponding
> attack situation before using it.
> 

[Med] We do have two occurrences in the document. I fixed these two. 

> Section 1
> 
> I wasn't sure whether the RFC 4987 reference was supposed to be for what
> an ACK-flood is or the fact that it is CPU-exhausting or something else.
> (Searching for those terms in its text did not help me come to a
> conclusion.)
> 

[Med] RFC 4987 is a pointer to back that SYN flood is memory exhausting. I move the citation right after SYN-flood. 

> We also talk about "DOTS servers" and "DOTS agents" in Section 1, before
> we've defined the terminology.  But these two are sufficiently
> self-explanatory that it may be fine to leave them as-is.
> 

[Med] You are right. I don't think a change is needed. 

>                                                  This protocol enables
>    cooperation between DOTS agents to permit a highly-automated network
>    defense that is robust, reliable, and secure.
> 
> We should explain somewhere what we mean by "secure".  (I guess, that
> the signal and data channels are integrity- and
> confidentiality-protected, and that changes in mitigation status are not
> made unless properly authorized.)
> 

[Med] By secure, we meant the set of features called in Section 2.4 of draft-ietf-dots-requirements. We can add a pointer to that section if this helps. 

> Section 3
> 
>             DOTS clients MAY alternatively support means to dynamically
>    discover the ports used by their DOTS servers.  [...]
> 
> If we have some examples in mind of dynamic discovery protocols, it
> would be appropriate to provide informative references here.
> 

[Med] OK. I added an informative reference to draft-boucadair-dots-discovery. 

> We should also have an informative reference for "Happy Eyeballs" (e.g.,
> RFC 8305).
> 

[Med] That text points to the section defining HE:

A Happy Eyeballs procedure for DOTS signal channel is
   specified in Section 4.3.

8305 is cited in section 4.3:

   To overcome these connection setup problems, the DOTS client attempts
   to connect to its DOTS server(s) using both IPv6 and IPv4, and tries
   both DTLS over UDP and TLS over TCP in a manner similar to the Happy
   Eyeballs mechanism [RFC8305].

This is sufficient, IMO.  

>    From that standpoint, this document specifies a YANG module for
>    representing DOTS mitigation scopes, DOTS signal channel session
>    [...]
> 
> Which standpoint?

[Med] that is "use the same data models...". 

I deleted the "From that standpoint," because this may not be clear. 

> 
>    Representing these data as CBOR data is assumed to follow the rules
>    in [I-D.ietf-core-yang-cbor] or those in [RFC7951] combined with
>    JSON/CBOR conversion rules in [RFC7049].  All parameters in the
>    payload of the DOTS signal channel are mapped to CBOR types as
>    specified in Section 6.
> 
> How do I know which set of rules is in use? 

[Med] This s not important from a DOTS interoperability standpoint. What is important is the mapping table in Section 6 (and mapping entries that will defined in future documents). 

 Are the two sets of rules
> equivalent and interoperable?
> 
>    DOTS agents MUST support GET, PUT, and DELETE CoAP methods.  [...]
> 
> As written, this applies to all agents (clients, servers, and proxies).
> Presumably this is intended,

[Med] Yes. 

 but I just wante to double-check --
> sometimes it's okay to place weaker requirements on clients.
> 
>    In deployments where one or more translators (e.g., Traditional NAT
>    [RFC3022], CGN [RFC6888], NAT64 [RFC6146], NPTv6 [RFC6296]) are
>    enabled between the client's network and the DOTS server, DOTS signal
>    channel messages forwarded to a DOTS server MUST NOT include internal
>    IP addresses/prefixes and/or port numbers; external addresses/
>    prefixes and/or port numbers as assigned by the translator MUST be
> 
> Do we want to give any examples of signal channel messages that might
> include internal addresses/prefixes?

[Med] I'd avoid citing a message which is not defined yet at this stage of the document. 

> 
>    Such procedure is needed to avoid experiencing long connection
>    delays.  For example, if an IPv4 path to reach a DOTS server is
>    found, but the DOTS server's IPv6 path is not working, a dual-stack
>    DOTS client may experience a significant connection delay compared to
>    an IPv4-only DOTS client.  [...]
> 
> There seems a bit of a mismatch between "found" and "not working".  If
> the point is supposed to be that the client is going to try both IPv4
> and IPv6 but the v6 path has issues and it would take the client's
> algorithm some extra time to choose to fall back to v4, then maybe "iv
> an IPv4 path to a DOTS server is functional and there is also an
> apparently present but non-functional IPv6 path to the same server"?

[Med] You got it. I changed the text to: 

"if an IPv4 path to reach a DOTS server is functional, but the DOTS server's IPv6 path is non-functional,"

> 
>                                   These connection attempts are
>    performed by the DOTS client when it initializes.  The results of the
>    Happy Eyeballs procedure are used by the DOTS client for sending its
>    subsequent messages to the DOTS server.
> 
> I see this is scoped to "when the client initializes", so I don't know
> whether it adds more or not to end with "for the duration of the DOTS
> session" or some similar scoping for the caching of the happy eyeballs
> results.

[Med] The connection attempts are performed each time the client has to select among a list of v4, v6 (tls, dtls). This is particularly true when the client initiates, but this may also be true each time the client has to select among v4, v6, DTLS, TLS (e.g., the client attaches to a new network). 

I updated the text to: 

"These connection attempts are performed by the DOTS client when it initializes, or in general when it has to select an address family and transport to contact its DOTS server."

> 
>    client because there is no long delay before using IPv4 and TCP.  The
>    DOTS client repeats the mechanism to discover whether DOTS signal
>    channel messages with DTLS over UDP becomes available from the DOTS
>    server, so the DOTS client can migrate the DOTS signal channel from
> 
> What would cause UDP to "become available"?

[Med] In this example, this is assumed to be IPv6 path (with no middlebox) available again. 

In general, this can be due to a path change, network configuration change, middlebox configuration change, IPv6 become functional, etc. 

  Would this be a case like
> if there's a stateful NAT or where we need to actively apply some sort
> of NAT traversal?  If so, do we want to list it as an example?  (If it's
> a complicated scenario, it may not be worth listing an example, of
> course.)

[Med] The text already says the following: 

"it is assumed that the IPv6 path is broken and UDP traffic is dropped by a middlebox"

I do think this is sufficient. 

> 
> I'm not sure if we want to add some annotations to Figure 4 that (e.g.)
> the initial DTLS attempts do not need to be strictly ordered in the
> order presented, or to indicate which lines are retries.

[Med] The text explaining that figure mentions the following: "...two TCP SYNs and two DTLS ClientHello messages at the same time over IPv6 and IPv4."

Adding annotation would be redundant, IMO.

[SNIP]

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 16 Jan 2019 11:10:37 +0000

Hi Med,

Please see inline

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Wednesday, January 16, 2019 1:30 PM
> To: Benjamin Kaduk <[email-masked]>; draft-ietf-dots-signal-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (1st Part)
> 
> 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.
> 
> Hi Ben,
> 
> > De : Benjamin Kaduk [mailto:[email-masked]] Envoyé : mercredi 16
> > janvier 2019 01:14 À : [email-masked]
> > Cc : [email-masked]
> > quick look at the diff, and tried to remove comments that are no
> > longer applicable, but probably missed some.
> >
> > I wasn't sure whether the RFC 4987 reference was supposed to be for
> > what an ACK-flood is or the fact that it is CPU-exhausting or something else.
> > We also talk about "DOTS servers" and "DOTS agents" in Section 1,
> > before we've defined the terminology.  But these two are sufficiently
> > confidentiality-protected, and that changes in mitigation status are
> > not made unless properly authorized.)
> >
> 
> [Med] By secure, we meant the set of features called in Section 2.4 of draft-
> ietf-dots-requirements. We can add a pointer to that section if this helps.
> 
> > Section 3
> >
> > We should also have an informative reference for "Happy Eyeballs"
> > (e.g., RFC 8305).
> >
> 
> [Med] This s not important from a DOTS interoperability standpoint. What is
> important is the mapping table in Section 6 (and mapping entries that will
> defined in future documents).
> 
> [Med] The connection attempts are performed each time the client has to
> select among a list of v4, v6 (tls, dtls). This is particularly true when the client
> initiates, but this may also be true each time the client has to select among
> v4, v6, DTLS, TLS (e.g., the client attaches to a new network).
> 
> I updated the text to:
> 
> "These connection attempts are performed by the DOTS client when it
> initializes, or in general when it has to select an address family and transport
> to contact its DOTS server."

Happy eyeballs mandates caching the results, see https://tools.ietf.org/html/rfc6555#section-4 (to avoid thrashing the network).
We may want to update the above line accordingly. 

Cheers,
-Tiru

> In general, this can be due to a path change, network configuration change,
> middlebox configuration change, IPv6 become functional, etc.
> 
> > of NAT traversal?  If so, do we want to list it as an example?  (If
> > it's a complicated scenario, it may not be worth listing an example,
> > of
> > course.)
> 
> > I'm not sure if we want to add some annotations to Figure 4 that
> > (e.g.) the initial DTLS attempts do not need to be strictly ordered in
> > the order presented, or to indicate which lines are retries.
> 
> [Med] The text explaining that figure mentions the following: "...two TCP
> SYNs and two DTLS ClientHello messages at the same time over IPv6 and
> IPv4."
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Jan 2019 11:43:44 -0600

Trying to get both Tiru and Med's comments, inline...

> > [Med] We do have two occurrences in the document. I fixed these two.

Thanks.  I guess my more meta-point was whether we expect the audience to
be familiar with the usage of "peacetime" for "absence of a DoS attack" --
I personally found it slightly jarring, but I'm also not exactly the target
audience.

> > move the citation right after SYN-flood.

Ah, that makes perfect sense; thanks.

> > ietf-dots-requirements. We can add a pointer to that section if this helps.

It's probably worth doing.

> >    Eyeballs mechanism [RFC8305].

So it is.  Sorry to have missed that before.

> > I deleted the "From that standpoint," because this may not be clear.

Sounds good.

> > > equivalent and interoperable?

So the claim is that following either set of rules will result in the same
(well, equivalent) encoding, based on the relevant CBOR types?  If so, this
text could probably be reworded to just use declarative language instead of
"is assumed to", maybe something like "are encoded in CBOR; the procedures
in [] or [] will produce a valid encoding", though I don't have a great
concrete suggestion off the top of my head.

> > [Med] I'd avoid citing a message which is not defined yet at this stage of the

Okay.

> We may want to update the above line accordingly. 

We probably do, perhaps by qualifying the decision as being one made when
conditions have changed in some way since the last decision (and some
amount of timeout could be considered a "change").

> > middlebox configuration change, IPv6 become functional, etc.

I think I would have been less confused if we said "periodically repeats".

> > I do think this is sufficient.

It's probably fine, yes.  I was just wondering if there would be scenarios
where the situation would be improved if a DOTS agent applied active
NAT-busting; if so, we would then need to decide whether the benefits were
large enough and the situation common enough to merit a mention.  (It
sounds like we think it is not common enough to mention, which is fine.)

> > Adding annotation would be redundant, IMO.

It's often helpful for the figure to stand alone, but I'm happy to wait and
see if anyone else asks for a change.

-Ben

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 07:02:55 +0000

Hi Tiru, 

As you know RFC8305 obsoletes RFC6555. 

I fail to see where caching results is mentioned in 8305. Do you?

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : mercredi 16 janvier 2019 12:11
> À : BOUCADAIR Mohamed TGI/OLN; Benjamin Kaduk; draft-ietf-dots-signal-
> [email-masked]
> Cc : [email-masked]
> Objet : RE: AD review of draft-ietf-dots-signal-channel-25 (1st Part)
> 
> Hi Med,
> 
> Please see inline
> 
> Happy eyeballs mandates caching the results, see
> https://tools.ietf.org/html/rfc6555#section-4 (to avoid thrashing the
> network).

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 17 Jan 2019 07:16:05 +0000

> From: [email-masked]
> <[email-masked]>
> Sent: Thursday, January 17, 2019 12:33 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Benjamin Kaduk <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: RE: AD review of draft-ietf-dots-signal-channel-25 (1st Part)
> 
> 
> 
> Hi Tiru,
> 

Though RFC8035 obsoletes RFC6555, it is still compatible with RFC6555 (see https://tools.ietf.org/html/rfc8305#appendix-A). 
It is useful to cache the happy eyeball results for a specific time.

-Tiru

> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > Envoyé : mercredi 16 janvier 2019 12:11 À : BOUCADAIR Mohamed TGI/OLN;
> > Benjamin Kaduk; draft-ietf-dots-signal- [email-masked] Cc :
> > [email-masked] Objet : RE: AD review of
> > draft-ietf-dots-signal-channel-25 (1st Part)
> >
> > Hi Med,
> >
> > Please see inline
> >
> > > Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25
> > > (1st
> > Part)
> > >
> > > >
> > > > I see this is scoped to "when the client initializes", so I don't
> > > > know whether it adds more or not to end with "for the duration of
> > > > the DOTS session" or some similar scoping for the caching of the
> > > > happy eyeballs results.
> > >
> > > [Med] The connection attempts are performed each time the client has
> > > to select among a list of v4, v6 (tls, dtls). This is particularly
> > > true when
> > the client
> > > initiates, but this may also be true each time the client has to
> > > select
> > among
> > > initializes, or in general when it has to select an address family
> > > and
> > transport

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 07:38:45 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 16 janvier 2019 18:44
> À : Konda, Tirumaleswar Reddy
> Cc : BOUCADAIR Mohamed TGI/OLN; [email-masked];
> [email-masked]
> Objet : Re: AD review of draft-ietf-dots-signal-channel-25 (1st Part)
> 
> > > [Med] RFC 4987 is a pointer to back that SYN flood is memory exhausting.
> I
> > > move the citation right after SYN-flood.
> 

[Med] Done.

> concrete suggestion off the top of my head.

[Med] What about the following:

   This document specifies a YANG module for representing DOTS
   mitigation scopes, DOTS signal channel session configuration data,
   and DOTS redirected signalling (Section 5).  Representing these data
   as CBOR data can either follow the rules in [I-D.ietf-core-yang-cbor]
   or those in [RFC7951] combined with JSON/CBOR conversion rules in
   [RFC7049]; both approaches produce a valid encoding.  All parameters
   in the payload of the DOTS signal channel are mapped to CBOR types as
   specified in Section 6.

> > > [Med] I'd avoid citing a message which is not defined yet at this stage
> of the
> > > document.
> 
> Okay.
> 
> > > >
> > > "if an IPv4 path to reach a DOTS server is functional, but the DOTS
> server's
> > > IPv6 path is non-functional,"
> > >
> > > >
> > > [Med] In this example, this is assumed to be IPv6 path (with no
> middlebox)
> > > available again.
> > >

[Med] Fixed.

> > > "it is assumed that the IPv6 path is broken and UDP traffic is dropped by
> a
> > > middlebox"
> > >

[Med] Thanks.

---

From: <[email-masked]>
Date: Thu, 17 Jan 2019 07:46:16 +0000

Re-,

OK. 

Given that we don't have an explicit mention about this in 8305, I added this NEW sentence echoing what was in 6555:

   Note that the DOTS client must cache information regarding the
   outcome of each connection attempt, and it uses that information to
   avoid thrashing the network with subsequent attempts.

Cheers,
Med

> Envoyé : jeudi 17 janvier 2019 08:16
> Though RFC8035 obsoletes RFC6555, it is still compatible with RFC6555 (see
> https://tools.ietf.org/html/rfc8305#appendix-A).

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 17 Jan 2019 09:33:23 +0000

> Sent: Thursday, January 17, 2019 1:16 PM

Minor change:

Note that the DOTS client must cache information regarding the
outcome of each connection attempt for a specific time period (e.g. 10 minutes), and it uses that information to
avoid thrashing the network with subsequent attempts.

-Tiru

> > [email-masked] Cc : [email-masked] Objet : RE: AD review of
> > Though RFC8035 obsoletes RFC6555, it is still compatible with RFC6555
> > (see https://tools.ietf.org/html/rfc8305#appendix-A).
> > > > Envoyé : mercredi 16 janvier 2019 12:11 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Benjamin Kaduk; draft-ietf-dots-signal- [email-masked] Cc :
> > > > > Subject: Re: [Dots] AD review of
> > > > > >    performed by the DOTS client when it initializes.  The
> > > > > > results of
> > the
> > > > > >    Happy Eyeballs procedure are used by the DOTS client for
> > > > > > sending
> > its
> > > > > > I see this is scoped to "when the client initializes", so I
> > > > > > don't know whether it adds more or not to end with "for the
> > > > > > duration of the DOTS session" or some similar scoping for the
> > > > > > caching of the happy eyeballs results.
> > > > >
> > > > > [Med] The connection attempts are performed each time the client
> > > > > has to select among a list of v4, v6 (tls, dtls). This is
> > > > > particularly true when
> > > > the client
> > > > > "These connection attempts are performed by the DOTS client when
> > > > > it initializes, or in general when it has to select an address
> > > > > family and
> > > > transport
> > > > https://tools.ietf.org/html/rfc6555#section-4 (to avoid thrashing
> > > > the network).

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 17 Jan 2019 10:08:38 -0000

> From: Dots [mailto: [email-masked]] On Behalf Of Konda,
> Tirumaleswar Reddy
> Sent: 17 January 2019 09:33
> To: [email-masked]; Benjamin Kaduk; draft-ietf-dots-signal-
> [email-masked]
> Cc: [email-masked]
> > Given that we don't have an explicit mention about this in 8305, I added
> this
> > NEW sentence echoing what was in 6555:
> >
> outcome of each connection attempt for a specific time period (e.g. 10
> minutes), and it uses that information to

How frequently should the client retry when all 4 connection methods fail - 10 minutes is excessive to me?

~Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 17 Jan 2019 10:32:11 +0000

> From: Dots <[email-masked]> On Behalf Of Jon Shallow
> Sent: Thursday, January 17, 2019 3:39 PM
> [email-masked]; [email-masked]; 'Benjamin Kaduk'
> <[email-masked]>; [email-masked]
> > To: [email-masked]; Benjamin Kaduk;
> > draft-ietf-dots-signal- [email-masked]
> > Cc: [email-masked]
> > (1st Part)
> > > (1st Part)
> > > 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.
> > >
> > > Re-,
> > >
> > > OK.
> > >
> > Note that the DOTS client must cache information regarding the outcome
> > of each connection attempt for a specific time period (e.g. 10
> > minutes), and it uses that information to avoid thrashing the network
> > with subsequent attempts.
> 

10 minute change is for successful outcome only.

-Tiru

> > > > Envoyé : jeudi 17 janvier 2019 08:16 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Benjamin Kaduk; draft-ietf-dots-signal- [email-masked]
> > > > Cc : [email-masked] Objet : RE: AD review of
> > > > Though RFC8035 obsoletes RFC6555, it is still compatible with
> > > > RFC6555 (see https://tools.ietf.org/html/rfc8305#appendix-A).
> > > > > > > >    Happy Eyeballs procedure are used by the DOTS client
> > > > > > > > for sending
> > > > its
> > > > > > > > I see this is scoped to "when the client initializes", so
> > > > > > > > I don't know whether it adds more or not to end with "for
> > > > > > > > the duration of the DOTS session" or some similar scoping
> > > > > > > > for the caching of the happy eyeballs results.
> > > > > > >
> > > > > > > [Med] The connection attempts are performed each time the
> > > > > > > client has to select among a list of v4, v6 (tls, dtls).
> > > > > > > This is particularly true when
> > > > > > the client
> > > > > > > initiates, but this may also be true each time the client
> > > > > > > has to select
> > > > > > among
> > > > > > > "These connection attempts are performed by the DOTS client
> > > > > > > when it initializes, or in general when it has to select an
> > > > > > > address family and
> > > > > > transport
> > > > > > https://tools.ietf.org/html/rfc6555#section-4 (to avoid
> > > > > > thrashing the network).

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Jan 2019 13:42:11 -0600

> avoid thrashing the network with subsequent attempts.

We'll probably get somebody asking why it's not  a "MUST", but that's not
enough to hold up the IETF LC.

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 19 Jan 2019 02:47:29 +0000

> From: Benjamin Kaduk <[email-masked]>
> Sent: Saturday, January 19, 2019 1:12 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: AD review of draft-ietf-dots-signal-channel-25 (1st Part)
> 
> 
> 
> > > Given that we don't have an explicit mention about this in 8305, I
> > > added this NEW sentence echoing what was in 6555:
> > >
> > minutes), and it uses that information to avoid thrashing the network with
> subsequent attempts.
> 

Yes, will fix.

-Tiru