Subject: [Dots] draft-ietf-dots-data-channel: Value and/or Range

From: <[email-masked]>
Date: Mon, 19 Feb 2018 07:52:16 +0000

Hi Jon,

Good point.

Actually, some filtering parameters are worth to be supplied as values or ranges but the current netmod module does not allow for it. I can cite:

·         Length fields

·         TTL

Do we need to have value/range supported in the module for these fields?

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 16 février 2018 17:14
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Ttl is an interesting one.  It is not definable as a range, and so if you want to match "ttl lt 16" you are going to have to have 16 ACLs preceding any other ACL that does anything else.

I would expect that 'ttl' would be done properly as a one of the mitigator rules, and DOTS does not need to 'hint' it as well.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 15:46
To: [email-masked]<mailto:[email-masked]>; Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

We may want to add

1)      UDP (length) to the list. It may be useful to block large DNS packets (e.g. DNS amplification attack).

2)      In IPv4/IPv6, add length, ttl (https://www.cisco.com/c/en/us/about/security-center/ttl-expiry-attack.html) to the list.

-Tiru

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Jon Shallow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Re-,

Here is a tentative list:

   Header Mandatory Fields
   ------ --------------------------------------------------------------
   IPv4   protocol, source-port-range-or-operator, destination-port-
          range-or-operator, destination-ipv4-network, source-
          ipv4-network, and v4-fragments
   IPv6   protocol, source-port-range-or-operator, destination-port-
          range-or-operator, destination-ipv4-network, source-
          ipv4-network,and v6-fragments
   TCP    flags
   ICMP   type and code

Please comment/update.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : vendredi 16 février 2018 14:55
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

+1. In TCP, only "flags" field looks mandatory.

-Tiru

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Re-,

I tend to agree with you to have to define a minimum set of mandatory match fields.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 16 février 2018 14:29
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Hi Med,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Jon,

Thank you for sharing your thoughts.

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 16 février 2018 13:24
À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

I like the concept of "+--ro capabilities" allowing for future support as the DOS server becomes more mature in its capabilities.

If a DOTS client includes a filtering field parameter that is not currently supported, should the parameter be ignored (and not returned for a GET), or the request rejected?

[Med] I would vote for rejecting the request. The client should only use match criteria that are understood by the server; otherwise there will be different expectation from the service.

[Jon] I think that this is my preference - I was just seeking clarity of thinking.

It is conceivable that a DOTS client has 2 DOTS servers (one possibly a backup, or 2 different ISPs), which may have differing filtering field parameter support capabilities.

[Med] The backup/case seems odd. I would expect a feature parity for a redundancy group used to provide the same service.

[Jon] Agreed that a backup server is most likely to be from the same manufacturer and hence support the same functionality.  But one may have just been upgraded to have extra support.

  Adding in intelligence code to work out what is / is not allowed may not be practical in a (memory or cpu) constrained environment of the DOTS client.

[Med] Fair.

That said, I think we need to define the minimum set of supported parameters - e.g. protocol, source / dest ports,  source / dest IPv4 prefixes, source / dest IPv6 prefixes, fragments and icmp type/code.

[Jon] Any comments?

-Jon

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 16 February 2018 10:18
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Hi Med,

Please see inline [TR2]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, February 16, 2018 1:45 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-dots-data-channel: Filtering Fields

Re-,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : vendredi 16 février 2018 08:00
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, February 14, 2018 1:49 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Hi all,

As agreed during the interim, there are some issues that need fixes in the data-channel spec. We would like to hear from the WG to know what to record in the document.

Issue description: Should we support all of the match fields defined by "ietf-packet-fields" or do we need to define a minimum supported set?

[TR] I don't see the need to support all the match fields, define a minimum supported set (don't see the use for acl-eth-header-fields for DOTS use cases).
[Med] Agree that acl-eth-header-fields aren't required. The text is already clear about this:

DOTS implementations MUST support the following
   matching criteria: match based on the IP header (IPv4 and IPv6),
   match based on the transport header (TCP, UDP, and ICMP), and any
   combination thereof.

The question is whether we need to go further and mandate (or not) the support of matching based on specific fields: dscp, ecn, ttl,... flow-label, ... tcp sequence-number, tcp flags, ...

[TR2] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature statements in the YANG model allowing vendors to advertise match rules they are capable and willing to support but not at the field-level. The problem is router implementations today don't support ACLs with tcp sequence-number, acknowledgement-number, window-size etc but support TCP flags. If the server could convey the list of match criteria supported, it not only allows the client to convey the supported match rules but also allows the server in future to advertise the new supported match fields.

