Subject: [sipcore] Recording the addresses of intermediaries for OOD requests

From: [email-masked] (Dale R. Worley)
Date: Sun, 6 Apr 2014 21:43:04 -0400

draft-allen-dispatch-routing-out-of-dialog-request-00 says in section
2:

   What is needed is a way for intermediaries that need to receive and
   manipulate or process mid session requests to indicate that mid
   session out of dialog requests that relate to the dialog of the
   session being established, to indicate a URI to be included in the
   Route header of such out of dialog requests so that the request will
   route by the intermediary.

One question that arises is if a dialog passes through two
intermediaries that need to record themselves this way.  Whatever
mechanism is used must be able to record (implicitly or explicitly)
the addresses of two or more intermediaries.  This doesn't seem to be
intrinsically difficult for any of the proposed mechanisms (section
3), but the use of the chosen mechanism in case of multiple
intermediaries needs to be documented if it is not implicitly
specified by other parts of SIP.

One potential solution that is not listed in section 3 is the use of a
header part of the Contact URI to provide a Route header for the OOD
request.  (This has been mentioned before.)  E.g.,

    Contact: [email-masked]?Route=%3csbc%40example.com%3blr%3e

specifies a Route header "<[email-masked];lr>".  This would be
somewhat more verbose than some of the proposals (new header field,
new rr-param), but about as verbose as others (new URI parameter).

Since this mechanism is already implemented but is not considered a
solution to the problem, there is presumably a reason why it is not
workable.  That should be documented in the draft.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Apr 2014 16:49:13 -0400

> workable.  That should be documented in the draft.

IMO, if this is a problem that needs solving, then this seems like a 
good solution.

When using URIs with embedded header fields, there are already warnings 
to consider carefully which ones to trust and which ones not to. That 
applies here. But it applies regardless of the solution.

Another issue is how this route is to interact with any other route that 
the client is predisposed to use for new OOD requests. (E.g., an 
outbound proxy.) Does this route *replace* that? Or is it *merged* in 
some way?

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 9 Apr 2014 11:46:55 -0400

> From: Paul Kyzivat <[email-masked]>
> 
> IMO, if this is a problem that needs solving, then this [using
> ?Route=...] seems like a good solution.
> 

The baseline advice is in RFC 3261 section 19.1.5, "Forming Requests
from a URI".  Though it says:

   An implementation SHOULD NOT honor any requested Route header field
   values in order to not be used as an unwitting agent in malicious
   attacks.

I have a vague memory that the current BCP has a different opinion.

And any technique that specifies intermediaries for OOD dialogs will
present similar problems regarding attacks.

> outbound proxy.) Does this route *replace* that? Or is it *merged* in 

I've been assuming that the configured outbound proxy is put as the
first Route value and the Route(s) specified in the URI follow it.
That is, the request goes first to the outbound proxy, which then
forwards it to the first specified Route URI.  But I don't have any
practical experience with the situation.

Again, any technique that specifies intermediaries for OOD dialogs
will present similar problems.  We probably need to specify how it is
to be handled in order to prevent chaos.  Does anyone have practical
experience with this?

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 11 Apr 2014 16:40:41 -0400

> workable.  That should be documented in the draft.

It won't work.

For one thing, the next SBC in the chain can't just leave that thing there, since it reveals the upstream host machine. They'd have to encrypt/cookify both the "[email-masked]" as well the embedded Route header portion.

But more importantly, there's no guarantee that the receiving UAS will use those embedded Route headers as real Route headers in out-of-dialog requests.  There's just too much crap out there to think that will work reliably - it's far easier/safer to simply embed the info (in encrypted/cookified form) in the Contact user portion, and replace the Contact. (and an SBC is a B2BUA, and B2BUA's really *should* replace the Contact)

-hadriel

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 21 Apr 2014 15:51:00 -0400

[sorry for not responding to these faster]

> From: Hadriel Kaplan <[email-masked]>

> It won't work.
> 
> For one thing, the next SBC in the chain can't just leave that thing
> there, since it reveals the upstream host machine. They'd have to
> encrypt/cookify both the "[email-masked]" as well the embedded Route
> header portion.

What is the prohibition on "reveals the upstream host machine"?

> But more importantly, there's no guarantee that the receiving UAS
> will use those embedded Route headers as real Route headers in
> out-of-dialog requests.  There's just too much crap out there to
> think that will work reliably

I think you mean, "There are far too many devices that won't properly
process a Route header component of a URI".  Am I right?

> From: Hadriel Kaplan <[email-masked]>

> > When you say "You would send out-of-dialog REFERs", it sounds like
> > this is the *bulk* of the problems you're encountering.  So let me
> > ask, "If no UA ever sent out-of-dialog REFERs, would the problems you
> > see with GRUUs vanish?"
> 
> I don't know.  REFER is the main one for out-of-dialog messages to a
> previously received in-dialog Contact that I see.
> 
> I seem to recall some problems with out-of-dialog Subscriptions[1]
> to in-dialog Contacts too, but that was a long time ago and not
> GRUU-specific.

People have mentioned SUBSCRIBE as well.  What makes the problem with
REFER to be GRUU-specific?

What I'm trying to do is to turn "It won't work." into  a clear list
of the problems that are causing things not to work.

Dale