Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-probe-attribution-05

[Justin Iurman <[e-mail]>]

Hi Linda,

Actually, probes could be whatever you want. It is defined in the draft as:

    Many measurement researches ([LARGE_SCALE], [RFC7872], and
    [I-D.draft-vyncke-v6ops-james]) are about sending IP packets
    (sometimes with extension headers or layer-4 headers) over the public
    Internet and those packets can be destined to either collaborating
    parties or non-collaborating ones.  Such packets are called probes in
    this document.

So, basically, a probe is a packet. Let's say, for example, that I'm a 
researcher and I want to measure if an IPv6 Hop-by-Hop Extension Header 
goes through from my home router towards a random target, with TCP as 
layer 4. I'd send some crafted packets (i.e., IPv6/Hbh/TCP), also called 
probes in this document. So far so good. Let's now assume that you are 
an operator where these probes transit or arrive. As is, you don't 
really know why you're receiving them and it could be perceived as 
harmful or aggressive. This document proposes simple techniques for a 
source (me, in this case) to identify the probes for any third parties 
on the path that would want to know (one of them is you, in this case). 
In fact, it allows me to say "I'm the origin of these probes and I do 
that because ...", so that you are able to understand why you receive 
such probes.

Thanks,
Justin

On 7/11/23 22:35, Linda Dunbar wrote:
> Justin,
> 
> Thank you very much for the explanation.
> Is the "Probe" another ICMP message?  Does the "probe" have an ICMP Header?
> 
> 
> Does it mean that Source can include an "URL" to the ICMP message content?
> 
> 
> I reviewed the -08 version, I still can't find answers to my puzzle.
> 
> Thank you
> Linda
> 
> -----Original Message-----
> From: Justin Iurman <[e-mail]>
> Sent: Thursday, June 8, 2023 3:28 PM
> To: Linda Dunbar <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Opsdir last call review of draft-ietf-opsec-probe-attribution-05
> 
> Hi Linda,
> 
> Please see inline ([JI]).
> 
> On 6/8/23 18:06, Linda Dunbar via Datatracker wrote:
>> Reviewer: Linda Dunbar
>> Review result: Not Ready
>>
>> I have reviewed this document as part of the Ops area directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the Ops area directors.
>> Document editors and WG chairs should treat these comments just like
>> any other last-call comments.
>>
>> Summary:
>> This document describes the method for any organizations to send
>> queries to understand the received unsolicited probing packets.
> 
> [JI] I think there might be a misunderstanding here. What we define for the in-band technique is just a simple way to include a probe description URI (a link, an email address, a phone number, etc) in probes/packets so that third parties on the path would be able to identify them (what's the reason for such probes? who's responsible for that? what's the purpose? etc). We do *not* define how third parties would verify the probe attribution (at least, we explain how, but we do not define a query to do that automatically).
> 
>> Issues:
>> - Are those queries generated automatically?
> 
> [JI] Not really sure about what you mean with "queries". See the above explanation. If I missed your point, please shout.
> 
>> - If the queries are generated automatically, does it require routers
>> upgrade to support the auto-generating of those queries? - If the
>> queries are generated manually, the draft should give some detailed
>> examples since those queries will be generated by people not coming to
>> IETF. - Today, most routers ignore the Internet probes they don't support. What are the problems of ignoring them?
> 
> [JI] No, routers do not need any upgrade. If the out-of-band technique, nothing is included in probes. If the in-band technique, the probe attribution is included in probes, but these bytes are just like data payload.
> 
> Thanks,
> Justin
> 
>> Best Regards,
>> Linda Dunbar
>>
>>
>>