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

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
> Envoyé : lundi 24 septembre 2018 11:39
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [e-mail]; [e-mail]; opsawg-
> [e-mail]; The IESG
> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-
> 15: (with DISCUSS)
> 
> Hi med,
> 
> inline...
> 
> > Am 24.09.2018 um 11:31 schrieb <[e-mail]>
> <[e-mail]>:
> >
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
> >> Envoyé : lundi 24 septembre 2018 11:23
> >> À : BOUCADAIR Mohamed IMT/OLN
> >> Cc : The IESG; [e-mail]; [e-mail];
> opsawg-
> >> [e-mail]
> >> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-
> yang-
> >> 15: (with DISCUSS)
> >>
> >> Hi Med,
> >>
> >> please see inline.
> >>
> >>> Am 24.09.2018 um 10:55 schrieb <[e-mail]>
> >> <[e-mail]>:
> >>>
> >>> Re-,
> >>>
> >>> Please see inline.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
> >>>> Envoyé : lundi 24 septembre 2018 10:14
> >>>> À : BOUCADAIR Mohamed IMT/OLN
> >>>> Cc : The IESG; [e-mail]; [e-mail];
> >> opsawg-
> >>>> [e-mail]
> >>>> 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.
> >>
> >> 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).
> >>
> >>>
> >>>
> >>>> 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.
> >>
> >> 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.
> 
> 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.  

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