Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules

From: Martin Stiemerling <[email-masked]>
Date: Wed, 1 Feb 2006 14:59:39 +0100

Hi Henning, all,

by the way this issue has made it in the NATFW NSLP issue tracker:

https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue60

More inline.

Am 31.01.2006 um 19:00 schrieb Henning Peters:

> Hi Martin,
>
> can you specify an application for the signaling of ICMP policy rules?
> Don't ICMP messages already refer to a certain data flow? I don't  
> see a
> reason why a firewall or NAT should deny or drop them. And if they are
> configured to behave like this, a different configuration might not be
> wanted in the first place?! But probably the 3GPP2 guys already  
> have sth.
> particular in mind that I am currently not seeing.

I do not know about the application 3GPP2 has in mind but in general  
it is
a good idea to allow or deny ICMP messages in middleboxes. Focussing
on the 3GPP2 case first:

3GPP2 assumes only firewalls in their network ('cause it is IPv6) and  
these
firewalls are default-to-allow. All traffic is allowed to go in and  
out unhindered.
A 3GPP2 mobile terminal will use the NATFW NSLP to request the blocking
of particular data traffic coming out of the Internet towards the  
terminal, causing
costs to the terminal user (it's all running wireless and you pay  
byte by byte, or
feel directly when the link is filled with garbage). An unwanted  
traffic can be
ICMP ECHO request messages sent by some to your terminal, in the worst
case flooding your wireless link. This kind of traffic may not come  
from a single
source, so that blocking of a single IP address would not solve the  
issue. Therefore,
you will request to block all ICMP traffic in your upstream firewalls  
for any host,
but let TCP and UDP through.

Second, for hosts behind firewalls running default-to-deny and NATs.
a) The host wants to send ICMP messages to other hosts but does not
have a transport layer connection/state on the firewall, i.e., you  
ping a
host to see if it is alive. In this case, the NATFW NSLP will request  
the
downstream firewalls to open for ICMP traffic. This would bring back
the old-style ICMP diagnosis to some people that are located behind
very strictly configured firewalls and NATs

b) A server located behind a NAT/firewalls running some sort of service,
for instance, FTP, would like to be reachable for ICMP ECHO REQUEST
packets. Some people running servers still like them to be reachable by
ICMP, since this sometimes the only way to test remotely if the server
is up and running.

>
> How does the change affect NAT? As this might have impacts on the
> (de)multiplexing behavior of NATs.

Right, but either the NAT can multiplex ICMP packets or it cannot.  
But this
is not something the NATFW NSLP can change. For instance, OpenBSD's
pf as NAT can do ICMP demultiplexing. Some other NATs probably can't do.

>
> If adding a new code object to NAT/FW NSLP, allowing multiple codes  
> in a
> single message might be valuable to save unnecessary signaling  
> traffic.

Could by a good way to aggregate. I have thing about it.
Do you mind adding this to the issue 60 in the tracker?

>
>> - For REA and REA-F, the "Data Terminal Information Object" must be
>> modified to carry the ICMP code.
>
> Why do you want to have a new code object _and_ an additional code  
> field
> in the DTInfo object? Wouldn't it make sense to set the protocol to  
> ICMP
> in DTInfo protocol field and add the new ICMP code object regularly?

Yes, good idea.
Do you mind adding this to the issue 60 in the tracker, so it does  
not get forgotten?

Thanks,

   Martin

>
> Henning
>
>
> Martin Stiemerling sagte Di, 31.01.2006, 13:10:
>> Dear all,
>>
>> The NSIS working group has received some request from a 3GPP2 working
>> group to add features to the NATFW NSLP, as said in my email sent
>> before.
>>
>> One of the features is the ability to signaling for ICMP policy
>> rules. Up to now, the NATFW NSLP can signal for IP only, TCP, and UDP
>> flows by using the NTLP path-coupled MRM and the LE-MRM. It's
>> possible to signal for ICMP flows by using the PC-MRM and setting the
>> 'protocol' field to 'ICMP'. However, it is currently not possible to
>> specify anything beyond that, for instance, the ICMP code to be used.
>>
>> Here is the proposed extension to the NATFW NSLP:
>> - Add a new object 'icmp' that carries solely the ICMP code
>> - This object can be included in CREATE messages where the NTLP is
>> carrying a MRM with IP addresses only, protocol set to ICMP.
>> - For REA and REA-F, the "Data Terminal Information Object" must be
>> modified to carry the ICMP code.
>>
>> This proposed change does *NOT* require any change to the NTLP but
>> *ONLY* to the NATFW NSLP.
>>
>> Any view on this?
>>
>> Thanks,
>>
>>    Martin_______________________________________________
>> 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: Elwyn Davies <[email-masked]>
Date: Wed, 01 Feb 2006 14:30:20 +0000

