[IPsec] Some comments to the draft-mglt-ipsecme-security-gateway-discovery-00

[Tero Kivinen <[e-mail]>]

In section 4.1 Multiple Interfaces you say:

----------------------------------------------------------------------
   Distributed VPN infrastructures are composed of multiple, independent
   Security Gateways.  Currently, IPsec [RFC4301] does not have the
   mechanisms that enable "moving" a VPN connection from one Security
   Gateway to another Security Gateway.  In practice, this means that
----------------------------------------------------------------------

There is Redirect Mechanism for the Internet Key Exchange Protocol
Version 2 (IKEv2) RFC5685, which is standard track document allow
redirecting the IKEv2 SA to another gateway. This can used when
initially creating the tunnel, but it can also be used in the middle
of the session, i.e. gateway can request client to move to another
gateway.

How is this draft working together with REDIRECT RFC?

In section 5 this document seems to be using Notify payloads to do
request reply protocol. I think configuration payloads might be better
suited for this kind of request reply protocol.

In section 5.1 the draft says:
----------------------------------------------------------------------
5.1.  Sending a NEIGHBOR_INFORMATION Query

   The initiator builds the NEIGHBOR_INFORMATION Notify Payload
   (described in Section 6.1) by setting the Question bit to 1 and
   providing the necessary Options.  Notify Payloads have a Critical bit
   set.
----------------------------------------------------------------------

The RFC5996 says:

----------------------------------------------------------------------
2.5.  Version Numbers and Forward Compatibility
...
                                   Note that the critical flag applies
   only to the payload type, not the contents.  If the payload type is
   recognized, but the payload contains something that is not (such as
   an unknown transform inside an SA payload, or an unknown Notify
   Message Type inside a Notify payload), the critical flag is ignored.
...
3.2.  Generic Payload Header
...
   o  Critical (1 bit) - MUST be set to zero if the sender wants the
      recipient to skip this payload if it does not understand the
      payload type code in the Next Payload field of the previous
      payload.  MUST be set to one if the sender wants the recipient to
      reject this entire message if it does not understand the payload
      type.  MUST be ignored by the recipient if the recipient
      understands the payload type code.  MUST be set to zero for
      payload types defined in this document.  Note that the critical
      bit applies to the current payload rather than the "next" payload
      whose type code appears in the first octet.  The reasoning behind
      not setting the critical bit for payloads defined in this document
      is that all implementations MUST understand all payload types
      defined in this document and therefore must ignore the critical
      bit's value.  Skipped payloads are expected to have valid Next
      Payload and Payload Length fields.  See Section 2.5 for more
      information on this bit.
----------------------------------------------------------------------

I.e. it says that Notify payloads MUST have critical bit set to zero,
as it is payload that is defined in the RFC5996, and as
implementations will support Notify payloads, none of them will ever
return UNSUPPORTED_CRITICAL_PAYLOAD error. The Critical bit only
applies to the payload type, not contents.

So the text in section 5.2 is incorrect:
----------------------------------------------------------------------
   Once a NEIGHBOR_INFORMATION Notify Payload is received, the responder
   checks whether the Critical bit is set to 1.  If the Critical Bit is
   set and the Notify Payload is not supported by the responder then,
   following [RFC5996] section 2.5, setting the Critical bit to one
   forces the Responder to send back a UNSUPPORTED_CRITICAL_PAYLOAD
   Notify Payload if it does not understand the received Notify Payload.
----------------------------------------------------------------------

As implementations do support Notify payloads, they will not return
UNSUPPORTED_CRITICAL_PAYLOAD, even when they might not support
NEIGHBOR_INFORMATION notify payload type. As the Notify Payload is
specified in the RFC5996, all implementations will support it. Some
minimal implementations might simply ignore them, if they do not
support any of the features provided by the contents of the Notify
Payload, but they do know how to ignore it.

Also in same section:
----------------------------------------------------------------------
   If no corresponding query has been sent previously an INVALID_SYNTAX
   MUST be sent back and the rest of the Notify Payload MUST be ignored.
   Conversely, if a query has been sent, the receiver will process the
   response as per Section 5.2.2.
----------------------------------------------------------------------

If the peer sends INVALID_SYNTAX notification back, that will cause
the whole IKE SA to be deleted without separate delete notification. I
do not assume this what is wanted here. Most likely it would be better
to simply ignore unsocilicated message, than to tear down the whole
IKE SA.

The RFC5996 the INVALID_SYNTAX is defined as follows:
----------------------------------------------------------------------
2.21.3.  Error Handling after IKE SA is Authenticated
...
   If a peer parsing a request notices that it is badly formatted (after
   it has passed the message authentication code checks and window
   checks) and it returns an INVALID_SYNTAX notification, then this
   error notification is considered fatal in both peers, meaning that
   the IKE SA is deleted without needing an explicit Delete payload.
----------------------------------------------------------------------

In section 6.4.1 there is Padding payload defined:
----------------------------------------------------------------------
6.4.1.  Padding Payload: PADDING

   The Padding Payload is used to make the NEIGHBOR_INFORMATION Notify
   Payload length a multiple of 32 bits.
----------------------------------------------------------------------

Why is this needed?

There is nothing in the IKEv2 that requires anything to be padded to
specific length. This also opens one more side channel, to send
information out as the "padding octects are for padding and MUST NOT
be interpreted".
-- 
[e-mail]