Subject: [Sipping] comments on draft-ietf-sipping-v6-transition

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Nov 2005 10:32:47 -0500

>  If user agents are configured with the Fully-Qualified Domain Name
>    (FQDN) of their outbound proxy servers (instead of with their IP
>    addresses) there SHOULD be both IPv6 and IPv4 DNS entries for
>    outbound proxy servers.  This way, user agents can use DNS to obtain
>    both their IPv6 and IPv4 addresses.

actually, the configuration of outbound proxies should not be done with 
an FQDN or an IP address, but rather a URI. Furthermore, that URI needs 
to be appearing in the Route header field of requests sent to this 
outbound proxy. <shameless-plug>See 
draft-rosenberg-sip-route-construct</shameless-plug> which discusses 
some of this.

As it relates to v6, this means that the existing URI resolution 
techniques for SIP URI can be applied to handle v6/v4 lookups.

* I couldn't tell the difference between the scenarios in section 3.2 
and 3.3. I think the draft genreally could benefit from a diagram that 
shows a sip trapezoid with various v4/v6 combinations, and then use that 
to help guide discussions in the draft.

> A SIP proxy server that receives a request using IPv6 and relays it
>    to the user agent using IPv4, or vice versa, needs to remain in the
>    path traversed by subsequent requests between both user agents.
>    Therefore, such a SIP proxy server MUST be configured to Record-Route
>    in that situation.

you should also indicate that if the proxy record-routes with an IP 
address, as is often done in practice, you'll need to modify your 
record-route in the response so that each side sees a different address 
type.

Also, the use case here explicitly talks about receiving a request from 
one IP address type and then relaying to a USER AGENT of another type. 
However, the problem arises when relaying between proxies. The root 
cause is really that you can't be certain of dual stack on either side; 
otherwise if everyone did dual stack it wouldn't be necessary to 
record-route.

> When a request is re-targeted to a new branch because the old one did
>    not elicit a response, and the request is now destined to a new
>    network (i.e., old request went to an IPv4 downstream server while
>    the new one is destined towards an IPv6 downstream server) care must
>    be taken in re-computing the identifiers.  More specifically,
>    implementations MUST ensure that, at the very least, the branch id is
>    recomputed.  

this is already an rfc3261 requirement; I don't know why v6 really 
changes anything here.

> Additionally, if raw IP addresses were used to generate
>    the signatures for the Identity header and AIB, these signatures MUST
>    be recomputed.
> 
>    To avoid recomputing the signatures used in the Identity header or
>    the AIB, it is RECOMMENDED that SIP entities use FQDNs in those
>    headers that are used as the basis for the Identity header and the
>    AIB.

I'm confused by this. The Identity header contains signatures over 
fields genreated by UAs. Whether those contain IP addresses or not, they 
are not things changed by proxies and so I dont see the issue. Unless 
this is targeting SBCs that might be modifying these things?

> agent using IPv4.  Such user agents MAY use any mechanism to obtain
>    addresses in relays, but, following the recommendations in ICE, it is
>    RECOMMENDED that user agents support TURN [10] [11] for this purpose.

It might be good to also discuss teredo and why you ruled it out (if you 
did).

> procedures, both user agents SHOULD perform the STUN-based [6]
>    connectivity checks specified by ICE.  This checks help prevent some
>    types of flooding attacks and allow user agents to discover new
>    addresses that can be useful in the presence of NATs (Network Address
>    Translators).

Its important to note that ICE impelemtnations should only pair up 
candidates with identical IP address types.

Also, you might want to discuss how to select the active candidate. 
Unfortunately there is no good choice here.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Aki Niemi <[email-masked]>
Date: Mon, 07 Nov 2005 17:08:15 +0200

