Subject: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

From: <[email-masked]>
Date: Mon, 23 Oct 2017 12:28:05 +0000

Hi Jon, all, 

I agree with Flemming that "some more work" is needed. IMHO, this is a typical discussion to include in a dedicated section in the DOTS architecture I-D.

>From a requirement standpoint, we don't need to elaborate how the protocols will fulfil it. SIG-10 does even a nice job by citing RFC8085 which points to NAT traversal mechanisms. One could pick his/her favorite protocol from the list in 8085 to discover the external IP address/prefix, if needed. External IP addresses/prefixes can be IPv4 for a NAT44 or NAT64, but can be IPv6 prefixes for enterprises deploying NPTv6, and so on. 

In some deployments, DOTS clients may be provisioned with the set of internal resources, so there is no need for discovery. 

Also, as Jon mentioned, DOTS gateways can be of help to set the appropriate IP addresses/prefixes/port numbers in the presence of translators. 

An open question though would be to discuss if there is a value in having a feature in the DOTS protocol to inform a DOTS client that a NAT is detected on-path. This can be presented as an information element returned by the server to the client. This information can be, for example, used by the client to adjust its HT interval, adjust the internal IP addresses/prefixes to be protected, etc. Opinions?

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Jon Shallow
> Envoyé : lundi 23 octobre 2017 13:18
> À : 'Flemming Andreasen'; [email-masked]
> Objet : Re: [Dots] DOTS Requirements review (-06)
> 
> Hi Flemming,
> 
> The way my mind works is to think of a practical situation and see if
> things fit.
> 
> As I read SIG-010, there could be a DOTS client with a management IP
> address that is RFC1918 - this client could be monitoring Netflow
> information and can request mitigation for the appropriate public IPs that
> are being monitored.  So SIG-010 is needed for this use case.
> 
> It is the responsibility of the DOTS server as to whether it accepts a
> mitigation request for a particular target ip (or domain etc.) or not.
> 
> If there is going to be a NAT border where public IPs are mapped into
> private IPs (and vice versa), I would then expect there to be a DOTS
> gateway between these 2 zones, and it is the responsibility of the DOTS
> gateway to do any target-ip mappings.
> 
> Regards
> 
> Jon
> 
> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of
> Flemming Andreasen
> Sent: 22 October 2017 20:17
> To: dots; [email-masked]
> Subject: [Dots] DOTS Requirements review (-06)
> 
> Greetings
> 
> I have reviewed the latest version of the DOTS requirements draft
> (https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt). In general,
> I think the draft is in good shape with only a few edits required, so I
> hope we can move to WGLC soon. I have a few comments below (of which the
> NAT one is the only real substantial one). I have also submitted a pull
> request with a few nit fixes on GitHub:
> 
> 
> Section 1.2
> - The definition of "DOTS Signal" is slightly inconsistent with the
> respective "Client Signal" and "Server Signal" definitions.
> 
> SIG-005:
> - Not clear that always requiring "number of packets" metrics is
> meaningful. Consider TCP-based attacks for example. Number of bytes may
> always be ok - above and beyond that it should probably be extensible
> and/or attack dependent.
> - I don't think the requirements document should get into specifying timer
> values - expontial backoff with some maximum value seems about the right
> level of detail here.
> 
> SIG-009:
> - To be clear, the conflicts only apply within a single administrative
> domain, right ? For example, if a client tells the same domain to
> alternately turn on/off mitigation for a given prefix, route flapping may
> occur. The same concern does not apply if a client tells two different
> administrative domains to respective turn mitigation on (domain 1) and off
> (domain 2). If so, can we clarify that (also in lieu of some of the multi-
> homing comments raised previously) ?
> 
> SIG-010:
> - DOTS Client behind NAT. On one hand, it seems reasonable to have this
> requirement since clients for sure can be behind NATs, and with things
> like dynamic DNS, they can     certainly be reachable. However, if we do
> want to allow for this scenario, and in particular for the DOTS client to
> have a private IP-address (potentially behind multiple NATs), then we have
> more work to do because it won't do the DOTS server any good to get a
> mitigation request referring to that private IP-address (or prefix).
> 
> 
> Thanks
> 
> -- Flemming
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Oct 2017 11:35:49 -0400

> I agree with Flemming that "some more work" is needed. IMHO, this is a typical discussion to include in a dedicated section in the DOTS architecture I-D.
Agreed.
> >From a requirement standpoint, we don't need to elaborate how the protocols will fulfil it. SIG-10 does even a nice job by citing RFC8085 which points to NAT traversal mechanisms. One could pick h…
Part of the challenge here is that the attack target and the DOTS client 
are not necessarily one and the same, which makes it more difficult to 
determine the public-facing IP-address/port under attack (at least if 
the DOTS client is going to do it).
> Also, as Jon mentioned, DOTS gateways can be of help to set the appropriate IP addresses/prefixes/port numbers in the presence of translators.
Agreed - but they still need a way to figure out the private/public 
mapping for a given attack target.
> An open question though would be to discuss if there is a value in having a feature in the DOTS protocol to inform a DOTS client that a NAT is detected on-path. This can be presented as an informat…
It sounds appealing, but it's very difficult to do this reliably, and 
it's not just NATs that are an issue here; Firewalls present similar 
challenges (and they may or may not be NAT'ing individual flows).

-- Flemming

> .

---

From: <[email-masked]>
Date: Tue, 24 Oct 2017 08:50:18 +0000

Hi Flemming, all,

Please see inline. 

Cheers,
Med

> De : Flemming Andreasen [mailto:[email-masked]]
> Envoyé : lundi 23 octobre 2017 17:36
> À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
> Objet : Re: DOTS & NAT (was RE: [Dots] DOTS Requirements review (-06))
> 
> 
> 
> > I agree with Flemming that "some more work" is needed. IMHO, this is a
> typical discussion to include in a dedicated section in the DOTS
> architecture I-D.
> Agreed.
> > >From a requirement standpoint, we don't need to elaborate how the
> protocols will fulfil it. SIG-10 does even a nice job by citing RFC8085
> which points to NAT traversal mechanisms. One could pick his/her favorite
> protocol from the list in 8085 to discover the external IP address/prefix,
> if needed. External IP addresses/prefixes can be IPv4 for a NAT44 or
> NAT64, but can be IPv6 prefixes for enterprises deploying NPTv6, and so
> on.

[Med] This is exactly the kind of the discussion to have. Thanks. 

With or without NAT, DOTS clients are assumed to be fed with the internal target(s). This can be achieved by provisioning (likely) or by discovery means (e.g., residential or small enterprise networks). 

Can we assume that the discovery of the external IP address/prefix/.. is done by a DOTS client only if it is explicitly instructed to do so?

> > In some deployments, DOTS clients may be provisioned with the set of
> internal resources, so there is no need for discovery.
> >
> > Also, as Jon mentioned, DOTS gateways can be of help to set the
> appropriate IP addresses/prefixes/port numbers in the presence of
> translators.

[Med] Because a DDoS attack is observed from the internal network, mapping(s) are necessarily maintained by the on-path translator(s). Otherwise, the incoming attack traffic couldn't be forwarded to internal hosts. 
This model assumes that the gateway is collocated with the NAT. So, the gateway can replace the internal IP address/prefix with the one retrieves from the NAT mapping table. 

Do you see any issue with this scheme?

> > An open question though would be to discuss if there is a value in
> having a feature in the DOTS protocol to inform a DOTS client that a NAT
> is detected on-path. This can be presented as an information element
> returned by the server to the client. This information can be, for
> example, used by the client to adjust its HT interval, adjust the internal
> IP addresses/prefixes to be protected, etc. Opinions?

[Med] I fully agree that firewalls detect is more complex. Let's put it aside and focus on the NAT case. 

We can consider many approaches to detect a NAT, e.g., 

(1) The DOTS client inserts in the core message the IP address/port it uses to send the request to the DOTS server. Upon receipt of the request by the DOTS server, it checks if the enclosed IP address/port match the source IP address/port of the received packet. If yes, the server sets in the response a dedicated parameter to indicate that a translator is detected on-path.

(2) The DOTS server inserts systematically the source IP address/port in a response to a message from a DOTS client. Upon receipt of that response, the DOTS client compares the enclosed address/port with the ones it used to send the request to detect any mismatch.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 26 Oct 2017 07:44:03 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, October 24, 2017 2:20 PM
> To: Flemming Andreasen <[email-masked]>; Jon Shallow <supjps-
> [email-masked]>; [email-masked]
> Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))
> 
> Hi Flemming, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Flemming Andreasen [mailto:[email-masked]] Envoyé : lundi 23
> > octobre 2017 17:36 À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow;
> > [email-masked] Objet : Re: DOTS & NAT (was RE: [Dots] DOTS Requirements
> > review (-06))
> >
> >
> >
> > protocols will fulfil it. SIG-10 does even a nice job by citing
> > RFC8085 which points to NAT traversal mechanisms. One could pick
> > his/her favorite protocol from the list in 8085 to discover the
> > external IP address/prefix, if needed. External IP addresses/prefixes
> > can be IPv4 for a NAT44 or NAT64, but can be IPv6 prefixes for
> > enterprises deploying NPTv6, and so on.
> > Part of the challenge here is that the attack target and the DOTS
> > client are not necessarily one and the same, which makes it more
> > difficult to determine the public-facing IP-address/port under attack
> > (at least if the DOTS client is going to do it).
> 
> With or without NAT, DOTS clients are assumed to be fed with the internal
> target(s). This can be achieved by provisioning (likely) or by discovery means
> (e.g., residential or small enterprise networks).
> 
> Can we assume that the discovery of the external IP address/prefix/.. is done
> by a DOTS client only if it is explicitly instructed to do so?
> 
> 
> [Med] Because a DDoS attack is observed from the internal network,
> mapping(s) are necessarily maintained by the on-path translator(s).
> Otherwise, the incoming attack traffic couldn't be forwarded to internal hosts.
> This model assumes that the gateway is collocated with the NAT. So, the
> gateway can replace the internal IP address/prefix with the one retrieves
> from the NAT mapping table.
> 
> > having a feature in the DOTS protocol to inform a DOTS client that a
> > NAT is detected on-path. This can be presented as an information
> > element returned by the server to the client. This information can be,
> > for example, used by the client to adjust its HT interval, adjust the
> > internal IP addresses/prefixes to be protected, etc. Opinions?

