Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-11.txt

From: [email-masked]
Date: Mon, 18 Dec 2017 07:31:34 -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) Data Channel
        Authors         : Tirumaleswar Reddy
                          Mohamed Boucadair
                          Kaname Nishizuka
                          Liang Xia
                          Prashanth Patil
                          Andrew Mortensen
                          Nik Teague
	Filename        : draft-ietf-dots-data-channel-11.txt
	Pages           : 31
	Date            : 2017-12-18

Abstract:
   The document specifies a Distributed Denial-of-Service Open Threat
   Signaling (DOTS) data channel used for bulk exchange of data not
   easily or appropriately communicated through the DOTS signal channel
   under attack conditions.

   This is a companion document to the DOTS signal channel
   specification.

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) Data Channel";

   o  reference: RFC XXXX

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

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

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

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: Mon, 18 Dec 2017 15:37:27 +0000

Re-,

The main changes in this version are as follows:
- Remove target-ip because it is redundant with target-prefix
- Indicate that the order of establishing signal/data channel is implementation/deployment specific
- Mention that the signal channel I-D is the authoritative reference for manipulating client-id; the data channel must follow the signal channel spec. 
- Add a discussion about translation implications
- Add conflict support
- The same resource can be associated with different aliases if multiple dots clients are deployed within a network
- Check the normative language 

Please review and share comments. 

Cheers,
Med

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

---

From: <[email-masked]>
Date: Wed, 20 Dec 2017 09:10:42 +0000

Hi all, 

Christian has kindly reviewed this version of the draft. Many thanks to him. 

