[Sip] Re: URI comparison rules - IPv6 addresses

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Wed, 21 November 2007 15:37 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iurdz-00060h-Eb; Wed, 21 Nov 2007 10:37:39 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Iurdy-00060c-3J for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:37:38 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iurdx-00060R-9T for sip@ietf.org; Wed, 21 Nov 2007 10:37:37 -0500
Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iurdw-0004xI-Qq for sip@ietf.org; Wed, 21 Nov 2007 10:37:37 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lALFbMfV003261; Wed, 21 Nov 2007 09:37:23 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lALFbMj21870; Wed, 21 Nov 2007 09:37:23 -0600 (CST)
Message-ID: <474450B2.1020907@alcatel-lucent.com>
Date: Wed, 21 Nov 2007 09:37:22 -0600
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
References: <BBE61D1553D8A34F812FF87377B2935F01CCDE6A@ATL1VEXC020.usdom003.tco.tc> <4743F62A.8040903@ericsson.com> <4743F78D.4070705@ericsson.com>
In-Reply-To: <4743F78D.4070705@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: sip <sip@ietf.org>, Brett Tate <brett@broadsoft.com>
Subject: [Sip] Re: URI comparison rules - IPv6 addresses
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Gonzalo Camarillo wrote:
> Hi,
> 
> Brett brought this up in the SIP Implementors mailing list. The
> following IPv6 addresses are supposed to be equivalent:
> 
> [::ffff:192.0.2.128] and [::ffff:c000:280]
> [2001:db8::9:1] and [2001:db8::9:01]
> [0:0:0:0:0:FFFF:129.144.52.38] and [::FFFF:129.144.52.38]
> 
> Now, let's say I need to compare sip:user1@[::ffff:192.0.2.128] and
> sip:user1@[::ffff:c000:280]. Should we consider these URIs to be
> equivalent or not?
> 
> My proposal is that we clarify that IPv6 address comparison happens at
> the binary level, not at the textual level. We could log a bug against
> RFC3261, and try and add such a clarification to the IPv6 transition
> document (I will need to ask the ADs whether or not we can add this in
> AUTH48).

Gonzalo: My only concern that I had mentioned to Brett as
well was that this should not be construed as endorsing the
notion of multiple representations of the IPv6 address in
SIP signaling.  This may cause problems in normal SIP operations.

Consider a proxy that uses the sent-by address in a loop detection
mechanism.  If it gets a looped request but the upstream proxy
had now put a different representation of the IP address, then
the proxy will not recognize that as a loop.  Admittedly, the
upstream proxy should not be inserting different representations
of the same IP address in each request (unless, of course it is
malicious; but then if it is malicious, it could probably do
damage by other means.)

Now, regarding where to put it: in v6-transition or in a SIP
essential fix, here are some thoughts.  Insofar as we are talking
about URI comparison, this clarification is probably best put
in S19.1.4 (URI Comparison) of rfc3261.  We already have a
SIP essential fix document that fixes the IPv6 ABNF in rfc3261
(http://tools.ietf.org/html/draft-gurbani-sip-ipv6-abnf-fix-00);
this clarification could be tacked on in that draft if the WG
agrees.  Thoughts?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


_______________________________________________
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