Subject: [Sip] Review of draft-ietf-sip-outbound-12

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Mar 2008 16:46:47 -0800

$Id: draft-ietf-sip-outbound-12-rev.txt,v 1.3 2008/03/07 00:23:20 ekr Exp $

S 1.
   possible.  This can happen for several reasons.  Connections to the
   UA can be blocked by a firewall device between the UA and the proxy
   or registrar, which will only allow new connections in the direction
   of the UA to the Proxy.  Similarly a NAT could be present, which is
   only capable of allowing new connections from the private address
   side to the public side.  This specification allows a SIP User Agent

Suggest rewrite:

   This can happen for several reasons, but the most likely is a
   NAT or a firewall in between the SIP UA and the proxy. Many
   such devices will only allow outgoing connections.
   This specification allows a SIP User Agent

   datagrams, a TCP connection, or an analogous concept of another
s/of/for/

S 2.1.
   Authoritative Proxy:  A proxy that handles non-REGISTER requests for
      a specific Address-of-Record (AOR), performs the logical Location
      Server lookup described in RFC 3261, and forwards those requests
      to specific Contact URIs.

Are you saying it doesn't handle REGISTERs too, or merely that
it might not?

S 3.1.
   is power cycled.  Each UA can register multiple times over different
   connections for the same SIP Address of Record (AOR) to achieve high

s/connections/flows/

   can use the instance-id to recognize that two different registrations

s/registrations/registrations (flows)/, perhaps?

   When sending a dialog-forming request, a UA can also ask its first

First == Closest? Highest priority?

   UAs can use a simple periodic message as a keep alive mechanism to

can? Isn't this no longer optional?

S 3.3.
   Scalability is achieved by using DNS SRV [RFC2782] to load balance
   the primary connection across a set of machines that can service the
   primary connection, and also using DNS SRV to load balance across a
   separate set of machines that can service the secondary connection.
   The deployment here requires that DNS is configured with one entry
   that resolves to all the primary hosts and another entry that
   resolves to all the secondary hosts.  While this introduces
   additional DNS configuration, the approach works and requires no
   additional SIP extensions.

      Note:  Approaches which select multiple connections from a single
      DNS SRV set were also considered, but cannot prevent two
      connections from accidentally resolving to the same host.  The
      approach in this document does not prevent future extensions, such
      as the SIP UA configuration framework
      [I-D.ietf-sipping-config-framework], from adding other ways for a
      User Agent to discover its outbound-proxy-set.

I don't actually think this note makes sense, since SRV can 
distinguish multiple servers. I think I understand why the
protocol is designed this way, but I would just remove the
Note.

S 3.4.
   The Edge Proxy includes a Path header [RFC3327] so that
   when the registrar later forwards a request to this UA, the request
   is routed through the Edge Proxy.

I would move this to after the diagram. The rest of this graf is setup.

S 3.5.
   This document describes three keep alive mechanisms. 

I would insert after this a list of thee mechanisms.

S 4.2.3.
   A User Agent MUST NOT include a reg-id header parameter in the
   Contact header field of a registration with a non-zero expiration, if
   the registering UA is not the same instance as the UA referred to by
   the target Contact header field.  (This practice is occasionally used
   to install forwarding policy into registrars.)

This is pretty hard to parse. Can you rewrite.

S 4.4.
   If no Flow-Timer header field was present in a register response for
   this flow, the UA can send keepalives at its discretion.  The rest of
   this paragraph provides RECOMMENDED default values for these
   keepalives.  The time between each keep alive request when using non
   connection based transports such as UDP SHOULD be a random number
   between 24 and 29 seconds.  For connection based transports such as
   TCP, correct selection of keepalive frequency is primarily a trade-
   off between battery usage and availability.  For devices where power
   is not a significant concern, the UA SHOULD select a random number
   between 95 and 120 seconds between keepalives.  When battery power is
   a concern, the UA SHOULD select a random number between 672 and 840
   seconds (14 minutes).  These times MAY be configurable.  To clarify,
   the random number will be different for each keepalive ping.

Why not move these definitions to the CRLF and STUN sections. I think
that will be more readable.