Proposed changes are available at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/wdiff%20draft-ietf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : lundi 18 décembre 2017 16:37
> À : [email-masked]
> Objet : [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt
> 
> Re-,
> 
> - Mention that the signal channel I-D is the authoritative reference for
> manipulating client-id; the data channel must follow the signal channel
> spec.
> - The same resource can be associated with different aliases if multiple
> dots clients are deployed within a network

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 20 Dec 2017 10:16:30 -0000

Hi Med,

You need to update the following in the diff pdf

1. Introduction

Replace
  ... from these sites is protected from DDoS attacks. The DOTS client uses
the....
with
  ... from these sites is protected from DDoS attack mitigation. The DOTS
client uses the....

Otherwise

7.1 Install Filtering rules

I-D.ietf-netmod-acl-model also supports 'reject' for actions.  Should this
be added?

Replace
  Content-Type: "application/yang+data+json"
With - should not have the quotes I believe (change is needed in several
places)
  Content-Type: application/yang+data+json

Replace
  The "insert" query parameter discussed in Section 4.8.5 of [RFC8040]
  MAY be used to specify how a ACE is inserted within an ACL and how a
  ACL is inserted within an ACL list.
With - ACL Lists are not configured to be ordered
  The "insert" query parameter discussed in Section 4.8.5 of [RFC8040]
  MAY be used to specify how a ACE is inserted within an ACL and how a
  ACL is inserted within an ACL Set in container dots-acl-order.

As part of another discussion on the use of client-identifiers, I am not
happy with (it is too restrictive).  The draft elsewhere refers to the
control of IPs being revealed

  In order to prevent leaking internal information outside a client-
  domain, client-side DOTS gateways SHOULD NOT reveal the identity of
  internal DOTS clients (client-identifier) unless explicitly
  configured to do so.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 20 December 2017 09:11
To: [email-masked]
Cc: JACQUENET Christian IMT/OLN
Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt

Hi all, 

Proposed changes are available at:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/wdiff%20draft-i
etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf 

Cheers,
Med

> [email-masked] Envoyé : lundi 18 décembre 2017 16:37 À : 
> [email-masked] Objet : [Dots] TR: I-D Action: 
> draft-ietf-dots-data-channel-11.txt
> 
> Re-,
> 
> - Mention that the signal channel I-D is the authoritative reference 
> for manipulating client-id; the data channel must follow the signal 
> channel spec.
> - The same resource can be associated with different aliases if 
> multiple dots clients are deployed within a network
> > [email-masked] Envoyé : lundi 18 décembre 2017 16:32 À : 
> > [email-masked] Cc : [email-masked] Objet : [Dots] I-D Action: 
> > draft-ietf-dots-data-channel-11.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: Wed, 20 Dec 2017 11:58:09 +0000

Hi Jon,

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : mercredi 20 décembre 2017 11:17
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; JACQUENET Christian IMT/OLN
> Objet : RE: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt
> 
> Hi Med,
> 

[Med] Do you really mean "protect..." from "...mitigation"?

>   Content-Type: application/yang+data+json

[Med] Good catch. Fixed. Thanks. 

>   ACL is inserted within an ACL Set in container dots-acl-order.

[Med] I made some minor changes to your proposal: 

   The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY be used
   to specify how an Access Control Entry (ACE) is inserted within an
   ACL and how an ACL is inserted within an ACL set in container dots-
   acl-order.

>   internal DOTS clients (client-identifier) unless explicitly

[Med] Is it too restrictive? 

It does set the bar where an administrator has to instruct the gateway explicitly about the information to be inserted/leaked. 

This text follows the reco in: https://tools.ietf.org/html/rfc8165

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 20 Dec 2017 12:23:08 -0000

Hi Med,

See inline [Jon]

In addition, I think that 'set-name' and 'type' in 'acl-set' should really
be called 'acl-set-name' and 'acl-set-type' respectively in all the
appropriate reference points.

  augment /ietf-acl:access-lists:
    +--rw dots-acl-order
       +--rw acl-set* [set-name type]
          +--rw acl-set-name    -> /ietf-acl:access-lists/acl/acl-name
          +--rw acl-set-type      -> /ietf-acl:access-lists/acl/acl-type

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 20 December 2017 11:58
To: Jon Shallow; [email-masked]; JACQUENET Christian IMT/OLN
Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt

Hi Jon,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 11:17 À : BOUCADAIR Mohamed 
> IMT/OLN; [email-masked]; JACQUENET Christian IMT/OLN Objet : RE: [Dots] 
> TR: I-D Action: draft-ietf-dots-data-channel-11.txt
> 
> Hi Med,
> 
>   ... from these sites is protected from DDoS attacks. The DOTS client 
> uses the....
> with
>   ... from these sites is protected from DDoS attack mitigation. The 
> DOTS client uses the....
> 

[Med] Do you really mean "protect..." from "...mitigation"?
[Jon] The context here is white-listed IPs - the whitelisted IPs should not
get mitigated, not protected from DDoS attacks. So, 'yes'.
[Jon] I should have added in the rest of the line "The DOTS client uses the
 DOTS data channel to convey the white-listed IP prefixes of the
 partner sites to its DOTS server."

> I-D.ietf-netmod-acl-model also supports 'reject' for actions.  Should 
> this be added?
> 
> Replace

[Jon] Works for me

> As part of another discussion on the use of client-identifiers, I am 
> not happy with (it is too restrictive).  The draft elsewhere refers to 
> the control of IPs being revealed
> 

It does set the bar where an administrator has to instruct the gateway
explicitly about the information to be inserted/leaked. 

[Jon] This follows on from our other discussions about client-identifiers -
which actually do not reveal the identity of the client (there is no IP
information, the unique information about the client is one way hashed into
the client-identifier).  That said, the DOTS server can work out how many
clients there actually are behind the gateway and which of them are more
active, but I do not see this as a real security risk.  All traffic is
encrypted, making it difficult for any other device to work out what is
going on.  Without the client-identifier (or some alternative "mangling" of
the mitigation ids to provide uniqueness) the DOTS server cannot effectively
/ correctly handle the same mitigation-id when requested /used by different
DOTS clients. 

> > >    Please update these statements with the RFC number to be 
> > > assigned
> to
> > >    this document:
> > >
> > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel
> > > -1
> > > 1
> > >

---

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

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 13:23

[Med] Please note that as per YANG naming conventions, there is little value in repeating names in a
given hierarchy. I'm sure this will be a comment we will get from yangdoctors if we change the names as you suggest. 

> / correctly handle the same mitigation-id when requested /used by

[Med] In order to keep this text (and its initial intent) aside from the client-id discussion. I suggest to make this change: 

   In order to prevent leaking internal information outside a client-
   domain, client-side DOTS gateways SHOULD NOT reveal the identity of
   internal DOTS clients (e.g., source IP address) unless explicitly
   configured to do so. 

We may update based on the conclusion of the client-id discussion. 

Hope this is OK with you. 

Please double check at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/wdiff%20draft-ietf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf

---

From: <[email-masked]>
Date: Wed, 20 Dec 2017 13:09:17 +0000

Jon,

One further clarification about acl-set-* names, you may want check this PR, currently discussed in the netmod wg: https://github.com/netmod-wg/acl-model/pull/21/files:

s/acl-type/type
s/acl-name/name
s/set-name/name 

If accepted, we will need to update the draft as follows:

OLD:

          +--rw set-name    -> /ietf-acl:access-lists/acl/acl-name
          +--rw type        -> /ietf-acl:access-lists/acl/acl-type

NEW:

          +--rw name        -> /ietf-acl:access-lists/acl/name
          +--rw type        -> /ietf-acl:access-lists/acl/type

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 13:56
> À : Jon Shallow; [email-masked]; JACQUENET Christian IMT/OLN
> Objet : Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> given hierarchy. I'm sure this will be a comment we will get from
> yangdoctors if we change the names as you suggest.
> 
> >
> > [Jon] This follows on from our other discussions about client-
> identifiers
> > -
> [Med] In order to keep this text (and its initial intent) aside from the
> client-id discussion. I suggest to make this change:
> 
> Please double check at: https://github.com/boucadair/IETF-Drafts-
> Reviews/blob/master/wdiff%20draft-ietf-dots-data-channel-11.txt%20draft-
> ietf-dots-data-channel-12.pdf
> 
> > > Regards
> > >
> > > Jon
> > >
> > > > >         Title           : Distributed Denial-of-Service Open
> Threat
> > > > > Signaling (DOTS) Data Channel

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 20 Dec 2017 13:09:24 -0000

Hi Med,

See inline [Jon1].

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 20 December 2017 12:56
To: Jon Shallow; [email-masked]; JACQUENET Christian IMT/OLN
Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 13:23 À : BOUCADAIR Mohamed 
> In addition, I think that 'set-name' and 'type' in 'acl-set' should 
> really be called 'acl-set-name' and 'acl-set-type' respectively in all 
> the appropriate reference points.

[Med] Please note that as per YANG naming conventions, there is little value
in repeating names in a given hierarchy. I'm sure this will be a comment we
will get from yangdoctors if we change the names as you suggest.
[Jon1] Fair enough

> >   ... from these sites is protected from DDoS attacks. The DOTS 
> > client uses the....
> > with
> [Jon] The context here is white-listed IPs - the whitelisted IPs 
> should not get mitigated, not protected from DDoS attacks. So, 'yes'.
> [Jon] I should have added in the rest of the line "The DOTS client 
> uses the  DOTS data channel to convey the white-listed IP prefixes of 
> the  partner sites to its DOTS server."
> 
> > Otherwise
> >
> > I-D.ietf-netmod-acl-model also supports 'reject' for actions.  
> > Should this be added?
[Jon1] you have not responded to this question
> > not happy with (it is too restrictive).  The draft elsewhere refers 
> > to the control of IPs being revealed
> >
> [Jon] This follows on from our other discussions about 
> client-identifiers
> -
> which actually do not reveal the identity of the client (there is no 
> IP information, the unique information about the client is one way 
> hashed into the client-identifier).  That said, the DOTS server can 
> work out how many clients there actually are behind the gateway and 
> which of them are more active, but I do not see this as a real 
> security risk.  All traffic is encrypted, making it difficult for any 
> other device to work out what is going on.  Without the 
> client-identifier (or some alternative "mangling"
> of
> the mitigation ids to provide uniqueness) the DOTS server cannot 
> effectively / correctly handle the same mitigation-id when requested 
> /used by different DOTS clients.
> 
> 

Hope this is OK with you. 
[Jon1] Yes, this is a good initial move for me.

Please double check at:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/wdiff%20draft-i
etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf 
[Jon1] Apart from one thing above, you have captured this email thread.

> > > - Mention that the signal channel I-D is the authoritative 
> > > reference for manipulating client-id; the data channel must follow 
> > > the signal channel spec.
> > > > 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: Wed, 20 Dec 2017 13:17:53 -0000

Hi Med,

It makes sense - I guess I was baulking at 'set-name' and 'type' and wanted
to normalize them - which they have done as 'name' and 'type'.

They also are proposing changing 'rule-name' to 'name' which affects the
data channel draft as well.

Regards

Jon

-----Original Message-----
Sent: 20 December 2017 13:09

Jon,

One further clarification about acl-set-* names, you may want check this PR,
currently discussed in the netmod wg:
https://github.com/netmod-wg/acl-model/pull/21/files:

s/acl-type/type
s/acl-name/name
s/set-name/name 

OLD:

NEW:

Cheers,
Med

> [email-masked] Envoyé : mercredi 20 décembre 2017 13:56 
> À : Jon Shallow; [email-masked]; JACQUENET Christian IMT/OLN Objet : 
> Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > IMT/OLN; [email-masked]; JACQUENET Christian
> IMT/OLN
> really
> [Med] Please note that as per YANG naming conventions, there is little 
> value in repeating names in a given hierarchy. I'm sure this will be a 
> comment we will get from yangdoctors if we change the names as you 
> suggest.
> 
> >
> > >   ... from these sites is protected from DDoS attack mitigation. 
> > > The DOTS client uses the....
> > >
> >
> > uses the  DOTS data channel to convey the white-listed IP prefixes 
> > of the  partner sites to its DOTS server."
> >
> > > Otherwise
> > >
> > > As part of another discussion on the use of client-identifiers, I 
> > > am not happy with (it is too restrictive).  The draft elsewhere 
> > > refers to the control of IPs being revealed
> > >
> > It does set the bar where an administrator has to instruct the 
> > gateway explicitly about the information to be inserted/leaked.
> >
> > work out how
> many
> > clients there actually are behind the gateway and which of them are 
> > more active, but I do not see this as a real security risk.  All 
> > traffic is encrypted, making it difficult for any other device to 
> > work out what is going on.  Without the client-identifier (or some
alternative "mangling"
> [Med] In order to keep this text (and its initial intent) aside from 
> the client-id discussion. I suggest to make this change:
> 
> > > > [email-masked] Envoyé : lundi 18 décembre 2017 
> > > > 16:37
> À :
> > > > reference for manipulating client-id; the data channel must 
> > > > follow the signal channel spec.
> > > > > internet- [email-masked] Envoyé : lundi 18 décembre 2017 16:32
À :
> > > > >    Signaling (DOTS) data channel used for bulk exchange of 
> > > > > data
> not
> > > > >    easily or appropriately communicated through the DOTS 
> > > > > signal
> > > channel
> > > > >    under attack conditions.
> > > > >
> > > > > of submission until the htmlized version and diff are 
> > > > > available at tools.ietf.org.
> > > > >

---

From: <[email-masked]>
Date: Wed, 20 Dec 2017 13:18:39 +0000

Re-,

I'm hesitating to add "reject" in the context for DDoS because it will require sending ICMP messages to (misbehaving) sources.

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 14:09
> value

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 20 Dec 2017 13:28:16 -0000

Hi Med,

Good point.  I have discussed with Tiru in the past about nominating a
subset of netmod-acl that DOTS has to support (e.g. L2 stuff I think is
irrelevant), and it may sense to also have a "never to use" subset list.

Regards

Jon

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 20 December 2017 13:19
To: Jon Shallow; [email-masked]; JACQUENET Christian IMT/OLN
Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt

Re-,

I'm hesitating to add "reject" in the context for DDoS because it will
require sending ICMP messages to (misbehaving) sources.

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 14:09 À : BOUCADAIR Mohamed 
> > really be called 'acl-set-name' and 'acl-set-type' respectively in 
> > all the appropriate reference points.
> 
> > security risk.  All traffic is encrypted, making it difficult for 
> > any other device to work out what is going on.  Without the 
À :
> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-cha
> > > > > nn
> > > > > el
> > > > > -1
> > > > > 1
> > > > >
> > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel
> > > > > -1
> > > > > 1
> > > > >
> > > > >

---

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

Re-,

Providing some guidance to implementers is helpful, IMO. 

The ACL YANG module defines these features: 
* l2-acl
* mixed-ipv4-acl
* mixed-ipv6-acl
* l2-l3-ipv4-ipv6-acl
* tcp-acl
* udp-acl
* icmp-acl
* any-acl
* interface-stats

We can indicate that in the context of DOTS, the following features MUST be supported:
* ipv4-acl 
* ipv6-acl
* tcp-acl
* udp-acl
* icmp-acl

This branch of the module MUST NOT be implemented because we are not touching interfaces:
       +--rw interfaces 

I would be silent about the other features.

We can discourage from using "reject" action. 

I can draft some text among those lines, if needed. 

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 14:28

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 20 Dec 2017 14:29:14 -0000

Hi Med,

I think this would be helpful to implementers so that they know the minimum
of what should be supported.

Regards

Jon

-----Original Message-----
Sent: 20 December 2017 14:08

Re-,

We can indicate that in the context of DOTS, the following features MUST be
supported:
* ipv4-acl
* ipv6-acl
* tcp-acl
* udp-acl
* icmp-acl

This branch of the module MUST NOT be implemented because we are not
touching interfaces:
       +--rw interfaces 

Cheers,
Med

> Envoyé : mercredi 20 décembre 2017 14:28 À : BOUCADAIR Mohamed 
> subset of netmod-acl that DOTS has to support (e.g. L2 stuff I think 
> is irrelevant), and it may sense to also have a "never to use" subset
list.
> > > In addition, I think that 'set-name' and 'type' in 'acl-set' 
> > > should really be called 'acl-set-name' and 'acl-set-type' 
> > > respectively in all the appropriate reference points.
> >
> > [Med] Please note that as per YANG naming conventions, there is 
> > little value in repeating names in a given hierarchy. I'm sure this 
> > will be a comment we will get from yangdoctors if we change the 
> > names as you suggest.
> > [Jon1] Fair enough
> >
> >
> > >
> > > >   MAY be used to specify how a ACE is inserted within an ACL and 
> > > > how
> a
> > > >   MAY be used to specify how a ACE is inserted within an ACL and 
> > > > how
> a
> > >    The "insert" query parameter (Section 4.8.5 of [RFC8040]) MAY 
> > > be
> used
> > > > As part of another discussion on the use of client-identifiers, 
> > > > I am not happy with (it is too restrictive).  The draft 
> > > > elsewhere refers to the control of IPs being revealed
> > > >
> > > >   domain, client-side DOTS gateways SHOULD NOT reveal the 
> > > > identity
> of
> > > which actually do not reveal the identity of the client (there is 
> > > no IP information, the unique information about the client is one 
> > > way hashed into the client-identifier).  That said, the DOTS 
> > > server can work out how many clients there actually are behind the 
> > > gateway and which of them are more active, but I do not see this 
> > > as a real security risk.  All traffic is encrypted, making it 
> > > difficult for any other device to work out what is going on.  
> > > Without the client-identifier (or some alternative "mangling"
> > > of
> > > effectively / correctly handle the same mitigation-id when 
> > > requested /used by different DOTS clients.
> > >
> > >
> >
> > > > > - The same resource can be associated with different aliases 
> > > > > if multiple dots clients are deployed within a network
> > > > > >    The document specifies a Distributed Denial-of-Service 
> > > > > > Open
> > > Threat
> > > > > > Please note that it may take a couple of minutes from the 
> > > > > > time of submission until the htmlized version and diff are

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 21 Dec 2017 03:09:50 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
> Sent: Wednesday, December 20, 2017 7:59 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> I think this would be helpful to implementers so that they know the
> minimum of what should be supported.

+1

-Tiru

---

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

Hi all, 

Please find below a text proposal to address the implementation note issue: 

==
   DOTS implementations MUST support the following features defined in
   [I-D.ietf-netmod-acl-model]:

      match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match-
      on-icmp, ipv4, and ipv6.

   Given that DOTS data channel does not deal with interfaces, the
   support of the "ietf-interfaces" module [RFC7223] and its
   augmentation in the "ietf-access-control-list" module are not
   required for DOTS.  Specifically, the support of interface-related
   features and branches (e.g., interface-attachment, interface-stats,
   acl-aggregate-stats, and interface-acl-aggregate) of the ACL YANG
   module is not required.

   The following forwarding actions MUST be supported:

      'accept' and 'drop'

   The support of 'reject' action is NOT RECOMMENDED because it is not
   appropriate in the context of DDoS mitigation.  Generating ICMP
   messages to notify drops when mitigating a DDoS attack will
   exacerbate the DDoS attack.  Further, it will be used by an attacker
   as an explicit signal that the traffic is being blocked.
==

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
> Reddy
> Envoyé : jeudi 21 décembre 2017 04:10
> À : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]; JACQUENET
> Christian IMT/OLN
> > > > >           +--rw acl-set-type      -> /ietf-acl:access-
> lists/acl/acl-
> > > type
> > > > >
> > > > > Regards
> > > > >
> > > > > Jon
> > > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 21 Dec 2017 08:46:46 -0000

Hi Med,

I think a copy of the YANG tree (including the MUST netmod-acl information)
for ietf-dots-data-channel should also be included (as well as leaving the
existing augment information) - so that it is easy to look at the final
layout.  Otherwise the additional text below looks fine.

Regards

Jon

-----Original Message-----
From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 21 December 2017 08:11
To: Konda, Tirumaleswar Reddy; Jon Shallow; [email-masked]; JACQUENET
Christian IMT/OLN
Subject: Re: [Dots] TR: I-D Action: draft-ietf-dots-data-channel-11.txt

Hi all, 

==

      'accept' and 'drop'

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Konda, 
> Tirumaleswar Reddy Envoyé : jeudi 21 décembre 2017 04:10 À : Jon 
> Shallow; BOUCADAIR Mohamed IMT/OLN; [email-masked]; JACQUENET Christian 
> IMT/OLN Objet : Re: [Dots] TR: I-D Action: 
> > We can indicate that in the context of DOTS, the following features 
> > MUST
> be
> > supported:
> > * ipv4-acl
> > * ipv6-acl
> > * tcp-acl
> > * udp-acl
> > * icmp-acl
> >
> > > Good point.  I have discussed with Tiru in the past about 
> > > nominating a subset of netmod-acl that DOTS has to support (e.g. 
> > > L2 stuff I think is irrelevant), and it may sense to also have a 
> > > "never to use" subset
> > list.
> > >
> > > Regards
> > >
> > > Jon
> > >
> > > I'm hesitating to add "reject" in the context for DDoS because it 
> > > will require sending ICMP messages to (misbehaving) sources.
> > >
> > > Cheers,
> > > Med
> > >
> > > > little value in repeating names in a given hierarchy. I'm sure 
> > > > this will be a comment we will get from yangdoctors if we change 
> > > > the names as you suggest.
> > > > [Jon1] Fair enough
> > > >
> > > >
> > > > >
> > > > > > Envoyé : mercredi 20 décembre 2017 11:17 À : BOUCADAIR 
> > > > > > Mohamed IMT/OLN; [email-masked]; JACQUENET Christian IMT/OLN
Objet : RE:
> > > > > > [Dots]
> > > > > >   ... from these sites is protected from DDoS attacks. The 
> > > > > > DOTS client uses the....
> > > > > > with
> > > > > [Jon] The context here is white-listed IPs - the whitelisted 
> > > > > IPs should not get mitigated, not protected from DDoS attacks. 
> > > > > So,
> 'yes'.
> > > > > [Jon] I should have added in the rest of the line "The DOTS 
> > > > > client uses the  DOTS data channel to convey the white-listed 
> > > > > IP prefixes of the  partner sites to its DOTS server."
> > > > >
> > > > > > Otherwise
> > > > > >
> > > > > >   MAY be used to specify how a ACE is inserted within an ACL 
> > > > > > and how
> > > a
> > > > > >   MAY be used to specify how a ACE is inserted within an ACL 
> > > > > > and how
> > > a
> > > > >    The "insert" query parameter (Section 4.8.5 of [RFC8040]) 
> > > > > MAY be
> > > used
> > > > >    to specify how an Access Control Entry (ACE) is inserted 
> > > > > within
> an
> > > > >    ACL and how an ACL is inserted within an ACL set in 
> > > > > container
> dots-
> > > > >    acl-order.
> > > > > [Jon] Works for me
> > > > >
> > > > > > As part of another discussion on the use of 
> > > > > > client-identifiers, I am not happy with (it is too 
> > > > > > restrictive).  The draft elsewhere refers to the control of 
> > > > > > IPs being revealed
> > > > > >
> > > > > which actually do not reveal the identity of the client (there 
> > > > > is no IP information, the unique information about the client 
> > > > > is one way hashed into the client-identifier).  That said, the 
> > > > > DOTS server can work out how many clients there actually are 
> > > > > behind the gateway and which of them are more active, but I do 
> > > > > not see this as a real security risk.  All traffic is 
> > > > > encrypted, making it difficult for any other device to work out
what is going on.
> > > > > the mitigation ids to provide uniqueness) the DOTS server 
> > > > > cannot effectively / correctly handle the same mitigation-id 
> > > > > when requested /used by different DOTS clients.
> > > > >
> > > > >
> > > >
> > > > [Med] In order to keep this text (and its initial intent) aside 
> > > > from the client-id discussion. I suggest to make this change:
> > > >
> > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.p
> > > > df [Jon1] Apart from one thing above, you have captured this 
> > > > email
> thread.
> > > >
> > > > > > Regards
> > > > > >
> > > > > > Jon
> > > > > >
> > > > > > etf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-
> > > > > > 12.p
> > > > > > df
> > > > > >
> > > > > > Cheers,
> > > > > > Med
> > > > > >
> > > > > > > -----Message d'origine----- De : Dots 
> > > > > > > [mailto:[email-masked]] De la part de 
> > > > > > > - Indicate that the order of establishing signal/data 
> > > > > > > channel is implementation/deployment specific
> > > > > > > reference for manipulating client-id; the data channel 
> > > > > > > must follow the signal channel spec.
> > > > > > > - The same resource can be associated with different 
> > > > > > > aliases if multiple dots clients are deployed within a 
> > > > > > > network
> > > > > > > > -----Message d'origine----- De : Dots 
> > > > > > > > [mailto:[email-masked]] De la part de
> > > > > > > > internet- [email-masked] Envoyé : lundi 18 décembre 
> > > > > > > > 2017
> > > > > > > > 16:32
> > > À :
> > > > > > > > [email-masked] Cc : [email-masked] Objet : [Dots] 
> > > > > > > > I-D
> > > > Action:
> > > > > > > >    The document specifies a Distributed 
> > > > > > > > Denial-of-Service Open
> > > > > Threat
> > > > > > > >    Signaling (DOTS) data channel used for bulk exchange 
> > > > > > > > of data
> > > > not
> > > > > > > >    Please update these statements with the RFC number to 
> > > > > > > > be assigned
> > > > > > to
> > > > > > > >    this document:
> > > > > > > >
> > > > > > > >    o  "RFC XXXX: Distributed Denial-of-Service Open 
> > > > > > > > Threat
> > > > Signaling
> > > > > > > >       (DOTS) Data Channel";
> > > > > > > >
> > > > > > > >    o  reference: RFC XXXX
> > > > > > > >
> > > > > > > >
> > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-data-ch
> > > > > > > > anne
> > > > > > > > l/
> > > > > > > >
> > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-da
> > > > > > > > ta-c
> > > > > > > > ha
> > > > > > > > nn
> > > > > > > > el
> > > > > > > > -1
> > > > > > > > 1
> > > > > > > >
> > > > > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-c
> > > > > > > > hann
> > > > > > > > el
> > > > > > > > -1
> > > > > > > > 1
> > > > > > > >
> > > > > > > >
> > > > > > > > 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: Thu, 21 Dec 2017 09:16:06 +0000

Re-,

Happily. 

Please check at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/wdiff%20draft-ietf-dots-data-channel-11.txt%20draft-ietf-dots-data-channel-12.pdf 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Jon Shallow
> Envoyé : jeudi 21 décembre 2017 09:47
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]; Konda, Tirumaleswar Reddy;
> JACQUENET Christian IMT/OLN
> > > > > >           +--rw acl-set-name    -> /ietf-acl:access-
> lists/acl/acl-
> > name