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

From: <[email-masked]>
Date: Fri, 24 Sep 2021 08:52:30 +0000

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-masked]]
> Envoyé : jeudi 23 septembre 2021 10:45
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> 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:

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. 

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

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

> 
> (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).";
          }

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.";
           }
        ...

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

_________________________________________________________________________________________________________________________

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Sep 2021 16:51:03 -0700

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

> [[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 prov…

Exactly, just want to resolve the corner case.  The proposal below (as in
the -13) does so nicely; thanks.

> [[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 wit…

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]] 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]] 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) d…

Okay, if the WG considered this topic already I don't think I have more to
add.  Thanks for confirming.

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

>                "SAD-entry-unique name to identify this

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]] 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 deployment…

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

---

From: <[email-masked]>
Date: Tue, 28 Sep 2021 07:00:18 +0000

Hi Ben, 

Please see inline. 

Cheers,
Med

> De : Benjamin Kaduk <[email-masked]>
> Envoyé : mardi 28 septembre 2021 01:51
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> (with DISCUSS)
> 
> Hi Med,
> 
> > > De : Benjamin Kaduk via Datatracker [mailto:[email-masked]] Envoyé
> > > : jeudi 23 septembre 2021 10:45 À : The IESG <[email-masked]> Cc :
> > > [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]; [email-masked] Objet :
> > > Benjamin Kaduk's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> > > 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.)
> > >
> > >
> > > (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
> > > 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:
> 
> > 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:
> > > connected" list for BGP routing, that is also keyed on an
> > > address-family identityref.
> >
> > > (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.
> 
> 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.

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

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

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