Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
RFC 5061
Yes
No Objection
No Record
Note: This ballot was opened for revision 22 and is now closed.
Lars Eggert (was Discuss, Yes) Yes
(Magnus Westerlund; former steering group member) Yes
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Ward; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
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...
(Lisa Dusseault; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
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/
(Sam Hartman; former steering group member) No Objection
(Tim Polk; former steering group member) (was No Record, Discuss, No Objection) No Objection
(Jon Peterson; former steering group member) No Record
Please expand the first use of ASCONF.