Subject: RE: Security Use Requirements

From: [email-masked]
Date: Sat, 10 Feb 2001 09:06:06 +0200

Bernard,

No the initiator port is different (the TCP connections are disjoint).

However this brings with it another issue. Separate connections (even
within the same session) can have different security - and this is not a
useless feature e.g., a private link with a backup public link.
In other environments you have links with similar needs.   Does  IPSec
provide a replication mechanism for security contexts?

Regards,
Julo

"Bernard Aboba" <[email-masked]> on 09/02/2001 18:32:31

Please respond to "Bernard Aboba" <[email-masked]>

To:   [email-masked], [email-masked]
cc:   [email-masked]
Subject:  RE: Security Use Requirements

>iSCSI envisions and allows multiple targets behind a single IP
>address and TCP port.  The targets are named (via WWUIs) in a
>fashion that neither IPsec nor TLS can be expected to understand

Let me make sure I understand this. You will have multiple
SCSI authentications to the same target IP address and port.
Does the initiator port vary between them or is that the
same too?

If the same initiator port is used, I think there
will be a problem. How would the conversants know which IPSEC QM SA
to use to send a particular transaction? On outbound, from
the point of view of the IPSEC driver, it sees a packet
come down with a given IP and transport header. Based on this
information, it decides which IKE QM SA the packet belongs
to, if any. So the driver has no notion of WWUIs, and needs
to make its decision purely based on the IP and transport
headers. If there isn't anything in there that is different
between the QM SAs, the driver will pick one, but it might
not be the right one.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 11 Feb 2001 08:40:31 -0800

>No the initiator port is different (the TCP connections are disjoint).

That is a good thing because it means that you can distinguish between
the IPSEC QM SAs. 

>provide a replication mechanism for security contexts?

It is possible to open multiple IKE QM SAs between the target and
the initiator. For example, you could decide that the backup public
link requires ESP 3DES while the private link can live with AH. 
As long as the connections are distinct (e.g. different initiator
port) then the target and initiator can figure out which QM SA 
corresponds to which traffic, and everything will be fine. 

It is also possible to negotiate multiple IKE MM SAs between
two nodes, although this is rarely done. This might be useful if
the initiator wants to use a different certificate for 
authentication than in a previous IKE MM SA. For example, the
set of trusted roots might need to be different, etc. 
Again, as long as IKE QM SAs derived from that MM SA are
distinguishable from other QM SAs derived from other MM SAs,
everything will work fine.