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

Alberto García <alberto@it.uc3m.es> Tue, 04 May 2010 08:52 UTC

Return-Path: <alberto@it.uc3m.es>
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 E94C73A68F8 for <shim6@core3.amsl.com>; Tue, 4 May 2010 01:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.783
X-Spam-Level:
X-Spam-Status: No, score=-3.783 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 72wAIMaYYGjO for <shim6@core3.amsl.com>; Tue, 4 May 2010 01:52:29 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 009363A6956 for <shim6@ietf.org>; Tue, 4 May 2010 01:52:27 -0700 (PDT)
X-uc3m-safe: yes
Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 10253B4A47E; Tue, 4 May 2010 10:52:09 +0200 (CEST)
From: =?iso-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
To: "'Javier Ubillos'" <jav@sics.se>
References: <1272457259.4126.63.camel@bit> <DD1BCF0217394718A07CF6EFF8493B0A@bombo> <1272880626.4126.75.camel@bit>
Date: Tue, 4 May 2010 10:52:08 +0200
Message-ID: <ED8FDA38530C4C57AB9FCE0AC2E109FE@bombo>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <1272880626.4126.75.camel@bit>
Thread-Index: Acrqpv1hXG+5+Vs/SRmtNAmPbBfNqQAv3taw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17362.006
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: Tue, 04 May 2010 08:52:30 -0000

Hi,

|  -----Mensaje original-----
|  De: Javier Ubillos [mailto:jav@sics.se]
|  Enviado el: lunes, 03 de mayo de 2010 11:57
|  Para: Alberto García
|  CC: jav@sics.se; shim6@ietf.org
|  Asunto: RE: [shim6] Problems with ULID (IP) over longer sessions.
|  
|  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.

This is discussed in RFC 5533, D.1. "Context Granularity"

Regards,
Alberto

|  
|  >
|  > |
|  > |  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