Re: [Int-area] New Draft - ICMPv6 Loopback

[Rolf Winter]

Hi Tal,

don't get me wrong. Of course a new type is technically an equally valid 
solution and I do not want to talk you into using new codes under an 
existing type instead. I just wanted to point out that I believe 
generally speaking working with new codes is equally valid and feasible, 
which is what reverse traceroute 
(https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute) 
is suggesting.


Using different codes was just one example to distinguish a request from 
a response given the reflective behavior of hosts on the internet. The 
same would apply if the ICMP payload or something else in the header 
would differ in the response.


Best,

Rolf

Am 21.06.23 um 13:49 schrieb Tal Mizrahi:

Hi Rolf,

I agree that a new type is not necessarily required for every case,
however a new type is probably the cleanest solution for Loopback.

Here is an alternative solution that does not require a new type:
- The Loopback requester sends an Echo Request with code=X (newly
allocated to indicate Loopback Request).
- The Loopback responder replies with an Echo Reply with code=X+1
(newly allocated to indicate Loopback Reply).
- The requester can distinguish a Loopback reply (code=X+1) from a
reply received from a legacy device (which reflects code=X).

While this solution should work, it assumes a certain behavior from
legacy devices (reflecting code=X as-is) that is not compliant with
RFC 4443.
Therefore, I believe using a new type would be cleaner.

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 a different type in the Echo Response), then you can distinguish
a reflecting host from a host that actually understands this "new ICMP
thing". The real good news is in both measurement cases are that a) most
tested NATs let those packets through (both request and response) and b)
mostly, they cross the internet unmodified as can be seen in the
unmodified code inside the ICMP reply (for v4 at least).

Best,

Rolf

Am 21.06.23 um 06:53 schrieb Tal Mizrahi:

Hi Valentin,

Thanks for this valuable data.
Based on your findings, the good news is that new codes will most
likely traverse NATs, and the bad news is that most hosts will respond
according to the "old" behavior without checking the code value. In
light of the latter observation, I would say that new behavior *from
the responder* requires a new ICMP type. However, more feedback about
this assessment is welcome.

Cheers,
Tal.

On Tue, Jun 20, 2023 at 8:45 PM Valentin Heinrich
 wrote:


we had similar questions when working on reverse traceroute
(https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute).
Should we use new ICMP types or extend existing ones with a new code?

We actually conducted measurements to test deployability of those two
choices.
One of the big question marks was whether new ICMP messages using a new
type are able to traverse common NAT middleboxes.
Unfortunately, as one would probably expect, new ICMP types are most
commonly filtered (or they just bypass the NAT, which is just as bad as
they are forwarded untranslated into the public internet).
We then sent ICMP Echo requests with the new codes 1 and 2 through those
same NAT boxes.
Only a single NAT box (out of 12) dropped the corresponding Echo
response message and in all other cases both requests and replies
correctly traversed the NAT.
In this regard, our measurements showed that extending existing ICMP
Echo messages with new codes is the way to go if immediate deployability
is the goal.

We then also performed a measurement to assess the deployment of ICMP
Echo messages with new codes on the public Internet.
We probed over a million hosts that correctly responded to regular ICMP
Echo requests (code 0) with ICMP Echo responses.
To each of those hosts we sent ICMP Echo requests with code 1. Over 92%
of the probed hosts responded with an ICMP Echo response and reflected
the new code back in their response.
The fact that we received that many "reflective" responses shows us,
that ICMP Echo messages (both request and response) with a new code make
it through the Internet unfiltered and unaltered in the vast majority of
cases. About 3% of the probes were answered with a regular ICMP Echo
response (code 0), thus not reflecting the request's code back.

For more details of the measurement study, you can have a look at this
talk: https://youtu.be/Y7NtqLEtfgjU?t=63

Or listen to this episode of the Ping Podcast:
https://blubrry.com/ping_podcast/94883480/reverse-traceroute-its-just-traceroute-but-the-other-direction/


One caveat is however that we conducted these measurements only on IPv4.
Results might or might not differ for IPv6.
For reverse traceroute, which itself imple

Re: [Int-area] New Draft - ICMPv6 Loopback

[Rolf Winter]

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 distinguish 
a reflecting host from a host that actually understands this "new ICMP 
thing". The real good news is in both measurement cases are that a) most 
tested NATs let those packets through (both request and response) and b) 
mostly, they cross the internet unmodified as can be seen in the 
unmodified code inside the ICMP reply (for v4 at least).


Best,

Rolf

Am 21.06.23 um 06:53 schrieb Tal Mizrahi:

Hi Valentin,

Thanks for this valuable data.
Based on your findings, the good news is that new codes will most
likely traverse NATs, and the bad news is that most hosts will respond
according to the "old" behavior without checking the code value. In
light of the latter observation, I would say that new behavior *from
the responder* requires a new ICMP type. However, more feedback about
this assessment is welcome.

Cheers,
Tal.

On Tue, Jun 20, 2023 at 8:45 PM Valentin Heinrich
 wrote:


we had similar questions when working on reverse traceroute
(https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute).
Should we use new ICMP types or extend existing ones with a new code?

We actually conducted measurements to test deployability of those two
choices.
One of the big question marks was whether new ICMP messages using a new
type are able to traverse common NAT middleboxes.
Unfortunately, as one would probably expect, new ICMP types are most
commonly filtered (or they just bypass the NAT, which is just as bad as
they are forwarded untranslated into the public internet).
We then sent ICMP Echo requests with the new codes 1 and 2 through those
same NAT boxes.
Only a single NAT box (out of 12) dropped the corresponding Echo
response message and in all other cases both requests and replies
correctly traversed the NAT.
In this regard, our measurements showed that extending existing ICMP
Echo messages with new codes is the way to go if immediate deployability
is the goal.

We then also performed a measurement to assess the deployment of ICMP
Echo messages with new codes on the public Internet.
We probed over a million hosts that correctly responded to regular ICMP
Echo requests (code 0) with ICMP Echo responses.
To each of those hosts we sent ICMP Echo requests with code 1. Over 92%
of the probed hosts responded with an ICMP Echo response and reflected
the new code back in their response.
The fact that we received that many "reflective" responses shows us,
that ICMP Echo messages (both request and response) with a new code make
it through the Internet unfiltered and unaltered in the vast majority of
cases. About 3% of the probes were answered with a regular ICMP Echo
response (code 0), thus not reflecting the request's code back.

For more details of the measurement study, you can have a look at this
talk: https://youtu.be/Y7NtqLEtfgjU?t=63

Or listen to this episode of the Ping Podcast:
https://blubrry.com/ping_podcast/94883480/reverse-traceroute-its-just-traceroute-but-the-other-direction/


One caveat is however that we conducted these measurements only on IPv4.
Results might or might not differ for IPv6.
For reverse traceroute, which itself implements both ICMP and ICMPv6, we
have however successfully tested our implementation across the public
internet.

I hope this data point helps in this discussion.

On 07.06.23 06:30, Tal Mizrahi wrote:

Bob, Eric,

Thanks for the feedback.
Defining a new code for ICMPv6 Echo rather than defining a new type
may be the right way to go.
Our main concern with this is that RFC 4443 defines what to do with an
unknown type, but does not define what to do with an unknown code. It
is not clear what existing implementations do when receiving an Echo
Request with an unknown code. That is why the current draft calls for
a new type. However, we are open to more feedback about this, and it
may end up being just a new code.

Cheers,
Tal.

On Tue, Jun 6, 2023 at 8:33 PM Eric Vyncke (evyncke)  wrote:

Without any hat, I agree with Bob.

This I-D should eventually go to 6MAN WG though (with my AD hat)

-éric

