Subject: [Dots] Signal Channel Heartbeats

From: "Jon Shallow" <[email-masked]>
Date: Mon, 18 Dec 2017 14:59:47 -0000

Hi there,

There has been a lot of discussion on this, culminating in an update in
draft-ietf-dots-signal-channel-13 where 'config-interval' has been added in
to try to handle the different concerns.

>From my trying to simplify things perspective:-

1. NAT devices usually allow outbound session requests (source IP nat'ing)
and allow for a response to come back within a defined time frame (lots of
discussion on this time frame - eventually setting on 30 seconds as a good
compromise - but could be longer).

2. NAT devices may be configured to allow inbound session requests (port
redirection) and allow for a response to come back within a defined time
frame.  Doing this does raise security policy issues as this potentially
allows uncontrolled access from the Internet to an internal device.

3. NAT devices are likely to break any server initiated heartbeats if the
server request frequency is longer than a NAT session is maintained in the
NAT device, and inbound session requests are disabled (for security
reasons).

4. The frequency of Heartbeats ideally are different between peace time and
attack.  In peace time there could be no heartbeats or at a slow rate to
keep the signal channel alive.  In attack time, 30 seconds appears to be the
agreed compromise time, but this is also influenced by the underlying COAP
protocol  (retry intervals and counters etc.).  In attack time, the rate
should be sufficient to detect any transmission issues within a reasonable
time frame.

5. For DOTS clients, there should be no issues with heartbeats going through
NAT devices (other than during an attack where there may be packet loss) no
matter what the heartbeat frequency is.

6. For DOTS servers dropping the heartbeat rate below that of the active NAT
session time will cause issues if there is a NAT device that does not allow
inbound initiated sessions.

7. If heartbeats are in use, then both DOTS server and DOTS client have to
do their separate heartbeats for network connectively / DOTS agent
availability.

8. If heartbeats are being used, the DOTS server can optionally trigger
mitigation is heartbeats stop working

To give the ability to change the heartbeat rates, 'config-interval' has
been added to the signal draft.  A client then knows when to re-request the
configuration (e.g. for potentially changed heartbeat values).  However,
'config-interval' has to be sufficiently large to not compete with the
heartbeat rate (if they both were for the same interval, then configuration
update requests would effectively be doing the same task as heartbeats!).
But if 'config-interval' is too large (signal draft-13 example has it as 24
minutes) then it could take time for the heartbeat rate to get increased in
attack time (and if the config update response packet does not get through,
it will not get updated).  I think 'config-interval' needs to be thought
through further.

I have 2 proposals here

A. If the heartbeat frequency is below that of the NAT session inactive
timeout, the DOTS client will always transmit the heartbeats at the
appropriate frequency.  When the heartbeat request arrives at the DOTS
server, this triggers a heartbeat process on the DOTS server to then
heartbeat test the DOTS client.  Thus the DOTS server can use the "warm" NAT
session during peacetime.  If the heartbeat requests do not come in from the
DOTS client (and a peacetime heartbeat rate is configured) then
auto-mitigation can get invoked if required.

B. There are defined two heartbeat rates - one for when one or more
mitigation requests are in progress (attack situations) and a second rate
for peace time (can be 0 (no heartbeats) or some long timeout).  Whenever
the first mitigation is requested over a DOTS session, both ends start
heart-beating at the "attack" rate.   This gets rid of any potential
'config-interval' refresh delays / 'new heartbeat interval' packets getting
lost.  When there are no more mitigations active for that DOTS session, then
the DOTS session drops immediately back into the peacetime values.
'config-interval' could then be replaced with
'peace-time-heartbeat-interval'.

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 19 Dec 2017 10:01:56 +0000

Hi Jon,

Thank you for initiating this thread. This is exactly the discussion I wanted to have.

The initial requirement that motivated introducing config-interval was the following from the requirements I-D:

      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.

Also, given that configuration changes may occur at the server, clients will continue using stale configuration data retrieved previously from the server because there is no procedure to refresh the config. This is undesirable. config-interval solves this. Of course, DOTS agents may decide to disable the refresh procedure by setting it to 0 or by not returning the parameter.

Having distinct heartbeat values (peacetime/attack) is an option, but it does not address the issue of stale configuration. Note that, for example, a distinct max-retransmit may also be configured for peace time.

The following would meet all the requirements:

          +--:(configuration)

             +--rw session-id            int32

             +--rw heartbeat-interval?   int16

             +--rw missing-hb-allowed?   int16

             +--rw max-retransmit?       int16

             +--rw ack-timeout?          int16

             +--rw ack-random-factor?    decimal64

             +--rw trigger-mitigation?   Boolean

             +--rw peace-time-config

             |   +--rw heartbeat-interval?   int16

             |   +--rw missing-hb-allowed?   int16

             |   +--rw max-retransmit?       int16

             |   +--rw ack-timeout?          int16

             |   +--rw ack-random-factor?    decimal64

             +--rw config-interval?      int32

·         If no peace-time-config is provided, the same values will be used for both peace and attack times till a change occurs. This is what is currently in the draft.

·         peace-time-config may be returned to specify values to be used for peacetime. Switching between attack/peace time parameter values will be automatic.

Your point (A) makes sense to me. What about adding the following:

NEW:

   In order to avoid complications due to the presence of some stateful

   translators and firewalls (e.g., discard an incoming packet because

   no matching state is found), DOTS servers MAY trigger their heartbeat

   requests immediately after receiving heartbeat probes from peer DOTS

   clients.

I do fully agree that consistent setting of the parameters is important.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : lundi 18 décembre 2017 16:00
À : [email-masked]
Objet : [Dots] Signal Channel Heartbeats

Hi there,

There has been a lot of discussion on this, culminating in an update in draft-ietf-dots-signal-channel-13 where 'config-interval' has been added in to try to handle the different concerns.

>From my trying to simplify things perspective:-

1. NAT devices usually allow outbound session requests (source IP nat'ing) and allow for a response to come back within a defined time frame (lots of discussion on this time frame - eventually setting on 30 seconds as a good compromise - but could be longer).

2. NAT devices may be configured to allow inbound session requests (port redirection) and allow for a response to come back within a defined time frame.  Doing this does raise security policy issues as this potentially allows uncontrolled access from the Internet to an internal device.

3. NAT devices are likely to break any server initiated heartbeats if the server request frequency is longer than a NAT session is maintained in the NAT device, and inbound session requests are disabled (for security reasons).

4. The frequency of Heartbeats ideally are different between peace time and attack.  In peace time there could be no heartbeats or at a slow rate to keep the signal channel alive.  In attack time, 30 seconds appears to be the agreed compromise time, but this is also influenced by the underlying COAP protocol  (retry intervals and counters etc.).  In attack time, the rate should be sufficient to detect any transmission issues within a reasonable time frame.

5. For DOTS clients, there should be no issues with heartbeats going through NAT devices (other than during an attack where there may be packet loss) no matter what the heartbeat frequency is.

6. For DOTS servers dropping the heartbeat rate below that of the active NAT session time will cause issues if there is a NAT device that does not allow inbound initiated sessions.

7. If heartbeats are in use, then both DOTS server and DOTS client have to do their separate heartbeats for network connectively / DOTS agent availability.

8. If heartbeats are being used, the DOTS server can optionally trigger mitigation is heartbeats stop working

To give the ability to change the heartbeat rates, 'config-interval' has been added to the signal draft.  A client then knows when to re-request the configuration (e.g. for potentially changed heartbeat values).  However, 'config-interval' has to be sufficiently large to not compete with the heartbeat rate (if they both were for the same interval, then configuration update requests would effectively be doing the same task as heartbeats!).  But if 'config-interval' is too large (signal draft-13 example has it as 24 minutes) then it could take time for the heartbeat rate to get increased in attack time (and if the config update response packet does not get through, it will not get updated).  I think 'config-interval' needs to be thought through further.

I have 2 proposals here

A. If the heartbeat frequency is below that of the NAT session inactive timeout, the DOTS client will always transmit the heartbeats at the appropriate frequency.  When the heartbeat request arrives at the DOTS server, this triggers a heartbeat process on the DOTS server to then heartbeat test the DOTS client.  Thus the DOTS server can use the "warm" NAT session during peacetime.  If the heartbeat requests do not come in from the DOTS client (and a peacetime heartbeat rate is configured) then auto-mitigation can get invoked if required.

B. There are defined two heartbeat rates - one for when one or more mitigation requests are in progress (attack situations) and a second rate for peace time (can be 0 (no heartbeats) or some long timeout).  Whenever the first mitigation is requested over a DOTS session, both ends start heart-beating at the "attack" rate.   This gets rid of any potential 'config-interval' refresh delays / 'new heartbeat interval' packets getting lost.  When there are no more mitigations active for that DOTS session, then the DOTS session drops immediately back into the peacetime values.  'config-interval' could then be replaced with 'peace-time-heartbeat-interval'.

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 19 Dec 2017 10:49:09 -0000

Hi Med,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 19 December 2017 10:02
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel Heartbeats

Hi Jon, 

Thank you for initiating this thread. This is exactly the discussion I
wanted to have. 

The initial requirement that motivated introducing config-interval was the
following from the requirements I-D:

      control load.

Also, given that configuration changes may occur at the server, clients will
continue using stale configuration data retrieved previously from the server
because there is no procedure to refresh the config. This is undesirable.
config-interval solves this. Of course, DOTS agents may decide to disable
the refresh procedure by setting it to 0 or by not returning the parameter.

[Jon] I agree there may be stale signal configurations (most likely to occur
during initial set-up and tuning) and “config-interval” will handle this.
The requirements I-D refer to this only being done when ‘no mitigation
request is active’.  The peacetime/attack (with possibly) alternative
heartbeat configurations partially handle this requirement as well.

Having distinct heartbeat values (peacetime/attack) is an option, but it
does not address the issue of stale configuration. Note that, for example, a
distinct max-retransmit may also be configured for peace time. 

          +--:(configuration)
             +--rw session-id            int32

[Jon]  A minor comment – is the following more logical and more descriptive?

          +--:(configuration)
             +--rw session-id            int32
             +--rw attack-time-config
             +--rw peace-time-config?

·         If no peace-time-config is provided, the same values will be used
for both peace and attack times till a change occurs. This is what is
currently in the draft. 

·         peace-time-config may be returned to specify values to be used for
peacetime. Switching between attack/peace time parameter values will be
automatic.

[Jon] We just need to make sure the ‘automatic’ switching is defined in the
text as well as updating CBOR mappings etc.

[Jon] How do we handle in the YANG definition the fact that, say, when doing
a GET, heartbeat-interval is
“heartbeat-interval”:{“current-value”:xx,”min-value”:yy,”max-value”:zz}, but
a PUT currently is {“heartbeat-interval”:aa}.  I think actually the PUT
should be {“heartbeat-interval”:{“current-value”:aa} and the YANG definition
updated accordingly.

NEW:

[Jon] Works for me

Cheers,

Med

Hi there,

There has been a lot of discussion on this, culminating in an update in
draft-ietf-dots-signal-channel-13 where ‘config-interval’ has been added in
to try to handle the different concerns.

>From my trying to simplify things perspective:-

1. NAT devices usually allow outbound session requests (source IP nat’ing)
and allow for a response to come back within a defined time frame (lots of
discussion on this time frame – eventually setting on 30 seconds as a good
compromise – but could be longer).

To give the ability to change the heartbeat rates, ‘config-interval’ has
been added to the signal draft.  A client then knows when to re-request the
configuration (e.g. for potentially changed heartbeat values).  However,
‘config-interval’ has to be sufficiently large to not compete with the
heartbeat rate (if they both were for the same interval, then configuration
update requests would effectively be doing the same task as heartbeats!).
But if ‘config-interval’ is too large (signal draft-13 example has it as 24
minutes) then it could take time for the heartbeat rate to get increased in
attack time (and if the config update response packet does not get through,
it will not get updated).  I think ‘config-interval’ needs to be thought
through further.

I have 2 proposals here

heartbeat test the DOTS client.  Thus the DOTS server can use the “warm” NAT

B. There are defined two heartbeat rates – one for when one or more
mitigation requests are in progress (attack situations) and a second rate
for peace time (can be 0 (no heartbeats) or some long timeout).  Whenever
the first mitigation is requested over a DOTS session, both ends start
heart-beating at the “attack” rate.   This gets rid of any potential
‘config-interval’ refresh delays / ‘new heartbeat interval’ packets getting
lost.  When there are no more mitigations active for that DOTS session, then
the DOTS session drops immediately back into the peacetime values.
‘config-interval’ could then be replaced with
‘peace-time-heartbeat-interval’.

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 19 Dec 2017 11:14:05 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 19 décembre 2017 11:49
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] Signal Channel Heartbeats

Hi Med,

See inline [Jon]

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 19 December 2017 10:02
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel Heartbeats

Hi Jon,

Also, given that configuration changes may occur at the server, clients will continue using stale configuration data retrieved previously from the server because there is no procedure to refresh the config. This is undesirable. config-interval solves this. Of course, DOTS agents may decide to disable the refresh procedure by setting it to 0 or by not returning the parameter.
[Jon] I agree there may be stale signal configurations (most likely to occur during initial set-up and tuning) and "config-interval" will handle this. The requirements I-D refer to this only being done when 'no mitigation request is active'.  The peacetime/attack (with possibly) alternative heartbeat configurations partially handle this requirement as well.
[Med] Agree.

          +--:(configuration)

             +--rw session-id            int32

             +--rw ack-timeout?          int16

             +--rw peace-time-config

             +--rw config-interval?      int32
[Jon]  A minor comment - is the following more logical and more descriptive?
[Med] I considered this but favored the other one because it is more compact. For example, when the same config is to be used for both peace/attack times, you just need to omit "peace-time-config", while you need to include the same value twice for the other proposal. Do you have a strong preference?

          +--:(configuration)

             +--rw session-id            int32

             +--rw attack-time-config

             +--rw peace-time-config?

·         peace-time-config may be returned to specify values to be used for peacetime. Switching between attack/peace time parameter values will be automatic.
[Jon] We just need to make sure the 'automatic' switching is defined in the text as well as updating CBOR mappings etc.

[Jon] How do we handle in the YANG definition the fact that, say, when doing a GET, heartbeat-interval is "heartbeat-interval":{"current-value":xx,"min-value":yy,"max-value":zz}, but a PUT currently is {"heartbeat-interval":aa}.  I think actually the PUT should be {"heartbeat-interval":{"current-value":aa} and the YANG definition updated accordingly.

[Med] A config parameter in the PUT implicitly means "current value". Is there a benefit in saying it explicitly? I don't think so. No?

NEW:

   clients.

[Jon] Works for me

[Med] Great!

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : lundi 18 décembre 2017 16:00
À : [email-masked]<mailto:[email-masked]>
Objet : [Dots] Signal Channel Heartbeats

Hi there,

I have 2 proposals here

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 19 Dec 2017 11:25:31 +0000

The CoAP messages for configuration update are marked as Confirmable, and are not suitable to be exchanged during attack time. It does not sound like a good idea to modify the DOTS signal channel configuration parameters during attack time. I don't see the need for proposal (A) discussion below but agree with the proposed updated yang model with attack-time-config and peace-time-config.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 19, 2017 4:44 PM
To: Jon Shallow <[email-masked]>; [email-masked]
Subject: Re: [Dots] Signal Channel Heartbeats

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 19 décembre 2017 11:49
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] Signal Channel Heartbeats

Hi Med,

See inline [Jon]

Regards

Jon

Hi Jon,

          +--:(configuration)

             +--rw session-id            int32

             +--rw ack-timeout?          int16

             +--rw peace-time-config

          +--:(configuration)

             +--rw session-id            int32

             +--rw attack-time-config

             +--rw peace-time-config?

NEW:

   clients.

[Jon] Works for me

[Med] Great!

Cheers,
Med

Hi there,

I have 2 proposals here

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 19 Dec 2017 11:27:13 -0000

Hi Med,

See inline [Jon1]

Regards

Jon

Hi Jon, 

      control load.

[Med] Agree. 

          +--:(configuration)
             +--rw session-id            int32

[Med] I considered this but favored the other one because it is more
compact. For example, when the same config is to be used for both
peace/attack times, you just need to omit “peace-time-config”, while you
need to include the same value twice for the other proposal. Do you have a
strong preference?

[Jon1] Actually, I had sneaked in a ? after peace-time-config, making it
optional (and all the elements below).  As an implementer, I find my
suggestion more readable / understandable – but am really agnostic as to
which definition version.

          +--:(configuration)
             +--rw session-id            int32
             +--rw attack-time-config

[Med] A config parameter in the PUT implicitly means “current value”. Is
there a benefit in saying it explicitly? I don’t think so. No?

[Jon1] I agree that current-value is implicit, but if we are to strictly use
the YANG model, the GET returns information that is not YANG defined (hence
unparseable), so if the YANG definition is extended to include current-value
etc. then we need to update the PUT to be YANG compliant.

NEW:

Cheers,

Med

Hi there,

I have 2 proposals here

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 19 Dec 2017 11:31:37 -0000

Hi Tiru,

Proposal A just gives DOTS servers the capability to continue to do
heartbeats through a NAT device, there is no NAT port redirection in place
on the NAT device and any outbound NAT session has an expiry timeout that is
smaller than the repeat frequency of the heartbeats.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar
Reddy
Sent: 19 December 2017 11:26
To: [email-masked]; Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel Heartbeats

The CoAP messages for configuration update are marked as Confirmable, and
are not suitable to be exchanged during attack time. It does not sound like
a good idea to modify the DOTS signal channel configuration parameters
during attack time. I don’t see the need for proposal (A) discussion below
but agree with the proposed updated yang model with attack-time-config and
peace-time-config.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of

Re-,

Please see inline. 

Cheers,

Med

Hi Med,

See inline [Jon]

Regards

Jon

Hi Jon, 

      control load.

[Med] Agree. 

          +--:(configuration)
             +--rw session-id            int32

          +--:(configuration)
             +--rw session-id            int32
             +--rw attack-time-config

 

NEW:

Cheers,

Med

Hi there,

I have 2 proposals here

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 19 Dec 2017 11:37:49 +0000

Re-,

OK with having attack-time-config and peace-time-config.

I understand better your comment "Jon1".

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 19 décembre 2017 12:27
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] Signal Channel Heartbeats

Hi Med,

See inline [Jon1]

Regards

Jon

Hi Jon,

          +--:(configuration)

             +--rw session-id            int32

             +--rw ack-timeout?          int16

             +--rw peace-time-config

             +--rw config-interval?      int32
[Jon]  A minor comment - is the following more logical and more descriptive?
[Med] I considered this but favored the other one because it is more compact. For example, when the same config is to be used for both peace/attack times, you just need to omit "peace-time-config", while you need to include the same value twice for the other proposal. Do you have a strong preference?
[Jon1] Actually, I had sneaked in a ? after peace-time-config, making it optional (and all the elements below).  As an implementer, I find my suggestion more readable / understandable - but am really agnostic as to which definition version.

          +--:(configuration)

             +--rw session-id            int32

             +--rw attack-time-config

             +--rw peace-time-config?

[Med] A config parameter in the PUT implicitly means "current value". Is there a benefit in saying it explicitly? I don't think so. No?
[Jon1] I agree that current-value is implicit, but if we are to strictly use the YANG model, the GET returns information that is not YANG defined (hence unparseable), so if the YANG definition is extended to include current-value etc. then we need to update the PUT to be YANG compliant.

NEW:

   clients.

[Jon] Works for me

[Med] Great!

Cheers,
Med

Hi there,

I have 2 proposals here

Regards

Jon