The presence and behavior of NAT and Firewall, and keepalive interval can be determined using STUN (discussed in https://tools.ietf.org/html/rfc5780). 

-Tiru

> (1) The DOTS client inserts in the core message the IP address/port it uses to
> send the request to the DOTS server. Upon receipt of the request by the
> DOTS server, it checks if the enclosed IP address/port match the source IP
> address/port of the received packet. If yes, the server sets in the response a
> dedicated parameter to indicate that a translator is detected on-path.
> 
> (2) The DOTS server inserts systematically the source IP address/port in a
> response to a message from a DOTS client. Upon receipt of that response,
> the DOTS client compares the enclosed address/port with the ones it used to
> send the request to detect any mismatch.
> 
> 
> > -- Flemming
> >
> >
> > > Cheers,
> > > Med
> > >
> > >> Envoyé : lundi 23 octobre 2017 13:18 À : 'Flemming Andreasen';
> > >> [email-masked] Objet : Re: [Dots] DOTS Requirements review (-06)
> > >>
> > >> Hi Flemming,
> > >>
> > >> The way my mind works is to think of a practical situation and see
> > >> if things fit.
> > >>
> > >> As I read SIG-010, there could be a DOTS client with a management
> > >> IP address that is RFC1918 - this client could be monitoring
> > >> Netflow information and can request mitigation for the appropriate
> > >> public IPs
> > that
> > >> It is the responsibility of the DOTS server as to whether it
> > >> accepts a mitigation request for a particular target ip (or domain etc.) or
> not.
> > >>
> > >> If there is going to be a NAT border where public IPs are mapped
> > >> into private IPs (and vice versa), I would then expect there to be
> > >> a DOTS gateway between these 2 zones, and it is the responsibility
> > >> of the DOTS gateway to do any target-ip mappings.
> > >>
> > >> Regards
> > >>
> > >> Jon
> > >>
> > >> I think the draft is in good shape with only a few edits required,
> > >> so I hope we can move to WGLC soon. I have a few comments below (of
> > >> which
> > the
> > >> NAT one is the only real substantial one). I have also submitted a
> > >> pull request with a few nit fixes on GitHub:
> > >>
> > >>
> > >> Section 1.2
> > >> meaningful. Consider TCP-based attacks for example. Number of bytes
> > >> may always be ok - above and beyond that it should probably be
> > >> extensible and/or attack dependent.
> > >> - I don't think the requirements document should get into
> > >> specifying
> > timer
> > >> - To be clear, the conflicts only apply within a single
> > >> administrative domain, right ? For example, if a client tells the
> > >> same domain to alternately turn on/off mitigation for a given
> > >> prefix, route flapping
> > may
> > >> occur. The same concern does not apply if a client tells two
> > >> different administrative domains to respective turn mitigation on
> > >> (domain 1) and
> > off
> > >> - DOTS Client behind NAT. On one hand, it seems reasonable to have
> > >> this requirement since clients for sure can be behind NATs, and with
> things
> > >> want to allow for this scenario, and in particular for the DOTS
> > >> client
> > to
> > >> have a private IP-address (potentially behind multiple NATs), then
> > >> we
> > have
> > >> more work to do because it won't do the DOTS server any good to get
> > >> a mitigation request referring to that private IP-address (or prefix).
> > >>
> > >>
> > >> Thanks
> > >>
> > >> -- Flemming
> > >>

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 08:22:19 +0000

Tiru, 

Yes, STUN can be listed as part of the existing tools box (among the lines of what is already discussed in 8085).

I don't think that it makes sense to require STUN support by DOTS clients.

The proposal is to include a simple built-in feature in the DOTS protocol itself that can help to detect NATs. The support of such feature will, e.g., ease troubleshooting when connectivity problems are experienced on the path between a client and a server.

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : jeudi 26 octobre 2017 09:44
> À : BOUCADAIR Mohamed IMT/OLN; Flemming Andreasen; Jon Shallow;
> [email-masked]
> Objet : RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))
> 
> > [Med] I fully agree that firewalls detect is more complex. Let's put it
> aside
> > and focus on the NAT case.
> 
> The presence and behavior of NAT and Firewall, and keepalive interval can
> be determined using STUN (discussed in
> https://tools.ietf.org/html/rfc5780).
> 
> -Tiru
> 
> >
> > > >> like dynamic DNS, they can     certainly be reachable. However, if
> we
> > > do

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 26 Oct 2017 08:36:25 +0000

But NATs are not the only problem, firewalls will also be most likely present, and STUN helps discover both NATs and firewalls and useful even in IPv6 networks to determine the keepalive interval of firewall.

-Tiru

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, October 26, 2017 1:52 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> Flemming Andreasen <[email-masked]>; Jon Shallow <supjps-
> Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))
> 
> Tiru,
> 
> The proposal is to include a simple built-in feature in the DOTS protocol itself
> that can help to detect NATs. The support of such feature will, e.g., ease
> troubleshooting when connectivity problems are experienced on the path
> between a client and a server.
> 
> Cheers,
> Med
> 
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > [email-masked] Objet : RE: [Dots] DOTS & NAT (was RE: DOTS Requirements
> > review (-06))
> >
> > > > De : Flemming Andreasen [mailto:[email-masked]] Envoyé : lundi
> > > > 23 octobre 2017 17:36 À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow;
> > > > [email-masked] Objet : Re: DOTS & NAT (was RE: [Dots] DOTS
> > > > Requirements review (-06))
> > > >
> > > >
> > > >
> > > > external IP address/prefix, if needed. External IP
> > > > addresses/prefixes can be IPv4 for a NAT44 or NAT64, but can be
> > > > IPv6 prefixes for enterprises deploying NPTv6, and so on.
> > > > difficult to determine the public-facing IP-address/port under
> > > > attack (at least if the DOTS client is going to do it).
> > >
> > > target(s). This can be achieved by provisioning (likely) or by
> > > discovery
> > means
> > > Can we assume that the discovery of the external IP
> > > address/prefix/.. is
> > done
> > > > Agreed - but they still need a way to figure out the
> > > > private/public mapping for a given attack target.
> > >
> > > Otherwise, the incoming attack traffic couldn't be forwarded to
> > > internal
> > hosts.
> > > This model assumes that the gateway is collocated with the NAT. So,
> > > the gateway can replace the internal IP address/prefix with the one
> > retrieves
> > > > having a feature in the DOTS protocol to inform a DOTS client that
> > > > a NAT is detected on-path. This can be presented as an information
> > > > element returned by the server to the client. This information can
> > > > be, for example, used by the client to adjust its HT interval,
> > > > adjust the internal IP addresses/prefixes to be protected, etc. Opinions?
> > > > It sounds appealing, but it's very difficult to do this reliably,
> > > > and it's not just NATs that are an issue here; Firewalls present
> > > > similar challenges (and they may or may not be NAT'ing individual
> flows).
> > > >
> > >
> > The presence and behavior of NAT and Firewall, and keepalive interval
> > can be determined using STUN (discussed in
> > > (1) The DOTS client inserts in the core message the IP address/port
> > > it
> > uses to
> > > send the request to the DOTS server. Upon receipt of the request by
> > > the DOTS server, it checks if the enclosed IP address/port match the
> > > source
> > IP
> > > (2) The DOTS server inserts systematically the source IP
> > > address/port in
> > a
> > > response to a message from a DOTS client. Upon receipt of that
> > > response, the DOTS client compares the enclosed address/port with
> > > the ones it used
> > to
> > > > >> De : Dots [mailto:[email-masked]] De la part de Jon
> > > > >> Shallow Envoyé : lundi 23 octobre 2017 13:18 À : 'Flemming
> > > > >> Andreasen'; [email-masked] Objet : Re: [Dots] DOTS Requirements
> > > > >> review (-06)
> > > > >>
> > > > >> Hi Flemming,
> > > > >>
> > > > >> The way my mind works is to think of a practical situation and
> > > > >> see if things fit.
> > > > >>
> > > > >> As I read SIG-010, there could be a DOTS client with a
> > > > >> management IP address that is RFC1918 - this client could be
> > > > >> monitoring Netflow information and can request mitigation for
> > > > >> the appropriate public IPs
> > > > that
> > > > >> accepts a mitigation request for a particular target ip (or
> > > > >> domain
> > etc.) or
> > > not.
> > > > >>
> > > > >> If there is going to be a NAT border where public IPs are
> > > > >> mapped into private IPs (and vice versa), I would then expect
> > > > >> there to be a DOTS gateway between these 2 zones, and it is the
> > > > >> responsibility of the DOTS gateway to do any target-ip mappings.
> > > > >>
> > > > >> Regards
> > > > >>
> > > > >> Jon
> > > > >>
> > > > >> From: Dots [mailto:[email-masked]] On Behalf
> > > > >> Of Flemming Andreasen
> > > > >> (https://www.ietf.org/id/draft-ietf-dots-requirements-06.txt).
> > > > >> In
> > > > general,
> > > > >> I think the draft is in good shape with only a few edits
> > > > >> required, so I hope we can move to WGLC soon. I have a few
> > > > >> comments below (of which
> > > > the
> > > > >> NAT one is the only real substantial one). I have also
> > > > >> submitted a pull request with a few nit fixes on GitHub:
> > > > >>
> > > > >>
> > > > >> Section 1.2
> > > > >> - The definition of "DOTS Signal" is slightly inconsistent with
> > > > >> the respective "Client Signal" and "Server Signal" definitions.
> > > > >>
> > > > >> SIG-005:
> > > > >> - Not clear that always requiring "number of packets" metrics
> > > > >> is meaningful. Consider TCP-based attacks for example. Number
> > > > >> of bytes may always be ok - above and beyond that it should
> > > > >> probably be extensible and/or attack dependent.
> > > > >> values - expontial backoff with some maximum value seems about
> > > > >> the
> > > > right
> > > > >> level of detail here.
> > > > >>
> > > > >> SIG-009:
> > > > >> administrative domain, right ? For example, if a client tells
> > > > >> the same domain to alternately turn on/off mitigation for a
> > > > >> given prefix, route flapping
> > > > may
> > > > >> different administrative domains to respective turn mitigation
> > > > >> on (domain 1) and
> > > > off
> > > > >> (domain 2). If so, can we clarify that (also in lieu of some of
> > > > >> the
> > > > multi-
> > > > >> - DOTS Client behind NAT. On one hand, it seems reasonable to
> > > > >> have this requirement since clients for sure can be behind
> > > > >> NATs, and
> > with
> > > things
> > > > >> have a private IP-address (potentially behind multiple NATs),
> > > > >> then we
> > > > have
> > > > >> more work to do because it won't do the DOTS server any good to
> > > > >> get a mitigation request referring to that private IP-address
> > > > >> (or
> > prefix).
> > > > >>
> > > > >>
> > > > >> Thanks
> > > > >>
> > > > >> -- Flemming
> > > > >>

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 08:50:35 +0000

Re-,

I hear you. My take is that we don't need to recommend which companion "protocols/mechanisms" need to be supported for NAT/FW traversal purposes. Having a discussion at the same level in 8085 would be sufficient, IMHO. 

Let's focus on the simple built-in feature for NAT detect. 

Cheers,
Med

> Envoyé : jeudi 26 octobre 2017 10:36
> But NATs are not the only problem, firewalls will also be most likely
> present, and STUN helps discover both NATs and firewalls and useful even
> in IPv6 networks to determine the keepalive interval of firewall.
> 
> -Tiru
> 
> > Yes, STUN can be listed as part of the existing tools box (among the
> lines of
> > what is already discussed in 8085).
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 26 Oct 2017 10:57:36 +0000

> Sent: Thursday, October 26, 2017 2:21 PM
> I hear you. My take is that we don't need to recommend which companion
> "protocols/mechanisms" need to be supported for NAT/FW traversal
> purposes. Having a discussion at the same level in 8085 would be sufficient,
> IMHO.
> 

I don’t think the simple built-in feature is sufficient, DOTS client will have to rely on mechanisms discussed in 8085 for both firewall and NAT traversal.

-Tiru

> > present, and STUN helps discover both NATs and firewalls and useful
> > even in IPv6 networks to determine the keepalive interval of firewall.
> >
> > -Tiru
> >
> > > that can help to detect NATs. The support of such feature will,
> > > e.g.,
> > ease
> > > troubleshooting when connectivity problems are experienced on the
> > > path between a client and a server.
> > >
> > > Cheers,
> > > Med
> > >
> > > > Envoyé : jeudi 26 octobre 2017 09:44 À : BOUCADAIR Mohamed
> > > > IMT/OLN; Flemming Andreasen; Jon Shallow; [email-masked] Objet :
> > > > RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))
> > > >
> > > > > To: Flemming Andreasen <[email-masked]>; Jon Shallow
> > > > > <supjps- [email-masked]>; [email-masked]
> > > > > > 23 octobre 2017 17:36 À : BOUCADAIR Mohamed IMT/OLN; Jon
> > > > > > Shallow; [email-masked] Objet : Re: DOTS & NAT (was RE: [Dots]
> > > > > > DOTS Requirements review (-06))
> > > > > >
> > > > > >
> > > > > >
> > > > > > typical discussion to include in a dedicated section in the
> > > > > > DOTS architecture I-D.
> > > > > > Agreed.
> > > > > > RFC8085 which points to NAT traversal mechanisms. One could
> > > > > > pick his/her favorite protocol from the list in 8085 to
> > > > > > discover the external IP address/prefix, if needed. External
> > > > > > IP addresses/prefixes can be IPv4 for a NAT44 or NAT64, but
> > > > > > can be
> > > > > > Part of the challenge here is that the attack target and the
> > > > > > DOTS client are not necessarily one and the same, which makes
> > > > > > it more difficult to determine the public-facing
> > > > > > IP-address/port under attack (at least if the DOTS client is going to
> do it).
> > > > >
> > > > > > appropriate IP addresses/prefixes/port numbers in the presence
> > > > > > of translators.
> > > > > This model assumes that the gateway is collocated with the NAT.
> > > > > So, the gateway can replace the internal IP address/prefix with
> > > > > the one
> > > > retrieves
> > > > > > having a feature in the DOTS protocol to inform a DOTS client
> > > > > > that a NAT is detected on-path. This can be presented as an
> > > > > > information element returned by the server to the client. This
> > > > > > information can be, for example, used by the client to adjust
> > > > > > its HT interval, adjust the internal IP addresses/prefixes to be
> protected, etc.
> > Opinions?
> > > > > > It sounds appealing, but it's very difficult to do this
> > > > > > reliably, and it's not just NATs that are an issue here;
> > > > > > Firewalls present similar challenges (and they may or may not
> > > > > > be NAT'ing individual
> > > flows).
> > > > > >
> > > > >
> > > > The presence and behavior of NAT and Firewall, and keepalive
> > > > interval can be determined using STUN (discussed in
> > > > > (1) The DOTS client inserts in the core message the IP
> > > > > address/port it
> > > > uses to
> > > > > send the request to the DOTS server. Upon receipt of the request
> > > > > by the DOTS server, it checks if the enclosed IP address/port
> > > > > match the source
> > > > IP
> > > > > address/port of the received packet. If yes, the server sets in
> > > > > the
> > > > response a
> > > > > dedicated parameter to indicate that a translator is detected
> > > > > on-
> > path.
> > > > >
> > > > > response, the DOTS client compares the enclosed address/port
> > > > > with the ones it used
> > > > to
> > > > > > >> -----Message d'origine----- De : Dots
> > > > > > >> [mailto:[email-masked]] De la part de Jon Shallow
> > > > > > >> Envoyé : lundi 23 octobre 2017 13:18 À : 'Flemming
> > > > > > >> Andreasen'; [email-masked] Objet : Re: [Dots] DOTS
> > > > > > >> Requirements review (-06)
> > > > > > >>
> > > > > > >> Hi Flemming,
> > > > > > >>
> > > > > > >> The way my mind works is to think of a practical situation
> > > > > > >> and see if things fit.
> > > > > > >>
> > > > > > >> management IP address that is RFC1918 - this client could
> > > > > > >> be monitoring Netflow information and can request
> > > > > > >> mitigation for the appropriate public IPs
> > > > > > that
> > > > > > >> It is the responsibility of the DOTS server as to whether
> > > > > > >> it accepts a mitigation request for a particular target ip
> > > > > > >> (or domain
> > > > etc.) or
> > > > > not.
> > > > > > >>
> > > > > > >> mapped into private IPs (and vice versa), I would then
> > > > > > >> expect there to be a DOTS gateway between these 2 zones,
> > > > > > >> and it is the responsibility of the DOTS gateway to do any
> > > > > > >> target-ip
> > mappings.
> > > > > > >>
> > > > > > >> Regards
> > > > > > >>
> > > > > > >> Jon
> > > > > > >>
> > > > > > >> From: Dots [mailto:[email-masked]] On
> > > > > > >> Behalf Of Flemming Andreasen
> > > > > > >> - The definition of "DOTS Signal" is slightly inconsistent
> > > > > > >> with the respective "Client Signal" and "Server Signal" definitions.
> > > > > > >>
> > > > > > >> SIG-005:
> > > > > > >> - Not clear that always requiring "number of packets"
> > > > > > >> metrics is meaningful. Consider TCP-based attacks for
> > > > > > >> example. Number of bytes may always be ok - above and
> > > > > > >> beyond that it should probably be extensible and/or attack
> dependent.
> > > > > > >> values - expontial backoff with some maximum value seems
> > > > > > >> about the
> > > > > > right
> > > > > > >> level of detail here.
> > > > > > >>
> > > > > > >> SIG-009:
> > > > > > >> administrative domain, right ? For example, if a client
> > > > > > >> tells the same domain to alternately turn on/off mitigation
> > > > > > >> for a given prefix, route flapping
> > > > > > may
> > > > > > >> occur. The same concern does not apply if a client tells
> > > > > > >> two different administrative domains to respective turn
> > > > > > >> mitigation on (domain 1) and
> > > > > > off
> > > > > > >> (domain 2). If so, can we clarify that (also in lieu of
> > > > > > >> some of the
> > > > > > multi-
> > > > > > >> - DOTS Client behind NAT. On one hand, it seems reasonable
> > > > > > >> to have this requirement since clients for sure can be
> > > > > > >> behind NATs, and
> > > > with
> > > > > things
> > > > > > >> want to allow for this scenario, and in particular for the
> > > > > > >> DOTS client
> > > > > > to
> > > > > > >> have a private IP-address (potentially behind multiple
> > > > > > >> NATs), then we
> > > > > > have
> > > > > > >> more work to do because it won't do the DOTS server any
> > > > > > >> good to get a mitigation request referring to that private
> > > > > > >> IP-address (or
> > > > prefix).
> > > > > > >>
> > > > > > >>
> > > > > > >> Thanks
> > > > > > >>
> > > > > > >> -- Flemming
> > > > > > >>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 26 Oct 2017 11:15:09 +0000

I think there is another option to handle the NAT/firewall problems by changing the protocol.

If I understand correctly, currently the NAT and firewall need to be kept open to permit unsolicited server packets.

If the protocol is changed to require client polling of the server updates, the NAT and firewall problems go away.

-Dave

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: Thursday, October 26, 2017 12:58 PM
To: [email-masked]; Flemming Andreasen; Jon Shallow; [email-masked]
Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

> purposes. Having a discussion at the same level in 8085 would be 
> sufficient, IMHO.
> 

-Tiru

> > Envoyé : jeudi 26 octobre 2017 10:36 À : BOUCADAIR Mohamed IMT/OLN; 
> > Flemming Andreasen; Jon Shallow; [email-masked] Objet : RE: [Dots] 
> > DOTS & NAT (was RE: DOTS Requirements review (-06))
> >
> > But NATs are not the only problem, firewalls will also be most 
> > likely present, and STUN helps discover both NATs and firewalls and 
> > useful even in IPv6 networks to determine the keepalive interval of firewall.
> >
> > -Tiru
> >
> > > > > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements 
> > > > > review
> > > > > (-06))
> > > > >
> > > > > Hi Flemming, all,
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > Shallow; [email-masked] Objet : Re: DOTS & NAT (was RE: 
> > > > > > [Dots] DOTS Requirements review (-06))
> > > > > >
> > > > > >
> > > > > >
> > > > > > DOTS client are not necessarily one and the same, which 
> > > > > > makes it more difficult to determine the public-facing 
> > > > > With or without NAT, DOTS clients are assumed to be fed with 
> > > > > the
> > > > internal
> > > > > > appropriate IP addresses/prefixes/port numbers in the 
> > > > > > presence of translators.
> > > > > Otherwise, the incoming attack traffic couldn't be forwarded 
> > > > > to internal
> > > > hosts.
> > > > > So, the gateway can replace the internal IP address/prefix 
> > > > > with the one
> > > > retrieves
> > > > > > having a feature in the DOTS protocol to inform a DOTS 
> > > > > > client that a NAT is detected on-path. This can be presented 
> > > > > > as an information element returned by the server to the 
> > > > > > client. This information can be, for example, used by the 
> > > > > > client to adjust its HT interval, adjust the internal IP 
> > > > > > addresses/prefixes to be
> protected, etc.
> > Opinions?
> > > > > > Firewalls present similar challenges (and they may or may 
> > > > > > not be NAT'ing individual
> > > flows).
> > > > > >
> > > > >
> > > > > send the request to the DOTS server. Upon receipt of the 
> > > > > request by the DOTS server, it checks if the enclosed IP 
> > > > > address/port match the source
> > > > IP
> > > > > address/port of the received packet. If yes, the server sets 
> > > > > in the
> > > > response a
> > > > > > >> The way my mind works is to think of a practical 
> > > > > > >> situation and see if things fit.
> > > > > > >>
> > > > > > >> it accepts a mitigation request for a particular target 
> > > > > > >> ip (or domain
> > > > etc.) or
> > > > > not.
> > > > > > >>
> > > > > > >> and it is the responsibility of the DOTS gateway to do 
> > > > > > >> any target-ip
> > mappings.
> > > > > > >>
> > > > > > >> Regards
> > > > > > >>
> > > > > > >> Jon
> > > > > > >>
> > > > > > >> required, so I hope we can move to WGLC soon. I have a 
> > > > > > >> few comments below (of which
> > > > > > the
> > > > > > >> - The definition of "DOTS Signal" is slightly 
> > > > > > >> inconsistent with the respective "Client Signal" and "Server Signal" definitions.
> > > > > > >>
> > > > > > >> SIG-005:
> > > > > > >> tells the same domain to alternately turn on/off 
> > > > > > >> mitigation for a given prefix, route flapping
> > > > > > may
> > > > > > >> - DOTS Client behind NAT. On one hand, it seems 
> > > > > > >> reasonable to have this requirement since clients for 
> > > > > > >> sure can be behind NATs, and
> > > > with
> > > > > things
> > > > > > >> want to allow for this scenario, and in particular for 
> > > > > > >> the DOTS client
> > > > > > to
> > > > > > >> good to get a mitigation request referring to that 
> > > > > > >> private IP-address (or
> > > > prefix).
> > > > > > >>
> > > > > > >>
> > > > > > >> Thanks
> > > > > > >>
> > > > > > >> -- Flemming
> > > > > > >>

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 12:09:28 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : jeudi 26 octobre 2017 12:58
> sufficient,
> I don’t think the simple built-in feature is sufficient,

[Med] It depends for what purpose. For example, the built-in feature will help troubleshooting when problems are experienced to deliver DOTS messages in the presence of NATs. 

 DOTS client will
> have to rely on mechanisms discussed in 8085 for both firewall and NAT
> traversal.

[Med] I'm not sure. Actually, it depends whether we want to ** optimize ** the keepalive messages and avoid overloading the network. Having a NAT/FW traversal protocol that allows to learn the NAT/FW validity lifetime will allow to adjust the keep alive interval. That's only an optimization. 

> > > > > > > >> like dynamic DNS, they can     certainly be reachable.
> However,
> > > if
> > > > > we
> > > > > > > do

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 12:11:54 +0000

Hi Dave, 

The protocol does already support a mechanism to send keepalive messages every 30s (recommended value). 

Cheers,
Med

> De : Dave Dolson [mailto:[email-masked]]
> Envoyé : jeudi 26 octobre 2017 13:15
> À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed IMT/OLN; Flemming
> Andreasen; Jon Shallow; [email-masked]
> If I understand correctly, currently the NAT and firewall need to be kept
> open to permit unsolicited server packets.
> 
> If the protocol is changed to require client polling of the server
> updates, the NAT and firewall problems go away.
> 
> -Dave
> 
> 
> I don’t think the simple built-in feature is sufficient, DOTS client will

---

From: Dave Dolson <[email-masked]>
Date: Thu, 26 Oct 2017 12:49:48 +0000

My point was that if server status was solicited, keep-alive interval would be independent of firewall/NAT timeout. Keep-alives would be optional.

Solicited means that client says "get status" vs. the server just sending updates.

David Dolson
Sandvine
  Original Message
From: [email-masked]
Sent: Thursday, October 26, 2017 2:11 PM
To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon Shallow; [email-masked]
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

Hi Dave,

Cheers,
Med

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 13:06:04 +0000

Re-,

Not sure how to get rid of the constraint imposed by the NAT/FW timer, Dave. 

The current text says the following: 

   To provide a metric of signal health and distinguish an 'idle' signal
   channel from a 'disconnected' or 'defunct' session, the DOTS agent
   sends a heartbeat over the signal channel to maintain its half of the
   channel.  The DOTS agent similarly expects a heartbeat from its peer
   DOTS agent, and may consider a session terminated in the extended
   absence of a peer agent heartbeat.

Which covers your proposal. No? 

Solicited messages from the server do not prevent from failures. Consider the case where a DOTS server has to send a mitigation status update back to the client, but the client didn't refreshed the state. Or when the NAT fired out a mapping and assigns the external port to another host than the DOTS client. 

Did I missed something?

Thank you.

Cheers,
Med

> Envoyé : jeudi 26 octobre 2017 14:50
> À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; Flemming
> Objet : Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))
> 
> My point was that if server status was solicited, keep-alive interval
> would be independent of firewall/NAT timeout. Keep-alives would be
> optional.
> 
> > From: Dots [mailto:[email-masked]] On Behalf Of Konda,
> Tirumaleswar
> > Reddy
> > I don't think the simple built-in feature is sufficient, DOTS client
> will

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 26 Oct 2017 13:11:39 +0000

> Sent: Thursday, October 26, 2017 5:39 PM
> > > I hear you. My take is that we don't need to recommend which
> > > companion "protocols/mechanisms" need to be supported for NAT/FW
> > > traversal purposes. Having a discussion at the same level in 8085
> > > would be
> > sufficient,
> > > IMHO.
> > >
> [Med] It depends for what purpose. For example, the built-in feature will
> help troubleshooting when problems are experienced to deliver DOTS
> messages in the presence of NATs.

NATs will not cause any specific problem for just the DOTS signal channel protocol. 
In the presence of  NAT, DOTS will face the same problems as any other protocol like QUIC, CoAP etc. running over UDP. 

> [Med] I'm not sure. Actually, it depends whether we want to ** optimize **
> the keepalive messages and avoid overloading the network. Having a
> NAT/FW traversal protocol that allows to learn the NAT/FW validity lifetime
> will allow to adjust the keep alive interval. That's only an optimization.

Yes, these mechanisms only help to optimize the keep-alive interval.

-Tiru

> > > > Envoyé : jeudi 26 octobre 2017 10:36 À : BOUCADAIR Mohamed
> > > > likely present, and STUN helps discover both NATs and firewalls
> > > > and useful even in IPv6 networks to determine the keepalive interval of
> firewall.
> > > >
> > > > -Tiru
> > > >
> > > > > I don't think that it makes sense to require STUN support by
> > > > > DOTS
> > > > clients.
> > > > >
> > > > > troubleshooting when connectivity problems are experienced on
> > > > > the path between a client and a server.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > > > -----Message d'origine----- De : Flemming Andreasen
> > > > > > > > [mailto:[email-masked]] Envoyé :
> > > > > > > > lundi
> > > > > > > > typical discussion to include in a dedicated section in
> > > > > > > > the DOTS architecture I-D.
> > > > > > > > Agreed.
> > > > > > > > RFC8085 which points to NAT traversal mechanisms. One
> > > > > > > > could pick his/her favorite protocol from the list in 8085
> > > > > > > > to discover the external IP address/prefix, if needed.
> > > > > > > > External IP addresses/prefixes can be IPv4 for a NAT44 or
> > > > > > > > NAT64, but can be
> > > > > > > > Part of the challenge here is that the attack target and
> > > > > > > > the DOTS client are not necessarily one and the same,
> > > > > > > > which makes it more difficult to determine the
> > > > > > > > public-facing IP-address/port under attack (at least if
> > > > > > > > the DOTS client is
> > going to
> > > do it).
> > > > > > >
> > > > > > > target(s). This can be achieved by provisioning (likely) or
> > > > > > > by discovery
> > > > > > means
> > > > > > > > client that a NAT is detected on-path. This can be
> > > > > > > > presented as an information element returned by the server
> > > > > > > > to the client. This information can be, for example, used
> > > > > > > > by the client to adjust its HT interval, adjust the
> > > > > > > > internal IP addresses/prefixes to
> > be
> > > protected, etc.
> > > > Opinions?
> > > > > > > response to a message from a DOTS client. Upon receipt of
> > > > > > > that response, the DOTS client compares the enclosed
> > > > > > > address/port with the ones it used
> > > > > > to
> > > > > > > > >> [mailto:[email-masked]] De la part de Jon
> > > > > > > > >> Shallow Envoyé : lundi 23 octobre 2017 13:18 À :
> > > > > > > > >> 'Flemming Andreasen'; [email-masked] Objet : Re: [Dots]
> > > > > > > > >> DOTS Requirements review (-06)
> > > > > > > > >>
> > > > > > > > >> Hi Flemming,
> > > > > > > > >>
> > > > > > > > >> management IP address that is RFC1918 - this client
> > > > > > > > >> could be monitoring Netflow information and can request
> > > > > > > > >> It is the responsibility of the DOTS server as to
> > > > > > > > >> whether it accepts a mitigation request for a
> > > > > > > > >> particular target ip (or domain
> > > > > > etc.) or
> > > > > > > not.
> > > > > > > > >>
> > > > > > > > >> If there is going to be a NAT border where public IPs
> > > > > > > > >> are mapped into private IPs (and vice versa), I would
> > > > > > > > >> then expect there to be a DOTS gateway between these 2
> > > > > > > > >> zones, and it is the responsibility of the DOTS gateway
> > > > > > > > >> to do any target-ip
> > > > mappings.
> > > > > > > > >>
> > > > > > > > >> Regards
> > > > > > > > >>
> > > > > > > > >> Jon
> > > > > > > > >>
> > > > > > > > >> From: Dots [mailto:[email-masked]]
> > > > > > > > >> On Behalf Of Flemming Andreasen
> > > > > > > > >> I think the draft is in good shape with only a few
> > > > > > > > >> edits required, so I hope we can move to WGLC soon. I
> > > > > > > > >> have a few comments below (of which
> > > > > > > > the
> > > > > > > > >> inconsistent with the respective "Client Signal" and "Server
> Signal"
> > definitions.
> > > > > > > > >>
> > > > > > > > >> SIG-005:
> > > > > > > > >> - I don't think the requirements document should get
> > > > > > > > >> into specifying
> > > > > > > > timer
> > > > > > > > >> values - expontial backoff with some maximum value
> > > > > > > > >> seems about the
> > > > > > > > right
> > > > > > > > >> level of detail here.
> > > > > > > > >>
> > > > > > > > >> SIG-009:
> > > > > > > > >> occur. The same concern does not apply if a client
> > > > > > > > >> tells two different administrative domains to
> > > > > > > > >> respective turn mitigation on (domain 1) and
> > > > > > > > off

---

From: Dave Dolson <[email-masked]>
Date: Thu, 26 Oct 2017 13:13:07 +0000

I'm not pushing for this. I saw the working group struggling with the firewall/NAT problem, and offered a different way of thinking about it.
To be clear, my suggestion is to remove unsolicited messages from the server to client.

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 26, 2017 3:06 PM
To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon Shallow; [email-masked]
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

Re-,

Did I missed something?

Thank you.

Cheers,
Med

> De : Dave Dolson [mailto:[email-masked]] Envoyé : jeudi 26 
> octobre 2017 14:50 À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar 
> Reddy; Flemming Andreasen; Jon Shallow; [email-masked] Objet : Re: 
> [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))
> 
> > De : Dave Dolson [mailto:[email-masked]] Envoyé : jeudi 26 
> > octobre 2017 13:15 À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed 
> > IMT/OLN; Flemming Andreasen; Jon Shallow; [email-masked] Objet : RE: 
> > [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))
> >
> > > would be sufficient, IMHO.
> > >
> > have to rely on mechanisms discussed in 8085 for both firewall and 
> > NAT traversal.
> >
> > -Tiru
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements 
> > > > > review
> > > > > (-06))
> > > > >
> > > > > Tiru,
> > > > >
> > > > > The proposal is to include a simple built-in feature in the 
> > > > > DOTS
> > > > protocol itself
> > > > > that can help to detect NATs. The support of such feature 
> > > > > will, e.g.,
> > > > ease
> > > > > > > > could pick his/her favorite protocol from the list in 
> > > > > > > > 8085 to discover the external IP address/prefix, if 
> > > > > > > > needed. External IP addresses/prefixes can be IPv4 for a 
> > > > > > > > NAT44 or NAT64, but can be
> > > > > > > With or without NAT, DOTS clients are assumed to be fed 
> > > > > > > with the
> > > > > > internal
> > > > > > > target(s). This can be achieved by provisioning (likely) 
> > > > > > > or by discovery
> > > > > > means
> > > > > > > Otherwise, the incoming attack traffic couldn't be 
> > > > > > > forwarded to internal
> > > > > > hosts.
> > > > > > > > presented as an information element returned by the 
> > > > > > > > server to the client. This information can be, for 
> > > > > > > > example, used by the client to adjust its HT interval, 
> > > > > > > > adjust the internal IP addresses/prefixes to be
> > > protected, etc.
> > > > Opinions?
> > > > > > > > Firewalls present similar challenges (and they may or 
> > > > > > > > may not be NAT'ing individual
> > > > > flows).
> > > > > > > >
> > > > > > >
> > > > > > > address/port of the received packet. If yes, the server 
> > > > > > > sets in the
> > > > > > response a
> > > > > > > > >> 'Flemming Andreasen'; [email-masked] Objet : Re: 
> > > > > > > > >> [Dots] DOTS Requirements review (-06)
> > > > > > > > >>
> > > > > > > > >> Hi Flemming,
> > > > > > > > >>
> > > > > > > > >> As I read SIG-010, there could be a DOTS client with 
> > > > > > > > >> a management IP address that is RFC1918 - this client 
> > > > > > > > >> could be monitoring Netflow information and can 
> > > > > > > > >> request mitigation for the appropriate public IPs
> > > > > > > > that
> > > > > > > > >> are being monitored.  So SIG-010 is needed for this 
> > > > > > > > >> use
> > case.
> > > > > > > > >>
> > > > > > > > >> then expect there to be a DOTS gateway between these 
> > > > > > > > >> 2 zones, and it is the responsibility of the DOTS 
> > > > > > > > >> (https://www.ietf.org/id/draft-ietf-dots-requirements
> > > > > > > > >> -
> > 06.txt).
> > > > > > > > >> In
> > > > > > > > general,
> > > > > > > > >> NAT one is the only real substantial one). I have 
> > > > > > > > >> also submitted a pull request with a few nit fixes on GitHub:
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> Section 1.2
> > > > > > > > >> - To be clear, the conflicts only apply within a 
> > > > > > > > >> single administrative domain, right ? For example, if 
> > > > > > > > >> a client tells the same domain to alternately turn 
> > > > > > > > >> on/off mitigation for a given prefix, route flapping
> > > > > > > > may
> > > > > > > > >> (domain 2). If so, can we clarify that (also in lieu 
> > > > > > > > >> of some of the
> > > > > > > > multi-
> > > > > > > > >> want to allow for this scenario, and in particular 
> > > > > > > > >> for the DOTS client
> > > > > > > > to
> > > > > > > > >> have a private IP-address (potentially behind 
> > > > > > > > >> multiple NATs), then we
> > > > > > > > have
> > > > > > > > >> more work to do because it won't do the DOTS server 
> > > > > > > > >> any good to get a mitigation request referring to 
> > > > > > > > >> that private IP-address (or
> > > > > > prefix).
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> Thanks
> > > > > > > > >>
> > > > > > > > >> -- Flemming
> > > > > > > > >>

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 13:31:53 +0000

Re-,

Glad to see that we are in agreement that all this is about optimizations. 

Back to the initial proposal, is there any problem if we support an optional feature in the protocol to detect on-path translators? Wouldn't the be helpful to troubleshoot when some connectivity are experienced? 

As a reminder, the proposal is as follows:
- include the ip-address/port used by the DOTS agent when sending the request
- if that information is present in the request, the server includes the source IP address/port in the response.

Cheers,
Med

> Envoyé : jeudi 26 octobre 2017 15:12
> In the presence of  NAT, DOTS will face the same problems as any other
> protocol like QUIC, CoAP etc. running over UDP.
> 
> >
> >  DOTS client will

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 26 Oct 2017 09:39:22 -0400

> Can we assume that the discovery of the external IP address/prefix/.. is done by a DOTS client only if it is explicitly instructed to do so?
Seems reasonable, however having the DOTS client instead of the attack 
target doing the discovery may not always work.

> Do you see any issue with this scheme?
Requiring co-location of the DOTS gateway and the NAT seems like a 
significant obstacle to real-life deployment.

> (2) The DOTS server inserts systematically the source IP address/port in a response to a message from a DOTS client. Upon receipt of that response, the DOTS client compares the enclosed address/por…
We will probably end up reinventing STUN before we are done, so I'd 
rather leverage that.

Thanks

-- Flemming

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 13:41:11 +0000

Re-,

Thanks Dave for the clarification. 

That's indeed an option. 

I do personally prefer to maintain the current design which allows for the following with one single message from the client: 

                       DOTS Client            DOTS Server
                          |                               |
                          |  GET /<mitigation-id number>  |
                          |  Token: 0x4a                  |   Registration
                          |  Observe: 0                   |
                          +------------------------------>|
                          |                               |
                          |  2.05 Content                 |
                          |  Token: 0x4a                  |   Notification of
                          |  Observe: 12                  |   the current state
                          |  status: "mitigation          |
                          |          in progress"         |
                          |<------------------------------+
                          |  2.05 Content                 |
                          |  Token: 0x4a                  |   Notification upon
                          |  Observe: 44                  |    a state change
                          |  status: "mitigation          |
                          |          complete"            |
                          |<------------------------------+
                          |  2.05 Content                 |
                          |  Token: 0x4a                  |   Notification upon
                          |  Observe: 60                  |   a state change
                          |  status: "attack stopped"     |
                          |<------------------------------+
                          |                               |

If we disallow this behavior, the client will need to regulatory poke the server to get a status update.   

Cheers,
Med

> Envoyé : jeudi 26 octobre 2017 15:13
> I'm not pushing for this. I saw the working group struggling with the
> firewall/NAT problem, and offered a different way of thinking about it.
> Solicited messages from the server do not prevent from failures. Consider
> the case where a DOTS server has to send a mitigation status update back
> to the client, but the client didn't refreshed the state. Or when the NAT
> fired out a mapping and assigns the external port to another host than the
> DOTS client.
> 
> Did I missed something?
> 
> Thank you.
> 
> Cheers,
> Med
>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 26 Oct 2017 09:46:42 -0400

As I have stated several times before, I'm not all that comfortable with 
the current requirement around always sending keep-alives, whether 
attacks are in progress or now. My concerns are around scalability/cost 
of the overall solution, so I think it's worth considering during 
peace-time at least.

-- Flemming

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Thu, 26 Oct 2017 16:58:33 +0000

On Oct 26, 2017, at 9:46 AM, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:

As I have stated several times before, I'm not all that comfortable with the current requirement around always sending keep-alives, whether attacks are in progress or now. My concerns are around scalability/cost of the overall solution, so I think it's worth considering during peace-time at least.

Hi Flemming. I suspect your concerns aren’t fully addressed by reducing the heartbeat MUST to a SHOULD, as captured in this issue:

<https://github.com/dotswg/dots-requirements/issues/57>

Do we need to recast the requirement to capture the peace-time aspect? For example, should a DOTS server be able to tell a client to stop heartbeats, or slow the heartbeat rate?

andrew

-Dave

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, October 26, 2017 3:06 PM
To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

Re-,

Did I missed something?

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Dave Dolson [mailto:[email-masked]] Envoyé : jeudi 26
octobre 2017 14:50 À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar
Reddy; Flemming Andreasen; Jon Shallow; [email-masked]<mailto:[email-masked]> Objet : Re:
[Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

Solicited means that client says "get status" vs. the server just
sending updates.

David Dolson
Sandvine
  Original Message
From: [email-masked]<mailto:[email-masked]>
Sent: Thursday, October 26, 2017 2:11 PM
To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon
Shallow; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review
(-06))

Hi Dave,

The protocol does already support a mechanism to send keepalive
messages every 30s (recommended value).

Cheers,
Med

-----Message d'origine-----
De : Dave Dolson [mailto:[email-masked]] Envoyé : jeudi 26
octobre 2017 13:15 À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed
IMT/OLN; Flemming Andreasen; Jon Shallow; [email-masked]<mailto:[email-masked]> Objet : RE:
[Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

I think there is another option to handle the NAT/firewall problems
by changing the protocol.

If I understand correctly, currently the NAT and firewall need to be
kept
open to permit unsolicited server packets.

-Dave

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Konda,
Tirumaleswar
Reddy
Sent: Thursday, October 26, 2017 12:58 PM
To: [email-masked]<mailto:[email-masked]>; Flemming Andreasen; Jon Shallow;
[email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review
(-06))

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, October 26, 2017 2:21 PM
To: Konda, Tirumaleswar Reddy
<[email-masked]>;
Flemming Andreasen <[email-masked]>; Jon Shallow <supjps-
[email-masked]>; [email-masked]
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review
(-06))

Re-,

-Tiru

Cheers,
Med

-----Message d'origine-----
IMT/OLN; Flemming Andreasen; Jon Shallow; [email-masked]<mailto:[email-masked]> Objet :

But NATs are not the only problem, firewalls will also be most
likely present, and STUN helps discover both NATs and firewalls
and useful even in IPv6 networks to determine the keepalive
interval of
firewall.
-Tiru

-----Original Message-----
From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]]
Sent: Thursday, October 26, 2017 1:52 PM
To: Konda, Tirumaleswar Reddy
<[email-masked]<mailto:[email-masked]>>;
Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; Jon Shallow <supjps-
[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements
review
(-06))

Tiru,

Yes, STUN can be listed as part of the existing tools box
(among the
lines of
what is already discussed in 8085).

Cheers,
Med

-----Message d'origine-----
De : Konda, Tirumaleswar Reddy
[mailto:[email-masked]]
Envoyé : jeudi 26 octobre 2017 09:44 À : BOUCADAIR Mohamed
IMT/OLN; Flemming Andreasen; Jon Shallow; [email-masked]<mailto:[email-masked]> Objet :
RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review
(-06))

-----Original Message-----
[email-masked]<mailto:[email-masked]>

Hi Flemming, all,

Please see inline.

Cheers,
Med

I agree with Flemming that "some more work" is needed.
IMHO, this is a
typical discussion to include in a dedicated section in
the DOTS architecture I-D.
Agreed.
>From a requirement standpoint, we don't need to
elaborate how the
protocols will fulfil it. SIG-10 does even a nice job by
citing
the DOTS client is going to
[Med] This is exactly the kind of the discussion to have.
Thanks.

In some deployments, DOTS clients may be provisioned
with the set of
internal resources, so there is no need for discovery.
Also, as Jon mentioned, DOTS gateways can be of help
to set the
appropriate IP addresses/prefixes/port numbers in the
presence of translators.
Agreed - but they still need a way to figure out the
private/public mapping for a given attack target.
[Med] Because a DDoS attack is observed from the internal
network,
mapping(s) are necessarily maintained by the on-path
translator(s).
Otherwise, the incoming attack traffic couldn't be
forwarded to internal
hosts.
This model assumes that the gateway is collocated with the
NAT.
So, the gateway can replace the internal IP address/prefix
with the one
retrieves
from the NAT mapping table.

