Dear Eric,
thank you for your comments. I inlined my replies.
Am 21.07.24 um 16:51 schrieb Eric Vyncke (evyncke):
Dear authors,
Without any hat (i.e., feel free to ignore), in preparation for the
IETF-120 I have read your I-D and here are some comments. As always,
reviews note the things to
Dear IntArea WG,
we have submitted a new version of our stateless reverse traceroute draft.
https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-stateless
The biggest change is that we have added an ICMP multi-part extension
for adding padding bytes to the request in
Hi Ron,
to your first point: in reality, it is actually slightly more
complicated than this. If I run e.g. traceroute on my Mac, it will per
default use UDP (Windows tracert e.g. would use ICMP Echo Requests) and
it will have a little bit of payload (12 bytes all 0). It will use the
same
Hi Ron,
you raise a valid point, which however is not specific to reverse
traceroute but applies to regular traceroute just as well, since we
perform the exact same operation. One way to deal with this is assign a
port for this purpose just as for regular traceroute:
).
Thanks,
Rolf
Am 03.06.24 um 18:16 schrieb Dan Wing:
This is a great design and the statelessness also reduces amplification attack.
-d
On May 31, 2024, at 11:17 AM, Rolf Winter wrote:
Dear Int-Area WG,
the last time we presented Reverse Traceroute a comment was made that ICMP as
being used
Dear Int-Area WG,
the last time we presented Reverse Traceroute a comment was made that
ICMP as being used today usually does not keep state around. We still
believe that it does no real harm in this case but, as an alternative
that does not need state, we have written up a stateless
.
Cheers,
Tal.
On Wed, Jun 21, 2023 at 12:39 PM Rolf Winter wrote:
Hi Tal,
I don't think your assessment that a new type is required really holds
for every case. I think the key point is, the requests get _reflected_.
So if you expect something else in you response (e.g. Echo Request would
expect
Hi Tal,
I don't think your assessment that a new type is required really holds
for every case. I think the key point is, the requests get _reflected_.
So if you expect something else in you response (e.g. Echo Request would
expect a different type in the Echo Response), then you can
Dear Int-area folks,
we have updated our reverse traceroute draft. As always, we appreciate
comments and feedback on the document. You can find the new version here:
https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-01
Also, our implementation has progressed. Both
Dear Intarea WG,
in the not so distant future, we will make an update to our internet
draft on a reverse traceroute mechanism, that you can find here:
https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-00
Feedback welcome!
We now also have publicly available
Dear Intarea WG,
we have just submitted a 00 version of a reverse traceroute mechanism
relying on ICMP. You can find the document here.
https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute-00
The mechanism that is described there has been implemented in eBFP
Hi,
these pointers are very useful. Thanks. I would add one more:
https://tools.ietf.org/html/rfc8386
We know for a fact that there are protocols out there, even at the
application layer, that would thwart efforts to randomize MAC addresses.
Of course you'd have to be connected to the same
Warren,
I think I understand the issue you have with that bit of text.
draft-perkins-intarea-multicast-ieee802 discusses a bunch of bcast/mcast
management features that certain classes of APs provide. We have one
example of this in the draft (and should point to
nataro (cpignata):
Hi, Rolf,
On Jan 16, 2018, at 4:53 AM, Rolf Winter <rolf.win...@hs-augsburg.de
<mailto:rolf.win...@hs-augsburg.de>> wrote:
Carlos,
thanks for the review. Comments below:
Thanks to you for the quick response, and for the document. Please see
inline.
Am 14.01.18
Carlos,
thanks for the review. Comments below:
Am 14.01.18 um 05:20 schrieb Carlos Pignataro:
Reviewer: Carlos Pignataro
Review result: Not Ready
Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or
: Privacy considerations for IP broadcast and
multicast protocol designers
Authors : Rolf Winter
Michael Faath
Fabian Weisshaar
Filename: draft-ietf-intarea-broadcast-consider-05.txt
Pages : 13
Hi,
thanks for the review and sorry for the belated reply. Please see
comments inline.
Am 26.09.17 um 00:57 schrieb Nancy Cam-Winget (ncamwing):
Reviewer: Nancy Cam-Winget
Review result: On the right track
*General Comments*
There are actual distinctions that need to be made from a
Hi,
I am quite strongly opposed to assign any further IETF ressources to
this work. This has gone on too long for my taste. In April (!!,
https://www.ietf.org/mail-archive/web/int-area/current/msg05634.html)
the WG has already determined that it does not want to pursue this work
any further.
Internet-Drafts directories.
This draft is a work item of the Internet Area Working Group WG of the IETF.
Title : Privacy considerations for IP broadcast and
multicast protocol designers
Authors : Rolf Winter
Michael Faath
of the Internet Area Working Group of the IETF.
Title : Privacy considerations for IP broadcast and
multicast protocol designers
Authors : Rolf Winter
Michael Faath
Fabian Weisshaar
Filename
Tom,
see inline.
Am 3/9/17 um 6:13 PM schrieb t.petch:
I wonder if the mix of SHOULD and should is intentional.
And I cannot recall seeing RFC2119 as an Informative Reference before.
Will be fixed.
s.1
/ entierly/ entirely/
thanks, will be fixed, too.
And I am surprised at the
Dear chairs,
I am not aware of any IPR related to this document.
Best,
Rolf
Am 3/6/17 um 10:09 PM schrieb Juan Carlos Zuniga:
Dear Int-Area WG,
A review of draft-ietf-intarea-broadcast-consider has been published.
Since there was good support for this document from the beginning and
the
protocol designers
Authors : Rolf Winter
Michael Faath
Fabian Weisshaar
Filename: draft-ietf-intarea-broadcast-consider-02.txt
Pages : 11
Date: 2017-02-13
Abstract:
A number
Hi,
Randomized hostnames might have implications in places we do not even
think about for now, so why not take this as a mere example. Also, it
seems that the randomization might not be the problem but the time
between changes of a name, if tracking is the only use case. How about:
There
is important in the Internet architecture.
Joe
On 11/2/2016 3:34 AM, Rolf Winter wrote:
Hi Brian,
great that you found the document useful. Since the 00 version a lot
has changed, and you might want to look at it again. We will look at
RFC 5374 and see where it should be mentioned
?
Regards
Brian Carpenter
On 01/11/2016 03:08, Rolf Winter wrote:
Hi,
Apologies, but I screwed up the draft naming convention and just
uploaded the 00 and a 01 version with correct naming. The 00 version is
the one that was adopted by the WG, the 01 version now addresses the
comments made by Eliot
designers
Authors : Rolf Winter
Michael Faath
Fabian Weisshaar
Filename: draft-ietf-intarea-broadcast-consider-01.txt
Pages : 10
Date: 2016-10-31
Abstract:
A number
Hi,
me again... that of course should read: "during the adoption call".
Best,
Rolf
Am 10/31/16 um 10:10 AM schrieb Rolf Winter:
Hi,
we just posted version 02 of the broadcast/multicast considerations
draft. We believe we have now addressed the review comments that the
document ha
Hi,
we just posted version 02 of the broadcast/multicast considerations
draft. We believe we have now addressed the review comments that the
document has received during last call. Could commentors please check?
Best,
Rolf
___
Int-area mailing
Hi Stephane,
thanks for the review. We just posted a new version incorporating your
comments (see inline). We currently work on another version
incorporating examples as suggested.
https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-03
Am 9/9/16 um 3:02 PM schrieb Stephane
schrieb Eliot Lear:
Rolf,
Thanks. Please see below.
On 8/29/16 8:57 PM, Rolf Winter wrote:
What is needed are specific recommendations or even the strengthening of
a generalized mechanism, the obvious candidate being mDNS/DNS-SD. What
specific recommendations would the authors make when
Eliot,
thanks for the review. Please find comments inline:
Am 8/27/16 um 9:29 AM schrieb Eliot Lear:
Juan Carlos,
I like the idea of this document being published as an informational
document, but I wonder if the document needs another rev or two first.
While it is important to have privacy
of the IETF.
Title : Current Hostname Practice Considered Harmful
Authors : Christian Huitema
Dave Thaler
Rolf Winter
Filename: draft-ietf-intarea-hostname-practice-03.txt
Pages : 11
Rolf Winter
Filename: draft-ietf-intarea-hostname-practice-02.txt
Pages : 10
Date: 2016-05-10
Abstract:
Giving a hostname to your computer and publishing it as you roam from
one network to another is the Internet
Am 1/26/16 um 2:01 AM schrieb Christian Huitema:
On Monday, January 25, 2016 4:37 PM, Rolf Winter wrote:
Am 1/26/16 um 1:10 AM schrieb Christian Huitema:
...
Rolf, I appreciate that you are trying to improve network privacy, but I
wonder whether a generic abstract draft is the best way
esp. sec 5 and 6.
Joe
On 1/18/2016 4:07 AM, Rolf Winter wrote:
Hi,
we just posted a draft that discusses considerations for IP
broadcast/multicast protocol designers:
https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-00
We presented this work briefly during the last meeting i
Am 1/25/16 um 10:54 PM schrieb Joe Touch:
On 1/25/2016 1:47 PM, Rolf Winter wrote:
Hi Joe,
The document focusses right now on observed behaviour of dominant
protocols by a) volume/message frequency and b) content that gives away
privacy relevant information. Some of these are (popular
Am 1/26/16 um 1:10 AM schrieb Christian Huitema:
On Monday, January 25, 2016 2:16 PM, Rolf Winter wrote:
Am 1/25/16 um 10:54 PM schrieb Joe Touch:
On 1/25/2016 1:47 PM, Rolf Winter wrote:
Hi Joe,
The document focusses right now on observed behaviour of dominant
protocols by a) volume
Hi,
we just posted a draft that discusses considerations for IP
broadcast/multicast protocol designers:
https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-00
We presented this work briefly during the last meeting in Yokohama in a
1 minute pitch during the chairs
39 matches
Mail list logo