Would it be useful for a client to retrieve the list of match criteria supported by a DOTS server?

[TR2] Yes.

-Tiru

[TR] The YANG model supported by the DOTS server can retrieved by the DOTS client using RESTCONF to determine the match criteria supported by the server.
[Med] I'm afraid this is not the same functionality. If we need to allow a server to return its supported match criteria, this should be allowed by the module. For example, the module may include the following (example):

                +--ro capabilities

                |  +--ro match-header*

                |  |       identityref

                |  +--ro transport-protocols* [protocol-id]

                |  |  +--ro protocol-id      uint8

                |  |  +--ro protocol-name?   string

                |  +--ro dscp-support?       boolean

                |  +--ro ecn-support?        boolean

                |  +--ro length-support?     boolean

                |  +--ro ttl-support?        boolean

                |  +--ro protocol-support?   boolean

The client can ask the server to return its supported match criteria. The server will indicate the exact set of fields it supports.

I'm not expressing a preference to have this in the model, but I'm clarifying how it would look like.

-Tiru

Please comment.

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 19 Feb 2018 10:19:28 +0000

I don't think router vendors support ranges for TTL fields !

-Tiru

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 19, 2018 1:22 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: draft-ietf-dots-data-channel: Value and/or Range

Hi Jon,

Good point.

·         Length fields

·         TTL

Cheers,
Med

Regards

Jon

We may want to add

-Tiru

Re-,

   Header Mandatory Fields

Please comment/update.

Cheers,
Med

-Tiru

Re-,

Cheers,
Med

Hi Med,

See inline [Jon]

Regards

Jon

Jon,

Please see inline.

Cheers,
Med

[Med] Fair.

[Jon] Any comments?

-Jon

Regards

Jon

Hi Med,

Please see inline [TR2]

Re-,

Please see inline.

Cheers,
Med

Hi all,

[TR2] Yes.

-Tiru

                +--ro capabilities

                |  +--ro match-header*

                |  |       identityref

-Tiru

Please comment.

Cheers,

Med

---

From: <[email-masked]>
Date: Mon, 19 Feb 2018 10:36:29 +0000

Re-,

I can cite at least these two router vendors:

·         https://www.juniper.net/documentation/en_US/junos/topics/reference/general/firewall-filter-match-conditions-for-ipv4-traffic.html

·         https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-0073-HTML/7750_SR_OS_Router_Configuration_Guide/filters.html

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : lundi 19 février 2018 11:19
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : RE: draft-ietf-dots-data-channel: Value and/or Range

-Tiru

Hi Jon,

Good point.

*         Length fields

*         TTL

Cheers,
Med

Regards

Jon

We may want to add

-Tiru

Re-,

   Header Mandatory Fields

Please comment/update.

Cheers,
Med

-Tiru

Re-,

Cheers,
Med

Hi Med,

See inline [Jon]

Regards

Jon

Jon,

Please see inline.

Cheers,
Med

[Med] Fair.

[Jon] Any comments?

-Jon

Regards

Jon

Hi Med,

Please see inline [TR2]

Re-,

Please see inline.

Cheers,
Med

Hi all,

[TR2] Yes.

-Tiru

                +--ro capabilities

                |  +--ro match-header*

                |  |       identityref

-Tiru

Please comment.

Cheers,

Med

---

From: "Dobbins, Roland" <[email-masked]>
Date: Mon, 19 Feb 2018 16:05:24 +0000

> On Feb 19, 2018, at 17:20, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 

Most don't. 

Still confused & dismayed that we're falling down the rabbit hole of re-implementing flowspec in DOTS.

This is adding needless & unwanted complexity to DOTS. DOTS nodes should simply self-describe their protocols/ports, & figuring out what network access policies to wrap around them should take place outside the scope of DOTS. 

Very strong objections to all this ACL stuff.  

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 20 Feb 2018 08:50:29 +0000

> -----Original Message-----
> From: Dobbins, Roland [mailto:[email-masked]]
> Sent: Monday, February 19, 2018 9:35 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]; Jon Shallow <supjps-
> [email-masked]>; [email-masked]
> Subject: Re: [Dots] draft-ietf-dots-data-channel: Value and/or Range
> 
> 
> 
> > On Feb 19, 2018, at 17:20, Konda, Tirumaleswar Reddy
> <[email-masked]> wrote:
> >
> This is adding needless & unwanted complexity to DOTS. DOTS nodes should
> simply self-describe their protocols/ports, & figuring out what network
> access policies to wrap around them should take place outside the scope of
> DOTS.
> 

