[SCTP]: Follow Add-IP security consideratiosn wrt INIT/INIT-ACK
The Security Considerations section of RFC 5061 has the following
text:
If an SCTP endpoint that supports this extension receives an INIT
that indicates that the peer supports the ASCONF extension but does
NOT support the [RFC4895] extension, the receiver of such an INIT
MUST send an ABORT in response. Note that an implementation is
allowed to silently discard such an INIT as an option as well, but
under NO circumstance is an implementation allowed to proceed with
the association setup by sending an INIT-ACK in response.
An implementation that receives an INIT-ACK that indicates that the
peer does not support the [RFC4895] extension MUST NOT send the
COOKIE-ECHO to establish the association. Instead, the
implementation MUST discard the INIT-ACK and report to the upper-
layer user that an association cannot be established destroying the
Transmission Control Block (TCB).
Follow the recomendations.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 46f5418..dd98763 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -1836,6 +1836,39 @@
return 0;
}
+static int sctp_verify_ext_param(union sctp_params param)
+{
+ __u16 num_ext = ntohs(param.p->length) - sizeof(sctp_paramhdr_t);
+ int have_auth = 0;
+ int have_asconf = 0;
+ int i;
+
+ for (i = 0; i < num_ext; i++) {
+ switch (param.ext->chunks[i]) {
+ case SCTP_CID_AUTH:
+ have_auth = 1;
+ break;
+ case SCTP_CID_ASCONF:
+ case SCTP_CID_ASCONF_ACK:
+ have_asconf = 1;
+ break;
+ }
+ }
+
+ /* ADD-IP Security: The draft requires us to ABORT or ignore the
+ * INIT/INIT-ACK if ADD-IP is listed, but AUTH is not. Do this
+ * only if ADD-IP is turned on and we are not backward-compatible
+ * mode.
+ */
+ if (sctp_addip_noauth)
+ return 1;
+
+ if (sctp_addip_enable && !have_auth && have_asconf)
+ return 0;
+
+ return 1;
+}
+
static void sctp_process_ext_param(struct sctp_association *asoc,
union sctp_params param)
{
@@ -1966,7 +1999,11 @@
case SCTP_PARAM_UNRECOGNIZED_PARAMETERS:
case SCTP_PARAM_ECN_CAPABLE:
case SCTP_PARAM_ADAPTATION_LAYER_IND:
+ break;
+
case SCTP_PARAM_SUPPORTED_EXT:
+ if (!sctp_verify_ext_param(param))
+ return SCTP_IERROR_ABORT;
break;
case SCTP_PARAM_SET_PRIMARY:
@@ -2139,10 +2176,11 @@
!asoc->peer.peer_hmacs))
asoc->peer.auth_capable = 0;
-
- /* If the peer claims support for ADD-IP without support
- * for AUTH, disable support for ADD-IP.
- * Do this only if backward compatible mode is turned off.
+ /* In a non-backward compatible mode, if the peer claims
+ * support for ADD-IP but not AUTH, the ADD-IP spec states
+ * that we MUST ABORT the association. Section 6. The section
+ * also give us an option to silently ignore the packet, which
+ * is what we'll do here.
*/
if (!sctp_addip_noauth &&
(asoc->peer.asconf_capable && !asoc->peer.auth_capable)) {
@@ -2150,6 +2188,7 @@
SCTP_PARAM_DEL_IP |
SCTP_PARAM_SET_PRIMARY);
asoc->peer.asconf_capable = 0;
+ goto clean_up;
}
/* Walk list of transports, removing transports in the UNKNOWN state. */