Re: [NSIS] NATFW NSLP; using REA mode for blocking data flows

Ali Fessi <ali.fessi@uni-tuebingen.de> Wed, 17 May 2006 09:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIFi-0000zc-QB; Wed, 17 May 2006 05:23:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIFh-0000zX-Kc for nsis@ietf.org; Wed, 17 May 2006 05:23:33 -0400
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgIFf-0004g5-TH for nsis@ietf.org; Wed, 17 May 2006 05:23:33 -0400
Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 994B211C; Wed, 17 May 2006 11:23:30 +0200 (MST)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14966-05; Wed, 17 May 2006 11:23:28 +0200 (DFT)
Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4A65D115; Wed, 17 May 2006 11:23:28 +0200 (MST)
Message-ID: <446AEB90.9060609@uni-tuebingen.de>
Date: Wed, 17 May 2006 11:23:28 +0200
From: Ali Fessi <ali.fessi@uni-tuebingen.de>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Martin Stiemerling <stiemerling@netlab.nec.de>
Subject: Re: [NSIS] NATFW NSLP; using REA mode for blocking data flows
References: <4443F69F.9000708@uni-tuebingen.de> <4D167603-348A-48BA-AB2E-634153ACF4F6@netlab.nec.de>
In-Reply-To: <4D167603-348A-48BA-AB2E-634153ACF4F6@netlab.nec.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: nsis <nsis@ietf.org>
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org

Hi Martin,

just a suggestion for the name of the REA message:

in some earlier versions of the draft you had a UCREATE message 
(Upstream Create).

I think UCREATE would fit better, since:

- in case the data receiver (DR) is behind a firewall, UCREATE creates a 
firewall pinhole to receive the data

- in case DR is behind a NAT it creates a NAT binding with a external 
address

- in case DR want to block some unwanted traffic UCREATE creates a 
firewall rule to block this data traffic

So the naming UCREATE fits well in all cases.

My concerns with REA is that in few years any historical reasons for 
choosing this name will not be obvious and the name will be rather 
inappropriate.

Especially using REA for blocking incoming data traffic is confusing.

cheers,
ali



Martin Stiemerling wrote:
> Hi Ali,
> 
> I have been away on vacation and now catching up with the emails.
> 
> The name REA (RESERVE-EXTERNAL-ADDRESS) has its roots in the time of  
> reserving a public reachable IP address at a NAT. The semantics of  this 
> REA message has changed over time and does now include firewalls  as well.
> 
> We have had some proposals for a new name of REA, but none of them  
> could ultimately convince. My current reading for REA is, that in any  
> case (NAT or firewall) you do reserve the external reachable IP  
> address. For the NAT case, this is the public reachable IP address;  for 
> the firewall case this is the globally routable IP address of the  host 
> (or one of these addresses). Both "types" of addresses are  external 
> addresses.
> 
> However, if somebody has a good proposal for another name describing  
> the semantics in a better way -- send it NOW. (yet another naming  
> contest :-)
> 
>   Martin
> 
> Am 17.04.2006 um 22:12 schrieb Ali Fessi:
> 
>> Hi all,
>>
>> the REA mode (Reserving External Address) was originally called REA  
>> mode because it is used by hosts behind a NAT to reserve a publicly  
>> reachable IP address (and port number).
>>
>> Now, the REA mode is also used by hosts behind a firewall to signal  
>> to a firewall for blocking data traffic.
>>
>> Although from functionality point of view, it might be fine to use  
>> the same name for these two similar functionalities; but from  
>> terminology point of view, this is rather confusing to signal for  
>> blocking data traffic and call it "REA mode".
>>
>> So, why not use a different name that matches more the  functionality, 
>> something like "BLOCK mode" for example?! This would  make it easier 
>> for the readers to understand.
>>
>> Cheers,
>> Ali
>> -- 
>> Ali Fessi
>> University of Tuebingen, Germany
>>
>> _______________________________________________
>> nsis mailing list
>> nsis@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nsis


-- 
Ali Fessi
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen, Germany
Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220
EMail: ali.fessi@uni-tuebingen.de
Web: http://net.informatik.uni-tuebingen.de/~fessi/

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis