[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPsec Architecture -- List of changes
Folks,
At the direction of the working group chairs, we're posting the IPsec
Architecture draft directly to the mailing list to minimize delays. (It
is also being sent to the secretariat.) The chairs ask everyone to
please review and comment as quickly as possible.
This draft has been significantly changed from the previous draft. The
following list summarizes some of the changes. Please note that we did
not always use the exact edit/text proposed in the 10/7 email. We also
made edits, corrections, and clarifications which are not on this list.
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).
** The references were left 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.?
** We shortened the problem description in Section 4.6.3 "Locating a
Security Gateway" and added text stating that "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....." And
that "This document does not address the issue of how to automate the
discovery/verification of security gateways."
=============================================================================
3. How should we handle MLS issues?
** We have inserted the MLS text supplied on 11/6 by Dan McDonald et al.
It is now section 8 and has been re-titled "Use in Systems Supporting
Information Flow Security". A few minor edits were made to reflect
changes to other parts of the document.
=============================================================================
4. Clarification about using a different SPI when a new SA is created
because of rekeying...
** We have replaced the phrase "rekey" with "replace" or otherwise
clarified the text.
=============================================================================
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?
** We have added 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?
** A new selector paragraph has been added to section 4.4.3 "Selectors":
for "IPsec protocol (AH or ESP or AH/ESP)"
=============================================================================
7. Should the "Transport Protocol" selector be required only for systems
supporting IPv6, and be optional for IPv4?
** We have modified the Transport Protocol paragraphs of section 4.4.3
"Selectors" to be "[REQUIRED for IPv6 implementations, MAY be
supported in IPv4 implementations]"
=============================================================================
8. Additional selector changes -- adding TOS and renaming IPv6
"Priority" to "Class".
** Added the text:
IPv4 Type of Service (TOS): Obtained from the IPv4 header. This
may be expressed as a wildcard or an explicit value.
[REQUIRED for all systems that implement IPv4]
** Changed "IPv6 Priority..." to "IPv6 Class..."
=============================================================================
9. Additional warnings that certain selectors may not always be
accessible....
** We added text to section 4.4.3 "Selectors" indicating that "in the
case of receipt of a packet with an ESP header....the transport layer
protocol and source/destination ports may be opaque, thus making them
unavailable for use as selectors."
=============================================================================
10. How should we handle header copying in tunnel mode?
** We have modified the text to more closely follow the model used in
RFC 2003 "IP Encapsulation with IP". This RFC minimizes the
complexity of this problem by generally not copying options, e.g.,
source routing. The TTL is also no longer being copied.
=============================================================================
11. Multicast clarification.
** Clarified Section 4.7 "Security Associations and Multicast"
=============================================================================
12. How should we ensure interoperable mapping of key material to keys?
** Text has been added to Section 4.6.2 "Automatic Techniques -- Key Mgt
Protocol Requirements" to clarify how key material is to be mapped to
keys to ensure interoperability.
=============================================================================
13. In *TRANSPORT MODE*, allowing arbitrary ordering of IPsec headers?
** The draft has been altered to support:
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
and any one of 1, 2, 3, above 4 or 5.
=============================================================================
14. Revision of Section 4. "Security Associations"
** Section 4, 5, 6 have been revised:
o removed 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 added the following attributes to the Security Association
Database:
- Anti-replay window size
- Largest valid (has passed ICV check) sequence number
seen (receiver only)
- Path MTU information
o added IPsec protocol mode (transport or tunnel or wildcard) to
the Security Policy Database (SPD).
o enabled an SA to be used by more than one policy
o enabled specification of which of the following values should
used for each selector in the SA: (a) the value in the packet,
(b) the value associated with the policy, or (c) a wildcard.
o clarified the details of mapping and checking between
packet, SPD, and SAD.
o added to Section 6 (ICMP)
We did not remove the IPsec protocol mode (transport, tunnel or
wildcard) as an SA attribute from Section 4.4.4 "Security Association
Database (SAD)". If an SA is to be used for both modes, the SA
"mode" selector can be set to wildcard.
=============================================================================
15. Per email from Dan McDonald 9/21...
** We added GKMP as an example of work in progress for multicast key
distribution in section 4.7.
=============================================================================
16. Per email from Dan McDonald 9/21...
** We added 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 was added to section 9. "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 first
packet."
=============================================================================
18. Should the IPsec architecture support checking of the selectors by
the receiver and the enforcement of receiver-specified security
policies?
** Modified Section 4 "Security Associations" and Section 5.2
"Processing Inbound Traffic" to support checking of the selectors by
the receiver and the enforcement of receiver-specified security
policies?
=============================================================================
19. SPI ranges -- need to think more about reserved range for multicast
** NO changes made; a reserved range does not appear to provide much
benefit.
=============================================================================
20. ICMPs -- entering ends of tunnels
** Modified section 4 and 5 to enable better handling of ICMPs from beyond
the end of a tunnel.
=============================================================================
21. Unneeded sections
** Removed the following sections:
7. Algorithm Descriptions
8. Usage Scenarios..
=============================================================================
22. ICMP processing
** Modified Section 6 to provide direction on handling ICMP messages
besides ICMP PMTU.