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

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

 



Title: Re: [anonsec] review comments on draft-ietf-btns-prob-and-
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]