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

IPsec Architecture -- proposed changes



Folks,

In response to discussions at Munich and later comments from the working
group, here's a list of proposed changes for the IPsec Architecture
document.  (It does not include minor edits -- typos, simple
clarifications, address changes, etc.)  Many of these items are offered
for discussion and are not meant to be a final resolutions drawn from
mailing list consensus.  Please let us know by 10/13 of any issues we've
missed and any feedback you have on the items below.

Thank you,
Karen

=============================================================================
1. Which documents should contain references to current default
   algorithms (mandatory-to-implement)?  We currently have:
	- AH mandatories in AH, Arch (and DOI).
	- ESP mandatories in ESP, Arch (and DOI).

   Per discussion on 7/22 between Rodney Thayer, Ted Tso... We propose
   to leave the references in the AH, ESP, and Architecture documents.

=============================================================================
2. How should we handle the security gateway problem -- discovery of the
   security gateway, verification of its authenticity and authorization,
   etc.?

   Per discussion at Munich IETF... In section 4.6.3 "Locating a
   Security Gateway", we propose to:
	- remove the [NOTE: This topic is still under discussion...] 
	  on page 18.
	- leave the problem description in place (pages 18-19)
	- remove the rest of the section and replace it with:

	  "To address these problems, a host or security gateway MUST
	  have an administrative interface that allows the
	  user/administrator to configure the address of a security
	  gateway for any sets of destination addresses that require its
	  use. This includes the ability to configure:
		o the SAs to use for a communication association to the
		  destination host.  In the example above, this would
		  mean a tunnel mode SA from H1 to SG1 and a transport
		  mode SA from H1 to H2.
		o the SAs to use if the path to the destination host
		  fails.  In the example above, this would mean a tunnel
		  mode SA from H1 to SG2 and a transport mode SA from H1
		  to H2.
		o the requisite information for locating, authenticating
		  and verifying the authorization of the relevant
		  security gateways.  In the example above, the relevant
		  security gateways would be SG1 and SG2.

	  This document does not address the issue of how to automate
	  the discovery/verification of security gateways."

=============================================================================
3. How should we handle MLS issues?

   Per discussion at the Munich IETF and following up on email to the
   list (8/19, Steve Kent), we propose to defer this problem to another
   document that will be issued later.  The following text will be
   included in Section 10.  "Use in systems supporting information flow
   security":

   "The use of IPsec in an MLS environment imposes additional
   requirements on IPsec implemntations.  A separate document will
   address these requirements."

=============================================================================
4. Clarification about using a different SPI when a new SA is created
   because of rekeying...

   Following up on discussion on the mailing list (8/6, Bill Sommerfeld,
   Catherine Gibson, Dan McDonald), we propose to include text in the
   section 4.6 "SA Establishment", before 4.6.1 "Manual Techniques" and
   4.6.2 "Automatic Techniques -- Key Mgt Protocol Requirements" that
   says:

   "The rekeying of an SA implies creation of a new SA with a new SPI."

=============================================================================
5. Should the IPsec architecture enable an application, which is using a
   single socket to communicate with multiple peers, to use different
   security policies for different peers?

   From observations by Charlie Lynn -- "UDP sockets may, and do, switch
   destination addresses on a packet by packet basis.  SAs would also
   have to correspondingly change on a packet by packet basis based on
   the packet's destination (and maybe other things)...People are
   already thinking about how applications might specify security policy
   requirements, e.g., the 8/1/97 draft-metz-net-security-api-00.txt,
   "Network Security API for Sockets."  

   To address this concern, we propose to add the following text to
   section 4.4.1, "Security Policy Database", paragraph 3, after
   sentence 1.

	"This interface must allow the user/application to specify a set
	of policies that can be invoked on a packet by packet basis for
	a single socket, e.g., for UDP traffic.  Also, the system
	administrator MUST be able to specify whether or not a
	user/application can circumvent system policies."

