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

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.

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 <csp@csperkins.org> wrote:
>>
>> Hi,
>>
>> Apologies – I realise I’m replying to this very late.
>>
>>> On 4 Oct 2021, at 08:13, Tal Mizrahi <tal.mizrahi.phd@gmail.com> 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
>>> <noreply@ietf.org> 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
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm