Subject: RE: Problem of blocking ICMP packets

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 16 Jun 2004 23:00:23 -0400

> >  "As Figure 5 shows, in many cases no connection was 
 > established when
 > >  the [IP] Record Route Option or the [IP] Timestamp Option 
 > was included in 
 > >  the SYN packet.  When IP Option X [a new IP Option; e.g., 
 > QuickStart]
 > >  is included in the SYN segment, the connection was not established
 > >  to over 70% of the web servers tested.  This does not 
 > bode well for
 > >  the deployment of new IP options in the Internet."
 > 
 > It implies that mobile IPv6 depndeing on routing header
 > may not work.

=> This statement is true IFF people assume that 
Record Route Option == Routing header type 2 used for MIPv6.
Of course that is not true because there are security
implications for using routing header type 2 and an
assumption that the end node will verfiy such use. Moreover,
RH type 2 will not impact other nodes behind the FW
if used in a malicious way. All this points to two things:
1. The two are not equivalent, and
2. We need to make sure that network admins know (1). 

Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

From: Jean-Jacques Puig <[email-masked]>
Date: Thu, 17 Jun 2004 10:11:23 +0200

> 2. We need to make sure that network admins know (1).

But (2) is the same issue with ICMP filtering ! So, I would not trust
admins to tell the difference.

Earlier in this thread were envisioned signaling alternatives: in-band,
IP options, out-band (either ICMP or stg else).

In-band signaling may be appropriate in most cases, if the actual
'signal' is closely related to the protocol. Besides current trend in
firewalls user interfaces let expect that the relation between the
signaling part of the protocol and the protocol itself would be
correctly underlined or automatically managed in such a case.

Out-band signaling and IP options are prone to be modified or generated
by routers; but this is sometimes what is expected ! Better set a bit in
IP header than directly in the transport for ECN. The issue is, IMHO,
that the relation between out-band or IP options and higher layer
protocols is often unknown to admins and not presented in a suitable way
or checked by firewalls user interfaces.

Design is not the issue, I think. Current schemes would actually work
correctly, if only network admins knew.

Yet, we cannot expect admins to learn about each possible combination.
This is where part of the firewall product quality may lay: managing
automatically relations (and noticing about these to admins) or at least
displaying a huge warning when checking rules according to a set of best
current practices. And these are best practices because in some cases
firewalls just don't have adequate information to make a logical
decision.

Three paths:
	- Asking for better fw products
	- Teaching admins (hopeless ?), especially about the grey color
	  somewhere between black and white.
	- Finding out the failing devices, looking up in the whois, picking
	  the phone, flaming them :)

-- 
Jean-Jacques Puig
[homepage] http://www-lor.int-evry.fr/~puig/