Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt

From: Xiaoming Fu <[email-masked]>
Date: Mon, 10 Jul 2006 08:21:53 -0400

Hi Martin, all,

Is it possible for NAT/FW NSIS NSLP to support detection of middlebox 
presence? We find out this feature will be useful in MIP6 FW traversal 
scenarios, as depicted in 
http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis-mip6-fw-04.txt
This could save additional signaling message flows, especially if one 
expects to install multiple rules in a firewall -- if exists -- in a 
particular IP path, e.g., rules for allowing both BU and HoTI messages 
to traverse between the MN and the HA.

Cheers,
Xiaoming

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Next Steps in Signaling Working Group of the IETF.
> 
> 	Title		: NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
> 	Author(s)	: M. Stiemerling, et al.
> 	Filename	: draft-ietf-nsis-nslp-natfw-12.txt
> 	Pages		: 101
> 	Date		: 2006-6-29
> 	
> This memo defines the NSIS Signaling Layer Protocol (NSLP) for
>    Network Address Translators (NATs) and firewalls.  This NSLP allows
>    hosts to signal on the data path for NATs and firewalls to be
>    configured according to the needs of the application data flows.  It
>    enables hosts behind NATs to obtain a public reachable address and
>    hosts behind firewalls to receive data traffic.  The overall
>    architecture is given by the framework and requirements defined by
>    the Next Steps in Signaling (NSIS) working group.  The network
>    scenarios, the protocol itself, and examples for path-coupled
>    signaling are given in this memo.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-nsis-nslp-natfw-12.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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: Martin Stiemerling <[email-masked]>
Date: Mon, 10 Jul 2006 13:38:27 -0400

Hi Xiaoming,

What do exactly refer as "detection of middlebox presence"?  
Basically, the NATFW NSLP, to be precise GIST, is already detecting  
the presence of NATFW NSLP enabled middleboxes.

   Martin

Am 10.07.2006 um 08:21 schrieb Xiaoming Fu:

> Hi Martin, all,
>
> Is it possible for NAT/FW NSIS NSLP to support detection of  
> middlebox presence? We find out this feature will be useful in MIP6  
> FW traversal scenarios, as depicted in http://www.ietf.org/internet- 
> drafts/draft-thiruvengadam-nsis-mip6-fw-04.txt
> This could save additional signaling message flows, especially if  
> one expects to install multiple rules in a firewall -- if exists --  
> in a particular IP path, e.g., rules for allowing both BU and HoTI  
> messages to traverse between the MN and the HA.
>
> Cheers,
> Xiaoming
>
>> To remove yourself from the I-D Announcement list, send a message  
>> to [email-masked] with the word unsubscribe in the  
>> body of the message.  You can also visit https://www1.ietf.org/ 
>> mailman/listinfo/I-D-announce to change your subscription settings.
>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- 
>> sites.txt

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 10 Jul 2006 14:52:57 -0400

Hi Martin,

I mean detection as a separate message exchange in NSLP level before 
signaling desired rules. It can be simply a request-response pair, but 
no real signaling action (install, response or removal of NAT/FW state). 
In principle one could use REA or a new message type for this purpose, 
e.g., for detecting firewalls between MN-HA
- MN sends a REA message towards HA, resulting in a RESPONSE from a 
firewall and an ERROR RESPONSE from the HA. This way, MN will know 
whether there is a FW between them (but not the type).
- alternatively, MN can issue a DETECT (no matter it is called) message 
towards the HA to collect all firewall information, if any, and RESPONSE 
from the HA gives the response to MN. This is similar to what 
diagnostics function covers.

This feature could provide the NI some freedom e.g., choosing multiple 
rules in a single signaling message exchange, or even no NAT/FW 
signaling is needed (if it is clear that no firewall is encountered in 
the data path).

Xiaoming

Martin Stiemerling wrote:
> Hi Xiaoming,
> 
> What do exactly refer as "detection of middlebox presence"?  Basically, 
> the NATFW NSLP, to be precise GIST, is already detecting  the presence 
> of NATFW NSLP enabled middleboxes.
> 
>   Martin
> 
>> presence? We find out this feature will be useful in MIP6  FW 
>> traversal scenarios, as depicted in http://www.ietf.org/internet- 
>> particular IP path, e.g., rules for allowing both BU and HoTI  
>>> [email-masked] with the word unsubscribe in the  body 
>>> of the message.  You can also visit https://www1.ietf.org/

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 10 Jul 2006 14:47:50 -0400

Dear all,

Please find the htmlized diff between -11 and -12 here:

http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-12- 
diff-to-11.html

   Martin

Anfang der weitergeleiteten E-Mail:

> Von: [email-masked]
> Datum: 29. Juni 2006 15:50:02 GMT-04:00
> An: [email-masked]
> Kopie: [email-masked]
> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt
>
> of the message.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> ENCODING mime
> FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 12 Jul 2006 13:17:07 -0400

Hi Xiaoming,

Am 10.07.2006 um 14:52 schrieb Xiaoming Fu:

> Hi Martin,
>
> I mean detection as a separate message exchange in NSLP level  
> before signaling desired rules. It can be simply a request-response  
> pair, but no real signaling action (install, response or removal of  
> NAT/FW state). In principle one could use REA or a new message type  
> for this purpose, e.g., for detecting firewalls between MN-HA

Hmm, that is not the NATFW NSLP behaviour. The REA message would hop- 
by-hop (if any) forwarded to the HA and it would return an error  
response. All other nodes would see this error response and forget  
about the session. There is no separated response of the firewall.

> - alternatively, MN can issue a DETECT (no matter it is called)  
> message towards the HA to collect all firewall information, if any,  
> and RESPONSE from the HA gives the response to MN. This is similar  
> to what diagnostics function covers.
>
> This feature could provide the NI some freedom e.g., choosing  
> multiple rules in a single signaling message exchange, or even no  
> NAT/FW signaling is needed (if it is clear that no firewall is  
> encountered in the data path).

This is talking about two different things here. First, the a  
detection message exchange and aggregation of policy rules into a  
signalling message.

There is basically no need for having a separated detection  
mechanisms, since you run one message exchange just for nothing. You  
suggest to run the detection mechanisms to find out if there is any  
firewall/NAT and afterwards to signal for the desired rules. Isn't it  
better to directly signal for the desired rules? If there is any  
firewall/NAT en route, it is automatically configured as requested.  
Adding a detection mechanism will require another round trip and is  
not saving anything.

Second, the aggregation of policy rules into a signalling message.  
This is not supported by the NATFW NSLP. You can signal for a  
specific flow (which in turn can be quite unspecific) and say it is  
running from A to B with IPv6. This would cover packets of this flow  
out of mobile IP and the latter data traffic.

   Martin

>> Basically, the NATFW NSLP, to be precise GIST, is already  
>> detecting  the presence of NATFW NSLP enabled middleboxes.
>>   Martin
>>> middlebox presence? We find out this feature will be useful in  
>>> MIP6  FW traversal scenarios, as depicted in http://www.ietf.org/ 
>>> internet- drafts/draft-thiruvengadam-nsis-mip6-fw-04.txt
>>> This could save additional signaling message flows, especially  
>>> if  one expects to install multiple rules in a firewall -- if  
>>> exists --  in a particular IP path, e.g., rules for allowing both  
>>> BU and HoTI  messages to traverse between the MN and the HA.
>>>
>>> Cheers,
>>> Xiaoming
>>>
>>>> To remove yourself from the I-D Announcement list, send a  
>>>> message  to [email-masked] with the word  
>>>> unsubscribe in the  body of the message.  You can also visit  
>>>> https://www1.ietf.org/ mailman/listinfo/I-D-announce to change  
>>>> your subscription settings.
>>>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ 
>>>> 1shadow- sites.txt
>>>> ------------------------------------------------------------------- 
>>>> -- ---

---

From: <[email-masked]>
Date: Thu, 13 Jul 2006 10:16:34 -0700

Hi Martin,

>-----Original Message-----
>From: ext Martin Stiemerling [mailto:[email-masked]] 
>Sent: Wednesday, July 12, 2006 10:17 AM
>To: Xiaoming Fu
>Cc: [email-masked]
>Subject: Re: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt
>
>> and RESPONSE from the HA gives the response to MN. This is 
>similar to 
>> what diagnostics function covers.
>>
>detection message exchange and aggregation of policy rules 
>into a signalling message.
>
>mechanisms, since you run one message exchange just for 
>nothing. You suggest to run the detection mechanisms to find 
>out if there is any firewall/NAT and afterwards to signal for 
>the desired rules. Isn't it better to directly signal for the 
>desired rules? If there is any firewall/NAT en route, it is 
>automatically configured as requested.  
>Adding a detection mechanism will require another round trip 
>and is not saving anything.

The MN may want to know if there is any firewall on the path between the
MN's new CoA and the HA and the CN, respectively. If there is no
firewall, then there is no reason using NSLP. Not using NSLP would save
one round trip for each mipv6 signalling and also data connection setup
for each pair of (CoA, HA) and (CoA, CN) connections.

It would probably be preferable to have a firewall detection mechanism
inbuilt into MIPv6, instead of NSLP. 

Gabor

>specific flow (which in turn can be quite unspecific) and say 
>it is running from A to B with IPv6. This would cover packets 
>of this flow out of mobile IP and the latter data traffic.
>
>   Martin
>
>>
>> Xiaoming
>>
>detecting  
>>>>> A New Internet-Draft is available from the on-line 
>Internet- Drafts  
>>>>> directories.
>>>>>    architecture is given by the framework and 
>requirements defined 
>>>>> by
>message  
>>>>> "anonymous" and a password of your e-mail address. After logging 
>>>>> in, type "cd internet-drafts" and then
>>>>>               Below is the data which will enable a MIME 
>compliant 
>>>>> mail reader implementation to automatically retrieve the ASCII 
>>>>> version of the Internet-Draft.
>>>>>

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 31 Jul 2006 11:49:24 +0200

Hi Gabor,

> for each pair of (CoA, HA) and (CoA, CN) connections.

Ok, I see, there is space for some signalling cost saving.

> inbuilt into MIPv6, instead of NSLP.

I'm fine if MIPv6 is providing this or any other mean. Any other mean,
could include the NATFW NSLP, would very likely involve one round
trip to get the information whether there are firewalls or not. Using,
for instance, some probing mechanisms, will eat some round trips too.
If MIPv6 is not providing such information, sending a probe request
of the NATFW NSLP could be a good idea. Either there is are firewalls
in between and they are configured accordingly or there are no firewalls
and the signalling messages just runs through.

   Martin