Subject: [IPsec] RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2)

From: Michael Christian <[email-masked]>
Date: Sat, 21 Nov 2015 01:20:38 +0000

Hello,
I'm investigating a possible RFC 7296 compliance issue and I was hoping you may be able to shed some light on the RFC for me.

In section 2.9 Page 43 regarding multiple traffic selectors:

Can two TSi proposals be sent by the initiator every time IKEv2 is negotiated due to a data packet? Or Is the proposal of an unknown traffic selector type required before the initiator can respond with more specific and range TSi's?

I appreciate any clarification you may be able to provide.

Thank you,
Mike Christian

Technical Account Manager
Fortinet - The New Generation of Secure Gateways
899 Kifer Road | Sunnyvale, CA 94086 | USA

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 23 Nov 2015 13:42:35 +0200

Michael Christian writes:
> Hello,
> 
> I’m investigating a possible RFC 7296 compliance issue and I was hoping you
> may be able to shed some light on the RFC for me.
> 
> Can two TSi proposals be sent by the initiator every time IKEv2 is negotiated
> due to a data packet?

I do not really understand what you are trying to ask. Any TSi payload
can have multiple traffic selectors. Those traffic selectors are from
the policy rule, and the first of them can be from the data packet, if
SA was created because of the data packet, i.e. the text says:

   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include as the first Traffic Selector in each of TSi
   and TSr a very specific Traffic Selector including the addresses in
   the packet triggering the request.  

So yes, when you ask for SA to be created based on the traffic, you
SHOULD always include two TSi traffic selectors, one which matches the
data from the packet, and another which is taken from the policy.

> Or Is the proposal of an unknown traffic selector type required
> before the initiator can respond with more specific and range TSi’s?

Initiator will never respond with TSi. Initiator sends the TSi ranges,
and it of course should never send unknown traffic selector types, as
it should only send those traffic selectors it knows. The responder
might receive unknown traffic selector types, because initiator might
support more things than responder do, and in that case the responder
will simply ignore those and process TS payload just like those
unknown traffic selector types were not there at all, i.e. narrow the
request using the known traffic selector types. As responder will only
reply with traffic selectors sent by the initiator the initiator can
never get back an TS reply containing unknown traffic selector types.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 23 Nov 2015 14:47:48 +0300

Hi Mike,

I'm not sure I completely understand your question.

RFC7296 requires that exactly one TSi payload and exactly one TSr payload are present in IKE_AUTH or 
CREATE_CHILD_SA exchanges (if the latter doesn't rekey IKE SA). However, both TSi and TSr may contain
multiple Traffic Selector substructures.By convention, if SA is being negotiated due to data packet, then 
the very first Traffic Selectors in TSi and TSr contain specific network information from that packet (Traffic Selector
in TSi - source IP address/pprotocol/port, Traffic Selector in TSr - destination IP address/pprotocol/port).
The other Traffic Selectors (if any) in TSi/TSr contain specification of additional (wider) traffic that the Initiator
thinks is appropriate to send later over the SA being created. The Responder could agree on this or it could narrow 
this Traffic Selectors in its response. Sometimes Initiators include wildcard traffic selectors in Request allowing 
Responders to narrow them according to its policy.

Hope this helps. Feel free to ask more if you have any concerns.

Regards,
Valery Smyslov.

  ----- Original Message ----- 
  From: Michael Christian 
  To: [email-masked] 
  Sent: Saturday, November 21, 2015 4:20 AM
  Subject: [IPsec] RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2)

  Hello,

  Thank you,

  Mike Christian

------------------------------------------------------------------------------
  *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** 

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

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

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