On 06/06/2023, 08:34, "Int-area on behalf of Bob Hinden" mailto:int-area-boun...@ietf.org> on behalf of bob.hin...@gmail.com 
> wrote:


Tal,


I did a quick read of your draft.


As noted in the draft this seems to be very similar to ICMPv6 Echo/Echo Reply. 
The change is to include the request packet in the response, not just the 
payload.


While I don’t have any real opinion on the need for this, I do think it would 
be a lot simpler if the draft just defined a new Code field value for Echo 
Request/Reply that specified this behavior. Currently the Code field is set to 
zero, another value could specify this behavior.


Deployment might be 

[Int-area] Reverse Traceroute - update

[Rolf Winter]

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 client and server now 
fully support v4 and v6. If you would like to host a server instance, 
please come and talk to us. The code and documentation can be found here:


https://github.com/hsanet/reverse-traceroute

If you just want to experiment with the client, you can find a list of 
public servers here:


https://github.com/HSAnet/reverse-traceroute/blob/main/ENDPOINTS

If you prefer a video, here is a talk on reverse traceroute given at 
DENOG14:


https://youtu.be/Y7NtqLEtgjU

Or for an overview of all the work we have done so far, check out:

https://net.hs-augsburg.de/en/project/reverse-traceroute/

Thanks,

Rolf


smime.p7s
Description: S/MIME Cryptographic Signature
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Reverse Traceroute - running code

[Rolf Winter]

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 running code (both server and client 
implementations), that you can find here:


https://github.com/HSAnet/reverse-traceroute

We would appreciate, if people could offer to host a reverse traceroute 
server on the public internet, since we are both evaluating the current 
implementation and planning our next improvements. If anybody is 
interested, please reach out to me. Also, if people would like to run 
the client, there is a command line switch that will send us the result 
of a reverse traceroute run. We would appreciate, if you could run our 
client against one or more public instances of reverse traceroute, that 
would be great and use the switch to send us the measurement. So far 
there is only one public endpoint, but the list in the ENDPOINTS file in 
the above mentioned github repository will be updated, as more public 
endpoints come online.


In addition to the implementation, we presented our work at DENOG14 (the 
annual conference of the german network operators group). The feedback 
from the operational community was very good and there is interest in 
the work. If you would like to hear about reverse traceroute and the 
things that drove our design, the talk was recorded and is available here:


https://youtu.be/Y7NtqLEtgjU

As always, please read the document, send us feedback and if you can 
host a reverse traceroute instance, please reach out.


Thanks a lot,

Rolf


smime.p7s
Description: S/MIME Cryptographic Signature
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Reverse Traceroute draft

[Rolf Winter]

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 
(server) and as a python script (client). We would appreciate feedback 
on the general idea and of course on all the protocol details.


Best,

Rolf




smime.p7s
Description: S/MIME Cryptographic Signature
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [Captive-portals] [homenet] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Rolf Winter]

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 L2 network, but the 
IETF meeting network, internet cafes, campus networks... it is not 
uncommon to be connected at L2 to devices that you probably do not 
trust, manage, know about.


I think a BoF about this general topic would be interesting, but I 
believe it should be scoped tightly, so the discussion can be focussed.


Best,

Rolf

Am 29.09.20 um 22:10 schrieb Juan Carlos Zuniga:
Indeed, this is a continuation of the work started at IEEE 802 back in 
2014 after the STRINT Workshop pre-IETF 89 [1] [2].


So far IEEE 802 has developed the (soon to be published) 802E Privacy 
Recommendations [3], the recommended use of MAC address randomization in 
802c [4], and now the work in 802.11 that Peter points out.


We carried out the experiment on the IETF (x2) and IEEE 802 Wi-Fi 
meeting networks and we published some results at the time [5]. Even 
though we found some very minor impact on DHCP, the experiment showed 
that MAC address randomization worked fine. However, as we pointed out 
the Privacy issues should not stop at L3.


If there is a good take away from that work, it is that Privacy cannot 
be solved at a single layer, and effective solutions should be system-wide.


Juan Carlos

[1] 
https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-tutorial.pdf 



[2] http://www.ieee802.org/PrivRecsg/

[3] https://1.ieee802.org/security/802e/

[4] https://ieeexplore.ieee.org/document/8016709

[5] https://ieeexplore.ieee.org/abstract/document/7390443/  pre-print: 
https://www.it.uc3m.es/cjbc/papers/pdf/2015_bernardos_cscn_privacy.pdf



On Tue, Sep 29, 2020 at 3:40 PM Peter Yee > wrote:


On 29/09/2020 12:03, Stephen Farrell wrote:

 > More on-topic, I do think MAC address randomisation has a role to
play for WiFi as it does for BLE, but yes there is a lack of
guidance as to how to implement and deploy such techniques well.
It's a bit tricky though as it's fairly OS dependent so maybe not
really in scope for the IETF?
 > (For the last 3 years I've set a possible student project in this
space, but each time a student has considered it, it turned out "too
hard";-)

As I mentioned previously, IEEE 802.11 is looking into this area,
both from an operational perspective and from a privacy perspective.
New IEEE 802.11 amendments (IEEE 802.11bh and IEEE 802.11bi, if
approved) are being discussed. The (very) high-level documents
describing each can be found at [1] and [2]. I would be happy to
convey input to IEEE 802.11 regarding either document, particularly
in regards to layers 3 and above. Without wishing to open up a can
of worms about meeting fees, I will note that IEEE 802.11 is
currently not charging for its online meetings, so if anyone wishes
to take part in the random MAC address discussions directly, the
next meeting will be held in early November. The RCM Study Group met
yesterday morning (Americas) and will meet again in two weeks. See [3].

                 -Peter

[1]

https://mentor.ieee.org/802.11/dcn/20/11-20-0742-04-0rcm-proposed-par-draft.docx
[2]

https://mentor.ieee.org/802.11/dcn/20/11-20-0854-06-0rcm-par-proposal-for-privacy.pdf
[3]
https://mentor.ieee.org/802.11/dcn/20/11-20-0995-10-0rcm-rcm-sg-agenda.pptx



___
Int-area mailing list
Int-area@ietf.org 
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area





smime.p7s
Description: S/MIME Cryptographic Signature
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Warren Kumari's Discuss on draft-ietf-intarea-broadcast-consider-08: (with DISCUSS and COMMENT)

[Rolf Winter]

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 
draft-perkins-intarea-multicast-ieee802 for more examples). The problem 
is, that these features target specific protocols, i.e. ones that are 
standardized and worth paying attention to. The rest can only be dealt 
with by not rebroadcasting frames over the wireless medium. That is the 
best you can do. And it is done for performance reasons on networks such 
as the IETF meeting network, but I guess not for privacy reasons. All we 
really wanted to say was, that as a network administrator you can 
protect your users from the privacy risks described in the document, but 
you might affect certain applications, potentially rendering them 
useless. And we wanted it to be value-free because this in not a black 
and white thing in my personal opinion.


As a suggestion, we would add 
draft-mcbride-mboned-wifi-mcast-problem-statement and respective text. 
Since we already have the other draft in the document, we would point to 
the already implemented things in 
draft-perkins-intarea-multicast-ieee802, which really makes a good point 
for reusing IETF-specified protocols and not invent something new. Would 
that clear your discuss?


Best,

Rolf

Am 25.01.18 um 00:58 schrieb Warren Kumari:

Warren Kumari has entered the following ballot position for
draft-ietf-intarea-broadcast-consider-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/



--
DISCUSS:
--

Sorry for the late DISCUSS. I'm likely to clear after discussions on the call
tomorrow.

I'm somewhat surprised at how much this document glosses over the (sometimes
extensive) broadcast/multicast twiddling that Access Points and similar do (a
fair bit of discussion of which can be found in
draft-perkins-intarea-multicast-ieee802 (which I think will be expiring) or
draft-mcbride-mboned-wifi-mcast-problem-statement). Simply saying: "A feature
not uncommonly found on access points e.g. is to filter broadcast and multicast
traffic.  This will potentially break certain applications or some of their
functionality but will also protect the users from potentially leaking
sensitive information." seems to be shrugging off all of the privacy benefits
(or possibly harms) that this might create.


--
COMMENT:
--

I found this sentence very confusing:
" For one, non-standard  protocols will likely not receive operational
attention and support in making them more secure such as e.g.  DHCP snooping
does for DHCP because they typically are not documented. "   -- I know what it
is trying to say, but I don't think it accomplishes what it intends to.


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05

[Rolf Winter]

Hi Carlos,

we just uploaded a new version. I think I now better understood your 
comments. We stressed the fact, that in order to become a receiver (for 
the relevant addresses described in section 1.1. "To become a receiver, 
the only requirement is to be part of the same subnetwork." I hope this 
makes it much clearer, what the thread is and what a "passive observer" is.


We also changed the wording the the summary from "you SHOULD"... to "the 
protocol SHOULD".


Thanks again for your feedback.


Rolf

Am 16.01.18 um 06:44 schrieb Carlos Pignataro (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 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 routing-related 
drafts as
they pass through IETF last call and IESG review, and sometimes on 
special
request. The purpose of the review is to provide assistance to the 
Routing ADs.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, 
it would

be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through 
discussion or by

updating the draft.
Summary:
This document has a set of minor issues, detailed below.
Comments:
1. Target
The document's title targets "IP broadcast and multicast protocol 
designers",
the Abstract and document throughout about "Therefore, 
broadcast/multicast
protocol designers". However, upon reading, it becomes clear that the 
target
audience of this document is not multicast/broadcast protocol 
designers, but
rather designers (?) of higher-level protocols that use broadcast or 
multicast.
The Abstract does say "A number of application-layer protocols make 
use of IP
broadcasts or". This causes major confusion on the first few reads of 
the doc.
In addition to the target layer, the role is unclear. The document 
says "Also
application developers use broadcast/multicast messages to implement" 
in at
least one more instance. Do these considerations target designers, 
developers,

both? Of multicast protocols? Of application protocols?



Point well taken. As the previous reviewer suggested something 
similar, we changed the title from:


"Privacy considerations for IP broadcast and multicast protocol designers"

to

"Privacy considerations for protocols relying on IP broadcast and 
multicast""


And made textual changes throughout the document to rephrase 
"broadcast/multicast protocol" to something along the lines of 
"protocol making use of broadcast/multicast messages”




Thanks! I believe that change will add much clarity.


We published a new version reflecting that already.


2. Threat model
The document talks about "a passive observer in the same 
broadcast/multicast

domain". It does not seem to cover, however, how exactly is bcast/mcast
different from unicast, when the passive observer has an interface is
promiscuous mode or has a packet capture library.


But there is a whole section on what boradcast/multicast is being used 
for and how it differs from unicast. It also details which multicast 
addresses are most relevant for this work. The key is that the 
receiver group is much larger and protecting the traffic, with e.g. 
encryption is much harder.


I think you are pointing to S1.1. In my comment, I was referring more to 
the characteristics of the user, rather than those of bcast/mcast. 
Stephane’s email response explained that. Maybe better defining a 
“passive observer”? “Plugging” into the segment and capturing without 
any tapping?





The doc then says "can trivially record these messages and analyze their
content". But how trivial or not it is to analyze the message 
contents seems to
be independent of the means in which they are sent. After captured, 
how is a

unicast different than a bcast/mcast? The content can have cryptographic
protection, which might make it not trivial to analyze.


That is the whole point and the document I thought is clear about it. 
In order to being able to even capture a unicast packet, you'd have to 
be at a special location inside the network such as a router.


“Passive observer” does not specify the attachment characteristics or 
location of the observing. That’s why I suggested above define the 
vector with more precision.


Bcast you just have to be connected to the network and then listen. 
Also, crypto is so much 

Re: [Int-area] Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05

[Rolf Winter]

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 routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Summary:

This document has a set of minor issues, detailed below.

Comments:

1. Target

The document's title targets "IP broadcast and multicast protocol designers",
the Abstract and document throughout about "Therefore, broadcast/multicast
protocol designers". However, upon reading, it becomes clear that the target
audience of this document is not multicast/broadcast protocol designers, but
rather designers (?) of higher-level protocols that use broadcast or multicast.
The Abstract does say "A number of application-layer protocols make use of IP
broadcasts or". This causes major confusion on the first few reads of the doc.

In addition to the target layer, the role is unclear. The document says "Also
application developers use broadcast/multicast messages to implement" in at
least one more instance. Do these considerations target designers, developers,
both? Of multicast protocols? Of application protocols?



Point well taken. As the previous reviewer suggested something similar, 
we changed the title from:


"Privacy considerations for IP broadcast and multicast protocol designers"

to

 "Privacy considerations for protocols relying on IP broadcast and 
multicast""


And made textual changes throughout the document to rephrase 
"broadcast/multicast protocol" to something along the lines of "protocol 
making use of broadcast/multicast messages"


We published a new version reflecting that already.



2. Threat model

The document talks about "a passive observer in the same broadcast/multicast
domain". It does not seem to cover, however, how exactly is bcast/mcast
different from unicast, when the passive observer has an interface is
promiscuous mode or has a packet capture library.


But there is a whole section on what boradcast/multicast is being used 
for and how it differs from unicast. It also details which multicast 
addresses are most relevant for this work. The key is that the receiver 
group is much larger and protecting the traffic, with e.g. encryption is 
much harder.




The doc then says "can trivially record these messages and analyze their
content". But how trivial or not it is to analyze the message contents seems to
be independent of the means in which they are sent. After captured, how is a
unicast different than a bcast/mcast? The content can have cryptographic
protection, which might make it not trivial to analyze.



That is the whole point and the document I thought is clear about it. In 
order to being able to even capture a unicast packet, you'd have to be 
at a special location inside the network such as a router. Bcast you 
just have to be connected to the network and then listen. Also, crypto 
is so much harder. With TLS two parties agree on keys etc. but in 
multicast it is not necessarily that trivial as more parties are 
involved. There is a reference regarding this also in the security 
considerations section.



3. References:

The document says:

"  Most of these items
are based on protocol behavior observed as part of experiments on
operational networks [TRAC2016]."

Based on this citation, should [TRAC2016] be Normative? And is it readily
available?


I would think one understands the document without having read the 
paper, so I would assume informative would be ok?




4. Qualification of examples used to derive conclusions.

"of a popular application", "A popular operating system". Which ones?


We discussed it a bit in WG review and later again. We decided we did 
not want to put "blame" on any app or OS. If you read the paper though, 
you'll know some ;)




Further, the document includes the following text:

"  This is
clearly true for any protocol, but broadcast/multicast is special in
at least two respects:

(a)  The aforementioned large receiver group, consisting of receivers
 unknown to the sender.  This makes eavesdropping without special
 privileges or a special location in the network trivial for
 anybody in the broadcast/multicast domain.

(b)  Encryption is more difficult when broadcast/multicast messages,
 leaving content of these messages in the clear and making it
  

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-05.txt

[Rolf Winter]

Hi,

we fixed a few things that were recommended by the last reviews (Int dir 
and IoT dir). The Int dir comments are fully addressed as far as 
possible (Carlos please shout if you disagree). We disagree with a few 
things recommended in the IoT dir review and would need clarifications 
on a few points for us to incorporate final changes.


Best,

Rolf

Am 25.10.17 um 10:50 schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line 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
   Fabian Weisshaar
Filename: draft-ietf-intarea-broadcast-consider-05.txt
Pages   : 13
Date: 2017-10-25

Abstract:
A number of application-layer protocols make use of IP broadcasts or
multicast messages for functions like local service discovery or name
resolution.  Some of these functions can only be implemented
efficiently using such mechanisms.  When using broadcasts or
multicast messages, a passive observer in the same broadcast/
multicast domain can trivially record these messages and analyze
their content.  Therefore, broadcast/multicast protocol designers
need to take special care when designing their protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-05
https://datatracker.ietf.org/doc/html/draft-ietf-intarea-broadcast-consider-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] IoT-dir early review of draft-ietf-intarea-broadcast-consider

[Rolf Winter]

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 general 
privacy/security


and considerations of using broadcast vs. multicast.  Whereas multicast has

the means by which multicast groups can be managed and thus authentication

and authorization of group membership to a multicast group can be handled,

broadcast does not.  As such, the privacy considerations, while sharing 
a lot


of commonality between multicast vs. broadcast, hold differences

that need to be called out.


The document focusses on cases where multicast is used in an unmanaged 
fashion, i.e. there is no authentication and authorization in place that 
can readily be used, see section 1.1 of the document. A tightly managed 
environment where authentication and authorization in place is not the 
target scenario. And most apps cannot really rely on something like this 
and use e.g. the all nodes addesses, broadcast or the local network 
control block.




*Technical comments:*

_Introduction:_

   The 2 respects called out need to be better clarified:

    For (a):  messages can be protected especially  in a multicast group 
and keys


     can be managed with membership changes, whereas broadcast 
is more


    difficult to manage.

    For (b): why is encryption more difficult??  Broadcast/multicast 
messages today


    are being encrypted, but are subject to full viewership by 
the key holders


    (e.g. members of the broadcast or multicast domain for the 
duration of that key)


    The last paragraph is of concern as its intent is not clear. I 
believe it is trying to state


that the draft is needed as RFC6973 focuses on the general privacy but 
more care is


needed for broadcast and multicast. If that’s the case, suggest to 
reduce paragraph


to a sentence or 2 to just highlight that point.


There is that, but there is a real concern that protocols developed 
outside the IETF which we see on networks today pose a risk to privacy. 
We wanted to make clear that this document is addressing people outside 
the IETF. We can reduce some text about that but I do not understand why 
that text is a concern. I would suggest to make a separate paragraph out 
of it, separating it from the reference to RFC6973. Would that work?




_Section 2.1_

*“Frequent bcast/mcast traffic caused by an application…”*

I think you mean the continuous use and the patterns it draws can define

a behavioral pattern….I don’t believe the literal “frequent” lends itself to

improving accuracy, but rather the temporal length of time in observing

such a pattern can improve on the fidelity of the behavioral pattern 
observed.


I guess most accurate would be frequency and duration.



In general, making the periodicity of the message use unpredictable is what

can help.  Otherwise, a better rationale or guidance on what 
“conservative” in


“the frequency SHOULD be chosen conservatively” is needed.





_Section 2.2_

*“true in case the IP and/or MAC address changes*”

I think you mean DOES NOT change.  Also, these track devices not users.


No, it really means "in case it is changing". There is work ongoing to 
implement MAC address or IP address randomization. But if a 
broadcast/multicast protocol is using persistent identifiers, then a 
passive observer can deduce that the MAC address has changed, because 
the application layer identifier is still the same. In other words, this 
might actually break the efforts on lower layers.




I would actually disagree that “frequent rotations of IDs” (in general) make

user tracking more difficult.  This section needs to improve the 
qualifications


and conditions for when and how it can make tracking more difficult.

While I do not entirely agree with rotation as a solution, I can see SOME

instances in which it can slow down the tracking but not completely 
obfuscate


behavior that can be used to deduce identity (of a device, or user).

I am also puzzled as to how this is unique to broadcast/multicast messages?


Could you give an example where this does not work, then we can address 
your concern. This is unique to broadcast/multicast, because a passive 
obserser sees this. In unicast traffic you need to be on-path to observe 
this, which is a special requirement and much harder to achieve (when 
you are on-path many more things are possible anyway).




_Section 2.4_

Need to capitalize the ‘should’ in the last paragraph as the intent is 
to provide


that as a recommended consideration.


I would disagree. Awareness is a recommendation that you cannot really 
enforce.




_Section 2.5_

What is a “safe” environment?  The first paragraph needs to be clear on

intent and definition of what is “safe”.


The following paragraphs do not suffice 

Re: [Int-area] Call for support: IPmix I-D (was IPv10)

[Rolf Winter]

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. There has only been a single proponent, who at some point 
wanted to have his text removed from the IETF servers and threatened to 
even use legal actions, just to come back days later with another 
version of this idea. The whole discussion around this is unfounded 
claims which industry professionals have dismissed repeatedly such as 
the ease of software updates to deploy this. As others have said, 
interested people can go someplace else and further discuss and develop 
this, but AFAICT, the IETF community as agreed to NOT pursue this 
further. Please make this stop! It is one thing to be nice to newcomers, 
which I believe is important, but THIS is not healthy to the community 
and it is wasting a lot of people's time. Rewarding this behaviour with 
additional IETF ressources will set a bad precedence in my oppinion.


Best,

Rolf



Am 05.10.17 um 05:08 schrieb Juan Carlos Zuniga:

Dear all,

The IntArea mailing list has been repeatedly used to debate 
draft-omar-ipv10. So far, comments posted on the mailing list have 
consistently pointed towards a highly controversial topic on multiple 
levels. This includes the lack of a valid problem statement as well as a 
clear and persistent disconnect between the suggested proposal in 
draft-omar-ipv10 and the current market trends, deployments and 
available solutions.


The IntArea AD and WG chairs are not satisfied with the nature and tone 
of the current exchange on the IntArea ML, nor enthusiastic about its 
potential prospect within the IntArea WG.


However, the IntArea AD and WG chairs would like to encourage pursuing 
the discussion outside the IntArea WG if there is sufficient interest in 
the topic, e.g., on a separate mailing list. For this purpose, we would 
like to gauge the community interest to work on the problem statement 
and proposal described in draft-omar-IPv10 (possibly to be renamed IPmix).


If you are interested in participating in the work mentioned above, 
please respond to this mail expressing your support by October 17, 2017.


Regards,

Juan Carlos, Wassim and Suresh

IntArea WG Chairs + AD



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-04.txt

[Rolf Winter]

Hi,

we did a few changes based on the feedback received from the shepherd 
review. They are mostly clarifying and cosmetic. If you have any 
questions, please let us know.


Best,

Rolf

Am 30.08.17 um 10:42 schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line 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
   Fabian Weisshaar
Filename: draft-ietf-intarea-broadcast-consider-04.txt
Pages   : 13
Date: 2017-08-30

Abstract:
A number of application-layer protocols make use of IP broadcasts or
multicast messages for functions like local service discovery or name
resolution.  Some of these functions can only be implemented
efficiently using such mechanisms.  When using broadcasts or
multicast messages, a passive observer in the same broadcast/
multicast domain can trivially record these messages and analyze
their content.  Therefore, broadcast/multicast protocol designers
need to take special care when designing their protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-04
https://datatracker.ietf.org/doc/html/draft-ietf-intarea-broadcast-consider-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-03.txt

[Rolf Winter]

Hi,

we updated the draft trying to address comments made by Joe and Tom.

In particular we added a section on types and use of broadcast and 
multicast. This is not an all encompassing summary of it, but highlights 
the types most important for the scope of the document. We did not 
include LANE as suggested, because we felt that this is side-tracking 
the discussion a little. Also, we left out relays for certain protocols, 
as the focus is on the standard broadcast and multicast capabilities of 
the network which proprietary protocols will need to use, as by design, 
there are no relays for these types of protocols.


Joe, could you check, whether the new text properly addresses your 
comments or not?


Thanks,

Rolf

Am 29.05.17 um 09:30 schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item 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: draft-ietf-intarea-broadcast-consider-03.txt
Pages   : 13
Date: 2017-05-29

Abstract:
A number of application-layer protocols make use of IP broadcasts or
multicast messages for functions like local service discovery or name
resolution.  Some of these functions can only be implemented
efficiently using such mechanisms.  When using broadcasts or
multicast messages, a passive observer in the same broadcast/
multicast domain can trivially record these messages and analyze
their content.  Therefore, broadcast/multicast protocol designers
need to take special care when designing their protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-03
https://datatracker.ietf.org/doc/html/draft-ietf-intarea-broadcast-consider-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WGLC for draft-ietf-intarea-broadcast-consider

[Rolf Winter]

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 lack of mention of IPv6 which did its bit for
the planet by eliminating broadcast.



Multicast in many cases is not any better from the perspective of the 
size of the receiver group, which is why this traffic is more sensitive 
to privacy concerns. The document therefore discusses both broadcast and 
multicast. We will update the document, including a section on broadcast 
and multicast properties as suggested by Joe earlier. It should be much 
clearer then.


Thanks,

Rolf



Tom Petch


- Original Message -
From: "Juan Carlos Zuniga" 
To: 
Sent: Monday, March 06, 2017 9:09 PM



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

new

version addresses the pending comments, we believe it is ready for WG

Last

Call.

This email starts an Int-Area WG Last Call on:

https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-02

Please respond to this email to support the document and/or send

comments

by 2017-03-20.

In addition, to satisfy RFC 6702 "Promoting Compliance with

Intellectual

Property Rights (IPR)":
Are you personally aware of any IPR that applies to
draft-ietf-intarea-hostname-practice?
If so, has this IPR been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

Best,

Juan Carlos Zuniga & Wassim Haddad
(Int-Area WG co-chairs)









___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WGLC for draft-ietf-intarea-broadcast-consider

[Rolf Winter]

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 new version addresses the pending comments, we believe it is ready
for WG Last Call.

This email starts an Int-Area WG Last Call on:

https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-02

Please respond to this email to support the document and/or send
comments by 2017-03-20.

In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual
Property Rights (IPR)":
Are you personally aware of any IPR that applies to
draft-ietf-intarea-hostname-practice?
If so, has this IPR been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

Best,

Juan Carlos Zuniga & Wassim Haddad
(Int-Area WG co-chairs)


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-02.txt

[Rolf Winter]

Hi,

we just posted a new version of the document addressing the outstanding 
comments listed below:


- added a reference to RFC 3819 and pointing out the importance of 
broadcast/multicast support in a subnetwork (comment by Joe Touch)


- added a reference to RFC 5374 and respective text in the security 
considerations section (comment by Brian Carpenter)


- added a reference to draft-ietf-dnssd-privacy and corresponding text 
(comment by Tim Chown)


From our viewpoint there is nothing to add at this point in time and we 
would like to request feedback from the group.


Best,

Rolf

Am 2/13/17 um 11:34 AM schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item 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: draft-ietf-intarea-broadcast-consider-02.txt
Pages   : 11
Date: 2017-02-13

Abstract:
   A number of application-layer protocols make use of IP broadcasts or
   multicast messages for functions like local service discovery or name
   resolution.  Some of these functions can only be implemented
   efficiently using such mechanisms.  When using broadcasts or
   multicast messages, a passive observer in the same broadcast/
   multicast domain can trivially record these messages and analyze
   their content.  Therefore, broadcast/multicast protocol designers
   need to take special care when designing their protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Kathleen Moriarty's Yes on draft-ietf-intarea-hostname-practice-04: (with COMMENT)

[Rolf Winter]

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 are obvious privacy gains to changing to randomized hostnames and 
also to change these names frequently. Wide deployment might however 
affect security functions or current practices. For example, incident 
response using hostnames to track the source of traffic might be 
affected.  It is common practice to include hostnames and reverse lookup 
information at various times during an investigation.


Best,

Rolf


Am 2/3/17 um 3:55 AM schrieb kathleen.moriarty.i...@gmail.com:



Please excuse typos, sent from handheld device


On Feb 2, 2017, at 6:47 PM, Christian Huitema  wrote:




On 2/2/2017 8:45 AM, Kathleen Moriarty wrote:

On Thu, Feb 2, 2017 at 12:08 PM, Christian Huitema  wrote:
...
OK. This is the classic tension between privacy and management, and we
can certainly add a statement in the privacy section. Kathleen, do you
prefer something specific to incident response, or should we write
something more generic?

Thanks, Christian.  Something more generic and maybe in the security
section as it's used in a security function to track attackers.

How about saying something like "In managed environments, the hostname
is often used as part of incident response
or other security related functions. Mitigations for the hostname
related privacy
issues will need to consider the effect on these functions" ?


Hmm, I'll have to think about it more as the host names they are typically 
sharing is that of the attacker.  The above reads as if it's the hostname of 
the managed environment that should be considered.

Feel free to tweak to use the language you have in the draft, how about:
Although there are privacy gains to changing randomized hostnames, wide 
deployment will affect security functions like incident response who use 
hostnames to track the source of traffic.  It is common practice to include 
hostnames and reverse lookup information at various times during an 
investigation.

It's more specific than what you were looking to include, but accurate in terms 
of a consideration with this change.

Thank you,
Kathleen


-- Christian Huitema



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt

[Rolf Winter]

Hi,

another thing we will look at for the next revision. Sorry that it 
slipped through.


Best,

Rolf

Am 11/2/16 um 4:26 PM schrieb Joe Touch:

Hi, all,

I thought I mentioned this before, but regardless:

This doc should include a discussion of RFC3819, which explains where
and why broadcast 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 in the document. Thanks
for the hint!

Best,

Rolf

Am 10/31/16 um 8:25 PM schrieb Brian E Carpenter:

Rolf,

I read this draft (the -00 version) recently, since I'm co-author of
draft-ietf-anima-grasp, which relies heavily on link-local multicast.
I did
find it useful, although I didn't in the end change anything as a
result.

Should you mention the MSEC work and RFC 5374 in particular?

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 and Stephane.

Sorry for the confusion.

Best,

Rolf

Am 10/31/16 um 3:05 PM schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item 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: draft-ietf-intarea-broadcast-consider-01.txt
Pages   : 10
Date: 2016-10-31

Abstract:
   A number of application-layer protocols make use of IP
broadcasts or
   multicast messages for functions like local service discovery or
name
   resolution.  Some of these functions can only be implemented
   efficiently using such mechanisms.  When using broadcasts or
   multicast messages, a passive observer in the same broadcast/
   multicast domain can trivially record these messages and analyze
   their content.  Therefore, broadcast/multicast protocol designers
   need to take special care when designing their protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/


There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-01



Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area




___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt

[Rolf Winter]

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 in the document. Thanks for 
the hint!


Best,

Rolf

Am 10/31/16 um 8:25 PM schrieb Brian E Carpenter:

Rolf,

I read this draft (the -00 version) recently, since I'm co-author of
draft-ietf-anima-grasp, which relies heavily on link-local multicast. I did
find it useful, although I didn't in the end change anything as a result.

Should you mention the MSEC work and RFC 5374 in particular?

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 and Stephane.

Sorry for the confusion.

Best,

Rolf

Am 10/31/16 um 3:05 PM schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item 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: draft-ietf-intarea-broadcast-consider-01.txt
Pages   : 10
Date: 2016-10-31

Abstract:
   A number of application-layer protocols make use of IP broadcasts or
   multicast messages for functions like local service discovery or name
   resolution.  Some of these functions can only be implemented
   efficiently using such mechanisms.  When using broadcasts or
   multicast messages, a passive observer in the same broadcast/
   multicast domain can trivially record these messages and analyze
   their content.  Therefore, broadcast/multicast protocol designers
   need to take special care when designing their protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt

[Rolf Winter]

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 and Stephane.


Sorry for the confusion.

Best,

Rolf

Am 10/31/16 um 3:05 PM schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item 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: draft-ietf-intarea-broadcast-consider-01.txt
Pages   : 10
Date: 2016-10-31

Abstract:
   A number of application-layer protocols make use of IP broadcasts or
   multicast messages for functions like local service discovery or name
   resolution.  Some of these functions can only be implemented
   efficiently using such mechanisms.  When using broadcasts or
   multicast messages, a passive observer in the same broadcast/
   multicast domain can trivially record these messages and analyze
   their content.  Therefore, broadcast/multicast protocol designers
   need to take special care when designing their protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] New Version Notification for draft-intarea-broadcast-consider-02

[Rolf Winter]

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 has received during last call. Could commentors please check?

Best,

Rolf

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] New Version Notification for draft-intarea-broadcast-consider-02

