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

[Sip] Re: IESG Discuss Comments on Symmetric Response Routing

My apologies for the delay. I managed to get in a revision to the draft before the deadline which addresses these comments. Until it appears in the archives, you can find it at:

http://www.jdrosen.net/papers/draft-ietf-sip-symmetric-response-01.txt


I also converted to xml while I was at it, so the general formatting should be better. Responses below.

Allison Mankin wrote:

The IESG reviewed draft-ietf-sip-symmetric-response-00.txt and there were
two sets of Discuss comments.  They do not seem too hard to address.  In
addition, the FQDNs in the draft need to be changed to example.com.
OK, fixed. I also changed public addresses to be within 192.0.2/24. The private addresses remain with 10/8.

Below are the comments.  They are also in the ID tracker.

Allison

Comments:

Ted Hardie:
First, let me say that a large number of the issues I had
with the document turned out to be very well documented
in the IAB considerations section of the draft. A few
other issues:

In Section 3:

      When the client sends the request, if the request is sent using UDP,
        the client MUST be prepared to receive the response on the same
        socket the request was sent on. Specifically, it MUST be prepared to
        receive the response on the same IP address and port present in the
        source IP address and source port of the request. For backwards
        compatibility, the client MUST still be prepared to receive a
        response on the port indicated in the sent-by field of the topmost
        Via header field value, as specified in Section 18.1.1 of SIP [1].


It seems pretty clear from the "on the same socket" that the following
sentence means the IP address and port present in the source IP
and port of the request _when it is sent_. I think it would be clearer,
though, to use phrasing like "it MUST be prepared to receive the
response on the same IP address and port it used to populate
the source IP address and source port of the request.".
OK, I changed the wording to the text you suggest. I made this change everywhere the term "socket" was used, in order to be explicit about what is meant.

Also in Section 3:

        To keep the binding fresh, the client SHOULD retransmit its INVITE every 20
        seconds or so. These retransmissions will need to take place even
        after receiving a provisional response.

based on the idea the one minute seems to be a common UDP binding lifetime.
Section 9.3 notes, however, that there is no way to determine the UDP binding
lifetime. Is there anyway to introduce a growing/shrinking algorithm
to this for cases where the binding lifetime is much longer (to avoid the
aggressiveness of 20 seconds for an arbitrary period of time) or to handle
the cases where the binding lifetime is shorter than 20+transmission time to
the NAT (since this has to handle the NAT being at some arbitrary place in
the topology).
Yes. STUN describes a binary search algorithm for trying to detect the lifetime. That is not without peril as well, and the issues there are documented in STUN. I added the following text:

<t>
A UA MAY execute the binding lifetime discovery algorithm in Section
10.2 of <xref target="RFC 3489">RFC 3489</xref> to determine the
actual binding lifetime in the NAT. If it is longer than 1
minute, the client SHOULD increase the interval for request
retransmissions up to half of the discovered lifetime. If it is
shorter than one minute, it SHOULD decrease the interval for request
retransmissions to half of the discovered lifetime. Note that
discovery of binding lifetimes can be unreliable. See Section 14.3 of
<xref target="RFC3489">RFC 3489</xref>.
</t>


In the initial section of 9:

        The client can then perform an additional registration,
        using this address in a Contact header. This would allow a client to
        receive incoming requests, such as INVITE, on the socket through
        which the registration was sent.

As is noted below that point, there are cases in which the port binding
is only valid for the server to which the original registration was sent.
Will the Contact header "leak" that so that a direction connection between a
different sip agent (user or proxy) might attempt to use it? If so, a forward
pointer to the limitation might be useful here.
This is possible with the Path extension to SIP (RFC 3327). That spec allows for servers between the client and the registrar to indicate that they need to be on the path of requests from the registrar to the client. Its a good idea to include a reference to that and a brief discussion.

Here is what I added:

<t>
In many cases, the server to whom the registration is sent won't be
the registrar itself, but rather, a proxy which then sends the request
to the registrar. In such a case, any incoming requests for the client
must traverse the proxy to whom the registration was directly
sent. The <xref target="RFC3327">Path header extension to SIP</xref>
allows the proxy to indicate that it must be on the path of such
requests.
</t>

and this introduced some additional brittleness that I documented:

<t>If the registrar and the server to whom the client sent its
REGISTER request are not the same, the approach will only work if the
server uses the <xref target="RFC3327">Path header field</xref>. There
is not an easy and reliable way for the server to determine that the
Path header should be used for a registration. Using Path when the
address in the topmost Via header field is a private address will
usually work, but may result in usage of Path when it is not actually
needed.
</t>

I would personally consider the UNSAF document a normative reference,
but this is not a big deal.
RFC 3424 is informational. I dont think you can have a normative reference to an informational document. As such, I have kept the UNSAF reference as informational.


Erik Nordmark:
The security considerations section doesn't set a very good example. It could easily be read as "we didn't look hard for security issues".

Thus I'd like it to provide the reasoning that lead to thinking
that there are no added security issues. Presumably a paragraph or two would
suffice.
OK. Here is the text I put in there:

<t>When a server uses this specification, responses that it sends will
now include the source port where the request came from. In some
instances, the source address and port of a request are sensitive
information. If they are sensitive, requests SHOULD be protected by
using SIP over TLS <xref target="RFC3261"/>. In such a case, this
specification does not provide any response routing functions (as
these only work with TCP); it merely provides the client with
information about the source port as seen by the server.
</t>

<t>
It is possible that an attacker might try to disrupt service to a
client by acting as a man-in-the-middle, modifying the rport parameter
in a Via header in a request sent by a client. Removal of this
parameter will prevent clients from behind NATs from receiving
service. Addition of the parameter will generally have no
impact. Of course, if an attacker is capable of launching a
man-in-the-middle attack, there are many other ways of denying
service, such as merely discarding the request. Therefore, this attack
does not seem significant.
</t>

Thanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip