RFC 3884 on Use of IPsec Transport Mode for Dynamic Routing

A new Request for Comments is now available in online RFC libraries.

        RFC 3884

        Title:      Use of IPsec Transport Mode for Dynamic Routing
        Author(s):  J. Touch, L. Eggert, Y. Wang
        Status:     Informational
        Date:       September 2004
        Mailbox:    touch@isi.edu, lars.eggert@netlab.nec.de,
                    yushunwa@isi.edu
        Pages:      25
        Characters: 59437
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-touch-ipsec-vpn-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3884.txt

IPsec can secure the links of a multihop network to protect
communication between trusted components, e.g., for a secure virtual
network (VN), overlay, or virtual private network (VPN). Virtual links
established by IPsec tunnel mode can conflict with routing and
forwarding inside VNs because IP routing depends on references to
interfaces and next-hop IP addresses. The IPsec tunnel mode
specification is ambiguous on this issue, so even compliant
implementations cannot be trusted to avoid conflicts.  An
alternative to tunnel mode uses non-IPsec IPIP encapsulation together
with IPsec transport mode, which we call IIPtran.  IPIP encapsulation
occurs as a separate initial step, as the result of a forwarding
lookup of the VN packet. IPsec transport mode processes the resulting
(tunneled) IP packet with an SA determined through a security
association database (SAD) match on the tunnel header.  IIPtran
supports dynamic routing inside the VN without changes to the current
IPsec architecture.  IIPtran demonstrates how to configure any
compliant IPsec implementation to avoid the aforementioned conflicts.
IIPtran is also compared to several alternative mechanisms for VN
routing and their respective impact on IPsec, routing, policy
enforcement, and interactions with the Internet Key Exchange (IKE).

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.