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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Tiru,

thanks, the proposed text works well for me!

Mirja



> Am 21.02.2019 um 15:58 schrieb 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
>>> 
>