PPPEXT Working Group                                       Baiju Patel
     INTERNET-DRAFT                                                   Intel
     Category: Standards Track                                Bernard Aboba
     <draft-ietf-pppext-l2tp-security-00.txt>                     Microsoft
     21 November 1997
     
     
                           Securing L2TP using IPSEC
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing documents as Internet-Drafts.
     
     Internet-Drafts are draft documents valid for a maximum of six  months
     and  may  be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as  reference  mate-
     rial or to cite them other than as ``work in progress.''
     
     To  learn  the  current status of any Internet-Draft, please check the
     ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
     Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
     
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     ietf-pppext-l2tp-security-00.txt> and  expires June 1,  1998.   Please
     send comments to the authors.
     
     
     2.  Abstract
     
     This document discusses how L2TP may utilize IPSEC to provide for tun-
     nel authentication, privacy protection,  integrity  check  and  replay
     protection. Both the voluntary and compulsory tunneling cases are dis-
     cussed.
     
     
     3.  Requirements language
     
     This specification uses the same words as [6] for defining the signif-
     icance of each particular requirement.  These words are:
     
     
     MUST      This  word,  or  the adjectives "REQUIRED" or "SHALL", means
               that the definition is an absolute requirement of the speci-
               fication.
     
     MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defi-
               nition is an absolute prohibition of the specification.
     
     
     
     
     
     Patel & Aboba                                                 [Page 1]


     INTERNET-DRAFT                                        21 November 1997
     
     
     SHOULD    This word, or the adjective "RECOMMENDED", means that  there
               MAY  exist  valid  reasons  in  particular  circumstances to
               ignore a particular item, but the full implications must  be
               understood and carefully weighed before choosing a different
               course.
     
     SHOULD NOT
               This phrase means that there MAY exist valid reasons in par-
               ticular   circumstances  when  the  particular  behavior  is
               acceptable or even useful, but the full implications  should
               be  understood  and the case carefully weighed before imple-
               menting any behavior described with this label.
     
     MAY       This word, or the adjective "OPTIONAL", means that  an  item
               is  truly  optional.   One  vendor may choose to include the
               item because a particular marketplace requires it or because
               the  vendor feels that it enhances the product while another
               vendor may omit the same item.  An implementation which does
               not include a particular option MUST be prepared to interop-
               erate with another implementation  which  does  include  the
               option,  though  perhaps  with reduced functionality. In the
               same vein an implementation which does include a  particular
               option  MUST be prepared to interoperate with another imple-
               mentation which does  not  include  the  option.(except,  of
               course, for the feature the option provides)
     
     Silently Discard
               The  implementation  discards  the  datagram without further
               processing, and without indicating an error to  the  sender.
               The  implementation SHOULD provide the capability of logging
               the error, including the contents of the discarded datagram,
               and SHOULD record the event in a statistics counter.
     
     An  implementation is not compliant if it fails to satisfy one or more
     of the MUST or MUST NOT requirements for the protocols it  implements.
     An  implementation  that  satisfies all the MUST, MUST NOT, SHOULD and
     SHOULD NOT requirements for its protocols is said to be  "uncondition-
     ally compliant"; one that satisfies all the MUST and MUST NOT require-
     ments but not all the SHOULD or SHOULD NOT requirements for its proto-
     cols is said to be "conditionally compliant."
     
     
     4.  Terminology
     
     
     Voluntary Tunneling
               In  voluntary  tunneling,  a  tunnel is created by the user,
               typically via use of a tunneling client. As  a  result,  the
               user  will  send  L2TP packets to the NAS which will forward
               them on to the LNS. Note that in  voluntary  tunneling,  the
               NAS  does  not need to support L2TP, and the LAC effectively
               resides on the same machine as the dial-in user.
     
     
     
     
     
     Patel & Aboba                                                 [Page 2]


     INTERNET-DRAFT                                        21 November 1997
     
     
     Compulsory Tunneling
               In compulsory tunneling, a tunnel  is  created  without  any
               action  from  the  user  and  without  allowing the user any
               choice. As a result, the user will send PPP packets  to  the
               NAS/LAC, which will encapsulate them in L2TP and tunnel them
               to the LNS. In the compulsory tunneling  case,  the  NAS/LAC
               must be L2TP capable.
     
     
     5.  Introduction
     
     L2TP,  described  in  [1], is a protocol that tunnels PPP traffic over
     variety of networks (e.g., IP, SONET, ATM). Since the protocol  encap-
     sulates  PPP,  L2TP  inherits  PPP  authentication, as well as the PPP
     Encryption Control Protocol (ECP) (described in [19]),  and  the  Com-
     pression  Control  Protocol  (CCP)  (described  in  [18]).  L2TP  also
     includes support for tunnel authentication, which can be used to mutu-
     ally  authenticate the tunnel endpoints. However, L2TP does not define
     tunnel protection mechanisms.
     
     IPSEC is a protocol suite defined by IETF working group on IP security
     to  secure  communication  at  the network layer between communicating
     peers.  This  protocol  is  comprised  of  three   primary   elements:
     ISAKMP/Oakley, described in [11], IPSEC AH, described in [7] and IPSEC
     ESP, described in [9]. ISAKMP/Oakley is the  key  management  protocol
     while AH and ESP are used to protect IP traffic.
     
     This  draft  proposes  use of IPSEC protocol suite for protecting L2TP
     traffic over IP and Non-IP networks, and discusses how IPSEC and  L2TP
     should be used together. This document does not attempt to standardize
     end-to-end security. When end-to-end security is required, it is  rec-
     ommended that additional security mechanisms (such as IPSEC or TLS) be
     used inside the tunnel, in addition to L2TP tunnel security.
     
     
     5.1.  L2TP security requirements
     
     L2TP tunnels PPP traffic over  the  IP  and  non-IP  public  networks.
     Therefore, both the control and data packets of L2TP protocol are vul-
     nerable to attack. Examples of attacks include:
     
     1. The adversary may try to discover user identities by snooping  data
     packets.
     
     2. The adversary may try to modify packets (both control and data).
     
     3.  The adversary may try to hijack the L2TP tunnel or the PPP connec-
     tion inside the tunnel.
     
     4. An adversary can launch denial of service  attacks  by  terminating
     PPP connections, or L2TP tunnels.
     
     5.  An  adversary  may  attempt  to disrupt the PPP ECP negotiation in
     order to weaken or remove confidentiality  protection.  Alternatively,
     
     
     
     Patel & Aboba                                                 [Page 3]


     INTERNET-DRAFT                                        21 November 1997
     
     
     an  adversary  may wish to disrupt the PPP LCP authentication negotia-
     tion so as to weaken the PPP authentication process or gain access  to
     user passwords.
     
     To  address threats outlined above, the L2TP security protocol MUST be
     able to provide authentication, integrity and  replay  protection  for
     control  packets.  In addition, it SHOULD be able to protect confiden-
     tiality of control packets. It MUST be able to provide  integrity  and
     replay  protection  of data packets, and MAY be able to protect confi-
     dentiality of data packets. An L2TP security protocol MUST  also  pro-
     vide a scalable approach to key management.
     
     The  L2TP  protocol, and PPP authentication and encryption do not meet
     the security requirements  for  L2TP.  L2TP  authentication  typically
     mutually  authenticates LAC to LNS at tunnel origination and may peri-
     odically re-authenticate. Therefore, it does not protect  control  and
     data  traffic  on a per packet basis. Thus, L2TP tunnel authentication
     leaves L2TP tunnel vulnerable  to  the  attacks  outlined  above.  PPP
     authenticates  the  client  to the LNS, but also does not provide per-
     packet authentication, integrity, or replay protection. PPP encryption
     meets  confidentiality  requirements  for  PPP  traffic  but  does not
     address authentication, integrity  and  key  management  requirements.
     Therefore,  PPP  encryption  provides a weak security solution, and in
     addition does not assist in securing L2TP control channel.
     
     Key management facilities are not provided by the L2TP protocol.  How-
     ever,  where L2TP tunnel authentication is desired, it is necessary to
     distribute keys. Where manual key distribution is not feasible, a  key
     management protocol is required. Since secure key management protocols
     are difficult to design, protocols designed for another purpose  (such
     as RADIUS) MUST NOT be used for L2TP key management.
     
     Note  that several of the attacks outlined above may be carried out on
     PPP packets sent over the link between  the  dial-up  client  and  the
     NAS/LAC,  prior to encapsulation of the packets within an L2TP tunnel.
     While strictly speaking these attacks are outside the  scope  of  L2TP
     security,  in order to protect against them, the user MUST provide for
     confidentiality, authentication and integrity protection for PPP pack-
     ets  sent  over the dial-up link. Authentication and integrity protec-
     tion are not currently supported by the PPP  encryption  methods  out-
     lined in [20]-[22], and PPP ECP, outlined in [19] does not provide for
     a protected ciphersuite negotiation.
     
     
     5.2.  L2TP Security Protocol
     
     Where security is required, L2TP tunnels MUST be secured using  IPSEC,
     both  for IP and non-IP networks. IPSEC AH or ESP MUST be used to pro-
     vide for authentication, integrity and replay protection, and ESP  MAY
     be  used  to  provide for confidentiality. ISAKMP/Oakley MUST used for
     authentication, security association negotiation and key management.
     
     The L2TP tunnel is secured between either LAC and LNS, or between  LAC
     and  a  firewall  (when  a firewall is present and is trusted by LAC).
     
     
     
     Patel & Aboba                                                 [Page 4]


     INTERNET-DRAFT                                        21 November 1997
     
     
     Both LAC and LNS must meet L2TP security requirements.
     
     All compliant implementations MUST implement IPSEC  ESP  for  securing
     control  packets.  Replay  protection, the compulsory cipher suite for
     IPSEC ESP, and NULL encryption MUST be implemented. Optionally,  IPSEC
     AH  MAY  also  be  supported.  All compliant implementations MUST also
     implement IPSEC ESP for protection of data packets. Replay  prevention
     and  integrity protection using IPSEC ESP mandated cipher suit MUST be
     implemented. NULL encryption also MUST be supported. Other  IPSEC  ESP
     required ciphers MAY also be supported.
     
     ISAKMP/Oakley  MUST be supported in for authentication, security asso-
     ciation negotiation, and key management using IPSEC DOI.
     
     
     5.2.1.  Implementation considerations for L2TP over Non-IP networks
     
     L2TP requires that a non-IP network supports packet transport, so that
     the non-IP network should be able to carry L2TP control and data pack-
     ets.
     
     Since ESP functions are defined on the IP payload  (excluding  the  IP
     header),  the presence of an IP header is not a requirement for use of
     ESP. Therefore, L2TP implemented on non-IP networks MUST  be  able  to
     transport  IPSEC ESP packets. The next payload field of the ESP header
     MUST be set to zero.
     
     ISAKMP/Oakley messages use UDP transport. Therefore, in  order  to  be
     compliant  with the ISAKMP/Oakley protocol on non-IP media, the non-IP
     media (which is capable of transporting packets) MUST  support  trans-
     port  of  UDP datagrams. Since the IP header is not present in the UDP
     datagram over non-IP media, the UDP checksum MUST be set  to  zero  by
     the source and ignored by the destination.
     
     The  exact  mechanisms  for  enabling transport of ESP and UDP packets
     over non-IP media MUST be addressed in appropriate standards for  L2TP
     over specific non-IP networks.
     
     
     5.3.  L2TP/IPSEC interoperability guidelines
     
     The  following  guidelines  are  established  to  meet  L2TP  security
     requirements using IPSEC in practical situations. Note that this  sec-
     tion  is  not  a requirement for an implementation to be L2TP security
     compliant.  Its purpose to make  the  implementors  aware  of  certain
     efficiency and security considerations.
     
     In  the  design of an L2TP/IPSEC interoperability guidelines, the fol-
     lowing goals were identified:
     
     
     Elimination of redundant operations
          If possible, it is desirable that compression/encryption only  be
          applied at a single layer in the protocol stack.
     
     
     
     Patel & Aboba                                                 [Page 5]


     INTERNET-DRAFT                                        21 November 1997
     
     
     Stateless compression and encryption
          For  reasons  described  below, it is desirable that L2TP over IP
          utilize stateless compression and encryption.
     
     
     Maximal coverage
          Along its travel path, an L2TP packet may be handled by the dial-
          in user, NAS/LAC, LNS, and endstation. It is desirable that secu-
          rity services be applied over the largest possible portion of the
          travel path.
     
     
     5.3.1.  Elimination of duplicate encryption/compression
     
     Given  that L2TP over IP consists of an results IP packet encapsulated
     in PPP encapsulated in L2TP encapsulated in IP  running  over  a  link
     layer, many opportunities exist for duplication of encryption and com-
     pression services. In general such duplication is undesirable since it
     is  ineffective and wastes CPU cycles. However, avoiding such duplica-
     tion is not a simple task, since it may require communication  between
     non-adjacent layers of the protocol stack, as well as ensuring that IP
     and link layers be capable of  turning  off/on  compression/encryption
     services  on  a  per-packet  basis. Current PPP compression/encryption
     implementations are not capable of doing this, and achieving  this  in
     IPSEC  may require negotiation of two security associations, with mul-
     tiplexing of packets between them. As noted in  [16],  elimination  of
     duplicate compression/encryption may require changes to wire protocols
     and/or sockets APIs.
     
     
     5.3.2.  Stateless compression and encryption
     
     Stateless encryption and/or compression is highly desirable when  L2TP
     is  run  over IP. Thus IPSEC encryption and IP compression (stateless)
     are to be preferred over PPP encryption/compression  (stateful)  wher-
     ever  possible.  Since  L2TP is a connection-oriented protocol, use of
     stateful compression/encryption is feasible, but  when  run  over  IP,
     this  is  not desirable. While providing better compression, and some-
     what more secure encryption, when used without an underlying  reliable
     delivery  mechanism  stateful  methods magnify packet losses, and thus
     are problematic when used over the Internet where packet loss  can  be
     significant.  In  addition,  although L2TP is connection oriented, the
     L2TP specification does not mandate packet ordering, which can  create
     difficulties  in  implementation  of  stateful  compression/encryption
     schemes. However, these considerations are not as important when  L2TP
     is  run  over  non-IP  media  such as ATM, X.25, or Frame Relay, since
     these media guarantee ordering, and packet losses are typically low.
     
     
     5.3.3.  Maximal coverage
     
     If it is desired to apply security services when communicating between
     a  client  and an endstation, then maximal coverage can be achieved by
     having security services negotiated at the application layer. However,
     
     
     
     Patel & Aboba                                                 [Page 6]


     INTERNET-DRAFT                                        21 November 1997
     
     
     in practice the problem is not so simple since the absence of applica-
     tion-layer security does not necessarily imply that security is  unde-
     sirable  at  lower layers. Similarly, where there are multiple parties
     involved in processing of packets (as there are in compulsory and vol-
     untary  tunneling scenarios), the negotiation of security services can
     become quite complex since the parties may have  different  objectives
     and  may  not trust each other. The problem is also complicated by the
     presence of legacy hosts.
     
     As a result,  it may be difficult to achieve maximal coverage  without
     some  degree of duplication in encryption/compression services, unless
     per-packet turn off/on can be achieved.
     
     
     5.4.  L2TP/IPSEC Interoperability scenarios
     
     In the scenarios that follow, it is assumed that both L2TP clients and
     servers are able to set and get the properties of IPSEC security asso-
     ciations, as well as to influence the IPSEC security services  negoti-
     ated.  Furthermore,  it  is  assumed that L2TP clients and servers are
     able to influence the negotiation process for PPP encryption and  com-
     pression. These and other API-related questions are addressed in [31].
     
     
     5.4.1.  Scenario 1: Compulsory tunnel
     
     In the case of a compulsory tunnel, the dial-in user will  be  sending
     PPP packets to the LAC, and will typically not be aware that its pack-
     ets are being tunneled. From the LNS's point of view, it will  note  a
     PPP packet encapsulated in L2TP, which is itself encapsulated in an IP
     frame. Assuming that the LNS is able to retrieve the properties of the
     Security  Association  set up between itself and the LAC, it will have
     knowledge of the security  services  in  place  between  the  LAC  and
     itself.  Thus  in  the  compulsory tunneling case, there is asymmetric
     knowledge between the dial-in user and the LNS.
     
     Since the LNS is capable of knowing whether confidentiality, authenti-
     cation,  integrity  and  replay protection is in place between the LAC
     and itself, it is able to use this knowledge to modify the PPP ECP and
     CCP  negotiation.  If  IPSEC  confidentiality is in place, the LNS may
     behave as though a "Require Encryption" directive had been  fulfilled,
     and  will  not mandate use of PPP encryption or compression. Note how-
     ever that the LNS should not insist that PPP encryption/compression be
     turned off, instead leaving this decision to the dial-in user.
     
     Since  the  dial-in  user has no knowledge of the security services in
     place between the LAC and the LNS, and since it does  not  necessarily
     trust the LAC or the wire between itself and the LAC, it SHOULD either
     rely on end-to-end IPSEC or should request  that  PPP  encryption/com-
     pression be negotiated. This behavior would not even be modified if it
     had knowledge of the security services in place between  the  LAC  and
     the  LNS,  since  the  dial-in user needs to negotiate confidentiality
     services in order to provide  privacy  on  the  portion  of  the  path
     between itself and the LAC, and between the LNS and the endstation.
     
     
     
     Patel & Aboba                                                 [Page 7]


     INTERNET-DRAFT                                        21 November 1997
     
     
     Given  that the dial-in user will typically not trust the LAC and will
     negotiate confidentiality and compression services on its own, the LAC
     MAY  only  negotiate  IPSEC AH (authentication + integrity check) with
     the LNS, and the LNS will request replay protection. This will  ensure
     that  confidentiality  and compression services will not be duplicated
     over the path between the LAC and the  LNS.  It  also  will  typically
     result  in  better  scalability  for the LAC, since encryption will be
     handled by the dial-in user and the LNS.
     
     The dial-in user can satisfy its desire for  confidentiality  services
     in one of two ways. If it knows that all endstations that it will com-
     municate with are IPSEC-capable (or if it refuses to talk to non-IPSEC
     capable  endstations),  then  it  can  refuse to negotiate PPP encryp-
     tion/compression and negotiate IPSEC ESP with the endstations instead.
     If  the  client does not know that all endstations it will contact are
     IPSEC capable (the most likely  case),  then  it  will  negotiate  PPP
     encryption/compression.   This   may   result  in  duplicate  compres-
     sion/encryption  which  can  only  be  eliminated  if   PPP   compres-
     sion/encryption can be turned off on a per-packet basis.
     
     5.4.1.1.  Scenario 1a: Endstation not IPSEC capable
     
     In  the case that the client is communicating with a non-IPSEC capable
     endstation, the protocol stack will appear as follows:
     
     Dial-in User     LAC                 LNS        End Station
     <--------------------------IP------------------------->
     <-----------PPP Enc + Comp------------>
                       <-------L2TP-------->
                       <----IPSEC AH------->
     
     
     5.4.1.2.  Scenario 1b: All Endstations IPSEC capable
     
     In the case where the client only communicates with IPSEC-capable end-
     stations,
     
     Dial-in User     LAC                 LNS        End Station
     <----------------------IPSEC ESP---------------------->
     <------------------PPP---------------->
                       <-------L2TP-------->
                       <----IPSEC AH------->
     
     5.4.1.3.   Scenario  1c:  Some endstations IPSEC-capable, some not, no
     duplication
     
     In the case where the client communicates with  a  mixture  of  IPSEC-
     capable  and  non-capable  endstations, and it is desired to eliminate
     duplicate compression/encryption, it is necessary to allow PPP Encryp-
     tion  and  Compression to be turned off on a per-packet basis. In this
     case, scenario 1c degenerates to scenario 1b when  the  endstation  is
     IPSEC-capable, and scenario 1a when it is not.
     
     Dial-in User     LAC                 LNS        End Station
     
     
     
     Patel & Aboba                                                 [Page 8]


     INTERNET-DRAFT                                        21 November 1997
     
     
     <--------------IP (1) or IPSEC ESP (2)---------------->
     <-----PPP Enc + Comp (1) or PPP (2)--->
                       <-------L2TP-------->
                       <----IPSEC AH------->
     
     
     5.4.2.  Scenario 2: Voluntary tunnel
     
     In  the  case  of a voluntary tunnel, the dial-in user will be sending
     L2TP packets to the NAS, which will route them to the LNS.  Note  that
     over  a dialup link, these L2TP packets will be encapsulated in IP and
     PPP.  Assuming that it is possible for the dial-in  user  to  retrieve
     the properties of the Security Association between itself and the LNS,
     the dial-in user will have knowledge of any security services  negoti-
     ated  between  itself  and the LNS. It will also have knowledge of PPP
     encryption/compression services negotiated between itself and the NAS.
     
     From  the  LNS's point of view, it will note a PPP packet encapsulated
     in L2TP, which is itself encapsulated in an IP frame.  This  situation
     is  identical  to  that  given in scenario 1. Assuming that the LNS is
     able to retrieve the properties of the  Security  Association  set  up
     between  itself  and  the  dial-in user, it will have knowledge of the
     security services in place between the dial-in user and  itself.  Thus
     in  the  voluntary  tunneling  case, the dial-in user and the LNS have
     symmetric knowledge.
     
     Since the LNS is capable of knowing whether confidentiality, authenti-
     cation,  integrity  check or replay protection is in place between the
     dial-in user and itself, it is able to use this  knowledge  to  modify
     its PPP ECP and CCP negotiation stance. If IPSEC confidentiality is in
     place, the LNS will behave as though a "Require Encryption"  directive
     had been fulfilled, and will not mandate use of PPP encryption or com-
     pression. Note however that the LNS will not insist that  PPP  encryp-
     tion/compression  be  turned off, instead leaving this decision to the
     dial-in user.
     
     Since the dial-in user has knowledge of the security services in place
     between  itself  and the LNS, it will act as though a "Require Encryp-
     tion" directive had been fulfilled if IPSEC ESP was already  in  place
     between  itself and the LNS. Thus, it will request that PPP encryption
     and compression not be negotiated. Note that turning off PPP  compres-
     sion should occur even if IP Compression services could not be negoti-
     ated, due to the undesirable effects of PPP stateful compression.
     
     In this case, we recommend that the dial-in  user  and  LNS  negotiate
     IPSEC  Confidentiality,  Authentication, and Integrity protection ser-
     vices, as well as IP  Compression  if  available,  and  that  the  LNS
     request  replay  protection. PPP encryption and compression should not
     be negotiated between the dial-in user and the LNS.
     
     Note that this may result in duplicate encryption if the dial-in  user
     is  communicating  with an IPSEC-capable endstation. In order to avoid
     duplicate encryption/compression, the dial-in user may  negotiate  two
     Security  Associations  with  the  LNS,  one  with  AH,  and  one with
     
     
     
     Patel & Aboba                                                 [Page 9]


     INTERNET-DRAFT                                        21 November 1997
     
     
     confidentiality/compression. Packets going to an IPSEC-capable endsta-
     tion would run over the AH security association, and packets to a non-
     IPSEC capable endstation would run over the  other  security  associa-
     tion. Note that many IPSEC implementations cannot support this without
     allowing L2TP packets on the same tunnel to be originated from  multi-
     ple  UDP  ports. This will require modification of the L2TP specifica-
     tion.
     
     Also note that the dial-in user may wish to put  confidentiality  ser-
     vices  in place for non-tunneled packets travelling between itself and
     the NAS. This will protect the dial-in user against  eavesdropping  on
     the wire between itself and the NAS. As a result, it may wish to nego-
     tiate PPP encryption and compression with the NAS. As in  scenario  1,
     this  will  result  in  duplicate  encryption and possibly compression
     unless PPP compression/encryption can be turned off  on  a  per-packet
     basis.  In the figures below, this possible use of PPP encryption/com-
     pression is not shown since it is desirable that it be turned off when
     transporting L2TP packets that have already been compressed/encrypted.
     
     5.4.2.1.  Scenario 2a: Endstation not IPSEC capable
     
     In the case that the dial-in  user  is  communicating  with  non-IPSEC
     capable endstations, it will wish to negotiate IPSEC ESP with the LNS.
     This will provide confidentiality, authentication, and integrity  ser-
     vices between the dial-in user and LNS.
     
     Dial-in User     NAS                 LNS        End Station
     <--------------------------IP------------------------->
     <----------------PPP------------------>
     <---------------L2TP------------------>
     <------------IPSEC ESP---------------->
     <--------PPP------>
     
     
     5.4.2.2.  Scenario 2b: All Endstations IPSEC capable
     
     In  the case where the dial-in user only communicates with IPSEC-capa-
     ble endstations, the dial-in user may wish to only  require  IPSEC  AH
     between itself and the LNS. Note that negotiating IPSEC AH between the
     dial-in user and LNS is only possible if the LNS does not require ESP.
     
     Dial-in User     NAS                 LNS        End Station
     <----------------------IPSEC ESP---------------------->
     <----------------PPP------------------>
     <---------------L2TP------------------>
     <------------IPSEC AH----------------->
     <--------PPP------>
     
     5.4.2.3.  Scenario 2c: Some endstations IPSEC-capable
     
     In  the  case  where  the  dial-in user communicates with a mixture of
     IPSEC-capable and non-capable  endstations,  duplicate  encryption  is
     possible.  This  can  be  avoided  if packets are multiplexed over two
     Security Associations, one with AH, and the other with ESP. This would
     
     
     
     Patel & Aboba                                                [Page 10]


     INTERNET-DRAFT                                        21 November 1997
     
     
     allow encryption to be turned off on a per-packet basis. In this case,
     scenario 2c would revert to scenario 2a when  the  endstation  is  not
     IPSEC-capable,  and  to  scenario  2b when it is IPSEC-capable. Again,
     note that negotiating IPSEC AH between the dial-in  user  and  LNS  is
     only possible if the tunnel server does not require ESP.
     
     Dial-in User     NAS                 LNS        End Station
     <----------------IP (1) or IPSEC ESP (2)-------------->
     <----------------PPP------------------>
     <---------------L2TP------------------>
     <------IPSEC ESP (1) or AH (2)-------->
     <--------PPP------>
     
     
     6.  Security considerations
     
     This draft defines a security protocol.
     
     
     
     7.  Acknowledgements
     
     Thanks  to  Gurdeep  Singh Pall, David Eitelbach, William Dixon, Peter
     Ford, and Sanjay Anand of Microsoft, John Richardson of Intel and  Rob
     Adams of Cisco for many useful discussions of this problem space.
     
     
     8.  References
     
     [1]  K.  Hamzeh,  A.  Rubens,  T.  Kolar, M. Littlewood, B. Palter, A.
     Valencia, G. S. Pall, J. Taarud, W. M. Townsley, W. Verthein.   "Layer
     Two  Tunneling  Protocol  -- L2TP." Internet draft (work in progress),
     draft-ietf-pppext-l2tp-07.txt, Ascend Communications,  Cisco  Systems,
     Microsoft, Copper Mountain Networks, IBM, 3Com, October 1997.
     
     [2]  P.  R.  Calhoun,  W.  M. Townsley.  "Layer Two Tunneling Protocol
     "L2TP" Security Extensions for Non-IP Networks." Internet draft  (work
     in  progress),  draft-ietf-pppext-l2tp-sec-02.txt,  3Com, IBM, October
     1997.
     
     [3] K. Hamzeh, G. S. Pall, J.  Taarud,  W.  Verthein,  W.  A.  Little.
     "Point-to-Point  Tunneling  Protocol -- PPTP." Internet draft (work in
     progress),   draft-ietf-pppext-pptp-02.txt,   Ascend   Communications,
     Microsoft, Copper Mountain Networks, U.S. Robotics, July 1997.
     
     [4]  G. Zorn.  "RADIUS Attributes for Tunnel Protocol Support." Inter-
     net draft (work  in  progress),  draft-ietf-radius-tunnel-auth-02.txt,
     Microsoft, July 1997.
     
     [5]  B.  Aboba, G. Zorn.  "Implementation of PPTP/L2TP Compulsory Tun-
     neling via RADIUS." Internet draft  (work  in  progress),  draft-ietf-
     radius-tunnel-imp-03.txt, Microsoft, July 1997.
     
     [6]  S.  Bradner.   "Key words for use in RFCs to Indicate Requirement
     
     
     
     Patel & Aboba                                                [Page 11]


     INTERNET-DRAFT                                        21 November 1997
     
     
     Levels." RFC 2119, Harvard University, March 1997.
     
     [7] S. Kent, R. Atkinson.  "IP Authentication Header." Internet  draft
     (work  in  progress),  draft-ietf-ipsec-auth-header-02.txt,  BBN Corp,
     @Home Network, October 1997.
     
     [8] R. Thayer, N. Doraswamy, R. Glen.  "IP Security Document Roadmap."
     Internet    draft    (work    in    progress),   draft-ietf-ipsec-doc-
     roadmap-01.txt, Sable, Bay Networks, NIST, July 1997.
     
     [9] S. Kent, R. Atkinson.  "IP Encapsulating Security Payload  (ESP)."
     Internet draft (work in progress), draft-ietf-ipsec-esp-v2-01.txt, BBN
     Corp, @Home Network, October 1997.
     
     [10] D. Piper.  "The Internet IP Security Domain of Interpretation  of
     ISAKMP."  Internet  draft  (work in progress), draft-ietf-ipsec-ipsec-
     doi-05.txt, Cisco Systems, October 1997.
     
     [11] D. Maughan, M. Schertler, M.  Schneider,  J.  Turner.   "Internet
     Security  Association  and Key Management Protocol (ISAKMP)." Internet
     draft (work in progress), draft-ietf-ipsec-isakmp-08.txt, NSA,  Terisa
     Systems, July 1997.
     
     [12]  D.  Harkins, D. Carrel.  "The resolution of ISAKMP with Oakley."
     Internet  draft  (work  in   progress),   draft-ietf-ipsec-isakmp-oak-
     ley-04.txt, Cisco Systems, July 1997.
     
     [13] N. Doraswamy.  "Implementation of Virtual Private Networks (VPNs)
     with IP Security." Internet  draft  (work  in  progress),  draft-ietf-
     ipsec-vpn-00.txt, FTP Software, March 1997.
     
     [14]  R.  Moskowitz.  "Network Address Translation issues with IPsec."
     Internet  draft   (work   in   progress),   draft-moskowitz-ipsec-vpn-
     nat-00.txt, Chrysler, August 1997.
     
     [15]  H.  K. Orman.  "The OAKLEY Key Determination Protocol." Internet
     draft (work in progress),  draft-ietf-ipsec-oakley-02.txt,  University
     of Arizona, August 1997.
     
     [16] R. Monsour, M. Sabin, A. Shacham, S. Anand, R. Thayer.  "Compres-
     sion in IP Security." Internet draft (work  in  progress),  draft-mon-
     sour-compr-ipsec-00.txt,  Hi/fn  Inc.,Cisco, Microsoft, Sable Technol-
     ogy, March 1997.
     
     [17] W. Simpson.  "The Point-to-Point Protocol (PPP)". RFC 1661,  Day-
     dreamer, July 1994.
     
     [18] D. Rand.  "The PPP Compression Control Protocol (CCP)". RFC 1962,
     Novell, June 1996.
     
     [19] G. Meyer.  "The PPP Encryption Control Protocol (ECP)". RFC 1968,
     Spider Systems, June 1996.
     
     [20]  K. Sklower, G. Meyer.  "The PPP DES Encryption Protocol (DESE)".
     
     
     
     Patel & Aboba                                                [Page 12]


     INTERNET-DRAFT                                        21 November 1997
     
     
     RFC 1969, UCB, Spider Systems, June 1996.
     
     [21] K. Sklower, G. Meyer.  "The PPP DES Encryption Protocol,  Version
     2  (DESE-bis)".  Internet draft (work in progress), draft-ietf-pppext-
     des-encrypt-v2-00.txt, UCB, Shiva, July 1997.
     
     [22] H. Kummert.  "The PPP Triple-DES  Encryption  Protocol  (3DESE)".
     Internet    draft    (work   in   progress),   draft-ietf-pppext-3des-
     encrypt-00.txt, Nentec GmbH, July 1997.
     
     [23] R. Friend.  "PPP Stac LZS Compression Protocol".  Internet  draft
     (work  in  progress),  RFC  1974, Stac Electronics, DayDreamer, August
     1996.
     
     [24] R. Friend.  "PPP Stac LZS Compression Protocol". RFC  1974,  Stac
     Electronics, DayDreamer, August 1996.
     
     [25] D. Schremp, J. Black, J. Weiss.  "PPP Magnalink Variable Resource
     Compression". RFC 1975, Magnalink, August 1996.
     
     [26] K. Schneider, S. Venters.  "PPP for Data Compression in Data Cir-
     cuit-Terminating  Equipment  (DCE)".  RFC  1976,  ADTRAN, Inc., August
     1996.
     
     [27] V. Schryver.  "PPP BSD  Compression  Protocol".  RFC  1977,  SGI,
     August 1996.
     
     [28] D. Rand.  "PPP Predictor Compression Protocol". RFC 1978, Novell,
     August 1996.
     
     [29] J. Woods.  "PPP  Deflate  Protocol".  RFC  1979,  Proteon,  Inc.,
     August 1996.
     
     [30] G. Pall.  "Microsoft Point-to-Point Compression (MPPC) Protocol".
     RFC 2118, Microsoft, March 1997.
     
     [31] D. L. McDonald.  "A Simple IP Security API Extension to BSD Sock-
     ets".  Internet draft (work in progress), draft-mcdonald-simple-ipsec-
     api-01.txt, Sun Microsystems, March 1997.
     
     
     9.  Authors' Addresses
     
     Baiju V. Patel
     Intel Corp
     2511 NE 25th Ave
     Hillsboro, OR 97124
     
     Phone: 503-264-2422
     Email: baiju@mailbox.jf.intel.com
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     
     
     
     Patel & Aboba                                                [Page 13]


     INTERNET-DRAFT                                        21 November 1997
     
     
     Redmond, WA 98052
     
     Phone: 425-936-6605
     EMail: bernarda@microsoft.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Patel & Aboba                                                [Page 14]