[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Architecture draft
Folks,
Here is a summary of the changes we've made to the IPsec Architecture
draft. We've tried to include all the comments/feedback received over
the past few weeks, but there were a few issues that came up at the last
minute which have not yet been resolved (waiting for feedback from the
community, etc.) and which therefore did not get addressed in this
version. In addition, there is still some text that could benefit from
additional clarification. Unfortunately, because of the small amount of
time between when we received the comments and today's deadline, we had
to focus on addressing the issues that seemed substantive or that were
just straightforward changes/corrections. Please accept our apologies
if we've missed any other comments/corrections.
At the request of the WG Chairs, we are sending the draft to both
the IETF secretariat and directly to the mailing list (to minimize
delays.) This latest version is:
draft-ietf-ipsec-arch-sec-04.txt.
Thank you,
Karen
===========================================================================
1. Typos/clarifications:
------------------------
Section 1.1 Summary of Contents of Document
fixed formatting of item c.
Section 1.3 Related Documents
fixed formatting of item d.
Section 4.3 Combining Security Associations -- per H. Redelmeier
changed first bullet of second paragraph from:
o Transport adjacency refers to applying more than one
security protocol to the same IP datagram, without
invoking tunneling. This approach to combining AH and
ESP allows for only one level of combination; further
nesting yields no added benefit since the processing
is performed at one IPsec instance at the (ultimate)
destination.
to:
o Transport adjacency refers to applying more than one
security protocol to the same IP datagram, without
invoking tunneling. This approach to combining AH and
ESP allows for only one level of combination; further
nesting yields no added benefit (assuming use of
adequately strong algorithms in each protocol) since
the processing is performed at one IPsec instance at
the (ultimate) destination.
changed 3rd paragraph from:
These two approaches also can be combined, i.e., an SA
bundle could be constructed from one tunnel mode SA and
one or two transport mode SAs, applied in sequence.
to:
These two approaches also can be combined, e.g., an SA
bundle could be constructed from one tunnel mode SA and
one or two transport mode SAs, applied in sequence.
Section 4.4.1 The Security Policy Database (SPD) -- per H. Redelmeier
changed 3rd paragraph to clarify why it is feasible to specify
that security processing be applied on a "packet by packet
basis":
For every IPsec implementation, there MUST be an
administrative interface that allows a user or system
administrator to manage the SPD. This interface must
allow the user (or system administrator) to specify the
security processing to be applied to each packet
entering or exiting the system, on a packet by packet
basis. (In a host IPsec implementation making use of a
socket interface, the SPD may not need to be consulted
on a per packet basis, but the effect is still the
same.) The management interface for the SPD MUST allow
creation of entries consistent with the selectors
defined in Section 4.4.2, and MUST support ordering of
these entries.
to:
For every IPsec implementation, there MUST be an
administrative interface that allows a user or system
administrator to manage the SPD. Specifically, every
inbound or outbound packet is subject to processing by
IPsec and the SPD must specify what action will be taken
in each case. Thus the administrative interface must
allow the user (or system administrator) to specify the
security processing to be applied to any packet entering
or exiting the system, on a packet by packet basis. (In
a host IPsec implementation making use of a socket
interface, the SPD may not need to be consulted on a per
packet basis, but the effect is still the same.) The
management interface for the SPD MUST allow creation of
entries consistent with the selectors defined in Section
4.4.2, and MUST support (total) ordering of these
entries. It is expected that through the use of
wildcards in various selector fields, and because all
packets on a single UDP or TCP connection will tend to
match a single SPD entry, this requirement will not
impose an unreasonably detailed level of SPD
specification. The selectors are analogous to what are
found in a stateless firewall or filtering router and
which are currently manageable this way.
Section 4.4.2 Selectors -- paragraph on "Name" -- per D. Piper
changed "Note that these name forms are supported in ISAKMP"
to "Note that these name forms are supported in the IPsec DOI"
changed "[REQUIRED for...."
to "[REQUIRED for the following cases...."
Section 4.5 Basic Combinations of Security Associations --per Kai Martius
changed last sentence of Case 4 from:
The details of support for this case, (how H1 locates
SG2, authenticates it, and verifies its authorization to
represent H2) are discussed in Section 4.4.3, "Locating
a Security Gateway".
to
The details of support for this case, (how H1 locates
SG2, authenticates it, and verifies its authorization to
represent H2) are discussed in Section 4.6.3, "Locating
a Security Gateway".
Section 4.6.3 Locating a Security Gateway -- per Kai Martius
fixed last word of next to last paragraph from:
It is assumed that the SPD is also configured with
policy information that covers any other IPsec
requirements for the path to the security gateway and
the destination hos.
to
It is assumed that the SPD is also configured with
policy information that covers any other IPsec
requirements for the path to the security gateway and
the destination host.
Section 5.1.2 Header Construction for Tunnel Mode -- per H. Redelmeier
changed first bullet to clarify the meaning of "original" in
the presence of tunneling within tunneling:
o 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....
to
o 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, (from
the perspective of this tunnel), respectively....
Section 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode -- per
Indermohan Singh Monga
changed table entry for checksum from:
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
...... ...... ......
checksum constructed no change
...... ...... ......
to:
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
...... ...... ......
checksum constructed constructed (2)
...... ...... ......
changed footnote (2) from:
2. The TTL in the inner header is decremented by the
encapsulator prior to forwarding and by the
decapsulator if it forwards the packet. (The
checksum changes when the TTL changes.)
Acknowledgements -- per H. Redelmeier
removed space after comma and changed 2 years to 3 years:
For over 2 years (although it sometimes seems *much*
longer) , this....
to
For over 3 years (although it sometimes seems *much*
longer), this....
Appendix C -- per H. Redelmeier
changed each occurrence of "(1 << diff)" to "((u_long)1 << diff)"
left "test harness" as is -- received no comments
2. Modify to make ESP encryption/confidentiality optional -- per co-chairs
--------------------------------------------------------------------------
Section 3.2 How IPsec Works
changed 1st paragraph, second bullet from:
o The Encapsulating Security Payload (ESP) protocol
[KA98b] provides confidentiality (encryption), and
limited traffic flow confidentiality. It also may
provide connectionless integrity, data origin
authentication, and an anti-replay service.
to:
o The Encapsulating Security Payload (ESP) protocol
[KA98b] may provide confidentiality (encryption), and
limited traffic flow confidentiality. It also may
provide connectionless integrity, data origin
authentication, and an anti-replay service. (One or
the other set of these security services must be applied
whenever ESP is invoked.)
Section 4.2 Security Association Functionality
changed first and last sentences of the 3rd paragraph from:
"ESP always provides confidentiality for traffic.
(However, the strength of the confidentiality service
will depend, in part, on the encryption algorithm
employed.) ESP also may optionally provide
authentication (as defined above). If authentication is
negotiated for an ESP SA, the receiver also may elect to
enforce an anti-replay service with the same features as
the AH anti-replay service. The scope of the
authentication offered by ESP is narrower than for AH,
i.e., the IP header(s) "below" the ESP header is not
protected. If only the upper layer protocols need to be
authenticated, then ESP authentication is an appropriate
choice and is more space efficient than use of AH
encapsulating ESP."
to
"ESP optionally provides confidentiality for traffic.
(The strength of the confidentiality service depends
in part, on the encryption algorithm employed.) ESP
also may optionally provide authentication (as defined
above). If authentication is negotiated for an ESP SA,
the receiver also may elect to enforce an anti-replay
service with the same features as the AH anti-replay
service. The scope of the authentication offered by ESP
is narrower than for AH, i.e., the IP header(s) "below"
the ESP header is(are) not protected. If only the upper
layer protocols need to be authenticated, then ESP
authentication is an appropriate choice and is more
space efficient than use of AH encapsulating ESP. Note
that although both confidentiality and authentication
are optional, they cannot both be omitted. At least one
of them MUST be selected.
Section 4.4.1 The Security Policy Database (SPD)
added the following text after paragraph 8 ("As described
below..."
Note that if ESP is specified, either (but not both)
authentication or encryption can be omitted. So it MUST
be possible to configure the SPD value for the
authentication or encryption algorithms to be "NULL".
However, at least one of these services MUST be
selected, i.e., it MUST NOT be possible to configure
both of them as "NULL".
Section 4.4.3 Security Association Database (SAD)
added the following text at the end of paragraph 1 "For each of
the selectors defined in Section 4.4.2..."
Note that for an ESP SA, either the encryption algorithm
or the authentication algorithm can be "NULL". However
they MUST NOT both be "NULL".
3. Mention IPSec DOI support for IP compression negotiation
------------------------------------------------------------
Section 3.1 What IPsec Does
changed 4th paragraph from:
NOTE: When encryption is employed within IPsec, it
prevents effective compression by lower protocol layers.
However, IPsec does not provide its own compression
services. Such services may be provided by existing
higher layer protocols, or, in the future, in IP itself.
The IETF working group, "IP Payload Compression Protocol
(ippcp)" has the charter to "develop protocol
specifications that make it possible to perform lossless
compression on individual payloads before the payload is
processed by a protocol that encrypts it. These
specifications will allow for compression operations to
be performed prior to the encryption of a payload by
such protocols as IPsec."
to;
The IPsec DOI supports negotiation of IP compression,
motivated in part by the observation that when
encryption is employed within IPsec, it prevents
effective compression by lower protocol layers. The IETF
working group "IP Payload Compression Protocol (ippcp)"
has the charter to "develop protocol specifications that
make it possible to perform lossless compression on
individual payloads before the payload is processed by a
protocol that encrypts it. These specifications will
allow for compression operations to be performed prior
to the encryption of a payload by such protocols as
IPsec."