RE: Dropping stealthing from opsec; Anyone for a little I>R<TF work ?

["Smith, Donald" <Donald.Smith@qwest.com>]

Actually firewalls, IDSes, IPSes and other devices could benefit
from stealthing. I agree it should probably be in a separate document.
But it should/would apply beyond the core.

As for the core, I am afraid lots of things will probably break if its'
invisible.
However making it invisible from the OUTSIDE of the network might be 
practical. 

Donald.Smith@qwest.com GCIA
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC
(coffee != sleep) & (!coffee == sleep)

> -----Original Message-----
> From: George Jones [mailto:gmj@pobox.com]
> Sent: Thursday, July 31, 2003 2:11 PM
> To: Florian Weimer; donald.smith@qwest.com
> Cc: Todd MacDermid; opsec@ops.ietf.org
> Subject: Dropping stealthing from opsec; Anyone for a little 
> I>R<TF work
> ?
> 
> 
> I'm going to drop "stealthing" out of the draft as it's a bit to far
> out to be considered BCP.  I spoke with Vern Paxson briefly about it
> at IETF.  He seemed to think the idea might be worth persuing as a
> short term project in the IRTF.
> 
> The basic idea is to make the core invisible/unaddressable beyond the
> edge.  Think 10 addressing the core (or functional equivilant).
> Think no ICMP messages from the core (sent/proxied from the edge ?).
> If it can't be addressed/routed to from beyond the edge, it can't be
> attacked....but what would break ?  Routing ?  Apps that depend on
> ICMP ? IP options processing ?
> 
> The first step is just defining the problem....but we need someone
> to drive it.  I'll probably be seing Vern next week (USENIX).
> Let me know if you're interested in working on this.
> 
> ---George Jones
> 
> 
> On Wed, 25 Jun 2003, Florian Weimer wrote:
> 
> > Todd MacDermid <tmacd@synacklabs.net> writes:
> >
> > > IMO, in an ideal world, all management traffic would take 
> place out
> > > of band. That includes routing table data, active management, SNMP
> > > traps out, everything. The box, to an in-bound 
> perspective, would simply
> > > be a bump in the wire, decrementing TTLs, and silently 
> dropping packets
> > > if they got to zero. (Well, maybe send something back to home base
> > > to look for the routing loop).
> >
> > On the current Internet, the necessity of IP options processing
> > prevents this.  IP options require far more complex processing, and
> > most routers can handle packets with IP options only at a 
> very limited
> > rate.  At least one vendor offers to turn of IP option processing
> > (forwarding the packets simply as if they weren't there), but it
> > breaks some protocols (RSVP? IIRC something in the QoS land), and,
> > more important, existing peering contacts---many of them 
> require that
> > you honour source routing information.
> >
> > (Sorry if this is already addressed in the draft, I haven't 
> found the
> > time to read it carefully yet.)
> >
> >
> 
> 
> 4.1.1 Ability To Stealth Device
> 
>    Requirement. The device MUST provide a mechanism to allow it to
>       become a "black box" as seen from public interfaces.  
> Specifically
>       this means:
> 
>       *  The device SHOULD provide no information about itself (e.g.,
>          system type, HW configuration, operating system 
> type/revision,
>          etc.) beyond the edge of the network (except for what's
>          required to route traffic).
> 
>       *  Edge interfaces SHOULD be visible beyond the network.
> 
>       *  Internal interfaces SHOULD NOT be visible beyond the network
>          (but would be visible within the network).
> 
>       *  It MUST be possible to not only disable all listening ports,
>          but also to prevent them from initiating any traffic (such as
>          ICMP error messages) in response to user activity.
> 
>       While the default configuration of the device SHOULD be 
> fully RFC
>       compliant (including the sending of ICMP messages), it MUST be
>       possible to alter the default configuration such that the device
>       is "stealthed" (i.e., does not send ICMP messages or otherwise
>       respond directly to packets directed to it on non-management
>       interfaces).
> 
>    Justification. This applies primarily in the context of 
> core network
>       infrastructure. A stealthed infrastructure which can not be
>       addressed is less susceptible to direct attack.  Stealthing the
>       core network infrastructure would eliminate the possibility of
>       large classes of attacks and thus increase reliability and
>       availability.
> 
>    Examples. Some specific capabilities important to 
> stealthing include:
> 
>       *  Ability to filter/deny/ignore pings (ICMP echo requests)
> 
>       *  Ability to filter on individual protocol header bits
> 
> 
> 
> Jones, Editor           Expires December 8, 2003              
>  [Page 54]
> 
> Internet-Draft       Network Security Requirements            
>  June 2003
> 
> 
>       *  Ability to control the generation of ICMP messages, including
>          port unreachable and timeouts
> 
>       It MUST be possible to configure each of these settings
>       individually.
> 
>    Warnings. Although some STEALTHING MECHANISMS MAY BE IN 
> VIOLATION OF
>       SOME RFCs, they are desirable/necessary in certain circumstances
>       for security and operational reasons.
> 
> 
>