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

[Lou Berger <[e-mail]>]

Tero,

     Thank you for the comments, please see below.

On 3/12/2020 9:15 PM, Tero Kivinen via Datatracker wrote:
> 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.

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


>
> 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?

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
> wrapped ESP (rfc5840) with bit different format, i.e., having wrapped ESP
> header before the normal ESP header. Should this be included 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.

> 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.

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!

> 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.

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>