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 <[email protected]>
Sent: Thursday, June 8, 2023 3:28 PM
To: Linda Dunbar <[email protected]>; [email protected]
Cc: [email protected]; [email protected];
[email protected]
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
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
