<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [anonsec] review comments on
draft-ietf-btns-prob-and-</title></head><body>
<div>At 2:06 PM -0600 1/14/08, Nicolas Williams wrote:</div>
<blockquote type="cite" cite>...<br>
> <span
></span
> <span
></span
> <span
></span>
Ipsec does support<br>
<span
></span
> <span
></span
> <span
></span>
^^^^^<br>
You're slipping :) :)</blockquote>
<div><br></div>
<div>oh my!<br>
</div>
<blockquote type="cite" cite>> per-user authentication if protocol
ID and port pairs can be used to<br>
> distinguish the sessions for different users.<br>
<br>
I thought this was feasible (see above) but I thought the RFC4301
model<br>
didn't quite deal with this (or at least Sam once convinced me that
the<br>
name selector of the SPD didn't quite work the way I would think
it<br>
should). I am glad to be wrong on this.<br>
<br>
(So then, the name selector in the SPD can be used to select the
local</blockquote>
<blockquote type="cite" cite>ID and credentials?)</blockquote>
<div><br></div>
<div>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.</div>
<div><br></div>
<div><font face="Courier" size="+2"
color="#000000"> - Name: This is
not a selector like the others above. It is not<br>
acquired from a packet.
A name may be used as a symbolic<br>
identifier for an IPsec
Local or Remote address. Named SPD<br>
entries are used in two
ways:</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
<div><font face="Courier" size="+2"
color="#000000"> 1.<b>
A named SPD entry is used by a responder (not an initiator)<br>
in
support of access control when an IP address would not be<br>
appropriate for the Remote IP address selector, e.g.,
for</b></font></div>
<div><font face="Courier" size="+2"
color="#000000"><b
>
"road warriors". The name used to match this field
is</b></font></div>
<div><font face="Courier" size="+2"
color="#000000"><b
>
communicated during the IKE negotiation in the ID payload.</b><br>
In
this context, the initiator's Source IP address (inner IP<br>
header in tunnel mode) is bound to the Remote IP address in<br>
the
SAD entry created by the IKE negotiation. This address<br>
overrides the Remote IP address value in the SPD, when the<br>
SPD
entry is selected in this fashion. All IPsec<br>
implementations MUST support this use of names.</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
<div><font face="Courier" size="+2"
color="#000000"> 2.<b>
A named SPD entry may be used by an initiator to identify
a</b></font></div>
<div><font face="Courier" size="+2"
color="#000000"><b
>
user for whom an IPsec SA will be created</b> (or for whom<br>
traffic may be bypassed). The initiator's IP source address<br>
(from inner IP header in tunnel mode) is used to replace
the</font></div>
<div><font face="Courier" size="+2"
color="#000000"
>
following if and when they are created:<br>
<br>
<span
></span> - local
address in the SPD cache entry<br>
<span
></span> - local
address in the outbound SAD entry<br>
<span
></span> - remote
address in the inbound SAD entry</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
<div><font face="Courier" size="+2"
color="#000000"
> <b>
Support for this use is optional for multi-user, native host<br>
implementations and not applicable to other
implementations.</b></font></div>
<div><font face="Courier" size="+2"
color="#000000"><b
>
Note that this name is used only locally</b>; it is not<br>
communicated by the key management protocol. Also, name<br>
forms other than those used for case 1 above (responder) are<br>
applicable in the initiator context (see below).</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
<div><br></div>
<div>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.</div>
<blockquote type="cite" cite><br>
> <span
></span
> <span
></span
> <span
></span
> <span
></span> So, if you want to<br>
> restrict the cited motivation to applications that multiplex<br>
> different users onto a single TCP/UDP session, that would be
accurate.<br>
</blockquote>
<blockquote type="cite" cite>I don't want to restrict it only to such
applications, _no_.</blockquote>
<div><br></div>
<div>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.</div>
<div><br></div>
<blockquote type="cite" cite>...</blockquote>
<blockquote type="cite" cite><br>
I think the examples that you object to can remain in the I-D, but
it<br>
should be clear that BTNS is not 'RECOMMENDED' (nor 'NOT
RECOMMENDED')<br>
for those -- that those examples are speculative. Provided that
such</blockquote>
<blockquote type="cite" cite>examples are feasible.</blockquote>
<div><br></div>
<div>my only requirement is that the motivation text be factually
accurate.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>