1 Dec 2004 10:15
Issue on Phase 2 handler
Park Lee <parklee_sel <at> yahoo.com>
2004-12-01 09:15:43 GMT
2004-12-01 09:15:43 GMT
Hi,
When we've unpacked the ipsec-tools-0.2.5.tar.gz, In ipsec-tools-0.2.5/src/racoon/handler.h, we can see something like the following:
/* Phase 2 handler */
/* allocated per a SA or SA bundles of a pair of peer's IP addresses. */
/*
* initiator responder
* 0 (---) (---)
&nbssp;* 1 start start (1st msg received)
* 2 acquire msg get 1st valid msg received
* 3 getspi request sent getspi request sent
* 4 getspi done getspi done
* 5 1st msg sent 1st msg sent
* 6 1st valid msg received 2nd valid msg received
* 7 (commit bit) (commit bit)
* 8 SAs added SAs added
* 9 SAs established SAs established
* 10 SAs expired SAs expired
*/
/* allocated per a SA or SA bundles of a pair of peer's IP addresses. */
/*
* initiator responder
* 0 (---) (---)
&nbssp;* 1 start start (1st msg received)
* 2 acquire msg get 1st valid msg received
* 3 getspi request sent getspi request sent
* 4 getspi done getspi done
* 5 1st msg sent 1st msg sent
* 6 1st valid msg received 2nd valid msg received
* 7 (commit bit) (commit bit)
* 8 SAs added SAs added
* 9 SAs established SAs established
* 10 SAs expired SAs expired
*/
Then,
1), Since the initiator only send one message (step 5), why should the responder receive two messages (step 2 and step 6)?
2), We know that before initiator begins its negotiation with responder, it will send an SADB_GETSPI message from a user process to the kernel for an SPI. When it get the SPI, it can begins its negotiation.
But here, Why should the responder also send an SADB_GETSPI (step 3 and step 4)? Is it still send the message to its kernel? Why don't it use the SPI from the initiator? If the responder get its own SPI, then there will be two different SPI between the initiator and responder, which one will they finally use?
1), Since the initiator only send one message (step 5), why should the responder receive two messages (step 2 and step 6)?
2), We know that before initiator begins its negotiation with responder, it will send an SADB_GETSPI message from a user process to the kernel for an SPI. When it get the SPI, it can begins its negotiation.
But here, Why should the responder also send an SADB_GETSPI (step 3 and step 4)? Is it still send the message to its kernel? Why don't it use the SPI from the initiator? If the responder get its own SPI, then there will be two different SPI between the initiator and responder, which one will they finally use?
Thank you.
Do you Yahoo!?
Meet the all-new My Yahoo!
_______________________________________________ Ipsec mailing list Ipsec <at> ietf.org https://www1.ietf.org/mailman/listinfo/ipsec
.
Please note:
1. On November 12th, Steve Kent requested a poll of the working group
to confirm which option we should put into 2401bis for handling of
BYPASS'd fragments.
However, there wasn't any subsequent poll/consensus as to whether to
make the change below that Mark Duffy proposed for Section 7.4
BYPASS/DISCARD traffic, sentence 2, so I didn't change the text.
From:
An implementation MUST support stateful fragment checking to
accommodate BYPASS traffic for which a non-trivial port
range is specified.
To:
An implementation MUST NOT forward fragmented BYPASS traffic
without performing stateful fragment checking.
2. All changes below after the 2 rows of ==== were made based on
feedback from Russ Housley during the current working group last
call. Hence they didn't show up on the list
Thank you,
Karen
===========================================================================
Section 5.1 "Outbound IP Traffic Processing (protected-to-unprotected)" --
restored the following NOTE after step 4. I also inserted some new
text saying that "(This applies only to IPv4. For IPv6 packets, only
the originator is allowed to fragment them.)"
Note: With the exception of IPv4 and IPv6 transport mode,
an SG, BITS, or BITW implementation MAY fragment packets
before applying IPsec. (This applies only to IPv4. For IPv6
packets, only the originator is allowed to fragment them.)
The device SHOULD have a configuration setting to disable
this. The resulting fragments are evaluated against the SPD
in the normal manner. Thus, fragments not containing port
numbers (or ICMP message type and code, or Mobility Header
type) will only match rules having port (or ICMP message type
and code, or MH type) selectors of OPAQUE or ANY. (See section
7 for more details.)
===========================================================================
Appendix B.1 -- clarified text by changing the 2nd sentence:
From:
In appendix B.1: "The resulting entries that are decorrelated
with the decorrelated set of entries are then added to that
decorrelated set."
To:
The nodes of the tree are the selectors that may overlap
between the policies. At each node, the algorithm creates a
branch for each of the values of the selector. It also
creates one branch for the complement of the union of all
selector values. Policies are then formed by traversing the
tree from the root to each leaf. The policies at the leaves
are compared to the set of already decorrelated policy rules.
Each policy at a leaf is either completely overridden by a
policy in the already decorrelated set and is discarded or
is decorrelated with all the policies in the decorrelated set
and is added to it.
===========================================================================
Section 4.4.1 "The Security Policy Database (SPD)", subsection on
"How To Derive the Values for an SAD entry" -- Changed:
From:
For each selector in an SPD entry, the entry specifies how to
derive the corresponding values for a new Security Association
Database (SAD, see Section 4.4.2) entry from those in the SPD
and the packet. The goal is to allow an SAD entry and an SPD
cache entry to be created based on specific selector values
from the packet, or from the matching SPD entry. For outbound
traffic, there are SPD-S cache entries and SPD-O cache entries.
For inbound traffic, there are SPD-I cache entries and there
is the SAD, which represents the cache for inbound
IPsec-protected traffic (See Figure 3 in Section 5.2).
To:
For each selector in an SPD entry, the entry specifies how to
derive the corresponding values for a new Security Association
Database (SAD, see Section 4.4.2) entry from those in the SPD
and the packet. The goal is to allow an SAD entry and an SPD
cache entry to be created based on specific selector values
from the packet, or from the matching SPD entry. For outbound
traffic, there are SPD-S cache entries and SPD-O cache entries.
For inbound traffic not protected by IPsec, there are SPD-I
^^^^^^^^^^^^^^^^^^^^^^
cache entries and there is the SAD, which represents the cache
for inbound IPsec-protected traffic (See Figure 3 in Section
5.2).
===========================================================================
Section 7.4 BYPASS/DISCARD traffic and Section D.4 BYPASS/DROP
Traffic (last paragraph) -- corrected TCP port 25 (Telnet) to be TCP
port 23 (Telnet).
===========================================================================
Section 5. "IP Traffic Processing" -- Clarified that the mapping of
one cached SPD entry to one SA is not a consequence of decorrelation.
Added the following sentences at the end of the paragraph 1:
"For the purposes of this specification, it is
assumed that each cached entry will map to exactly
one SA. Note, however, exceptions arise when one
uses multiple SAs to carry traffic of different
priorities (e.g., as indicated by distinct DSCP
values) but the same selectors."
Changed paragraph 2, sentence 3 from:
But, if the SPD entries are first decorrelated, then the
resulting entries can safely be cached and each cached entry
will map to exactly one SA, or indicate that matching traffic
should be bypassed or discarded, appropriately.
To:
But, if the SPD entries are first decorrelated, then the
resulting entries can safely be cached. Each cached entry
will indicate that matching traffic should be bypassed or
discarded, appropriately.
===========================================================================
We made the following changes to clarify how the looping of traffic
protected by nested SAs is handled if there are multiple SPD-I's
Section 5.1 "Outbound IP Traffic Processing
(protected-to-unprotected)", step 4 -- Added the following sentences
at the end of step 4 (The packet is passed to....):
If necessary, i.e., if there is more than one SPD-I,
the traffic being looped back MAY be tagged as
coming from this internal interface. This would
allow the use of a different SPD-I for "real"
external traffic vs looped traffic, if needed.
Appendix E - "Example of Supporting Nested SAs via SPD and Forwarding
Table Entries", paragraph 1 -- Added the following sentence at the
end of this paragraph:
For simplicity, this example assumes just one SPD-I.
===========================================================================
Section 8.2.1 "Propagation of PMTU" -- Modified last sentence to
clarify when to send a PMTU ICMP message:
From:
When such traffic arrives, if the traffic would exceed the
updated PMTU value the traffic MUST be discarded and an
appropriate ICMP PMTU message sent.
To:
When such traffic arrives, if the traffic would exceed the
updated PMTU value the traffic MUST be handled as follows:
Case 1: Original (cleartext) packet is IPv4 and has the DF
bit set. The implementation SHOULD discard the packet
and send a PMTU ICMP message.
Case 2: Original (cleartext) packet is IPv4 and has the DF
bit clear. The implementation SHOULD fragment (before
orafter encryption per its configuration) and then
forward the fragments. It SHOULD NOT send a PMTU
ICMP message.
Case 3: Original (cleartext) packet is IPv6. The implementation
SHOULD discard the packet and send a PMTU ICMP message.
===========================================================================
Section D.3. The Problem of Non-Initial Fragments, -- Since Section
7.2 allows separate SAs to be used for non-initial fragments, we
modified the text that said the WG had "rejected" this option:
2nd paragraph, last sentence
From:
However, RFC 2401 did not provide detailed guidance on this
and thus it may not have been apparent that use of this
feature would essentially create a "non-initial fragment
only" SA, precisely the solution that the WG rejected.
To:
However, RFC 2401 did not provide detailed guidance on this
and thus it may not have been apparent that use of this
feature would essentially create a "non-initial fragment
only" SA.
3rd paragraph, 1st sentence
From:
In the course of rejecting the "fragment-only" SA approach,
it was noted that some subtle problems, problems not
considered in RFC 2401, would have to be avoided.
To:
In the course of discussing the "fragment-only" SA approach,
it was noted that some subtle problems, problems not
considered in RFC 2401, would have to be avoided.
Section D.6 "Other Suggested Solutions", paragraph 4:
From:
The Working Group rejected the convention of creating an SA
to carry only non-initial fragments, something that was
supported implicitly under the RFC 2401 model via use of
OPAQUE port fields, but never clearly articulated in the RFC
2401. The (rejected) text called for each non-initial
fragment to be treated as protocol 44 (the IPv6 fragment
header protocol ID) by the sender and receiver.
To:
The Working Group rejected an earlier version of the
convention of creating an SA to carry only non-initial
fragments, something that was supported implicitly under the
RFC 2401 model via use of OPAQUE port fields, but never
clearly articulated in the RFC 2401. The (rejected) text
called for each non-initial fragment to be treated as
protocol 44 (the IPv6 fragment header protocol ID) by the
sender and receiver.
===========================================================================
Section 13 "Differences from RFC 2401" -- Added the following bullet
o With respect to IP addresses and ports, the terms "Local"
and "Remote" are used for policy rules (replacing source
and destination). "Local" refers to the entity being
protected by an IPsec implementation, i.e., the "source"
address/port of outbound packets or the "destination"
address/port of inbound packets. "Remote" refers to a peer
entity or peer entities. The terms "source" and
"destination" are still used for packet header fields.
===========================================================================
Section 5.1 "Outbound IP Traffic Processing (protected to
unprotected)" -- Added back the following note after Step 4
NOTE: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or BITW
implementation MAY fragment packets before applying IPsec. The
device SHOULD have a configuration setting to disable this. The
resulting fragments are evaluated against the SPD in the normal
manner. Thus, fragments not containing port numbers (or ICMP message
type and code, or Mobility Header type) will only match rules having
port (or ICMP message type and code, or MH type) selectors of OPAQUE
or ANY. (See section 7 for more details.)
===========================================================================
===========================================================================
All the following changes were suggested by Russ Housley...
===========================================================================
===========================================================================
In addition to fixing typos that he caught, we made various edits
including but not limited to:
1. Spelled out acronyms -- NAT, ECN, DSCP, TCAM....
2. Used SA instead of Security Association after initial definition
3. Put in requests to RFC Editor to replace ?? with RFC numbers for
the various IDs that are about to become RFCs and which are in
the Reference section.
4. Changed all "Note" or "NOTE" to be consistently just one
style --> "Note:"
5. Tried to change SPD-I, SPD-O, SPD-S and SPD-ID to use non-breaking
hyphens, but I ran into a Microsoft Word glitch with this. So
I may have missed some.
6. Replaced "system"/"systems" with "implementation"/"implementations
in a number of places
7. Replaced "drop"/"DROP" with "discard"/"DISCARD" for consistency.
8. Replaced "2401bis" with phrases like "this document".
===========================================================================
Section 2.1, "Goals/Objectives/Requirements/Problem Description",
paragraph 5 -- Changed:
From:
A set of default cryptographic algorithms for use with AH and
ESP is specified in [Eas03] to facilitate interoperability in
the global Internet. The use of these cryptographic algorithms....
To:
To facilitate interoperability in the global Internet, a set
of default cryptographic algorithms for use with AH and ESP
is specified in [Eas03] and a set of mandatory-to-implement
algorithms for IKEv2 is specified in [Sch03]. [Eas03] and
[Sch03] will be periodically updated to keep pace with
computational and cryptologic advances. By specifying these
algorithms in documents that are separate from the AH, ESP,
and IKEv2 specifications, these algorithms can be updated or
replaced without affecting the standardization progress of
the rest of the IPsec document suite. The use of these
cryptographic algorithms...
===========================================================================
Section 3.2 "How IPsec Works", paragraph 1, bullet 2 -- changed
From:
o The Encapsulating Security Payload (ESP) protocol [Ken04a]
offers the same set of services, and also offers
confidentiality. Use of ESP in a confidentiality-only mode
is discouraged.
To:
o The Encapsulating Security Payload (ESP) protocol [Ken04a]
offers the same set of services, and also offers
confidentiality. Use of ESP to provide confidentiality
without integrity is NOT RECOMMENDED.
===========================================================================
Section 4.2 "Security Association Functionality" (changed in the rev
to SA Functionality), paragraph 2 -- changed
From:
For example, both AH and ESP offer integrity and authentication
services, but the coverage differs for each protocol and
differs for transport vs. tunnel mode. If the integrity of an
IPv4 option or IPv6 extension header must be protected en-route
between sender and receiver, AH can provide this service,
except for the mutable (non-predictable) parts of the IP or
extension headers.....
To:
For example, both AH and ESP offer integrity and authentication
services, but the coverage differs for each protocol and
differs for transport vs. tunnel mode. If the integrity of an
IPv4 option or IPv6 extension header must be protected en-route
between sender and receiver, AH can provide this service,
except for IP or extension headers that may change in a fashion
not predictable by the sender....
===========================================================================
Section 4.4.1.2 "Structure of an SPD entry", 1st sentence -- Changed
to indicate that the ASN.1 in Appendix C is an example, not normative.
From:
This section contains a prose description of an SPD entry.
Also, an ASN.1 definition of an SPD entry is provided in
Appendix C.
To:
This section contains a prose description of an SPD entry.
Also, Appendix C provides an example of an ASN.1 definition
of an SPD entry.
===========================================================================
Section 4.4.1.2 "Structure of an SPD entry", 2nd paragraph, 1st
sentence -- Changed:
From:
This text describes the SPD in a fashion that maps directly
into IKE payloads. One should not create SPD entries that
cannot be mapped into something that IKE can negotiate.
To:
This text describes the SPD in a fashion that maps directly
into IKE payloads to ensure that the policy required by SPD
entries can be negotiated through IKE.
===========================================================================
Section 4.4.1.2 "Structure of an SPD entry", paragraph 3, bullet 1 -- Changed
From:
o Name -- a list of IDs. This quasi-selector is optional.
To:
o Name -- a list of IDs. This quasi-selector is optional.
The forms that MUST be supported are described above in
Section 4.4.1.1 under "Name".
===========================================================================
Section 4.5 SA and Key Management, first sentence -- Changed as follows
From:
IPsec mandates support for both manual and automated SA and
cryptographic key management.
To:
All IPsec implementations MUST support both manual and
automated SA and cryptographic key management.
===========================================================================
Section 8.2.2 "PMTU Aging", paragraph 1 -- Changed as follows:
From:
In all IPsec implementations the PMTU associated with an
SA MUST be "aged" and some mechanism is required to update
the PMTU in a timely manner, especially for discovering if
the PMTU is smaller than it should be,
To:
In all IPsec implementations the PMTU associated with an
SA MUST be "aged" and some mechanism is required to update
the PMTU in a timely manner, especially for discovering if
the PMTU is smaller than required by current network conditions.
===========================================================================
Section 13. "Differences from RFC 2401" -- Changed as follows:
From:
o Support for AH in both IPv4 and IPv6 is now a MAY.
To:
o Support for AH in both IPv4 and IPv6 is no longer required.
Deleted redundant bullet:
o Text and an ASN.1 desription have been added to clarify
the structure of an SPD entry and its alignment with what
can be negotiated in IKEv2.
===========================================================================
Appendix C -- ASN.1 for an SPD Entry -- made about a dozen
corrections and changes. It should compile. Let me know if you want
the details.
RSS Feed