Re: [netmod] A few comments on draft-dbb-netmod-acl

[[e-mail]]

Hi Qin,

Please see inline.

Cheers,
Med

De : Qin Wu <[e-mail]>
Envoyé : vendredi 4 novembre 2022 21:19
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]
Objet : RE: A few comments on draft-dbb-netmod-acl

Hi, Med:
See my follow up comments marked with [Qin-1]
发件人: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
发送时间: 2022年11月4日 21:58
收件人: Qin Wu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
主题: RE: A few comments on draft-dbb-netmod-acl

Hi Qin,

Thanks for the comments.

Please see inline.

Cheers,
Med

De : netmod <[e-mail]<mailto:[e-mail]>> De la part de Qin Wu
Envoyé : jeudi 27 octobre 2022 08:08
À : [e-mail]<mailto:[e-mail]>
Objet : [netmod] A few comments on draft-dbb-netmod-acl

Hi, Oscar:
I have read the latest version of draft-dbb-netmod-acl, the problem statement and gap analysis are interesting, here are a few comments on this draft:
1.For problem statement in section 4.3 and section 4.5, I am wondering how  do you feel encrypted traffic at the transport layer, e.g., TLS layer or QUIC layer,
I feel it is hard, you might read one of presentation slides for IAB MTEN workshop, one gap we identify is ACL fall short to deal with encrypted traffic.

[Med] I guess this falls under a match-based on the payload:

==

3.7.  Payload-based Filtering



   Some transport protocols use existing protocols (e.g., TCP or UDP) as

   substrate.  The match criteria for such protocols may rely upon the

   'protocol' under 'l3', TCP/UDP match criteria, part of the TCP/UDP

   payload, or a combination thereof.  [RFC8519] does not support

   matching based on the payload.



   Likewise, the current version of the ACL model does not support

   filtering of encapsulated traffic.

[Qin-1] :Thank for clarification, this is exactly what I am looking for, see additional comment below.
===

The full augmentation is


     augment /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace

               /ietf-acl:matches:

       +--rw (payload)?

          +--:(prefix-pattern)

             +--rw prefix-pattern {match-on-payload}?

                +--rw offset?       identityref

                +--rw offset-end?   uint64

                +--rw operator?     operator

                +--rw prefix?       binary


Please let us know if you think this does not address the case you have in mind. Thanks.
[Qin-1] See the following identity definitions:
“
     identity layer3 {
       base offset-type;
       description
         "IP header.";
     }

     identity layer4 {
       base offset-type;
       description
         "Transport header (e.g., TCP or UDP).";
     }

     identity payload {
       base offset-type;
       description
         "Transport payload. For example, this represents the beginning
          of the TCP data right after any TCP options.";
     }

”
It looks payload definition is not generic enough to cover layer 3 payload case, when I read
“Transport payload. For example, this represents the beginning
          of the TCP data right after any TCP options.”
Transport is usually referred to layer 4, am my understanding correct?

[Med] I’m afraid it isn’t. Please note that these identities are used to populate:

=
       leaf offset {
         type identityref {
           base offset-type;
         }
         description
           "Indicates the payload offset.";
       }

==

for l3 payload cases, a l3 offset type can be used. We will make this change: s/ identity payload/ identity transport-payload

Also it would be great to provide xml snippet example for payload based filtering usage.
[Med] Yes, will do.


But for unencrypted traffic, yes, the ACL extension provide fine granularity access control.

[Med] Thanks.



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.