Re: Extreme Networks BD 6808 errors -- help to interpret.
I have probably missed something, perhaps unwritten policy, and for that I am sorry. I will not repeat my mistake. Please DO CONTINUE to discuss this on the list. Ignore all those messages of complaint. The only complaints that matter are those of the Mailing List Administrators whose names are listed here: http://www.nanog.org/listadmins.html The people who were complaining to you are not serious about network operations. They just want to keep it as a private club where only people who know the secret handshake can apply. However, in the 21st century, stable and reliable network operations are vital to the global economy. This means that we MUST openly discuss issues that arise in order to jointly solve the problems and to educate all parties involved, vendors, researchers and operators. It's OK to step on some toes and offend a few people. This is a rough and tumble business where you need to have a thick skin to survive. Perhaps the problem is that the COMPLAINANTS do not have a thick enough skin. --Michael Dillon
Re: wrt joao damas' DLV talk on wednesday
you were attending nanog without registering and paying? that is rude. have you offered to pay retroactively? that would be the honorable thing to do. todd underwood +1 603 643 9300 x101 renesys corporationchief of operations security There was a similar comment from another Renesys employee on nanog-futures. Is it possible that this is some sort of commercial dispute between two companies, Renesys and ISC, who are not network operators, but who offer services to network operators? In any case, it doesn't seem to be on topic for the NANOG list. If Renesys really doesn't like ISC, why don't you sue him instead of whining on this list? --Michael Dillon
Re: IP failover/migration question.
clear understanding as to what is involved in terms of moving the IPs, and how fast it can potentially be done. I don't believe there is any way to get the IPs moved in any kind of reasonable time frame for an application that needs this level of failover support. If I were you I would focus my attention on maintaining two live connections, one to each data centre. If you can change the client software, they they could simply open two sockets, one for traffic and one for keepalives. If the traffic destination datacentre fails, your backend magic starts up the failover datacentre and the traffic then flows over the keepalive socket. And if you can't change the clients, you can do much the same by using two tunnels of some sort, MPLS LSPs, multicast dual-feed, GRE tunnels. The Chicago Mercantile Exchange has published a network guide that covers similar use cases. In the case of market data, they generally run both links with duplicate data and the client chooses whichever packets arrive first. Since market data applications can win or lose millions of dollars per hour, they are the most time-sensitive applications on the planet. http://www.cme.com/files/NetworkingGuide.pdf When I desire to migrate hosts to the failover site, B would send a BGP update advertizing that the redundant link should become preferred, There is your biggest timing problem which is also effectively out of your control. By maintaining two live connections over two separate paths to two separate data centers, you have more control over when to switch and how quickly to switch. --Michael Dillon
Re: wrt joao damas' DLV talk on wednesday
attending nanog wasn't an option. i hadn't realized that sitting in on joao's talk so i could be there for QA equalled attendance, and so i neither paid nor offered retroactively to pay. Sounds to me like your intent was to be a Speaker do you really think i should? (i asked everybody i met on site, and was universally told by those i asked to stop worrying about it.) If Merit had simply given you a Speaker's Badge then all this tempestuous teapot wouldn't have dribbled a single drop. --Michael Dillon
Re: Zebra/linux device production networking?
On Tue, Jun 06, 2006 at 02:42:36PM -0700, Nick Burke [EMAIL PROTECTED] wrote a message of 39 lines which said: How many of you have actually use(d) Zebra/Linux as a routing device IMHO, the question is not perfectly phrased. You actually have several issues: * use a regular PC instead of big and expensive iron, * use Linux instead of FreeBSD or IOS or JunOS, * use Zebra instead of Quagga or Xorp. These questions are partly independent and should be addressed as such. For instance, Quagga + a free Unix can run on dedicated boxes like the Soekris, who have different characteristics than a regular PC (no moving parts, for instance). One last advice: be very careful when you read claims like it may seem appealing to suits with no networking knowledge: many people never tried what they criticize, they just do not want their CEO to discover that the expensive network could have been done for much less. [I installed, in a former job, Debian + Linux + Zebra on PCs and they route fine.]
Re: 2006.06.07 NANOG-NOTES TCP Anycast--don't spread the FUD!
On 6/12/06, Rodrick Brown [EMAIL PROTECTED] wrote: Looks like this document maybe have been removed? the link appears to be dead any mirrors? The slide deck hadn't been put online when I sent my notes; I took a guess at what the location might end up being, but guessed wrong. The actual location ended up being http://www.nanog.org/mtg-0606/pdf/levine.pdf Matt -- Rodrick R. Brown Senior Systems Engineer http://www.rodrickbrown.com http://groups.yahoo.com/group/wallstandtech
Re: wrt joao damas' DLV talk on wednesday
michael, all, On Mon, Jun 12, 2006 at 10:43:16AM +0100, [EMAIL PROTECTED] wrote: you were attending nanog without registering and paying? that is rude. have you offered to pay retroactively? that would be the honorable thing to do. todd underwood +1 603 643 9300 x101 renesys corporationchief of operations security There was a similar comment from another Renesys employee on nanog-futures. Is it possible that this is some sort of commercial dispute between two companies, Renesys and ISC, who are not network operators, but who offer services to network operators? as far as i know ISC and renesys have no overlapping businesses at all. we certainly don't consider them competitors and as far as i know, they don't even know who we are. In any case, it doesn't seem to be on topic for the NANOG list. If Renesys really doesn't like ISC, why don't you sue him instead of whining on this list? odd and harsh words. i have no beef with the ISC at all, no intention to sue them, and no idea what i would sue them for. i do have a problem with people attending nanog for free without paying and without being speakers (speakers are not those selected at random by Merit, but rather people whose presentations or panels are approved by the program committee as part of the official program). but indeed, aside from answering these oddly delusional comments on this list, this topic is better handled on nanog-futures. t. -- _ todd underwood +1 603 643 9300 x101 renesys corporationchief of operations security [EMAIL PROTECTED] http://www.renesys.com/blog/todd.shtml
Day tickets
On the DLV thread, but not responding to anybody in particular. As soon as you allow people to attend 1 talk for free, then you opened the door for people attending without paying. OTOH, I don't think that it is fair to ask people to pay the whole $350 if they only want to attend a few talks. For the RIPE meeting, this has been solved by introducing day tickets. People who don't want to attend the whole meeting, can buy tickets for individual days. They can attend the sessions they want, without feeling guilty about using resources but also without having to pay the full fee to attend only a few talks. Maybe this can be considered for NANOG as well Henk -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- 1160438400. Watch this space...
Re: wrt joao damas' DLV talk on wednesday
If Paul is present specifically and only for QA that pertains to subject matter with which he is knowledgeable, his presence helps the ops community. I have not seen any writings that indicate that Paul was at bg or bofs or other portions of the conference. i was at the BG, having first checked with the host to find out if visitors were welcome. while my intent was to pick somebody up for dinner, i admit that i also ate and drank and socialized. Based upon that data, I am inclined to support Paul. The proper procedure would have been to let Merit know that he would be there to support the individual presenting the talk. Other than that, I see no offense. now that you know the whole story, perhaps you'll reevaluate your position. my own feeling on this is that if i'm attending a nanog in some distant city and there are ops people living/working in that city who do not have time to attend, then i would rather that they came to the nanog social events than either (a) not see them at all, or (b) have to meet them elsewhere. however, this is not a debate about facts (which aren't in dispute), but rather manners, a social-subjective matter. what is or isn't rudeness varies somewhat with time, location, culture, society's mood, and so on. lacking a miss manners to gauge the nanog society's mood in this time and place, we all have to just use our own best judgement. mine failed me, and i've already apologized for that.
Re: Day tickets
On 6/12/06, Henk Uijterwaal [EMAIL PROTECTED] wrote: As soon as you allow people to attend 1 talk for free, then you opened the door for people attending without paying. OTOH, I don't think that it is fair to ask people to pay the whole $350 if they only want to attend a few talks. APRICOT has something quite similar - register for whichever tutorials / tracks you want and pay for just those (though of course it works out cheaper to pay for the entire mtg, beyond a certain point) Something like this - http://www.apricot2006.net/index.php/fuseaction/home.registration --srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: wrt joao damas' DLV talk on wednesday
Paul Vixie wrote: If Paul is present specifically and only for QA that pertains to subject matter with which he is knowledgeable, his presence helps the ops community. I have not seen any writings that indicate that Paul was at bg or bofs or other portions of the conference. i was at the BG, having first checked with the host to find out if visitors were welcome. while my intent was to pick somebody up for dinner, i admit that i also ate and drank and socialized. Based upon that data, I am inclined to support Paul. The proper procedure would have been to let Merit know that he would be there to support the individual presenting the talk. Other than that, I see no offense. now that you know the whole story, perhaps you'll reevaluate your position. my own feeling on this is that if i'm attending a nanog in some distant city and there are ops people living/working in that city who do not have time to attend, then i would rather that they came to the nanog social events than either (a) not see them at all, or (b) have to meet them elsewhere. however, this is not a debate about facts (which aren't in dispute), but rather manners, a social-subjective matter. what is or isn't rudeness varies somewhat with time, location, culture, society's mood, and so on. lacking a miss manners to gauge the nanog society's mood in this time and place, we all have to just use our own best judgement. mine failed me, and i've already apologized for that. Wow, are there no outstanding technical, networking, product subjects left to talk about that this has been the most active subject in the last few days? It happened, but that doesn't necessarily mean that others will take advantage of this in the future. Some make small mistakes and others have no honor. This seems to be a case of a small mistake. GET OVER IT! --Payam T Chychi
Re: wrt joao damas' DLV talk on wednesday
michael, all, [ if you can't use procmail, could you at least respond to non-ops trolls on the nanog-futures list? ] but todd, you have a bit of clue. do you have a clue at all regarding the question i asked on-list the other day? what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? if the above can not be very clearly answered (by isc?), then this proposal is techno-political hubris at best. randy
Re: wrt joao damas' DLV talk on wednesday
Paul Vixie wrote: I have not seen any writings that indicate that Paul was at bg or bofs or other portions of the conference. i was at the BG, having first checked with the host to find out if visitors were welcome. while my intent was to pick somebody up for dinner, i admit that i also ate and drank and socialized. Based upon that data, I am inclined to support Paul. now that you know the whole story, perhaps you'll reevaluate your position. Let's see: 1) You attended a bg after checking with the host 2) You attempted to attend a qa with the purpose of providing additional input for the ops community and that provided support for a speaker. Is there a better way to have handled the situation? Perhaps. The positive outcome of this issue is that we are discussing how to handle drop-ins (freebie conference attenders?). I still don't see that you fall into this category with regard to this incident.
RE: wrt joao damas' DLV talk on wednesday
now that you know the whole story, perhaps you'll reevaluate your position. While I have a number of opinions on the subject (who on this list does not have opinions?), I suggest that the program committee members take this on as todo to formulate some sort of acceptable practice for future NANOG meetings. Paul has made a number of good points, as have others. Paul may be special (are we not all?), but just because he is special should not mean different expectations in behavior and actions at these meetings. Many good points have been raised. Make some choices, and stick with them for future meetings. Gary smime.p7s Description: S/MIME cryptographic signature
Re: wrt joao damas' DLV talk on wednesday
Is there a better way to have handled the situation? Perhaps. indeed, i should have registered as a speaker and sat behind joao while he spoke. The positive outcome of this issue is that we are discussing how to handle drop-ins (freebie conference attenders?). agreed, there's a salient issue underlying all of this chaff. for example, if someone only wants to come to nanog for the hallway discussions and not attend any of the meetings or bofs (or eat any of the food, or use the wireless), are they welcome? before last week i'd've said yes. manners in this case means what should others be allowed to do rather than what each of us would like to be able to do, or in other words, what will scale? I still don't see that you fall into this category with regard to this incident. from my personal e-mail so far, that view is in the minority. (this is not your grandfather's nanog.) on the other hand i really would rather talk about DLV than meeting manners.
Re: wrt joao damas' DLV talk on wednesday
i really would rather talk about DLV than meeting manners. cool! or we should at least take meeting manners and registration policies over to nanog-futures. but, if you want to talk about dlv, could you answer my questions? what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? as providing a tld key registry is tantamount to emulating the root key responsibilities of the iana, potential users should be rather concerned. randy
Re: wrt joao damas' DLV talk on wednesday
Paul Vixie wrote: [some other stuff] on the other hand i really would rather talk about DLV than meeting manners. I'd like to hear about DLV. For example, Randy Bush asked (twice) the following: my question was a bit simpler. what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? I would also like to understand the security policy, and to hear how DLV at ISC will handle key roll-over and revocation. as providing a tld key registry is tantamount to emulating the root key responsibilities of the iana, potential users should be rather concerned. -- ...any language that actually pays attention to white space is the spawn of pure oozing black evil from the 29th layer of the deepest hell imaginable --Phil Dibowitz, on Python
Re: wrt joao damas' DLV talk on wednesday
randy, all, On Mon, Jun 12, 2006 at 06:37:01AM -1000, Randy Bush wrote: michael, all, [ if you can't use procmail, could you at least respond to non-ops trolls on the nanog-futures list? ] indeed. i don't use the former but i should have used the latter. apologies. but todd, you have a bit of clue. do you have a clue at all regarding the question i asked on-list the other day? what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? i don't. i've been reading the spec recently and trying to catch up on the contents of the recent nanog meeting that i was unable to attend. i've been a long-term sceptic of dns-sec due to the lack of any movement on the issuing of a root key (and the multiple, incompatible changes in the protocol itself), but this effort looks interesting. if the above can not be very clearly answered (by isc?), then this proposal is techno-political hubris at best. yes, or an interesting proof-of-concept that can be taken-up and completed by someone else. t. -- _ todd underwood +1 603 643 9300 x101 renesys corporationchief of operations security [EMAIL PROTECTED] http://www.renesys.com/blog/todd.shtml
Re: wrt joao damas' DLV talk on wednesday
Paul may be special ... nope. we're all just bozos on this bus.
Re: wrt joao damas' DLV talk on wednesday
Randy, On Jun 12, 2006, at 9:56 AM, Randy Bush wrote: as providing a tld key registry is tantamount to emulating the root key responsibilities of the iana, While I might wish otherwise, IANA does not have root key responsibilities. potential users should be rather concerned. If they're concerned, then I would imagine they can wait until the root is signed. Rgds, -drc
Re: wrt joao damas' DLV talk on wednesday
what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? if the above can not be very clearly answered (by isc?), then this proposal is techno-political hubris at best. yes, or an interesting proof-of-concept that can be taken-up and completed by someone else. actually, i suspect that the issues of dlv are exactly those of iana root signing, key management and tld signature policy. and hence dlv is hoisted on the same petard it attempts to avoid, and then devolves to a simple power play of isc vs iana with neither having a good answer to the real technical and security issues. randy
to DLV or not
My background and position on this is best summed up as one of the early implementers of DNSSEC and now working for a gTLD/ccTLD registry. In between I spent a lot of time developing, redeveloping DNSSEC in the face of operational realities. (To those who are critics of DNSSEC, I ask forgiveness for my wasted middle-age.) DLV is a concept that someone somewhere in the past few years came up with to put needed DNSSEC data in a special location. Although DLV per se is novel in the development of DNSSEC, it is well in-line with the earliest intentions of the protocol dreamers. The original DNSSEC design was to allow any resolver (client) to decide how it would collect the needed records to substantiate an answer. In the mid to late 90's we tried to figure out how to first express a policy and then come up with something that could take the policy and direct the operation of a DNS validator (the thing that gives a thumbs up or down to an answer after checking the DNSSEC stuff). We punted, resulting in RFC 3008, which said that the only common policy was to follow the tree, i.e., root signs tlds, tlds, sign down, etc. A few years later, a project called FMESHD to reopen the policy to be more general. Again, the problem proved too big to solve. Why DLV is different from these two failures is that we had been trying to solve the general case without a validator in hand. (We did have validators, but nothing that was integrated with a real name server.) DLV is starting from an implementation and is a pragmatic attack on the problem. DLV is not as general as the original idea, but wider than RFC 3008. The main concern with DLV is that is it not scaleable. That's inherent in the problem so I am not surprised. The tradeoff is that you can go off the tree but at the cost of knowing where you are going off the tree. Some folks feel that DLV will compete with TLD registries and delay their interest. Or maybe, for the same reason, spur their interest. My opinion is neither, DLV is orthogonal to the TLDs. DLV may be a good measure of interest in DNSSEC though. Either there will be no interest, a quick spike in interest, or a sustained growth. My guess is the middle option - a lot of early registrations and then slow growth. If that's the case, scaling isn't the concern and it won't spur the registries to add DNSSEC. So, ISC's DLV operation? The developers of BIND are free to distribute code with a validation policy that looks up data in their DLV. If all works, then all is good. If it's a disaster, ISC's DLV will cease and the code will cease to have the feature. Let the market decide. I don't think that what the pro-s and anti-s *think* matters as much as having tangible data on what *happened*. If the techies still rule the Internet, something like DLV ought to be given a try. Show off a technical solution and use that as an example of the way forward. We've been stalling long enough trying to move policy makers to sign the root zone. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
Re: wrt joao damas' DLV talk on wednesday
Randy, On Jun 12, 2006, at 10:08 AM, Randy Bush wrote: actually, i suspect that the issues of dlv are exactly those of iana root signing, key management and tld signature policy. Nope. Oh sure, from a technical perspective, the problems are pretty much the same, but I think they are solvable (if not in a way that will please everyone). However, one of the major layer-9 or above issues having to do with signing the root is who is going to sign the root, which translates to who owns the root. The answer, from a political perspective, isn't as obvious as one might wish. When you push down a layer in the DNS hierarchy, then the layer-9 or above issue becomes _much_ clearer and easier to solve. ccTLD admins and folks like PIR, Verisign, Neustar, etc., have clear and unambiguous authority over their zones (not getting into the argument of whether they should have clear and unambiguous authority) and thus, there is no question who should sign those zones (how is a mere implementation detail). The problem is, if you push down a layer, you have to figure out how to get the appropriate keying information into the caching server's trusted-key (or moral equivalent) statement. I personally think some sort of automated non-DNS out-of-band mechanism would be better than recreating the who gets to sign X problem, but there are lots of annoying details to deal with. and hence dlv is hoisted on the same petard it attempts to avoid, and then devolves to a simple power play of isc vs iana with neither having a good answer to the real technical and security issues. Can you have a power play when at least one party doesn't play? IANA's role is really easy: people tell us what to do, we try to do it. When somebody tells IANA how to deal with root signing, key management, and tld signature policy, we do what is necessary to implement what is asked of us. Until then, I'm a bemused bystander... Rgds, -drc
Working on a long-term ipv6 multihoming solution
This is a follow-up to my and Jason's presentation from Wednesday. Several people mentioned in the hallways that they were interested in following this issue and possibly helping work on the solution. If you are one of them and haven't already seen a message subscribing you to the mailing list, please send email to: [EMAIL PROTECTED] It would be helpful to indicate whether you are interested in following the work or in actively participating in it. Note that ipmh-interest is not the actual mailing list (there will be two separate lists established: ipmh-discuss, which is a open mailing list to follow and track the work and ipmh-design which will be a closed list for a small, focused design team. If anybody has issues with this list being hosted at Cisco (it is most definitely not a Cisco-only effort and shouldn't be perceived as such; I'm only hosting it there for convenience), please provide that comment too; if there is strong consensus, I'll be happy to move the list to a more neutral place. --Vince P.S. Jeff Burgan: can you please contact me offline? It looks like your employer's email system is misconfigured and is bouncing all mail that I attempt to send to you.
Re: Day tickets
For the RIPE meeting, this has been solved by introducing day tickets. RIPE is a whole week at Butlins[1] to Nanogs' day by the sea brandon [1] http://en.wikipedia.org/wiki/Butlins
Tracing network procedure for stolen computers
Hi folks, Quick security tracing question, flame me if you think offnetwork topic. Earlier this month my daughters Ibook was stolen, oh well that is life I guess. Anyway updated mail server software for full debug and IP log since noticed that mail account was accessed yesterday. I am now hoping it is access'd again, system was setup to pull each min so when they(thugs) access internet again hopefully will honeytrap IP number. What does one do next ? I guess inform police etc but would this be too slow ?? Do I contact ARIN/RIPE contacts direct ?? I know about software that should have been installed for tracing if stolen but wondered about in the real network world how useful this was and if any items recovered ?? Colin Johnston Satsig sysadmin
Re: Tracing network procedure for stolen computers
Colin Johnston wrote: Hi folks, Quick security tracing question, flame me if you think offnetwork topic. Earlier this month my daughters Ibook was stolen, oh well that is life I guess. Anyway updated mail server software for full debug and IP log since noticed that mail account was accessed yesterday. I am now hoping it is access'd again, system was setup to pull each min so when they(thugs) access internet again hopefully will honeytrap IP number. What does one do next ? I guess inform police etc but would this be too slow ?? Do I contact ARIN/RIPE contacts direct ?? I know about software that should have been installed for tracing if stolen but wondered about in the real network world how useful this was and if any items recovered ?? Colin Johnston Satsig sysadmin Apple have their own good ideas. Besides a VoIP phone software or something like no-ip.com is good to permanently know what ip-address the toy has. Knowing the ip you can traceroute to guess what continent, state, province it is, via its final router. The police and the owner of the final router should do the rest. Bad idea :) have some child porn on the box and mail it to the police. They will trace it very fast. -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
Re: wrt joao damas' DLV talk on wednesday
I'd like to hear about DLV. For example, Randy Bush asked (twice) the following: my question was a bit simpler. what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? I would also like to understand the security policy, and to hear how DLV at ISC will handle key roll-over and revocation. since joao is probably still sleeping-off the time shift from san jose to madrid, i'll chime in here. the last plan i saw was the same as the last draft i heard about for what any other important zone would do with a key that has to be hard coded in a lot of places: allocate more than one KSK and an infinite lifetime. use this KSK offline (only), to generate ZSK's with short lifetimes that are in turn used online to sign the zone. many are those argue that DNSSEC-bis, having failed to address key-rollover, is unimplementable. DNSSEC-ter may or may not come about (depending on the contining faith and patience of those who funded DNSSEC and DNSSEC-bis) in order to (a) prevent zone-walking, (b) allow for unsecured subdelegations, and (c) automate key-rollover. (that's NSEC3 and TAKREM in a nutshell.) on the other hand i believe that DNSSEC-bis is good enough to solve some real world problems, and that the thing that makes it unimplementable is merely its dependence on cooperation between US-DoC, ICANN, and VeriSign around the myriad issues touched on by the sign the root zone work item. that's why ISC is helping (under contract to VeriSign and Nominet) with NSEC3 and stands ready to help with automated trust anchor work as well-- these are important problems. if hand-edited trust anchors backed by infinite-lifetime offline KSK's are unacceptable to you, then you are already not a candidate for DNSSEC-bis and you're going to be waiting for DNSSEC-ter. so, no complaints about the fact that DLV uses the only thing DNSSEC-bis specifies in that area, unless you have a proposal for automated rollover that's as easy to implement as DLV was, and IPR-unencumbered, in which case, send it over! as providing a tld key registry is tantamount to emulating the root key responsibilities of the iana, potential users should be rather concerned. tantamount is an unruly word, it accuses without specification. in any case anyone who is concerned about DLV should seek alternatives, such as: | 1. figure out why the root zone isn't signed and fix whatever it is. | | 2. design your own version of DLV (as sam weiler has done, long before | ISC's although i didn't learn this until later), publish it, and | urge adoption (find someone to run a DLV registry, implement the | validator side, and so on.) | | 3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code | for the validator side, start your own DLV registry. | | 4. go to IETF and say i think something DLV should be a standard but | i don't like ISC's, so let's make an RFC together. and i forgot to mention: 5. forget about DNSSEC until all these problems are solved by others. whichever (or whatever else related) you want to do, you can count on ISC's support. just don't count on ISC's inaction; ISC isn't adept at inaction. that URL again is http://www.isc.org/ops/dlv/. -- Paul Vixie
Re: wrt joao damas' DLV talk on wednesday
[EMAIL PROTECTED] (David Conrad) writes: Can you have a power play when at least one party doesn't play? what i find fascinating by the whole why don't you and him fight? angle being played out here is that there is *no* trusted entity for this. drc, can you check with your corporate masters to find out whether ICANN, ISOC, ITU, NRO, and the other alphabet-soup denizens of your choice could somehow do a joint venture around DLV? it seems to me that if we dilute the stew with enough disparite international unaligned interests, we'll eventually reach a point where the result appears so dilute as to be powerless and therefore trustworthy, but still barely potent enough to operate a DLV zone. -- Paul Vixie
Re: wrt joao damas' DLV talk on wednesday
On Mon, 12 Jun 2006, Randy Bush wrote: what is the security policy that isc plans to use over the content of the isc dlv registry? and how will the dvl trust key roll-over and revocation be handled? if the above can not be very clearly answered (by isc?), then this proposal is techno-political hubris at best. yes, or an interesting proof-of-concept that can be taken-up and completed by someone else. actually, i suspect that the issues of dlv are exactly those of iana root signing, key management and tld signature policy. and hence dlv is hoisted on the same petard it attempts to avoid, and then devolves to a simple power play of isc vs iana with neither having a good answer to the real technical and security issues. Unless I misunderstood the issues are not some-kind of power-play but that in order to use DNSSEC right now you need to be within the zone/TLD that itself is using DNSSEC and these are almost non-existent right now with zone maintainers unwilling to take necessary financial and other risks associated with upgrading to fully support DNSSEC. So DLV offers potential for individual domain owners to start using DNSSEC without waiting for the registry operator of their domain's TLD or SLD. This seems good to me and I'm happy ISC as non-profit organization is taking the initiative as I don't want the same situation as was with domains and certificates at the end of 1990s where profit-driven companies were acting as virtual monopoly in domain business. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: wrt joao damas' DLV talk on wednesday
On Mon, Jun 12, 2006 at 09:41:03PM +, Paul Vixie wrote: since joao is probably still sleeping-off the time shift from san jose to madrid, i'll chime in here. the last plan i saw was the same as the last draft i heard about for what any other important zone would do with a key that has to be hard coded in a lot of places: allocate more than one KSK and an infinite lifetime. use this KSK offline (only), to generate ZSK's with short lifetimes that are in turn used online to sign the zone. At NANOG 37, possibly after you had left the room, Randy actually asked if we were writing a document describing ISC's operational guidelines and policies for the dlv zone. All those things DRC recently said no one has told him to do yet. It's in that context I think that he asks these questions now. I got the idea Randy was looking for info like appears in the BCP that describes root server operations requirements, except as applies to our DLV zone (and probably not an IETF document). So, how many boxes have the private keys? What barriers lock them away? How many people have access to the raw keys? How many authoritative servers give out dlv.isc.org and where do they sit in the network and on the globe? Do you pre-publish or double-sign (or triple-sign (or quintuple-sign (or ...)))? I have no idea if such a thing exists or plans to exist, or what might appear inside it. | 1. figure out why the root zone isn't signed and fix whatever it is. | 2. design your own version of DLV (as sam weiler has done, long before | 3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code | 4. go to IETF and say i think something DLV should be a standard but 5. forget about DNSSEC until all these problems are solved by others. Even if I choose not to do any of those 5 things and adopt ISC's DLV registry, I probably would want some basis to compare ISC's DLV registry with Acme's DLV registry. Having a basis to compare ourselves with...an imagined ideal of ourselves...is a bit of an intellectual excercise, but it does set the bar for future work in similar operations, such as signing TLDs and the root zone (wether it is IANA who is asked to do it or not). And it helps people decide if they want to throw in or wait it out for someone with stronger practices (or deploy a DLV with stronger practices). I personally think Randy's request (or my imagined version of same) would be good reading, if someone could be found who had both the time and knowledge to write it, and if doing so wouldn't be construed as giving away the keys to the castle. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpTTO0IQk1fQ.pgp Description: PGP signature
Re: IP failover/migration question.
On Mon, 12 Jun 2006 [EMAIL PROTECTED] wrote: clear understanding as to what is involved in terms of moving the IPs, and how fast it can potentially be done. I don't believe there is any way to get the IPs moved in any kind of reasonable time frame for an application that needs this level of failover support. There may be actually... if you don't have to be TOO far apart: soemthing like (that no one at mci/vzb seems to want to market :( as a product) 2 external connections (isp) 2 internal connections (private network) 2 cities (washington, DC and NYC for this arguement) 2 Metro-Private-Ethernet connections 2 Nokia Firewall devices (IP740 or IP530 ish) 2 catalyst switches 2 copies of equipment in 'datacenter' (one in each location) Make the nokia's do BGP with the outside world, do state-sync across the MPLE link, make the MPLE link look like a front-side VLAN, backside VLAN, and state-sync VLAN (you could do this with a single MPLE connection of course) announce all routes out NYC, if that link goes dark push routes out DC link. State sync on the firewalls Checkpoint/Nokia says will work if the link has less than 10ms latency (or so... they aren't much with the hard numbers on this since they noramally site in the same rack). you could even (probably) make things work in NYC for NYC users and DC for DC users... though backside state-sync in the apps might get hairy. -chris
