Re: [ippm] draft-ietf-ippm-ioam-data-integrity

[Tommy Pauly <[e-mail]>]

(No hats)

My impression is that solution #2, where we protect the data fields only, should be sufficient to address the integrity goals.

Thanks,
Tommy

> On Jan 11, 2022, at 10:58 AM, Justin Iurman <[e-mail]> wrote:
> 
> Hi all,
> 
> On behalf of the authors of draft-ietf-ippm-ioam-data-integrity, and as a new
> co-author, I wanted to share a key question that arose when working on the next
> version of the draft. Hope we can get some feedback or advice.
> 
> Currently, version -00 specifies that not only IOAM data fields are protected
> (i.e., signed) but also headers (both the IOAM Option-Type and the Integrity
> Protected Option-Type headers). Headers are signed by the encap node. It is
> indeed the most secure and complete solution. However, some header fields are
> updated in place between the encap and decap, which makes it impossible to
> include them in the signature or the validator won't be able to recompute it.
> For instance, as defined in draft-ietf-ippm-ioam-data, it is the case for the
> Trace Option-Type with its Flags field (especially the Overflow bit) and its
> RemainingLen field. The problem is potentially equivalent for the POT
> Option-Type and its future "Flags", depending on their definitions (note that
> the Cumulative field, which is a data field, must be excluded no matter what,
> for the exact same reason as mentioned above). Therefore, we can think of two
> solutions, although solution #2 would have our vote.
> 
> Solution #1: include headers in the signature, exclude header fields that are
> updated in place.
> * pros:
>  - some header fields are protected.
> * cons:
>  - requires to define which fields to include/exclude in/from the signature,
>    and so for each Option-Type header.
>  - more processing due to non-contiguous fields to include, potentially.
> 
> Solution #2: exclude headers (both the IOAM Option-Type and the Integrity
> Protected Option-Type) from the signature.
> * pros:
>  - avoids cons from solution #1.
> * cons:
>  - headers are not protected.
> 
> Based on this tradeoff, we'd go for #2. It actually makes sense, as the draft is
> about "Integrity of In-situ OAM Data Fields". Of course, one could argue that
> some header fields bring context to data fields and, if altered, could
> potentially trick nodes on the path (e.g., Namespace-ID). This is true, and it's
> also exactly why we bring this discussion to the list, so that we can reach a
> consensus on the best solution to adopt. FYI, draft-ietf-ippm-ioam-data has a
> section which states that in case you're looking for integrity protection, you
> can consider the data-integrity draft, or rely on the encapsulating protocol.
> The latter is therefore a solution for #2.
> 
> Thanks,
> Justin
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm