Subject: Re: [Ipsec] WORKING GROUP LAST CALL: draft-ietf-ipsec-rfc2401bis-03.txt

From: Mark Duffy <[email-masked]>
Date: Tue, 05 Oct 2004 16:02:40 -0400

At 10:10 PM 9/28/2004, Theodore Ts'o wrote:
>Many thanks to Stephen Kent and Karen Seo for submitting the updated
>version of the rfc2401bis-03.txt.  At this point, we believe that this
>document has addressed all pending issues that have been listed in the
>Issue Tracker.  So therefore, it is appropriate that we start a one
>week working group, starting today and terminating on Tuesday, October
>2nd.

I presume that was supposed to be Tues Oct *5*  :-)

Thank you Steve and Karen, this is coming together nicely!  Nonetheless, 
here are a bunch of comments...

--Mark

-------
In sect. 3.1 p. 8:

"In this document, the term "inbound" refers to traffic entering an IPsec 
implementation via the unprotected interface or emitted by the 
implementation on the unprotected side of the boundary and directed towards 
the unprotected interface."

I believe the next-to-last word there should be protected, not UNprotected.

-------
In sect 4.1 p. 13:

"A transport mode SA is a security association typically employed between a 
pair of hosts to provide end-to-end security services. When security is 
desired between two intermediate systems along a path (vs. end-to-end use 
of IPsec), transport mode MAY be used between security gateways or between 
a security gateway and a host.  In the latter case, transport mode may be 
used to support in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling 
[FaLiHaMeTr00]) over transport mode SAs."

The phrase "in the latter case" may have been meant to refer to "when 
security is desired between two intermediate systems" as distinct from 
"between a pair of hosts."  But, it can easily be read as referring to 
"between a security gateway and a host" vs. "between security gateways" and 
thereby stating that transport mode with in-IP tunneling may be used 
between an SG and a host but not between 2 SGs.  Since I don't think that's 
the intent I propose the following change:

s/In the latter case/In the case where transport mode is used between 
security gateways or between a security gateway and a host/
--------------

In sect. 4.4.1 re selectors (p. 20):

"Since the SPD-I is just a part of the SPD, the same rule applies here, 
i.e., if a packet that is looked up in the SPD-I cannot be matched to an 
entry there, then the packet MUST be discarded."

In this text, it is not clear to me what "the same rule applies here" is 
referring back to.  Perhaps this can be clarified or removed.
--------------------

Also in 4.4.1:  If I understand correctly, the SPD-S, SPD-I, and SPD-O are 
just subcategories of the overall SPD and in the ordered SPD these are all 
interleaved, is  that right?  If the SPD has been decorrelated the question 
doesn't really arise but if not decorrelated and working from an ordered 
SPD, it's not clear that it makes any sense to look in one of these without 
looking in all of them.  Perhaps the text can clarify this.

--------------------
In sect 4.4.1.1 (Selectors), Next Layer Protocol:  I believe that for IPv4 
the next layer protocol in the packet that is evaluated against the SPD is 
*always* the value in the Protocol field, i.e. there is no concept of 
skipping over any encapsulations.  I think the description here of skipping 
over extension headers should be clarified that it applies only to IPv6.

-------------------
In sect. 4.4.1.1 p 25-26, where it is describing selectors for ICMP type 
and code it talks about e.g. "The message type is placed in the most 
significant 8 bits of the 16-bit selector and the code is placed in the 
least significant 8 bits. ..."  There is similar text for the MH 
selector.  I don't think this is relevant for RFC2401bis; this looks like 
it belongs in IKEv2, and in fact it is (for icmp anyway).  This text should 
be removed, or if it needs to stay for some reason it should state that it 
is talking about encoding these selectors for IKE.

In sect 4.4.1.3 there is other text about setting port selectors.  Is this 
about setting port selectors in IKE?  If so I suggest adding a sentence 
pointing out that that's what the section is about.

----------------
In 4.4.1.1 and 4.4.1.2.  Is "Name" a Selector or is it something else?  In 
4.4.1.1 (p.26) it's listed as one of the selector types but in 4.4.1.2 it 
is listed as a part of the SPD entry separate from the selector sets.

