ntp-service acl is used to configure the right for peer devices to access the IPv4 NTP services on the local device. See NTP ACL documentation example below: https://techhub.hpe.com/eginfolib/networking/docs/switches/5710/5200-4997_nmm_cr/content/517710203.htm My impression is both NTP client and NTP server are router or switch. ACL provide network level access control for NTP peer. Not sure it can be applied to ALTO case.
-Qin 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Dhruv Dhody 发送时间: 2022年12月14日 14:50 收件人: Jensen Zhang <jingxuan.n.zh...@gmail.com> 抄送: IETF ALTO <alto@ietf.org>; draft-ietf-alto-oam-y...@ietf.org 主题: Re: [alto] Open discussion on providing resource-level access control in ALTO O&M Hi Jensen, For what it's worth, rfc 9249 (NTP Yang, which I am a co-author of..) uses ACL for similar access control. module: ietf-ntp +--rw ntp! +--rw port? inet:port-number {ntp-port}? +--rw refclock-master! | +--rw master-stratum? ntp-stratum +--rw authentication {authentication}? | +--rw auth-enabled? boolean | +--rw authentication-keys* [keyid] | +--rw keyid uint32 | +--rw algorithm? identityref | +--rw key | | +--rw (key-string-style)? | | +--:(keystring) | | | +--rw keystring? string {deprecated}? | | +--:(hexadecimal) {hex-key-string}? | | +--rw hexadecimal-string? yang:hex-string | +--rw istrusted? boolean +--rw access-rules {access-rules}? | +--rw access-rule* [access-mode] | +--rw access-mode identityref | +--rw acl? -> /acl:acls/acl/name +--ro clock-state Thanks! Dhruv On Tue, Dec 13, 2022 at 3:46 PM Jensen Zhang <jingxuan.n.zh...@gmail.com<mailto:jingxuan.n.zh...@gmail.com>> wrote: Hi ALTOers, From the discussion about the ALTO O&M draft last week, we find there is another open issue that we should solve before we request YANG doctor reviews: According to Section 16.2.4 of RFC7285 and Requirement R5-3 of the ALTO O&M draft, the data model should support configuration for access control at the information resource level. In other words, the data model should configure: 1. How an ALTO server identifies an ALTO client? 2. Which ALTO clients can access a given information resource? To realize them, we consider two design options: --- Option 1: authentication and authorization based approach - To realize the first one, conceptually, we should provide data model to configure authentication and authorization for each client. It can be simply based on username and password, or delegated to other more complex authentication systems like openID and LDAP. - To realize the second one, a simple approach is to use a role-based solution. Every authenticated client can be assigned to multiple roles. And each information resource can configure to be accessible by given roles. The YANG module can be like the following: +--rw alto! +--rw alto-server ... +--rw auth-client* [username] | +--rw username string | +--rw (auth-config) | +--:(basic-auth) | | +--rw username string | | +--rw password string | ... | +--rw role* role-name +--rw resource* [resource-id] ... +-- rw accepted-role* role-name ... The choice auth-config can be augmented for different authentication protocols. We can reference or even reuse the openconfig-aaa data mode [1]. [1] https://github.com/openconfig/public/blob/master/release/models/system/openconfig-aaa.yang --- Option 2: ACL based approach This approach only requires the server to configure an ACL. We can reuse the YANG data model defined by RFC8519 [2]. It only filters the traffic by the packet attributes, not the application-level authentication. Compared with option 1, it may lose some fine-grained control. But for some simple use cases like CDN or cloud networks, it may be good enough. [2]: https://datatracker.ietf.org/doc/html/rfc8519 --- We are looking forward to seeing comments or suggestions on this open issue from the WG. Best regards, Jensen on behalf of coauthers of ALTO O&M draft
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