[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 has received during last call. Could commentors please check?


Best,

Rolf

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Remarks on draft-winfaa-intarea-broadcast-consider-02

[Rolf Winter]

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 Bortzmeyer:

[I'm not on intarea but I've been told there is a call for adoption
going on; so here are my remarks.]

I've read draft-winfaa-intarea-broadcast-consider-02. I approve it, I
hope it will be published as a RFC, but I have a few remarks.

The lack of actual examples is a problem (Eliot Lear made the same
remark on the list). Referencing the TRAC paper is not enough since,
thanks to IEEE, it is not public. Giving a few examples would be
useful (you can pseudonymize them if you don't want to bash
Dropbox...)


The IEEE allows a copy of the accepted version (not the final version) 
to be posted on a personal and/or institution page. We did this, so for 
all of you that are interested in the findings, you can now download the 
paper and the presentation slides here:


paper:
http://net.hs-augsburg.de/docs/paper_trac_2016.pdf

slides:
http://net.hs-augsburg.de/docs/paper_trac_2016_slides.pdf

The next version will nevertheless contain examples as requested.



For the people who meet this draft and are not familiar with IETF
internals, it would be useful to explain where to discuss it. (Name of
the mailing list, URL, etc)


We have added this as a note into the document.




Broadcast and multicast messages have a large receiver group by
design.


You mention several times "large". This is not the only issue, another
problem is that the receiver group is unknown.


We added this.



You never mention the RFC on privacy, RFC 6973, which is
strange.


Fixed.



The second paragraph of 2.1 "Besides the privacy implications of
frequent broadcasting, it also represents a performance problem"
should be deleted. It is true but unconnected to privacy.


You are right. It is not the core of the document but important 
nevertheless. What we have done is we pulled that text from the main 
body and placed it at the end into a new section called:


"Other considerations"



draft-ietf-dhc-dhcp-privacy has been published, as RFC 7819.



fixed


permanent identifier


RFC 7819 says "stable identifiers". May be using the same terminology
would be better?



We use persistent identifier which also appears in RFC6973. RFC6973 also 
talks about the "persistence" of identifiers. We would stick with that 
term, as the document tries to align with the terminology used in RFC6973.




A lot of applications and services using broadcast protocols do not
include the means to declare "safe" environments (e.g. based on the
SSID of a WiFi network).


I understand the problem but is the example correct? The SSID is not
authentified and proves nothing (see RFC 7593, section 2.1.1).




The SSID is potentially a poor choice of a configuration item but it is 
certainly better than nothing and the easiest choice to come up with. It 
will certainly protect you in cases where you e.g. allow broadcasts in 
your home network, but not in any other with a different SSID, to which 
you likely conciously attach your device to.




___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Call for adoption of draft-winfaa-intarea-broadcast-consider-02

[Rolf Winter]

Hi Eliot,

I though a bit more about what you said. I think the suggestions to 
developers were clear in my mind but maybe aren't all that clearly 
formulated. Here are the most important suggestions that I read from the 
text:


- Use IETF-specified protocols if possible
- Avoid using user-specified information inside broadcast/multicast messages
- Avoid persistent IDs in messages
- If you really must use a broadcast/multicast protocol and cannot use 
an IETF-specified protocol, then:

- Be very conservative in how frequently you send messages
	- Seek advice from IETF-specifies protocols such as message supression 
in mDNS
	- Try to design the protocol in a way that the information cannot be 
correlated with other information in broadcast/multicast messages
	- Let the user configure safe environments if possible (e.g. based on 
the SSID)



The reasoning for the above list is in the text of the document. If we 
spell out the above more clearly and add examples from our experiments, 
would you say the document is ready for adoption? That is something we 
can also do once the document has been adopted as part of the first 
revision.


Best,

Rolf

Am 8/29/16 um 10:13 PM 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 using 6761/6762?


Using a well-known protocols such as mDNS, DNS-SD, LLMNR etc. is only
solving parts of the problem. In our experiments, mDNS - albeit being
a standard - was a big problem concerning privacy as it often
contained PII. Section 2.3. addresses this.


Precisely my point and this is the real crux of the matter.  It would be
VERY helpful if you were able to give some very specific examples of
discovery done wrong and how it would be done right.  It is probably
worth noting that sometimes this is just moving the problem from
"impossible to solve" to "impractical to solve", such as when PII moves
from discovery to an application protocol where the information is sent
in the clear, and that might even make matters worse, because the
distance of the stretch of the connection.  Another approach you might
want to explore is to examine common reasons why identifying information
ends up in discovery messages and what alternatives would prove better.

Now I realize that one draft can't fix everything, but there needs to be
enough advice for the developer to act on, and right now I don't think
there is.






Also, Section 2.5 talks about configurability as if that's a good
thing.  Given the opportunity of the user to make a decision in this
space, he or she is likely to make the wrong one.  We know this from
long experience.  Again what is needed is far more specific
recommendations that do not require user interaction.


I would argue that some things require user configuration. But that
does not necessarily mean editing YAML files or similar which is too
technical for the average user. A good example (to me at least) is how
e.g. Windows asks a user what kind of network an unknown network is
(private, work or public I think are option here). Every user can
answer that and Windows decides how to configure itself based on that
piece of information. That is enough for potentially privacy leaking
protocols where at home a broadcast is supposingly fine, but
broadcasting your identity on the airport network is probably not.
Making a wrong decision here is also better than no decision I would
assume, because many protocols we observed broadcast/multicast
irrespective of the network location today. So the user won't be worse
off compared to today.


I would suggest then that you require more support for your assertion.
If you like I can dig up many papers that go the other way, not to
mention the long sordid history of TLS.





There is probably another avenue of consideration here as well.  It is
probably also helpful to discuss scale.  Use of unique identifiers can
adversely impact scale either within the server implementation or on the
network itself.  There's a hint of this in Section 2.1 re performance
and energy consumption.


An the operational experience on the IETF meeting network. We can add
text here but some of that would be duplications of the referenced
work. But that is fine. On one of the networks where we did our
experiments, there was an average rate of 20kbit/s of broadcast and
multicast traffic. That does not sound like much, but that is average,
including nights and weekends, where there is hardly any traffic.


I think the case Stewart likes to look at is the baseball stadium or the
mall.

Eliot



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Call for adoption of draft-winfaa-intarea-broadcast-consider-02

[Rolf Winter]

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 considerations for discovery
protocols, this document needs to go further than that to be useful to
developers so that they just get it right.  Section 1 talks about how
the document is intended for non-IETF protocols.  I think we need
guidance for both IETF and non-IETF.  As a port reviewer, I want to
encourage developers to use common mechanisms.  In fact I want to be
able to refuse port requests that don't use those common mechanisms
without good reason.  That means that the common mechanisms need to
really do the right thing.  And so when the authors write:


   For one, non-
   standard protocols will likely not receive operational attention and
   support in making them more secure such as e.g.  DHCP snooping does
   for DHCP because they typically are not documented.


That is a very strong argument for use of IETF protocols, and they
should say so (but that last phrase should be made more clear as to what
it means - I had trouble parsing it.).


We can be more clear here. The general principle here is that the 
protocols of the IETF are well-known and their header structure and 
operation are understood, so it is possible to make operational 
provisions in case the network administrator wants to protect the 
privacy of its users or strengthen the security of the network. DHCP 
snooping is an example of this where DHCP packets are not re-broadcast 
over the wireless interface. You can also generally switch off e.g. 
broadcasts but that is not always desirable. We had broadcasts generally 
switched off on the IETF wireless network in Yokohama and Berlin (but 
for performance reasons). With multicast, that is however not as trivial.




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 using 6761/6762?


Using a well-known protocols such as mDNS, DNS-SD, LLMNR etc. is only 
solving parts of the problem. In our experiments, mDNS - albeit being a 
standard - was a big problem concerning privacy as it often contained 
PII. Section 2.3. addresses this.




Also, Section 2.5 talks about configurability as if that's a good
thing.  Given the opportunity of the user to make a decision in this
space, he or she is likely to make the wrong one.  We know this from
long experience.  Again what is needed is far more specific
recommendations that do not require user interaction.


I would argue that some things require user configuration. But that does 
not necessarily mean editing YAML files or similar which is too 
technical for the average user. A good example (to me at least) is how 
e.g. Windows asks a user what kind of network an unknown network is 
(private, work or public I think are option here). Every user can answer 
that and Windows decides how to configure itself based on that piece of 
information. That is enough for potentially privacy leaking protocols 
where at home a broadcast is supposingly fine, but broadcasting your 
identity on the airport network is probably not. Making a wrong decision 
here is also better than no decision I would assume, because many 
protocols we observed broadcast/multicast irrespective of the network 
location today. So the user won't be worse off compared to today.




There is probably another avenue of consideration here as well.  It is
probably also helpful to discuss scale.  Use of unique identifiers can
adversely impact scale either within the server implementation or on the
network itself.  There's a hint of this in Section 2.1 re performance
and energy consumption.


An the operational experience on the IETF meeting network. We can add 
text here but some of that would be duplications of the referenced work. 
But that is fine. On one of the networks where we did our experiments, 
there was an average rate of 20kbit/s of broadcast and multicast 
traffic. That does not sound like much, but that is average, including 
nights and weekends, where there is hardly any traffic.


Best,

Rolf



Regards,

Eliot

On 8/26/16 12:56 AM, Juan Carlos Zuniga wrote:

Dear all,

At the Berlin meeting we got strong support to adopt
draft-winfaa-intarea-broadcast-consider-02 as a WG work item. We are
now confirming the adoption by issuing this call on the ML.

The document has been presented and discussed now for a few meetings
and we believe the contents are highly relevant to the group.

Please indicate your support (or lack thereof) by replying to this
email until September 9.

https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-02

Regards,

Juan Carlos & Wassim


___
Int-area 

Re: [Int-area] I-D Action: draft-ietf-intarea-hostname-practice-03.txt

[Rolf Winter]

Hi,

this version addresses the comments that have come up during the last call.

Best,

Rolf

Am 7/8/16 um 8:17 PM schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Area Working Group 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
Date: 2016-07-08

Abstract:
   Giving a hostname to your computer and publishing it as you roam from
   one network to another is the Internet equivalent of walking around
   with a name tag affixed to your lapel.  This current practice can
   significantly compromise your privacy, and something should change in
   order to mitigate these privacy threads.

   There are several possible remedies, such as fixing a variety of
   protocols or avoiding disclosing a hostname at all.  This document
   describes some of the protocols that reveal hostnames today and
   sketches another possible remedy, which is to replace static
   hostnames by frequently changing randomized values.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-hostname-practice/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-intarea-hostname-practice-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-hostname-practice-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-hostname-practice-02.txt

[Rolf Winter]

Hi,

this version contains a clarification regarding the potential for 
correlation in case host names change for privacy reasons (i.e. even if 
the host name changes but tokens such as MAC and IP address remain 
constant, then the host name change is pointless, because based on e.g. 
the MAC address, the host can still be identified and a connection 
between the old and new host name can be made).


The question now is, is there anything the WG feels should be added or 
changed? Or is the document ready.


Best,

Rolf

Am 5/11/16 um 4:14 PM schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Area Working Group of the IETF.

Title   : Current Hostname Practice Considered Harmful
Authors : Christian Huitema
  Dave Thaler
  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 equivalent of walking around
   with a name tag affixed to your lapel.  This current practice can
   significantly compromise your privacy, and something should change in
   order to mitigate these privacy threads.

   There are several possible remedies, such as fixing a variety of
   protocols or avoiding disclosing a hostname at all.  This document
   describes some of the protocols that reveal hostnames today and
   sketches another possible remedy, which is to replace static
   hostnames by frequently changing randomized values.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-hostname-practice/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-intarea-hostname-practice-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-hostname-practice-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] IP broadcast and multicast protocol considerations

