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

From: Martin Stiemerling <[email-masked]>
Date: Thu, 4 May 2006 15:57:01 +0200

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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Ali Fessi <[email-masked]>
Date: Wed, 17 May 2006 11:23:28 +0200

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

-- 
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: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 22 May 2006 16:14:11 +0200

Hi Ali,

Thanks for the suggestion. I am in dislike about UCREATE, because the  
current REA and CREATE have basically two very different semantics.  
CREATE is creating a path from the sender to the receiver, where REA  
is solely reserving the resources for a CREATE.

The "upstream" part sounds reasonable for a new name, but Robert has  
pointed out that this term might be confusing for the reader. The  
direction might not be obvious...

So we still need a new name :-) Any other suggestions?

   Martin

Am 17.05.2006 um 11:23 schrieb Ali Fessi:

> - 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
>
> 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.
>
>> 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
>>> 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".
>>>
>>> functionality, something like "BLOCK mode" for example?! This  
>>> would  make it easier for the readers to understand.
>>>
>>> Cheers,
>>> Ali
>>> -- 
>>> Ali Fessi