Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)

[<[e-mail]>]

Re-,

My point is that combining RFC8085 and deployments where timers can be controlled/discovered is sufficient to fulfill the requirement. 

Of course, this does not guarantee that bindings are kept active if a NAT/FW assigns timers of less than 15 seconds...which is fair. The requirement does not ask for such guarantee. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
> Envoyé : jeudi 21 février 2019 14:46
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]; [e-mail]; [e-mail]; The
> IESG; [e-mail]
> Objet : Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-
> 18: (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
> please see below.
> 
> > Am 21.02.2019 um 13:17 schrieb [e-mail]:
> >
> >>>> 2) Also on this text in SIG-004:
> >>>> "The heartbeat interval during active mitigation could be
> >>>>     negotiable, but MUST be frequent enough to maintain any on-path
> >>>>     NAT or Firewall bindings during mitigation.  When TCP is used as
> >>>>     transport, the DOTS signal channel heartbeat messages need to be
> >>>>     frequent enough to maintain the TCP connection state."
> >>>>
> >>>> As Joe commented already, different heartbeats at different layers can
> be
> >>>> used
> >>>> at the same time for different purposes. You can use heartbeats at the
> >>>> application layer to check service availability while e.g. using a
> higher
> >>>> frequent heartbeat at the transport layer to maintain firewall and NAT
> >> state.
> >>>
> >>> [Med] Please note that the text you quoted is about "during active
> >> mitigation". When no attack is ongoing, we do have the following behavior
> >> which covers your comment:
> >>>
> >>>     When DOTS agents are exchanging heartbeats and no
> >>>     mitigation request is active, either agent MAY request changes to
> >>>     the heartbeat rate.  For example, a DOTS server might want to
> >>>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>     reduce heartbeat frequency or cease heartbeat exchanges when an
> >>>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>     active DOTS client has not requested mitigation, in order to
> >>>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>     control load.
> >>>
> >>>> The advantage to such an approach is that there is less application
> layer
> >>>> overhead/load e.g. in scenarios where it might be expensive to wake up
> the
> >>>> application or a server is already highly loaded. Also note that the
> >> time-
> >>>> outs
> >>>> values of NATs and firewalls on the path are usually unknown, therefore
> an
> >>>> application can never rely on heartbeats (no matter at which level) and
> >> must
> >>>> be
> >>>> prepared to try to reconnect on the application layer if the connection
> >>>> fails.
> >>>> Usually, the main reason for using heartbeats to maintain NAT or
> firewall
> >>>> state
> >>>> (vs. reconnect every time) in TCP is if the application is time-
> sensitive
> >> and
> >>>> a
> >>>> full TCP handshake takes too long for the desired service. I'm not sure
> >> that
> >>>> the case for DOTS, however, I understand it may be beneficial to have
> >>>> established state if an attack is on-going.
> >>>
> >>> [Med] This is important to avoid new handshakes when the client has to
> >> request a mitigation.
> >>
> >> This is okay but could be spelled out more explicitly as a requirement,
> >> rather than taking about the details of sending heartbeats.
> >>>
> >>>>
> >>>> For UDP I guess it's more complicated in your case. Time-outs are
> usually
> >>>> very
> >>>> short, however, state is created with the first packet of a flow (as
> there
> >> is
> >>>> no handshake in UDP). As you don't see blocking if state is expired as
> new
> >>>> state is created immediately, it's kind of impossible to measure the
> >>>> configured
> >>>> time-out values. Only if the firewall is under attack it would start
> >> blocking
> >>>> UDP traffic that is has no state for yet. So I understand why it is
> >> desirable
> >>>> to maintain UDP state for you, however, I don't understand how you can
> >> know
> >>>> that your frequency is high enough to actually keep the state open. Note
> >> that
> >>>> TCP time-outs are usually in the order of hours, while UDP time-outs are
> >>>> usually in range of tens of seconds, and might expire even quicker if a
> >>>> system
> >>>> is under attack. If that is a scenario that is important for you, and
> >>>> assuming
> >>>> that not all time-outs values on the path can be known, I guess it would
> >> be
> >>>> recommendable to use TCP instead.
> >>>>
> >>>> In any case this can not be a MUST requirement (as timers are usually
> not
> >>>> known). I would recommend to state something like:
> >>>>
> >>>> "MAY be frequent enough to maintain NAT or firewall state, if timer
> values
> >>>> are
> >>>> known, or if TCP is used, SHOULD use in addition TCP heartbeats  to
> >> maintain
> >>>> the TCP connection state and reconnect immediately if a failure is
> >> detected."
> >>>>
> >>>
> >>> [Med] The original wording is accurate and reflects the requirement of
> the
> >> WG. How this will be enforced is part of the solution/specification space.
> >>
> >> My hold point here is that
> >>
> >> "MUST be frequent enough to maintain any on-path NAT or Firewall bindings
> >> during mitigation.“
> >>
> >> cannot be a MUST requirement as the network time-out values are not known
> by
> >> the endpoints. Therefore it is impossible to fulfill this requirement.
> >
> > [Med] Two comments here:
> > * The requirement can be fulfilled by relying RFC8085 recommendations. This
> is discussed in the spec documents.
> 
> RFC8085 provide recommended value and limits, however, this does not
> guarantee that the proposed values actually match the time-out values as
> deployed on the path.
> 
> > * there are deployments in which timers can be discovered (e.g., PCP
> (RFC6887)).
> 
> This does not work in all cases and the draft does not seem to require the
> usage of anything like this. If a requirement is that the timeout values MUST
> be known in the deployed scenario, then that should be spelled out, however,
> I assume that is not your intention because that would limit deployment
> heavily.
> 
> Mirja
>