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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 1 Feb 2006 14:57:39 -0000

hi,

replies to a snipped subset:

> > 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).
> 
> 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}".

i could say {0 in, 8 out} or {0 out, 8 in} - if i regard there as
being a difference between being able to ping and being pingable.
(and it's *type* not *code*!)

for the other types of messages, it may be that there is no point
in there being anything other than a default policy associated with
the state of the corresponding flow, so there is nothing to signal.
that would be a reasonable point of view. i think the analysis needs
to be done [maybe Elwyn has already done it ;-) ]

r.

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

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 01 Feb 2006 15:33:55 +0000

The considerations for error messages and info messages in ICMP (both 
versions) are different.

To state the fairly obvious:
Error messages need to be associated with another flow (which could of 
course  be an ICMP info flow!)
Info messages are part of some sub-protocol of ICMP

For error messages, the prospective errored flow *has* to do the setup 
for the error messages - you can't expect an arbitrary router to set up 
the pinholes before sending an ICMP!

Just talking about the ping or traceroute info case, an echo request 
needs to set up a a one time pinhole for the echo reply - basically like 
TCP or UDP replies and this is mostly handled automatically today.  The 
question is, I guess, should the flow specification liaise with this set 
up of the return path (by having a flag or some such) or should we 
expect to get the return path set up separately?  Asymmetric routing?

Elwyn

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 2 Feb 2006 08:55:38 +0100

Hi,

> i could say {0 in, 8 out} or {0 out, 8 in} - if i regard there as

Yes, you could says so in the case you are signaling in proxy mode
(for instance, CREATE-PROXY) and with the REAs.

I will write some text for the ICMP support and send it to the list for
comments.

> (and it's *type* not *code*!)

It's type. I got it wrong when typing it. Thanks!

> the state of the corresponding flow, so there is nothing to signal.

I share your view.

> to be done [maybe Elwyn has already done it ;-) ]

I have no analysis at my hands, but I know from my past experience of
firewall/NAT kernel hacking that either the box can do ICMP state
to flow state matching or there is not much to configure.

Cheers,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 2 Feb 2006 09:04:02 +0100

Elwyn,

Am 01.02.2006 um 16:33 schrieb Elwyn Davies:

> The considerations for error messages and info messages in ICMP  
> (both versions) are different.
>
> Error messages need to be associated with another flow (which could  
> of course  be an ICMP info flow!)
> For error messages, the prospective errored flow *has* to do the  
> setup for the error messages - you can't expect an arbitrary router  
> to set up the pinholes before sending an ICMP!
>
> Just talking about the ping or traceroute info case, an echo  
> request needs to set up a a one time pinhole for the echo reply -  
> basically like TCP or UDP replies and this is mostly handled  
> automatically today.  The question is, I guess,

The same of automatic state setup for the return traffic holds true  
for ICMP (originated as ICPM) as well. Given you have a modern  
middlebox, for which I count all the open source implementations  
(IPTables, PF, IPFW, IPF). I assume other vendors have the same  
functionality.

> should the flow specification liaise with this set up of the return  
> path (by having a flag or some such) or should we expect to get the  
> return path set up separately?  Asymmetric routing?

In my opinion, each path must be set up independently when we are in  
end-to-end NSIS operations, since we have a path-coupled protocol.  
This is when both ends support NSIS NATFW NSLP. In the case of only  
one side having NSIS NATFW support, you can use the proxy mode to set  
up both paths from one end. This holds true for the case, when you  
like to configure your local middleboxes only. So there is no extra  
flag needed anymore.

   Martin

>>>> 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 -
>>>> to be able to signal multiple types/codes in a coordinated 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}".
>>>
>>