Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
draft-ietf-tsvwg-addip-sctp-22

Christian Vogt's review:

I was reading the protocol spec primarily with two questions in mind:
How does the protocol prevent session hijacking, and how does it protect
against 3rd-party flooding.

Session hijacking
-----------------

The Add-IP protocol is robust to session hijacking.  Hijacking is
prevented by exchanging random values and negotiating a hash algorithm
at session establishment based on which requests to add or remove an IP
address can be authenticated subsequently.  A session hijacker would
have to intercept these parameters during session establishment.  The
Add-IP protocol thereby successfully binds any IP address
additions/deletions to the initial connection setup.  Optionally, the
authentication mechanism can take advantage of shared secrets between
the peers so that sessions cannot be hijacked even if the attacker can
eavesdrop on connection establishment.

The authentication protocol is specified separately in
draft-ietf-tsvwg-sctp-auth-08.txt.

What is not mentioned in the Add-IP protocol spec, but which increases
the robustness of the protocol against connection hijacking IMO, is that
an attacker would also need to know a current sequence number.  I.e.,
the attacker would have to be on-path at connection setup AND shortly
before the attack.  (The additional robustness is small, of course,
given that a sequence number can be guessed.)

Flooding attacks
----------------

Flooding attacks are not properly protected against, however.  According
to the draft, the receiver of an Add-IP request is supposed to probe the
new IP address with a HEARTBEAT chunk, which in turn is to be echoed by
the requesting node.  Yet the HEARTBEAT chunk includes only predictable
information according to the SCTP base spec -- a timestamp and the
requesting node's IP address --, and the Add-IP spec does not overwrite
this.  Theoretically, it would be perfectly feasible to include
unpredictable information in a HEARTBEAT chunk, but this is nowhere
demanded AFAICT.

Flooding attacks are also not discussed in the security considerations.

The flooding issue in SCTP Add-IP is similar to the one Mobile IPv6
avoids with periodic care-of address tests.  But I think it's even more
significant because SCTP Add-IP allows an attacker to register multiple
IP addresses with a peer.  A flooding attacker could hence register its
own IP address in addition to the victim's IP address, and send faked
acknowledgments from a /topologically correct/ IP source address.  Since
Mobile IPv6 permits only a single care-of address per mobile node, it at
least forces a flooding attacker to spoof the victim's IP address in its
fake acknowledgments.

Similarly, SCTP Add-IP allows the attacker to use an IP source address
for the Add-IP request that is different than the IP address being
added.  The IP source address may therefore be topologically correct,
while the IP address being added could belong to a victim.  This is the
same issue that was discussed in the context of the Mobile IPv6
Alternative Care-of Address option.  But in contrast to Mobile IPv6,
SCTP Add-IP does not properly verify such an IP address, as explained above.

Suggestion:  (1) Add text that demands the use of unpredictable
information in HEARTBEAT chunks.  (2) Discuss the threat of flooding in
security associations.

Miscellaneous
-------------

I very much think that the document could be improved editorially.  I
found it difficult to read.  The following piece of text from page 25 is
quite representative, I would say:

> >              The receiver of the add IP address request may use the
> >       address as a destination immediately.  The receiver MUST use the
> >       path verification procedure for the added address before using
> >       that address.  The receiver MUST NOT send packets to the new
> >       address except for the corresponding ASCONF-ACK Chunk or HEARTBEAT
> >       Chunks for path verification before the new path is verified.

Another example is that the reader finds out only very late and in a
hidden place (in a side note in section 4.2.6) that the "adaptation
indication" specified in the document has nothing to do with mobility or
multi-homing, but was merely included to spare another SCTP document.

There are more examples of highly improvable text, but I'll leave it for
now...

  The Technical Summary in the Write-up is better than the Abstract
  in the document.  I suggest that it be used as the Abstract:
  
    A local host may have multiple points of attachment to the
    Internet, giving it a degree of fault tolerance from
    hardware failures. SCTP was developed to take full advantage
    of such a multi-homed host to provide a fast failover and
    association survivability in the face of such hardware
    failures. This document describes an extension to SCTP that
    will allow an SCTP stack to dynamically add an IP Addresses
    to an SCTP association, dynamically delete an IP addresses
    from an SCTP association, and to request to set the primary
    address the peer will use when sending to an endpoint.

  Based on Gen-ART Review by Francis Dupont:

  Section 3: s/2*32/2**32/ OR s/2*32/2^32/

  Section 4.1.1: s/message i.e./message, i.e.,/

  Section 4.2: s/Table 2, 3 and 4/Tables 2, 3, and 4/

  Section 4.2.4: s/appear in the ASCONF Chunk,/appear in the ASCONF,/

  Section 4.3: s/illegal ASCONF-ACK/illegal ASCONF-ACK./

  Section 4.3.4: s/2^^31/2**31/ OR s/2^^31/2^31/

  Section 5.1.1: s/a minimal path MTU.  The minimum PMTU/
                  /a minimal path MTU.  The minimal path MTU/

  Section 5.2: s/i.e./i.e.,/ (two places)

  Section 5.2: insert a blank line before E1, E2, and V3

  Section 5.2: s/PMTU/path MTU/

  Section 5.3: s/2^^31/2**31/ OR s/2^^31/2^31/

  Section 5.3.1: s/rule D4/rule F4/ (on page 28)

  Section 5.4: s/i.e./i.e.,/ 

  Section 5.5: s/other i.e./other, i.e.,/

  Section 5.5: s/Each new ASCONFs lookup/Each new ASCONF lookup/

  Section 6: s/modfiy/modify/