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

[George Jones <gmj@pobox.com>]

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.