-------------
4.4.2.1 Data items in the SAD.  Should this list include the Bypass DF bit 
and Bypass DSCP, (copied from the SPD entry)?

-----------------
Sect 5 first paragraph:

"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. (Note: The original SPD entry might result in multiple SAs, 
e.g., because of PFP.)"

As the text here points out, multiple SAs might be created pursuant to one 
SPD entry.  But it seems like a bit of a leap from that to saying that each 
cached SPD entry maps to one SA.  It doesn't even seem correct, unless the 
"SPD cache" *by definition of the model* contains entries that map to one 
SA each.  If that is the case it should be so stated; otherwise the 
statement about each cached SPD entry mapping to one SA should be 
removed.  As far as I can see, nothing is gained by requiring the SPD cache 
to be so fine-grained.

-----------------

In sect. 5.1 item 4:

" 4. The packet is passed to the outbound forwarding function (operating 
outside of the IPsec implementation), to select the interface to which the 
packet will be directed. This function may cause the packet to be passed 
back across the IPsec boundary, for additional IPsec processing, e.g., in 
support of nested SAs. If so, there MUST be an entry in SPD-I database that 
permits inbound bypassing of the packet, otherwise the packet will be 
discarded."

I don't understand why the last 2 sentences are there.  Let's look at the 
case of an overlay network, which I presume is one of the applications that 
might cause iterated application of IPsec.  After once applying IPsec we 
have, say, an ESP packet.  We do a forwarding lookup on the dest address of 
the ESP packet and that forwarding lookup selects another (or the same) 
SPD-O/SPD-S, which the packet is then evaluated against.  Where and why 
does the SPD-I bypass rule come into play in such a scenario?  Where is the 
packet "passed back across the IPsec boundary"?  I think perhaps there is 
more to the model you have in mind here then I am picking up from the text.

Ditto for the similar statement in the Inbound Processing section.
-----------

In sect 5.1.1 2 several cases where packets are dropped are itemized. There 
are two categories listed for cases where IKE could not negotiate an 
appropriate SA:

"  b1. The IPsec system was unable to set up the SA required by the SPD 
entry matching the packet because the IPsec peer at the other end of the 
exchange is administratively prohibited from communicating with the initiator."

"  b2. The IPsec system was unable to set up the SA required by the SPD 
entry matching the packet because the IPsec peer at the other end of the 
exchange could not be contacted."

These don't seem to cover all the possible reasons the IKE might fail, for 
example, the case where the local IPsec device could not successfully 
authenticate itself to the remote one.  I think that either more reasons 
should be added (with appropriate ICMP type and code), or one or both of 
the above items should be made more general.  For example, b1 could be 
generalized to "... because a suitable SA could not be negotiated with the 
IPsec peer at the other end."
---------------

In sect 5.1.2 at the bottom of p. 46 there are several references to "DS 
field".  I believe these are referring specifically to the DS field in the 
*outer* IP header.  It would be helpful to make that explicit.
-----------

In sect 5.2 p. 51 step 3a it discussed creating an audit log entry.  It's 
not clear whether the auditable event would be any processing done under 
step 3a, or just the multicast case discussed just before the 
auditing.  But, it doesn't seem in either case that it should be an 
auditable event -- there is no error case or unusual occurrence here, just 
normal, vanilla processing.
-----------

In sect 7.2 (Separate Tunnel Mode SAs for Non-Initial Fragments):

"Also, because an SA of this sort will carry ALL non- initial fragments 
that match a specified Local/Remote address pair and protocol value, users 
and administrators are advised to protect such traffic using ESP (with 
integrity) and the "strongest" integrity and encryption algorithms 
available at both peers."

I think the point here is that the fragments carried on this SA belong to 
packets that might have gone on a variety of separate SAs of varying 
security, if not for the fragmentation.  So I think it makes more sense if we
s/algorithms available at both peers/algorithms in use for any traffic 
between both peers/
-------------

