Re: [BEHAVE] working group status update

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Sun, 03 May 2009 20:12 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB673A6D76 for <behave@core3.amsl.com>; Sun, 3 May 2009 13:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.374
X-Spam-Level: *
X-Spam-Status: No, score=1.374 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
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 RAkDXgTDM7cT for <behave@core3.amsl.com>; Sun, 3 May 2009 13:12:18 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id A24923A6CC7 for <behave@ietf.org>; Sun, 3 May 2009 13:11:55 -0700 (PDT)
Received: from [192.168.1.194] (p508FFE3D.dip.t-dialin.net [80.143.254.61]) by mail-n.franken.de (Postfix) with ESMTP id 32FE81C0B4629; Sun, 3 May 2009 22:13:17 +0200 (CEST)
Message-Id: <450DA87F-0C24-4940-A84D-44056DA727EF@lurchi.franken.de>
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
To: Fred Baker <fred@cisco.com>
In-Reply-To: <956E26DC-D729-4C2F-A56F-288843099146@cisco.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.4)
Date: Sun, 03 May 2009 22:13:21 +0200
References: <0e0f01c9c9c9$f94e7d90$c5f0200a@cisco.com> <956E26DC-D729-4C2F-A56F-288843099146@cisco.com>
X-Mailer: Apple Mail (2.930.4)
Cc: Behave WG <behave@ietf.org>, Behave Chairs <behave-chairs@tools.ietf.org>
Subject: Re: [BEHAVE] working group status update
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2009 20:12:19 -0000

Hi Fred,

draft-ietf-tsvwg-port-randomization is not a problem for
SCTP, since it talks about choosing the port for an
transport layer endpoint.

If middleboxes change the port number, it breaks SCTP
in multihoming scenarios, since the port number is not
per path, but per end-point. If you are using multiple
paths and you have NAT boxes on the different paths changing
the port number, they all need to do the same change!
This requires therefore the synchronization of all these
NAT boxes, which is very hard (I would even say impossible)
to achieve.

Therefore the NAT solution we propose does not change the
port number.

So the solutions described below which change the port number
will *NOT* be able to support multihomed SCTP associations.

Best regards
Michael

On May 2, 2009, at 12:31 AM, Fred Baker wrote:

>
> On Apr 30, 2009, at 12:29 PM, Dan Wing wrote:
>
>> * no update on SCTPNAT.
>
> by which I assume you mean:
> http://tools.ietf.org/html/draft-ietf-behave-sctpnat
>  "Stream Control Transmission Protocol (SCTP) Network Address  
> Translation",
>  Randall Stewart, Michael Tuexen, Irene Ruengeler, 16-Feb-09,
>  <draft-ietf-behave-sctpnat-01.txt>
>
> Something the working group might want to wonder about...
>
> We have recently seen several drafts that talk about using port  
> numbers to differentiate among multiple systems using the same IP  
> address. The different systems get different port ranges.
>
> http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-ipaddr-assign
>  "Port Restricted IP Address Assignment", Gabor Bajko, Teemu  
> Savolainen,
>  3-Nov-08, <draft-bajko-v6ops-port-restricted-ipaddr-assign-02.txt>
>
> http://tools.ietf.org/html/draft-boucadair-dhc-port-range
>  "DHCP Options for Conveying Port Mask and Port Range Router IP  
> Address",
>  Mohammed Boucadair, Jean-Luc Grimault, Pierre Levis, Alain  
> Villefranque,
>  29-Oct-08, <draft-boucadair-dhc-port-range-01.txt>
>
> http://tools.ietf.org/html/draft-boucadair-port-range
>  "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion",
>  Mohammed Boucadair, Pierre Levis, Gabor Bajko, Teemu Savolainen, 30- 
> Jan-09,
>  <draft-boucadair-port-range-01.txt>
>
> http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization
>  "Port Randomization", Michael Larsen, Fernando Gont, 11-Mar-09,
>  <draft-ietf-tsvwg-port-randomization-03.txt>
>
> As I understand the SCTP NAT draft, it has no problem with people  
> changing their addresses, but really hopes they won't change their  
> ports. How do these two lines of reasoning fit together?
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>