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".
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