In sect. 7.4 (BYPASS/DISCARD traffic) it says "An implementation MUST 
support stateful fragment checking to accommodate BYPASS traffic for which 
a non-trivial port range is specified."  This seems to mandate that an 
implementation support the type of stateful fragment checking that is made 
a MAY in 7.3.

I propose that this statement be changed to include the alternative of 
dropping the non-initial fragments (which should be the normal behavior 
*anyway* if there is no applicable SPD policy with port selectors of ANY or 
OPAQUE).  So I would change the above-quoted sentence to:

    "An implementation MAY BYPASS non-initial fragments pursuant to an SPD 
policy entry with a non-trivial port range if stateful fragment checking is 
performed to verify the applicable ports for those fragments."
----------

In sect 8.2.1 (propagation of PMTU), it says that once it has "learned" a 
new PMTU, the IPsec implementation should wait for outbound traffic for the 
SA and "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."

I think that is the correct behavior *if* the packet had DF set, but if it 
does not then the IPsec implementation should either fragment then encrypt 
or encrypt then fragment, per its configuration.
-----------------

Appendix D has not been updated to align with what was eventually decided, 
and so may lead to confusion.  Perhaps it should just be dropped?
-------------

Thanks,
Mark

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Oct 2004 15:31:55 -0400

Mark,

Karen and I were reviewing all the comments we received during the WG 
last call, making final change to 2401bis. Most of your comments were 
easy to address, but there were some that require further discussion, 
or which we feel do not merit the changes you suggest:

>Sect 5 first paragraph:
>
>"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. (Note: The original SPD entry might 
>result in multiple SAs, e.g., because of PFP.)"
>
>As the text here points out, multiple SAs might be created pursuant 
>to one SPD entry.  But it seems like a bit of a leap from that to 
>saying that each cached SPD entry maps to one SA.  It doesn't even 
>seem correct, unless the "SPD cache" *by definition of the model* 
>contains entries that map to one SA each.  If that is the case it 
>should be so stated; otherwise the statement about each cached SPD 
>entry mapping to one SA should be removed.  As far as I can see, 
>nothing is gained by requiring the SPD cache to be so fine-grained.

in general, an entry in the SPD cache points to exactly one SA. this 
is what one would expect because the purpose of the cache is to speed 
up the mapping of outbound packets to SAs. there are exceptions, 
however, and so we will revise the text. exceptions arise when one 
uses multiple SAs to carry traffic of different priorities (e.g., as 
indicated by distinct DSCP values) but with the same selectors, on 
different SAs.

>In sect. 5.1 item 4:
>
>" 4. The packet is passed to the outbound forwarding function 
>(operating outside of the IPsec implementation), to select the 
>interface to which the packet will be directed. This function may 
>cause the packet to be passed back across the IPsec boundary, for 
>additional IPsec processing, e.g., in support of nested SAs. If so, 
>there MUST be an entry in SPD-I database that permits inbound 
>bypassing of the packet, otherwise the packet will be discarded."
>
>I don't understand why the last 2 sentences are there.  Let's look 
>at the case of an overlay network, which I presume is one of the 
>applications that might cause iterated application of IPsec.  After 
>once applying IPsec we have, say, an ESP packet.  We do a forwarding 
>lookup on the dest address of the ESP packet and that forwarding 
>lookup selects another (or the same) SPD-O/SPD-S, which the packet 
>is then evaluated against.  Where and why does the SPD-I bypass rule 
>come into play in such a scenario?  Where is the packet "passed back 
>across the IPsec boundary"?  I think perhaps there is more to the 
>model you have in mind here then I am picking up from the text.

Once a packet has crossed the IPsec boundary, it cannot be processed 
via IPsec again, unless it is bypassed, i.e., lopped. this is true in 
both directions, inbound or outbound. If one requires multiple passes 
through IPsec to protect a packet, then one must have entries in the 
SPD-O/I caches to allow such bypassing, as illustrated in Appendix E.