Two extra points come to  mind with regard to ICMP filtering:
- In many cases (e.g., ping responses and error messages), what would be 
ideal would be to allow exactly one error message relevant to the flow 
or ping response if the firewall is capable of counting (actually 
counting to 1 is easy - just destroy the rule after it has been invoked 
;-)  ).
- Some of the rules are not related to a specific flow but really are 
administrative setups targeted on a particular firewall.  Do we envisage 
using NATFW NSLP for this?

In practice, you would have to install quite a number of filters per 
data flow to cope with all the ICMP messages that you might want to 
allow in response to a particular data flow setup.  There may be 
performance issues here.  Maybe what is needed is a way to create a 
filter set rather than a simple tuple for one filter.

Regards,
Elwyn

Martin Stiemerling wrote:

>> Don't ICMP messages already refer to a certain data flow? I don't  see a
>> wanted in the first place?! But probably the 3GPP2 guys already  have 
>> sth.
>> single message might be valuable to save unnecessary signaling  traffic.
>
>
>------------------------------------------------------------------------
>

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 1 Feb 2006 17:57:00 +0100

Am 01.02.2006 um 15:30 schrieb Elwyn Davies:

> - In many cases (e.g., ping responses and error messages), what  
> would be ideal would be to allow exactly one error message relevant  
> to the flow or ping response if the firewall is capable of counting  
> (actually counting to 1 is easy - just destroy the rule after it  
> has been invoked ;-)  ).

This could be done on the middlebox. But in some cases you will  
receive more than one reply and you could use this for diagnosis as  
well. The NI could do the same, simply tear the session down after  
having received one reply, if desired. This will keep the protocol  
and the implementation lightweight.

> - Some of the rules are not related to a specific flow but really  
> are administrative setups targeted on a particular firewall.  Do we  
> envisage using NATFW NSLP for this?

Are you referring to management of middleboxes? If yes, than this is  
out of scope for the NATFW NSLP. Long-term administrative setups are  
done by CLI or some other management interface.

>
> In practice, you would have to install quite a number of filters  
> per data flow to cope with all the ICMP messages that you might  
> want to allow in response to a particular data flow setup.  There  
> may be performance issues here.  Maybe what is needed is a way to  
> create a filter set rather than a simple tuple for one filter.

I do not think so. ICMP messages belonging to a particular data flow  
are not configurable by the NATFW NSLP. They are subject to the local  
middlebox implementation, how the NATFW daemon feeds rules into the  
engines, and what the administrator thinks about his allowed  
configuration. My point is just about independent ICMP packets, e.g.,  
for ping or traceroute applications.

Regards,

   Martin

