Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS)

[[e-mail]]

Hi Ben, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk <[e-mail]>
> Envoyé : mardi 28 septembre 2021 01:51
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> (with DISCUSS)
> 
> 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, [e-mail]
> 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:[e-mail]] Envoyé
> > > : jeudi 23 septembre 2021 10:45 À : The IESG <[e-mail]> Cc :
> > > [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]; [e-mail] 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."

[Med] Sure. Fixed. 

> 
> > , 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.

[Med] Thanks.

> 
> > >
> > > (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."?

[Med] That was the intent. Works for me. Thanks. 

> 
> > >
> > > (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

_________________________________________________________________________________________________________________________

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.