=============================================================================
6. Should AH/ESP be a selector?  What should this selector be called?

   Per suggestion from Charlie Lynn, we propose that AH and ESP be
   allowed as selector inputs, and that the name for this selector be
   "IPsec Protocols".  A new selector paragraph will be added to section
   4.4.3 "Selectors":

	"IPsec protocol (AH or ESP or AH/ESP): If present, this is
	obtained from the IPv4 "Protocol" field or the IPv6 "Next
	Header" field.  [REQUIRED for all implementations]

	NOTE: These fields could contain a Transport Protocol, Routing
	Header, AH, ESP, Fragmentation Header, Destination Options,
	Hop-by-hop options, etc.  And while IPv6 recommends a particular
	order for extension headers, it also specifies that the
	implementation must be prepared to accept them in any order.  So
	to check for the existence of an IPsec header, a system has to
	chain through the packet headers checking the Protocol/Next
	Header field until it has checked all that are not opaque."

=============================================================================
7. Should the "Transport Protocol" selector be required only for systems
   supporting IPv6, and be optional for IPv4?  

   Per suggestion from the working group and given the proposal to add
   IPsec protocol as a selector (see above), we propose to modify the
   Transport Protocol paragraphs of section 4.4.3 "Selectors" as
   follows:
	- At the end of the paragraph on "Transport Protocol", change
	  "[REQUIRED for all implementations]" to "[REQUIRED for IPv6
	  implementations, MAY be supported in IPv4 implementations]
	- Change the first Transport Protocol paragraph by rewording the
	  first 2 sentence and deleting the last 3 sentences.  Leave
	  the second paragraph as is.  This results in:

		"Transport Layer Protocol: Obtained from the IPv4
                "Protocol" or the IPv6 "Next Header" fields.  These
                fields may not contain the Transport Protocol due to the
                presence of IP extension headers, e.g., a Routing
                Header, AH, ESP, Fragmentation Header, Destination
                Options, Hop-by-hop options, etc.  
		[REQUIRED for all implementations]

		NOTE: To locate the transport protocol, a system has to
		chain through the packet headers checking the "Next
		Protocol" field until it encounters either one it
		recognizes as a transport protocol or until it reaches
		one that isn't on its list of extension headers."

=============================================================================
8. Additional selector changes -- adding TOS and renaming IPv6
   "Priority" to "Class".

   Based on discussion at the Munich IETF, we propose to add TOS for
   IPv4 as a selector and change the IPv6 Priority field to "Class" to
   match the IPv6 spec.  This involves changing Section 4.4.3
   "Selectors" by:

   Adding the text:
	"IPv4 Type of Service (TOS):  Obtained from IP header
	[REQUIRED for all systems that implement IPv4]"

   Changing "IPv6 Priority..." to "IPv6 Class..."

=============================================================================
9. Additional warnings that certain selectors may not always be
   accessible....

   Per suggestion in private email from a working group member, we
   propose to make the following changes to section 4.4.3 "Selectors":

   Paragraph 1 (An SA (or SA bundle) may be...) after the third
   sentence, insert the text:

	"In the case of receipt of a packet with an ESP header, e.g., at
	an encapsulating security gateway or bump in the wire
	implementation, the transport layer protocol and ports may be
	opaque, thus making them unavailable for use as selectors."

   Paragraph 9 (Source and Destination (TCP/UDP) Ports...) at the 
   end, add the text:

	"Note that the source and destination ports may not be available
	in the case of receipt of a packet with an ESP header."

   The proposed paragraph from item (7) on "Transport Protocol", add the
   text:

	"Note that the Transport Protocol may not be available in the
	case of receipt of a packet with an ESP header."

