and the port number for that protocol.  Firewalls can be used with
   the Authentication Header regardless of whether that firewall is
   party to the appropriate Security Assocation, but a firewall that is
   not party to the applicable Security Association will not normally be
   able to decrypt an encrypted upper-layer protocol to view the
   protocol or port number needed to perform per-packet filtering OR to
   verify that the data (e.g., source, destination, transport protocol,
   port number) being used for access control decisions is correct and
   authentic.  Hence, authentication might be performed not only within
   an organisation or campus but also end to end with remote systems
   across the Internet.  This use of the Authentication Header with IP
   provides much more assurance that the data being used for access
   control decisions is authentic.

   Organisations with two or more sites that are interconnected using
   commercial IP service might wish to use a selectively encrypting
   firewall.  If an encrypting firewall were placed between each site of
   a company and the commercial IP service provider, the firewall could
   provide an encrypted IP tunnel among all the company's sites.  It
   could also encrypt traffic between the company and its suppliers,
   customers, and other affiliates.  Traffic with the Network
   Information Center, with public Internet archives, or some other
   organisations might not be encrypted because of the unavailability of
   a standard key management protocol or as a deliberate choice to
   facilitate better communications, improved network performance, and
   increased connectivity.  Such a practice could easily protect the
   company's sensitive traffic from eavesdropping and modification.

   Some organisations (e.g., governments) might wish to use a fully
   encrypting firewall to provide a protected virtual network over
   commercial IP service.  The difference between that and a bulk IP
   encryption device is that a fully encrypting firewall would provide
   filtering of the decrypted traffic as well as providing encryption of
   IP packets.








 
RFC 1825              Security Architecture for IP           August 1995


5.2 USE WITH IP MULTICAST

   In the past several years, the Multicast Backbone (MBONE) has grown
   rapidly.  IETF meetings and other conferences are now regularly
   multicast with real-time audio, video, and whiteboards.  Many people
   are now using teleconferencing applications based on IP Multicast in
   the Internet or in private internal networks.  Others are using IP
   multicasting to support distributed simulation or other applications.
   Hence it is important that the security mechanisms in IP be suitable
   for use in an environment where multicast is the general case.

   The Security Parameters Indexes (SPIs) used in the IP security
   mechanisms are receiver-oriented, making them well suited for use in
   IP multicast [Atk95a, Atk95b].  Unfortunately, most currently
   published multicast key distribution protocols do not scale well.
   However, there is active research in this area.  As an interim step,
   a multicast group could repeatedly use a secure unicast key
   distribution protocol to distribute the key to all members or the
   group could pre-arrange keys using manual key distribution.

5.3 USE TO PROVIDE QOS PROTECTION

   The recent IAB Security Workshop identified Quality of Service
   protection as an area of significant interest [BCCH].  The two IP
   security mechanisms are intended to provide good support for real-
   time services as well as multicasting.  This section describes one
   possible approach to providing such protection.

   The Authentication Header might be used, with appropriate key
   management, to provide authentication of packets.  This
   authentication is potentially important in packet classification
   within routers.  The IPv6 Flow Identifier might act as a Low-Level
   Identifier (LLID).  Used together, packet classification within
   routers becomes straightforward if the router is provided with the
   appropriate keying material.  For performance reasons the routers
   might authenticate only every Nth packet rather than every packet,
   but this is still a significant improvement over capabilities in the
   current Internet.  Quality of service provisioning is likely to also
   use the Flow ID in conjunction with a resource reservation protocol,
   such as RSVP [ZDESZ93].  Thus, the authenticated packet
   classification can be used to help ensure that each packet receives
   appropriate handling inside routers.

5.4 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS

   A multi-level secure (MLS) network is one where a single network is
   used to communicate data at different sensitivity levels (e.g.,
   Unclassified and Secret) [DoD85] [DoD87].  Many governments have




 
RFC 1825              Security Architecture for IP           August 1995