[Sip] comments on draft-ietf-sip-record-route-fix-01

Firstly, I am still of the opinion that this is NOT an essential 
correction to SIP, but rather a BCP. Clearly the record-route mechanism 
in RFC3261 itself still works and works fine for the cases where it is 
applicable. Documenting double-record routing makes sense, but I do not 
believe it should replace what is in RFC3261 or obsolete it. There is no 
reason to do it, and its unrealistic to think that everyone who is doing 
rr-rewriting will go an change their implementation because IETF decided 
to deprecate something that works.

Section 3.1: this is an unrealistic use case. If this were the actual 
network, no media would be able to flow in the resulting session.

Section 3.2: the indented text seems to include both the original 
rfc3261 text and commentary on it; I think only the orginal text should 
be indented.

> often been noticed that letting [RFC3261] with the Record-Route
>    rewriting as the only technique described in core specification is
>    dangerous, due to the fact that rewriting has some heavy drawbacks.

this is hyperbole, and not supported by the two points which follow:

>   1) Callee cannot sign the route set, because it gets edited by the
>       proxy in the response.  Consequently, end-to-end protection of the
>       route set can not be supported by the protocol.  The openness and
>       the end-to-end principles are broken (!)...

sign the route set?? This has never been possible. Even S/MIME doesn't 
support that:

    Header fields that can be legitimately modified by proxy servers are:
    Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-
    Authorization.  If these header fields are not intact end-to-end,
    implementations SHOULD NOT consider this a breach of security

I don't know what real attack or real problem you are talking about here.

>   2) Proxy must implement special "multi-homed" stateful logic.  On
>       the request phase, it goes through output interface calculation
>       and writes the output interface into the route.  It must then
>       inspect all responses, grep for an input interface, and
>       selectively edit them to reference the correct output interface:
>       this is a CPU drag.

it is true that there is additional CPU cost. However, that is hardly 
"dangerous". And, I suspect, in most cases, not a very big CPU burden.

I'm not opposed to double record-routing; I am taking objection to the 
vilification of what is in RFC 3261.

> Thus, on the request processing side: item 4 of section 16.6 of
>       [RFC3261], it SHOULD be noticed that the URI MAY contain the

I don't know what it means to SHOULD notice something. Why is this text 
indented?

> This technique has many benefits, and is completely backwards
>    compatible with [RFC3261].  It consists in putting as the first
>    value, the Route of receiving interface, including schemes and/or URI
>    parameters, and, as second value, the Route of the sending interface.
>    When processing the response, no modification of the recorded route
>    is required.

s/Route/URI

Section 5 has odd indenting.

The document is hard to follow; it intermixes restatements of RFC3261 
sections along with other normative text which is not defined as a 
restateemnt of rfc3261.

I think it would be a clearer document, in fact, if it were not an 
essential correction and instead a clear description of how to double 
record-route and when to do it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen@cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.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