Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt

From: [email-masked]
Date: Tue, 19 Dec 2017 07:19:28 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.

        Title           : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
        Authors         : Tirumaleswar Reddy
                          Mohamed Boucadair
                          Prashanth Patil
                          Andrew Mortensen
                          Nik Teague
	Filename        : draft-ietf-dots-signal-channel-14.txt
	Pages           : 84
	Date            : 2017-12-19

Abstract:
   This document specifies the DOTS signal channel, a protocol for
   signaling the need for protection against Distributed Denial-of-
   Service (DDoS) attacks to a server capable of enabling network
   traffic mitigation on behalf of the requesting client.

   A companion document defines the DOTS data channel, a separate
   reliable communication layer for DOTS management and configuration
   purposes.

Editorial Note (To be removed by RFC Editor)

   Please update these statements with the RFC number to be assigned to
   this document:

   o  "This version of this YANG module is part of RFC XXXX;"

   o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
      (DOTS) Signal Channel";

   o  "| 3.00 | Alternate server | [RFCXXXX] |"

   o  reference: RFC XXXX

   o  This RFC

   Please update TBD statements with the port number to be assigned to
   DOTS Signal Channel Protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14
https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-14

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Tue, 19 Dec 2017 15:34:37 +0000

Re-,

This version integrates the outcomes of the mailing list discussion, in particular:
- Multiple client-id values does not mean anymore that multiple GWs have injected a value each. 
- Introduce attack-time-config and peace-time-config
- Add some text to suggest dots servers to send heartbeats immediately after receiving the one from the peer dots client. 
- Refreshing the configuration must not occur during attack times. 

The document is still using client-side and server-side DOTS GW terms. The text will be aligned with the requirements I-D.

Jon, please double check. 

