Subject: [Sip] Re: draft-ietf-sip-outbound-02

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Mar 2006 17:47:15 -0500

I only have a couple of comments re this revision:

  "5.1. Processing Register Requests	 		
				
   When an Edge Proxy receives a registration request with a
   sip.instance media feature tag in the Contact header field, it MUST
   form a flow identifier token that is unique to this network flow.		
   The Edge Proxy MUST insert this token into a URI referring to this		
   proxy and place this URI into a Path header field as described in RFC		
   3327 [12]. The token MAY be placed in the userpart of the URI."

I believe this should only be done if the request contains 
Supported:path. Without Supported:path it should not add a Path entry, 
and without that none of this works.

  "The advantage to a stateless approach to managing the flow	 	
   information is that there is no state on the edge proxy that			
   requires clean up or that has to be synchronized with the			
   registrar."

This isn't quite true. The flow itself is state. How long should it be 
kept around? Seems like deciding that requires *some* additional state.

	Paul

_______________________________________________
Sip mailing list  https://www1.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

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Mar 2006 10:11:25 -0800

> and without that none of this works.
Hmm, we probably need to fix some text here. I don't actually see how it
matters if the UA supports the path header or not. It's the registrar that
needs to support it.

> kept around? Seems like deciding that requires *some* additional state.
Agree - would it be better to phrase this as the state gets bound to the
flow and lifetime is determined by the lifetime of the flow? I'm not sure
how to say this.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 Mar 2006 17:26:56 -0500

> matters if the UA supports the path header or not. It's the registrar that

The way that Path is specified, the UAC is supposed to indicate support 
before the proxies use it. Technically, things could still work fine 
without the UAC being complicit, but this is a constraint in the RFC.

> flow and lifetime is determined by the lifetime of the flow? I'm not sure

Yeah, I'm not sure either. I was just reacting to the wording here, 
which seems misleading.

Its not entirely clear to me what is the minimum amount of state that 
must be kept to make this work. There are probably alternatives 
depending on which particular pieces of state one might prefer to keep. 
One possibility is to keep the expiration time of the registration that 
the flow is associated with.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Mar 2006 12:12:55 -0600

On Mar 12, 2006, at 4:26 PM, Paul Kyzivat wrote:

> The way that Path is specified, the UAC is supposed to indicate  
> support before the proxies use it. Technically, things could still  
> work fine without the UAC being complicit, but this is a constraint  
> in the RFC.

We added this behavior in PATH at the insistence of some security  
types.  Others also viewed it as an OPES and/or UNSAF issue, which  
could perhaps explain just how confusing the whole proxy-routing  
model in SIP actually is.

The idea behind Supported: path is that if the UA understands Path,  
then it has the ability to perform validation of received Path  
vectors to detect "unexpected proxies" that are presumed to be MITM  
attackers on its vector. It might also do run time analysis of Route  
and Via against Path to make sure everything is well-behaved.

In practical reality, we seem to trust SIP proxies as implicitly as  
we trust IP routers, and expect routes to change periodically as  
topologies adapt. Of course, we can't re-route mid-dialog, meaning we  
just get a failure scenario for dialogs that are affected by a  
topology change unless subtle and complex (and unspecified by IETF)  
redundancy measures have been applied at the proxy layer.

Also in practice, no UA that I know of pays any attention to the  
returned Path header field, and many systems are refusing to return  
it because they believe letting the UA know about the route of its  
requests violates the proxy-operator's veil of secrecy, which they  
hold to be a Good Thing.

This lends credence to the argument that proxy-routing should be a  
single-layered special-case negotiated and controlled by the UAs (the  
"outbound" case) rather than the multi-layered, invisible to the UA  
service-invoking model that IMS uses.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Mar 2006 22:30:06 -0800

> service-invoking model that IMS uses.

What can I say :-) Do you think we should do anything to update drafts that
mandate you do something that no one knows how to do (and the draft provides
no hits on how to do) and no one does? Probably not given we have more
important things but depressing all the same.

Anyway, it is easy to fix outbound to be consistent with this.

---

From: Hans Persson <[email-masked]>
Date: Thu, 16 Mar 2006 17:22:10 +0100

I have some nits on outbound-02.

Section 1, first paragraph: Remove the "the" starting line three.
"Connection to the UA" -> "Connections to the UA".

Section 1, last paragraph: "Since," -> "Since". 
"keep alive" -> "keep-alive" (this applies to lots of places throughout
the text).

Section 2.1. "flow" definition should be "Flow".
Colon missing after outbound-proxy-set definition.

Section 3: Add comma after "redundancy".

Section 3.2, second paragraph: Add "which" after "reg-id parameter".

Section 3.3, second paragraph: Shouldn't "two" on line two be "multiple"
or something like that? The rest of the paragraph talks about "two of
the physical hosts" and things like that, implying the presence of more
than two. Another option is that the text should be something like "two
logical hosts" to differentiate it from "physical hosts" later.

Section 3.3, second paragraph: "the two connection" -> "the two
connections".
fourth paragraph: Move "approach" to before the parenthesis for better
readability.

Section 3.4: It seems to be the idea that "Edge Proxy" is to be
capitalized, but starting here there are several instances where this is
not the case.

Section 3.5, Note: "detect a changes" -> "detect a changed", "per
connection" -> "per-connection".

Section 4.1, first paragraph: "cylces" -> "cycles".

Section 4.2, first paragraph: Sentence two starts with "The" but it
would be better with "This".

Section 4.3.1: "When an UA" -> "When a UA".

Section 4.3.2: "non TLS" -> "non-TLS". Remove comma after "to this IP
address". The sentence starting with "For TLS protocols" should be taken
out and shot. I *think* changing "in the next hop URI MUST match one" to
"in the next hop URI matches one".

Section 4.4, second paragraph: "UDP based" -> "UDP-based". "TCP based" -
> "TCP-based".
Note: Insert "make" before "the keep-alive" and "upper bound" after "120
seconds".

Section 4.5, second paragraph: The base time is set to 90 seconds here,
but in the next paragraph it is 60 seconds. Insert "the" before "power
of the number".

Section 5.2, Algorithm 1: Change "This results in an approximately 16
octet identifier." to "This results in an identifier approximately 16
octets long."
Algorithm 2: "20 byte" -> "20-octet". "The concatenation of the HMAC and
S are" -> "The concatenation of the HMAC and S is". "32 octet" -> "32-
octet". 

Section 5.3, Algorithm 2: Remove the comma after "flow token" and put it
after "URI". Insert "that" after "checking".

Section 6.1, heading: "Register" -> "REGISTER".
Third paragraph: Remove the first comma.

Section 7, heading: "UAS" -> "UASs".
First paragraph: "register" -> "REGISTER".

Section 8, last-but-one paragraph: Remove duplicated and misspelled
"seams".

Section 10.1, first paragraph: Spurious space after reference.

Section 10.2, first paragraph: Ditto.

Section 10.3, Description: Change "A Registrar places this option-tag in
a Supported header to communicate to the registering User Agent the
Registrars support for this extension." to "A Registrar places this
option-tag in a Supported header to communicate the Registrar's support
for this extension to the registering User Agent."

Section 11, third paragraph: "route" -> "Route".
Fourth paragraph: "route header" -> "Route header". "path header" ->
"Path header".

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210877   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/