Re: Why DNS sucks for referrals (was Re: Stupid NAT tricks and how to stop them.)
Are you saying that ENUM is a dead end? F. -- [EMAIL PROTECTED] 819 692 1383 On Wed, 29 Mar 2006, Keith Moore wrote: - DNS is often out of sync with reality Dynamic DNS updates are your friend. From an app developer's point-of-view, DDNS is worthless. DDNS is far from universally implemented, and when it is implemented, it's often implemented badly. DDNS can actually makes DNS a less reliable source of information about the host. In network operations you always see that stuff that isn't really used is a big mess, because nobody cares to set it up correctly in the first place and/or maintain it after that. Since current peer to peer applications (the applications that use referrals) don't bother with the DNS and for non-servers its only other purpose is looking pretty, it's no surprise that DNS info isn't very good. Of course a big part of the reason that distributed apps (not just p2p apps) don't consistently use DNS is that it doesn't work well. But it's not quite a chicken and egg problem. DNS cannot really work well for referrals. Core design assumptions in DNS no longer apply. Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism. If it's good enough for the web and email, why wouldn't it be good enough for p2p? (Which in itself is often very unreliable.) I'd argue that DNS is NOT good enough for the web, and maybe not good enough for email. When you click on a link and it takes seconds before the page even starts loading, that's probably DNS. Email is less delay sensitive, but when you send mail and it bounces because the MX records were out of sync with reality, DNS is implicated there also. Some p2p apps are unreliable because they are trying to layer over a network that imposes arbitrary restrictions on its use (unlike the IP design that assumes best effort) and on top of hosts that appear and disappear at a whim. Even then, they sometimes work better than client-server apps that try to serve the same purpose. - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS. Because there is little reason for them to be. But by expecting distributed apps to use DNS, you would be imposing the operational constraint that all of those hosts be listed in DNS. But even if that's something that continues to be so, it would still be better to use the DNS when available and use the address otherwise, rather than ignore the DNS completely. adding complexity that makes your app less relable is usually not a good way to go. Using DNS names as identifiers for referrals has problems. Using IP addresses as identifiers for referrals has a different set of problems. But IP addresses are a lot closer than DNS names. With the difference that the DNS is the control plane where you have time to think about stuff, while IP is the data plane where you need to perform millions of lookups per second. no. DNS is just an app that lets other apps find out certain kinds of information about certain resources on the network. It's nowhere nearly flexible enough to be a control plane. But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used. If we can agree which problem should be solved where, then consensus on the details becomes a lot easier. What I'm saying is that the IP address wont be an identifier stable enough to handle referrals in the future, so any protocols that make this assumption won't work very well. What I'm saying is that if IP addresses won't be stable enough for referrals in distributed apps, they won't be stable enough for referrals in DNS either. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Multiple roots E2E PKI trust discovery, chain management capabilities exchange
IETF-ers, What is the latest state-of-the-art thinking at the IETF about a distributed multiple-root systems for name discovery based on end-to-end peer-to-peer PKI-based trust discovery and trust chain management properties/capabilities exchange (I can sign you, you can sign me, I can do 4096 bits but you'll only parse 2048, etc.) Is it permissible to think that this could be an alternative to the DNS at some point in time in the future or does the DNS needs to remain as it is? I am thinking on figthing on the policy front to force a Tier1C implementation of ENUM with a distributed registry based on the use of registries at the NPA-NXX- (Co-code) level in Canada while the USA would remain with a flat file per NPA (Tier 1B) However, there is more generality to my question ... I need a quick rundown of the latest thinking (RFCs, ID's, IESG IAB directives, IRTF experiments) regarding: 1) distributed multiple roots 2) E2E P2P PKI-based trust discovery and trust chain management 3) capabilities and properties exchange in an E2E PKI environment. You can tell me to RTFM with reason since I have been out of touch for the last 5 years, and I will not take it personally, but any investment of time and energy into providing me some good warnings of DO NOT GO THERE would be very appreciated. -=Francois=- -- [EMAIL PROTECTED] 819 692 1383 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
However, there is more generality to my question ... I need a quick rundown of the latest thinking (RFCs, ID's, IESG IAB directives, IRTF experiments) regarding: 1) distributed multiple roots I would certainly be interested in any scientific and technical papers about this issue. This is a very interesting and challenging problem. But I think that we can safely say that you canNOT have multiple roots IF you want to keep the present semantics of the DNS. (For instance, the current semantics is If I send an email to [EMAIL PROTECTED], it will arrive in the same malibox, irrespective of my current email provider. See http://www.finee.com/travel_tld.htm.) Wouldn't you be able to resolve to a primary-ness state for a given TLD (domain names is just an example of the name resource you could resolve to), through a trust relationship. I would for example not trust .travel from new.net if ICANN had assumed control over .travel ... I should be able to pick this from a PKI-based P2P trust chain, would I not? It is not a limit of the current protocols. It is a limit forced upon us by the requirments: if you want the above semantics for [EMAIL PROTECTED], you canNOT have multiple roots, because something (the root) will have to decide who manages .travel. Otherwise, you will not arrive in Paris for the next IETF :-) It would not be the root, it would be the trust chain you build in your resolver... [You can compare with distributed file systems or distributed databases: you typically have to give in some requirments.] I have not seem trust chain management in any type of DFS... but I am not a specialist in DFS... though I cannot wait to see the day that Ethernet interfaces start to ship for SATA drives... -=Francois=- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multiple roots E2E PKI trust discovery, chain management capabilities exchange
On Sat, 23 Jul 2005, Masataka Ohta wrote: PKI has nothing to do with E2E. As CAs and DNS servers are intermediate systems, neither PKI nor DNS are E2E. As intermediate systems, they don't have any information on ongoing transaction that they can't give any real guarantee. Masataka-San, your NOTASIP ID still rings in my mind after all these years and I see that your approach at providing consistency to a discussion continues to be as thoughtful as it ever has been. This being said, in my question, I did knowingly imply that PKI as we know it from CAs is not end-to-end as CAs are intermediate systems. In your opinion, what do you see as the latest state of the art thinking towards PKI that is true-er to an E2E environment, knowing that I am looking for an answer in the context of my need to catch up quick so that I can better defend the need for a multiple roots at the NXX level in the ENUM environment - my true goal being to tell carriers to screw it with Carrier-ENUM. My argument is that you cannot subdomain a telephone number which can remain reachable from a telephone keypad, thus the need for competition at the registry level (if not, innovation will be restricted by the transaction costs of registering entries in Tier1B). I have described my proposed Tier1C here in details: http://www.crtc.gc.ca/cisc/COMMITTE/C-docs/CNCO0004.doc If pursuing this discussion gets too wild on IETF-discuss, I will agree to defer the ongoing discussion to the E2E-interest mailing list on postel.org and refer back once I have a better idea how stable is the ground. However, true here is my ambition to frame the discussion in such a way that I can know how to tackle my Tier1C proposed framework into the broader perspective of where the IETF has been, where it can go and where it does not or no longer wants to go (at least in the short term). -=Francois=- 819 692 1383 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Need for an open access IPv6 working group at the IETF
On Mon, 18 Jul 2005, Brian E Carpenter wrote: In 1999 you asked my predecessor's predecessor: I wonder if we should not have a new working group within the IETF that would issue informational RFC's on the topics of equal access using Internet Protocol technologies. Well, I'm quite sure the answer is no. That is a business model, policy and governance question, and these are not areas within the IETF's mission. I am in agreement that open access issues as they relate to business models, policy or governance, are not areas within the IETF mission. However, you have avoided giving consideration to the technical guts of my proposal: re: IPv6 flow field range partitioning, IPv6 prefix propagation and MPLS LSP to v6 flow mapping (as they emerge from DOCSIS SIDs). I am not proposing an open access working group per se, but I would like to know what the IETF-ers think about how best to support multiple simultaneous ISPs in an IETF-standardized sort of way. Do not ask me to have these discussions at Cablelabs... they do not want it. So where else? I've been out of touch for a while, so if anybody can bring me up to speed in a manner that is a bit more enthusiastic, I would appreciate deeply. Discussion of specific vendor's products is also outside our scope, except when they directly illustrate technical discussions. Can one at least tell me whether Multi-VRF is known to be an IETF standard? What is the RFC? It's clear that producing technical standards that are fair and open is in the IETF's mission, and that is where we should focus. If you have technical proposals that tackle this, they are most welcome, in Paris, Vancouver, or on-line. I should propose an ID in the IPv6 working group? You might, however, be interested by RFC 4084. I do not see the relevance of this RFC. Anything else? -=Francois=- 819 692 1383 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Need for an open access IPv6 working group at the IETF
Folks, With the positive result in Lafayette a few hours ago, and the increased reliance on non-standard Multi-VRF in CMTS for cable modem open access in Canada (which is finally being turned on as we speak), I think it is finally time to get my July 17, 1999 proposal out of the drawer (making it its 6th anniversary today by pure coincidence... proving again that things never change... or at least take forever to change...). What process should I follow to make this happen from a distance if I cannot manage to travel onsite at an IETF meeting? (Vancouver is as far from here as Paris!, but I am tempted to go.) Can anyone comment about whether I should be able to expect getting an MPLS LSP straight out of a Cisco CMTS into my own provider edge router as an ISP rather than rely on this being done internally by the cable carrier to a 7206 acting as the PE, but then running policy routing on the source IP address to select the right interface towards the ISP and then require to run the DHCP server on behalf of the ISP? Does anybody know whether this: http://www.cisco.com/en/US/products/hw/routers/ps259/prod_bulletin09186a00800921d7.html is known to be standardized and interoperable at the MPLS level with other provider hardware? I know some people my think that I should ask these questions to Cisco directly, but really, this is not the case... In Canada the CMTS hardware that cable carriers use might be cisco, but ISPs are free to select the PE hardware of their choice... So there is cause for concern that the cable carriers might be able to get LSPs straight out of the CMTS devices into PEs running at the ISP premises, but are refusing to do so, to restrict the cable modem unbundling framework in a manner which is not going to stand up for 2 seconds in a complaint at the CRTC (and I'm getting quite good at those). Has anybody got a better architecture to propose? Do not say PPPoE please... I want something that is IPv6 friendly. I still have in the back of my mind the idea of #1) using IPv6, #2) partitioning the flow field range and #3) doing admission control on certain ranges in combination with peering on an interdomain basis with QoS using a specific DSCP profile for peering across (not the Internet), but across the PSTN equivalent of a billkeep IMT trunk if you want. My thinking is of getting an LSP from the CMTS serving the cable modem CPE of the third party ISP, straight into the third party ISP. This would allow a fully bridged dedicaed LAN per third party ISP end-customer (one per home, using the DOCSIS session identifier to filter out broadcast traffic from neighbours on the same optical node). The third party ISP would then only need to have an IPv6 router with one leg into each LAN of each of its residential customers so that NDP works as-is. Does anyone make an IPv6 router with say, the capability of 1000 subinterfaces? I'd like to have an off-list discussion on this topic with those who feel their gear is up to the task. Does anyone make a tunnel stack for Windows XP which supports IPv4 tunnel over IPv6? Does anyone make a router which supports an IPv4 tunnel over IPv6? Does anyone make a VoIP ATA which supports IPv6? Does anoyone make an ADSL2+ router + H.264 settop box which supports an IPv4 tunnel over IPv6? Anybody in Asia with the genius to make this happen ? Best regards, -=Francois=- [EMAIL PROTECTED] --- For references, see a copy of my email dating from July 17, 1999: Date: Sat, 17 Jul 1999 14:13:34 -0400 (EDT) From: Francois D. Menard [EMAIL PROTECTED] To: ietf@ietf.org Subject: Equal Access Working Group ... Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Fred, everyone, I wonder if we should not have a new working group within the IETF that would issue informational RFC's on the topics of equal access using Internet Protocol technologies. Here in Canada, there is a trend in the government mandating shared access of the high speed Internet access facilities of the incumbent carriers. This means that instead of mandating shared access to the spectrum, the government seems to be increasingly satisfied with the incumbents offering interfaces at Layer 3 to satisfy the pouding requests of the non-facility based ISP's for a reasonable rate for a connection at the last mile. Unfortunately, we are already facing a huge problem: The CATV industry is lining up on variants of Source-Address-Looked Routing (a.k.a policy routing in Cisco-land) (not to call it source routing which seems to have more of a meaning for putting the path that the packet should take in the header of the packet). This isin't too bad as long as the CATV operators are confident to be capable of implementing this in a scaleable manner. So far, only Regional Cablesystems of Sudbury/Timmins Ontario has done it and seems to be satisfied
Re: IPv6 MTU issues in FTTH applications
I think the compatibility issue is the driver here. As long as there is some way to phase in new gear to take advantage of the standard, without breaking what is there now, MTU size could be increased to something that makes sense for the applications. With streaming media, application sharing, VoIP, and all the emerging apps, there is a need to increase the efficiency of the protocols. The larger the payload, assuming apps can take advantage of it, the more efficient the protocol (simplistically and generally speaking). vr bob That was my point, with the IEEE looking at a brand new generation of hardware for fiber to the home applications, if re-consideration of increasing MTU to something wich would be more optimal for an IPv6 FTTH world do not happen over the coming weeks, we'll be missing a great opportunity. There are no budge cycles here, no hubs to worry about, no intermediate routers that could not support the higher MTU. What we have here is a community of FTTH users with brand new gear doing peer to peer applications like high quality video conferencing. I'm trying to validate if the IPv6 routing header could be a good way to perform constraint-based routing without requiring the use of MPLS to perform this. -=Francois=-
RE: Specification verification tools
Hopefully, the venue of XML in the ASN.1 community will result in more open source PER runtime objects... -=Francois=- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Phil Griffin Sent: October 3, 2001 2:45 PM To: Henning G. Schulzrinne Cc: [EMAIL PROTECTED] Subject: Re: Specification verification tools That note mentioned ASN.1 and several others. Some language development that might be of interest that bridges both ASN.1 and XML can be found to various extents at: http://asn1.elibel.tm.fr/en/xml/ http://www.eetimes.com/story/OEG20010807S0038 http://www.ddj.com/news/fullstory.cgi?id=4341 http://xml.coverpages.org/ni2001-02-28-e.html http://xml.coverpages.org/xer.html This ASN.1 XML standards work should be completed next week at an ASN.1 group meeting in Orlando, FL, then immediately balloted. I understand that tools support for this work is slated for fourth quarter 2001 delivery. There is a free tools list on the first site listed, which I believe offers several ASN.1 syntax checkers as well as pointers to other free and for sale tools. Some of these are general, others quite specialized. The new ITU-T ASN.1 Project is in the process of compiling a list of verified ASN.1 modules that are being made freely available to anyone at http://www.itu.int:2001/ITU-T/asn1/database/. Currently these seem to include only ITU-T specifications, but I do not know what their intended scope may be. An on line base of correct IETF ASN.1 modules would certainly be useful. A note to the web master or contact might reveal more. And of course, all of the ASN.1 and SDL standards are now freely available from the ITU-T web site. A revision of ASN.1 is currently underway that will incorporate all of the TCs and amendments into a new 2002 edition. Phil Griffin Henning G. Schulzrinne wrote: Recently, the IESG sent a note describing and encouraging the use of formally verifiable means of protocol specification, in addition to English prose. To facilitate this effort, I will be setting a resource web page to provide information on mechanisms and tools. (Unless there is a formal IETF effort, of course.) For now, please send me pointers to tools and possible languages or other suitable means, including, for example, RFC 2234 (ABNF), ASN.1 as used for LDAP and SNMP, or XML schemas. Note that these tools are meant for verification, not for code generation. This is a freelance effort, and any statements or listings do not necessarily reflect official IETF or IESG policy or recommendations. Thank you. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs
RE: Nimda virus and whois search...
Seriously, what is the appropriate term: owner, rentee, leaser ? Assignee? -=Francois=-
