Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP
Jari, But back to the proposal. In particular, I would like to know how people feel about this work being ready for an (Experimental) IETF WG, what the scope should be, whether the charter is reasonable. And if not, what would make it so. There are reasonably stable specs that people can code to, there is code, there is a running network, there is a community of interest (myself included), and there are some interesting questions to answer still (like liveness and EID/locator update) that are ripe community involvement. So yes, I think it would be useful to provide a forum for the community to discuss and evolve this work. Eliot ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP
So the question - that is not administrative - boils down imho to: can we exclusively concentrate on the LISP protocol(s) specifics leaving the issue of our confidence on the Loc/ID split and associated challenges open. That question deserves imho a specific discussion that should happen in the context of a BoF. I missed the part where anyone said that we should *exclusively* concentrate on LISP. Where/when did that happen? ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP
On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote: All items in the charter - see below - are exclusively oriented toward LISP protocols implementation specifics, and interworking: Right. This is a LISP WG. There is nothing stopping anyone from creating another WG, assuming the work warrants it. And again, the output is experimental docs. No standardization choices are being made. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [lisp] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for LISP
On 1/22/09 12:48 AM, PAPADIMITRIOU Dimitri wrote: Your question is: does one size (of approach) fits all and the answer is no. Indeed, these situations can not be compared (SHIM6 is a WG whereas HIP is a WG and a RG) but none did intend to address the Internet routing system scalability. It's not entirely so. The routing system was clearly in peoples' minds when HIP was in its early stages. Bob Moskowitz was involved in the Name Space Research Group (NSRG) back when it existed, and as a co-chair of that group I was asked to comment on the chartering on both HIP groups. The NSRG looked at HIP in the light of route scalability. This was one reason that Mike O'Dell (author of 8+8) was interested. Was there was any alternative propose to HIP at the host level as a layer 3.5 mechanism? That is really where SHIM6 comes in, which as I recall was an outgrowth of MULTI6 and Tony Li's early proposal on NOID. Bob Braden, John Wrocklawski (?), et al argued at one point (and I'm sorry I don't have the cite) that we have all the names we need in the IP stack. Both NOID and SHIM6 were, at least in part, evolutions on that notion, and a nameless (stack-wise) alternative to HIP. And so while I agree with your high level point that one size does not fit all, I would say that the policy here as I understand it from Jari is simply that he will not favor one proposal over another and he will not short circuit the RRG process, while at the same time he will provide a venue for work where there is sufficient interest to mature the specifications through community involvement. Eliot ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Starting some discussion on renumbering
Brian, I am interested in participating in discussions, on or off list ;-) One comment now: On 11/11/10 8:55 AM, Brian E Carpenter wrote: - Should we focus entirely on IPv6? That is probably easier in several ways (new deployment for most sites, not constrained by a shortage of prefixes) While of course we should focus entirely on IPv6, I would not want to overstate the value of the size of address space, for the following reasons: * Large portions of network devices still require (re)configuration. * While aspects of DHCP have evolved in IPv6, their use (a'la Prefix Delegation) has to date not been well deployed (yet). * One reason is that there is a perceived trade-off between stability and the use of signaling mechanisms. This has been reinforced by some operator behavior, where they sell static stable address space at a different rate than dynamic space. * Interaction between the DNS/and the other L3 components really hasn't really evolved at all since RFC 4192, particularly on the inter-domain front. I would propose that this be the subject of discussions LONG before a BoF proposal. This is not to say that there isn't any improvement at all. Having a larger block provides for an opportunity to simplify certain aspects of renumbering, especially when the lower-64 are reserved for hosts. This too has not changed since 4192. Eliot - We need a gap analysis. Is the gap analysis in RFC 5887 sufficient? - In any case we should focus on what is doable, and put other problems on the too hard pile. If you are interested in contributing to some work in this area, please let me know (off-list is fine). If there is enough interest, we can set up an ad hoc mailing list and decide on the next steps. Remember that the cut-off for BOF requests for IETF 80 will be somewhere round the end of January. Not much time... ___ 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
Hi Stephen, On 6/7/14, 3:20 PM, Stephen Farrell wrote: I'm frankly amazed that that's not crystal clear to anyone who has read all 2.5 non-boilerplate pages of the BCP. Or even just the last two words of the 1-line abstract (hint: those say where possible.) Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Adding new identifiers with privacy impact, as proposed here, is quite different. This came up today in a discussion around spam and cybersecurity with at least one major service provider who has some pretty sophisticated cbyersecurity systems. Someone mentioned CGN and how entire groups of customers are blocked when a single IP address goes bad. We even experienced this on the IAB, by the way, when its MSP got blocked by an anti-spam site due to presumably someone else misusing them. Our architecture isn't really set up for IP address sharing or hiding. If your source address is naughty, the only back pressure I have at my disposal is to block it. If enough in an address range are bad, I might block a range, even if that means some small amount of good mail being blocked. Go to a lousy SP and this is what it gets you. But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I *might* do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. Eliot ___ 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
Just to be clear: that was SMTP. The calculus can be different for other protocols, depending on their end to end nature. SMTP is very hop by hop and it is very difficult to secure an entire path with confidence due to downgrade attack threats. https would be a horse of a different color. On 6/9/14, 10:10 PM, Brian E Carpenter wrote: On 10/06/2014 04:43, Ted Lemon wrote: On Jun 9, 2014, at 12:32 PM, Eliot Lear l...@cisco.com wrote: But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I might do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. Bingo. So, there are some more components of the threat analysis and the solution requirements. That's good, but I thought we were discussing whether to document the use cases. Brian ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] various approaches to dns channel secrecy
Paul, This seems like a fine and modular approach that doesn't boil the ocean. Eliot On 7/5/14, 5:04 AM, Paul Vixie wrote: i've now seen a number of proposals reaction to the snowden disclosures, seeking channel encryption for dns transactions. i have some thoughts on the matter which are not in response to any specific proposal, but rather, to the problem statement and the context of any solution. first, dns data itself is public -- the data is there for anybody to query for it, if you know what to query for. only the question, questioner, and time can be kept secret. answers are only worth keeping secret because they identify the question, questioner, and time. second, dns transactions are not secret to protocol agents. whether stub resolver, full resolver, forwarder, proxy, or authority server -- the full identity of the question must be knowable to the agent in order to properly process that question. if the agent does logging, then the question, questioner, and time will be stored and potentially shared or analyzed. by implication, then, the remainder of possible problem statement material is hide question from on-wire surveillance, there being no way to hide the questioner or the time. to further narrow this, the prospective on-wire surveillance has to be from third parties who are not also operators of on-path dns protocol agents, because any second party could be using on-wire surveillance as part of their logging solution, and by (2) above there is no way to hide from them. so we're left with hide question from on-wire surveillance by third parties. this is extremely narrow but i can envision activists and dissidents who rightly fear for their safety based on this narrowly defined threat, so i'm ready to agree that there should be some method in DNS of providing this secrecy. and as we know from the history of secrecy, if you only encrypt the things you care about, then they stand out. therefore, secrecy of this kind must become ubiquitous. datagram level channel secrecy (for example, DTLS or IPSEC) offers a solution which matches the existing datagram level UDP transport used primarily by DNS. however, the all-pervasive middleboxes (small plastic CPE devices installed by the hundreds of millions by DSL and Cable and other providers) have been shown to be more powerful than IPv6, DNSSEC, and EDNS -- we could expect them to prevent any new datagram level channel secrecy protocol we might otherwise wish to employ. TCP/53 is less prone to middlebox data inspection, and may seem to be an attractive solution here. i think not for two reasons. first, TCP/53 is often blocked outright, and second, because TCP/53 as defined in RFC 1035 has a connection management scheme that prohibits persistent TCP/53 connections at Internet scale, and we cannot afford the setup/teardown costs of a non-persistent TCP-based channel secrecy protocol for DNS. to those who suggest redefining TCP/53 and upgrading the entire physical plant and all software and operating systems, i challenge you to first show how this is less global effort than other proposals now on the table, and then show how you would handle the long-tail problem, since many agents will never be upgraded, or will only be upgraded on a scale of half-decades. DNS works today because TCP/53 is a fallback for UDP/53. its definition and deployment makes it unsuitable either currently or as-would-be upgraded to become the primary transport. i suggest that any channel secrecy protocol we wish to add to the DNS system must be suitable as the primary transport, to which the existing UDP/53 and TCP/53 protocols are fallbacks. i further suggest that any new transport be operable at internet scale, which demands connection persistence. finally i suggest that this be done using a protocol that the internet's middle boxes (cheap CPE devices who think they know what all valid traffic must look like) will allow to pass without comment. one candidate for this would be RESTful JSON carried over HTTPS. because of its extensive use in e-commerce and web API applications, HTTPS works everywhere. because HTTPS currently depends on X.509 keys, other groups in the IETF world are already working to make HTTPS proof against on-path surveillance. (google for perfect forward secrecy to learn more), and others are working to defend the internet user population against wildcard or targeted SSL certificates issued by governments and other anti-secrecy agents with on-path capabilities. stephane bortzmeyer has already shown us that JSON representation of DNS transactions is possible. i have heard from another protocol engineer who is also working in this area (and who credits bortzmeyer for informing his work). the special advantage of TCP/443 as a primary transport for persistent DNS with channel secrecy is that HTTPS's connection management permits massive scale, as in, a single protocol agent with tens
Re: [Int-area] various approaches to dns channel secrecy
Hi Hannes, On 7/7/14, 8:23 AM, Hannes Tschofenig wrote: Just a minor note on this paragraph: On 07/07/2014 06:48 AM, Eliot Lear wrote: because HTTPS currently depends on X.509 keys, other I didn't write the above, Paul did. But to your point below... groups in the IETF world are already working to make HTTPS proof against on-path surveillance. (google for perfect forward secrecy to learn more), and others are working to defend the internet user population against wildcard or targeted SSL certificates issued by governments and other anti-secrecy agents with on-path capabilities. TLS has this ciphersuite concept and allows you to more than just X.509 certificates. As such, you have more freedom than you think (if you know what you want). Yes. This is something you might know something about ;-) It would be funny if the precondition using using DANE would be to require a PKI as currently used on the Web... Unless what you're using ISN'T a PKI. Any DNS mechanism must be free and clear of dependency loops. While that may be theoretically possible with a PKI, I'd hazard a guess (perhaps worth a drink at a bar) that the number of dependencies explodes, making such a loop more likely in an operational environment. Eliot ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] various approaches to dns channel secrecy
On 7/7/14, 1:14 PM, Hannes Tschofenig wrote: I also struggle to see the significant improvement for the cases that had been discussed on the list. I would say that they go close to zero when one uses DNS servers provided by the local network operator. That's a matter of service selection and orthogonal to Paul's proposal. 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
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
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
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
Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt
Hi Rolf, I apologize. I had entirely forgotten about this draft. I've put out very much a -00 of my own draft-lear-network-helps-01.txt. The key point of my draft, to expropriate from Ecclesiastes, is simply this: there is a time for sharing. But when doing so, (a) do so by design, (b) use encryption where practicable, and (c) consider the tradeoffs (we must acknowledge that there are tradeoffs, as engineers). It is ABSOLUTELY drafty, but I would like the idea of combining some concepts. What do people think? I know mine stretches a bit beyond the intarea... Eliot On 10/31/16 3:08 PM, 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 > 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] New Version Notification for draft-lhan-problems-requirements-satellite-net-00.txt
Lawful Intercept. On 08.07.21 19:52, Lin Han wrote: What does “LI” stand for? OpenPGP_signature Description: OpenPGP digital signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Hi Andrew, On 03.08.21 21:11, Andrew Sullivan wrote: On Tue, Aug 03, 2021 at 02:43:10AM -0700, John Gilmore wrote: lowest-address draft is the first of a set of upcoming drafts that propose small, easy improvements in IPv4. I think I recalled an (int area?) meeting something like a decade ago where there was a pretty strong sense of consensus that the right thing for the IETF to do is to stop fiddling with IPv4 and to make the path to v6 easier. Dave Meyer, Vince Fuller, and I were the co-authors of that work that was presented here at the int-area. We dropped the idea because there were some serious concerns about undefined behaviors in endpoints that would not expect to see packets with those addresses. If memory serves, Dave Thaler raised those issues, and referred to CPEs and firewalls in particular. The part of the logic that ran *for* using this address space was that it would show appropriate stewardship, by being as efficient as possible. Since then, IPv6 adoption is way up, and so are IPv4 prices; which is why this proposal is so interesting now. That doesn't invalidate your logic, but it's not why we dropped the proposal. Eliot OpenPGP_signature Description: OpenPGP digital signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Continuing the addressing discussion: what is an address anyway?
Hi Dirk, On 25.01.22 08:19, Dirk Trossen wrote: Hence, I would suggest that any answers to the question above ought to be guided by what we (as users) want from the network, e.g., in terms of reachability, privacy, security, exposure of desired capabilities and possibly more. The orthodoxy here is the seminal work of Shoch[1]. And of course there's Saltzer et al.[2] The assumptions being made today by different players are indeed all over the map. Routing is a function of the network. Or is it? Privacy is something the endpoint must manage. Or is it? So I like your approach for discussion. Eliot [1] http://www.postel.org/ien/txt/ien19.txt [2] http://web.mit.edu/Saltzer/www/publications/endtoend/endtoendA4.pdf OpenPGP_0x87B66B46D9D27A33.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Continuing the addressing discussion: what is an address anyway?
[copy architecture-discuss] Geoff, This is a pretty good characterization. In fact, it's exactly where we went in the NSRG nearly 20 years ago, just after MO first kicked out 8+8. For people's reference, we looked at naming at different levels, including at L3, in DNS, URNs (which were relatively new things then), HIP, etc. There were then several efforts in both the IRTF and IETF to deal with portability of connectivity in transport. I think QUIC gets a lot of that right. QUIC – at least at the moment – as some limitations for local use (either you have certs or some sort of prearranged bidirectional authentication). I think it's a fair engineering assumption that those will be kinked out. With all of that having been said, I go back to Dirk's note: what properties do we need at L3? * If QoS is still a thing, then admission control has to be part of the story. * There is a tussle between endpoint privacy and the endpoint itself being a threat. In the latter case, the endpoint has to be identified. But to whom? As you describe, a lot of routing has moved up a layer. Sort of. But not all. CDNs need to be well aware of topology, and that comes from L3, perhaps with additional OOB info. So... what's missing from L3 at this point that we need, and is it even a good question to ask? I ask that because I have seen recently a retrenching AWAY from IPv6. If that is happening, what makes us think that any new L3 beyond IPv6 would ever get adopted? OR... what is missing from IPv6 that would cause people to move? Eliot On 25.01.22 12:38, Geoff Huston wrote: On 25 Jan 2022, at 6:19 pm, Dirk Trossen wrote: All, Thanks for the great discussion, following our side meeting at IETF 112, so far. I wanted to turn the discussion to a key question which not only arose in the side meeting already but also in the discussions since, namely “what is an address anyway?”. In this world of NATs it seems that we treat addresses as no more than temporary ephemeral session tokens and we've passed all the heavy lifting of service identification over to the name system. These days you and I could be accessing the same service yet we could b e using entirely different addresses to do so. Or I could be accessing the same service at different times, and again be using different addresses each time. I find it somewhat ironic that we see increasing moves to pull in IP addresses as part of the set of personal information in some regulatory regimes, yet what the larger network sees of end clients is a temporary NAT binding to a public address that may be shared by hundreds if not thousands of others. And IPv6’s use of privacy addressing achieves a similar outcome in a different way. And QUIC’s use of the session token inside the encrypted envelope even makes the binding of an address to a single session fluid, as the same QUIC session can be address agile on the client side. So perhaps an address these days is just an ephemeral transport token and really has little more in the way of semantic intent. Geoff ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area OpenPGP_signature Description: OpenPGP digital signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] [IANA #1287329] expert review for draft-ietf-intarea-rfc7042bis (ethernet-numbers)
They seem ok. Eliot On 09.11.2023 13:22, Sabrina Tanamal via RT wrote: Hi Eliot and Dan (cc: intarea wg), Can one of you review the LLDP TLV Subtype changes in this newly approved document draft-ietf-intarea-rfc7042bis for us? Please see https://datatracker.ietf.org/doc/html/draft-ietf-intarea-rfc7042bis-11#section-5.8 If these are OK, we'll make the changes now. Please note that this registry was recently moved to the IANA OUI Ethernet Numbers registry group: https://www.iana.org/assignments/ethernet-numbers Please review by November 24th. Thanks, Sabrina ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