>In sect. 7.4 (BYPASS/DISCARD traffic) it says "An implementation 
>MUST support stateful fragment checking to accommodate BYPASS 
>traffic for which a non-trivial port range is specified."  This 
>seems to mandate that an implementation support the type of stateful 
>fragment checking that is made a MAY in 7.3.
>
>I propose that this statement be changed to include the alternative 
>of dropping the non-initial fragments (which should be the normal 
>behavior *anyway* if there is no applicable SPD policy with port 
>selectors of ANY or OPAQUE).  So I would change the above-quoted 
>sentence to:
>
>    "An implementation MAY BYPASS non-initial fragments pursuant to 
>an SPD policy entry with a non-trivial port range if stateful 
>fragment checking is performed to verify the applicable ports for 
>those fragments."

Yes, 7.3 is a MAY, but that's for protected traffic, not for BYPASS 
traffic. The debate over fragment handling for IPsec-protected 
traffic spilled over into BYPASS traffic as well, as documented in 
Appendix D. I don't recall messages that suggest the WG decided to 
drop the requirement to support fragment reassembly for BYPASS 
fragments.  If you can point me to the relevant messages, then we 
will change the text as you suggest.

>In sect 8.2.1 (propagation of PMTU), it says that once it has 
>"learned" a new PMTU, the IPsec implementation should wait for 
>outbound traffic for the SA and "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."
>
>I think that is the correct behavior *if* the packet had DF set, but 
>if it does not then the IPsec implementation should either fragment 
>then encrypt or encrypt then fragment, per its configuration.

Tbe processing described above is correct for IPv4 when the DF bit is 
set, as you noted. It also is appropriate for IPv6, because we can't 
fragment on the plaintext side for v6. maybe we could fragment on the 
ciphertext side, but that is still not in the spirit of v6, since we 
are an intermediate system performing fragmentation. The question is 
very poor performance that results for v4 or v6 if we fragment. How 
about  compromise: for v6 we send the PMTU and drop the packet, as 
now described;  for v4 we send the PMTU message, but still pass the 
packet, fragmenting on either side as configured.

>Appendix D has not been updated to align with what was eventually 
>decided, and so may lead to confusion.  Perhaps it should just be 
>dropped?

We were explicitly asked to preserve the analysis that motivated the 
final text in 2401bis, hence the appendix in question. The Appendix 
presents arguments for different approaches, and ends with the 
observation that we settled for one MUST and two MAYs. other than the 
question about fragment reassembly for BYPASS traffic, what parts of 
it do you feel are no longer consistent with the final text?

Steve

---

From: Karen Seo <[email-masked]>
Date: Tue, 26 Oct 2004 23:25:54 -0400

Mark,

I believe we've made edits per your suggestions or replied with 
comments/proposed approaches for all the items you listed except for 
the following one...

>In sect 5.2 p. 51 step 3a it discussed creating an audit log entry. 
>It's not clear whether the auditable event would be any processing 
>done under step 3a, or just the multicast case discussed just before 
>the auditing.  But, it doesn't seem in either case that it should be 
>an auditable event -- there is no error case or unusual occurrence 
>here, just normal, vanilla processing.

	Given that the packet specifies AH or ESP as the protocol
	and is addressed to this device, there should be an entry
	in the SAD for it.  The auditable event is the failure to
	find a match in the SAD.  This is an error and applies
	to both unicast or multicast packets.  So the current
	wording seems reasonable.  Do you agree?

	"3a. If the packet is addressed to the IPsec device and
	AH or ESP is specified as the protocol, the packet is
	looked up in the SAD. For unicast traffic, use only the
	SPI (or SPI plus protocol). For multicast traffic, use
	the SPI plus the destination or SPI plus destination and
	source addresses, as specified in section 4.1. In either
	case (unicast or multicast), if there is no match, discard
	the traffic.  This is an auditable event...."

Thank you,
Karen

---

From: Mark Duffy <[email-masked]>
Date: Wed, 27 Oct 2004 16:03:58 -0400

Hi Steve and Karen, and thanks again for your efforts.  I've responded 
below for each item.
--Mark

At 03:31 PM 10/22/2004, Stephen Kent wrote:
>Mark,
>
>Karen and I were reviewing all the comments we received during the WG last 
>call, making final change to 2401bis. Most of your comments were easy to 
>address, but there were some that require further discussion, or which we 
>feel do not merit the changes you suggest:
>
>>Sect 5 first paragraph:
>>
>>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. (Note: The original SPD entry might result in 
>>multiple SAs, e.g., because of PFP.)"
>>
>>As the text here points out, multiple SAs might be created pursuant to 
>>one SPD entry.  But it seems like a bit of a leap from that to saying 
>>that each cached SPD entry maps to one SA.  It doesn't even seem correct, 
>>unless the "SPD cache" *by definition of the model* contains entries that 
>>map to one SA each.  If that is the case it should be so stated; 
>>otherwise the statement about each cached SPD entry mapping to one SA 
>>should be removed.  As far as I can see, nothing is gained by requiring 
>>the SPD cache to be so fine-grained.
>
>in general, an entry in the SPD cache points to exactly one SA. this is 
>what one would expect because the purpose of the cache is to speed up the 
>mapping of outbound packets to SAs. there are exceptions, however, and so 
>we will revise the text. exceptions arise when one uses multiple SAs to 
>carry traffic of different priorities (e.g., as indicated by distinct DSCP 
>values) but with the same selectors, on different SAs.

I agree that if one is using the SPD cache to speed up the mapping of 
outbound packets one would like to have one cache entry per SA 
(**).  However, it is my understanding that the purpose of the SPD cache 
*in the context of the 2401bis document* is not to speed up execution but 
to model the desired behavior under the standard.  Therefore I suggest two 
changes to the wording:

.  State somewhere that for the purposes of this specification, it is 
assumed that there is one SPD cache entry for every SA (**).

.  The wording from rfc2401bis-03 that is quoted above implies that the 
cache-entry-per-SA is a *consequence* of the decorrelation, i.e. it says 
"... if the SPD entries are first decorrelated, then ... and each cached 
entry will map to exactly one SA ...".  This was the cause of my original 
comment.  I suggest changing this text to e.g.
     "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."

(**)  I agree that multiple SAs for the same selector set but for different 
DSCPs would share an SPD cache entry.  One way to capture this would be to 
replace statements like:
   "each cached entry will map to exactly one SA, or ... bypassed or 
discarded" with:
   "each cached entry will map to one or more SAs with the same selector 
set, or ... bypassed or discarded"

>>outside of the IPsec implementation), to select the interface to which 
>>the packet will be directed. This function may cause the packet to be 
>>passed back across the IPsec boundary, for additional IPsec processing, 
>>e.g., in support of nested SAs. If so, there MUST be an entry in SPD-I 
>>database that permits inbound bypassing of the packet, otherwise the 
>>packet will be discarded."
>>
>>case of an overlay network, which I presume is one of the applications 
>>that might cause iterated application of IPsec.  After once applying 
>>IPsec we have, say, an ESP packet.  We do a forwarding lookup on the dest 
>>address of the ESP packet and that forwarding lookup selects another (or 
>>the same) SPD-O/SPD-S, which the packet is then evaluated against.  Where 
>>and why does the SPD-I bypass rule come into play in such a 
>>scenario?  Where is the packet "passed back across the IPsec 
>>boundary"?  I think perhaps there is more to the model you have in mind 
>>here then I am picking up from the text.
>
>Once a packet has crossed the IPsec boundary, it cannot be processed via 
>IPsec again, unless it is bypassed, i.e., lopped. this is true in both 
>directions, inbound or outbound. If one requires multiple passes through 
>IPsec to protect a packet, then one must have entries in the SPD-O/I 
>caches to allow such bypassing, as illustrated in Appendix E.

The way I am looking at it, once a SG has applied tunnel mode IPsec to a 
packet, it has created a *new* IP packet that is from the SG itself.  I 
view this new packet as originating *inside* the IPsec boundary (comparable 
to the way that, say, IKE packets from the SG originate from inside the 
IPsec boundary).

If on the other hand an SG is to view the tunnel mode packet that it just 
created as having arrived from outside the IPsec boundary, that seems to me 
to be quite confusing.  What interface would it be considered to have 
arrived from?  Which (of potentially multiple) SPDs should be used for the 
pseudo-inbound processing?  How do I (configuring the policy) distinguish 
these packets from ones that really came in off the network?  At the bottom 
line, why should an SG treat an IPsec packet that it just created as though 
it just arrived on an unprotected interface?

