Re: [Int-area] Call for adoption of draft-winfaa-intarea-broadcast-consider-02
Hello, After seeing continuous interest in this document we are hereby confirming the adoption of the document in the WG. We would like to request the authors to submit a WG version and address the received comments, so that we can continue the discussion on the ML and at the upcoming IETF meeting. Best, Juan Carlos & Wassim On Thu, Aug 25, 2016 at 6:56 PM, Juan Carlos Zunigawrote: > 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 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, September 2, 2016 7:05 AM, Eliot Lear wrote: > To: Rolf Winter; int-area@ietf.org > ... > This. Get some good examples. I haven't reviewed your experimental results, > but following a few common discovery mechanisms that both do and do not get > it > right would be useful. I would be particularly interested in situations > where the > end goal is entirely understandable, but the method used is just leaky. I > would > expect that in some cases, there may not be alternatives, and in some cases > there > may be, depending on the use of the information. Classing those cases and > providing > quite specific recommendations would be very useful. Yes. And I think Rolf's draft is a good start in that direction. I support adoption as a WG item. And I will be happy to review and help improve... - -- Christian Huitema -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using gpg4o v3.5.53.6558 - http://www.gpg4o.com/ Charset: utf-8 iQEcBAEBAgAGBQJXyeJ4AAoJELba05IUOHVQoSYH/A85BKrhx3JJLUEUhnlJc5eY THACv2nCfkDqt2iQlCKCCVonP0FqWKNS27D2ALF4ZZiKV7l563JP9VGQxIBmX8TW STX13mwvUS6WvExm2tokASLxRm7M7KwtGkSf6yCEOIYMaSkvgrAcQyohP8BD7YO7 k1VL4P5anDJBPYFghLw9gg2i/JDGP+14zIfbxdTv5yNt8YB8dnHyZpBk4LadM+gv XQbq1nneOM3H+0+Z0aY3q4/cc3XYJrfLVBUNF6zb+ruOSmnJOpNiFRpmLUBEnUme v2pMuAkchSlDWXW0sPuMzX9JEB/YbdkGReeCWpmHgbhscJg/ozsHQ5+yCszvnGk= =Ys/0 -END PGP SIGNATURE- ___ 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
Hi Rolf, On 9/2/16 2:38 PM, Rolf Winter wrote: > 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. I do like the above recommendations called out in one place. That's a very nice summary. If it were just a matter of clarity, I wouldn't be concerned about adoption, because you can fix that in the WG process. What I'm hoping for is a bit more texture to this. And so: > If we spell out the above more clearly*and add examples from our > experiments, w*ould 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. This. Get some good examples. I haven't reviewed your experimental results, but following a few common discovery mechanisms that both do and do not get it right would be useful. I would be particularly interested in situations where the end goal is entirely understandable, but the method used is just leaky. I would expect that in some cases, there may not be alternatives, and in some cases there may be, depending on the use of the information. Classing those cases and providing quite specific recommendations would be very useful. Eliot signature.asc Description: OpenPGP digital signature ___ 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
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, 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 signature.asc Description: OpenPGP digital signature ___ 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
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] Call for adoption of draft-winfaa-intarea-broadcast-consider-02
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.). 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? 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. 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. 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 mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area signature.asc Description: OpenPGP digital signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area