=============================================================================
10.  How should we handle header copying in tunnel mode?

   Per discussion at the Munich IETF, we propose to use an approach
   similar to that described in RFC 2003 "IP Encapsulation with IP".
   This RFC minimizes the complexity of this problem by generally not
   copying options, e.g., source routing.  Since RFC 2003 does not
   address IPv6 and to avoid having to worry about the text in RFC 2003
   that is not needed by the IPsec architecture document, we propose to
   write text that is modeled after RFC 2003 rather than to simply refer
   the reader to RFC2003.

   ICMP processing -- Section 6.1.1 DF bit and 6.1.2 Path MTU
   Discovery, leave text as is.

   Appendix B "Analysis/Discussion of PMTU/DF/Fragmentation Issues",
   leave text as is.

   Inbound processing -- Section 5.2 "Processing Inbound IPsec Traffic,
   add the text:

	"The handling of the inner and outer IP headers, extension
 	headers, and options for AH and ESP tunnels should be done
 	as described in the tables in Section 5.1.

   Outbound processing -- Section 5.1.2 "Header construction for tunnel
   mode", 
	o Delete the first (parenthetical) paragraph, "There are a
	  variety..."
	o Replace the rest of the section with:

	  "This section describes the handling of the inner and outer IP
	  headers, extension headers, and options for AH and ESP
	  tunnels.  This includes how to construct the encapsulating
	  (outer) IP header, how to handle fields in the inner IP
	  header, and what other actions should be taken.  The 
	  general idea is modeled after the one used in RFC 2003,
	  "IP Encapsulation with IP":
		- The outer IP header Source Address and Destination
		  Address identify the "endpoints" of the tunnel (the
		  encapsulator and decapsulator).  The inner IP header
		  Source Address and Destination Addresses identify the
		  original sender and recipient of the datagram,
		  respectively.
		- The inner IP header is not changed except to decrement
       		  the TTL as noted below, and remains unchanged during
       		  its delivery to the tunnel exit point.  
		- No change to IP options or extension headers in the
       		  inner header occurs during delivery of the
       		  encapsulated datagram through the tunnel.
		- If need be, other protocol headers such as the IP
		  Authentication header [1] may be inserted between the
		  outer IP header and the inner IP header.

	  The tables in the following sub-sections show the handling for
	  the different header/option fields (constructed = the value in
	  the outer field is constructed independently of the value in
	  the inner):


5.1.2.1 IPv4 -- Header construction for tunnel mode

                     <-------- How Outer Hdr Relates to Inner Hdr --------->
IPv4                 Outer Hdr at Encapsulator    Inner Hdr at Decapsulator
  Header fields
    version          4 or 6 (1)                   no change
    header length    constructed                  no change
    TOS              copied from inner hdr        no change
    total length     constructed                  no change
    ID               constructed                  no change
    flags (DF,MF)    constructed, DF copie        no change
    fragmt offset    constructed                  no change
    TTL              copy from inner header (2)   copy from outer hdr (2) &
                     decrement before forwarding  decrement before forwarding
    protocol         AH, ESP, routing hdr         no change
    checksum         constructed                  no change
    src address      constructed (3)              no change
    dest address     constructed (3)              no change
  Options            never copied                 no change

	1. The IP version in the encapsulating header can be different
           from the value in the inner header.
	2. In order to support dynamic (rather than manual) set up of
	   tunnels, the TTL (or hop count) must be processable by the
	   receiver without requiring coordination with the sender, etc.
	   In particular multicast traffic should not require preconfigured
	   tunnels.  The TTL (or hop count) is decremented at each hop
	   in the tunnel as well as at the encapsulator and
	   decapsulator.
	3. src and dst addresses depend on the SA, which is used to
           determine the dst address which in turn determines which src
           address (net interface) is used to forward the packet.

5.1.2.2 IPv6 -- Header construction for tunnel mode

  See previous section 5.1.2 for notes indicated by (#).

                     <-------- How Outer Hdr Relates to Inner Hdr --------->
IPv6                 Outer Hdr at Encapsulator    Inner Hdr at Decapsulator
  Header fields:
    version          6                            no change
    priority         copy or configure            no change
    flow id          copy or configure            no change
    len              construct                    no change
    next header      AH,ESP,routing hdr           no change
    hop count        copy from inner hdr (2) &    copy from outer hdr (2) &
                     decrement before forwarding  decrement before forwarding 
    src address      constructed (3)              no change
    dest address     constructed (3)              no change
  Extension headers  never copied                 no change

=============================================================================
11. Multicast clarification.			        
						        
   Following up on discussion at the Munich IETF, we propose to modify
   Section 4.7 "Security Associations and Multicast":
	a) delete the last 2 sentences of paragraph 2, which describe
	   the case of using asymmetric cryptographic algorithsm.
	b) replace the third paragraph with "Other cases of multicast
	   will be addressed in other documents."
	
=============================================================================
12. How should we ensure interoperable mapping of key material to keys?

    We propose adding the following text to Section 4.6.2 "Automatic
    Techniques -- Key Mgt Protocol Requirements"

	"Multiple keys may be needed for a single ESP SA, either because
	the encryption algorithm uses multiple keys (e.g., triple DES)
	or because both encryption and authentication algorithms are
	employed.  The Key Management System may provide a seprate
	string of bits for each key or it may generate one string of
	bits from which all of them are extracted.  If a single string
	of bits is provided, care needs to be taken to ensure that the
	parts of the system that map the string of bits to the required
	keys do so in the same fashion at both ends of the SA.  To
	ensure that the IPsec implementations at each end of the SA use
	the same bits for the same keys, and irrespective of which part
	of the system divides the string of bits into individual keys,
	the encryption keys MUST be taken from the first (left-most,
	high-order) bits and the authentication key(s) MUST be taken
	from the remaining bits.  The number of bits for each key is
	defined in the relevant algorithm specification RFC.  In the
	case of multiple encryption keys, the specification for the
	encryption algorithm must specify the order in which they are to
	be selected from a single string of bits provided to the
	algorithm."

=============================================================================
13. In *TRANSPORT MODE*, allowing arbitrary ordering of IPsec headers.

   Following up on the mailing list discussion on nesting IPsec headers
   (8/22 to 8/30), we propose to modify the Architecture document by:

   a) Adding a section in Outbound Processing --> 5.1.3, "Header nesting
      for transport mode" that says:

       "If more than one IPsec header/extension is required:
          o the order of nesting of the security headers MUST be
            defined by security policy
          o The following 3 cases MUST be supported:
             1. [IP][AH][upper]
             2. [IP][ESP][upper]
             3. [IP][AH][ESP][upper]
          o arbitrary nesting is allowed -- Senders MAY generate
            arbitrary nestings of IPsec headers and Receivers SHOULD
            accept arbitrary nestings of IPsec headers.

        Support for arbitrary nesting requires that implementations
	ensure that any mutable "AH protected" fields outside/above the
	AH header, i.e., IP length, IP Next Protocol and any IPsec
	headers, are appropriately handled by Outbound and Inbound
	processing as the headers are nested and unnested.  To ensure
	interoperability, the implementation should ignore the existence
	(i.e., neither zero the contents nor try to predict the contents) of
	IPsec headers to be applied later when
	  o constructing an IPsec header
	  o adjusting the IP length and IP Next Protocol in the IP
	    header or immediately preceding IP extension header

	This will apply to:
             [IP][ESP or AH][ESP or AH]...[ESP or AH] [AH][upper]

	Nesting involving only ESP headers should not be problematic:
             [IP][ESP][ESP]...[ESP][upper]

	(While a native IP or bump-in-the-stack implementation could
        predict the contents of later IPsec headers that it applies
        itself, it won't be possible for it to predict any IPsec headers
        added by a bump-in-the-wire implementation between the host and
        the network.)"

   b) In Section 5.2 "Processing Inbound IPsec Traffic", adding the
      following text:

        "If there is more than one IPsec header/extension present, the
        processing for each one ignores (does not zero, does not use)
        any IPsec headers applied subsequent to the header being
        processed."