An open question though would be to discuss if there
is a value in
[Med] I fully agree that firewalls detect is more complex.
Let's put it

-Tiru

dedicated parameter to indicate that a translator is
detected

-- Flemming

Cheers,
Med

'Flemming Andreasen'; [email-masked]<mailto:[email-masked]> Objet : Re:

Hi Flemming,

gateway to do any target-ip
mappings.
Regards

Jon

-----Original Message-----
To: dots; [email-masked]<mailto:[email-masked]>

Greetings

I have reviewed the latest version of the DOTS
requirements draft

Section 1.2
- The definition of "DOTS Signal" is slightly
inconsistent with the respective "Client Signal" and
"Server Signal" definitions.
SIG-005:
- Not clear that always requiring "number of packets"
metrics is meaningful. Consider TCP-based attacks for
example. Number of bytes may always be ok - above and
beyond that it should probably be extensible and/or
attack
dependent.
- I don't think the requirements document should get
into specifying
timer
values - expontial backoff with some maximum value
seems about the
right
level of detail here.

SIG-009:

SIG-010:

Thanks

-- Flemming

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots
_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots
.

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 26 Oct 2017 17:13:12 +0000

Up to now we’ve treated heartbeats as essentially 2x unidirectional signals – I think there’s value in the zero heartbeat mode… maybe another way to look at a way around the nat would be a ‘passive’ mode where a client can solicit a heartbeat

