Subject: [IPsec] [IANA #785032] General Request for Assignment (ikev2-parameters)

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Oct 2014 13:26:21 +0300

Got following request form IANA, and approved it. This is just for
information in case someone is interested. 

Amanda Baber via RT writes:
> We have another request for an IKEv2 Configuration Payload Attribute
> Type. If this is OK, how should we fill in the "Multi-Valued" and
> "Length" columns? 
> ===
> 
> Contact Name:
> Frederic Firmin
> 
> Contact Email:
> [email-masked]
> 
> Type of Assignment:
> IKEv2 configuration attribute
> 
> Registry:
> IKEv2 Configuration Payload Attribute Types
> 
> Description:
> see 24.302 F3.3. When FTT_KAT configuration attribute is included in
> the CFG_REQUEST configuration payload of IKEv2 security association,
> packets of which are transported via FTT, the Keep-alive time field
> indicates preferred maximum time in seconds between two envelopes
> (any of those described in subclause F.3.2) sent via FTT. When
> FTT_KAT configuration attribute is included in the CFG_REPLY
> configuration payload of IKEv2 security association, packets of
> which are transported via FTT, the Keep-alive time field indicates
> actual maximum time in seconds between two envelopes (any of those
> described in subclause F.3.2 of 24.302) sent via FTT. 
> 
> Additional Info:
> 24.302 12.6.0 available at http://www.3gpp.org/DynaReport/24302.htm

This parameter is related to the EPC (evolved packet core), where they
use IKEv2 and ESP to connect the UE (user equipment, i.e. the phone)
to the ePDG (evolved packet data gateway, i.e. their IPsec gateway)
over non-3gpp network (i.e. wlan etc).

They have feature called FTT (firewall traversal tunnel), where they
try to get connectivity even when the non-3gpp networks is very
restrictive, i.e. firewalls block IKEv2 and ESP traffic, but https
goes through. In that case they tunnel IKEv2 and ESP through TLS
tunnel made from the UE to the ePDG (possibly through proxy). For this
tunnel they want to use keepalives, but the normal IKEv2 NAT-T
keepalives are not usable here as this is over TLS over TCP, not over
UDP, and the keepalives needed in those environments are in the order
of 10 minutes, not 10 seconds...

This configuration parameter is used to configure the keepalive
interval for the tunnel. They have their own mechanism to wrap the
IKEv2, ESP, and the keepalive packets sent over the TLS tunnel.

This looks ugly, and the usability might not be the best when you are
running IP over TCP, but if the environment is such that, this is only
connectivity you get (hotel etc), it is best you can do...

That is at least what I understood from their 24.302 specification
with quick check.
-- 
[email-masked]