=============================================================================
14. Revision of Section 4. "Security Associations"

    Following up on discussions at the Munich IETF, subsequent email,
    etc., this section will be rewritten to:
	o remove the Security Association Map (section 4.4.2 "Security
	  Association Outbound Processing) from the design because of
	  problems identified by several people on the list.
	o revise the Selectors section to reconcile the selectors for
	  SAs defined in the IPsec Architecture document, the ID ranges
	  for SAs defined in the IPsec DOI for ISAKMP, and the name
	  forms in certificates.
	o add the following attributes to the Security Association
	  Database:
		- Anti-replay window size
		- Largest valid (has passed ICV check) sequence number
		  seen (receiver only)
		- Sequence Number counter (sender only)
	o address the question "Should the architecture allow a single
	  SA to alternate between transport and tunnel mode for
	  different packets?"  Following up on email from Dan McDonald
	  (9/21)...
		"It is my opinion that, while there are processing
		differences between transport and tunnel modes of IPsec,
		to explicitly distinguish them as an SA attribute is
		wrong.  They should be "Selectors" in your abstraction
		of the Security Policy Database.  I may wish to use a
		pair of SAs for both tunnel mode and transport mode
		simultaneously.  The differences between tunnel and
		transport mode are important, but they should be
		indicated with respect to processing and policy decision
		making, rather than be an explicit SA attribute."
	   We propose to:
		- add IPsec protocol mode (transport or tunnel) to the
		  Security Policy Database (SPD).
		- remove the "IPsec protocol mode (transport or tunnel)"
		  as an SA attribute from Section 4.4.4 "Security
		  Association Database (SAD)"

=============================================================================
15. Per email from Dan McDonald 9/21...

    We propose to give GKMP as an example of work in progress for
    multicast key distribution in section 4.7.  However, per IETF
    requirements for RFCs, we won't be able to formally cite it unless
    there is an RFC.

=============================================================================
16. Per email from Dan McDonald 9/21...

    We propose to add a note to the appendix on PMTU/DF processing: 

    	"If a bump-in-the-stack implementation of IPsec attempts to
	apply different IPsec algorithms based on source/destination
	ports, it will be difficult to apply Path MTU adjustments."

=============================================================================
17. Per Dan McDonald 9/21...

    Text will be added to section 11. "Performance Issues":
	
   	"The initial SA establishment overhead will be felt in the first
	packet.  This delay could impact the transport layer and
	application.  For example, it could cause TCP to retransmit the
	SYN before the ISAKMP exchange is done.  The effect of the delay
	would be different on UDP than TCP because TCP shouldn't
	transmit anything other than the SYN until the connection is set
	up whereas UDP will go ahead and transmit data beyond the 1st
	packet."

=============================================================================
18. Should the IPsec architecture support enforcement of
    receiver-specified security policies?

    Per Charlie Lynn, 

	"There is a need for a mechanism for a receiver to specify what
	IPsec services MUST be present for a given traffic stream, based
	on (post-IPsec processing) packet selectors."

    Per Dan McDonald 9/21, 

	"Consider the security gateway example...

		<subnet a.b.c/24> -- SG ==(The Internet)== SG' -- <a.b.d/24>

	...SG may accept legitimate SA establishment requests from
	parties other than SG'.  If this is so, it is CRUCIAL that SG
	take care that a malicious party M doesn't use its legitimate
	SAs to tunnel forged packets from a.b.d.X to a.b.c.Y.  A naive
	SG implementation may say "Oh, it was decrypted, of COURSE I can
	forward the inner packet" regardless of WHICH PEER SG sent it."

    [I.e., there's another security gateway SG" which has an SA with SG.
    And M is behind SG" but pretending to be a host behind SG'.]

    To address their concerns, we propose to make the following changes
	o modify section 4.4.1 "The Security Policy Database (SPD)"
		- end of paragraph 2, add the sentence: "This applies to
		  the IPsec protection to be applied by a sender and to
		  the IPsec protection that must be present at the
		  receiver.
		- paragraph 3, 1st sentence, change from "For every
		  IPsec implementation, there MUST be some form of
		  administrative interface...." to "For every IPsec
		  implementation, there MUST be some form of
		  administrative interface for both outbound and inbound
		  traffic ...

	o include the following text in section 5.2 "Processing Inbound
	  Traffic":
		  "For each packet, its SA attributes (IPsec protocol,
		  etc.) must be recorded to allow them to be checked
		  against the receiver's security policy.  Care must be
		  taken to do this for all IPsec headers that are
		  present including those that are nested.  After all
		  IPsec processing has been completed, the receiver
		  looks up the packet's selectors in its inbound
		  security policy database and verifies that the
		  required IPsec protection was present in the given
		  packet.  If not, it discards the packet."



Follow-Ups: