Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt

[Stephen Kent <[e-mail]>]

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

_______________________________________________