DOTS signal channel does not use any ACL, ACL is used only in the DOTS data channel for black-listing/white-listing traffic to meet the requirement DATA-004 in 
https://tools.ietf.org/html/draft-ietf-dots-requirements-14

-Tiru

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 20 Feb 2018 09:11:14 -0000

As the intent is to follow netmod-acl-model syntax, having a DOTS version of
some of the parameters makes no sense to me.

For example, the DOTS server when communicating with the DOTS mitigator
(albeit out of scope) will have to translate the current set of ACL
definitions into something – e.g. real netconf-acl.  With the exact
modelling of netmod-acl-model parameters, life is a lot easier as we just
have to strip out the DOTS specific parameters (e.g. lifetimes).

The right place to get this done is to get the netmod-acl-model authors to
update their definitions of ietf-packet-fields.

As draft-ietf-netmod-acl-16 can possibly change (we have seen significant
changes over the last few updates), we need to consider referring to the
specific version of ietf-packet-fields in the DOTS data channel Yang model.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 19 February 2018 07:52
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; [email-masked]
Subject: [Dots] draft-ietf-dots-data-channel: Value and/or Range

Hi Jon, 

Good point. 

Actually, some filtering parameters are worth to be supplied as values or
ranges but the current netmod module does not allow for it. I can cite:

·        Length fields

·        TTL

Cheers,

Med

Ttl is an interesting one.  It is not definable as a range, and so if you
want to match “ttl lt 16” you are going to have to have 16 ACLs preceding
any other ACL that does anything else.

I would expect that ‘ttl’ would be done properly as a one of the mitigator
rules, and DOTS does not need to ‘hint’ it as well.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 16 February 2018 15:46
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

We may want to add 

1)      UDP (length) to the list. It may be useful to block large DNS
packets (e.g. DNS amplification attack).