ext Jonathan Rosenberg wrote:
>>  to the user agent using IPv4, or vice versa, needs to remain in 
>> the path traversed by subsequent requests between both user agents.
>>  Therefore, such a SIP proxy server MUST be configured to 
>> Record-Route in that situation.
> 
> record-route in the response so that each side sees a different 
> address type.
> 
> Also, the use case here explicitly talks about receiving a request 
> from one IP address type and then relaying to a USER AGENT of another
>  type. However, the problem arises when relaying between proxies. The
>  root cause is really that you can't be certain of dual stack on 
> either side; otherwise if everyone did dual stack it wouldn't be 
> necessary to record-route.

I agree here. In fact, the recommended procedure for the proxy should be
to double-play the record-routing; it would record route once per each
address type, therefore installing a route that has an entry with a
matching address type on both the IPv4 and IPv6 side of the proxy.

This has come up in discussions before, but I'm not sure if it is a
documented practice.

Cheers,
Aki

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 08 Nov 2005 12:01:12 -0600

> matching address type on both the IPv4 and IPv6 side of the proxy.

I am curious -- do we absolutely need double R-R here?  It would
seem that a proxy re-writing the URI to be the correct network in the
response would be adequate.  Case in point, consider the following:

IPv4           IPv4/IPv6       IPv6
UAC            Proxy P1        UAS
INV------------->
                 INV ------------>
                 R-R: <IPv6>
                     <-----------200 OK
                                 R-R: <IPv6>
    <------------200 OK
                 R-R: <IPv4>

The UAC's route set includes an IPv4 Route P1, and for requests
originating from the UAS, the route set will include an IPv6
route.

Thanks,

- vijay

---

From: Aki Niemi <[email-masked]>
Date: Tue, 08 Nov 2005 23:21:03 +0200

Inline.

ext Vijay K. Gurbani wrote:
> I am curious -- do we absolutely need double R-R here?  

Nope.

> It would

I don't like it. Munging with the already collected set of Record-Routes 
in responses seems brittle. The proxy will anyway find out if the 
upstream and downstream transports don't mix when it finds the next hop 
for the request. I'd rather deal with the issue then and there, by 
pushing a pair of RRs into the request header, rather than delaying it.

We have an existing implementation that does this, and I think it is the 
reasonable thing to do. Why do you think it is not?

Cheers,
Aki

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 08 Nov 2005 16:01:59 -0600

Aki Niemi wrote:
> in responses seems brittle. 

The proxy is only munging what it inserted, so I think it is okay.

> The proxy will anyway find out if the 

It's more optimized if the proxy has to deal with the request
in one swoop.

What is the current thinking in the WG: should we be advocating
double R-R for such situations or response re-writing?

Thanks,

- vijay

---

From: Aki Niemi <[email-masked]>
Date: Wed, 09 Nov 2005 00:58:36 +0200

ext Vijay K. Gurbani wrote:
> Aki Niemi wrote:
> 
>> I don't like it. Munging with the already collected set of 
>> Record-Routes in responses seems brittle. 
> 
> 

Well, it probably works, but IMHO it's a hack nevertheless.

>> The proxy will anyway find out if the upstream and downstream 
>> transports don't mix when it finds the next hop for the request. I'd 
>> rather deal with the issue then and there, by pushing a pair of RRs 
>> into the request header, rather than delaying it.
>>
>> We have an existing implementation that does this, and I think it is 
>> the reasonable thing to do. Why do you think it is not? 
> 

Which one is this?

	Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Nov 2005 19:10:12 -0500

I think that its OK to do either. Modifying your RR in the response is 
OK (GRUU does this), inserting double RR is also OK. Its a local choice. 
I think double RR is slightly better in that avoids the CPU cost of 
searching for your own RR in the response just to rewrite it.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Tue, 8 Nov 2005 18:47:18 -0600

> double R-R for such situations or response re-writing?

Double recording, as this works much more cleanly with the Path/ 
Service-Route model, which is greatly simplified by route reversability.

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 09 Nov 2005 00:26:46 -0600

> searching for your own RR in the response just to rewrite it.

