Hi, Med: See my follow up comments marked with [Qin-1] 发件人: [email protected] <[email protected]> 发送时间: 2022年11月4日 21:58 收件人: Qin Wu <[email protected]>; [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? Also it would be great to provide xml snippet example for payload based filtering usage. But for unencrypted traffic, yes, the ACL extension provide fine granularity access control. 2.For section 3.2, I feel the solution seems not complete, how defined set is used, in the match, it lack a example to explain how it is used. [Med] We will consider adding more examples, but the defined sets can be called under the l3/l4 match conditions. Here is, for example, how a set can be referenced under l3/ipv4: augment /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace /ietf-acl:matches/ietf-acl:l3/ietf-acl:ipv4: +--rw next-header-set? leafref 3.For section 3.1, it is a good extension, but I understand the idea is to apply the same action to a set of prefixes, let's say two prefixes, since the destination-ipv6-network is defined as an array, I am wondering whether the action should be changes into 2 actions in an array: [Med] Not sure to get this comment. The proposal is to have the same action for all the addresses in a set/list. [Qin-1]: I think you are right, I am just thinking ALTO Endpoint Cost Service Example in section 11.5.1.7 of RFC7285, in the request, you describe <src,dst> pair to represent 3 endpoints, in the response, you will return the cost information for these 3 endpoints, therefore I am thinking whether you introduce a different use for JSON array usage, ie., one action applied to all the addresses represented by <destination-ipv6-network, source-ipv6-network> pairs. { "ietf-access-control-list:acls": { "acl": [ { "name": "prefix-list-support", "type": "ipv6-acl-type", "aces": { "ace": [ { "name": "my-test-ace", "matches": { "ipv6": { "destination-ipv6-network": [ "2001:db8:6401:1::/64", "2001:db8:6401:c::/64" ], "source-ipv6-network": "2001:db8:1234::/96", "protocol": 17, "flow-label": 10000 }, }, "actions": { "forwarding": [ "accept","accept"] } } ] } } ] } } Maybe one alternative solution is to use template, if we want to Manipulate Lists of Prefixes 4.I feel flags defined in RFC9519 is confusing, how does the controller know which packet is the last fragment, which packet is not, which packet needs to be fragmented, which one not,the fragment action is controlled by the ingress node, configuring flags seems wrong to me. [Med] Agree that the handling of flags in 8519 is problematic. The draft includes examples how to fix this and align with other tools such as flow spec. [Qin-1] Sounds reasonable. 5. For section 3.3 "Bind ACLs to Devices, Not Only Interfaces", do we have solution to this problem? If not, I think draft-ma-opsawg-ucl-acl-00 provide excatly the solution you are looking for if my understanding is correct, to address the limitation of IP address based access control, no need to tie to the specific interface of the device, or a single device. [Med] No solution is included for 3.3 because we think that it will be better addressed in a network model, not a device model. Also, agree that draft-ma-opsawg-ucl-acl is a good candidate. Thanks. -Qin _________________________________________________________________________________________________________________________ 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
