Hi Med, Sorry for not getting back to you last week -- I had to shift gears immediately after the telechat to another project.
Also inline... On Fri, Sep 24, 2021 at 08:52:30AM +0000, [email protected] wrote: > Hi Ben, > > (focusing on the DISCUSS part) > > Many thanks for the review. Much appreciated as usual. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk via Datatracker [mailto:[email protected]] > > Envoyé : jeudi 23 septembre 2021 10:45 > > À : The IESG <[email protected]> > > Cc : [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected] > > Objet : Benjamin Kaduk's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: > > (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-opsawg-l3sm-l3nm-11: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot- > > positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > (1) I think there may be some ambiguity we need to resolve, relating to > > per-AF router IDs and other per-AF lists: > > > > list router-id { > > key "address-family"; > > description > > "Router-id per address family."; > > leaf address-family { > > type identityref { > > base vpn-common:address-family; > > } > > description > > "Indicates the address family for which the > > Router-ID applies."; > > > > What actually gets used as the router-id for a given address family if > > both "dual-stack" and that address family are present in this list? > > > > [[Med]] If the same is used for both, then it is unlikely that the router-id > will be included under active-vpn-isntance-profile. I understand that you > want to catch corner cases where both are provided. I added this NEW general > note in Section 7.1: Exactly, just want to resolve the corner case. The proposal below (as in the -13) does so nicely; thanks. > NEW: > Some of the data nodes are keyed by the address-family. For the sake > of data representation compactness, It is RECOMMENDED to use the > dual-stack address-family for data nodes that have the same value for > both IPv4 and IPv6. If, for some reasons, a data node is present for > both dual-stack and IPv4 (or IPv6), the value that is indicated under > dual-stack takes precedence over the one that is indicated under IPv4 > (or IPv6). > > For the particular case of router-id, the general case is that the value > indicated under active-vpn-isntance-profile takes precedence. To make it > explicit (and in addition to the NEW text above), I made this change as well: > > OLD: > The structure of 'active- > vpn-instance-profiles' is the same as the one discussed in > Section 7.4 except 'router-id'. Indeed, Router IDs can be > configured per address family. This capability can be used, for > example, to configure an IPv6 address as a Router ID when such > capability is supported by involved routers. > > NEW: > The value of 'router-id' > indicated under 'active-vpn-instance-profiles' takes precedence > over the 'router-id' under the 'vpn-node' for the indicated address > family. For example, Router IDs can be configured per address > family. This capability can be used, for example, to configure an > IPv6 address as a Router ID when such capability is supported by > involved routers. > > > > There's some similar potential for amiguity in the "redistribute- > > connected" list for BGP routing, that is also keyed on an address-family > > identityref. > > [[Med]] I think this is covered by the NEW text above. > > > > > (2) In a similar vein as Roman's Discuss (and perhaps obviated by it?), > > if we're going to allow raw keys to be specified, as a string type > > [[Med]] As already clarified in the reply to Roman, we are just echoing what > is supported in the device models (already provided the reference list in > that reply). This is meant to ease mapping with these modules. Ok. I might consider a different phrasing than "in ASCII format" for the individual YANG stanzas (though I recognize there is precedent for it in what RFC 8695 did), since just that wording without the extra note in the security considerations might still be confusing to readers (i.e., including me). Perhaps something like "This model only supports the subset of keys that are representable as ASCII strings." > , we > > should be very clear about whether the string is hex-encoded, base64- > > encoded, etc., in light of deployed experience with devices that take > > the string and use it as the raw key (thereby eliminating a good chunk > > of the key space from potential use). > > [[Med]] The keys are in ASCII format for the RIP case, for example. Are you > seeking to echo such details in the network model? Yes. I want someone who sees a leaf of type "string" in this model to know exactly how to interface that string with the cryptographic operations, whether that's "pass it as is" or "base64 decode" or otherwise. The text in the -13 implies "pass it as is", which is unfortunate for the reasons noted in the -13, but does resolve any potential ambiguity. > > > > (2.5) For raw keys, should we be using nacm:default-deny-all? > > [[Med]] This was also a comment raised by Dhruv in the WGLC. But there is no > strict rule to follow here. The reason why we didn't in the L3NM is that the > corresponding device modules (RIP, IS-IS) does not use it and that > manipulating L3NM will require anyway specific right privileges that are > handled by NACM model cited in security considerations. Okay, if the WG considered this topic already I don't think I have more to add. Thanks for confirming. > > > > (3) the ipsec authentication option for the various routing protocols > > uses a string to identify an (IKE, unspecified version thereof) SA. RFC > > 7296 doesn't have the concept of a name for an IKE SA itself, so I think > > we need to provide more details on what is being named and what the > > naming authority is. IKE does have identities for the peers, if the > > goal is to refer to the peer's identity for the SA. > > [[Med]] We trusted what was already provided and reviewed in recent RFCs. For > example, we are basically echoing what was in RFC9129: > > leaf sa { > type string; > description > "Name of the Security Association (SA)."; > } It seems that I asked a similar question on the draft that will become 9129, and it was only partially answered (search for "4552"): https://mailarchive.ietf.org/arch/msg/lsr/fZGHWrNxQjXSDEJk3YpH8QvWt7Q/ So, they must be human-readable because they are to be configured, but the question of how the names are assigned and where this is to be discussed seems to have slipped through the cracks. > Note that, for example, RFC9061 indexes the Security Association Database > (SAD) by a name: > > container sad { > description > "Configuration of the IPsec Security Association > Database (SAD)."; > reference > "RFC 4301: Security Architecture for the Internet Protocol, > Section 4.4.2.1."; > list sad-entry { > key "name"; > ordered-by user; > leaf name { > type string; > description > "SAD-entry-unique name to identify this > entry."; > } > ... Sure, and having hame be the list key, with ordered-by: user, is pretty indicative that these are arbitrary strings assigned by the administrator. What can we do in this module to provide a similar indication? What about description: "Indicates the administrator-assigned name for the SA."? > > > > (4) I'd also like to have a discussion about the NTP configuration > > options; in particular, we currently have an enumeration to select > > between broadcast client and broadcast server, with no option apparent > > for symmetric or other NTP modes. Given the rigidity of YANG > > enumerations, I'd like to confirm that no other NTP modes could be > > appropriate on the network access before we lock in to this model. > > > > > > [[Med]] We spent many cycles on the NTP case before deciding to integrate it > into the module as this is needed for specific VPNs (infrastructure VPNs, as > mentioned in the I-D). For these deployments, only the two modes enumerated > in the I-D are supported (see, e.g., > https://documentation.nokia.com/html/0_add-h-f/93-0076-10-01/7750_SR_OS_Services_Guide/services_con_vprn.html > (search for "NTP Within a VPRN Service"). Enumeration seems appropriate to > us here. Thanks for the extra information. This still seems like an unneeded omission to me, but in light of the scope of this module and the need to make compromises to provide something workable while remaining of somewhat general applicability, I can migrate it to just a COMMENT-level remark. -Ben _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