But there are costs incurred in a double R-R as well.  A
naive implementation may actually spiral the request to
itself as the result of a double R-R, and in the end spend
time and space maintaining that extra transaction.  Of course,
a smarter implementation can optimize this if it knows that
the request is destined to itself anyway.

In the end, there are costs with both of the options.  But
for this specific purpose, modifying the response seems
cleaner IMHO.

Thanks,

- vijay

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 08 Nov 2005 21:39:10 -0500

> in responses seems brittle. 

Rewriting a Record-Route in a response as it passes through the proxy
that inserted it in the request does seem to have a long history though.
See RFC 3261 section 16.12.1.3 for a long discussion of how to do it
well.

Dale

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 09 Nov 2005 19:33:08 +0200

Hi,

> This has come up in discussions before, but I'm not sure if it is a

Double routing is documented in Section 6 of RFC 3486.

Cheers,

Gonzalo

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 Nov 2005 12:29:22 -0600

> Double routing is documented in Section 6 of RFC 3486.

Right. And any future extension that extends security across the  
route set (which Path and Service-Route can do in some circumstances,  
and I believe they reference 3486) will, I think, require in-out  
recording (aka double routing).

--
dean

---

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Nov 2005 09:39:13 -0600

There have been discussions on list about this several times. We've
got an arsenal of reasons now documenting what breaks with the rewriting
approach. That this comes around again (and seems to not be high on
the list of considerations in some of the proposals in the Route/ 
outbound
discussions) tells me we've got a weak spot in the way we're capturing
what we've learned.

Dean and Gonzalo point out that we captured some of this in 3486.
There are bugs in the bug database that are related (talking about
tls/non-tls transitions). I _thought_ there was a bug that captured the
double-record route idea in its entirety, but don't find it on search  
now.

What can we do to get this into the mainstream specs more clearly
and quickly?

RjS

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 16 Nov 2005 11:12:10 -0600

Robert:

Don't blame Dale ;-), it was I who raised this topic during IETF 64.
More inline.

Robert Sparks wrote:
> got an arsenal of reasons now documenting what breaks with the 
> rewriting approach. That this comes around again (and seems to not be
>  high on the list of considerations in some of the proposals in the 
> Route/ outbound discussions) tells me we've got a weak spot in the 
> way we're capturing what we've learned.
> 

Ironically enough, rfc3486 also provides a case for re-writing the
R-R entry (see second paragraph in Section 5 of rfc3486).  So
I don't think that we can rule re-writing out.

> tls/non-tls transitions). I _thought_ there was a bug that captured 
> the double-record route idea in its entirety, but don't find it on 
> search  now.

It appears to me that we are advocating a blanket double R-R for
all situations.  I am not arguing that we shouldn't do double R-R
for Path, Sevice Route, and TLS/non-TLS, and in fact, these will
not work without double R-R.

But is a double R-R absolutely neccessary for IPv4/IPv6 transition,
or for some other simple applications?  That is what I am trying to
figure out.

I went through Dean's seminal email on this going back three(!) years
(http://www1.ietf.org/mail-archive/web/sip/current/msg06589.html).
The two reasons why double R-R breaks down are:

(1) A UAS cannot sign the route set, because it gets edited when the
response goes through a proxy.

(2) A proxy must spent CPU cycles inspecting the R-R responses
and modifying the one it inserted.

Regarding (1), I don't quite understand this.  A UAS does not
have a fully formed route set when it gets a dialog-initiating
request.  Instead, it has a bunch of R-R headers.  Do we have
any security extensions that include signing R-R headers?

Regarding (2), I will note that there are costs incurred in
handling a double R-R as well.  A naive implementation may
actually spiral the request to itself as the result of a double
R-R, and in the end spend time and space maintaining that extra
transaction.  Of course, a smarter implementation can optimize
this if it knows that the request is destined to itself anyway.

I am probing to see whether double R-R is the blanket answer
for all questions.  Re-writing the R-R appears to be more
optimal for some cases; IPv4/IPv6 transition is what I had
in mind, as well as the case discussed in Section 5 of rfc3486.

> What can we do to get this into the mainstream specs more clearly and
> quickly?

I think we ought to first decide whether double R-R is the
only alternative in all situations?  If the answer to that is
no, we ought to come up with an I-D that describes situations
where double R-R is *the* only option and others where re-writing
will suffice.  And have that I-D drive subsequent discussions.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Ph.D.  vkg@{lucent.com,research.bell-labs.com,acm.org}
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Nov 2005 13:15:36 -0600

> Don't blame Dale ;-), it was I who raised this topic during IETF 64.

I didn't intend to be poking at anybody. My concern is that we're not
capturing work we've already done well.

> More inline.
ditto.
>
> Robert Sparks wrote:
>> There have been discussions on list about this several times.  
>> We've got an arsenal of reasons now documenting what breaks with  
>> the rewriting approach. That this comes around again (and seems to  
>> not be
>>  high on the list of considerations in some of the proposals in  
>> the Route/ outbound discussions) tells me we've got a weak spot in  
>> the way we're capturing what we've learned.
That use case called out there can also satisfied with a double  
record-route.

>> tls/non-tls transitions). I _thought_ there was a bug that  
>> captured the double-record route idea in its entirety, but don't  
>> find it on search  now.
>
> all situations.
Specifically all situations where a message arrives and leaves with
different transport characteristics (different interfaces, different  
compression,
different protocol, whatever).
> I am not arguing that we shouldn't do double R-R
It depends. If you find yourself wanting to rewrite, a double RR is  
better.
If you don't need to rewrite for things to work, then a single RR  
will work.

> The two reasons why double R-R breaks down are:

These are reasons that response rewriting breaks down, not double RR.

> any security extensions that include signing R-R headers?
Jon can probably better speak to this, but we've had several  
opportunities
go by where we would have _liked_ to include RR in a signature over a  
response,
but had to choose not to because of the rewriting rules in 3261.
> this if it knows that the request is destined to itself anyway.
You're not suggesting we optimize the protocol for naive  
implementations?

The only real cost with double record-routing over rewriting is space in
the message. If you trade that space off, computation is at the worst  
case
equivalent, and in some cases simpler.

> in mind, as well as the case discussed in Section 5 of rfc3486.
As above, The use case in Section 5 can be satisfied with a double RR.
I'm having a hard time seeing how transitioning a v4/v6 boundary would
be made easier with rewriting.

> will suffice.  And have that I-D drive subsequent discussions.

Sigh. And here is part of why I'm sad that we haven't captured the
earlier conversations better than we have.

Unless we care about how this affects the overall security story, we're
talking about something that is entirely an implementation decision.
If we're not breaking something by rewriting, then by all means, feel
free to rewrite. The conversations we've had to date indicate that we
should prefer double RR over rewrite because we've identified at least
one property that rewriting actually breaks.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 16 Nov 2005 16:42:14 -0600

Robert Sparks wrote:
> My concern is that we're not capturing work we've already done well.

Robert: I think this issue is still ambiguous in the SIP community.
It will be great to lay it to rest once and for all.

I think that the entire discussion can summed up by the last

> one property that rewriting actually breaks.

So it is appearing that whether or not to double R-R or
rewrite hinges on the overall security story.  If there are
use cases of where we want to include R-R headers in a
signature, then we ought to be mandating the use of double
R-R in all subsequent documents issued by SIP* WGs where this
problem arises.

I glanced at draft-cao-sip-response-auth-00.txt and could
not find it authoritatively stating that the R-R must be used
in a digest (is that an oversight?).  Can we please have some
direction from the security folks on this topic?.  Maybe we can
file the result as additional information in Bug number 664 -
Double Record Routing for future reference.

Thanks,

- vijay