[Rolf Winter]

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 to achieve that, by
opposition to specific drafts covering specific broadcast protocols.


If I look at protocols covered by INT Area, there are 5 big targets: DHCP and

DHCPv6, ARP and IPv6 Neighbor Discovery, and MDNS. DHCP and DHCPv6
are arguably already covered by the privacy work in the DHCP working
group. Maybe we should start by an analysis of the other 3 protocols? Or do
you have other similar protocols in mind?




DHCP is well covered, I agree. MDNS was one of the main "offenders" in our
experiments but that links strongly to your hostnames document.


Actually, MDNS would probably benefit from an in depth analysis. There is one obvious 
issue, broadcasting host names, but there may be more. The MDNS design largely assumes UI 
interaction, in which the user sees what is out there and makes an explicit decision to 
connect to it or not. But there are usage patterns in which a software agent sends a 
request over the network and then "automatically connects" if it find 
something, and those patterns are an accidient waiting to happen.



I would agree.



The not
covered "offenders" are often not IETF-specified potocols. I give you one
example. The DropBox LanSync protocol used by the DropBox desktop
client. Messages contain an identifier that identifies the installation of the
application. It broadcasts very frequently. Now with all the pricacy work in
the IEEE and IETF and other places, here is a protocol that, with a relatively
high frequency, broadcasts a persistent stable identifier. When e.g. your
MAC address changes (for privacy reasons e.g.), the LanSync protocol allows
you to easily recognize that you just changed your MAC address and all that
trouble changing the MAC address was useless.


