Subject: [tsvwg] Review of draft-ietf-tsvwg-sctp-failover-10.txt

From: Michael Tuexen <[email-masked]>
Date: Sat, 21 Mar 2015 10:56:02 -0500

Dear all,

I gave the new revision
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-10
a fresh read and have some comments:

* Abstract
  In addition, the document complements -> In addition, this document complements

* Abstract
  introducing alternative switchover operation modes
  Why plural? Isn't only on mode introduced?

* Section 1
  Until detecting the failover -> Until detecting the failure

* Section 3
  Isn't there also the issue that it takes longer to detect the failure
  of an idle path than to detect the failure of a non-idle path? At
  least this is addressed by point 5 of Section 4.2

* Section 4.2, Point 6
  The source address of the HEARTBEAT_ACK is not important, it is
  the destination address of the packet containing the corresponding
  HEARTBEAT chunk which triggered the sending of the packet containing
  the HEARTBEAT_ACK chunk.

* Section 4.2, Point 6
  on the destination address -> to the destination address

* Section 4.2, Point 7
  Point 5 requires an endpoint to send HEARTBEATs to destintation
  addresses in potentially failed state ignoring the configuration
  by the upper layer. However when the destination address reaches
  the inactive state, the configuration by the upper layer is honored.
  I think this is inconsistent.

* Section 4.2, Point 8
  Why is the handling of the congestion window mentioned? Congestion
  control is not covered (anymore) by this document.
  I don't understand the MUST NOT / MAY combination... Does this make sense?

* Section 4.2.1
  I think
  The above prescriptions for SCTP-PF dormant state handling SHOULD NOT
  be coupled to the value of the PFMR, but solely to the activation of
  SCTP-PF logic in an SCTP implementation.  It is further noted that
  also a standard [RFC4960] SCTP implementation can use this mode of
  operation to improve the fault tolerance (which some implementations
  already do).
  really says that the dormant state is independent of the potentially
  failed state handling. So why not make it a separate feature, move
  the text in its own section and require it when you use the potentially
  failed state.
  I know I brought it up earlier and will not insist on it, but the
  text even evolved in this direction. I just think moving the description
  in its own section improves the document structure.

* Section 6
  The statement
  The logic described here is for sender-side only enabled by configuration
  and does not have any impacts on protocol messages on the wire.
  is not true. It is correct that you don't impact the message formats on
  the wire, but you do change the timing of messages on the wire.
  However, you always follow the congestion control/flow control.

* Section 6
  Why do you state
  No new chunk type or new field parameter is not required in this document.
  This might belong to the IANA Considerations, but I don't get the point
  related to security here.

* Section 6
  There is one issue not being discussed. When using potentially failed,
  SCTP moves traffic away from a path faster than SCTP not using potentially
  failed. So if an attacker sends traffic on a path be can force SCTP
  to a different path with less effort. If you use Permanent Failover,
  the result is permanently. Shouldn't this be discussed?

Best regards
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Sun, 22 Mar 2015 12:49:08 +0100

Hi Michael,

Thank you very much for the valuable comments.
Please find feedback inline below.

BR, Karen

>-----Original Message-----
>From: tsvwg [mailto:[email-masked]] On Behalf Of Michael Tuexen
>Sent: Saturday, March 21, 2015 4:56 PM
>To: tsvwg
>Subject: [tsvwg] Review of draft-ietf-tsvwg-sctp-failover-10.txt
>
>Dear all,
>
>I gave the new revision
[Karen ] Ok - if you say so :-). English grammar issue.

>  Why plural? Isn't only on mode introduced?
[Karen ] I am ok with writing one mode.  technically speaking though, then
I consider the
mode where one permanently fail away once the primary path is PFF and the
mode where one may go back
if it comes up active with  a certain time as two different modes. That
was the motivation.
>  Until detecting the failover -> Until detecting the failure
[Karen ] Thanks. ok.

>  least this is addressed by point 5 of Section 4.2
[Karen ] Good point. We can add text of this.

>  HEARTBEAT chunk which triggered the sending of the packet containing
[Karen ] ok. I assume this goes to the text:
"When the sender receives a HEARTBEAT ACK from a destination
        address in PF state"

 good point. We can reformulate:

"When the sender receives a HEARTBEAT ACK for an outstanding  HEARTBEAT
send to a destination
        address in PF state"
