Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04
Thanks Lars. That's what I thought; I just wanted to be sure that I hadn't missed something by joining the discussion a bit later than others. I would be interested in hearing more broadly from the list on the subject of whether RFC6967 justifies further int-area work on host identification. I'm not asking about any specific solution candidate, but rather whether the solution set as a whole shows enough promise. The authors of the scenarios draft think that RFC6967 justifies the continued work effort, but Lars and some others do not. I'd like to get some sense of which direction consensus is leaning in that regard. Of course, if people have the sense that this isn't a useful line of inquiry, I'm receptive to that feedback too. Thanks, --Brandon On 07/31/2014 03:45 PM, Eggert, Lars wrote: Hi Brandon, On 2014-7-31, at 21:14, Brandon Williams brandon.willi...@akamai.com wrote: Has your read of RFC6967 been presented as the general int-area consensus in past discussions about the RFC? Or would there be some value in probing the list a bit more on the topic? my takeaway from the RFC as certainly has not been confirmed as the consensus of the WG, and I did't mean to imply so. Establishing any consensus would be up to the chairs. Lars -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
I agree entirely that defining host identification as a problem indicates that the authors believe a solution is called for. I also agree that the privacy impact of solution candidates must be discussed, including making a concerted effort to mitigate the possibility of those solution candidates being used for pervasive monitoring purposes. My point is simply that this draft is not intended to propose solutions or discuss solution candidates. RFC6967, which as you note is repeatedly cited, discusses solution candidates and lays out a framework for privacy discussion related to solution proposals. Future RFCs that actually propose solutions are already expected to follow the guidance from RFC6967, and the references to that RFC in this draft are meant to point to RFC6967 as the authoritative guidance. Is there some reason why you do not consider it adequate for this use cases draft to reference the existing and already published potential solutions analysis rfc? What specific content related to privacy and/or pervasive monitoring belongs in this draft that is not already present in RFC6967? Thanks, --Brandon On 06/09/2014 01:16 PM, joel jaeggli wrote: On 6/9/14, 7:01 AM, Stephen Farrell wrote: On 09/06/14 14:46, Brandon Williams wrote: Would you please indicate where the draft proposes a new identifier? If you are seeing a proposal for protocol changes somewhere in the draft, editing work is required in order to either clarify or excise the associated text. There are 6 citations of http://tools.ietf.org/html/rfc6967 the document doesn't exist in a vacuum where somehow how to do it has fallen off the table. given the repeated asertion that this work is useful because of external requests (etsi) and that request is in fact tied closely to a particular method it is relatively strait forward to conflate the discussion of scenarios and methods. Fair enough that its an assumption of mine that adding some kind of identifier is required to meet the (no-longer mis-stated:-) requirements for these use-cases. But I think that is logically required, and its valid to draw obvious conclusions and its also invalid to ignore obvious conclusions. S. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
I agree that the discussions in this draft and rfc6269 at least imply that potential solutions would provide a host identifier of some sort. However, this draft does not in fact propose any such solution, and instead clearly references rfc6967, which includes a discussion of the privacy implications of host identification. In particular, that document states: HOST_ID specification document(s) should explain the privacy impact of the solutions they specify, including the extent of HOST_ID uniqueness and persistence, assumptions made about the lifetime of the HOST_ID, whether and how the HOST_ID can be obfuscated or recycled, whether location information can be exposed, and the impact of the use of the HOST_ID on device or implementation fingerprinting. [IAB-PRIVACY] provides further guidance. Considering the fact that there is already a separate solution analysis rfc that discusses privacy considerations and provides the above guidance for authors of solution drafts, what are you suggesting for the use cases draft? Thanks, --Brandon On 06/09/2014 10:01 AM, Stephen Farrell wrote: On 09/06/14 14:46, Brandon Williams wrote: Would you please indicate where the draft proposes a new identifier? If you are seeing a proposal for protocol changes somewhere in the draft, editing work is required in order to either clarify or excise the associated text. Fair enough that its an assumption of mine that adding some kind of identifier is required to meet the (no-longer mis-stated:-) requirements for these use-cases. But I think that is logically required, and its valid to draw obvious conclusions and its also invalid to ignore obvious conclusions. S. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc
will transparently add and remove TCP options. This is kind of dangerous from an end-to-end perspective... Sorry if that has been answered before, but I really wonder what to do if OVRLY_IN can't add this option, either because of lack of TCP option space, or because the path MTU is exceeded by the resulting IP packet. (In fact, I think that this problem does not apply to TCP options only.) Unless I miss something, the latter case could become much more relevant soon: TCPM currently works on the fast-open scheme that adds data to SYNs. With that, I think it is possible that all data packets from a sender to a receiver are either full sized or large enough that the proposed option does not fit in. Given that this option can include full-sized IPv6 addresses, this likelihood is much larger than for other existing TCP option, right? In some cases, I believe that the proposed TCP option cannot be added in the overlay without either IP fragmentation, which is unlikely to be a good idea with NATs, or TCP segment splitting, which probably can cause harm as well. For instance, what would OVRLY_IN do if it receives an IP packet with a TCP SYN segment that already sums up to 1500 byte? And, to make the scenario more nasty, if the same applies to the first data segments as well? Thanks Michael -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] draft-williams-overlaypath-ip-tcp-rfc
Dear all, A new version of this draft has been submitted that attempts to lay out a more clear argument for the use of both TCP and IP options, with references to other efforts in the same arena. Comments are welcome. Cheers, --Brandon Original Message Subject: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-03.txt Date: Thu, 20 Dec 2012 11:55:33 -0500 From: internet-dra...@ietf.org internet-dra...@ietf.org To: Williams, Brandon bow...@akamai.com A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-03.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Filename:draft-williams-overlaypath-ip-tcp-rfc Revision:03 Title: Overlay Path Option for IP and TCP Creation date: 2012-12-20 WG ID: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tcp-rfc-03.txt Status: http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp-rfc Htmlized: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-overlaypath-ip-tcp-rfc-03 Abstract: Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines. The IETF Secretariat ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc
Hi Wes, Thanks for your comments. It looks like I might have managed to make the use of the proposed option less clear, instead of more clear. Or maybe I'm misunderstanding the point that you're making. The mechanics of our system are tunnel-based, as with most overlay architectures that I've looked at. The tunneling starts at an overlay ingress machine close to one of the endpoints (i.e. the client or server) and ends at an overlay egress machine close to the other endpoint. Since the ingress and egress are on the public internet, the overlay does not extend all the way onto the endpoints' LANs. This means that standard internet routing cannot be used to drive the connections into the overlay. Instead, NAT is used on both sides of the overlay, which results in the server having no way to reliably identify the client. The proposed options are not intended to be used as part of the mechanics of the overlay. The overlay is fully functional without the options. Instead, the options are intended to provide the client's connection identifying information to the server for use in load-balancing, diagnostics, etc. Does this clarify things? further muddy the waters? or simply indicate that I missed your point? --Brandon PS: Thanks for cross-posting your comments. I should have done that to begin with. I primarily posted to TCPM for informational purposes, since the TCPM has not shown much interest in this or similar drafts in the past. The INTAREA list has been more actively engaged in discussion related to client identification. Still, if I was going to cross-post, I should have done it with a single thread. On 12/20/2012 02:16 PM, Wesley Eddy wrote: On 12/20/2012 12:21 PM, Brandon Williams wrote: Dear all, A new version of this draft has been submitted that attempts to lay out a more clear argument for the use of both TCP and IP options, with references to other efforts in the same arena. Comments are welcome. (note, I've cross-posted to INTAREA and TCPM, since similar announcements went to each list) Hi Brandon, *many* thanks for writing this; it does help me (at least) to understand what you're doing with this option. As I now understand it, instead of a tunneling approach that would normally be applied for building overlay networks, this approach pushes and pops IP addresses from the protocol options fields. Can you discuss why normal tunneling protocols aren't used to build the overlay? Since those are easily and widely available, I wonder why they aren't used and why something more elaborate, fragile, and not as compatible with the Internet architecture is really needed or felt to be a good idea? I understand that it basically *works* ... but just am not seeing how it makes sense? -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc
On 12/20/2012 04:04 PM, Wesley Eddy wrote: On 12/20/2012 3:49 PM, Brandon Williams wrote: Hi Wes, Thanks for your comments. It looks like I might have managed to make the use of the proposed option less clear, instead of more clear. Or maybe I'm misunderstanding the point that you're making. The mechanics of our system are tunnel-based, as with most overlay architectures that I've looked at. The tunneling starts at an overlay ingress machine close to one of the endpoints (i.e. the client or server) and ends at an overlay egress machine close to the other endpoint. Since the ingress and egress are on the public internet, the overlay does not extend all the way onto the endpoints' LANs. This means that standard internet routing cannot be used to drive the connections into the overlay. Instead, NAT is used on both sides of the overlay, which results in the server having no way to reliably identify the client. The proposed options are not intended to be used as part of the mechanics of the overlay. The overlay is fully functional without the options. Instead, the options are intended to provide the client's connection identifying information to the server for use in load-balancing, diagnostics, etc. Ah, so are there additional devices beyond what's shown in your Figure 1? I ask because if the overlay ingress and egress are simple tunnel endpoints, then the endpoint addresses would be totally visible to one another. Yes. There are additional devices between the HOST and OVRLY_IN, and also between OVRLY_OUT and SERVER, but those devices are just the internet's standard routing infrastructure. There are also potential intermediate devices between OVRLY_IN and OVRLY_OUT that can be used for optimized routing between the overlay's ingress and egress. Your figure 1 is: ++ || | INTERNET | || +---+ | ++| | HOST_1 |-| OVRLY_IN_1 |---+| +---+ | ++ || | || +---+ | ++ +---+ | ++ | HOST_2 |-| OVRLY_IN_2 |-| OVRLY_OUT |-| SERVER | +---+ | ++ +---+ | ++ | || +---+ | ++ || | HOST_3 |-| OVRLY_IN_3 |---+| +---+ | ++| || ++ Figure 1 If there were tunnels between the OVRLY_IN and OVERLY_OUT boxes, then the inner IP headers would have the HOST_X and SERVER addresses, and the outer ones in the tunnel would have the overlay headers. Since the inner packets would be delivered ultimately after egressing the tunnels, the HOST_X addresses are totally visible to the server, and vice versa. There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and the inner IP headers will typically use either the client-side addresses or the server-side addresses. However, neither OVRLY_IN nor OVRLY_OUT can be assumed to be reliably in-path between HOST and SERVER, which means that internet routing cannot be relied upon to cause packets to arrive at the overlay ingress. Instead, HOST_1 must directly address OVRLY_IN_1 in order to send its packets into the tunnel, and SERVER must directly address OVRLY_OUT in order to send the return traffic into the tunnel. Your document shows instead: - ip hdr contains: ip hdr contains: SENDER - src = sender -- OVERLAY -- src = overlay2 -- RECEIVER dst = overlay1 dst = receiver - So, this is not really showing tunnels to me ... this is rewriting (NAT) of the destination address. As noted above, the use of tunnels and NAT in this case are not mutually exclusive. NAT is used to allow the overlay ingress to intercept packets, which are then tunneled to the overlay egress, where NAT is used to deliver the packets to the receiver and ensure that return traffic also uses the overlay. --Brandon PS: Sorry to double send this to you Wes. It was bounced by the ietf lists the first time. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