Obviously, your draft is based on experience and measurements in your lab. But you only write up 
your conclusions. It would be very nice if you could describe what you observed. OK, you may not 
want to name and shame a particular company. Maybe you can just anonymize, e.g. mention 
"Company X" or "Game Y."



That makes sense. It is not really shaming because often in isolation, 
these protocols are "harmless". Only when you start correlating the 
information from a number of protocols, these things leak a lot of 
information. In experiments with students that gave us their consent to 
look at the broadcast/multicast data in the clear (and only that data), 
we could easily find out names of people in the room, if they share data 
and with whom (often also identified by name) and a bunch of other 
intereting things about individuals on the network (things like 
nicknames). Just from looking at broadcast/multicast data.




Did you interact with the developers of these products? Do you know what they 
were trying to achieve with their design? Ideally, we should be able to point 
them to a standard and safe alternative. Your draft could document for each 
example the problematic design, the privacy or security issues, and the 
recommended alternative. The IETF would be very much in its role when doing 
that.



Not yet, no. We know what they are trying to achieve and it is generally 
things that make a lot of sense. But users are generally not aware of 
the things these protocols do and how often and where they do it.



There is a lot of effort all
over the place (IETF and other SDOs) to make protocols better regarding the
protection of privacy but there are deployed protocols that make many of
these efforts useless if these practices prevail. There are other things we
have observed today which can reveal interesting things with a little more
effort. I think there is good (generic) advice the IETF can give to protocol
designers (in particular outside the IETF).


