Subject: [Dots] draft-ietf-dots-data-channel: Filtering Fields

From: <[email-masked]>
Date: Wed, 14 Feb 2018 08:19:16 +0000

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?
Would it be useful for a client to retrieve the list of match criteria supported by a DOTS server?

Please comment.

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 06:59:52 +0000

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,

[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).

[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.

-Tiru

Please comment.

Cheers,

Med

---

From: <[email-masked]>
Date: Fri, 16 Feb 2018 08:14:41 +0000

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]<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,

[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, ...

[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: Fri, 16 Feb 2018 10:17:36 +0000

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]<mailto:[email-masked]>
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

Hi all,

[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.

[TR2] Yes.

-Tiru

                +--ro capabilities

                |  +--ro match-header*

                |  |       identityref

-Tiru

Please comment.

Cheers,

Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 12:24:04 -0000

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?
 
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.  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.
 
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. 
 
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: Fri, 16 Feb 2018 12:55:40 +0000

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]
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.

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.

  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.

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

Hi all,

[TR2] Yes.

-Tiru

                +--ro capabilities

                |  +--ro match-header*

                |  |       identityref

-Tiru

Please comment.

Cheers,

Med

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 13:29:00 -0000

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

 
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. 
 
[Jon] Any comments?
 
-Jon
 
Regards
 
Jon

Hi Med,

Please see inline [TR2]

Re-,

Please see inline. 

Cheers,

Med

Hi all, 

   combination thereof.

[TR2] Yes. 

-Tiru

                +--ro capabilities
                |  +--ro match-header*
                |  |       identityref

-Tiru

Please comment. 

Cheers,

Med

---

From: <[email-masked]>
Date: Fri, 16 Feb 2018 13:33:27 +0000

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]<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,

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

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

[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.

[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: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 13:55:11 +0000

+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-,

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

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: Fri, 16 Feb 2018 14:33:31 +0000

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]
Objet : Re: [Dots] draft-ietf-dots-data-channel: Filtering Fields

-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-,

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: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 15:20:05 -0000

Hi Med,

I agree with the list (and am likely to only implement those!).

As I see it, there are 2 possible ways forward here

1)      We add in an Boolean ‘supported’ capability for the list of all the
other options in packet-fields:acl-xxx

2)      We drop the use of “uses packet-fields:acl-xxx” and define our own
required entries, exactly modelled on draft-ietf-netmod-acl-model-16
definitions.

Comments?

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 16 February 2018 14:34
To: Konda, Tirumaleswar Reddy; Jon Shallow; [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

+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

Hi Med,

See inline [Jon]

Regards

Jon

Jon,

Please see inline.

Cheers,

Med

 

 

-Jon
 
Regards
 
Jon

Hi Med,

Please see inline [TR2]

Re-,

Please see inline. 

Cheers,

Med

Hi all, 

   combination thereof.

[TR2] Yes. 

-Tiru

                +--ro capabilities
                |  +--ro match-header*
                |  |       identityref

-Tiru

Please comment. 

Cheers,

Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 16 Feb 2018 15:45:59 +0000

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

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

-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: Fri, 16 Feb 2018 15:54:47 +0000

Re-,

I went in my local copy with the "uses packet-fields:acl-xxx" for managing filters, but added a new container to list the capabilities to our module. Below an excerpt of the (draft) tree structure:

    +--ro capabilities
       +--ro address-family*        enumeration
       +--ro supported-actions*     identityref
       +--ro fragment-support*      enumeration
       +--ro transport-protocols* [protocol-id]
       |  +--ro protocol-id      uint8
       |  +--ro protocol-name?   string
       +--ro ip-header-fields
          +--ro dscp-support?          boolean
          +--ro ecn-support?           boolean
          +--ro v4-length-support?     boolean
          +--ro v6-length-support?     boolean
          +--ro v4-ttl-support?        boolean
          +--ro v6-hoplimit-support?   boolean
          +--ro v4-ihl?                boolean
          +--ro v4-flags?              boolean
          +--ro v4-offset?             boolean
          +--ro v4-identification?     boolean
         +--ro v6-flowlabel?          boolean
          +--ro destination-prefix?    boolean
          +--ro source-prefix?         boolean
             ...

Cheers,
Med

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

Hi Med,

1)      We add in an Boolean 'supported' capability for the list of all the other options in packet-fields:acl-xxx

2)      We drop the use of "uses packet-fields:acl-xxx" and define our own required entries, exactly modelled on draft-ietf-netmod-acl-model-16 definitions.

Comments?

Regards

Jon

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

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: "Jon Shallow" <[email-masked]>
Date: Fri, 16 Feb 2018 16:14:29 -0000

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

-Tiru

Re-,

Cheers,

Med

Hi Med,

See inline [Jon]

Regards

Jon

Jon,

Please see inline.

Cheers,

Med

 

 

-Jon
 
Regards
 
Jon

Hi Med,

Please see inline [TR2]

Re-,

Please see inline. 

Cheers,

Med

Hi all, 

   combination thereof.

[TR2] Yes. 

-Tiru

                +--ro capabilities
                |  +--ro match-header*
                |  |       identityref

-Tiru

Please comment. 

Cheers,

Med

---

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

Hi Tiru,

Thank you.

Unless there is an objection, I will add length fields to the table.

I know router vendors who support TTL-based ACLs, but I don't think this is a reason to set TTL as mandatory-to-support for the DOTS case. For example, if upstream networks enforce policies based on a TTL range, this will have a side effect to filter packets that are destined to a leaf DOTS client domain.

Cheers,
Med

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

We may want to add

-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-,

   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: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 19 Feb 2018 07:43:02 +0000

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

Hi Tiru,

Thank you.

I did not get the response, what is the side effect ?

-Tiru

Cheers,
Med

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 07:58:59 +0000

Re-,

The (positive) side effect is that the leaf network will be protected because of the filters enforced at the upstream network. In other words, TTL-based filters issued by the leaf network may be redundant with the ones enforced by the upstream network.

Cheers,
Med

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

Hi Tiru,

Thank you.

-Tiru

Cheers,
Med

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: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 19 Feb 2018 10:04:56 +0000

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

Re-,

If it's a positive side effect, why not make TTL mandatory-to-support ?

-Tiru

Cheers,
Med

Hi Tiru,

Thank you.

-Tiru

Cheers,
Med

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: "Jon Shallow" <[email-masked]>
Date: Tue, 20 Feb 2018 09:49:23 -0000

Hi Med,

If we go with the capabilities model, instead of just defining the subset
that is supported in the filter fields in the Yang model, the below
suggestion adds in a lot of bloat into the packets as well as extra code in
the DOTS server (which could be in a constrained environment –e.g. in
https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1).

For example, all 256 different IP protocols will have to be defined under
transport-protocols, along with their protocol names if all of them are to
be supported (yes, I know 0 and 255 sometimes have special meanings!).

Regards

Jon

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

Re-,

I went in my local copy with the “uses packet-fields:acl-xxx” for managing
filters, but added a new container to list the capabilities to our module.
Below an excerpt of the (draft) tree structure:

    +--ro capabilities

       +--ro ip-header-fields

          +--ro v4-ihl?                boolean

          +--ro v4-flags?              boolean

          +--ro v4-offset?             boolean

             …

Cheers,

Med

Hi Med,

Comments?

Regards

Jon

Re-,

   Header Mandatory Fields

   TCP    flags

   ICMP   type and code

Please comment/update. 

Cheers,

Med

-Tiru

Re-,

Cheers,

Med

Hi Med,

See inline [Jon]

Regards

Jon

Jon,

Please see inline.

Cheers,

Med

 

 

-Jon
 
Regards
 
Jon

Hi Med,

Please see inline [TR2]

Re-,

Please see inline. 

Cheers,

Med

Hi all, 

   combination thereof.

[TR2] Yes. 

-Tiru

                +--ro capabilities
                |  +--ro match-header*
                |  |       identityref

-Tiru

Please comment. 

Cheers,

Med

---

From: <[email-masked]>
Date: Tue, 20 Feb 2018 10:15:41 +0000

Re-,

Please see inline.

Cheers,
Med

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

Hi Med,

If we go with the capabilities model, instead of just defining the subset that is supported in the filter fields in the Yang model, the below suggestion adds in a lot of bloat into the packets as well as extra code in the DOTS server (which could be in a constrained environment -e.g. in https://tools.ietf.org/html/draft-ietf-dots-use-cases-09#section-3.2.1).

[Med] Those may not implement the capability part of the module and then will likely to encounter errors when asking for a match/action capability not supported by the server.

For example, all 256 different IP protocols will have to be defined under transport-protocols
[Med] Actually, no. A number will be included in the capabilities only if transport-specific filtering is supported. For example, DCCP will be included if filtering based on DCCP fields is supported. So, this is likely to be at maximum tcp/udp/icmp.

, along with their protocol names
[Med] Name is optional. It can be removed.

if all of them are to be supported (yes, I know 0 and 255 sometimes have special meanings!).

Regards

Jon

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

Re-,

    +--ro capabilities

Cheers,
Med

Hi Med,

Comments?

Regards

Jon

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