Subject: [IPsec] NON_FIRST_FRAGMENTS_ALSO question

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Oct 2008 14:31:02 +0300

Scott C Moonen writes:
>   1) Does your implementation perform stateful fragment checking?

Yes, we always do stateful fragment checking.

>   2) Regardless of the answer to #1, does your implementation correctly 
> recognize that in this case there is a pseudo stateful fragment checking 
> going on even though the traffic at your endpoint is not forwarded?

As we always do stateful checking that does include locally generated
packets too. 

>   3) How do you handle this case?  Do you send NON_FIRST_FRAGMENTS_ALSO? 
> Or do you mark the SA as stateful-fragment-checking=false, perhaps 
> discarding those non-first fragments?  Or do you have additional logic to 
> perform a second SPD lookup for these non-first fragments after they have 
> been produced, so that they can be sent on the appropriate port=ALL or 
> port=OPAQUE SA?

We always send NON_FIRST_FRAGMENTS_ALSO notify and always do stateful
fragment checking, and send non first fragments in the same SA. 

>   4) If you treat this as a NON_FIRST_FRAGMENTS_ALSO case, what do you do 
> in the event that NON_FIRST_FRAGMENTS_ALSO is not also sent by the peer? 
> Do you delete the SA and document that a port=ALL SA must be established 
> instead (e.g., by setting the port PFP flags to false)?  Or do you revert 
> to any of the behaviors suggested in the previous question?

Currently we simply ignore the fact that other end didn't send the
NON_FIRST_FRAGMENTS_ALSO and send non first fragments to the SA, and
if other end drops them, then we do have configuration mismatch
causing black hole for fragmented packets. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 9 Oct 2008 16:05:09 -0400

Tero, thanks for your reply.  I would be very tempted to take the same 
approach, issuing a warning message but leaving the SA up and continuing 
to flow traffic.  I also wonder if it is possible that some minimal 
implementations may not be sending N(NON_FIRST_FRAGMENTS_ALSO) in the case 
I described, perhaps wrongly thinking that this payload doesn't apply to 
them since they don't perform stateful fragment checking.  Taking a lax 
approach would provide the ability to interoperate with such an 
implementation without forcing the SA to specify all ports/types/codes.

However, this text from RFC 4301 makes me reluctant to take your approach:

   . . . If an implementation does not
   successfully negotiate transmission of non-initial fragments for such
   an SA, it MUST NOT send such fragments over the SA. . .

I wonder:

  1) Are there any implementations that don't perform stateful fragment 
checking which have made the mistake of not sending 
N(NON_FIRST_FRAGMENTS_ALSO) in the case I described earlier (tunnel-mode 
SA sending locally originated traffic)?
  2) Are there any implementations, like yours, that are treating the 
absence of NON_FIRST_FRAGMENTS_ALSO in a more lenient fashion than RFC 
4301 allows?
  3) Do you have plans to change your own implementation to conform to RFC 
4301 as quoted above?

Thanks,

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
[email-masked]
Date:
10/07/2008 07:41 AM
Subject:
[IPsec] NON_FIRST_FRAGMENTS_ALSO question