Yes, but presenting it as "case studies" could be more convincing.



I guess you are right. From the discussion so far it seems we didn't get 
our point across very well.



We can have a look at ND and ARP
and what not, but the professional protocol engineers at the IETF are not the
main target for such a document. We already have
RFC6973 and RFC7258 that talk about privacy and I believe the IETF
community has already a good sense of privacy implications of protocol
choices, but the people outside the IETF building broadcast/multicast
protocols might not. It really means telling people what they break when the
do certain things.


No question there. But we also need to tell them how to achieve the result they 
want without breakage...


Right. Some of that is (probably hidden) in the text such as declaring a 
"safe" environment (something that is somewhat built into

Re: [Int-area] IP broadcast and multicast protocol considerations

[Rolf Winter]

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) apps, not IETF 
protocols, and we believe guidance to these protocol designers would be 
valuable. E.g. some of the protocols we see today would completely break 
the efforts on MAC address randomization.


You mentioned DHCP. There is 
https://tools.ietf.org/html/draft-ietf-dhc-dhcp-privacy-03 and 
https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-03. ARP is 
not terribly interesting compared to the other things we have observed 
but we can include any of the protocols you suggest. In the next version 
of the document we will add a section of ongoing work such as MAC 
address randomization and the work on DHCP mentioned above but I would 
prefer not to duplicate that effort but rather reference it.


