[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SCTP and IPsec issues


Per Ted's suggestion at the WG meeting, here is the list of issues mentioned in
draft-ietf-ipsec-sctp-00.txt which the working group needs to decide on.

First, the background: SCTP endpoints can use multiple network identifiers
(addresses) that are valid for the lifetime of a connection; thus, packets in
that connection can use any of a number of source and destination addresses,
while still referring to the same connection. Contrast this to TCP, where each
host uses one address for the lifetime of the TCP connection.

So, the issues:

1) Currently, IPsec SAs are identified by the triplet

  (destination address, SPI, security protocol)

for the purposes of locating them in the SAD. Since SCTP packets can have any
of a set of destination addresses, this identification needs to be extended to
be
 ({set of destination addresses}, SPI, security protocol).

The alternative (setting up a number of SAs, for each of the valid destination
addresses) does not work because of SA state issues (at least the replay
counter has to be synchronized across all these SAs) and the obvious memory
waste.

Recommendation: the architecture document should state that SAs are identified
by the extended triplet.


2) Since an SCTP connection can use a number of source and destination
addresses, the SPD has to accomodate this. If the two hosts use N and M number
of addresses respectively, the obvious solution is to generate N*M SPD entries.

The alternative is to let SPD rules use sets of addresses as the source and
destination address selectors, which has linear cost in memory and processing
(N+M).

Recommendation: this is an implementation issue, but it's probably a good idea
to include appropriate language in the architecture document.


3) The SCTP source/destination port numbers should be included as SPD selectors.

Recommendation: include this in the architecture document. No-brainer.


4) The multiple source/destination addresses need to appear in the Phase 2
ID payloads in IKE. There are two ways of doing this:

	a) Allow multiple source/destination ID payloads in messages 1 and 2
	   of IKE Quick Mode.
	b) Introduce a new type of ID, that allows for recursive inclusion
	   of other IDs. Thus, Phase 2 would still only send one ID payload
	   each for source/destination; each of these would then contain a
	   list of the addresses for the respective endpoint.

Recommendation: do (b), as we think it is less intrusive for implementations
than (a). However, recursion is limited to only one-deep (i.e., you can't
have a recursive ID inside a recursive ID).

	Subissue:
		1) If we do (b), what types of IDs are allowed to appear in
		   the recursive ID:
			a) Any of the defined IDs (e.g., FQDNs etc.)
			b) Only address-based IDs.

		   Recommendation: Do (b). The only potential use for other
			IDs inside the recursive ID would be to support
                        multi-party authentication in Phase 1 (i.e.,
                        multiple signatures from different principals in
                        Phase 1).


5) The initiator of an IKE exchange may not know all the remote host's
addresses (used for SCTP), and thus may not be able to propose an accurate
Phase 2 destination ID. Solutions:

	a) The Responder may drop the Phase 2 exchange and start a Phase 2
	   exchange on its own (using the same Phase 1 SA), using information
	   from the old exchange, providing the correct set of addresses. The
	   advantage of this approach is that it requires no protocol changes
	   (although implementations have to be able to deal with this
	    initial rejection).
	b) The Responder could modify the Responder ID received in message 1
	   of Quick Mode, and send it back in message 2. The Initiator then
	   needs to verify that this is according to policy (as opposed to
	   doing a simple bytestring comparison, as is possible today). This
	   requires no wire changes, but a small change in the processing at
	   the Initiator. This is a potentially more powerful and lightweight
	   approach (everything is still done in one exchange, and the
	   Initiator does not have to deal with a Phase 2 exchange rejection).

Recommendation: A slight bias towards (a), but feedback from other IKE
implementors is needed.


The draft includes some more text/advice to implementors; that may eventually
turn out as a document by itself. Most of the issues mentioned in this message
require changes to the architecture and IKE documents.
-Angelos
Follow-Ups: