rfc3135.txt

RFC 的详细文档！

4.1.1 Security

   In most cases, security applied above the transport layer can be used
   with PEPs, especially transport layer PEPs.  However, today, only a
   limited number of applications include support for the use of
   transport (or higher) layer security.  Network (IP) layer security
   (IPsec) [RFC2401], on the other hand, can generally be used by any
   application, transparently to the application.








Border, et al.               Informational                     [Page 14]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


4.1.1.1 Security Implications

   The most detrimental negative implication of breaking the end-to-end
   semantics of a connection is that it disables end-to-end use of
   IPsec.  In general, a user or network administrator must choose
   between using PEPs and using IPsec.  If IPsec is employed end-to-end,
   PEPs that are implemented on intermediate nodes in the network cannot
   examine the transport or application headers of IP packets because
   encryption of IP packets via IPsec's ESP header (in either transport
   or tunnel mode) renders the TCP header and payload unintelligible to
   the PEPs.  Without being able to examine the transport or application
   headers, a PEP may not function optimally or at all.

   If a PEP implementation is non-transparent to the users and the users
   trust the PEP in the middle, IPsec can be used separately between
   each end system and PEP.  However, in most cases this is an
   undesirable or unacceptable alternative as the end systems cannot
   trust PEPs in general.  In addition, this is not as secure as end-
   to-end security.  (For example, the traffic is exposed in the PEP
   when it is decrypted to be processed.)  And, it can lead to
   potentially misleading security level assumptions by the end systems.
   If the two end systems negotiate different levels of security with
   the PEP, the end system which negotiated the stronger level of
   security may not be aware that a lower level of security is being
   provided for part of the connection.  The PEP could be implemented to
   prevent this from happening by being smart enough to force the same
   level of security to each end system but this increases the
   complexity of the PEP implementation (and still is not as secure as
   end-to-end security).

   With a transparent PEP implementation, it is difficult for the end
   systems to trust the PEP because they may not be aware of its
   existence.  Even if the user is aware of the PEP, setting up
   acceptable security associations with the PEP while maintaining the
   PEP's transparent nature is problematic (if not impossible).

   Note that even when a PEP implementation does not break the end-to-
   end semantics of a connection, the PEP implementation may not be able
   to function in the presence of IPsec.  For example, it is difficult
   to do ACK spacing if the PEP cannot reliably determine which IP
   packets contain ACKs of interest.  In any case, the authors are
   currently not aware of any PEP implementations, transparent or non-
   transparent, which provide support for end-to-end IPsec, except in a
   case where the PEPs are implemented on the end hosts.







Border, et al.               Informational                     [Page 15]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


4.1.1.2 Security Implication Mitigations

   There are some steps which can be taken to allow the use of IPsec and
   PEPs to coexist.  If an end user can select the use of IPsec for some
   traffic and not for other traffic, PEP processing can be applied to
   the traffic sent without IPsec.  Of course, the user must then do
   without security for this traffic or provide security for the traffic
   via other means (for example, by using transport layer security).
   However, even when this is possible, significant complexity may need
   to be added to the configuration of the end system.

   Another alternative is to implement IPsec between the two PEPs of a
   distributed PEP implementation.  This at least protects the traffic
   between the two PEPs.  (The issue of trusting the PEPs does not
   change.)  In the case where the PEP implementation is not transparent
   to the user, (assuming that the user trusts the PEPs,) the user can
   configure his end system to use the PEPs as the end points of an
   IPsec tunnel.  And, an IPsec tunnel could even potentially be used
   between the end system and a PEP to protect traffic on this part of
   the path.  But, all of this adds complexity.  And, it still does not
   eliminate the risk of the traffic being exposed in the PEP itself as
   the traffic is received from one IPsec tunnel, processed and then
   forwarded (even if forwarded through another IPsec tunnel).

4.1.1.3 Security Research Related to PEPs

   There is research underway investigating the possibility of changing
   the implementation of IPsec to be more friendly to the use of PEPs.
   One approach being actively looked at is the use of multi-layer IP
   security.  [Zhang00] describes a method which allows TCP headers to
   be encrypted as one layer (with the PEPs in the path of the TCP
   connections included in the security associations used to encrypt the
   TCP headers) while the TCP payload is encrypted end-to-end as a
   separate layer.  This still involves trusting the PEP, but to a much
   lesser extent.  However, a drawback to this approach is that it adds
   a significant amount of complexity to the IP security implementation.
   Given the existing complexity of IPsec, this drawback is a serious
   impediment to the standardization of the multi-layer IP security idea
   and it is very unlikely that this approach will be adopted as a
   standard any time soon.  Therefore, relying on this type of approach
   will likely involve the use of non-standard protocols (and the
   associated risk of doing so).

4.1.2 Fate Sharing

   Another important aspect of the end-to-end argument is fate sharing.
   If a failure occurs in the network, the ability of the connection to
   survive the failure depends upon how much state is being maintained



Border, et al.               Informational                     [Page 16]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   on behalf of the connection in the network and whether the state is
   self-healing.  If no connection specific state resides in the network
   or such state is self-healing as in case of regular end-to-end
   operation, then a failure in the network will break the connection
   only if there is no alternate path through the network between the
   end systems.  And, if there is no path, both end systems can detect
   this.  However, if the connection depends upon some state being
   stored in the network (e.g., in a PEP), then a failure in the network
   (e.g., the node containing a PEP crashes) causes this state to be
   lost, forcing the connection to terminate even if an alternate path
   through the network exists.

   The importance of this aspect of the end-to-end argument with respect
   to PEPs is dependent upon both the PEP implementation and upon the
   types of applications being used.  Sometimes coincidentally but more
   often by design, PEPs are used in environments where there is no
   alternate path between the end systems and, therefore, a failure of
   the intermediate node containing a PEP would result in the
   termination of the connection in any case.  And, even when this is
   not the case, the risk of losing the connection in the case of
   regular end-to-end operation may exist as the connection could break
   for some other reason, for example, a long enough link outage of a
   last-hop wireless link to the end host.  Therefore, users may choose
   to accept the risk of a PEP crashing in order to take advantage of
   the performance gains offered by the PEP implementation.  The
   important thing is that accepting the risk should be under the
   control of the user (i.e., the user should always have the option to
   choose end-to-end operation) and, if the user chooses to use the PEP,
   the user should be aware of the implications that a PEP failure has
   with respect to the applications being used.

4.1.3 End-to-end Reliability

   Another aspect of the end-to-end argument is that of acknowledging
   the receipt of data end-to-end in order to achieve reliable end-to-
   end delivery of data.  An application aiming at reliable end-to-end
   delivery must implement an end-to-end check and recovery at the
   application level.  According to the end-to-end argument, this is the
   only possibility to correctly implement reliable end-to-end
   operation.  Otherwise the application violates the end-to-end
   argument.  This also means that a correctly designed application can
   never fully rely on the transport layer (e.g., TCP) or any other
   communication subsystem to provide reliable end-to-end delivery.

   First, a TCP connection may break down for some reason and result in
   lost data that must be recovered at the application level.  Second,
   the checksum provided by TCP may be considered inadequate, resulting
   in undetected (by TCP) data corruption [Pax99] and requiring an



Border, et al.               Informational                     [Page 17]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


   application level check for data corruption.  Third, a TCP
   acknowledgement only indicates that data was delivered to the TCP
   implementation on the other end system.  It does not guarantee that
   the data was delivered to the application layer on the other end
   system.  Therefore, a well designed application must use an
   application layer acknowledgement to ensure end-to-end delivery of
   application layer data.  Note that this does not diminish the value
   of a reliable transport protocol (i.e., TCP) as such a protocol
   allows efficient implementation of several essential functions (e.g.,
   congestion control) for an application.

   If a PEP implementation acknowledges application data prematurely
   (before the PEP receives an application ACK from the other endpoint),
   end-to-end reliability cannot be guaranteed.  Typically, application
   layer PEPs do not acknowledge data prematurely, i.e., the PEP does
   not send an application ACK to the sender until it receives an
   application ACK from the receiver.  And, transport layer PEP
   implementations, including TCP PEPs, generally do not interfere with
   end-to-end application layer acknowledgments as they let applications
   operate end-to-end.  However, the user and/or network administrator
   employing the PEP must understand how it operates in order to
   understand the risks related to end-to-end reliability.

   Some Internet applications do not necessarily operate end-to-end in
   their regular operation, thus abandoning any end-to-end reliability
   guarantee.  For example, Internet email delivery often operates via
   relay Mail Transfer Agents, that is, relay Simple Mail Transfer
   Protocol (SMTP) servers.  An originating MTA (SMTP server) sends the
   mail message to a relay MTA that receives the mail message, stores it
   in non-volatile storage (e.g., on disk) and then sends an application
   level acknowledgement.  The relay MTA then takes "full
   responsibility" for delivering the mail message to the destination
   SMTP server (maybe via another relay MTA); it tries to forward the
   message for a relatively long time (typically around 5 days).  This
   scheme does not give a 100% guarantee of email delivery, but
   reliability is considered "good enough".

   An application layer PEP for this kind of an application may
   acknowledge application data (e.g., mail message) without essentially
   decreasing reliability, as long as the PEP operates according to the
   same procedure as the regular proxy (e.g., relay MTA).  Again, as
   indicated above, the user and/or network administrator employing such
   a PEP needs to understand how it operates in order to understand the
   reliability risks associated with doing so.







Border, et al.               Informational                     [Page 18]

RFC 3135          PILC - Performance Enhancing Proxies         June 2001


4.1.4 End-to-end Failure Diagnostics

   Another aspect of the end-to-end argument is the ability to support
   end-to-end failure diagnostics when problems are encountered.  If a
   network problem occurs which breaks a connection, the end points of
   the connection will detect the failure via timeouts.  However, the
   existence of a PEP in between the two end points could delay
   (sometimes significantly) the detection of the failure by one or both
   of the end points.  (Of course, some PEPs are intentionally designed
   to hide these types of failures as described in Section 3.4.)  The