draft-dukes-ike-mode-cfg-02.txt

ipsec vpn

    Reserved for future use    16-16383 
    Reserved for private use   16384-32767 
    
   o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - Specifies an address 
   within the internal network.  This address is sometimes called a red 
   node address or a private address and MAY be a private address on 
   the Internet.  Multiple internal addresses MAY be requested by 
   requesting multiple internal address attributes.  The responder MAY 
   only send up to the number of addresses requested. 
    
   The requested address is valid until the expiry time defined with 
   the INTERNAL_ADDRESS EXPIRY attribute or until the ISAKMP SA that 
   was used to secure the request expires.  The address MAY also expire 
   when the IPSec (phase 2) SA expires, if the request is associated 
   with a phase 2 negotiation.  If no ISAKMP SA was used to secure the 
   request, then the response MUST include an 
   expiry or the host MUST expire the SA after an implementation-
   defined time. 
    
   An implementation MUST support this attribute. 
    
   o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal 
   network's netmask.  Only one netmask is allowed in the request and 
   reply messages (e.g. 255.255.255.0) and it MUST be used only with an 
   INTERNAL_ADDRESS attribute. 
    
  
Dukes, Pereira                                                       7 

                   The ISAKMP Configuration Method     September 2001 
 
 
   An implementation MUST support this attribute. 
    
   o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS 
   server within the network.  Multiple DNS servers MAY be requested.  
   The responder MAY respond with zero or more DNS server attributes. 
    
   o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a 
   NetBios Name Server (WINS) within the network.  Multiple NBNS 
   servers MAY be requested.  The responder MAY respond with zero or 
   more NBNS server attributes. 
    
   o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that the 
   host can use the internal IP address.  The host MUST renew the IP 
   address before this expiry time.  Only one attribute MAY be present 
   in the reply. 
    
   An implementation MUST support this attribute. 
    
   o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send 
   any internal DHCP requests to the address contained within the 
   attribute.  Multiple DHCP servers MAY be requested.  The responder 
   MAY respond with zero or more DHCP server attributes. 
    
   o APPLICATION_VERSION - The version or application information of 
   the IPSec host.  This is a string of printable ASCII characters that 
   is NOT null terminated. 
    
   This attribute does not need to be secured. 
    
   An implementation MUST support this attribute. 
    
   o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
   device protects.  This attribute is made up of two fields; the first 
   being an IP address and the second being a netmask.  Multiple sub-
   networks MAY be requested.  The responder MAY  respond with zero or 
   more sub-network attributes. 
    
   An implementation MUST support this attribute. 
    
   o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute 
   must be zero length and specifies a query to the responder to reply 
   back with all of the attributes that it supports.  The response 
   contains an attribute that contains a set of attribute identifiers 
   each in 2 octets.  The length divided by 2 (bytes) would state the 
   number of supported attributes contained in the response. 
    
   An implementation MUST support this attribute. 
    
   o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
   device protects.  This attribute is made up of two fields; the first 
   being a 16 octet IPv6 address the second being a one octet prefix-
   mask as defined in [ADDRIPV6].  Multiple sub-networks MAY be 

  
Dukes, Pereira                                                       8 

                   The ISAKMP Configuration Method     September 2001 
 
 
   requested.  The responder MAY respond with zero or more sub-network 
   attributes. 
    
   An implementation MUST support this attribute. 
    
   Note that no recommendations are made in this document how an 
   implementation actually figures out what information to send in a 
   reply.  i.e. we do not recommend any specific method of (an edge 
   device) determining which DNS server should be returned to a 
   requesting host. 
    
    
3.5. Retransmission 
    
   Retransmission SHOULD follow the same retransmission rules used with 
   standard ISAKMP messages. 
    
    
4. Exchange Positioning 
    
   The exchange and messages defined within this document MAY appear at 
   any time.  Because of security considerations with most attributes, 
   the exchange SHOULD be secured with an ISAKMP phase 1 SA. 
    
   Depending on the type of transaction and the information being 
   exchanged, the exchange MAY be dependant on an ISAKMP phase 1 SA 
   negotiation, a phase 2 SA negotiation, or none of the above. 
    
   The next section details specific functions and their position 
   within an ISAKMP negotiation. 
    
    
5. Specific Uses 
    
   The following descriptions detail how to perform specific functions 
   using this protocol.  Other functions are possible and thus this 
   list is not a complete list of all of the possibilities.  While 
   other functions are possible, the functions listed below MUST be 
   performed as detailed in this document to preserve interoperability 
   among different vendor's implementations. 
    
    
5.1. Requesting an Internal Address 
    
   This function provides address allocation to a remote host trying to 
   tunnel into a network protected by an edge device.   The remote host 
   requests an address and optionally other information concerning the 
   internal network from the edge device.  The edge device procures an 
   internal address for the remote host from any number of sources such 
   as a DHCP/BOOTP server or its own address pool. 
    
    Initiator                           Responder 
   -----------------------------       ------------------------------- 
  
