From nobody Thu Apr 14 14:01:05 2022 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6011E3A185F; Thu, 14 Apr 2022 14:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0TwH554b1jW; Thu, 14 Apr 2022 14:00:55 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E12D3A185D; Thu, 14 Apr 2022 14:00:55 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id e22so5195818qvf.9; Thu, 14 Apr 2022 14:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=u/f8TrxHZi8ozujIeiQA/woKp1odQY/pKhIroG5yzPg=; b=SALOB2/rJJqgNsvh3bHkNv5zTN3YoT35aRcJfVeacIuaBUhlW+DCVeQQNK9LmEOehb JyXDPTl7yImsFaGhKU/J/on+rZ44nIoZalEs6CDPqJ+prymntDAHki/7NnPKBq2ooYTJ H3vog5LZdkA+pZwRwmuraqDCW2cmre28RfWWf8C4PKGXVyIVEZGlYSRcm9eMshsoZr1s qn6+w8lfN2SGtrRTk/QmkYj3/Innvxf0C9JNiKqxrHt7ckVsid3Ks4afrhyMPYMwJxQ6 ldsElMl5/j2bqxqxOUqfg6yQAyqHnRY3De5um1Agk6ksSdqOqGh00y8voWFZ04Mc72Rz UYww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=u/f8TrxHZi8ozujIeiQA/woKp1odQY/pKhIroG5yzPg=; b=kSyfPYI24FrBH0vkSNGydUjwGXwfz1xNs5Ai6ps8aIXxqY9ygRD5EITFqyPQTJalt/ Ak7i++jT2hVvwqTjjjncIvWiZL3LRlsyvsPN5ieUlMiKWQ4FHLZX7C+eY43mMLsHlDin +tWhgGGCX0lfWuVEiAJdH1MTNsrLmvaYsHV0Kyt5StnDtjCeUXYVtLoFH1h+sJ7aKSC1 6E3H0mbB5WQX7d62r4GP/FvbsTCNgVj4xCp1kglwvFrY15LMJ3+G+dYGrJpR05Azydvg mGieqN6ggqCY+88gp9yM6x4pN9hG3U2uaDBZkqo3ltJtcWuFT/wHQQOMl/Yj+v5xls3u pBfg== X-Gm-Message-State: AOAM530bUQRlz0mPPOiFlC3yG2nqFkifYbYAkmHj22ZzkddfLmiozgus lKWBzHgWwSaUm7RxA9qO17Qoja/5XYW19g== X-Google-Smtp-Source: ABdhPJyEoCLiVF6Gv88XtPPlXU7qymffN7nfYMnZeOq4JiASt4ILw6QJkNU+cOEMSQ0KQGGR+wAeCg== X-Received: by 2002:a05:6214:20e4:b0:441:8031:9152 with SMTP id 4-20020a05621420e400b0044180319152mr5069549qvk.115.1649970054055; Thu, 14 Apr 2022 14:00:54 -0700 (PDT) Received: from smtpclient.apple (adsl-70-234-233-187.dsl.rcsntx.sbcglobal.net. [70.234.233.187]) by smtp.gmail.com with ESMTPSA id 20-20020ac84e94000000b002ef2ab3f499sm2060765qtp.3.2022.04.14.14.00.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2022 14:00:53 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <6DC607A8-2CC2-4DA8-AA1D-A7DEAE65408B@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_61E74A87-7557-4B4C-AB41-378A6B663586" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 14 Apr 2022 14:00:52 -0700 In-Reply-To: <20220302140422.GE13378@pfrc.org> Cc: Michael SCHARF , "idr-chairs@ietf.org" , "tcpm@ietf.org Extensions" To: Jeffrey Haas References: <4E897FFF-4C6B-43DB-9623-7F168898ECF0@pfrc.org> <20220225214059.GD452@pfrc.org> <94B53B56-1971-4FD1-A557-CF713CEEA62D@gmail.com> <6CACD42C-28D4-4209-B61A-E3F522C0DAE4@pfrc.org> <22b1e046fe6846b0a04e3b430357fb2b@hs-esslingen.de> <20220302140422.GE13378@pfrc.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [tcpm] [Idr] Last Call: (A YANG Model for Transmission Control Protocol (TCP) Configuration) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 21:01:01 -0000 --Apple-Mail=_61E74A87-7557-4B4C-AB41-378A6B663586 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Pruning the list down to the issue of TCP-AO configuration] Hi Jeff, > On Mar 2, 2022, at 6:04 AM, Jeffrey Haas wrote: >=20 >>>>=20 >>>> + The binding between a send-id and receive-id likely belong in the >>>> keychain. This likely requires augmenting the keychain model. >>=20 >>> Did you mean binding between tcp-ao and the keychain model it is = using? >>=20 >> I mean that send-id/receive-id state likely belongs in an individual = keychain entry. That means the keychain model needs augmenting. The = augmentation can be sourced from the tcpm RFC. >>=20 >> [ms] That solution (used by all known router implementations) is = already explicitly explained in draft-ietf-tcpm-yang-tcp-06 as follows: = =E2=80=9CThe keychain for TCP-AO can be modeled by the YANG Data Model = for Key Chains [RFC8177]. The groupings defined in this document can be = imported and used as part of such a preconfiguration.=E2=80=9D >=20 > I don't find the example clear. As noted above, configuration state = in > existing implementations requires a binding of a send-id and a = receive-id > (TCP-AO configuration state) to the keychain entry. Ok. >=20 >> [ms] Now, the challenge is that this solution would require an update = to RFC8177, and I don=E2=80=99t know if and when this would happen. One = option would just to define the grouping in draft-ietf-tcpm-yang-tcp and = do not define its use in the keychain, i.e., to leave that open until a = 8177bis document is done. We tried to find an alternative that can work = with the existing RFC8177 model instead. That does not prevent use of = the grouping in a future key-chain standard. >=20 > I will, perhaps unpopularly, argue that its dereliction of duty to = throw > your hands up and say "we can't get our responsible component to work > because of someone else's work". >=20 > If you own the YANG model for TCP-AO, you're responsible for figuring = out > how it should work. >=20 > If you can do it solely within your module, this is easy and done. >=20 > What is far more likely is that TCP-AO state needs to be coupled in = with the > keychain. If this can be done in a way that lets you satisfy = providing a > useful model for TCP-AO by augmenting the keychain model, that's a > reasonable path forward. Simply defining a grouping isn't the full = extent > of the work, defining the augmentation would be. Augmentation is certainly one way to make the binding, but may not be = the only way. I propose that the TCP model include a reference to the = keychain model. As modified, there is now a keychain reference on a per = connection basis that can be used for either TCP-AO or MD5. Here is what = the modified tree diagram looks like: +--rw tcp! +--rw connections | +--rw connection* | [local-address remote-address local-port remote-port] | +--rw local-address inet:ip-address | +--rw remote-address inet:ip-address | +--rw local-port inet:port-number | +--rw remote-port inet:port-number =E2=80=A6.. | +--rw authentication | +--rw keychain? | | key-chain:key-chain-ref | +--rw (authentication)? | +--:(ao) | | +--rw enable-ao? boolean | | +--rw send-id? uint8 | | +--rw recv-id? uint8 | | +--rw include-tcp-options? boolean | | +--rw accept-key-mismatch? boolean | | +--ro r-next-key-id? uint8 | +--:(md5) | +--rw enable-md5? boolean The example in the draft has been updated to reflect this change. Let me = know if this looks good. The full set of changes can be found here = . Separately, the BGP YANG model can now remove the container for = secure-session, leaving it up to this model to define how a TCP = connection is secured.=20 >=20 > If your analysis (because you're the group with the expertise) is that > configuration of TCP-AO does require binding of configuration state = from > TCP-AO into the keychain, but the keychain has structural issues that > prevent this from being current viable, IETF as a whole has a problem: = The > modules don't inter-work. >=20 > What should IETF do when such inter-work issues are identified? Fix = them. >=20 > What should tcpm or other Working Groups do about configuration state = if > such inter-work issues are identified? Perhaps hold up publishing = your > model until it can be fixed - the process for fixing YANG models is = painful > even for trivial things much less things that will require = restructuring. > Alternatively, if operational state is fine, perhaps configuration = state is > deferred to a later model while working through the issue with the = other > dependent Working Groups. >=20 >> [ms] I agree that a TCP connection will typically *not* be set up by = configuration state but instead by the socket APO. Thus the connection = list is most likely operational state only. The unknown is how TCP-AO = configuration would be provisioned in that case. If it is indeed done by = the key-chain, we may not require corresponding configuration state in = draft-ietf-tcpm-yang-tcp. >=20 > That's a possible way this goes. >=20 > But if the answer is that it belongs in the keychain model and the > configuration state is motivated by TCP-AO, it's reasoanble this = Working > Group supplies that model. Alternatively, this Working Group = initiates the > inter-working group discussion to solve the broader problem. >=20 > Such inter-work discussions are effectively why I'm here wearing my = BGP YANG > hat. :-) Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_61E74A87-7557-4B4C-AB41-378A6B663586 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Pruning the list down to the issue of TCP-AO = configuration]

Hi = Jeff,

On Mar 2, 2022, at 6:04 AM, Jeffrey Haas = <jhaas@pfrc.org> = wrote:


+ The binding between a send-id and = receive-id likely belong in the
  keychain. =  This likely requires augmenting the keychain model.

Did you mean binding between tcp-ao and the = keychain model it is using?

I = mean that send-id/receive-id state likely belongs in an individual = keychain entry.  That means the keychain model needs augmenting. =  The augmentation can be sourced from the tcpm RFC.
[ms] That solution (used by all known router = implementations) is already explicitly explained in = draft-ietf-tcpm-yang-tcp-06 as follows: =E2=80=9CThe keychain for TCP-AO = can be modeled by the YANG Data Model for Key Chains [RFC8177]. The = groupings defined in this document can be imported and used as part of = such a preconfiguration.=E2=80=9D

I don't find the example clear. =  As noted above, configuration state in
existing implementations = requires a binding of a send-id and a receive-id
(TCP-AO configuration state) to = the keychain entry.

Ok.


[ms] Now, the challenge is that this = solution would require an update to RFC8177, and I don=E2=80=99t know if = and when this would happen. One option would just to define the grouping = in draft-ietf-tcpm-yang-tcp and do not define its use in the keychain, = i.e., to leave that open until a 8177bis document is done. We tried to = find an alternative that can work with the existing RFC8177 model = instead. That does not prevent use of the grouping in a future key-chain = standard.

