Hadriel Kaplan wrote:
[note: I have not read Dale's comments yet, so there may be repeats
(I started drafting this before getting his email)]
Hadriel: Thanks for your in-depth WGLC review and feedback.
More inline.
Technical: Sec 5.2: I am really confused why this section exists. The
whole doc keeps repeating how TCP or SCTP alone (sans TLS) is not an
appropriate connection for connection reuse, and indeed this section
ultimately means the same. So why is all the mechanics of this
section in the doc? Is there something different about TCP
connection handling in this than previously? Why is it even added to
the alias table, when its entry cannot be used for aliasing? This
is quite confusing. I recommend removing it.
S5.2 cautions against reusing TCP connections in the same manner
as TLS (i.e., a single connection used to send requests in
both directions.) The reason this was added was to warn implementors
not to do so (for reasons in S9.3) When I inherited connect-reuse
(-04), it talked mostly about TLS connection reuse and did not
mention TCP connection reuse at all. Thus, I added some discussion
on TCP and SCTP connection reuse into the draft.
Based on the same feedback by Dale as well, I will wordsmith S5.2
to point to rfc3261.
Section 5.1, p.7: "P1 determines through RFC3263 server resolution
process that the request should be sent to P2 on port 5061 using
TLS..." and same thing on page 8 for P2. Now I'm no expert, but last
time I checked I thought SRV's allowed defining the port number, so
one did NOT need to use the well-known 5061 for TLS, but could use
anything. So why is this restricting alias use to 5061 only?
You are absolutely right. In that example I just assumed that the
DNS SRV for P2 pointed to the default port, 5061. The example
is not implying that DNS SRV only yielded P2's IP address and
that P1 used the default port (5061) for TLS. I will make that
a bit more clear maybe using the non-defaulted TLS port number.
Sec 9.3, p.15: the argument used here against TCP or SCTP
connect-reuse (sans TLS) is one of malware hijacking on a multi-user
computer. I don't find that argument convincing, because I think
it's a red herring. If you have a malware program running on a proxy
responsible for a domain, you are in a world of hurt regardless.
(You're rearranging the deck chairs on the Titanic)
True; although when we (i.e., the co-authors) had initially fleshed
out the session hijacking scenario, we were thinking more about a user
agent and not a proxy per se (note the alias parameter can be used
between any neighboring user agents, i.e., UAC->Proxy, Proxy->Proxy,
Proxy->UAS, and UAC->UAS.) I can drill down and talk about the
perils of a UAC->Proxy TCP connection reuse (i.e., connection
hijacking) and then talk about the perils of an un-authenticated
Proxy->Proxy TCP connection reuse as you outline below ...
What *is* convincing is that without the certificate proof of
identity inherent in TLS, the mechanism as defined in this draft
would let a completely different machine, from a different IP,
pretend to represent a legit domain's proxy by simply putting in the
Via and alias param. That would be bad. And due to SCTP
multi-homing coming from any IP, and load-balancing techniques and
such, just restricting the source IP to avoid that problem won't work
universally. *That* should be the text in the draft for why TLS is
required, vs. the "malware" excuse. I am only mentioning this
because not allowing TCP or SCTP alone is a major detractor for this
draft, so the explanations for why not need to be strong.
... would that be an acceptable compromise?
Sec 8.1, p.11: Regarding TCP/SCTP connections, it says "Subsequent
requests that resolve to the same IP address, port, and transport
tuple MUST reuse the same connection." Since when is that mandatory,
and why? There is no connection reuse for TCP/SCTP. If I want to
open two TCP connections to a server, for example due to head-of-line
blocking or failure of previous, why can't I? In fact, if I want to
open two separate TLS connection why can't I? This should at least
only be a SHOULD strength.
OK; good point. I will downgrade the strength to a SHOULD.
Sec 8.1, p.11: Further, next sentence says "It MUST only accept
responses over this connection and MUST NOT accept any requests over
this connection." Why is that? The far-end chose to send a request
over an open connection. It's definitely not clear that the far-end
should have done so (nor how it would have resolved to do so), but is
there anything wrong from a protocol perspective with the local end
accepting it? For example if the far-end is manually configured to
do so.
The tact the draft takes is not to accept requests from the far
end unless the far end has been authenticated through TLS. So I
would find it rather disconcerting if the draft allowed an entity
to accept a request over an unauthenticated connection.
Sec 5.1, p.8 says: "The presence of the "alias" parameter indicates
that P1 does support aliasing. P2 now authenticates the connection
(see Section 9.2) and if the authentication was successful, P2
creates an alias to P1 using the advertised address in the topmost
Via." This implies a server-side authentication occurs for the
initial TLS connection, the request is sent from P1 to P2, P2 sees
the alias, and then P2 does a TLS renegotiation to get the client
side's cert? I think it's important to spell this out in the draft,
because I'm not sure everyone supports this after the initial TLS
handshake is over (I think most mutual-TLS happens at the beginning
in the real world, but I could easily be wrong - IANAE).
OK; good point. I will make this more explicit.
Editorial: 1) Sec 3, page 4: "While this is adequate for TCP, and
indeed is the only way to securely do connection reuse over that
transport (see Section 9.3..." the words "connection reuse" should be
removed since it clearly does NOT reuse the connection in such a
case.
Yes ... good catch. I will reword.
2) Section 5 is a bit confusing, because the diagram shows two UA's
and two proxies between them, then describes things in terms of "UAC"
and "UAS", whereas I'm fairly sure you mean the proxies instead.
For example, second paragraph of sec 5.1 would imply the UAS uses
P2's connection for all subsequent requests going to the UAC, which
is NOT true. If it has a record-route, then for in-dialog requests
yes, but it has nothing to do with subsequent requests going to the
UAC in general.
Yes, you are right. Dale also pointed this out when he said in his
review that:
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 that approaching it as Dale has stated it -- two SIP agents
at the ends of the connection -- is the right way to go. I will
change the text to reflect this in the new revision.
3) sec 5.2: "Connection reuse on the TCP transport is done
differently from the TLS case." No, it's not done at all. There is
no "reused connection".
Yes.
4) sec 5.2 says "The presence of the "alias" parameter in the topmost
Via for a TCP transport is not required." Then later in section 8.1
it says "For TCP and SCTP transports, the client MUST NOT insert the
"alias" parameter in the topmost Via header.." (also note the
double-period at the end of that sentence)
I will fix this -- the double period is an easy fix. Regarding
the first comment in the above paragraph, S5.2 and S8.1 agree insofar
as saying that TCP transports do not require an "alias" parameter.
However since S5 is informative only, I did not put in any normative
language.
Thanks for your review, Hadriel.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
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
