Hi Qin, Please see inline.
Cheers, Med De : Qin Wu <[email protected]> Envoyé : vendredi 4 novembre 2022 21:19 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; [email protected] Objet : RE: A few comments on draft-dbb-netmod-acl Hi, Med: See my follow up comments marked with [Qin-1] 发件人: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 发送时间: 2022年11月4日 21:58 收件人: Qin Wu <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 主题: RE: A few comments on draft-dbb-netmod-acl Hi Qin, Thanks for the comments. Please see inline. Cheers, Med De : netmod <[email protected]<mailto:[email protected]>> De la part de Qin Wu Envoyé : jeudi 27 octobre 2022 08:08 À : [email protected]<mailto:[email protected]> 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.
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