Dukes, Pereira                                                       9 

                   The ISAKMP Configuration Method     September 2001 
 
 
    HDR*, HASH, ATTR1(REQUEST)    --> 
                                  <--   HDR*, HASH, ATTR2(REPLY) 
    ATTR1(REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute 
   (either IPv4 or IPv6) but MAY also contain any number of additional 
   attributes that it wants returned in the response. 
    
   For example: 
   ATTR1(REQUEST) = 
     INTERNAL_ADDRESS(0.0.0.0) 
     INTERNAL_NETMASK(0.0.0.0) 
     INTERNAL_DNS(0.0.0.0) 
    
   ATTR2(REPLY) = 
     INTERNAL_ADDRESS(192.168.219.202) 
     INTERNAL_NETMASK(255.255.255.0) 
     INTERNAL_SUBNET(291.168.219.0/255.255.255.0) 
    
   All returned values will be implementation dependent.  As can be 
   seen in the above example, the edge device MAY also send other 
   attributes that were not included in the REQUEST and MAY ignore the 
   non-mandatory attributes that it does not support. 
    
   This Transaction Exchange MUST occur after an ISAKMP phase 1 SA is 
   already established and before an ISAKMP phase 2 negotiation has 
   started, since that negotiation requires the internal address. 
    
   Initial Negotiation: 
     MainMode or AggressiveMode 
     TransactionMode (IP Address request) 
     QuickMode(s) 
    
   Subsequent address requests would be done without the phase 1 
   negotiation when there already exists a phase 1 SA. 
    
   Subsequent Negotiations: 
     TransactionMode (IP Address request) 
     QuickMode(s) 
    
5.2. Requesting the Peer's Version 
    
   An IPSec host wishing to inquire about the other peer's version 
   information (with or without security) MUST use this method. 
    
    Initiator                           Responder 
   -----------------------------       -------------------------- 
    HDR, ATTR1(REQUEST)           --> 
                                  <--   HDR, ATTR2(REPLY) 
    
   ATTR1(REQUEST) = 
     APPLICATION_VERSION("") 
    
   ATTR2(REPLY) = 
     APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 
  
Dukes, Pereira                                                      10 

                   The ISAKMP Configuration Method     September 2001 
 
 
    
   The return text string will be implementation dependent.  This 
   transaction MAY be done at any time and with or without any other 
   ISAKMP exchange and because the version information MAY be deemed 
   not sensitive, security is optional. 
    
    
6. Enterprise Management Considerations 
    
   The method defined in this document SHOULD NOT be used for wide 
   scale management.  Its main intent is to provide a bootstrap 
   mechanism to exchange information within IPSec.  While it MAY be 
   useful to use such a method of exchange information to some outlying 
   IPSec hosts or small networks, existing management protocols such as 
   DHCP [DHCP], RADIUS [RADIUS], SNMP or LDAP [LDAP] should be 
   considered for enterprise management as well as subsequent 
   information exchanges. 
    
    
7. Security Considerations 
    
   This entire draft discusses a new ISAKMP configuration method to 
   allow IPSec-enabled entities to acquire and share configuration 
   information. 
    
   The draft mandates that this exchange should normally occur after 
   the Phase I Security Association has been set up and that the entire 
   exchange be protected by that Phase I SA.  Thus the exchange is as 
   secure as any Phase II SA negotiation. 
    
   This exchange MAY be secured (encrypted and authenticated) by other 
   means as well, such as pre-configured ESP [ESP] or data-link 
   security. 
    
    
8. References 
    
 
   [1]         Bradner, S., "The Internet Standards Process -- Revision 
               3", BCP 9, RFC 2026, October 1996. 
    
   [2]         Bradner, S., "Key words for use in RFCs to Indicate 
               Requirement Levels", BCP 14, RFC 2119, March 1997 
    
   [Thayer97]  R. Thayer, N. Doraswamy, R. Glenn. "IP Security Document 
               Roadmap", RFC2411 
    
   [ArchSec]   S. Kent, R. Atkinson, "Security Architecture for the 
               Internet Protocol", RFC2401 
    
   [ISAKMP]    D. Maughan, M. Schertler, M. Schneider, J. Turner, 
               "Internet Security Association and Key Management 
               Protocol", RFC2408 
  
Dukes, Pereira                                                      11 

                   The ISAKMP Configuration Method     September 2001 
 
 
    
   [IKE]       D. Harkins, D. Carrel, "The Internet Key Exchange 
               (IKE)", RFC2409 
    
   [DHCP]      R. Droms, "Dynamic Host Configuration Protocol", 
               RFC2131 
    
   [RADIUS]    C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 
               Authentication Dial In User Service (RADIUS)", RFC2138 
    
   [LDAP]      M. Wahl, T. Howes, S. Kille., "Lightweight Directory 
               Access Protocol (v3)", RFC2251 
    
   [ESP]       S. Kent, "IP Encapsulating Security Payload (ESP)", 
               RFC2406 
    
   [ADDRIPV6]  Hinden, R., "IP Version 6 Addressing Architecture", 
               RFC 2373, July 1998. 
    
    
9. Acknowledgments 
    
   The editors would like to thank Sanjay Anand, Baiju V. Patel, 
   Stephane Beaulieu, Tim Jenkins, Peter Ford, Bob Moskowitz and Shawn 
   Mamros. 
    
    
10. Author's Addresses 
    
   Darren Dukes 
   Cisco Systems Co. 
   365 March Road 
   Kanata, ON, Canada 
   Phone: [phone] 
   Email: [e-mail] 
    
   Roy Pereira 
   Cisco Systems, Inc. 
   170 Tasman Drive 
   San Jose, CA, USA 
   Phone: [phone] 
   Email: [e-mail] 
    
    









  
Dukes, Pereira                                                      12 

                   The ISAKMP Configuration Method     September 2001 
 
 
    
Full Copyright Statement 
 
   "Copyright (C) The Internet Society (date). All Rights Reserved. 
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into 
    
    
   This Internet Draft expires September 2001 
    

































  
Dukes, Pereira                                                      13