Subject: Re: [Ipsec] Re: IKEv2 and OPAQUE protocol

From: "DIPANJAN DATTA" <[email-masked]>
Date: 2 May 2007 05:57:22 -0000

Hi Scott,

I believe there is no need for "protocol" values to be OPAQUE. OPAQUE datatypes are assigned for those values which may not be available in a fragmented packet for SPD or SAD matching. Hence port values which appear in the TCP /UDP header may not be available in a fragment of the original TCP/UDP packet, if that fragment happens to be non-first.
But there are no such issues with protocol values because, this values are obtained from the IP header during SPD/SAD matching. Hence irrespective of fragmentation, the protocol value is always available. Also this value is always in clear text because the outer IP header in  a tunnel mode or the IP header in a transport mode, is not going to be encrpypted (with ESP).
Hence the protocol value cannot be OPAQUE. That is why there is no provision in IKEv2 for defining protocol to be OPAQUE.

Regards
Dipanjan Datta

On Tue, 01 May 2007 Scott C Moonen wrote :
>Hi, I never received a response to the attached message.  I suspect the
>answer is that IKEv2 simply does not accomodate OPAQUE IPv6 protocol
>values.  Is this correct?  If so, will this be addressed in a future
>amendment to RFC 4306?  And how are existing IKEv2 implementations
>approaching the use of OPAQUE protocol in combination with SAs?
>
>Thanks in advance,
>
>
>Scott Moonen ([email-masked])
>
>
>
>
>Scott C Moonen/Raleigh/IBM
>02/13/2007 02:30 PM
>
>To
>[email-masked]
>cc
>
>Subject
>IKEv2 and OPAQUE protocol
>
>
>
>
>
>Hi, I am reading RFCs 4301, 4306 and have a question regarding
>interpretation.  RFC 4301 stipulates that SPD entries and SAs may cover
>OPAQUE port values, in case of non-initial packet fragments where the
>ports are unknown.  In the case of IPv6, it also stipulates support for
>OPAQUE protocol values in SPD entries and SAs, since the IPv6 protocol is
>not known in non-initial fragments (and might not be known in the first
>fragment).  I understand that IKEv2 specifies an OPAQUE port value using
>the special port range [65535, 0].  However, I cannot determine how IKEv2
>specifies an OPAQUE protocol value, since protocol ranges are not
>supported.
>
>I found a few notes on this list from November 2004 referencing this
>problem, but without any resolution.  RFC 4718 doesn't reference this
>problem.
>
>The inability to specify an OPAQUE protocol value seems to be a deficiency
>in the IKEv2 specification relative to the requirements of RFC 4301.  Am I
>missing something?  If not, how are various IKEv2 implementations
>approaching the use of OPAQUE protocol values in combination with SAs?
>
>Thanks in advance,
>
>
>Scott Moonen ([email-masked])
>_______________________________________________
>Ipsec mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 2 May 2007 05:48:15 -0600

Dipanjan,

That is true for IPv4 but not for IPv6.  The upper layer protocol is not 
contained in the IPv6 header but in the chain of extension headers.  In 
the absence of intervening extension headers, the upper layer protocol 
will be in every fragment's ip6f_nxt field.  But depending on the 
placement of extension headers, it is possible that the IPv6 protocol 
value will not be known in a non-initial fragment.  It is even possible 
that it will not be known in an initial fragment.

RFC 4301 addresses this by introducing support for OPAQUE IPv6 protocol. 
As far as I can see, RFC 4306 addresses support for OPAQUE transport 
selectors in IKEv2 but not for OPAQUE protocol.

I appreciate your taking time to respond,

"DIPANJAN  DATTA" <[email-masked]> 
05/02/2007 01:57 AM
Please respond to
"DIPANJAN  DATTA" <[email-masked]>

To
Scott C Moonen/Raleigh/IBM@IBMUS
cc
[email-masked]
Subject
Re: [Ipsec] Re: IKEv2 and OPAQUE protocol

Hi Scott,

I believe there is no need for "protocol" values to be OPAQUE. OPAQUE 
datatypes are assigned for those values which may not be available in a 
fragmented packet for SPD or SAD matching. Hence port values which appear 
in the TCP /UDP header may not be available in a fragment of the original 
TCP/UDP packet, if that fragment happens to be non-first.
But there are no such issues with protocol values because, this values are 
obtained from the IP header during SPD/SAD matching. Hence irrespective of 
fragmentation, the protocol value is always available. Also this value is 
always in clear text because the outer IP header in  a tunnel mode or the 
IP header in a transport mode, is not going to be encrpypted (with ESP).
Hence the protocol value cannot be OPAQUE. That is why there is no 
provision in IKEv2 for defining protocol to be OPAQUE.

Regards
Dipanjan Datta