All, please review and share your comments.

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de internet-
> [email-masked]
> Envoyé : mardi 19 décembre 2017 16:19
> À : [email-masked]
> Cc : [email-masked]
> Objet : [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 19 Dec 2017 15:55:00 +0000

I don't think the DOTS signal channel draft should enhance the functionality of DOTS gateway to aggregate mitigation requests, it's not discussed in any of the requirements and architecture drafts.
Why should the DOTS server send heartbeat request immediately after receiving the heartbeat request from the client, DOTS server anyways will send a heartbeat response (CoAP Reset message) for the heartbeat request from the client and that will keep the NAT binding alive. 
Why cannot the client-identifier be generated by client-side DOTS gateway (I don't understand the privacy problem, if the client-identifier does not reveal the actual DOTS client identity) ?

-Tiru

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, December 19, 2017 9:05 PM
> To: [email-masked]
> Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt
> 
> Re-,
> 
> - Add some text to suggest dots servers to send heartbeats immediately
> after receiving the one from the peer dots client.
> The document is still using client-side and server-side DOTS GW terms. The
> text will be aligned with the requirements I-D.
> 
> > [email-masked] Envoyé : mardi 19 décembre 2017 16:19 À :
> > [email-masked] Cc : [email-masked] Objet : [Dots] I-D Action:
> > draft-ietf-dots-signal-channel-14.txt
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org.
> >

---

From: <[email-masked]>
Date: Tue, 19 Dec 2017 16:13:52 +0000

Hi Tiru, 

Please see inline. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : mardi 19 décembre 2017 16:55
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt
> 
> I don't think the DOTS signal channel draft should enhance the
> functionality of DOTS gateway to aggregate mitigation requests, it's not
> discussed in any of the requirements and architecture drafts.

[Med] IMO, it is out of the scope of the document to recommend or preclude this. The main outcome of the discussion is that we don't have anymore a confusion to interpret the presence of multiple client-ids. The only provision is when a gateway decides to aggregate. Why and how aggregation is done is really out of scope. 

> Why should the DOTS server send heartbeat request immediately after
> receiving the heartbeat request from the client, DOTS server anyways will
> send a heartbeat response (CoAP Reset message) for the heartbeat request
> from the client and that will keep the NAT binding alive.

[Med] The problem is not in that direction. The problem is when the server sends a heartbeat request to the client but no mapping is found in the translator/firewall. Sending immediately the probe while the NAT mapping is likely to be open will ease nat traversal. This is a MAY. A serever is not obliged to follow it. 

> Why cannot the client-identifier be generated by client-side DOTS gateway
> (I don't understand the privacy problem, if the client-identifier does not
> reveal the actual DOTS client identity) ?

[Med] because, e.g., "DOTS server can fully trust the server-side gateway but cannot fully trust the client-side gateway". 

A network operator can decide to deploy multiple DOTS clients and hide the identity of these clients. To that purpose, it can enable GW in its domain to hide those clients.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 19 Dec 2017 16:51:16 +0000

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, December 19, 2017 9:44 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]
> Subject: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt
> 
> Hi Tiru,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > À : BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet : RE: [Dots] I-D
> > Action: draft-ietf-dots-signal-channel-14.txt
> >
> > functionality of DOTS gateway to aggregate mitigation requests, it's
> > not discussed in any of the requirements and architecture drafts.
> 
> [Med] IMO, it is out of the scope of the document to recommend or
> preclude this. 

Agreed. 

> The main outcome of the discussion is that we don't have
> anymore a confusion to interpret the presence of multiple client-ids. The
> only provision is when a gateway decides to aggregate. Why and how
> aggregation is done is really out of scope.

The problem is the draft is now discussing how the DOTS gateway will generate multiple client-ids when aggregating mitigation requests from multiple DOTS clients. It's enhancing the scope of the DOTS gateway to handle a lot more functionality, currently not covered and discussed in the requirements and architecture drafts. 

> > receiving the heartbeat request from the client, DOTS server anyways
> > will send a heartbeat response (CoAP Reset message) for the heartbeat
> > request from the client and that will keep the NAT binding alive.
> 
> [Med] The problem is not in that direction. The problem is when the server
> sends a heartbeat request to the client but no mapping is found in the
> translator/firewall. Sending immediately the probe while the NAT mapping is
> likely to be open will ease nat traversal. This is a MAY. A serever is not obliged
> to follow it.

Yes, I understand but it looks un-necessary on the DOTS server to immediately send a probe. Can you explain a scenario how the client initiated heartbeat exchange is not sufficient to keep its NAT binding alive ?
(see https://tools.ietf.org/html/rfc5245#section-10, keepalives to keep NAT bindings is unidirectional only and don't invoke a response from the peer). 
> 
> > Why cannot the client-identifier be generated by client-side DOTS
> > gateway (I don't understand the privacy problem, if the
> > client-identifier does not reveal the actual DOTS client identity) ?
> 
> [Med] because, e.g., "DOTS server can fully trust the server-side gateway
> but cannot fully trust the client-side gateway".

Yes, but client-identifier can also be used to detect and resolve collision (e.g. two DOTS clients using the same alias-name).  How will collisions be handled with this change ?

-Tiru

> 
> A network operator can decide to deploy multiple DOTS clients and hide the
> identity of these clients. To that purpose, it can enable GW in its domain to
> hide those clients.
> 
> >
> > -Tiru
> >
> > > This version integrates the outcomes of the mailing list discussion,
> > > in
> > > particular:
> > > - Add some text to suggest dots servers to send heartbeats
> > > immediately after receiving the one from the peer dots client.
> > > >    Please update these statements with the RFC number to be
> > > > assigned
> > to
> > > >    this document:
> > > >
> > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-chann
> > > > el-1
> > > > 4
> > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 19 Dec 2017 17:26:54 -0000

Hi Tiru / Med,

See inline [Jon].

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 19 December 2017 16:51
To: [email-masked]; [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt

> > Envoyé : mardi 19 décembre 2017 16:55 À : BOUCADAIR Mohamed IMT/OLN; 
> > [email-masked] Objet : RE: [Dots] I-D

Agreed. 

> The main outcome of the discussion is that we don't have anymore a 
> confusion to interpret the presence of multiple client-ids. The only 
> provision is when a gateway decides to aggregate. Why and how 

The problem is the draft is now discussing how the DOTS gateway will
generate multiple client-ids when aggregating mitigation requests from
multiple DOTS clients. It's enhancing the scope of the DOTS gateway to
handle a lot more functionality, currently not covered and discussed in the
requirements and architecture drafts. 

[Jon] As discussed elsewhere, to me aggregation of mitigation-id /
alias-name / filter requests is a real challenge and I can only think of a
couple of do-able scenarios out of a lot of different aggregation scenarios.
I am in agreement with you Tiru that aggregation is really all about session
aggregation, but recognize that someone may want to attempt to do this
aggregation of mitigation-id / alias-name / filter requests
[Jon] I have mentioned in another discussion
NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really read (which
may be where some of the confusion comes in)
Figure 7: Client-Side Gateway with session Aggregation
Figure 8: Client-Side Gateway without session Aggregation
Figure 9: Server-Side Gateway with session Aggregation
Figure 10: Server-Side Gateway without session Aggregation

> > will send a heartbeat response (CoAP Reset message) for the 
> > heartbeat request from the client and that will keep the NAT binding
alive.
> 
> [Med] The problem is not in that direction. The problem is when the 
> server sends a heartbeat request to the client but no mapping is found 
> in the translator/firewall. Sending immediately the probe while the 
> NAT mapping is likely to be open will ease nat traversal. This is a 
> MAY. A serever is not obliged to follow it.

Yes, I understand but it looks un-necessary on the DOTS server to
immediately send a probe. Can you explain a scenario how the client
initiated heartbeat exchange is not sufficient to keep its NAT binding alive
?
(see https://tools.ietf.org/html/rfc5245#section-10, keepalives to keep NAT
bindings is unidirectional only and don't invoke a response from the peer).

[Jon] If the heartbeat frequency is, say, 10 minutes (a time longer than the
NAT session timeout), and the DOTS server and DOTS client drift in their
time to re-transmit, you could end up with the client triggering at time +0,
+10, +20 etc. and the server triggering at +5, +15, +25 etc.  When the
server comes to transmit its heartbeat, there is no NAT session - and hence
failure.  If the DOTS server heartbeat transmission is synchronized to the
DOTS client, then there is no issue with NAT and the requirement that both
server and client transmit heartbeats to network test is fulfilled.
[Jon] There is a desire for the heartbeat rate to have long intervals in
peace-time - and sending keep-alives at a higher rate to keep NAT "warm"
defeats this.
 
> [Med] because, e.g., "DOTS server can fully trust the server-side 
> gateway but cannot fully trust the client-side gateway".

Yes, but client-identifier can also be used to detect and resolve collision
(e.g. two DOTS clients using the same alias-name).  How will collisions be
handled with this change ?

[Jon] If we are NOT adding in defined intelligence to a DOTS gateway as to
how to aggregate mitigation-id/alias-name/filters etc., then the
client-identifiers (to me) are the only easy way to avoid collisions with
the names of mitigation-ids, alias-names and filters.  Otherwise, the DOTS
gateway will need to "mangle" mitigation-id/alias-name/filters into an
unique definition per DOTS client before passing them on upstream.
Actually, client-identifier + mitigation-id is an example of the mangled
entity...

-Tiru

> 
> A network operator can decide to deploy multiple DOTS clients and hide 
> the identity of these clients. To that purpose, it can enable GW in 
> its domain to hide those clients.
> 
> >
> > -Tiru
> >
> > > This version integrates the outcomes of the mailing list 
> > > discussion, in
> > > particular:
> > > >    Please update TBD statements with the port number to be 
> > > > assigned
> to
> > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel
> > > > -1
> > > > 4
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from the time 
> > > > of submission until the htmlized version and diff are available 
> > > > at tools.ietf.org.
> > > >

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Tue, 19 Dec 2017 21:04:47 +0000

Thanks, Med. One comment after a quick skim of the updated draft.

I’m concerned about designating attack-time and peace-time config. A DOTS client is free to deal with a DDoS attack without requesting upstream mitigation, or for various reasons may withdraw an active mitigation request during an attack. The “attack-time” term to me implies something always taking place when an attack is active, regardless of whether the DOTS client has request mitigation. The distinction we want to draw is really between a config enabled when mitigation is requested/active, and when the client has not requested mitigation.

I’m not sure what the best terminology is for this distinction. Something like “idle-config” and “mitigation-config” get closer to the spirit of what I think we want, though.

andrew

On Dec 19, 2017, at 10:34 AM, [email-masked]<mailto:[email-masked]> wrote:

Re-,

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 19 Dec 2017 21:22:09 -0000

Hi Andrew,

Does “idle-config” and “mitigating-config” work for you?

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Mortensen, Andrew
Sent: 19 December 2017 21:05
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt

andrew

On Dec 19, 2017, at 10:34 AM, [email-masked] wrote:

Re-,

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Tue, 19 Dec 2017 21:41:46 +0000

On Dec 19, 2017, at 4:22 PM, Jon Shallow <[email-masked]<mailto:[email-masked]>> wrote:

Hi Andrew,

They do.

andrew

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Mortensen, Andrew
Sent: 19 December 2017 21:05
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt

andrew

Re-,

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 20 Dec 2017 03:24:03 +0000

Hi Jon,

Please see inline

> From: Jon Shallow [mailto:[email-masked]]
> Sent: Tuesday, December 19, 2017 10:57 PM
> <[email-masked]>;
> [email-masked]; [email-masked]
> From: Dots [mailto: [email-masked]] On Behalf Of Konda,
> Tirumaleswar Reddy
> [Jon] As discussed elsewhere, to me aggregation of mitigation-id / alias-
> name / filter requests is a real challenge and I can only think of a couple of
> do-able scenarios out of a lot of different aggregation scenarios.

Agreed. DOTS architecture draft should be updated to clarify the scope of aggregation is only at session level and 
remove text from the DOTS signal channel draft discussing aggregation of mitigation requests.

> may be where some of the confusion comes in) Figure 7: Client-Side
> Gateway with session Aggregation Figure 8: Client-Side Gateway without
> session Aggregation Figure 9: Server-Side Gateway with session Aggregation
> immediately send a probe. Can you explain a scenario how the client initiated
> heartbeat exchange is not sufficient to keep its NAT binding alive ?
> NAT session timeout), and the DOTS server and DOTS client drift in their time
> to re-transmit, you could end up with the client triggering at time +0,

If the heartbeat frequency is higher than the NAT session timeout, the heartbeat request packet from the DOTS client could get a different public source IP address and/or a different public source port allocated by NAT and the packet will be rejected by the DOTS server (no corresponding DTLS state associated with the 5-tuple). 

It is the responsibility of the DOTS client to maintain its NAT binding and not the problem of the DOTS server.  

> [Jon] There is a desire for the heartbeat rate to have long intervals in peace-
> time - and sending keep-alives at a higher rate to keep NAT "warm"
> defeats this.
> 
> >
> Yes, but client-identifier can also be used to detect and resolve collision (e.g.
> two DOTS clients using the same alias-name).  How will collisions be handled
> with this change ?
> 
> how to aggregate mitigation-id/alias-name/filters etc., then the client-
> identifiers (to me) are the only easy way to avoid collisions with the names of
> mitigation-ids, alias-names and filters.  Otherwise, the DOTS gateway will
> need to "mangle" mitigation-id/alias-name/filters into an unique definition
> per DOTS client before passing them on upstream.
> Actually, client-identifier + mitigation-id is an example of the mangled entity...

Agreed, the text needs to reverted back to allow both client-side and server-side gateways to add/update client-identifier. 

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Wed, 20 Dec 2017 07:11:03 +0000

Hi Tiru, 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 04:24
> À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]
> alias-

[Med] Updating the scope in the arch draft won't solve interoperability problems that may raise in the future if a gateways is designed (for its own reasons) to aggregate requests. With the current approach in -14, the server has a clear meaning how to interpret multiple client-ids. We don't have any more an ambiguity. 

Further, a gateway designer won't "play" with multiple client-ids for other purposes, because he/she is aware that the server has already a clear meaning for it. This is really good for interoperability. 

I still don't think we have arguments to recommend nor to preclude gateways from aggregating requests. Some complexity will be induced by such designs, Sure. But one may argue that aggregation will solve a problem during recursive signaling, or during massive attacks received on a large number of networks that are assigned with aggregable prefixes, etc. Who knows?

> initiated
> time
> If the heartbeat frequency is higher than the NAT session timeout, the
> heartbeat request packet from the DOTS client could get a different public
> source IP address and/or a different public source port allocated by NAT
> and the packet will be rejected by the DOTS server (no corresponding DTLS
> state associated with the 5-tuple).
> 

[Med] Tiru, this is a distinct problem. The initial optimization is about a server sending a probe when it is likely that the mapping used by the packet sent by the DOTS client is still active. If the server waited too long, that mapping would be removed from the table. Of course, if some validation failed, the received probe request from the client will be rejected at the first place and this optimization won't be followed. 

> peace-
> Agreed, the text needs to reverted back to allow both client-side and
> server-side gateways to add/update client-identifier.

[Med] Please note that the draft allows to relax the constraint on the client-side GW:

   In order to prevent leaking internal information outside a client-
   domain, DOTS gateways located in the client-domain SHOULD NOT reveal
   the identification information that pertains to internal DOTS clients
   (client-identifier) unless explicitly configured to do so.

But...

When a client-side GW inserts that information, it won't be trusted by the server domain. It will be handled as any client-id that is supplied directly by a client. 

** A server or a server-side gateway does not know if the peer DOTS agent is a GW or a pure DOTS client. ** 

The previous text is broken, we need to fix it. IMHO, the text has to be consistent:

(1) Either it should be updated to allow any client agent (including DOTS clients) to insert the identifier, but still it is up to the server-side may control it. The issue I have with this approach is: what is the purpose of inserting this identifier by a client? We need solid arguments for this. 

(2) Either we disallow it for obvious reasons (the peer server-side agent has sufficient information to identify the peer client agent and enforce policies accordingly). Supplying additional information won't be any way for identification and authorization.  

> > > > > The document is still using client-side and server-side DOTS GW
> terms.
> > > > The
> > > > > >         Title           : Distributed Denial-of-Service Open
> Threat
> > > > > > Signaling (DOTS) Signal Channel

---

From: <[email-masked]>
Date: Wed, 20 Dec 2017 07:12:07 +0000

Hi Andrew, Jon,

This works for me, too.

Cheers,
Med

De : Mortensen, Andrew [mailto:[email-masked]]
Envoyé : mardi 19 décembre 2017 22:42
À : Jon Shallow
Cc : dots; BOUCADAIR Mohamed IMT/OLN
Objet : Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt

Hi Andrew,

They do.

andrew

Cc: [email-masked]<mailto:[email-masked]>

andrew

Re-,

---

From: <[email-masked]>
Date: Wed, 20 Dec 2017 07:28:37 +0000

Tiru, 

Please see inline. 

Cheers,
Med

> Envoyé : mardi 19 décembre 2017 17:51
> gateway
> Yes, but client-identifier can also be used to detect and resolve
> collision (e.g. two DOTS clients using the same alias-name).  How will
> collisions be handled with this change ?
> 

[Med] The question is whether we need to handle this as a bug or feature: e.g., 
* DOTS clients, which belong to the same domain, using the same alias can be handled as part of conflict management and be reported by the final server as such.
* The client-side DOTS gateway may be instructed to detect locally collision/conflicts and notify the responsible clients locally. Collisions are not leaked to the server domain.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 20 Dec 2017 09:06:42 +0000

> Sent: Wednesday, December 20, 2017 12:59 PM
> > > > Envoyé : mardi 19 décembre 2017 16:55 À : BOUCADAIR Mohamed
> > > > IMT/OLN; [email-masked] Objet : RE: [Dots] I-D
> > > > functionality of DOTS gateway to aggregate mitigation requests,
> > > > it's not discussed in any of the requirements and architecture drafts.
> > >
> * DOTS clients, which belong to the same domain, using the same alias can be
> handled as part of conflict management and be reported by the final server
> as such.
> * The client-side DOTS gateway may be instructed to detect locally
> collision/conflicts and notify the responsible clients locally. Collisions are not
> leaked to the server domain.

Please look into 3.1.8 and 3.2.2 in dots use cases spec, there could be hundreds of DOTS clients and it does not look like a good approach to keep rejecting requests just because they had the same alias-name. We discussed this problem in the mailing list before agreeing to use the client-identifier as a list to resolve collisions (see https://mailarchive.ietf.org/arch/msg/dots/qqJ_aV8zDuwCP84qtJEmP-oIRKA). 

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 20 Dec 2017 09:10:25 +0000

Hi Med,

Please see inline

> Sent: Wednesday, December 20, 2017 12:41 PM
> <[email-masked]>; Jon Shallow <supjps-
> [email-masked]>; [email-masked]
> > Envoyé : mercredi 20 décembre 2017 04:24 À : Jon Shallow; BOUCADAIR
> > Mohamed IMT/OLN; [email-masked] Objet : RE: [Dots] I-D Action:
> > > > confusion to interpret the presence of multiple client-ids. The
> > > generate multiple client-ids when aggregating mitigation requests
> > > from multiple DOTS clients. It's enhancing the scope of the DOTS
> > > gateway to handle a lot more functionality, currently not covered
> > > and discussed in
> > the
> > > aggregation, but recognize that someone may want to attempt to do
> > > this aggregation of mitigation-id / alias-name / filter requests
> >
> > Agreed. DOTS architecture draft should be updated to clarify the scope
> > of aggregation is only at session level and remove text from the DOTS
> > signal channel draft discussing aggregation of mitigation requests.
> 
> [Med] Updating the scope in the arch draft won't solve interoperability
> problems that may raise in the future if a gateways is designed (for its own
> reasons) to aggregate requests. With the current approach in -14, the server
> has a clear meaning how to interpret multiple client-ids. We don't have any
> more an ambiguity.

No, multiple client-ids is also required to handle collisions. 

> 
> Further, a gateway designer won't "play" with multiple client-ids for other
> purposes, because he/she is aware that the server has already a clear
> meaning for it. This is really good for interoperability.
> 
> I still don't think we have arguments to recommend nor to preclude
> gateways from aggregating requests. Some complexity will be induced by
> such designs, Sure. But one may argue that aggregation will solve a problem
> during recursive signaling, or during massive attacks received on a large
> number of networks that are assigned with aggregable prefixes, etc. Who
> knows?

If future specifications decide to aggregate mitigation requests, the DOTS gateway can indicate that the mitigation request is aggregated, it can convey a new parameter to convey the same to the upstream DOTS servers. 
No need for the draft to discuss a undefined behavior of the DOTS gateway. 

> > > NOTE: ietf-dots-architecture Figure 7, 8, 9 and 10 should really
> > > read
> > (which
> > > Gateway with session Aggregation Figure 8: Client-Side Gateway
> > > without session Aggregation Figure 9: Server-Side Gateway with
> > > session
> > Aggregation
> > > > > Why should the DOTS server send heartbeat request immediately
> > > > > after receiving the heartbeat request from the client, DOTS
> > > > > server anyways will send a heartbeat response (CoAP Reset
> > > > > message) for the heartbeat request from the client and that will
> > > > > keep the NAT binding
> > > alive.
> > > >
> > > > [Med] The problem is not in that direction. The problem is when
> > > > the server sends a heartbeat request to the client but no mapping
> > > > is found in the translator/firewall. Sending immediately the probe
> > > > while the NAT mapping is likely to be open will ease nat
> > > > traversal. This is a MAY. A serever is not obliged to follow it.
> > >
> > > (see https://tools.ietf.org/html/rfc5245#section-10, keepalives to
> > > keep
> > NAT
> > > [Jon] If the heartbeat frequency is, say, 10 minutes (a time longer
> > > than
> > the
> > > +10, +20 etc. and the server triggering at +5, +15, +25 etc.  When
> > > +the
> > > server comes to transmit its heartbeat, there is no NAT session -
> > > and
> > hence
> > > failure.  If the DOTS server heartbeat transmission is synchronized
> > > to
> > the
> > > DOTS client, then there is no issue with NAT and the requirement
> > > that
> > both
> > heartbeat request packet from the DOTS client could get a different
> > public source IP address and/or a different public source port
> > allocated by NAT and the packet will be rejected by the DOTS server
> > (no corresponding DTLS state associated with the 5-tuple).
> >
> 
> [Med] Tiru, this is a distinct problem. The initial optimization is about a server
> sending a probe when it is likely that the mapping used by the packet sent by
> the DOTS client is still active. 

The server is already sending a heartbeat response (RST message) in response to a heartbeat request from the DOTS client.  Protocols like ICE used by browsers for WebRTC, send STUN Binding Indication to keep NAT the binding alive and that are send-and-forget, and do not evoke a response (see https://tools.ietf.org/html/rfc5245#section-10). 

> If the server waited too long, that mapping
> would be removed from the table. Of course, if some validation failed, the
> received probe request from the client will be rejected at the first place and
> this optimization won't be followed.
> 
> > It is the responsibility of the DOTS client to maintain its NAT
> > binding and not the problem of the DOTS server.
> >
> > > > > Why cannot the client-identifier be generated by client-side
> > > > > DOTS gateway (I don't understand the privacy problem, if the
> > collision (e.g.
> > > [Jon] If we are NOT adding in defined intelligence to a DOTS gateway
> > > as
> > to
> > > client- identifiers (to me) are the only easy way to avoid
> > > collisions with the
> > names of
> > > mitigation-ids, alias-names and filters.  Otherwise, the DOTS
> > > gateway
> > will
> When a client-side GW inserts that information, it won't be trusted by the
> server domain. It will be handled as any client-id that is supplied directly by a
> client.

Client-identifier list is only required to uniquely identify the request (e.g. alias-name) and not for any other purpose but the 'client-identifier' value to the end of the 'client-identifier' list inserted by the server-side DOTS-gateway can be trusted by the DOTS server for policy enforcement. 

> a GW or a pure DOTS client. **

In certain cases the server-side gateway may know if the peer DOTS agent is a GW (e.g. recursive signaling, MSSP as an end-customer requesting overflow DDoS mitigation
assistance from other MSSPs). 

-Tiru

> (1) Either it should be updated to allow any client agent (including DOTS
> clients) to insert the identifier, but still it is up to the server-side may control
> it. The issue I have with this approach is: what is the purpose of inserting this
> identifier by a client? We need solid arguments for this.

> 
> (2) Either we disallow it for obvious reasons (the peer server-side agent has
> sufficient information to identify the peer client agent and enforce policies
> accordingly). Supplying additional information won't be any way for
> identification and authorization.
> 
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > -Tiru
> > >
> > > >
> > > > A network operator can decide to deploy multiple DOTS clients and
> > > > hide the identity of these clients. To that purpose, it can enable
> > > > GW in its domain to hide those clients.
> > > >
> > > > >
> > > > > -Tiru
> > > > >
> > > > > > > De : Dots [mailto:[email-masked]] De la part de
> > > > > > > internet- [email-masked] Envoyé : mardi 19 décembre 2017 16:19
> À :
> > > > > > >    This document specifies the DOTS signal channel, a
> > > > > > > protocol
> > for
> > > > > > >    signaling the need for protection against Distributed
> > > > > > > Denial-
> > of-
> > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal
> > > > > > > -cha
> > > > > > > nn
> > > > > > > el-1
> > > > > > > 4
> > > > > > >
> > > > > > > Please note that it may take a couple of minutes from the
> > > > > > > time of submission until the htmlized version and diff are
> > > > > > > available at tools.ietf.org.
> > > > > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 21 Dec 2017 14:05:23 -0000

Hi Med,

Comments in my first pass through the -14 version

3. Design Overview

"in [RFC7951] combined with JSON/CBOR conversion rules in [RFC7049]. ."

Second trailing period not needed.

4.4.1. Request Mitigation

"Attributes with emty values" should read " Attributes with empty values"

4.5 DOTS Channel Session Configuration

Replace

If distinct configuration are
   used, DOTS agents MUST follow the appropriate configuration set as a

with (plural)

If distinct configurations are
   used, DOTS agents MUST follow the appropriate configuration set as a

4.5.2 Convey DOTS Signal Channel Session Configuration

I think config-interval should be defined in seconds - to be consistent with
lifetime, heartbeat-interval etc.

Replace

      If a non-null value of 'config-interval' is received by a DOTS
      agent, it has to issue a PUT request to refresh the configuration

with

      If a non-zero value of 'config-interval' is received by a DOTS
      client, it has to issue a PUT request to refresh the configuration

Replace (peace-time may now be idle-config, and attack-time-config may now
be mitigating-config)

   peace-time-config:   Set of configuration parameters to use during
      peacetime.  This attribute has the same structure as 'attack-time-
      config'.

With

   idle-config:   Set of configuration parameters to use during
      peacetime.  This attribute has the same structure as 'mitigating-
      config'.  If this parameter is not defined, then the peacetime
configuration 'idle-config' is assumed to be the same as
'mitigating-config'.

Figure 18: config-interval should have a current-value

Should Figure 19 include config-interval ?

5.1 Tree structure

Should 

          |     |        +--ro acl-name    ->
/ietf-acl:access-lists/acl/acl-name
          |     |        +--ro acl-type    ->
/ietf-acl:access-lists/acl/acl-type

Be (data channel definition is OK - other than perhaps 'set-name' really
should be name', and 'type' should be 'type' due to netmod-acl potential
changes)

          |     |        +--ro acl-name    ->
/ietf-dots-data-channel:access-lists/acl/name
          |     |        +--ro acl-type    -> /
ietf-dots-data-channel:access-lists/acl/type

'config-interval' also needs a current/min/max -value setting (as you have
in Figure 17) unless the DOTS server is going to control this absolutely.
Figure 18 will need updating as well.

yang:zero-based-counter64 is not supported by JSON (a JavaScript limitation
as I understand it)
RFC7159 6. Numbers 
   Note that when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
   sense that implementations will agree exactly on their numeric
   values.

5.2 YANG module

ack-random-factor was a float - and so current-value etc. subtypes of
ack-random-factor  should be floats, not int16.  I suggest that we use a
different name - i.e. current-value-decimal.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 19 December 2017 15:35
To: [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt

Re-,

This version integrates the outcomes of the mailing list discussion, in
particular:
- Multiple client-id values does not mean anymore that multiple GWs have
injected a value each. 
- Introduce attack-time-config and peace-time-config
- Add some text to suggest dots servers to send heartbeats immediately after
receiving the one from the peer dots client. 
- Refreshing the configuration must not occur during attack times. 

Cheers,
Med

---

From: <[email-masked]>
Date: Thu, 21 Dec 2017 14:06:43 +0000

Hi all, 

Tiru, Jon, and I organized a conf-call to discuss this issue. We agreed on the following:

* Introduce 'request-nonce' that will be used to prevent collisions. This parameter must be inserted by a DOTS client in all its requests and echoed by the server. It is valid for both signal and data channels.
* client-identifier will be renamed to reflect its actual usage: supply information about the client domain to the ultimate DOTS server for policy enforcement. It has nothing to do anymore with collisions detect. 
* As in -14, only server-side gateways are allowed to inject client-identifier. 

Unless there are objections, the draft will be updated accordingly. 

FWIW, you may find some information in slides 9/10/11/12/13 of the material available at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/DOTS%20Gateways-client%20identifier%20discussion.pdf 

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 10:07
> > [Med] The question is whether we need to handle this as a bug or
> feature:
> > e.g.,
> Please look into 3.1.8 and 3.2.2 in dots use cases spec, there could be
> hundreds of DOTS clients and it does not look like a good approach to keep
> rejecting requests just because they had the same alias-name. We discussed
> this problem in the mailing list before agreeing to use the client-
> identifier as a list to resolve collisions (see
> https://mailarchive.ietf.org/arch/msg/dots/qqJ_aV8zDuwCP84qtJEmP-oIRKA).
> 
> -Tiru

---

From: <[email-masked]>
Date: Thu, 21 Dec 2017 14:54:39 +0000

Re-,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : jeudi 21 décembre 2017 15:05

[Med] Already fixed in my local copy. Thanks. 

> "Attributes with emty values" should read " Attributes with empty values"

[Med] Idem as above. 

>    used, DOTS agents MUST follow the appropriate configuration set as a

[Med] Fixed.  

> lifetime, heartbeat-interval etc.

[Med] Works for me.  

>       client, it has to issue a PUT request to refresh the configuration

[Med] OK.

> configuration 'idle-config' is assumed to be the same as

[Med] We do already have a default behavior:

The DOTS agents MUST use the negotiated
   values for message transmission parameters and default values for
   non-negotiated message transmission parameters.

This means that the default values will be used if not specified. 

If the same config is to be used for both idle-mitigation, both should be returned. 

Actually, this is what I meant in this discussion:

==
[Jon]  A minor comment - is the following more logical and more descriptive?
[Med] I considered this but favored the other one because it is more compact. For example, when the same config is to be used for both peace/attack times, you just need to omit "peace-time-config", while you need to include the same value twice for the other proposal. Do you have a strong preference?
====
 
> Should Figure 19 include config-interval ?

[Med] This is on purpose to indicate that config-interval can be omitted.

> ietf-dots-data-channel:access-lists/acl/type

[Med] No, the initial one is correct. 

> Figure 18 will need updating as well.

[Med] Good catch. Figure 17 is wrong. 

There is no value for having this for config-interval, because it is always up to the server to decide which value to put. 

I will update figures 17/18 accordingly. 

>    sense that implementations will agree exactly on their numeric

[Med] I guess we need to encode them as strings. RFC7493#section-2.2 says the following: 

   An I-JSON sender cannot expect a receiver to treat an integer whose
   absolute value is greater than 9007199254740991 (i.e., that is
   outside the range [-(2**53)+1, (2**53)-1]) as an exact value.

   For applications that require the exact interchange of numbers with
   greater magnitude or precision, it is RECOMMENDED to encode them in
   JSON string values.  This requires that the receiving program
   understand the intended semantic of the value.  An example would be
   64-bit integers, even though modern hardware can deal with them,
   because of the limited scope of JavaScript numbers.

> different name - i.e. current-value-decimal.

[Med] I guess you are referring to section 6. 
 
It seems that we will need *-value for major type 7.

> after

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 21 Dec 2017 16:49:05 -0000

Hi Med,

See inline [Jon].

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 21 December 2017 14:55
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt

Re-,

Please see inline. 

Cheers,
Med

[Med] Idem as above. 

[Med] Fixed.  

> I think config-interval should be defined in seconds - to be 
> consistent with lifetime, heartbeat-interval etc.

[Med] Works for me.  

>       client, it has to issue a PUT request to refresh the 

[Med] OK.
[Jon] Not yet updated

> Replace (peace-time may now be idle-config, and attack-time-config may 
> now be mitigating-config)
> 

If the same config is to be used for both idle-mitigation, both should be
returned. 

==
[Jon]  A minor comment - is the following more logical and more descriptive?
[Med] I considered this but favored the other one because it is more
compact. For example, when the same config is to be used for both
peace/attack times, you just need to omit "peace-time-config", while you
need to include the same value twice for the other proposal. Do you have a
strong preference?
====
[Jon] OK - having both is fine by me - and if something is not defined then
it takes on the default values.

[Jon] OK

> Be (data channel definition is OK - other than perhaps 'set-name' 
> really should be name', and 'type' should be 'type' due to netmod-acl 
> potential
> changes)
> 
>           |     |        +--ro acl-name    ->

[Jon] OK

> 'config-interval' also needs a current/min/max -value setting (as you 
> have in Figure 17) unless the DOTS server is going to control this
absolutely.

There is no value for having this for config-interval, because it is always
up to the server to decide which value to put. 

I will update figures 17/18 accordingly.
[Jon] You currently have in your local copy draft config-interval only for
PUT, not GET, so config-interval is not under the control of the server.

> 
> yang:zero-based-counter64 is not supported by JSON (a JavaScript 
> limitation as I understand it)
> RFC7159 6. Numbers

[Med] I guess we need to encode them as strings. RFC7493#section-2.2 says
the following: 

[Jon] Oh - yuk - this means that there will be bloat in the COAP packet in
the 5 places where int64 (or uint64) are used.
[Jon] In all cases, I think that decimal64 will give us sufficient
precision, as well as handle the numbers getting very large (e.g. bytes
dropped).
[Jon] If we do go with the string version, then there has to be extra logic
(and context knowledge) to convert any JSON into 64bit numbers to do any
math on.
> ack-random-factor  should be floats, not int16.  I suggest that we use 
> a different name - i.e. current-value-decimal.
> 

It seems that we will need *-value for major type 7.
[Jon] Correct - I see that you have updated this in your local copy draft.

> The document is still using client-side and server-side DOTS GW terms. 
> The text will be aligned with the requirements I-D.
> 
> > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel
> > -1
> > 4
> >

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 22 Dec 2017 13:35:07 +0900

small nits in the CBOR mapping example were found:

4.4.1.  Request Mitigation
Figure 7: PUT for DOTS signal (CBOR)

line 4: client identifier
  18 20                             # unsigned(32)
  it must be:
  18 24                             # unsigned(36)

line 13: target-prefix
      04                          # unsigned(4)
  it must be:
     18 23                       # unsigned(35)

regards,
Kaname

On 2017/12/20 0:34, [email-masked] wrote:
>> submission