At 2:06 PM -0600 1/14/08, Nicolas Williams wrote:
...
Ipsec does support
^^^^^
You're slipping :) :)
oh my!
> per-user authentication if protocol ID and port pairs can be used to
distinguish the sessions for different users.
I thought this was feasible (see above) but I thought the RFC4301 model
didn't quite deal with this (or at least Sam once convinced me that the
name selector of the SPD didn't quite work the way I would think it
should). I am glad to be wrong on this.
(So then, the name selector in the SPD can be used to select the local
ID and credentials?)
The following text from pages 28-29 of 4301 seems pretty clear on
this point. I have marked some of the text as bold, to call attention
to especially relevant parts.
- Name: This is not a selector like the others above. It is not
acquired from a packet. A name may be used as a symbolic
identifier for an IPsec Local or Remote address. Named SPD
entries are used in two ways:
1. A named SPD entry is used by a responder (not an initiator)
in support of access control when an IP address would not be
appropriate for the Remote IP address selector, e.g., for
"road warriors". The name used to match this field is
communicated during the IKE negotiation in the ID payload.
In this context, the initiator's Source IP address (inner IP
header in tunnel mode) is bound to the Remote IP address in
the SAD entry created by the IKE negotiation. This address
overrides the Remote IP address value in the SPD, when the
SPD entry is selected in this fashion. All IPsec
implementations MUST support this use of names.
2. A named SPD entry may be used by an initiator to identify a
user for whom an IPsec SA will be created (or for whom
traffic may be bypassed). The initiator's IP source address
(from inner IP header in tunnel mode) is used to replace the
following if and when they are created:
- local address in the SPD cache entry
- local address in the outbound SAD entry
- remote address in the inbound SAD entry
Support for this use is optional for multi-user, native host
implementations and not applicable to other implementations.
Note that this name is used only locally; it is not
communicated by the key management protocol. Also, name
forms other than those used for case 1 above (responder) are
applicable in the initiator context (see below).
So, although support for this capability (for initiators) is not
strictly required for a multi-user system, we do explain how it is
intended to work in those systems.
So, if you want to
restrict the cited motivation to applications that multiplex
different users onto a single TCP/UDP session, that would be accurate.
I don't want to restrict it only to such applications, _no_.
Then you should include the sort of text you provided below, to
justify why BTNS is appropriate in these circumstances, since it is
not accurate to say that IPsec cannot provide the required support.
...
I think the examples that you object to can remain in the I-D, but it
should be clear that BTNS is not 'RECOMMENDED' (nor 'NOT RECOMMENDED')
for those -- that those examples are speculative. Provided that such
examples are feasible.
my only requirement is that the motivation text be factually accurate.
Steve
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf