Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

["Valery Smyslov" <[e-mail]>]

Hi,

 

a couple of comments.

 

I think that the profile is generally OK, but it seems to me that a few issues persist.

 

1. The

   Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be

   supported.  See [IKEV2IANA] for this and other IANA IKEv2 parameter

   names used in this text.

 

    “PKCS #7 wrapped X.509 certificate” certificate encoding is deprecated and is not used in IKEv2 

     (see https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-11).

     Generally, I see no need for the text that imposes requirements on certificate encoding at all – 

     we never run into the interoperability problems with this? as far as I remember. I suggest to remove this text.

 

2.   If certificate chains are used, all intermediate certificates up to,

   and including the locally provisioned trust anchor certificate MUST

   be signaled.  See Section 6.10.7 for the sub-CA example in which

   certificate chains are used.

 

    This is confusing. I read this text as the “MUST” is imposed only if 

    “certificate chains are used”. Does it mean that implementations 

    may skip this “MUST” if EE certificate is directly signed by CA certificate

    and there is no intermediate certificates? Or is it still a chain

    and “if” is relevant to the case when there is no CA and there is a direct trust to EE certificates

    (in which case PKI is not needed at all and you can use RAW public keys)?

     

     Another point: trust anchors certificates usually are not included in CERT payload in IKEv2.

     I see draft’s a reasoning that this inclusion would allow better network debugging,

     but I’m not sure I can buy this argument. Probably more detailed

     explanation is needed.

 

3.   IKEv2 authentication MUST use authentication method 14 ("Digital

   Signature") for ACP certificates; this authentication method can be

   used with both RSA and ECDSA certificates, as indicated by a PKIX-

   style OID.

 

    I think it’s better to rephrase this more accurately: “indicated by an ASN.1 object AlgorithmIdentifier”

    (which may include parameters besides OID).

 

A typo in the title of 6.7.1.1.2.:  s/RFC847/RFC8247

 

Regards,

Valery.

 

From: IPsec [mailto:[e-mail]] On Behalf Of Yoav Nir
Sent: Tuesday, February 25, 2020 11:18 PM
To: Toerless Eckert
Cc: [e-mail] WG; Michael Richardson; [e-mail]
Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

 

Hi, Toerless.

 

I trimmed below most of your background info.





On 24 Feb 2020, at 21:50, Toerless Eckert <[e-mail]> wrote:

 

[hope its fine to cross-post ipsec and ipsecme given how one is concluded, but may have
more long-time subscribers]

 

ipsec is this group’s mailing list. I don’t know that there even is an [e-mail]





We're looking for opinions about an IPsec profile for "Autonomic Control Plane"
draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 of:

https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/be056679b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt

Quick background so you do not need to read anything more than 6.7.1.1.1:

 

I read a little more. Hope you don’t mind.

 

The profile seems fine to me. There is one thing that I think is missing.

 

The profile specifies that the ACP nodes should use tunnel mode (when GRE is not used), because:

   IPsec tunnel mode is required because the ACP will route/forward
   packets received from any other ACP node across the ACP secure
   channels, and not only its own generated ACP packets.  With IPsec
   transport mode, it would only be possible to send packets originated
   by the ACP node itself.

OK. When IKEv2 is used to negotiate tunnel-mode SAs (and transport mode, but that’s not important here) they need an IPsec policy that specifies traffic selectors so that IKEv2 can specify traffic selectors.  Nowhere in your draft do I see a specification of what traffic selectors need to be negotiated.

 

If I understand the above paragraph correctly, both the source of the packet and the destination can be the IP address of any ACP node, neither of which are required to be the tunnel endpoints.  This implies some sort of generic traffic selector.  The draft should specify this, IMO

 

Yoav