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

Processing multiple phase 2 SA payloads

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Processing multiple phase 2 SA payloads

Let me preface this by stating that I have an IKE implementation 
that negotiates multiple SA payloads with different transforms in 
a single phase 2 negotiation. This seems to be allowed according
to <draft-ietf-ipsec-ike-01.txt> (although I believe the original
intent may have been for multiple SA payloads with the same 
transform such that the SAs could be cached to be used sequentially 
without re-negotiation). Even so, in building our implementation, 
I have found that either the multiple SA payload option does not 
seem to be sufficiently specified or I am missing some 
distinguishing characteristic.

The document does not specify that the SA payloads returning to the
initiator are in the same order as the SA payloads transmitted (they
are not the same payloads because they have different SPIs and may
have less underlying proposal payloads and transform payloads, but
one can think of response SA payloads being derived from initiator SA
payloads).

If the responder must send the SA payload responses back in the same
order that the SA payloads they were derived from were received, does
that mean that the negotiation must proceed all or nothing? That is,
if one out of 15 payloads is not acceptable, should no SA payload
response be sent? It seems to be the case that the initiator may not
be able to determine which one of the 15 SA payloads it sent was the
unacceptable one.

If the responders SA payloads can be in a different order then the
initiators SA payloads they were derived from, how can they be
distinguished?

The following is a contrived example to illustrate the point:

Initiator sends out:
SAi1
  proposal1/transform1 a
  proposal2/transform1 b
  proposal3/transform1 c

SAi2
  proposal1/transform1 x
  proposal2/transform1 b
  proposal3/transform1 c

SAi3
  proposal1/transform1 a
  proposal2/transform1 b
  proposal3/transform1 x

Responder replies with:
SAr1
  proposal2/transform1 b
SAr2
  proposal3/transform1 c
SAr3
  proposal1/transform1 a

So, which responder SA goes with which initiator SA?

If they are in the same order this is easy. But, what if SAr2 was 
not acceptable and did not get returned to the initiator? There is 
no way for the initiator to know if SAr1 goes with SAi1 or SAi2 
because they both contain "proposal3/transform1 c".

If they are not in the same order, I believe the initiator cannot
know which of the SA payloads the responder sent derives from which
of the SA payloads the initiator sent.

To make things even harder, the proposal and transform numbers can
change between initiator and responder - they only "SHOULD" stay
the same (RFC 2408 section 4.2).

Back to our implementation:

Our implementation currently does "first match", where the initiator
checks every returned SA payload in order against every sent one in 
the order that the payloads were sent. The first one to match is 
assumed to be the proper one and no sent payload is ever matched 
twice. This allows any order responder SA payloads but does a 
somewhat better job of matching payloads that come back with
the same ordering as the sent payloads they were derived from.

Our implementation should not send out payloads with repeated 
transforms so this algorithm is reasonable. But, I do not wish 
to write the machinery to enforce transform distinguishing rules, 
especially when no where does the specification state that all 
transforms must be either different or the same (if multiple SAs 
are to be use sequentially).

Just to throw out a possible solution:

A new attribute could be defined with the sole purpose of 
distinguishing otherwise identical transforms (this attribute must 
have a different value every time it is used).

- -Michael Heyman

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1b23

iQA/AwUBN5zZ4bXbkJfuXzRQEQIuNwCgp5kq32aG/dq3y4lN0OaH7fGxs9MAoNod
O3F9hmoJjVG8bWoskJXIMbSi
=ntHq
-----END PGP SIGNATURE-----