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

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip