Comments on draft-ietf-sip-connect-reuse-08.
Overall:
The mechanism defined in this I-D is sensible and useful. The writing
could be improved significantly.
Major technical:
Section 10, "Support for Virtual Servers" explains the necessity of
certain elements of the connection-reuse mechanism. But as far as I
can tell, this explanation is incorrect (although the problem is
real).
It's a bit hard to follow the flow that is described in this section,
it seems to involve five SIP agents, only one of which has a name
("P1") and one a description ("Alice's proxy"), leaving three unnamed.
But it looks like the first step is when a proxy P1 (that is
responsible for two domains) establishes a connection to Alice's
proxy, and Alice's proxy "establishes an alias" for it, that is,
decides that the connection is usable for requests in the reverse
direction.
The second step is when a request originating from a different one of
P1's domains passes through P1 and then to Alice's proxy, causing
Alice's proxy to establish an alias for the second connection, of
course, as an alias for the same address, that of P1.
This is then supposed to lead to the inability of P1 to correctly
route requests that arrive on the connection. This seems to involve a
binding between the connection and the ultimate destination of the
request. But that is not possible, because as a proxy, P1 must take
into account the domain-part of the request URIs of the requests.
This seems to be related to this sentence, which is meaningless on the
face of it: "But that entry is now aliased to a connection with
[EMAIL PROTECTED]" Of course, a connection is with a host, not
with a SIP URI. (Might this be a residuum of an older path-oriented
connection reuse concept?)
However, the virtual server problem is quite real. The fundamental
problem is that making a TLS connection to a destination involves two
distinct steps -- first, using RFC 3263 to find the address of the
destination, then second, using TLS to establish *and authenticate* a
connection. Only if both steps succeed is the connection available
for sending the message. As such, the "alias table" must cache not
only which connections go to which destination addresses, but which
connections have authenticated themselves as responsible for which SIP
domains. If a message is to a *new* SIP domain that resolves to an
address with a cached connection, the cached connection cannot be
used, because the connection is not authenticated for the new domain.
(Which suggests that a proxy serving multiple domains should be able
to present during TLS authentication certificate(s) that include all
the domains that it is responsible for, so that the connection can be
used for requests to all of those domains.)
Editorial:
Overall
Excessive text is spent on the cases of TCP and SCTP without TLS. As
far as I can see, they are to be handled exactly as previously. It is
useful to explain why this must be so, and section 9.3 does so, but I
don't see the need for the page-long section 5.2 and 5.3.
The description focuses on the "alias table", making that particular
implementation quasi-standard. But I don't see the mechanism as being
complex enough to require describing that specific implementation in
order to make the mechanism clear.
A few definitions are given, but various terms that are used with new
meanings are not defined. E.g., "establish an alias" meaning "the
destination of a connection deciding that the connection can be used
in the reverse direction, that is, for sending requests".
Examples tend to discuss multiple user agents and proxies, when the
entirety of the mechanism can be described by considering only the two
SIP agents at the ends of the connection. I think the intention is to
make the examples more realistic, but instead the examples get more
complex and hard to follow -- especially because the discussions often
aren't meticulous about specifying which agent sends which message to
which agent. (Not to mention that the discussion suggests that user
agents and proxies might participate in this mechanism in different
ways, whereas connection-reuse treats user agents and proxies
identically.)
The use of "alias descriptor" is unfortunate. To start with, it is
confusing -- initially I mistook it for some sort of identification of
the row of the alias table. But the concept of "descriptor" as being
a small integer identifying a network connection, as well as the very
term "descriptor", are Unix-specific. Much better would be to use a
neutral term like "internal connection identifier" and to represent
the value by something like "XXXX".
There is an overall conflating of two concepts as "connection reuse".
One is using one connection to send more than one request from one
sender to one recipient. The second is using one connection to send
requests in both directions. The first concept is already supported
by RFC 3261; the second is what is being enabled by this I-D. But the
I-D implements both actions using one alias table, obfuscating the
distinction and so obfuscating the changes that the I-D is
introducing.
Details
Section 5
- "P1 and P2 are proxies responsible for routing SIP requests through
user agents that use them as edge proxies (see Figure 4)."
Should that be "routing SIP requests *to* user agents"?
Section 5.1
- "Upon connection authentication and acceptance, P1 adds P2s to its
alias table."
"P2s" should be "P2".
- The text uses the phrase "items of interest in the alias table" when
it means "description of the values in the alias table".
- In both enumerated lists, the texts starting "At some later time"
should be separated into an independent paragraph, outside of the
enumerated lists, because they concern a different topic than the data
in the alias table.
- "When the server, P2, receives the request, it examines the topmost
Via to determine whether P1 supports aliased connections. ... The
presence of the "alias" parameter indicates that P1 does support
aliasing."
This should be rephrased, since the presence of "alias" means that the
initiating SIP agent is willing to use *this* connection in the
reverse direction: "When the server, P2, receives the request, it
examines the topmost Via to determine whether P1 is willing to use
this connection for an aliased connection. ... The presence of the
"alias" parameter indicates that P1 supports aliasing on this
connection."
Section 8.1
- "The implications of placing an "alias" parameter in the topmost Via
header of a request must be understood by the client. Specifically,
this means that the client MUST keep the connection open for as long
as the resources on the host operating system allow it to, and that it
MUST accept requests over this connection -- in addition to the
default listening port -- from its downstream peer."
It would seem obvious that the implications of inserting "alias" must
be understood by the client that does so. A better wording would be:
"If the client places an "alias" parameter in the topmost Via header
of a request, the client MUST keep the connection open for as long as
the resources on the host operating system allow it to, and that it
MUST accept requests over this connection -- in addition to the
default listening port -- from its downstream peer."
- "Whether or not to honor an aliased connection ultimately depends on
the policies of the server. It MAY choose to honor it, and thereby
send subsequent requests over the aliased connection."
This wording suggests that somehow the connection "is aliased" whether
or not the server even understands connection-reuse. It would be less
awkward to say: "Whether or not to use in the reverse direction a
connection marked with "alias" ultimately depends on the policies of
the server."
Section 9.3
- "This manner of opening connections, while still not secure, is at
least much more apparent and direct than using the connection reuse
mechanism over TCP or SCTP in an unauthenticated fashion."
What is the technical definition of "apparent and direct"? I would
suggest "... is at least more secure than ...".
Dale
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