>> I do not know about the application 3GPP2 has in mind but in  
>> general  it is
>> 3GPP2 assumes only firewalls in their network ('cause it is IPv6)  
>> and  these
>> firewalls are default-to-allow. All traffic is allowed to go in  
>> and  out unhindered.
>> case flooding your wireless link. This kind of traffic may not  
>> come  from a single
>> source, so that blocking of a single IP address would not solve  
>> the  issue. Therefore,
>> you will request to block all ICMP traffic in your upstream  
>> firewalls  for any host,
>> have a transport layer connection/state on the firewall, i.e.,  
>> you  ping a
>> host to see if it is alive. In this case, the NATFW NSLP will  
>> request  the
>> Right, but either the NAT can multiplex ICMP packets or it  
>> cannot.  But this
>>> If adding a new code object to NAT/FW NSLP, allowing multiple  
>>> codes  in a
>>> Why do you want to have a new code object _and_ an additional  
>>> code  field
>>> in the DTInfo object? Wouldn't it make sense to set the protocol  
>>> to  ICMP
>> Do you mind adding this to the issue 60 in the tracker, so it  
>> does  not get forgotten?
>>
>> Thanks,
>>
>>   Martin
>>
>>>
>>> Henning
>>>
>>>

---

From: "Henning Peters" <[email-masked]>
Date: Wed, 1 Feb 2006 19:18:43 +0100 (CET)

Hi,

just to avoid misunderstandings: the ICMP field is called "type" as
already stated in Roberts mail. The ICMP "code" field is its subtype. We
are currently talking about the type, are we? ;)

Henning

[...]
> - Add a new object 'icmp' that carries solely the ICMP code
[...]

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 1 Feb 2006 23:08:47 +0100

> are currently talking about the type, are we? ;)

Yes, it is the 'type'!

Sorry for the confusion, I know it is type and was switching to code  
because of my personal laziness

   Martin

---

From: [email-masked]
Date: Thu, 2 Feb 2006 09:48:07 -0800

Hello,

The requirement in 3GPP2 came from real use case scenarios. What
currently happens in wireless networks is, that in the IPv4 address
space ICMP traffic is ongoing (either initiated by users or e.g.
routers). As also pointed out in
http://www.watersprings.org/pub/id/draft-davies-v6ops-icmpv6-filtering-b
cp-00.txt, ICMP is a useful auxiliary in IPv4, but life could go on fine
without it too. 

ICMP traffic hurts wireless mobiles in two ways: one ICMP may wake up a
mobile, thus sending periodic ICMP to it may result in the battery going
flat even if the mobile is not used. Also, a ping -t type of traffic
targeted to the mobile would not only harm the mobile but the wireless
network operator too (by consuming a significant % of the available
resource).

The firewalls in 3GPP2 are regular 'deny by default' FWs.  But when a
pinhole is opened, that can allow unwanted ICMP traffic too. So what
3GPP2 wanted  was something similar to 'open a pinhole to my IP address
and allow everything except ICMP'. For IPv4 this seems trivial as a rule
saying 'deny ICMP' would solve the issue. And the other way around, when
pinholes are opened by applications making use of ICMP (e.g. SIP), then
ICMP traffic should be allowed.
The use cases described by Robert could also be valid.

For ICMPv6 things are not so simple. The mobile should not receive
unwanted ICMPv6, but its connection should not be altered, i.e. ICMPv6
messages that are needed to maintain the functioning of the network
should not be dropped while the rest could.

The granularity of the rule to be defined for ICMP is a tradeoff. We
need some granularity, but too much of it would be an overhead and
burden.

Gabor

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Henning Peters
>Sent: Tuesday, January 31, 2006 10:01 AM
>To: Martin Stiemerling
>Cc: nsis
>Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules
>
>Hi Martin,
>
>Don't ICMP messages already refer to a certain data flow? I 
>don't see a reason why a firewall or NAT should deny or drop 
>them. And if they are configured to behave like this, a 
>different configuration might not be wanted in the first 
>place?! But probably the 3GPP2 guys already have sth.
>How does the change affect NAT? As this might have impacts on 
>the (de)multiplexing behavior of NATs.
>
>codes in a single message might be valuable to save 
>unnecessary signaling traffic.
>
>code field in the DTInfo object? Wouldn't it make sense to set 
>the protocol to ICMP in DTInfo protocol field and add the new 
>ICMP code object regularly?
>
>Henning
>
>
>> One of the features is the ability to signaling for ICMP 
>policy rules. 
>> Up to now, the NATFW NSLP can signal for IP only, TCP, and UDP flows 
>> by using the NTLP path-coupled MRM and the LE-MRM. It's possible to 
>> signal for ICMP flows by using the PC-MRM and setting the 'protocol' 
>> field to 'ICMP'. However, it is currently not possible to specify 
>> anything beyond that, for instance, the ICMP code to be used.
>>