From: Dots [mailto:[email-masked]] On Behalf Of Mortensen, Andrew
Sent: Thursday, October 26, 2017 5:59 PM
To: Flemming Andreasen <[email-masked]>
Cc: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]; Dave Dolson <[email-masked]>
Subject: [EXTERNAL] Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

andrew

-Dave

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, October 26, 2017 3:06 PM
To: Dave Dolson; Konda, Tirumaleswar Reddy; Flemming Andreasen; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

Re-,

Did I missed something?

Thank you.

Cheers,
Med

-----Message d'origine-----

David Dolson
Sandvine
  Original Message

Hi Dave,

Cheers,
Med

-----Message d'origine-----

-Dave

-----Original Message-----

Reddy

-----Original Message-----

Re-,

-Tiru

Cheers,
Med

-----Message d'origine-----

-Tiru

-----Original Message-----

Tiru,

Cheers,
Med

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 24, 2017 2:20 PM
To: Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; Jon Shallow
<supjps- [email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements
review
(-06))

Hi Flemming, all,

Please see inline.

Cheers,
Med

Shallow; [email-masked]<mailto:[email-masked]> Objet : Re: DOTS & NAT (was RE:

On 10/23/17 8:28 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Jon, all,

>From a requirement standpoint, we don't need to

elaborate how the

Opinions?

-Tiru

-- Flemming

Cheers,
Med

Hi Flemming,

not.

Regards

Jon

-----Original Message-----

Greetings

In
general,

Section 1.2

SIG-005:

level of detail here.

SIG-009:

SIG-010:

things

if

we

do

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 26 Oct 2017 13:37:36 -0400

On 10/26/17 12:58 PM, Mortensen, Andrew wrote:
>> As I have stated several times before, I'm not all that comfortable 
>> with the current requirement around always sending keep-alives, 
>> whether attacks are in progress or now. My concerns are around 
>> scalability/cost of the overall solution, so I think it's worth 
>> considering during peace-time at least.
>
> Hi Flemming. I suspect your concerns aren’t fully addressed by 
> reducing the heartbeat MUST to a SHOULD, as captured in this issue:
>
Thanks for capturing it in the issue, and you are right, I would still 
have concerns with a SHOULD requirement (but it would obviously be 
better than the current MUST).

> Do we need to recast the requirement to capture the peace-time aspect? 
> For example, should a DOTS server be able to tell a client to stop 
> heartbeats, or slow the heartbeat rate?
>
That seems useful to me, however we may need to couple that with the 
client unilaterally increasing the rate when it's under attack to ensure 
bi-directional communication is still possible.

Thanks

-- Flemming

>>> I'm not pushing for this. I saw the working group struggling with 
>>> the firewall/NAT problem, and offered a different way of thinking 
>>> about it.
>>> <mailto:[email-masked]> 
>>> Shallow; [email-masked] <mailto:[email-masked]>
>>> Solicited messages from the server do not prevent from failures. 
>>> Consider the case where a DOTS server has to send a mitigation 
>>> status update back to the client, but the client didn't refreshed 
>>> the state. Or when the NAT fired out a mapping and assigns the 
>>> external port to another host than the DOTS client.
>>>
>>> Did I missed something?
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Med
>>>
>>>> <mailto:[email-masked]>
>>>> Shallow; [email-masked] <mailto:[email-masked]>
>>>>> To: [email-masked] 
>>>>> <mailto:[email-masked]>; Flemming Andreasen; Jon 
>>>>> Shallow;
>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>> <mailto:[email-masked]>
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]>>;
>>>>>>>> Flemming Andreasen <[email-masked] 
>>>>>>>> <mailto:[email-masked]>>; Jon Shallow <supjps-
>>>>>>>> [email-masked] <mailto:[email-masked]>>; [email-masked] 
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>>>>> 'Flemming Andreasen'; [email-masked] <mailto:[email-masked]> 
>>>>>>>>>>>>> Objet : Re:
>>>>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 27 Oct 2017 05:49:21 +0000

