[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPsec Arch draft
Folks,
Following up on recent mailing list discussions, we've made the changes
below to the IPsec Architecture document and submitted the draft to IETF
secretariat.
Thank you,
Karen
1. Per email from Fukumoto Atsushi, we've fixed several may/MAY errors.
Section "5.2.1 Selecting and Using an SA or SA Bundle", item 2,
4th sentence -- changed "MAY" to "may"
From:
2. Use the SA found in (1) to do the IPsec processing...
In general, a packet's source address MUST match the SA
selector value. However, an ICMP packet received on a tunnel
mode SA MAY have a source address other than that bound to
***
the SA and thus such packets should be permitted as
exceptions to this check. For an ICMP packet, the selectors
from the enclosed problem packet (the source and destination
addresses and ports should be swapped) should be checked
against the selectors for the SA....
To:
2. Use the SA found in (1) to do the IPsec processing...
In general, a packet's source address MUST match the SA
selector value. However, an ICMP packet received on a tunnel
mode SA may have a source address other than that bound to
the SA and thus such packets should be permitted as
exceptions to this check. For an ICMP packet, the selectors
from the enclosed problem packet (the source and destination
addresses and ports should be swapped) should be checked
against the selectors for the SA....
Section "6.1.2.1 Propagation of PMTU", 2nd bullet -- changed
"MAY" to "may"
From:
o PMTU message with >64 bits of IPsec header -- If the ICMP
message contains more information from the original packet
then there MAY be enough non-opaque information...
***
To:
o PMTU message with >64 bits of IPsec header -- If the ICMP
message contains more information from the original packet
then there may be enough non-opaque information ...
Section "B.3.1 Identifying the Originating Host(s)", last paragraph --
changed "MAY" to "may"
From:
Since only the latter approach is feasible in all instances, a
security gateway MUST provide such support, as an option.
However, if the ICMP message contains more information from the
original packet, then there MAY be enough information to
***
immediately determine to which host to propagate the ICMP/PMTU
message and to provide that system with the 5 fields (source
address, destination address, source port, destination port, and
transport protocol) needed to determine where to store/update
the PMTU. Under such circumstances, a security gateway MUST
generate an ICMP PMTU message immediately upon receipt of an
ICMP PMTU from further down the path. NOTE: The Next Protocol
field MAY not be contained in the ICMP message and the use of
***
ESP encryption MAY hide the selector fields that have been
***
encrypted.
To:
Since only the latter approach is feasible in all instances, a
security gateway MUST provide such support, as an option.
However, if the ICMP message contains more information from the
original packet, then there may be enough information to
immediately determine to which host to propagate the ICMP/PMTU
message and to provide that system with the 5 fields (source
address, destination address, source port, destination port, and
transport protocol) needed to determine where to store/update
the PMTU. Under such circumstances, a security gateway MUST
generate an ICMP PMTU message immediately upon receipt of an
ICMP PMTU from further down the path. NOTE: The Next Protocol
field may not be contained in the ICMP message and the use of
ESP encryption may hide the selector fields that have been
encrypted.
2. Section "B.2 Fragmentation", first paragraph -- Per email from Karen
Heron, clarified when to fragment by changing this section to match
the text in AH (3.3.4) and ESP (3.3.5) documents:
From:
Fragmentation MUST be done after outbound IPsec processing.
Reassembly MUST be done before inbound IPsec processing. The
general reasoning is shown below (delimited by the ****'s).
To:
If required, IP fragmentation occurs after IPsec processing
within an IPsec implementation. Thus, transport mode AH or ESP
is applied only to whole IP datagrams (not to IP fragments). An
IP packet to which AH or ESP has been applied may itself be
fragmented by routers en route, and such fragments MUST be
reassembled prior to IPsec processing at a receiver. In tunnel
mode, AH or ESP is applied to an IP packet, the payload of which
may be a fragmented IP packet. For example, a security gateway,
"bump-in-the-stack" (BITS), or "bump-in-the-wire" (BITW)
IPsec implementation may apply tunnel mode AH to such fragments.
Note that a BITS or BITW implementation are examples of where a
host IPsec implementation might receive fragments to which
tunnel mode is to be applied. However, if transport mode is to
be applied, then these implementations MUST reassemble the
fragments prior to applying IPsec.
3. Section "4.4.3 Security Association Database (SAD)" -- Per email from
the community, changed the following text to clarify what units to
use for SA Lifetime.
From:
o Lifetime of this Security Association: a time interval after
which an SA must be replaced with a new SA (and new SPI) or
terminated, plus an indication of which of these actions
should occur. This may be expressed as a time or byte count.
If time....
To:
o Lifetime of this Security Association: a time interval after
which an SA must be replaced with a new SA (and new SPI) or
terminated, plus an indication of which of these actions
should occur. This may be expressed as a time or byte count,
or a simultaneous use of both, the first lifetime to expire
taking precedence. A compliant implementation MUST support
both types of lifetimes, and must support a simultaneous use
of both. If time...