I will, perhaps unpopularly, argue that its dereliction of = duty to throw
your hands up = and say "we can't get our responsible component to work
because of someone else's = work".

If you own = the YANG model for TCP-AO, you're responsible for figuring out
how it should work.

If you can do it solely within = your module, this is easy and done.

What is far more likely is that TCP-AO state needs to be = coupled in with the
keychain.  If this can be done in a way that lets you = satisfy providing a
useful model for TCP-AO by augmenting the keychain model, = that's a
reasonable = path forward.  Simply defining a grouping isn't the full = extent
of the work, = defining the augmentation would be.

Augmentation is certainly one way to make the binding, = but may not be the only way. I propose that the TCP model include a = reference to the keychain model. As modified, there is now a keychain = reference on a per connection basis that can be used for either TCP-AO = or MD5. Here is what the modified tree diagram looks like:

  +--rw tcp!
    =  +--rw connections
     |  +--rw = connection*
     |         =  [local-address remote-address local-port = remote-port]
     |     +--rw = local-address     inet:ip-address
    =  |     +--rw remote-address   =  inet:ip-address
     |     = +--rw local-port       =  inet:port-number
     |     = +--rw remote-port       inet:port-number
  =    =E2=80=A6.. <stuff deleted>
    =  |     +--rw authentication
    =  |        +--rw keychain?
  =    |        |       = key-chain:key-chain-ref
     |     =    +--rw (authentication)?
     | =           +--:(ao)
    =  |           |  +--rw enable-ao? =             boolean
  =    |           |  +--rw send-id? =               uint8
  =    |           |  +--rw recv-id? =               uint8
  =    |           |  +--rw = include-tcp-options?   boolean
     | =           |  +--rw accept-key-mismatch? =   boolean
     |       =     |  +--ro r-next-key-id?         = uint8
     |           = +--:(md5)
     |         =      +--rw enable-md5?           =  boolean

The example in the = draft has been updated to reflect this change. Let me know if this looks = good. The full set of changes can be found here.

Separately, the = BGP YANG model can now remove the container for secure-session, leaving = it up to this model to define how a TCP connection is = secured. 


If your analysis (because you're the group with the = expertise) is that
configuration of TCP-AO does require binding of configuration = state from
TCP-AO into = the keychain, but the keychain has structural issues that
prevent this from being current = viable, IETF as a whole has a problem: The
modules don't inter-work.

What should IETF do when such inter-work issues are = identified?  Fix them.

What should tcpm or other Working Groups do about = configuration state if
such inter-work issues are identified?  Perhaps hold up = publishing your
model until it can be fixed - the process for fixing YANG = models is painful
even for trivial things much less things that will require = restructuring.
Alternatively, if operational state is fine, perhaps = configuration state is
deferred to a later model while working through the issue = with the other
dependent Working Groups.

[ms] I agree that a TCP connection = will typically *not* be set up by configuration state but instead by the = socket APO. Thus the connection list is most likely operational state = only. The unknown is how TCP-AO configuration would be provisioned in = that case. If it is indeed done by the key-chain, we may not require = corresponding configuration state in draft-ietf-tcpm-yang-tcp.

That's a possible way this goes.

But if the answer is that it = belongs in the keychain model and the
configuration state is motivated by TCP-AO, it's reasoanble = this Working
Group = supplies that model.  Alternatively, this Working Group initiates = the
inter-working = group discussion to solve the broader problem.

Such inter-work discussions are = effectively why I'm here wearing my BGP YANG
hat. :-)


Mahesh = Jethanandani
mjethanandani@gmail.com






= --Apple-Mail=_61E74A87-7557-4B4C-AB41-378A6B663586--