2)      In IPv4/IPv6, add length, ttl
(https://www.cisco.com/c/en/us/about/security-center/ttl-expiry-attack.html)
to the list. 

-Tiru

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 16, 2018 8:04 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Jon
Shallow <[email-masked]>; [email-masked]
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Re-,

   Header Mandatory Fields

   TCP    flags

   ICMP   type and code

Please comment/update. 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
Reddy
Envoyé : vendredi 16 février 2018 14:55
À : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; [email-masked]
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

+1. In TCP, only “flags” field looks mandatory. 

-Tiru

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 16, 2018 7:03 PM
To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy
<[email-masked]>; [email-masked]
Subject: RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Re-,

I tend to agree with you to have to define a minimum set of mandatory match
fields. 

Cheers,

Med

De : Jon Shallow [mailto:[email-masked]] 
Envoyé : vendredi 16 février 2018 14:29
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
Objet : RE: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Hi Med,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 16 February 2018 12:56
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; [email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Jon,

Please see inline.

Cheers,

Med

I like the concept of “+--ro capabilities“ allowing for future support as
the DOS server becomes more mature in its capabilities.
 
If a DOTS client includes a filtering field parameter that is not currently
supported, should the parameter be ignored (and not returned for a GET), or
the request rejected?
[Med] I would vote for rejecting the request. The client should only use
match criteria that are understood by the server; otherwise there will be
different expectation from the service. 
[Jon] I think that this is my preference – I was just seeking clarity of
thinking.
 
It is conceivable that a DOTS client has 2 DOTS servers (one possibly a
backup, or 2 different ISPs), which may have differing filtering field
parameter support capabilities.
[Med] The backup/case seems odd. I would expect a feature parity for a
redundancy group used to provide the same service.
[Jon] Agreed that a backup server is most likely to be from the same
manufacturer and hence support the same functionality.  But one may have
just been upgraded to have extra support.

  Adding in intelligence code to work out what is / is not allowed may not
be practical in a (memory or cpu) constrained environment of the DOTS
client.
[Med] Fair. 
 
That said, I think we need to define the minimum set of supported parameters
– e.g. protocol, source / dest ports,  source / dest IPv4 prefixes, source /
dest IPv6 prefixes, fragments and icmp type/code. 
[Jon] Any comments?
 
-Jon
 
Regards
 
Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 16 February 2018 10:18
To: [email-masked]; [email-masked]
Subject: Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Hi Med,

Please see inline [TR2]

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 16, 2018 1:45 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>;
[email-masked]
Subject: RE: draft-ietf-dots-data-channel: Filtering Fields

Re-,

Please see inline. 

Cheers,

Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar
Reddy
Envoyé : vendredi 16 février 2018 08:00
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

From: Dots [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, February 14, 2018 1:49 PM
To: [email-masked]
Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Hi all, 

As agreed during the interim, there are some issues that need fixes in the
data-channel spec. We would like to hear from the WG to know what to record
in the document. 

Issue description: Should we support all of the match fields defined by
“ietf-packet-fields” or do we need to define a minimum supported set? 

[TR] I don’t see the need to support all the match fields, define a minimum
supported set (don’t see the use for acl-eth-header-fields for DOTS use
cases).  

[Med] Agree that acl-eth-header-fields aren’t required. The text is already
clear about this:

   combination thereof.

The question is whether we need to go further and mandate (or not) the
support of matching based on specific fields: dscp, ecn, ttl,… flow-label, …
tcp sequence-number, tcp flags, …  
 
[TR2]  <https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16>
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 uses the feature
statements in the YANG model allowing vendors to advertise match rules they
are capable and willing to support but not at the field-level. The problem
is router implementations today don’t support ACLs with tcp sequence-number,
acknowledgement-number, window-size etc but support TCP flags. If the server
could convey the list of match criteria supported, it not only allows the
client to convey the supported match rules but also allows the server in
future to advertise the new supported match fields.   

Would it be useful for a client to retrieve the list of match criteria
supported by a DOTS server? 

[TR2] Yes. 

-Tiru

[TR] The YANG model supported by the DOTS server can retrieved by the DOTS
client using RESTCONF to determine the match criteria supported by the
server. 

[Med] I’m afraid this is not the same functionality. If we need to allow a
server to return its supported match criteria, this should be allowed by the
module. For example, the module may include the following (example): 

                +--ro capabilities
                |  +--ro match-header*
                |  |       identityref
 
The client can ask the server to return its supported match criteria. The
server will indicate the exact set of fields it supports. 
 
I’m not expressing a preference to have this in the model, but I’m
clarifying how it would look like. 

-Tiru

Please comment. 

Cheers,

Med

---

From: <[email-masked]>
Date: Tue, 20 Feb 2018 09:22:21 +0000

Hi Jon,

I confirm that the intent is not to discuss "how" or "have a DOTS version of the parameters" but whether the functionality is useful (including when translating filtering rules into network-specific actions).

What I had initially in mind is, based on the outcome of the discussion, raise the point during the IETF LC of draft-ietf-netmod-acl and push for it there.

Glad to see that we are in agreement.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 20 février 2018 10:11
À : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; [email-masked]
Objet : RE: [Dots] draft-ietf-dots-data-channel: Value and/or Range

As the intent is to follow netmod-acl-model syntax, having a DOTS version of some of the parameters makes no sense to me.

For example, the DOTS server when communicating with the DOTS mitigator (albeit out of scope) will have to translate the current set of ACL definitions into something - e.g. real netconf-acl.  With the exact modelling of netmod-acl-model parameters, life is a lot easier as we just have to strip out the DOTS specific parameters (e.g. lifetimes).

The right place to get this done is to get the netmod-acl-model authors to update their definitions of ietf-packet-fields.

As draft-ietf-netmod-acl-16 can possibly change (we have seen significant changes over the last few updates), we need to consider referring to the specific version of ietf-packet-fields in the DOTS data channel Yang model.

Regards

Jon

Hi Jon,

Good point.

·         Length fields

·         TTL

Cheers,
Med

Regards

Jon

We may want to add

-Tiru

Re-,

   Header Mandatory Fields

Please comment/update.

Cheers,
Med

-Tiru

Re-,

Cheers,
Med

Hi Med,

See inline [Jon]

Regards

Jon

Jon,

Please see inline.

Cheers,
Med

[Med] Fair.

[Jon] Any comments?

-Jon

Regards

Jon

Hi Med,

Please see inline [TR2]

Re-,

Please see inline.

Cheers,
Med

Hi all,

[TR2] Yes.

-Tiru

                +--ro capabilities

                |  +--ro match-header*

                |  |       identityref

-Tiru

Please comment.

Cheers,

Med