>>support stateful fragment checking to accommodate BYPASS traffic for 
>>which a non-trivial port range is specified."  This seems to mandate that 
>>an implementation support the type of stateful fragment checking that is 
>>made a MAY in 7.3.
>>
>>*anyway* if there is no applicable SPD policy with port selectors of ANY 
>>or OPAQUE).  So I would change the above-quoted sentence to:
>>
>>    "An implementation MAY BYPASS non-initial fragments pursuant to an 
>> SPD policy entry with a non-trivial port range if stateful fragment 
>> checking is performed to verify the applicable ports for those fragments."
>
>traffic. The debate over fragment handling for IPsec-protected traffic 
>spilled over into BYPASS traffic as well, as documented in Appendix D. I 
>don't recall messages that suggest the WG decided to drop the requirement 
>to support fragment reassembly for BYPASS fragments.  If you can point me 
>to the relevant messages, then we will change the text as you suggest.

I don't know of any relevant messages, either for or against this, for 
bypass traffic.  However, it seems to me that the whole stateful fragment 
checking question is about the same for PROTECT and for BYPASS.  I think 
all the same arguments could be made on all sides.  Therefore I would 
assume that the decision reached should be the same for PROTECT and for 
BYPASS.

Since we had the big discussion for PROTECT and decided that stateful 
fragment checking is a MAY, I would expect the same conclusion to apply for 
BYPASS.  However, you seem to be taking the position that unless this was 
specifically discussed for BYPASS, that the standard in this area is 
defaulting to MUST.  I don't see why that should be the case.

>>new PMTU, the IPsec implementation should wait for outbound traffic for 
>>the SA and "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."
>>
>>I think that is the correct behavior *if* the packet had DF set, but if 
>>it does not then the IPsec implementation should either fragment then 
>>encrypt or encrypt then fragment, per its configuration.
>
>Tbe processing described above is correct for IPv4 when the DF bit is set, 
>as you noted. It also is appropriate for IPv6, because we can't fragment 
>on the plaintext side for v6. maybe we could fragment on the ciphertext 
>side, but that is still not in the spirit of v6, since we are an 
>intermediate system performing fragmentation. The question is very poor 
>performance that results for v4 or v6 if we fragment. How 
>about  compromise: for v6 we send the PMTU and drop the packet, as now 
>described;  for v4 we send the PMTU message, but still pass the packet, 
>fragmenting on either side as configured.

Let me break it into 3 cases:

1.  Original (cleartext) packet is IPv4 and has DF set:
I think you and I are agreed that it should discard the packet, and send a 
PMTU ICMP message.

2.  Original (cleartext) packet is IPv4 and has DF clear:
I think you are suggesting that the IPsec implementation send a PMTU ICMP 
message but also fragment (before or after IPsec) and forward the 
packet.  I disagree with that.  I agree it should fragment and forward the 
packet, but I DO NOT agree that it should send the PMTU ICMP.  The reason 
is that the ICMP message that would be sent is type 3 (Destination 
Unreachable) code 4 ("fragmentation needed and DF set").  I do not think it 
is good practice to send "fragmentation needed and DF set" in cases where 
DF was not set.

3.  Original (cleartext) packet is IPv6:
I think you and I are agreed that this should be treated just like case 1.

BTW I think the above cases cover all cases, regardless of whether a tunnel 
mode IPsec encapsulation would be IPv4 or v6.

>>decided, and so may lead to confusion.  Perhaps it should just be dropped?
>
>
>We were explicitly asked to preserve the analysis that motivated the final 
>text in 2401bis, hence the appendix in question. The Appendix presents 
>arguments for different approaches, and ends with the observation that we 
>settled for one MUST and two MAYs. other than the question about fragment 
>reassembly for BYPASS traffic, what parts of it do you feel are no longer 
>consistent with the final text?

Re-reading the appendix now, it doesn't strike me as badly as last time :-) 
so  I will largely withdraw this complaint.  The only thing I see from a 
quick look (maybe only a nit, I'll concede):

"...essentially create a "non-initial fragment only" SA, precisely the 
solution that the WG rejected."  and
"The Working Group rejected the convention of creating an SA to carry only 
non-initial fragments"
As reflected in sect 7.2, separate SAs may be used for non-initial fragments.

---

From: Mark Duffy <[email-masked]>
Date: Wed, 27 Oct 2004 23:29:45 -0400

>>auditable event -- there is no error case or unusual occurrence here, 
>>just normal, vanilla processing.
>

Thanks Karen, that looks great.
(I think the -03 draft was actually missing a whole line of text here, 
which was the main problem.)
--Mark

---

From: Karen Seo <[email-masked]>
Date: Thu, 28 Oct 2004 01:13:33 -0400

Mark,

You're right -- the -03 draft is missing a critical sentence. Thanks 
for catching this.

Karen

>>>In sect 5.2 p. 51 step 3a it discussed creating an audit log 
>>>entry. It's not clear whether the auditable event would be any 
>>>processing done under step 3a, or just the multicast case 
>>>discussed just before the auditing.  But, it doesn't seem in 
>>>either case that it should be an auditable event -- there is no 
>>>error case or unusual occurrence here, just normal, vanilla 
>>>processing.
>>
>(I think the -03 draft was actually missing a whole line of text 
>here, which was the main problem.)
>--Mark

---

From: Stephen Kent <[email-masked]>
Date: Fri, 29 Oct 2004 18:55:11 -0400

Mark,

Section 5, first para:
I think we can change the text discussing SPD cache entries and SAs 
to avoid the unintended implication you noted.  As you said, the 
cache model is adopted to simplify presentation and there was no 
intent to suggest that the mapping to a single SA is a side effect of 
the cache use and an efficiency issue.  So, with the caveats we noted 
re multiple SAs for DSCP, etc., I think this issue is now closed.

>>>In sect. 5.1 item 4:
>>>	<SNIP>
>>
>>Once a packet has crossed the IPsec boundary, it cannot be 
>>processed via IPsec again, unless it is bypassed, i.e., lopped. 
>>this is true in both directions, inbound or outbound. If one 
>>requires multiple passes through IPsec to protect a packet, then 
>>one must have entries in the SPD-O/I caches to allow such 
>>bypassing, as illustrated in Appendix E.
>
>The way I am looking at it, once a SG has applied tunnel mode IPsec 
>to a packet, it has created a *new* IP packet that is from the SG 
>itself.  I view this new packet as originating *inside* the IPsec 
>boundary (comparable to the way that, say, IKE packets from the SG 
>originate from inside the IPsec boundary).

The new, tunneled packet is inside the IPsec boundary, but it is past 
the point where we do outbound packet lookups.  That was a major 
motivation re simplifying the processing model, i.e., avoiding 
looping inside of the IPsec boundary in support of nesting. This 
notion has been stable for quite a while, as we removed the 
requirement for support of SA bundles. the last list discussion of 
this took place back in early August when Mike Roe sent a message 
asking for clarification on how to set up entries in forwarding 
tables and in the SPD to effect the looping needed for nested SAs.

>If on the other hand an SG is to view the tunnel mode packet that it 
>just created as having arrived from outside the IPsec boundary, that 
>seems to me to be quite confusing.  What interface would it be 
>considered to have arrived from?  Which (of potentially multiple) 
>SPDs should be used for the pseudo-inbound processing?  How do I 
>(configuring the policy) distinguish these packets from ones that 
>really came in off the network?  At the bottom line, why should an 
>SG treat an IPsec packet that it just created as though it just 
>arrived on an unprotected interface?

I think the question of how one treats a packet as it emerges from 
IPsec processing is well illustrated in the set of figures we have 
added to 2401bis, going back to December of 2003. Figure 2 shows the 
output from AH/ESP processing going to the forwarding function, and 
shows a path from that function, through the SPD-I, and back to the 
SPD-selection function. This was described precisely to support the 
looping needed for nested SA processing.

Still, let me answer the questions you raised.  As per figure 2, this 
traffic goes from the forwarding module to the SPD-I. The inbound 
traffic discussion on page 52 says that a packet MAY be tagged with 
the interface IF that is necessary to support different SPD-Is. I 
guess we could say, in the outbound processing discussion, that if 
necessary, the traffic being looped back could be tagged as coming 
from this internal interface, if necessary, i.e., if there is more 
than one SPD-I. That would allow use of a different SPD-I for "real" 
external traffic vs. looped traffic, if needed. The example we gave 
in Appendix ?? did not make that assumption, i.e., it used just one 
SPD-I, which is the default. the bottom line is that we have said for 
about a year that this is how we would loop packets to effect nested 
SA processing.

>>>In sect. 7.4 (BYPASS/DISCARD traffic)
>	<SNIP>
>
>Since we had the big discussion for PROTECT and decided that 
>stateful fragment checking is a MAY, I would expect the same 
>conclusion to apply for BYPASS.  However, you seem to be taking the 
>position that unless this was specifically discussed for BYPASS, 
>that the standard in this area is defaulting to MUST.  I don't see 
>why that should be the case.

I am not sure that we defaulted a MUST for fragment reassembly for 
BYPASS, after deciding to  make it a MAY for protected traffic. I 
thought that we changed it to MUST after some discussion on the list, 
after having listed it as MAY/SHOULD in the earlier draft, but I may 
be wrong.  How about a quick straw poll, so we can make the word be 
MUST or MAY, depending on what folks decide.

>>>I think that is the correct behavior *if* the packet had DF set, 
>>>but if it does not then the IPsec implementation should either 
>>>fragment then encrypt or encrypt then fragment, per its 
>>>configuration.
>>
>>Tbe processing described above is correct for IPv4 when the DF bit 
>>is set, as you noted. It also is appropriate for IPv6, because we 
>>can't fragment on the plaintext side for v6. maybe we could 
>>fragment on the ciphertext side, but that is still not in the 
>>spirit of v6, since we are an intermediate system performing 
>>fragmentation. The question is very poor performance that results 
>>for v4 or v6 if we fragment. How about  compromise: for v6 we send 
>>the PMTU and drop the packet, as now described;  for v4 we send the 
>>PMTU message, but still pass the packet, fragmenting on either side 
>>as configured.
>
>I think you and I are agreed that it should discard the packet, and 
>send a PMTU ICMP message.

right.

>I think you are suggesting that the IPsec implementation send a PMTU 
>ICMP message but also fragment (before or after IPsec) and forward 
>the packet.  I disagree with that.  I agree it should fragment and 
>forward the packet, but I DO NOT agree that it should send the PMTU 
>ICMP.  The reason is that the ICMP message that would be sent is 
>type 3 (Destination Unreachable) code 4 ("fragmentation needed and 
>DF set").  I do not think it is good practice to send "fragmentation 
>needed and DF set" in cases where DF was not set.

whoops, good point. I guess we should just wait for hosts behind an 
SG to send traffic with DF set as part of PMTU discovery, and act 
accordingly. OK.

>I think you and I are agreed that this should be treated just like case 1.

right.

>BTW I think the above cases cover all cases, regardless of whether a 
>tunnel mode IPsec encapsulation would be IPv4 or v6.

agreed.

>>We were explicitly asked to preserve the analysis that motivated 
>>the final text in 2401bis, hence the appendix in question. The 
>>Appendix presents arguments for different approaches, and ends with 
>>the observation that we settled for one MUST and two MAYs. other 
>>than the question about fragment reassembly for BYPASS traffic, 
>>what parts of it do you feel are no longer consistent with the 
>>final text?
>
>Re-reading the appendix now, it doesn't strike me as badly as last 
>time :-) so  I will largely withdraw this complaint.  The only thing 
>I see from a quick look (maybe only a nit, I'll concede):
>
>"...essentially create a "non-initial fragment only" SA, precisely 
>the solution that the WG rejected."  and
>"The Working Group rejected the convention of creating an SA to 
>carry only non-initial fragments"

we'll revisit that chunk of text.

Steve