Would that address your point ?

>  on the destination address -> to the destination address
[Karen ] yes. thanks.

>  I think this is inconsistent.
[Karen ] I am not sure why this is inconsistent. The HBs off 5. are part
of the SCTP-PF function, enabling fast refresh
of paths that have potential problems.  The HBs of 7. are part of RFC4960
Path Heart Beat function for INACTIVE paths.

I believe this two-step approach of SCTP-PF is as intended.

I think one can discuss as to whether the HB transmittal in PF state
should be coupled to the configuration of the UL for Path Heartbeats.
We   have had this discussion and the text reflects the conclusion as I
understood it, but we can revisit this discussion and the conclusion ?

>  control is not covered (anymore) by this document.
[Karen ] _Changes_ to the congestion control handling is not covered by
this document anymore.

>  I don't understand the MUST NOT / MAY combination... Does this make
[Karen ] We could remove the discussion on
potential different approaches for now.

Alternatively - for the error counting - we amend the MUST NOT to a SHOULD
NOT as long as no mechanisms to
provided unequivocally information is implemented.

On the congestion control:
The intention is not to change RFC4960 congestion control handling in this
document.
The intention off the text was only to describe the situation as it is and
state that this is the situation also for SCTP-PF.
 But perhaps we better leave it out ?
RFC4960 is not clear on the congestion window growth - would you say that
the SHOULD described in 8. is what RCC4960 prescribes for ?

>  the text in its own section and require it when you use the potentially
[Karen ] I agree that it is also relevant for non SCTP-PF but as explained
in the text it is particularly relevant for
 SCTP-PF.

You say "When you use the potentially failed state" do you by this
sentence mean anything different from:
When SCTP-PF logic is active (and _may_ be configured with PFMR < PMR)
this is required"

>  in its own section improves the document structure.
[Karen ] If it improves the document structure and the readability, I am
perfectly ok with moving it
to  a separate section. The motivation indeed should be that it has its
own right. As long as it is clear that
this is required for an SCTP-PF implementation.

Moving is to a separate section, however, brings up the "update RFC4960"
issue. Or how do you see this ??

>  However, you always follow the congestion control/flow control.
[Karen ] ok. We can edit the text. I do not see any security issues in the
timing issue, hmm... except possibly
if you refer to the issue that you bring up below - ?
>  related to security here.
[Karen ] I think that you're right. We need to remove this.
>  the result is permanently. Shouldn't this be discussed?
[Karen ] Good point. You mean an attacker that inflicts congestion on a
path thereby making SCTP move away from the path
and now  with PF he need not push congestion as long as he did before.
Correct ?

On the other hand SCTP will not be so vulnerable towards "a path
congestion attack" from a throughput perspective.

I agree with describing this issue.
Also the particular issue when using Permanent Failover.

My take is that this is an issue to describe, but not an issue that
disqualifies the feature.
Do you agree ?

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 25 Mar 2015 00:26:21 -0700

Hi Michael,

Thanks for the review. Since Karen covered most of my comments, I just
would like to clarify one point...

>   the result is permanently. Shouldn't this be discussed?

Hmm. But, when Permanent failover is disabled, the attackers still need to
keep dropping heartbeats.
I guess they will need to do mostly the same efforts unless they are
interested in just a few data chunks.

Thanks,
--
Yoshi

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 25 Mar 2015 17:05:06 -0500

> On 25 Mar 2015, at 02:26, Yoshifumi Nishida <[email-masked]> wrote:
> 
> Hi Michael,
> 
> Thanks for the review. Since Karen covered most of my comments, I just would like to clarify one point...
> 
> On Sat, Mar 21, 2015 at 8:56 AM, Michael Tuexen <[email-masked]> wrote:
> 
> 
> * Section 6
> Hmm. But, when Permanent failover is disabled, the attackers still need to keep dropping heartbeats. 
> I guess they will need to do mostly the same efforts unless they are interested in just a few data chunks.
My point was:
If you use permanent failover, an attacker can get you change the path with an effort not lasting very long.
If you don't use permanent failover, it might require an continuous  effort.

I guess it might be worth documenting.

Best regards
Michael

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 26 Mar 2015 00:34:55 -0700

> I guess it might be worth documenting.

OK. I just wanted to check if there are more threats than I thought.
Thanks for the clarification. I think it's worth documenting.
--
Yoshi