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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 1 Feb 2006 10:35:29 -0000

hi all,

i can imagine interesting ICMP policy rules like
- i want to be able to ping other people
- i want to allow other people to ping me
- i want to be able to do traceroute (receive timex)

note that the first ping case implies outgoing type=8 and incoming
type=0 and the second ping case implies the opposite. (the ICMP
code - in rfc792 speak - is 0 in all cases.) certainly i can imagine
wanting to be able to signal multiple types/codes in a coordinated
way (and differently for incoming/outgoing packets).

in other cases, the handling of ICMP messages is much more dependent
on existing flows (other firewall state); e.g. "i'd like to receive
ICMP unreachable/timex messages but only about flows which exist".
(in fact, the traceroute case probably comes into this category also.)
the implication of that would be that the firewall had to apply the
policy based on the ICMP payload (which contains the flow packet header)
and not the ICMP header itself.

is there an obvious set of requirements for how to configure to
configure firewalls for ICMP? the midcom documents seem 'light'
on the ICMP front. 

r.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Henning Peters
> Sent: 31 January 2006 18:01
> To: Martin Stiemerling
> Cc: nsis
> Subject: Re: [NSIS] NATFW NSLP: Signaling for ICMP policy rules
> 
> 
> 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.
> 
> How does the change affect NAT? As this might have impacts on 
> the (de)multiplexing behavior of NATs.
> 
> 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.
> 
> > - 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?
> 
> 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
> 

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

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 01 Feb 2006 13:24:05 +0000

Hi.

v6ops has work in progress on this issue.  I am editing a proposed BCP 
on ICMP filtering for IPv6 which is a bit more complex than the v4 case.
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt

The next version (due out shortly) will provide an Appendix with example 
filtering rules.  For looking at the v4 case it might be useful to 
review either Appendix A or the previous version of this document 
(available (e.g.) as 
http://www.watersprings.org/pub/id/draft-davies-v6ops-icmpv6-filtering-bcp-00.txt) 
which was structured  differently, discussing the messages individually 
rather than looking at their the required treatment in the firewall.

The discussion of why ICMP messages need to be passed or dropped 
provides requirements: the v4 case could be derived quite easily but is 
more about administrative policy than the v6 case, where the network 
will assuredly break if some ICMPv6 messages are dropped 
inappropriately, and the size of the addressing space makes ICMP-based 
scanning less attractive to hackers than for v4 networks.

A major consideration for ICMP filtering is that many error messages are 
what are classified as 'any-to-end' as the source address can be any 
router on the path   Sophisticated filtering needs to look at the 
addresses of the embedded errored packet, as mentioned by Robert, but 
that depends on the capabilities of the firewall.

Regards,
Elwyn

---

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

Robert, all,

> - i want to be able to do traceroute (receive timex)

Right, plus the case(s) I have described in my answer to Henning,
when the firewall is letting everything in by default (default-to- 
allow).
In these cases you are blocking specifically  ICMP traffic.

> way (and differently for incoming/outgoing packets).

This goes along with Hennig's thoughts on aggregating different ICMP
codes in a single message. Taking your example, I assume this will
require two signaling sessions (outbound (type=8) and inbound (type=0))
to get the ICMP request/reply running. Probably, there is not much to
aggregate for outbound/inbound pairs, but saying "I want codes {0,8}".

> and not the ICMP header itself.

I see this separately from the ICMP policy rule discussion, but it is an
interesting issue. Until now, I have assumed this ICMP messages
coupled to some other firewall/NAT state (e.g., TCP, UDP, etc) as
you have said. Whenever the middlebox is able to have this coupling
(like pf of OpenBSD) it will automatically do so, even for NSLP  
signaling
TCP,UDP, etc flows. This behaviour is the desired one, since having ICMP
messages for TCP sessions (and others too) makes life much easier.

There is no way out, if the middlebox cannot do this coupling or the
sysadmin does not like it for any reason.

Adding a flag (or similar thing) saying please let for this TCP, UDP,  
etc
flow ICMP messages through as well is one possibility. But
whenever this signaling message is hitting a middlebox that does not
support this type of ICMP handling, an error response must be sent back.
This is going to stop the whole signalling and will make the NATFW NSLP
signalling less generic, i.e., it less "fire and forget" as it is today.

> configure firewalls for ICMP? the midcom documents seem 'light'

Probably, there is such requirement but I'm not aware of. In MIDCOM
we assumed the same as for NSIS: If the middlebox can do so, it will
do so. If the middlebox cannot do so, it won't do it.

I see this "coupled ICMP" should go into the appendix A "Firewall and  
NAT
Resources". I have added it to issue 26:

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

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 1 Feb 2006 15:25:34 +0100

Elwyn,

Am 01.02.2006 um 14:24 schrieb Elwyn Davies:

> Hi.
>
> v6ops has work in progress on this issue.  I am editing a proposed  
> BCP on ICMP filtering for IPv6 which is a bit more complex than the  
> v4 case.

Good to know about this document.

>
> The next version (due out shortly) will provide an Appendix with  
> example filtering rules.  For looking at the v4 case it might be  
> useful to review either Appendix A or the previous version of this  
> document (available (e.g.) as http://www.watersprings.org/pub/id/ 
> draft-davies-v6ops-icmpv6-filtering-bcp-00.txt) which was  
> structured  differently, discussing the messages individually  
> provides requirements: the v4 case could be derived quite easily  
> but is more about administrative policy than the v6 case, where the  
> network will assuredly break if some ICMPv6 messages are dropped  
> inappropriately, and the size of the addressing space makes ICMP- 
> based scanning less attractive to hackers than for v4 networks.
>
> A major consideration for ICMP filtering is that many error  
> messages are what are classified as 'any-to-end' as the source  
> address can be any router on the path   Sophisticated filtering  
> needs to look at the addresses of the embedded errored packet, as  
> mentioned by Robert, but that depends on the capabilities of the  
> firewall.

I have to second, that the ICMP filtering depends on the capabilities  
of the firewall.

   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.
>>>
>>> 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.
>>>
>>>
>>>> - For REA and REA-F, the "Data Terminal Information Object" must  
>>>> be modified to carry the ICMP code.
>>>>
>>> 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
>>>
>>>
>>>> group to add features to the NATFW NSLP, as said in my email  
>>>> sent before.
>>>>
>>>> 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.
>>>>
>>>> - 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.
>>>>