Re: [secdir] Secdir review: draft-ietf-tsvwg-sctp-failover-14

Karen Elisabeth Egede Nielsen <> Wed, 06 January 2016 08:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 260421ACD45 for <>; Wed, 6 Jan 2016 00:31:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OtCUWrH3XyjX for <>; Wed, 6 Jan 2016 00:31:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 019A21ACCEC for <>; Wed, 6 Jan 2016 00:31:02 -0800 (PST)
Received: by with SMTP id ik10so27869759igb.1 for <>; Wed, 06 Jan 2016 00:31:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type:content-transfer-encoding; bh=ghaVLOM4qseeuAytHfJVO/qm3cP/H8kAmkakq6mcmPA=; b=acNNCR7c1dkM9eWr/GyvLTAsgnNkd0cnHyLqPdXSL56PZUEl1wnBFUoNfyEdm4h1kM 5BsuAr8guqzaCzuGuyPbuaJjNw2lfJGpQdGTACcKtdMFkqwomF7eyyKmu0eAmUFniQIt 7Vi1JUNm+WgInQQby2cQ6o/OYvInzVsjbvYWk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type :content-transfer-encoding; bh=ghaVLOM4qseeuAytHfJVO/qm3cP/H8kAmkakq6mcmPA=; b=g0icQbSPv+SszQF9tGN6jAg3bl+684VaTnC60UTCsIaa0xBEBNFbhsCJN4ayL5kDZx iHSOAT5Dxv5XbJJ9FLeJgCJE7dj/tQQWTnPMzo5xyBnxowB66bmAUsMVfWc2VG7IaJ/v alVBdnJRAQjH3wLqyn2in1rHpYcYXmNh8ru8sydji9EVovo5d1Br/6qeHe9AGulKRRg5 yT8tJSvQyWk4s70Y2yWnlIPbh6O7Jj9Bv9p+x4A4QCLXMpUqyj3sfFyA7xdTiNN8nj3c kKOi9BydeQxa9j9rh4b060AB7qh5p3xWx5SKBx9N+G8mTZTze4LVMzwonL7UybHX2mUy zqDA==
X-Gm-Message-State: ALoCoQlEw2bLxR8mIMTnqLvE9tG+uNLAIua2o8qjXtNsLmgTa/DSjluNNBes/AdXNKVhqrM60gOMVB0tg4iBwtbOY3vBlMq+yvLE/OzacCA8Xqt4N3ekyX0l2GHcQj54sGdHWtc1Zjm4FAk5rHCxNCV9w1gMLVIPsg==
X-Received: by with SMTP id nq6mr7992984igb.96.1452069061676; Wed, 06 Jan 2016 00:31:01 -0800 (PST)
From: Karen Elisabeth Egede Nielsen <>
References: <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQIPY17I5aUwGrMMl8p8hgIOJvXwg55x7j4A
Date: Wed, 6 Jan 2016 09:31:00 +0100
Message-ID: <>
To: Robert Sparks <>,,,
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Approved-At: Wed, 06 Jan 2016 04:10:26 -0800
Subject: Re: [secdir] Secdir review: draft-ietf-tsvwg-sctp-failover-14
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jan 2016 08:31:05 -0000

Hi Robert,

Thanks a lot for your comments.
Please find feedback inline below.

BR, Karen

> -----Original Message-----
> From: Robert Sparks []
> Sent: 18. december 2015 21:11
> To:;;
> Subject: Secdir review: draft-ietf-tsvwg-sctp-failover-14
> I have reviewed this document as part of the security directorate's
> ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
> Summary: Ready for publication as Proposed Standard but with nits that
> should be considered
> This document defines a set of new SCTP sender behaviors that lead to
> quicker failover. The behaviors have an obvious security consideration (it
> is
> much easier for an attacker trigger failover, and potentially steer
> traffic to the
> most favorable of the available paths for the attacker's purposes). The
> document makes this very clear, and has a reasonable discussion in the
> Security Considerations section.
> The shepherd writeup notes that what is here is widely (if partially in
> some
> cases) implemented and deployed.
> There are a few places I suggest would benefit from more attention:
> There are several places in the text that allow (MAY) the sender to choose
> not to behave in the manner this document is trying to standardize. See
> item
> B in section 3.2, and item C in section 4 for example. These seem out of
> place
> - if something is doing those things, you might as well say they're
> implementing some other unstandardized extension for failover. Why do
> you need to include these statements?

[Karen Elisabeth Egede Nielsen] The motivation for including the statements
is to motivate the SHOULD statements (and to qualify the usage of SHOULD
opposed to MUST).
We have understood that such clarification was desirable (?).

However for clarity in the specification we would be
very happy to follow your guidance and remove the MAY paragraphs in section
3.2 and in section 4.
We would however not like to use MUSTs.

Would this action address your concerns ?

> They don't standardize whatever private "because I know better" behavior
> the endpoints they are discussing are engaging in. Consider deleting them,
> or
> restructuring the text to make this look less like protocol definition.
> (It's
> particularly odd that B in 3.2 uses MAY, but A does not use SHOULD).
[Karen Elisabeth Egede Nielsen] The reason A does not use a SHOULD is
because the RFC4960 text does not use a capital SHOULD. But perhaps we could
a capital SHOULD in SCTP-PF even if we are referring to text that uses a
non-capital should in RC4960 ?

> The third paragraph of section 4 has a "does not compromise the fault
> tolerance" condition, leaving what would be considered a compromise very
> vague. Again, an endpoint choosing a different dormant state operation
> than
> the one you're standardizing here isn't behaving in a standard way.
> Why do you need this paragraph? If you're going to keep it, consider
> pointing
> to or providing more discussion on what you mean by the condition.
> There are many unusual phrases used in the text. These are harder to read
> than they need to be, and will be even harder to translate. Please
> consider
> an editorial pass _before_ this is in the RFC Editor's hands.
> Search for "compromisation", "at exceed of which", "failover to deploy",
> and
> "unequivocally information" to get a feel for what I'm pointing to.
[Karen Elisabeth Egede Nielsen]

#1: Compromisation/compromise:

We could use “lower/lowering off/decrease” to be more precise.

Would you think this would resolve your concern ?

#2: Exceed of which:

The PFMR defines
        the new intermediate PF threshold on the destination address
        error counter at exceed of which the destination address is
        classified as PF.

We can reformulate to:

The PFMR defines
        the new intermediate PF threshold on the destination address
        error counter. When this threshold is exceeded, the destination
address is
        classified as PF.

Would you think this would resolve your concern ?

#3: Failover to deploy:

i  When there is outbound data to send and the destination
           address presently used for data transmission is in PF state,
           the sender SHOULD choose a destination address in active
           state, if one exists, and failover to deploy this destination
           address for data transmission.

We can reformulate:

i  When there is outbound data to send and the destination
           address presently used for data transmission is in PF state,
           the sender SHOULD choose a destination address in active
           state, if one exists and deploy this destination
           address for data transmission.

Would you think this would resolve your concern ?

#4: unequivocally information:

This would go away if we removed the MAY statement as suggested above.