Re: [shim6] Problems with ULID (IP) over longer sessions.

Javier Ubillos <jav@sics.se> Mon, 03 May 2010 09:57 UTC

Return-Path: <jav@sics.se>
X-Original-To: shim6@core3.amsl.com
Delivered-To: shim6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F0B3A6C25 for <shim6@core3.amsl.com>; Mon, 3 May 2010 02:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Level:
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+DUPwxLTZLT for <shim6@core3.amsl.com>; Mon, 3 May 2010 02:57:28 -0700 (PDT)
Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 27F1E3A6C60 for <shim6@ietf.org>; Mon, 3 May 2010 02:57:22 -0700 (PDT)
Received: from [10.0.255.253] (h206n3-haes-a12.ias.bredband.telia.com [78.72.156.206]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id B659B40313; Mon, 3 May 2010 11:57:06 +0200 (CEST)
From: Javier Ubillos <jav@sics.se>
To: Alberto =?ISO-8859-1?Q?Garc=EDa?= <alberto@it.uc3m.es>
In-Reply-To: <DD1BCF0217394718A07CF6EFF8493B0A@bombo>
References: <1272457259.4126.63.camel@bit> <DD1BCF0217394718A07CF6EFF8493B0A@bombo>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HiLzdiOPeSWW39ahF6he"
Date: Mon, 03 May 2010 11:57:06 +0200
Message-ID: <1272880626.4126.75.camel@bit>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1
Cc: shim6@ietf.org
Subject: Re: [shim6] Problems with ULID (IP) over longer sessions.
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2010 09:57:29 -0000

On Thu, 2010-04-29 at 16:20 +0200, Alberto García wrote:
> Hi,
> 
> |  -----Mensaje original-----
> |  De: shim6-bounces@ietf.org [mailto:shim6-bounces@ietf.org] En nombre de
> |  Javier Ubillos
> |  Enviado el: miércoles, 28 de abril de 2010 14:21
> |  Para: shim6@ietf.org
> |  CC: Zhongxing Ming
> |  Asunto: [shim6] Problems with ULID (IP) over longer sessions.
> |  
> |  Hi folks.
> |  
> |  Some time ago I heard a discussion about a potential issue with shim6.
> |  That the Upper Layer Identifier (ULID), chosen as the first pair of
> |  locators used in the communication, could cause
> |  problems/confusion/somethingelse when those locators where no longer
> |  used by the hosts. I.e not in the locator lists.
> 
> That's not much precise...

Sorry, I was being deliberately vague.
I'm not sure what the details are, and I did not want to rule some
possibility out due to my own misunderstandings. 

> 
> |  
> |  I'm unsure about the details of what would cause the problem or what the
> |  consequences could be.
> |  
> |  My own first reaction is that if a software believes it's communicating
> |  with an IP (a shim6 ULID), it might try to spawn more sockets/flows to
> |  that IP.
> 
> This is completely reasonable. If a Shim6 context exists for a
> communication, Shim6 will use the locators in use for the existing context,
> even if the ULIDs are no longer locators. 
> RFC 5533 even supports establishing a new session for a ULID which is not a
> valid locator, by using other addresses and including the ULID as an option.
> 
> Don't see here any problem. 

Then I'm confused about how the context is used and re-used.
I thought that each new call to socket() would create a new context,
independently of source/destination address pairs.

> 
> |  
> |  Have this kind of issues been discussed previously on this list? ( I
> |  couldn't find any discussions about it).
> |  Have any one on this list some more detailed thoughts/experience about
> |  what could cause issues?
> |  
> |  I'm asking this because a couple of colleges and I are looking at using
> |  alternative ULIDs which hopefully would be more of a match with session
> |  identifiers/FQDNs or similar.
> 
> Well, security issues for these alternative ULIDs should be carefully
> considered.

Ofcourse :)


Thanks for your reply
// Javier Ubillos