Subject: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-15: (with DISCUSS)

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 21 Sep 2018 09:19:39 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-opsawg-nat-yang-15: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for a well-written document and also for considering other protocols
like SCTP. I've put in a discuss because I would really like have a quick
discussion here to double-check that we do the right thing, however, it might
well be that we can resolve this discuss without any changes. My question is:
given the model is designed to be generic enough to incorporate other transport
protocols, I'm wondering if it would be possible to also define the timers you
have there in a more generic way such that they can be re-used for other
protocols (maybe just changing the name and adding some explanation text).

As a side node: I myself have been working on a model for a
protocol-independent state machine a bit (see draft-trammell-plus-statefulness;
now expired); maybe that's a helpful reference to have a quick look at…

---

From: <[email-masked]>
Date: Mon, 24 Sep 2018 05:39:50 +0000

Hi Mirja, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de Mirja Kühlewind
> Envoyé : vendredi 21 septembre 2018 18:20
> À : The IESG
> Cc : [email-masked]; [email-masked]; opsawg-
> [email-masked]
> Objet : [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-15:
> (with DISCUSS)
> 

[Med] The document includes timers that are valid for any transport protocol (e.g., per-port-timeout, hold-down, etc.). Things are more complicated for the other timers. For example, one could imagine that the same timer can be used to timeout any session (e.g., UDP and ICMP), nevertheless we do have different default/recommended values per transport protocol (e.g., 300s for UDP and 60s for ICMP). Also, existing implementations/deployments are used to allow for differentiating the behavior per transport protocol. For TCP, there are more state compared to UDP, hence the need for more specific timers. Other protocols may reuse some of these specific timers if needed. This should be described in an extension document, not in this one.

> now expired); maybe that's a helpful reference to have a quick look at…

[Med] Thank you for the reference. 

> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 24 Sep 2018 10:14:29 +0200

Hi Med,

thanks for you reply. It makes sense that you may want different values for different protocol in the case of UDP and TCP. However, I think the question is not that much which protocol but which properties does the protocol have, e.g. all connection-oriented protocol probably have some kind of handshake that can be used to trigger these timers.

Is it maybe possible to model these times generally for certain protocol feature and the have the ability to overwrite these „default“ values with protocol-specific values? 

Given that these protocol specific differences especially in NAT are a huge problem for the deployment of new protocol it would be really nice if this could be model in a generic as possible way. E.g. would be nice to be able to use the same config for the config for quic (one a NAT is implemented to detect the quic handshake over udp).

Mirja

> Am 24.09.2018 um 07:39 schrieb <[email-masked]> <[email-masked]>:
> 
> Hi Mirja, 
>

---

From: <[email-masked]>
Date: Mon, 24 Sep 2018 08:55:50 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Envoyé : lundi 24 septembre 2018 10:14
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : The IESG; [email-masked]; [email-masked]; opsawg-
> [email-masked]
> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-
> 15: (with DISCUSS)
> 
> Hi Med,
> 
> thanks for you reply. It makes sense that you may want different values for
> different protocol in the case of UDP and TCP.
 However, I think the question
> is not that much which protocol but which properties does the protocol have,
> e.g. all connection-oriented protocol probably have some kind of handshake
> that can be used to trigger these timers.
> 

[Med] I hear you... but the issue is the other way around: availability of a stateful implementation which adheres to that design approach.

> Is it maybe possible to model these times generally for certain protocol
> feature and the have the ability to overwrite these „default“ values with
> protocol-specific values?

[Med] There are ways to overwrite default values, e.g., define a type and derive new one from it. Nevertheless, it is simpler to define explicit timers as we have done in the document given that protocol differentiation is a requirement. One for UDP, one for ICMP, and state-specific timers for TCP. Future documents can re-use state-specific timers for generic configuration matters, if needed. 

> 
> Given that these protocol specific differences especially in NAT are a huge
> problem for the deployment of new protocol it would be really nice if this
> could be model in a generic as possible way. E.g. would be nice to be able to
> use the same config for the config for quic (one a NAT is implemented to
> detect the quic handshake over udp).

[Med] For the quic example, one would argue that the UDP-related config parameters are sufficient; there is even no need to inspect whether this is quic or plain UDP packet.

> > [Med] The document includes timers that are valid for any transport
> protocol (e.g., per-port-timeout, hold-down, etc.). Things are more
> complicated for the other timers. For example, one could imagine that the
> same timer can be used to timeout any session (e.g., UDP and ICMP),
> nevertheless we do have different default/recommended values per transport
> protocol (e.g., 300s for UDP and 60s for ICMP). Also, existing
> implementations/deployments are used to allow for differentiating the
> behavior per transport protocol. For TCP, there are more state compared to
> UDP, hence the need for more specific timers. Other protocols may reuse some
> of these specific timers if needed. This should be described in an extension
> document, not in this one.
> >
> >>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 24 Sep 2018 11:23:07 +0200

Hi Med,

please see inline.

> Am 24.09.2018 um 10:55 schrieb <[email-masked]> <[email-masked]>:
> 
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 

Understood. And I also understand that your motivation is to aline with existing implementations, which makes sense. I just wonder if there is a way to make it even easier to enable new implementations for other protocols in future (without defining a new protocol-specific extension).

> [Med] There are ways to overwrite default values, e.g., define a type and derive new one from it. Nevertheless, it is simpler to define explicit timers as we have done in the document given that pr…

What about maybe renaming the timers and don’t have tcp in the name but explain in the text that these timer are used for tcp but could/should also be used for other connection-oriented protocols…? Would that be an option that could eventually help? E.g. call the "tcp-trans-open-timeout“ just "trans-open-timeout“ and explain that RFC 7857 specifies this for TCP but other implementation for connection-oriented protocols could use the same timer? Just thinking...

> [Med] For the quic example, one would argue that the UDP-related config parameters are sufficient; there is even no need to inspect whether this is quic or plain UDP packet.

No, that’s exactly the problem. QUIC is a connection-oriented protocol, so it would potentially be possible and desirable to have longer time-outs than you usually have for other UDP traffic. 

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 24 Sep 2018 11:29:06 +0200

Hi Med,

one more small nit that I saw just now. Maybe you can change 

"NAT64 translation allows IPv6-only clients to contact IPv4
       servers using unicast UDP, TCP, or   ICMP.“

to something like

"NAT64 translation allows IPv6-only clients to contact IPv4
       servers using e.g. UDP, TCP, or ICMP.“

Thanks!
Mirja

---

From: <[email-masked]>
Date: Mon, 24 Sep 2018 09:31:18 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 24 septembre 2018 11:23
> > [Med] I hear you... but the issue is the other way around: availability of
> a stateful implementation which adheres to that design approach.
> 
> Understood. And I also understand that your motivation is to aline with
> existing implementations, which makes sense. I just wonder if there is a way
> to make it even easier to enable new implementations for other protocols in
> future (without defining a new protocol-specific extension).
> 
> >
> >
> > [Med] There are ways to overwrite default values, e.g., define a type and
> derive new one from it. Nevertheless, it is simpler to define explicit timers
> as we have done in the document given that protocol differentiation is a
> requirement. One for UDP, one for ICMP, and state-specific timers for TCP.
> Future documents can re-use state-specific timers for generic configuration
> matters, if needed.
> 
> What about maybe renaming the timers and don’t have tcp in the name but
> explain in the text that these timer are used for tcp but could/should also
> be used for other connection-oriented protocols…? Would that be an option
> that could eventually help? E.g. call the "tcp-trans-open-timeout“ just
> "trans-open-timeout“ and explain that RFC 7857 specifies this for TCP but
> other implementation for connection-oriented protocols could use the same
> timer? Just thinking...
> 

[Med] No problem to change the name if this helps, but I'm afraid this effort may be useless if there is no reference document that explains how these timers can be used for other protocols. 

> > [Med] For the quic example, one would argue that the UDP-related config
> parameters are sufficient; there is even no need to inspect whether this is
> quic or plain UDP packet.
> 
> No, that’s exactly the problem. QUIC is a connection-oriented protocol, so it
> would potentially be possible and desirable to have longer time-outs than you
> usually have for other UDP traffic.

[Med] We can already do that with this model: per-port-timeout. An entry for 443, for example may be provided in such case. No?

> >>>> Objet : [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-
> yang-
> >> 15:
> >>>> (with DISCUSS)
> >>>>
> >>>> well be that we can resolve this discuss without any changes. My
> question
> >> is:
> >>>> protocols, I'm wondering if it would be possible to also define the
> timers
> >>>> you

---

From: <[email-masked]>
Date: Mon, 24 Sep 2018 09:36:33 +0000

Re-,

I'm afraid I cannot do this modification because that text is referring to RFC6147 which says explicitly: 

==
   This document describes stateful NAT64 translation, which allows
   IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or
   ICMP.  
==

Thank you. 

Cheers,
Med

> Envoyé : lundi 24 septembre 2018 11:29

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 24 Sep 2018 11:39:02 +0200

Hi med,

inline...

> Am 24.09.2018 um 11:31 schrieb <[email-masked]> <[email-masked]>:
> 
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 

Understood. I don’t think people go ahead an implement this without a reference doc (however, some might actually have implementation for other protocols that are just not documented in an RFC, anyway) but at least you would not necessary need to extend the yang model as soon as we have the reference docs.

> [Med] We can already do that with this model: per-port-timeout. An entry for 443, for example may be provided in such case. No?

That already help. However, you might not always want to configure a long time-out without e.g. also having the trans-open-timeout as well which would be possible to implement with quic as the handshake is visible in clear.

Btw. is the per port time-out protocol-independent? Because HTTPS is also using 443 (over TCP) and I guess you would want the usually tcp timers there. So not sure if that config using the per-port-timeout would work at all?

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 24 Sep 2018 11:43:40 +0200

I saw that, however, just because RFC6147 only specifies this for UDP, TCP and ICMP, this does mean that there cannot be a future spec that also includes other protocols and I don’t think there is need to restrict the configuration option only to these protocols.

> Am 24.09.2018 um 11:36 schrieb <[email-masked]> <[email-masked]>:
> 
> Re-,
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Sep 2018 12:12:47 +0200

> What about maybe renaming the timers and don’t have tcp in the name but explain in the text that these timer are used for tcp but could/should also be used for other connection-oriented protocols…?…

I assume renaming is not sufficient. If you insist on generic timers,
then I assume you have to send this document back to the WG to define
semantics of generic timers and how such generic timers map to
different protocols.

> No, that’s exactly the problem. QUIC is a connection-oriented protocol, so it would potentially be possible and desirable to have longer time-outs than you usually have for other UDP traffic. 

So here we already hit the first obstacle. QUIC running over UDP,
which means QUIC timers and UDP timers interacting. So the new generic
timers would have a way of expressing that. Perhaps having protocol
specific timers is good enough?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 24 Sep 2018 12:21:11 +0200

Hi Jürgen,

I don’t want to push this back to the wg (expect people would be excited on their own to further work on this, which I assume is not the case) and I do understand that this document relies on the information can be found in other specifications which is the right approach.

I’m just trying to figure out if there is anything easy to do to make it easier for future implementations which cover other protocol to also use this model (without extension). I also understand that renaming alone may not be sufficient but it also may be sufficient. We just don’t really know and therefore making the naming more generic (and mention in the doc that these timers could be used for other protocol if suitable) provides at least the chance that it would work.

Please get me right, I’m holding the discuss to exactly have this discussion. However, I don’t necessarily want to enforce a chance if that is not adequate.

Mirja

> Am 24.09.2018 um 12:12 schrieb Juergen Schoenwaelder <[email-masked]>:
>

---

From: <[email-masked]>
Date: Mon, 24 Sep 2018 11:36:04 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 24 septembre 2018 11:39
> [email-masked]; The IESG
> > [Med] No problem to change the name if this helps, but I'm afraid this
> effort may be useless if there is no reference document that explains how
> these timers can be used for other protocols.
> 
> Understood. I don’t think people go ahead an implement this without a
> reference doc (however, some might actually have implementation for other
> protocols that are just not documented in an RFC, anyway) but at least you
> would not necessary need to extend the yang model as soon as we have the
> reference docs.
> 

[Med] Another approach is that the reference document can indicate that tcp-* timers are used to instruct the behavior, and hence no medication will be required to the module. Given that we may be speculating about what would be defined in the future, I do still have a preference for the current approach in the draft. If a generic approach is defined in a future standard, then it is easy to define an extension by reusing what is already defined for TCP.  

> >>>> could be model in a generic as possible way. E.g. would be nice to be
> able
> >> to
> > [Med] We can already do that with this model: per-port-timeout. An entry
> for 443, for example may be provided in such case. No?
> 
> That already help. However, you might not always want to configure a long
> time-out without e.g. also having the trans-open-timeout as well which would
> be possible to implement with quic as the handshake is visible in clear.
> 
> Btw. is the per port time-out protocol-independent? Because HTTPS is also
> using 443 (over TCP) and I guess you would want the usually tcp timers there.
> So not sure if that config using the per-port-timeout would work at all?
> 

[Med] Good catch. A leaf is missing to indicate the protocol. If no protocol is indicated, this means "any protocol". Updated my local copy. Thanks.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 24 Sep 2018 13:44:40 +0200

Hi Med,

top-posting as we coming closer to a conclusion here. It’s okay to leave it tcp specific as you say below. Maybe you can add some text in the doc saying basically exactly what you say below, a future spec could describe how to reuse these timers. (I guess that could fit in to 2.3)…?

Mirja

> Am 24.09.2018 um 13:36 schrieb <[email-masked]> <[email-masked]>:
> 
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
>

---

From: <[email-masked]>
Date: Mon, 24 Sep 2018 11:57:56 +0000

Re-,

I can add this text to cover your comment:

   It is tempting to define TCP-specific timers as generic timers
   applying to any connection-oriented protocol.  Nevertheless, such
   approach is not followed in this document because there is no
   standard document specifying such generic behavior.  Future documents
   may be edited to clarify how to reuse TCP-specific timers when
   needed.

Please let me know if this is OK. 

Thank you.

Cheers,
Med

> Envoyé : lundi 24 septembre 2018 13:45
> top-posting as we coming closer to a conclusion here. It’s okay to leave it
> tcp specific as you say below. Maybe you can add some text in the doc saying
> basically exactly what you say below, a future spec could describe how to
> reuse these timers. (I guess that could fit in to 2.3)…?
> 
> Mirja
> 
> 
> 
> >>>>>> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-
> nat-
> >>>> yang-
> >>>>>> 15: (with DISCUSS)
> >>>>>>
> >>>>>> Hi Med,
> >>>>>>
> >>>>>> thanks for you reply. It makes sense that you may want different
> values
> >>>> for
> > [Med] Another approach is that the reference document can indicate that
> tcp-* timers are used to instruct the behavior, and hence no medication will
> be required to the module. Given that we may be speculating about what would
> be defined in the future, I do still have a preference for the current
> approach in the draft. If a generic approach is defined in a future standard,
> then it is easy to define an extension by reusing what is already defined for
> TCP.
> >
> >>>
> >>>
> >>>>>
> >>>>>>
> >>>> No, that’s exactly the problem. QUIC is a connection-oriented protocol,
> so
> >> it
> >>>> would potentially be possible and desirable to have longer time-outs
> than
> >> you
> > [Med] Good catch. A leaf is missing to indicate the protocol. If no
> protocol is indicated, this means "any protocol". Updated my local copy.
> Thanks.
> >

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 24 Sep 2018 13:59:32 +0200

Work for me. (I wouldn’t use the word tempting but anyway.)

I will clear my discuss with this update!

Mirja

> Am 24.09.2018 um 13:57 schrieb <[email-masked]> <[email-masked]>:
> 
> Re-,
>