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

From: Karen Seo <[email-masked]>
Date: Mon, 25 Oct 2004 15:27:52 -0400

Mark, Folks,

Sorry, this was sent to the old mailing list by mistake.

Karen

>X-Sender: [email-masked]
>Date: Fri, 22 Oct 2004 15:31:55 -0400
>To: Mark Duffy <[email-masked]>
>From: Stephen Kent <[email-masked]>
>Subject: Re: [Ipsec] WORKING GROUP LAST CALL:
>	draft-ietf-ipsec-rfc2401bis-03.txt
>X-Scanned-By: MIMEDefang 2.35
>X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
>X-Spam-Score: 0.0 (/)
>X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
>Cc: [email-masked]
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.5
>List-Id: IP Security <ipsec.ietf.org>
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
>	<mailto:[email-masked]?subject=unsubscribe>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
>	<mailto:[email-masked]?subject=subscribe>
>Sender: [email-masked]
>X-Spam-Status: NO
>Status: 
>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

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