[Sip] IESG Discuss Comments on Symmetric Response Routing

[Allison Mankin <[e-mail]>]

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.

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.".

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).

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.

I would personally consider the UNSAF document a normative reference,
but this is not a big deal.

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.





_______________________________________________
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