Hi Felmming, 

Please see inline.

Cheers,
Med

> Envoyé : jeudi 26 octobre 2017 15:39
> > With or without NAT, DOTS clients are assumed to be fed with the
> internal target(s). This can be achieved by provisioning (likely) or by
> discovery means (e.g., residential or small enterprise networks).
> >
> > Can we assume that the discovery of the external IP address/prefix/.. is
> done by a DOTS client only if it is explicitly instructed to do so?
> >

[Med] Agree. This is deployment-specific. The client will do so only if it is "explicitly instructed".

> significant obstacle to real-life deployment.

[Med] Again, this is one deployment model among others. The intent is not to require it, but consider that this model may exist. 

> NAT
> aside and focus on the NAT case.
> >
> > (1) The DOTS client inserts in the core message the IP address/port it
> uses to send the request to the DOTS server. Upon receipt of the request
> by the DOTS server, it checks if the enclosed IP address/port match the
> source IP address/port of the received packet. If yes, the server sets in
> the response a dedicated parameter to indicate that a translator is
> detected on-path.
> >
> > (2) The DOTS server inserts systematically the source IP address/port in
> a response to a message from a DOTS client. Upon receipt of that response,
> the DOTS client compares the enclosed address/port with the ones it used
> to send the request to detect any mismatch.
> administrative
> different
> >>>> administrative domains to respective turn mitigation on (domain 1)
> and
> >> off
> this

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Mon, 30 Oct 2017 18:58:08 +0000

> On Oct 26, 2017, at 1:37 PM, Flemming Andreasen <[email-masked]> wrote:
> 
> ...
> That seems useful to me, however we may need to couple that with the client unilaterally increasing the rate when it's under attack to ensure bi-directional communication is still possible.

Below is the SIG-003 proposed text for -07:

   SIG-003  Channel Health Monitoring: DOTS agents MUST support exchange
      of heartbeat messages over the signal channel to monitor channel
      health.  Peer DOTS agents SHOULD regularly send heartbeats to each
      other while a mitigation request is active.  The heartbeat
      interval during active mitigation is not specified, but SHOULD be
      frequent enough to maintain any on-path NAT bindings during
      mitigation.

      To support scenarios in which loss of heartbeat is used to trigger
      mitigation, and to keep the channel active, DOTS clients MAY
      solicit heartbeat exchanges after successful mutual
      authentication.  When DOTS agents are exchanging heartbeats and no
      mitigation request is active, either agent MAY request changes to
      the heartbeat rate.  For example, a DOTS server might want to
      delay or cease heartbeat exchanges when an active DOTS client has
      not requested mitigation, in order to control load.

      Following mutual authentication, a signal channel MUST be
      considered active until a DOTS agent explicitly ends the session,
      or either DOTS agent fails to receive heartbeats from the other
      after a mutually agreed upon timeout period has elapsed.

andrew

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 30 Oct 2017 19:24:16 -0000

Hi Andrew,

As per the discussion ' [Dots] Full Pipe Scenario' about handling situations
with a full pipe dropping all traffic between the DOTS server and DOTS
client where the heartbeat request can still be seen by the DOTS server, the
DOTS Signal draft has been updated by Tiru with (3 paragraphs):-

"In case of a volumetric DDoS attack saturating the incoming link to the
DOTS client, all traffic from the DOTS server to the DOTS client will likely
be dropped, although the DOTS server receives heartbeat requests and DOTS
messages from the DOTS client.
In this scenario, the DOTS agents MUST behave differently to handle message
transmission and DOTS session liveliness during link saturation :

* The DOTS client MUST NOT consider the DOTS session terminated even after
maximum "missing-hb-allowed" threshold is reached. DOTS client SHOULD
continue to use the current DOTS session, and send heartbeat requests over
the current DOTS session, so the DOTS server knows the DOTS client has not
disconnected the DOTS session. After the maximum "missing-hb-allowed"
threshold is reached, the DOTS client SHOULD try (D)TLS session resumption.
The DOTS client SHOULD send mitigation requests over the current DOTS
session, and in parallel, try (D)TLS session resumption or 0-RTT mode in
DTLS 1.3 to piggyback the mitigation request in the ClientHello message.
Once the link is no longer statured, if traffic from the DOTS server reaches
the DOTS client over the current DOTS session, the DOTS client can stop
(D)TLS session resumption or if (D)TLS session resumption is successful then
disconnect the current DOTS session.

* If the DOTS server does not receive any traffic from the DOTS client, then
the DOTS server sends heartbeat requests to the DOTS client and if
"trigger-mitigation" is set to "false", then trigger DDoS mitigation after
maximum "missing-hb-allowed" threshold is reached."

This is in partial conflict with your suggestion (last half of final
paragraph) of  :-

"     Following mutual authentication, a signal channel MUST be
      considered active until a DOTS agent explicitly ends the session,
      or either DOTS agent fails to receive heartbeats from the other
      after a mutually agreed upon timeout period has elapsed."

I'm not sure of the best way to reword this conflict.  

Regards

Jon

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of
Mortensen, Andrew
Sent: 30 October 2017 18:58
To: Flemming Andreasen
Cc: Jon Shallow; Konda, Tirumaleswar Reddy; [email-masked];
[email-masked]; Dave Dolson
Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06))

andrew

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Mon, 30 Oct 2017 21:21:05 +0000

> On Oct 30, 2017, at 3:24 PM, Jon Shallow <[email-masked]> wrote:
> 
> …snip…
> 

Thanks Jon. I agree these need to be reconciled. We’ll also need to reconsider Section 5.6 of the signal channel draft given the added text on signaling over a saturated in-bound link:

5.6.  Heartbeat Mechanism

That seems more closely aligned with the phrasing in SIG-003 than the additions covering heartbeats during volumetric inbound attack. In the attempt to account for heartbeat loss during a volumetric attack, the new additions don’t seem to be accounting for how to decide when a client-initiated mitigation is orphaned, e.g., due to DOTS client reboot.

To try to make room for a resolution in the signal channel draft, here’s a stab at rewording the last paragraph of SIG-003:

  Following mutual authentication, a signal channel MUST be considered active
  until a DOTS agent explicitly ends the session, or either DOTS agent fails to
  receive heartbeats from the other after a mutually agreed upon timeout period
  has elapsed. Because heartbeat loss is much more likely during volumetric
  attack, DOTS agents SHOULD avoid signal channel termination when mitigation
  is active and heartbeats are not received by either DOTS agent for an extended
  period. In such circumstances, DOTS clients MAY attempt to reestablish the
  signal channel. DOTS servers SHOULD monitor the attack, using feedback from
  the mitigator and other available sources, and MAY use the absence of attack
  traffic and lack of client heartbeats as an indication the signal channel is
  defunct.

I will proceed with publishing -07 containing something very similar to the above while we continue this discussion.

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 31 Oct 2017 08:58:40 +0000

> From: Mortensen, Andrew [mailto:[email-masked]]
> Sent: Tuesday, October 31, 2017 2:51 AM
> To: Jon Shallow <[email-masked]>
> Cc: [email-masked]; Konda, Tirumaleswar Reddy
> <[email-masked]>
> > * If the DOTS server does not receive any traffic from the DOTS
> > client, then the DOTS server sends heartbeat requests to the DOTS
> > client and if "trigger-mitigation" is set to "false", then trigger
> > DDoS mitigation after maximum "missing-hb-allowed" threshold is
> reached."
> >
> Thanks Jon. I agree these need to be reconciled. We’ll also need to
> reconsider Section 5.6 of the signal channel draft given the added text on
> signaling over a saturated in-bound link:
> 
> 5.6.  Heartbeat Mechanism
> 
> That seems more closely aligned with the phrasing in SIG-003 than the
> additions covering heartbeats during volumetric inbound attack. In the
> attempt to account for heartbeat loss during a volumetric attack, the new
> additions don’t seem to be accounting for how to decide when a client-
> initiated mitigation is orphaned, e.g., due to DOTS client reboot.

No, the updated text handles the above scenario. In case of saturated incoming link to the DOTS client, If the DOTS server does not receive any traffic from the peer DOTS client, then the DOTS server sends heartbeat requests to the DOTS client and if “trigger-mitigation” is set to “false”, then trigger DDoS mitigation after maximum "missing-hb-allowed" threshold is reached. 

-Tiru

> 
> To try to make room for a resolution in the signal channel draft, here’s a stab
> at rewording the last paragraph of SIG-003:
>