[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: I-D ACTION:draft-ietf-ipsec-sctp-06.txt



Title: RE: I-D ACTION:draft-ietf-ipsec-sctp-06.txt

Hi Steve and all,

The draft (in the end of Section 2, below) appears to propose a new requirement that remote access tunnel mode IPsec users MUST use an inner IP address equivalent to their outer address (or else it reclassifies such users as "security gateways").  This seems to directly contradict all the work with DHCP over IKE and the entire Configuration Payload discussion, all of which is based on assigning an inner tunnel address which can be a part of a VPN address domain (i.e., different from the outer address).

Am I missing something (besides my second cup of coffee)?

Regards,
Paul Knight

From Section 2:
   When operating in tunnel mode, the question of what to use as the
   tunnel destination address (for the "outer" header) arises.  We
   distinguish three cases: where the end hosts are also the tunnel
   endpoints; where neither host is a tunnel endpoint (the tunnel
   endpoints are security gateways); and where only one of the hosts is
   a tunnel endpoint (the usual case for the "road warrior" talking to
   a security gateway).  In the first case, the outer addresses MUST be
   the same as the inner addresses of the tunnel.  In the second case
   (security gateways) there is no special processing; address
   selection proceeds as it would for two distinct sets of end hosts.
   In the third case, the "road warrior" uses the security gateway's
   address as the tunnel destination address, and MUST use the same
   source address as that of the inner packet.  Symmetrically, the
   security gateway uses its own address as the source address of the
   tunnel, and MUST use the the same destination address in the outer
   header as that of the inner packet.  An implementation will probably
   structure the code so that if, during SA setup, the inner and outer
   address of either side is the same, rather than explicitly store the
   corresponding address of the tunnel, it sets a flag that marks the SA
   to use the same address in the tunnel header as in the inner header.

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Wednesday, April 09, 2003 7:18 AM
> To: IETF-Announce; @tislabs.com
> Cc: ipsec@lists.tislabs.com
> Subject: I-D ACTION:draft-ietf-ipsec-sctp-06.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories. This draft is a work item of the
> IP Security Protocol Working Group of the IETF.
>
>       Title           : On the Use of SCTP with IPsec
>       Author(s)       : S. Bellovin et al.
>       Filename        : draft-ietf-ipsec-sctp-06.txt
>       Pages           : 0
>       Date            : 2003-4-8
>      
> This document describes functional requirements for IPsec
> [RFC2401] and IKE [RFC2409] to facilitate their use for
> securing SCTP [RFC2960] traffic.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-06.t
xt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then

        "get draft-ietf-ipsec-sctp-06.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-ipsec-sctp-06.txt".
       
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.
               
               
Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.