Protecting Network Resources

                                (Part of a)
                   Report from the IAB Security Workshop

                               February 1994


Protecting Network Resources

  Focus on security inside the network.

    o  Not inside the end-node.

  Called "denial of service."

  In general, it is considered hard.

  It's easy.

    o  (Want to buy a bridge?)


Three step process

  1)  Separate the network traffic into classes.

  2)  Make sure that the bad guys are not in your class.

  3)  Make sure each class gets some resources.

  Q.E.D.


Sorting traffic into classes

  Two issues:

    o  Establishing the class.
    o  Mapping the packets to the class.

  Establishing the class implies (gasp) setup!!

    o  We *are* putting more state in the routers.

  But setup comes in all sorts of forms.

    o  Explicit per-flow setup, e.g., RSVP.
    o  Long-term setup via management interface, e.g., SNMP.

  Setup must be secure.

    o  Presume some high level identifier.
    o  No per-packet performance issues.


Classifying the packet

  Must use fields in the packet to map it to proper class.

  Two methods:

    o  Put a bunch of identifier in the packet, one for each
       relevant point in the path.

    o  Put one identifier in the packet, and teach each relevant 
       point about it.

    o  The latter is the only way to go:  Low level identifier (LLID).

  What is the LLID?

    o  A new field, or
    o  The concatenation of some old fields.
    o  Put that point off.


The setup -- mechanistically

  Someone (sender, receiver, manager):

   o  Gets the LLID.
   o  Binds that LLID to some state in a router.

  Can bind different state to same LLID in different router.

   o  LLID must be "fine-grained."
   o  Trust in LLID must meet the max of requirements.
   o  Duration of LLID must match duration of setup.


Assuring the LLID

  How can we be sure that "bad guys" are not putting false
  LLIDs in packets?

  1)  Hope to goodness.

  2)  Use fields in packet for LLID that cannot be changed 
      without breaking things.

      o  Sometimes works, sometimes not.

  3)  Add an authenticator to the packet.


Hoping to goodness

  We do a lot of that in the Internet.

  Multicast religion -- anyone can send to an m-cast group.

    o  "Wild card" in source.

  Alternative religion -- defend me from bad guys sending to an 
  M-cast group.

    o  List the good guys.
    o  Black-ball the bad guys.

  But if the bad guy puts the wrong source address in an m-cast
  packet...


Break the packet if its wrong

  The most obvious example:

    o  Require all routers to check the source address and discard
       packet if it is bogus.

    o  Filter out bad guys based on source address.

  This takes a lot of thought to see if it actually helps.


Add an authenticator to the packet

  PK-lite (some public key signature over the packet)

    o  Expensive
    o  key pair

  MDx (a one way hash over the packet and a secret)

    o  Cheaper than PK-lite
    o  Shared secret key.
       -  Any router can be a sender (any router can resend, anyway)

  Pick a LLID from a sparse space.

    o  Real cheap.
    o  Any passive wire tapper can be a sender.


Multicast

  Can you say "multicast"?

  It makes the problem harder.

    o  Recipient may not (want to) know all the sources.
    o  So, recipient does not know (in advance) all the LLIDs.
    o  Must the recipient enumerate all the sources?
       -  Bad idea??


What is an LLID?

  1)  The concatenation of fields in the packet.

      o  Src host/port, dest host/port, prot, etc.

  2)  An explicit new field (like a flow id).

      2a) a sparse field for authentication

  It is NOT just an address.  Addresses and LLIDs are different.


Putting packets in classes

  We are building routers that sort packets into classes.

  We are building routers that assign resources to classes.

  Are these the same classes as for security?

  Perhaps not quite.  Issue is granularity of classes.

    o  For good bandwidth sharing, aggregate traffic sources.
    o  For security, separate sources.
    o  Example -- one corrupted source.

  But the right mechanism in the end-node could make the correct
  decisions dynamically.


Why is this possible?

  We are sorting traffic into classes anyway, to support real time
  and other QoS.

  We are proposing routers that allocate resources to classes for 
  the same reason.

  So, at last, the basic building blocks are there.

  What is missing?

    o  (Lots; come to the open meeting...)
    o  Keeping the bad guy from joining the wrong class.