Subject: [secdir] Secdir last call review of draft-ietf-detnet-ip-05

From: Tero Kivinen via Datatracker <[email-masked]>
Date: Thu, 12 Mar 2020 18:15:24 -0700

Reviewer: Tero Kivinen
Review result: Has Nits

In section 1 there is text saying:

   The DetNet Architecture models the DetNet related data plane
   functions as two sub-layers: functions into two sub-layers: a service
   sub-layer and a forwarding sub-layer.

I think the second one of the "functions as/into two sub-layers" instance
should be removed.

In section 5.1.2.2 it says that SPI field of the ESP and AH is used, but in
case the IPsec is configured to use UDP encapsulation (rfc3948, i.e., UDP
destination port is 4500) there is different location for the SPI. Should this
document also dig SPI out from the UDP encapsulated ESP/AH? There is also
wrapped ESP (rfc5840) with bit different format, i.e., having wrapped ESP
header before the normal ESP header. Should this be included also?

In section 6, I would think it would be useful to have wildcard SPI matching
too, i.e., match all ESP/AH traffic between two hosts regardless of SPI.

Note, that standard procedure to support QoS in IPsec is to create multiple SAs
between hosts with identical addresses, but different SPI, and where each flow
has traffic related to one QoS level inside, but there might not be any way for
external user to know which SPI match to which QoS level). So there is
definitely need to have exact match SPI, but problem is that DetNet might not
have any visibility which SPI match witch QoS level.

---

From: Lou Berger <[email-masked]>
Date: Sun, 15 Mar 2020 18:06:25 -0400

Tero,

     Thank you for the comments, please see below.

> I think the second one of the "functions as/into two sub-layers" instance

agreed. This looks like a cut-and-past bug to me.

> document also dig SPI out from the UDP encapsulated ESP/AH?

no.  I'll add qualifications that this applies when the "IPv4 Protocol 
and IPv6 Next Header Fields" are set to AH and ESP. specifically:

              The rules defined in this section only apply when the
               IPv4 Protocol or IPv6 Next Header Field contains the IANA
               defined value for AH or ESP.

> There is also

This was not discussed in the working group -- so a really great point 
to raise in this review.  Thank you!

As it has it's own protocol number, it would be not too hard to add.  
That said, there's no reason it couldn't be added later and no one in 
the working group raised it.  What do you think, is it important to add 
it now.

> too, i.e., match all ESP/AH traffic between two hosts regardless of SPI.

Agreed.  I think this is what is intended by the existing earlier text:

               Implementation SHOULD
               also allow for the field to be ignored for a specific
               DetNet flow.

So another good catch!

> have any visibility which SPI match witch QoS level.

understood.  The thinking is that such information will need to be 
mapped into the controller (control/management) plane provisioning of 
the QoS parameters subject to whatever restrictions are appropriate to 
not expose any security information.

Thanks again for the review!

Lou

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Mar 2020 13:08:59 +0200

Lou Berger writes:
> > In section 5.1.2.2 it says that SPI field of the ESP and AH is
> > used, but in case the IPsec is configured to use UDP encapsulation
> > (rfc3948, i.e., UDP destination port is 4500) there is different
> > location for the SPI. Should this document also dig SPI out from
> > the UDP encapsulated ESP/AH?
> 

If you are not concerned UDP encapsulated IPsec, then I think you can
ignore the Wrapped ESP too. I have not seen wrapped ESP in any real
use, compared to the UDP encapsulated IPsec, which is very commonly
used.

Wrapped ESP was meanly meant for enterprice use cases where they want
authentication only, but no encryption, as they do want to look inside
the packets.

UDP encapsulated IPsec is used when there is NATs in play, i.e., most
of the IPsec traffic from roadwarriors, i.e. laptops in hotels etc.
-- 
[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Mar 2020 08:31:43 -0400

Thanks again Tero.

I've made the changes in a PR to the document git repo and they will be
in the post LC update version.

Lou