Best,

Rolf

Am 1/25/16 um 10:23 PM schrieb Joe Touch:

This doc *ignores* dominant uses of multicast and broadcast today (e.g.,
ARP, DAD, IPv6 autoconfiguration, DHCP, etc.).

You should also review "Advice for Internet Subnetwork Designers", RFC
3819, 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 in Yokohama in a
1 minute pitch during the chairs presentation. This also relates to the
experiment that was done on the IETF network during the last meeting as
well.

This work addresses privacy problems with current broadcast and
multicast protocols (many of which are implemented by popular
applications). In other words, this work addresses issues that can be
frequently observed today.

Previous versions of the document can be found here:

https://tools.ietf.org/html/draft-winfaa-broadcast-consider

We are happy to receive feedback on the document and discuss its content.

Best,

Rolf

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] IP broadcast and multicast protocol considerations

[Rolf Winter]

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) apps, not IETF
protocols, and we believe guidance to these protocol designers would be
valuable. E.g. some of the protocols we see today would completely break
the efforts on MAC address randomization.


You're looking under the lamppost of privacy. You need to consider that
there are plenty of protocols for which your recommendations are both
incorrect and inappropriate.


Sure, that's why they are considerations. One should think about these 
things when designing a new protocol. If they do not apply, that is fine.





You mentioned DHCP. There is
https://tools.ietf.org/html/draft-ietf-dhc-dhcp-privacy-03 and
https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-03. ARP is
not terribly interesting compared to the other things we have observed
but we can include any of the protocols you suggest. In the next version
of the document we will add a section of ongoing work such as MAC
address randomization and the work on DHCP mentioned above but I would
prefer not to duplicate that effort but rather reference it.


The entirety of your document needs to be limited to use cases where
privacy is both desired and appropriate - including the title.


I think I agree with you. The title probably needs adjustment to reflect 
that privacy is the focus of the document.



That
includes a survey of *widely deployed and critical* IETF protocols that
already rely on broadcast and multicast snooping for correct behavior.


OK.

Rolf



Joe


Best,

Rolf

Am 1/25/16 um 10:23 PM schrieb Joe Touch:

This doc *ignores* dominant uses of multicast and broadcast today (e.g.,
ARP, DAD, IPv6 autoconfiguration, DHCP, etc.).

You should also review "Advice for Internet Subnetwork Designers", RFC
3819, 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 in Yokohama in a
1 minute pitch during the chairs presentation. This also relates to the
experiment that was done on the IETF network during the last meeting as
well.

This work addresses privacy problems with current broadcast and
multicast protocols (many of which are implemented by popular
applications). In other words, this work addresses issues that can be
frequently observed today.

Previous versions of the document can be found here:

https://tools.ietf.org/html/draft-winfaa-broadcast-consider

We are happy to receive feedback on the document and discuss its
content.

Best,

Rolf

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] IP broadcast and multicast protocol considerations

[Rolf Winter]

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/message frequency and b) content that gives
away privacy relevant information. Some of these are (popular) apps,
not IETF protocols, and we believe guidance to these protocol
designers would be valuable. E.g. some of the protocols we see today
would completely break the efforts on MAC address randomization.


You're looking under the lamppost of privacy. You need to consider
that there are plenty of protocols for which your recommendations are
both incorrect and inappropriate.


Sure, that's why they are considerations. One should think about these
things when designing a new protocol. If they do not apply, that is fine.


Rolf, I appreciate that you are trying to improve network privacy, but I wonder 
whether a generic abstract draft is the best way to achieve that, by opposition 
to specific drafts covering specific broadcast protocols.

If I look at protocols covered by INT Area, there are 5 big targets: DHCP and 
DHCPv6, ARP and IPv6 Neighbor Discovery, and MDNS. DHCP and DHCPv6 are arguably 
already covered by the privacy work in the DHCP working group. Maybe we should 
start by an analysis of the other 3 protocols? Or do you have other similar 
protocols in mind?



DHCP is well covered, I agree. MDNS was one of the main "offenders" in 
our experiments but that links strongly to your hostnames document. The 
not covered "offenders" are often not IETF-specified potocols. I give 
you one example. The DropBox LanSync protocol used by the DropBox 
desktop client. Messages contain an identifier that identifies the 
installation of the application. It broadcasts very frequently. Now with 
all the pricacy work in the IEEE and IETF and other places, here is a 
protocol that, with a relatively high frequency, broadcasts a persistent 
stable identifier. When e.g. your MAC address changes (for privacy 
reasons e.g.), the LanSync protocol allows you to easily recognize that 
you just changed your MAC address and all that trouble changing the MAC 
address was useless. There is a lot of effort all over the place (IETF 
and other SDOs) to make protocols better regarding the protection of 
privacy but there are deployed protocols that make many of these efforts 
useless if these practices prevail. There are other things we have 
observed today which can reveal interesting things with a little more 
effort. I think there is good (generic) advice the IETF can give to 
protocol designers (in particular outside the IETF). We can have a look 
at ND and ARP and what not, but the professional protocol engineers at 
the IETF are not the main target for such a document. We already have 
RFC6973 and RFC7258 that talk about privacy and I believe the IETF 
community has already a good sense of privacy implications of protocol 
choices, but the people outside the IETF building broadcast/multicast 
protocols might not. It really means telling people what they break when 
the do certain things.



-- Christian Huitema







___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] IP broadcast and multicast protocol considerations

[Rolf Winter]

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 presentation. This also relates to the 
experiment that was done on the IETF network during the last meeting as 
well.


This work addresses privacy problems with current broadcast and 
multicast protocols (many of which are implemented by popular 
applications). In other words, this work addresses issues that can be 
frequently observed today.


Previous versions of the document can be found here:

https://tools.ietf.org/html/draft-winfaa-broadcast-consider

We are happy to receive feedback on the document and discuss its content.

Best,

Rolf

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area