Re: [ippm] Tsvart early review of draft-ietf-ippm-ioam-direct-export-06

[Justin Iurman <[e-mail]>]

Hi Tal,

Sounds good. I'd replace the following, though:

  - s/DEX option/DEX Option-Type/
  - s/IOAM option/IOAM Option-Type/
  - s/IOAM data fields/IOAM-Data-Fields/

not only for this paragraph but for the entire document, so that we keep 
consistency with notations from RFC 9197.

+ see inline for my answer to your remark ([JI]).

Thanks,
Justin

On 6/14/22 11:06, Tal Mizrahi wrote:
> Hi Justin,
> 
> Thanks for the heads up. You raised a good point.
> 
> I suggest the following text instead.
> 
> 
>        The integrity of the DEX option can be protected through a mechanism
>        of the encapsulating protocol. While [I-D.ietf-ippm-ioam-data-integrity]
>        introduces an integrity protection mechanism that protects the
>        integrity of IOAM data fields, the DEX option does not include IOAM
>        data fields, and therefore these integrity protection mechanisms are not
>        applicable to the DEX option. As discussed in the threat analysis of
>        [I-D.ietf-ippm-ioam-data-integrity], injection or modification of IOAM
>        option headers are threats that are not addressed in IOAM.
> 
> + please see an additional comment below, marked [[TM]].
> 
> Cheers,
> Tal.
> 
> 
> On Tue, Jun 14, 2022 at 11:00 AM Justin Iurman <[e-mail]> wrote:
>>
>> Hi Tal,
>>
>> I believe the new paragraph should be:
>>
>>       The integrity of the DEX option can be protected through a mechanism
>>       of the encapsulating protocol.
>>
>> Indeed, integrity protection of headers is out of scope regarding
>> [I-D.ietf-ippm-ioam-data-integrity]. Only the integrity protection of
>> IOAM-Data-Fields is proposed in this draft. And, the DEX Option-Type has
>> no IOAM-Data-Fields, per se.
>>
>> Actually, [I-D.ietf-ippm-ioam-data-integrity] could be applied between
>> the IOAM transit nodes and the collector (or entity, whatever it is
>> called), once triggered by the DEX Option-Type.
> 
> [[TM]] Let's not go there. The exporting format is something that is
> not currently within the scope of any working group document, and
> specifically the integrity of the exporting format is currently out of
> scope. It will be in scope once the working group adopts an exporting
> format.
> 

[JI] Ofc, I only mentioned this as a possibility to explain the 
situation. Looks like we're on the same page :-)

>>
>> Thanks,
>> Justin
>>
>> On 6/14/22 09:17, Tal Mizrahi wrote:
>>> Dear Colin,
>>>
>>> Thanks again for your review.
>>> I am revisiting this thread as the draft is in IETF last call.
>>>
>>> I believe most of the comment have already been addressed - see the
>>> current version of the draft:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-08
>>>
>>> There is one comment that is still outstanding, regarding your comment
>>> about integrity protection. We propose to add the following paragraph
>>> to the Security Considerations section:
>>>
>>>      The integrity of the DEX option can be protected through
>>>      a mechanism of the encapsulating protocol, or by incorporating
>>>      the mechanisms specified in [I-D.ietf-ippm-ioam-data-integrity].
>>>
>>> If there are no further comments, we will include this paragraph in
>>> the next version of the draft.
>>>
>>> Thanks,
>>> Tal.
>>>
>>> On Fri, Nov 26, 2021 at 3:40 PM Colin Perkins <[e-mail]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Apologies – I realise I’m replying to this very late.
>>>>
>>>>> On 4 Oct 2021, at 08:13, Tal Mizrahi <[e-mail]> wrote:
>>>>>
>>>>> Dear Colin,
>>>>>
>>>>> Thanks for the feedback.
>>>>>
>>>>> Please see below a comment and a question regarding your feedback.
>>>>>
>>>>>
>>>>> On Fri, Sep 3, 2021 at 5:54 PM Colin Perkins via Datatracker
>>>>> <[e-mail]> wrote:
>>>>> [snip]
>>>>>
>>>>>> It may be worth considering to require the exporting mechanism to perform an
>>>>>> authenticated handshake with the destination to which it will export data, to
>>>>>> gain explicit consent to export the data to that destination, before starting
>>>>>> to send exported data.
>>>>>
>>>>> [TM] The point is well-taken. The following text edit is proposed,
>>>>> borrowing some of the text from your comment:
>>>>> OLD:
>>>>>     Although the exporting method is not within the scope of this
>>>>>     document, any exporting method MUST secure the exported data from the
>>>>>     IOAM node to the receiving entity.  Specifically, an IOAM node that
>>>>>     performs DEX exporting MUST send the exported data to a pre-
>>>>>     configured trusted receiving entity.
>>>>> NEW:
>>>>>     Although the exporting method is not within the scope of this
>>>>>     document, any exporting method MUST secure the exported data from the
>>>>>     IOAM node to the receiving entity.  Specifically, an IOAM node that
>>>>>     performs DEX exporting MUST send the exported data to a pre-
>>>>>     configured trusted receiving entity. Furthermore, an IOAM node
>>>>>     MUST gain explicit consent to export data to a receiving entity before
>>>>>     starting to send exported data.
>>>>
>>>> Something like that would seem appropriate.
>>>>
>>>>>> It may also be worth considering to add authentication
>>>>>> of IOAM DEX triggers, to ensure they come from a known and trusted source,
>>>>>> before acting on export requests.
>>>>>>
>>>>>
>>>>> [TM] Can you please clarify what you mean by "add authentication of
>>>>> IOAM DEX triggers"? What is the threat that you have in mind?
>>>>
>>>>
>>>> As the security considerations section notes, there’s a risk that an attackers could inject a spoof packet containing an export trigger. One way to prevent that would be to use a digital signature to authenticate the trigger messages as being from an authorised source. Maybe the larger IOAM framework already includes this, or a discussion of why it’s not appropriate, in which case it’s sufficient to add a (clearer) reference to that discussion. But if not, then the draft could usefully either add that, or add some discussion about why it’s not needed/appropriate.
>>>>
>>>> --
>>>> Colin Perkins
>>>> https://csperkins.org/
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ippm