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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Thursday, February 21, 2019 8:10 PM
> To: Mirja Kuehlewind (IETF) <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; The IESG
> <[e-mail]>; [e-mail]
> Subject: RE: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-
> 18: (with DISCUSS and COMMENT)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> 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.

Agreed, I propose the following update to capture the discussion and addresses the comment:

Channel Health Monitoring: DOTS agents MUST support exchange of heartbeat messages over the signal channel to monitor channel health. These keepalives serve the purpose to maintain any on-path NAT or Firewall bindings to avoid cryptographic handshake for new mitigation requests. The heartbeat interval during active mitigation could be negotiable based on NAT/Firewall characteristics. Absent information about the NAT/Firewall characteristics, DOTS agent needs to ensure its on-path NAT or Firewall bindings do not expire, by using the keep-alive frequency discussed in Section 3.5 of [RFC8085].

Cheers
-Tiru

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