S 5.1.
   When an Edge Proxy receives a registration request with a reg-id
   header parameter in the Contact header field, it needs to determine
   if it (the edge proxy) will have to be visited for any subsequent
   requests sent to the user agent identified in the Contact header
   field, or not.  If the Edge Proxy determines that this is the case,
   it inserts its URI in a Path header field value as described in RFC
   3327 [RFC3327].  If the Edge Proxy is the first SIP node after the
   UAC, it either MUST store a "flow token" (containing information
   about the flow from the previous hop) in its Path URI or reject the
   request. 

I'm having trouble parsing this graf. How is the proxy supposed to
make the determination in sentence 1? Is sentence 3 the rule
for making that determination?

S 5.3.
   If the Route header value contains an 'ob' parameter, the Route
   header was probably copied from the Path header in a registration.
   If this is the case and the request is a new dialog-forming request,
   the proxy needs to adjust the route set to insure that subsequent
   requests in the dialog can be delivered over a valid flow to the UA
   instance identified by the flow token.

I am having trouble reading this too. Does "this" in the second
sentence refer to the presence of 'ob' or to the Route header
having been copied? If the latter, how is the determination
made?

   If the flow in the flow token in the topmost Route header field value
   matches the source IP address and port of the request, the request is
   an "outgoing" request.  For an "outgoing" request, the edge proxy
   just removes the Route header and continues processing the request.
   Otherwise, this is an "incoming" request.  For an incoming request,
   the proxy removes the Route header field value and forwards the
   request over the 'logical flow' identified by the flow token, that is

the flow isn't "in" the flow token, right? It just corresponds
to it. Also, is this "if" or is it "iff"?

I would bulletize this list like so:

   If the flow in the flow token in the topmost Route header field value
   matches the source IP address and port of the request, the request is
   an "outgoing" request.  

   - For an "outgoing" request, the edge proxy
   just removes the Route header and continues processing the request.
   
   - For an incoming request,
   the proxy removes the Route header field value and forwards the
   request over the 'logical flow' identified by the flow token, that is

   Example Algorithm:  To decode the flow token, take the flow
      identifier in the user portion of the URI and base64 decode it,
      then verify the HMAC is correct by recomputing the HMAC and
      checking that it matches.  If the HMAC is not correct, the proxy
      SHOULD send a 403 (Forbidden) response.  (The proxy could ignore
      such requests for prevention of denial of service attacks.)  If
      the HMAC is correct then the proxy SHOULD forward the request on
      the flow that was specified by the information in the flow
      identifier.  If this flow no longer exists, the proxy SHOULD send
      a 430 (Flow Failed) response to the request.

The last two sentences are not part of the decoding algorithm.
They're generic instructions for how to handle valid flow tokens.
They should be moved out of this graf. Also, it's not clear to
me why the parenthetical significantl improves Dos resistance.

   Note that this specification needs mid-dialog requests to be routed
   over the same flows as those stored in the Path vector from the
   initial registration, but specific procedures at the edge proxy to
   ensure that mid-dialog requests are routed over an existing flow are
   not part of this specification.  However, an approach such as having
   the Edge Proxy add a Record-Route header with a flow token is one way
   to ensure that mid-dialog requests are routed over the correct flow.
   The Edge Proxy can use the presence of the "ob" parameter in dialog-
   forming requests in the UAC's Contact URI (or topmost Route header
   field) to determine if it should add a flow token.

I would rewrite the first sentence normatively and then have the rest 
of the graf as a implementation note.

S 6.
I don't think it's helpful to write this as a series of steps.
That's an implementation issue. Rather, describe the cases
and let the implementor work it out for themselves.

   Contact header contains more than one header field value with a non-
   zero expiration and a 'reg-id' parameter, the entire registration
   SHOULD be rejected with a 400 Bad Request response.  If the Contact

Why?

 If the Contact header field does not
   contain a '+sip.instance' media feature parameter, the registrar
   processes the request using the Contact binding rules in RFC 3261
   [RFC3261].

Isn't this really the high order bit? Maybe it should be moved
up to the front.

S 7.
      Typically this means that for TCP, the request is sent on the same
      TCP socket that received the REGISTER request.  For UDP, the
      request is sent from the same local IP address and port over which
      the registration was received, to the same IP address and port
      from which the REGISTER was received.

This is an implementation note? Maybe say so...

S 9.
The first set of examples where you fetch the profile seems
superfluous. There are other ways for the UAC to get config
information and this is not part of this spec.

-Ekr
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip