Subject: [Ipsec] Stateful fragment check

From: Surya Batchu <[email-masked]>
Date: Sat, 8 Jan 2005 08:38:36 -0800 (PST)

Hi,
 
If 'Stateful fragmen check' is required, then the security policies on the both communicating security gateways should be configured with the 'fragCheck' set to TRUE.  It means that, the users configuring the policies on these security gateways should know a priori that these gateway support this feature.  Is that correct?
 
If so, what are the advantages of negotiating IKE_NOTIFY_NON_FIRST_FRAGMENT_ALSO using IKEv2?
 
If there is any mis-configuration of 'fragCheck' flag on IPsec peers, then this negotiation helps in notifying the user with auditable event and correcting the configuration. This is one advantage I see.  Are there any other uses of this?
 
Surya

---------------------------------
Do you Yahoo!?
 Read only the mail you want - Yahoo! Mail SpamGuard.

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Jan 2005 11:57:37 -0500

At 8:38 AM -0800 1/8/05, Surya Batchu wrote:
>Hi,
>
>If 'Stateful fragmen check' is required, then the security policies 
>on the both communicating security gateways should be configured 
>with the 'fragCheck' set to TRUE.  It means that, the users 
>configuring the policies on these security gateways should know a 
>priori that these gateway support this feature.  Is that correct?
>
>If so, what are the advantages of negotiating 
>IKE_NOTIFY_NON_FIRST_FRAGMENT_ALSO using IKEv2?

An IPsec implementation uses this feature to determine if a peer is 
willing to accommodate non-initial fragments on the SA being 
negotiated, when the traffic selectors for the SA require inspection 
of port fields.

>  If there is any mis-configuration of 'fragCheck' flag on IPsec 
>peers, then this negotiation helps in notifying the user with 
>auditable event and correcting the configuration. This is one 
>advantage I see.  Are there any other uses of this?

It is not necessarily a mis-configuration, just a different local 
policy, just like traffic selectors are local policy info. We need a 
way to detect that there would be problems if non-initial fragments 
were sent via the SA, just as we want a way to detect if traffic 
consistent with specified selectors will be acceptable to a peer. IKE 
negotiation accomplishes this.

Steve

---

From: "subha" <[email-masked]>
Date: Mon, 10 Jan 2005 12:49:39 -0800

Hi List-members,

Is there a draft or RFC that indicates how to send Context Identifiers
and receive Context Identifiers in IKE payload ?

Basically, when acting as a responder, how do we get this context identifier
from the peer, to internally determine, which IPsec context to use ?

Thanks,
Subha

---

From: Subha Venkataramanan <[email-masked]>
Date: Tue, 11 Jan 2005 11:55:26 -0800 (PST)

Hi,

Maybe my initial mail was not clear. I am re-sending 
it with more information.

Draft 2401-bis, talks about the following in Section
4.4.

It states 'To this end, if supported by the key 
management protocolin use, context identifiers MAY be 
conveyed from Initiator to Responder in the signalling
messages, with the result that the IPsec SAs are 
created with a binding to a particular context'

This does not address the scenario, where when we are 
acting as a Responder,how do we make the peer send 
some IPsec context info, so that internally we
know which context to use.

Is there any draft that talks about this ?

Thanks,
Subha

> from the peer, to internally determine, which IPsec

		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

---

From: Mark Duffy <[email-masked]>
Date: Tue, 11 Jan 2005 16:29:00 -0500

Hi Subha,

There was a discussion of this relative to IKEv2 in March 2003.  (Look in 
the mail list archives for the thread "Another field for traffic 
selector?").  At that time the wg decided not to put anything into the base 
IKEv2 for signalling of context, but that it could possibly be done later 
as an extension.  Then in 2401bis the text you quote below was added to 
explicitly permit this sort of thing.   But AFAIK there has been no effort 
to actually define this capability for IKEv2.

--Mark