Re: wrt joao damas' DLV talk on wednesday
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). actually, i think it most important that a proposed dlv service make very clear its security policy and process in vetting the correctness of the data it serves, i.e. the trust anchors for dependent zones. once one can have confidence in the correctness of the data served, one might then become inclined to worry about the reliability of the service :-). randy
Re: Tracing network procedure for stolen computers
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. It's a UNIX machine. You own it. You know the password. If you had only set up an SSH server on it, you would now be able to log in and collect additional information about the current user. Interesting things can happen when intelligent devices find themselves stolen... http://www.evanwashere.com/StolenSidekick/ --Michael Dillon
RE: Tracing network procedure for stolen computers
Actually, it seems this his how you get stolen items back in the internet age ;-). http://www.evanwashere.com/StolenSidekick/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 5:32 AM To: [EMAIL PROTECTED] Subject: Re: Tracing network procedure for stolen computers 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. It's a UNIX machine. You own it. You know the password. If you had only set up an SSH server on it, you would now be able to log in and collect additional information about the current user. Interesting things can happen when intelligent devices find themselves stolen... http://www.evanwashere.com/StolenSidekick/ --Michael Dillon
Re: 2006.06.07 NANOG-NOTES Lightning talk notes
On Fri, Jun 09, 2006 at 03:49:50PM -0700, Matthew Petach wrote: (I think these were the toughest to take notes on, since they went by so fast; took the most cleaning up afterwards. But they were also the best talks of the 3 days. I wish we could have flipped, and taken more time on Tuesday for them so we really could have dug in and asked the questions we were itching to ask. ^_^; --Matt) Some of the talks are dups from the DNS Ops session the Friday previous, see http://public.oarci.net/dns-operations/workshop-2006/ for copies of the presentations. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: Day tickets
Moving to nanog-futures. Or trying, anyway. On Mon, Jun 12, 2006 at 04:45:30PM +0200, Henk Uijterwaal wrote: 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... -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: wrt joao damas' DLV talk on wednesday
On Tue, Jun 13, 2006 at 01:18:06AM -0700, Randy Bush wrote:
actually, i think it most important that a proposed dlv service
make very clear its security policy and process in vetting the
correctness of the data it serves, i.e. the trust anchors for
dependent zones.
Oh, you're asking specifically for more detail than is on our
web page, then ('Registering your zone key in the DLV tree').
You mentioned that this would have relevance to future practices
should the root be signed, and I can't for the life of me see how.
I think this is an artificial problem that arises only for ISC since
we're out of the delegation loop (except where we can authenticate
registries and receive trust anchors from them).
Do you imagine that, if IANA/ICANN/USDOT/someone were told to
implement a policy to sign the root, that they would have trouble
identifying the owners of the TLD's reliably?
If so, wouldn't this problem already exist today in the information
already present in the root zone?
once one can have confidence in the correctness of the data
served, one might then become inclined to worry about the
reliability of the service :-).
--
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
pgp9Ou6ZZGlFt.pgp
Description: PGP signature
Re: wrt joao damas' DLV talk on wednesday
Hi, On Jun 13, 2006, at 8:47 AM, David W. Hankins wrote: Do you imagine that, if IANA/ICANN/USDOT/someone were told to implement a policy to sign the root, that they would have trouble identifying the owners of the TLD's reliably? Yes. And it isn't a question of signing the root -- that just makes it more ... fun. It is a generic authentication problem that crops up anytime there is any change to the root. Fortunately, the root community is relatively small and well defined and IANA has evolved processes that, while sub-optimal, do generally work. If so, wouldn't this problem already exist today in the information already present in the root zone? Yes. However, I believe you all are proposing to remove the relatively small and well defined component that helps IANA deal with the issue on a daily basis. A hard problem. Rgds, -drc
Re: wrt joao damas' DLV talk on wednesday
I think this is an artificial problem that arises only for ISC since we're out of the delegation loop (except where we can authenticate registries and receive trust anchors from them). if other non-delegators run dlv services, they will have the same issues. and if you are a delegator, why play dlv as you can directly sign? Do you imagine that, if IANA/ICANN/USDOT/someone were told to implement a policy to sign the root, that they would have trouble identifying the owners of the TLD's reliably? how they validated that the keys they sign are correct would be an issue, for sure. but we have some idea of the iana's relationship with the tld zone holders, though, like many things, that could certainly be improved. the isc web page now says Before it is accepted into the dlv.isc.org zone, ISC will perform checks to ensure the keys are being used in the requested zone, that the persons making the request are who they claim to be and that they are authorised by the domain holder to request the inclusion of the keys in the zone. This check will require an in-person meeting with authorised ISC staff to verify documentation. so, there will be strange travel costs incurred, but we have no idea what actual checks will be done. when charles mussisi flies from kampala to redwood city, will he be expected to have brougt the zone key with him on cdrom or something, and you'll check his passport against the iana cctld registry and then accept the key? and, when the iana redelates the UG zone, how will you know this and stop handing out a bogus key? If so, wouldn't this problem already exist today in the information already present in the root zone? yep. and iana goes through some non-trivial exercises to validate that they are delegating 'correctly' as defined by 1591 and other documents. and those of us in the tld game are aware of them in some detail, irrespective of our opinion of them. luckily, they do not require people to pay airlines. all i am asking is that isc publish *how* it will validate the correctness of the zone trust keys they sign and provide under their proposed dlv service. e.g., how do you propose to check that the cctld, e.g. NG or UG, for which your proposed dlv service might yield a key is indeed the real NG or UG zone key? randy
Re: wrt joao damas' DLV talk on wednesday
On 13-Jun-2006, at 13:27, Randy Bush wrote: the isc web page now says Before it is accepted into the dlv.isc.org zone, ISC will perform checks to ensure the keys are being used in the requested zone, that the persons making the request are who they claim to be and that they are authorised by the domain holder to request the inclusion of the keys in the zone. This check will require an in-person meeting with authorised ISC staff to verify documentation. so, there will be strange travel costs incurred, but we have no idea what actual checks will be done. when charles mussisi flies from kampala to redwood city, will he be expected to have brougt the zone key with him on cdrom or something, and you'll check his passport against the iana cctld registry and then accept the key? I don't profess to speak for ISC here, but it may be worth noting that ISC staff continue to spend a lot of time travelling to operator meetings, workshops, root server installations and RIR and ICANN meetings. Outreach and community participation is one of the core things that ISC does. It's not unreasonable to think that for a lot of zone operators (ccTLD or otherwise), the mountain will eventually come to Mohammed, and travel by the zone operator won't be necessary. In the case of Uganda, by way of example, I've met Charles in person several times, and I'm sure we will do so again. I remain on ISC's books as an unpaid volunteer. If I can help Charles and ISC on some mutually-agreeable project I would of course be happy to. The social tendrils of ISC run longer and deeper than many people realise. Perhaps this is one of the things that makes ISC a good organisation to anchor projects like DLV. and, when the iana redelates the UG zone, how will you know this and stop handing out a bogus key? I can't answer that question. My expertise in this area is less about the crypto, and more about the beer :-) Joe
Re: wrt joao damas' DLV talk on wednesday
I don't profess to speak for ISC here, but it may be worth noting that ISC staff continue to spend a lot of time travelling to operator meetings, workshops, root server installations and RIR and ICANN meetings. Outreach and community participation is one of the core things that ISC does. It's not unreasonable to think that for a lot of zone operators (ccTLD or otherwise), the mountain will eventually come to Mohammed, and travel by the zone operator won't be necessary. can you say does not scale? or how about works poorly when a zone is transferred? i think there is no question that you and isc mean well. but we've entered the the twisty passages of security. randy
Re: wrt joao damas' DLV talk on wednesday
On 13-Jun-2006, at 14:37, Randy Bush wrote: I don't profess to speak for ISC here, but it may be worth noting that ISC staff continue to spend a lot of time travelling to operator meetings, workshops, root server installations and RIR and ICANN meetings. Outreach and community participation is one of the core things that ISC does. It's not unreasonable to think that for a lot of zone operators (ccTLD or otherwise), the mountain will eventually come to Mohammed, and travel by the zone operator won't be necessary. can you say does not scale? Indeed. With the current trust policy, it seems to me that DLV is a bootstrap mechanism intended to promote bottom-up pressure for DNSSEC deployment, and to give people a chance to get to grips with things like key rollover and zone signing. It's a frog dressed up as a chicken which is being rolled out because people are fed up waiting for an egg. In that context, perhaps it doesn't need to scale very far. Joe
Re: wrt joao damas' DLV talk on wednesday
With the current trust policy, it seems to me that DLV is a bootstrap mechanism intended to promote bottom-up pressure for DNSSEC deployment, and to give people a chance to get to grips with things like key rollover and zone signing. well, unlike ipv6 marketing efforts, at least it does not create an unrecoverable mess in routing. It's a frog dressed up as a chicken which is being rolled out because people are fed up waiting for an egg. In that context, perhaps it doesn't need to scale very far. perhaps the bottom line is whether it makes us more vulnerable. while an incorrectly secured zone is arguably no worse than one which is not secured, it seems to create a focus for attack. but what leaves me wondering is why this is all so difficult. why can isc not simply say we plan to vet zones as follows:. and we plan to manage maintenance of key rollover as follows: etc.? randy
Re: wrt joao damas' DLV talk on wednesday
On Jun 13, 2006, at 11:55, Randy Bush wrote: but what leaves me wondering is why this is all so difficult. Possibly because many people find writing formal security policies, which I think is what we're really talking about here, to be a dry and unpleasant experience, much less fun that code-hacking or packet- analyzing or whatever else you can find to do instead. why can isc not simply say we plan to vet zones as follows:. and we plan to manage maintenance of key rollover as follows: etc.? Would it help if I volunteered to talk to folks and help write something up? I mean, if there's some other issue that is preventing ISC from nailing this down, then that's one thing. But if it's just a case of never seems to bubble up to the top of the stack, then maybe a little outside assistance can do the trick. Besides, now that the semester's over, I need something besides just firing off resumes (gotta fill that summer time, and not completely lose touch with the Real World!) to keep myself entertained. You may flame when ready, Gridley. -- Brian McMahon brian dot mcmahon at cabrillo dot edu Computer Networking and System Administration Instructor Cabrillo College, Aptos, California
Re: wrt joao damas' DLV talk on wednesday
On Tue, Jun 13, 2006 at 11:37:08AM -0700, Randy Bush wrote: ... can you say does not scale? ... ... I think ISC very clearly already said that. They do not WANT it to scale. They _WANT_ DNSSEC to succeed and take over. This is a bootstrap mechanism to get DNSSEC rolling. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: wrt joao damas' DLV talk on wednesday
At 11:37 -0700 6/13/06, Randy Bush wrote: can you say does not scale? or how about works poorly when a zone is transferred? There are two ways to look at scaling. Scaling in volume and scaling across generations. DLV definitely does not scale across generations with such a person-to-person protocol backing it up. But if it's just a bootstrap mechanism, then I think it's acceptable. As far as volume scale, DLV puts more work onto whomever configures DLV repository data in resolvers. A DLV per TLD might lower the work for the TLD, and possibly remove the need to develop NSEC3 and opt-in. (As DLV only lists the DNSSEC'd zones.) i think there is no question that you and isc mean well. but we've entered the the twisty passages of security. DLV at least lets those who are able and willing to take the risk to gain first hand experience. If the ISC DLV runs for 5 years without an incident, even with the non-scalable approach as documented, it'll be seen as a winner. The longer it runs without incident, the more trustworthy it'll (appear to) be, right up until the point that it no longer scales. If there's an incident, then it won't be trusted but we will probably learn from the experience. Hopefully the lesson will come cheap. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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
can you say does not scale? Indeed. this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships. -- Paul Vixie
Re: wrt joao damas' DLV talk on wednesday
On Tue, Jun 13, 2006 at 10:27:49AM -0700, Randy Bush wrote: if other non-delegators run dlv services, they will have the same issues. Absolutely. and if you are a delegator, why play dlv as you can directly sign? I think Paul answered this question (it's because of the way DNSSEC-bis proves non-existence). I basically can't answer your other questions. I don't know the answers to most of them and don't want to guess at the others. And as for IANA applicability, I guess I'll have to give up and defer to you and DRC. It still sounds wonky to me that you would operate the root's authentication chain out-of-band like a DLV registry when in-band seems so much more useful and reliable. But clearly I don't know enough about the root's (scary) problems. when charles mussisi flies from kampala to redwood city, I think our staff in Europe are closer to Kampala than 950 Charter, and I assume at least one of them would be authorized, and I assume that there are some events somewhere that both Mr. Mussisi and some authorized member of our staff are likely to both attend. But if you would like to imagine for a moment that we actually require people to meet us in a faraday cage embedded 30 feet under the Arctic ice in an undisclosed location - just take a metal detector with you and knock on the ice when you think you've found us - then which of Paul's list of 5 other options would you prefer? Or is there a 6th? How soon can you start? That's an important open question in this dialogue. -- 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 pgpPZ8bhnevTH.pgp Description: PGP signature
Re: wrt joao damas' DLV talk on wednesday
... and alice has been working on deploying the .org DNSSEC testbed for 6 months now. Thus far my experence with deploying DNSSEC is: its just hard, not fun and for a lack of a better word... it SUCKS. In the last 6months since we deployed it, not one sole has clicked on the [now broken] _SECURE DOMAIN_ link to enable .ORG dnssec capabilities. I know we are a tiny registrar but none of our clients thought it important enough to even try clicking on the _SECURE DOMAIN_ link. So, even DLV is going to take a tremendous marketing effort to get folks to differentiate it from LOCK_DOMAIN which merely prevents the domain from being updated or transfered. DLV is a huge task so be supportive because it will probably fail just like DNSSEC is ...but we might just learn something. -rick Paul Vixie wrote: can you say does not scale? Indeed. this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
Re: wrt joao damas' DLV talk on wednesday
On Tue, 13 Jun 2006, Rick Wesson wrote: ... and alice has been working on deploying the .org DNSSEC testbed for 6 months now. Thus far my experence with deploying DNSSEC is: its just hard, not fun and for a lack of a better word... it SUCKS. In the last 6months since we deployed it, not one sole has clicked on the [now broken] _SECURE DOMAIN_ link to enable .ORG dnssec capabilities. I know we are a tiny registrar but none of our clients thought it important enough to even try clicking on the _SECURE DOMAIN_ link. So, even DLV is going to take a tremendous marketing effort to get folks to differentiate it from LOCK_DOMAIN which merely prevents the domain from being updated or transfered. DLV is a huge task so be supportive because it will probably fail just like DNSSEC is ...but we might just learn something. Not every domain out there needs what DNS-SEC can give. Not every domain out there is for a legit site, even if it will use DNS-SEC. A site that cares about its domain being verified as being the right site, would use DNS-SEC. Banks, the root servers, eCommerce, etc. Problem is, in the days of attacks against organizations being directed at users, the verifying client can be thrown aside. That said, it's less problems to fight and makes one front more secure - which is the infrastructure. Strike, that, less of a wh*re for everyone to (ab)use. Gadi. -rick Paul Vixie wrote: can you say does not scale? Indeed. this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships.
Re: wrt joao damas' DLV talk on wednesday
[EMAIL PROTECTED] (Brian McMahon) writes: why can isc not simply say we plan to vet zones as follows:. and we plan to manage maintenance of key rollover as follows: etc.? Would it help if I volunteered to talk to folks and help write something up? not at the moment. joao heard this question at the podium, and i've touched on it since then, and there doesn't seem to be any reason (yet) to assume that the answer won't be posted to www.isc.org/ops/dlv/ soon. I mean, if there's some other issue that is preventing ISC from nailing this down, then that's one thing. i believe it's called jet lag. But if it's just a case of never seems to bubble up to the top of the stack, then maybe a little outside assistance can do the trick. i don't think so. no bank in its right mind, for example, would allow its identity to be held or represented by a middleman whose security policies weren't auditable. on the other hand, joao heard this question at the podium and i don't think it's time yet to declare USC late answering it. Besides, now that the semester's over, I need something besides just firing off resumes (gotta fill that summer time, and not completely lose touch with the Real World!) to keep myself entertained. You may flame when ready, Gridley. isc depends on a lot of volunteers, i'm happy to hear of your availability and i assume that joao will also be happy to hear it when he catches up on [EMAIL PROTECTED] -- Paul Vixie
Re: wrt joao damas' DLV talk on wednesday
can you say does not scale? Indeed. this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships. so a key roll or change of delegation requires two levels of human intervention to work? randy
Re: wrt joao damas' DLV talk on wednesday
On Tue, 13 Jun 2006, Randy Bush wrote: can you say does not scale? Indeed. this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships. so a key roll or change of delegation requires two levels of human intervention to work? DNS-SEC will live and die on the business model. How user-friendly it is vs. how necessary it is against what alternatives there are. To be honest, waiting for so many years for DNS-SEC, if these questions were not answered by now... randy
Re: wrt joao damas' DLV talk on wednesday
... we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships. so a key roll or change of delegation requires two levels of human intervention to work? no. in the normal, non-DLV DNSSEC-bis model, a registrant informs its registrar of new KSK's before existing KSK's expire (or perhaps during revocation events) using the same authenticated automation they would use to change NS RRs or arrange for payment of fees or whatever. the registrar (like alice's for ISC) then tells the appropriate registry (like Afilias-PIR-UltraDNS, for .ORG) the new DS RR data using the same (EPP? RRP? fax? carrier pigeon?) authenticated automated model they would use when changing NS RR data. no human intervention at all. in the DLVified DNSSEC-bis model, the DNS registry (like VeriSign for .COM) is not yet accepting DS RR data via their EPP interface to their registrars, although i note with admiration that VeriSign has led the effort to add new EPP protocol elements to support this new data. as far as i know, no existing DNS registry will accept DS RR data. therefore registrars (like alice's... remember alice? this is a song about alice) have no place to go with registrant KSK data at this time. this in turn keeps most registrars from bothering to collect or store this useless data. ISC proposes to accept this KSK data (in the form of DLV RRs) via authenticated automated processes whereby lots of keys can be sent to us by interested/participating registrars. we do not have a good way of knowing whether somebody is or isn't the registrant for bankofamerica.com, but we think that bank of america's registrar does have a way of authenticating the registrant. and we know how to authenticate bankofamerica.com's registrar. so there IS a more scalable, untouched-by-human-hands, trust path available. until we get that working, we're left with the least desireable alternative, which is accepting keys directly from registrants, and authenticating these folks the hard way, with human hands and eyeballs. alas, i repeat myself. i've said this already. and if folks aren't going to read the explainations i really need to discipline myself into not repeating them. DNS-SEC will live and die on the business model. How user-friendly it is vs. how necessary it is against what alternatives there are. To be honest, waiting for so many years for DNS-SEC, if these questions were not answered by now... to be equally honest, i'm now weary of hearing what can't be done or shouldn't be done. anyone who wants to not do dnssec is free to do that, they don't need to shout it from the rooftop. anyone else who wants to wait until the root is signed and NSEC3 is done and automated trust key rollover is done is welcome to wait -- no shouting is required from any rooftop by those, either.
Re: wrt joao damas' DLV talk on wednesday
please reconcile no bank in its right mind, for example, would allow its identity to be held or represented by a middleman whose security policies weren't auditable. with this is why we're trying to sign up some registrars, starting with alice's, who can send us blocks of keys based on their pre-existing trust relationships. i think you might see why i am confused. do you propose to audit alice? as rick says, this is unfortunately trivial, as the signed registrations are zero sigh. btw, i fully admit that i have not thought through a detailed policy and process for a dlv registry. then again, i am not proposing to deploy one. yep, criticism is cheap. but then, i have not charged much :-). like some other technologies i'll not mention in this message, dnssec has been a typical non-deployable ivtf mis-design by committee for half the lifetime of the internet itself. [ i left a long trail of this is badly broken. someone should have listened to masataka. but have no idea if his 1/3 baked scheme would have flown. ] and i sympathize with your desire to get any useful flight milage out of the disaster. but, as this is a security service, please register your flight plan. randy
Re: wrt joao damas' DLV talk on wednesday
therefore registrars (like alice's... remember alice? this is a song about alice) have no place to go with registrant KSK data at this time. this in turn keeps most registrars from bothering to collect or store this useless data. ISC proposes to accept this KSK data (in the form of DLV RRs) via authenticated automated processes whereby lots of keys can be sent to us by interested/participating registrars. we do not have a good way of knowing whether somebody is or isn't the registrant for bankofamerica.com, but we think that bank of america's registrar does have a way of authenticating the registrant. and we know how to authenticate bankofamerica.com's registrar. so there IS a more scalable, untouched-by-human-hands, trust path available. thanks for actual technalia. ( first, i suspect much of the confusion could come from your thinking that the place up on skyline is *the* alice's restaurant. it isn't. the real one was in stockbridge, mass, and rather short-lived. so you can see why one might wonder about isc's validation methods. :-) i think if you amplified on and detailed the above, and went into how re-delegation and key changes would handled, it would go a long way to clarifying the isc dlv registry's security process. you're also welcome to use some of the cctlds and other zones i manage as outlying/strange examples. e.g. NG, which i could sign, but neither ng nor i have an established relationship to isc. and then i hope to get rid of it soon (been working with the in-country folk for five years on this, and the illumination at the end of the tunnel might be a light as opposed to a train!), and how it would be rolled would be of interest. and say psg.com, registered through retsiger, who we might assume, for sake of example, will not play. randy
Re: wrt joao damas' DLV talk on wednesday
From: Randy Bush [EMAIL PROTECTED] Date: Tue, 13 Jun 2006 15:16:50 -0700 To: Paul Vixie [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: wrt joao damas' DLV talk on wednesday therefore registrars (like alice's... remember alice? this is a song about alice) have no place to go with registrant KSK data at this time. this in turn keeps most registrars from bothering to collect or store this useless data. ISC proposes to accept this KSK data (in the form of DLV RRs) via authenticated automated processes whereby lots of keys can be sent to us by interested/participating registrars. we do not have a good way of knowing whether somebody is or isn't the registrant for bankofamerica.com, but we think that bank of america's registrar does have a way of authenticating the registrant. and we know how to authenticate bankofamerica.com's registrar. so there IS a more scalable, untouched-by-human-hands, trust path available. thanks for actual technalia. ( first, i suspect much of the confusion could come from your thinking that the place up on skyline is *the* alice's restaurant. it isn't. the real one was in stockbridge, mass, and rather short-lived. so you can see why one might wonder about isc's validation methods. :-) Actually, Paul might have been talking about Alice, Bob, and Mike. Well knows personages in cryptography circles. Alice and Bob want to exchange keys Mike is in the middle trying to figure out what alice and Bob are up to and also trying to thwart the exchange if possible. Or at the very least, gain knowledge of the keys so that Mike can read Alice's and Bob's message traffic. i think if you amplified on and detailed the above, and went into how re-delegation and key changes would handled, it would go a long way to clarifying the isc dlv registry's security process. you're also welcome to use some of the cctlds and other zones i manage as outlying/strange examples. e.g. NG, which i could sign, but neither ng nor i have an established relationship to isc. and then i hope to get rid of it soon (been working with the in-country folk for five years on this, and the illumination at the end of the tunnel might be a light as opposed to a train!), and how it would be rolled would be of interest. and say psg.com, registered through retsiger, who we might assume, for sake of example, will not play. randy --- Gregory Hicks| Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: [EMAIL PROTECTED] I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. - Benjamin Franklin The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
Re: wrt joao damas' DLV talk on wednesday
thanks for actual technalia. i've also been warned that this isn't ops-related and told to move elsewhere. ( first, i suspect much of the confusion could come from your thinking that the place up on skyline is *the* alice's restaurant. *the* alice's restaurants are the ones in our own private idaho's. i think if you amplified on and detailed the above, and went into how re-delegation and key changes would handled, it would go a long way to clarifying the isc dlv registry's security process. i feel sure that joao said at the podium that he would do that and put it on the www.isc.org/ops/dlv/ web site. so, you're just selling after the close. you're also welcome to use some of the cctlds and other zones i manage as outlying/strange examples. e.g. NG, which i could sign, but neither ng nor i have an established relationship to isc. it's possible that no trust path can be found for some domains. for example, i cannot imagine who could represent the root zone for the purpose of sending in a key for it. (not that DLV has a way to publish the root key; it doesn't; i'm just using the root as the ideal strange example of this problem.) and how it would be rolled would be of interest. key-roll through DLV is no different, from the high level, that key roll through non-DLV. either way you have to instantiate a new key and get it to your registry somehow (either through your registrar or otherwise) before you start using it. either way you have to remove your old keys after you've stopped using them. either way you'll have two keys in your key registry (either DLV or DNS) during the rollover. the only thing that changes with DLV is that you actually *have* someone to send your key to even if your DNS registrar and/or DNS registry isn't ready to accept/publish them yet. and say psg.com, registered through retsiger, who we might assume, for sake of example, will not play. anyone whose registrar won't play, will have to follow the procedure outlined on www.isc.org/ops/dlv/, which involves much manual labour, but can be done. (see http://www.isc.org/ops/dlv/#how_register in particular.)
Re: wrt joao damas' DLV talk on wednesday
therefore registrars (like alice's... remember alice? this is a song about alice) ( first, i suspect much of the confusion could come from your thinking that the place up on skyline is *the* alice's restaurant. it isn't. the real one was in stockbridge, mass, and rather short-lived. so you can see why one might wonder about isc's validation methods. :-) Actually, Paul might have been talking about Alice, Bob, and Mike. Well knows personages in cryptography circles. Alice and Bob want to exchange keys Mike is in the middle trying to figure out what alice and Bob are up to and also trying to thwart the exchange if possible. Or at the very least, gain knowledge of the keys so that Mike can read Alice's and Bob's message traffic. actually, in a brilliant demonstration of fair use of copyrighted lyrics, paul was quoting directly from the song about alice's restaurant. well, actually, despite saying so, it's not much about the restaurant at all. and the restaurant is not called alice's restaurant, that's just the name of the song. although i occasionally slum in the security community, i am not aware of a similar song about alice, bob, and mike; though i am more used to other attackers than mike. it might help if you were a 20-something in the '60s. then again, it is not helping me a lot these years. but perhaps we have gone adrift. randy
OT!!! Re: wrt joao damas' DLV talk on wednesday
On Tue, Jun 13, 2006 at 03:21:23PM -0700, Gregory Hicks wrote: From: Randy Bush [EMAIL PROTECTED] Date: Tue, 13 Jun 2006 15:16:50 -0700 To: Paul Vixie [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: wrt joao damas' DLV talk on wednesday therefore registrars (like alice's... remember alice? this is a song about alice) ... ... ( first, i suspect much of the confusion could come from your thinking that the place up on skyline is *the* alice's restaurant. it isn't. the real one was in stockbridge, mass, and rather short-lived. so you can see why one might wonder about isc's validation methods. :-) Actually, Paul might have been talking about Alice, Bob, and Mike. ... While Vixie segued into one of our old fav'rite songs from back when, he was actually originally talking about http://www.ar.com/. Look at the context. [And if Rick Wesson wasn't thinking about that song when he named the registry, and about twenty-seven eight-by-ten colour glossy pictures with circles and arrows and a paragraph on the back of each one, and a judge with a seeing-eye dog (blind justice), and the American draft, and getting injected, inspected, detected, infected, neglected, and selected, and ending the war by a movement of singers of Arlo Guthrie's song ... well then, I'll tell you, I don't know W H A T he was thinking. ;-)] -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: wrt joao damas' DLV talk on wednesday
thanks for actual technalia. i've also been warned that this isn't ops-related and told to move elsewhere. if it was not from the ml committee, tell whoever to foad. they would not know ops if it bit them on the bleep. i think if you amplified on and detailed the above, and went into how re-delegation and key changes would handled, it would go a long way to clarifying the isc dlv registry's security process. i feel sure that joao said at the podium that he would do that not really. he misunderstood my question and then waffled off into something directed at sam weiler that i think one needed to be steeped in ivtf bleep to understand. no blame. it was as if my question was off the wall, or i had stepped on a sore toe. i am good at both. it's possible that no trust path can be found for some domains. for example, i cannot imagine who could represent the root zone for the purpose of sending in a key for it. (not that DLV has a way to publish the root key; it doesn't; i'm just using the root as the ideal strange example of this problem.) how about cctlds, which are of great interest to me? i suspect that iana will not play, so how would cctlds play in way in which i can bet my bippies? and how it would be rolled would be of interest. key-roll through DLV is no different, from the high level, that key roll through non-DLV. either way you have to instantiate a new key and get it to your registry somehow (either through your registrar or otherwise) before you start using it. how do i enroll NG in a way that third parties can reasonably know is trustable? from the policy and process pov, how will we move it to a new zone set and server set when i get rid of it? similarly, how do i enroll psg.com in a way third parties can trust? how do we handshake in a clearly documented process- and key-wise exchange that gives third parties reason to be confident in the validity of the key isc hands out for psg.com? and anyone whose registrar won't play, will have to follow the procedure outlined on www.isc.org/ops/dlv/, which involves much manual labour, but can be done. (see http://www.isc.org/ops/dlv/#how_register in particular.) says not much about how things will actually be verified. only that isc will vet, i will fly, ... heck, for an org, it does not even state that corp docs of the flavors rirs use for transfers will be needed/used. i suspect that where we may be differing, other than restaurant lore, is that you may be saying the underlying technology is documented, and isc are good folk and if we say it's vetted you can trust us. problem is that, though i may want to trust isc (heck, i run isc's code!), for a security exercise, i should not. an example of some rigor in policy and process needs to be set. randy
howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
I'm ashamed to call myself a participant in NANOG, IETF and ICANN. every once in a while I get to participate in something that moves forward the network just a bit; please refrain from this thread -- a few folks are attempting to move DNSSEC ahead; we will fail, but would appreciate any constructive criticism on the pitfalls to deploy before we are all dead. -rick
re howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
I'm ashamed to call myself a participant in NANOG, IETF and ICANN. every once in a while I get to participate in something that moves forward the network just a bit; please refrain from this thread -- a few folks are attempting to move DNSSEC ahead; we will fail, but would appreciate any constructive criticism on the pitfalls to deploy before we are all dead. -rick I'm not. Consensus usually comes after the party, not before. -M -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
Re: re howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
On Tue, 13 Jun 2006, Martin Hannigan wrote: I'm not. Consensus usually comes after the party, not before. I guess you've never been to IETF ... -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
please refrain from this thread -- a few folks are attempting to move DNSSEC ahead; we will fail, but would appreciate any constructive criticism on the pitfalls to deploy before we are all dead. i am amazed that you do not consider open discussion of security policies and procedures to be used in the deployment of a security protocol to be constructive. imiho, over the years, dnssec has repeatedly suffered from not facing the reality of the sticky bits of deployment. so you may have to suffer folk discussing this, even though it may detract from dnssec marketing. randy
Interesting new spam technique - getting a lot more popular.
http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html Does seem to have potential, because at least one large webhost says they got bit hard by this (when they asked me to unblock one of their /24s) - and I've been seeing the same type of spam for quite some time [pizzabox cpanel servers running exim, but emitting porn spam with completely different hostnames and qmail headers] quote So this brings us today to a new technique reported by Stephen Satchell of satchell.net last Thursday. It reads almost like a mystery novel, involving cloaking, promiscuous interfaces, stolen IP addresses, and tunneling. It gets a little tricky, so follow the bouncing ball: * The spammer obtains a dedicated server at the victim service provider. The server shares a subnet with other customers. * A spamware daemon is installed on the dedicated server, to keep the network interface in promiscuous mode * The daemon determines which IP addresses on the local subnet are not in use. It also determines the addresses of the network routers. One or more unused IP addresses are commandeered for use by the spammer. * The perp server sends unrequested ARP responses to only the gateway routers, so that the routers never have to ask for a layer-3 to layer-2 association -- it's alway in the ARP cache of the routers. Nobody else sees this traffic in an EtherSwitch fabric, so ARPWATCH and its kin are defeated. Pings and traceroutes also fail with host unreachable.. The daemon then only has to watch on the NIC, in promiscuous mode, for TCP packets to the hijacked address on port 80, and pass them down the tunnel to the remote Web server. * Finally, GRE and IPIP tunneling is used to connect the stolen IP addresses to the spammer's real servers hosted elsewhere. The end result is that the spammer has created a server at an IP address which not even the owners of the network are aware of. There are a number of ways you can protect your own network from from this exploit: * Give each customer their own subnet. * Null-route unused IP addresses in your network space, or otherwise make sure that there's a legitimate server somewhere that will claim them. * Monitor your local network for interfaces transmitting ARP responses they shouldn't be. /quote -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Interesting new spam technique - getting a lot more popular.
On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html * Monitor your local network for interfaces transmitting ARP responses they shouldn't be. how about just mac security on switch ports? limit the number of mac's at each port to 1 or some number 'valid' ?
Re: Interesting new spam technique - getting a lot more popular.
That was not my advice btw - just forwarding on what I saw. What you say does seem like a must do all right - but putting ARP filters in is actually a reasonable idea. On 6/14/06, Christopher L. Morrow [EMAIL PROTECTED] wrote: On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html * Monitor your local network for interfaces transmitting ARP responses they shouldn't be. how about just mac security on switch ports? limit the number of mac's at each port to 1 or some number 'valid' ? -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Interesting new spam technique - getting a lot more popular.
On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: That was not my advice btw - just forwarding on what I saw. oh,. apologies, i did cut the message down quite a bit :( I understood you were quoting from the spamdiaries website, I apologize to the other listeners (readers?) if it confused the issue. What you say does seem like a must do all right - but putting ARP filters in is actually a reasonable idea. Atleast it'd trim down the 'problem' to the single customer subnet, I assume that dedicated hosting folks don't just drop machines behind a switch on one big flat subnet? That's probably a naive assumption though :( Perhaps this is clue #12 that that is a 'less than good' option? :) On 6/14/06, Christopher L. Morrow [EMAIL PROTECTED] wrote: On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html * Monitor your local network for interfaces transmitting ARP responses they shouldn't be. how about just mac security on switch ports? limit the number of mac's at each port to 1 or some number 'valid' ? -- Suresh Ramasubramanian ([EMAIL PROTECTED])
RE: Interesting new spam technique - getting a lot more popular.
It sure seems like this is a good demo of the best practice of having customers on their own VLANs with their own subnets. We have been doing this since we started offering colo services, is this less common than I thought? John -Ursprüngliche Nachricht- Von: Christopher L. Morrow [mailto:[EMAIL PROTECTED] Gesendet: Tuesday, June 13, 2006 9:23 PM An: Suresh Ramasubramanian Cc: NANOG Betreff: Re: Interesting new spam technique - getting a lot more popular. On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: That was not my advice btw - just forwarding on what I saw. oh,. apologies, i did cut the message down quite a bit :( I understood you were quoting from the spamdiaries website, I apologize to the other listeners (readers?) if it confused the issue. What you say does seem like a must do all right - but putting ARP filters in is actually a reasonable idea. Atleast it'd trim down the 'problem' to the single customer subnet, I assume that dedicated hosting folks don't just drop machines behind a switch on one big flat subnet? That's probably a naive assumption though :( Perhaps this is clue #12 that that is a 'less than good' option? :) On 6/14/06, Christopher L. Morrow [EMAIL PROTECTED] wrote: On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html * Monitor your local network for interfaces transmitting ARP responses they shouldn't be. how about just mac security on switch ports? limit the number of mac's at each port to 1 or some number 'valid' ? -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Interesting new spam technique - getting a lot more popular.
On 6/14/06, Christopher L. Morrow [EMAIL PROTECTED] wrote: Atleast it'd trim down the 'problem' to the single customer subnet, I assume that dedicated hosting folks don't just drop machines behind a switch on one big flat subnet? That's probably a naive assumption though :( Perhaps this is clue #12 that that is a 'less than good' option? :) Given the people who complained, and their traditionally spammer infested nature I wouldnt be surprised at all to find that they've put all their hosts on a flat subnet Various /24s of theirs keep getting complimentary upgrades from our filters after reaching a certain limit - based on a X IPs blocked per /24, Y /24s per /16 metric .. when that limit is reached, we automatically upgrade the blocks to cover infested /24s.
Re: Interesting new spam technique - getting a lot more popular.
On 2006-06-14-00:23:15, Christopher L. Morrow [EMAIL PROTECTED] wrote: [...] I assume that dedicated hosting folks don't just drop machines behind a switch on one big flat subnet? That's probably a naive assumption though I've long been a proponent of a per-customer VLAN or L3 interface, depending on what the topology allows for, but I'm afraid we're in the minority. From what I've seen, the overwhelming majority of dedicated hosters do precisely what the article alludes to -- placing hundreds (if not thousands!) of disparate hosts on the same broadcast domain, with no safeguards in place to prevent ARP spoofing, IP hijacking, and other forms of malfeasance... -a
Re: Interesting new spam technique - getting a lot more popular.
On Wed, 14 Jun 2006, Adam Rothschild wrote: On 2006-06-14-00:23:15, Christopher L. Morrow [EMAIL PROTECTED] wrote: [...] I assume that dedicated hosting folks don't just drop machines behind a switch on one big flat subnet? That's probably a naive assumption though I've long been a proponent of a per-customer VLAN or L3 interface, depending on what the topology allows for, but I'm afraid we're in the minority. doh :( From what I've seen, the overwhelming majority of dedicated hosters do precisely what the article alludes to -- placing hundreds (if not thousands!) of disparate hosts on the same broadcast domain, with no safeguards in place to prevent ARP spoofing, IP hijacking, and other forms of malfeasance... is it really that hard to make your foudry/extreme/cisco l3 switch vlan and subnet??? Is this a education thing or a laziness thing? Is this perhaps covered in a 'bcp' (not even an official IETF thing, just a hosters bible sort of thing) ?
Re: Interesting new spam technique - getting a lot more popular.
That’s a very good question... I was also under the assumption that most providers would have adopted new practices rather then simply dumping customers on a single subnet/vlan... unless were going back in time :P As far as the special daemon program goes.. any packet sniffer will reveal all needed information to jack an ip. I'm actually surprised that its taken spammers this long to figure out and utilize such vulnerabilities in networks... seeing how spamming is a multi billion $ industry... few ways to limit ip jackings... keep your subnets small as possible, force the use of private vlans, as a provider... you should provide a way for your clients to be able to view their traffic patterns... in case of a hijack, they would notice the increased traffic and could bring it to the providers attention sooner then later... monitor your switch ports (snmp?) for bursts of outbound traffic (bandwidth / pps)... -- Payam Chychi John van Oppen wrote: It sure seems like this is a good demo of the best practice of having customers on their own VLANs with their own subnets. We have been doing this since we started offering colo services, is this less common than I thought? John -Ursprüngliche Nachricht- Von: Christopher L. Morrow [mailto:[EMAIL PROTECTED] Gesendet: Tuesday, June 13, 2006 9:23 PM An: Suresh Ramasubramanian Cc: NANOG Betreff: Re: Interesting new spam technique - getting a lot more popular. On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: That was not my advice btw - just forwarding on what I saw. oh,. apologies, i did cut the message down quite a bit :( I understood you were quoting from the spamdiaries website, I apologize to the other listeners (readers?) if it confused the issue. What you say does seem like a must do all right - but putting ARP filters in is actually a reasonable idea. Atleast it'd trim down the 'problem' to the single customer subnet, I assume that dedicated hosting folks don't just drop machines behind a switch on one big flat subnet? That's probably a naive assumption though :( Perhaps this is clue #12 that that is a 'less than good' option? :) On 6/14/06, Christopher L. Morrow [EMAIL PROTECTED] wrote: On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html * Monitor your local network for interfaces transmitting ARP responses they shouldn't be. how about just mac security on switch ports? limit the number of mac's at each port to 1 or some number 'valid' ? -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Interesting new spam technique - getting a lot more popular.
On Wed, 14 Jun 2006, Christopher L. Morrow wrote: is it really that hard to make your foudry/extreme/cisco l3 switch vlan and subnet??? Is this a education thing or a laziness thing? Is this perhaps covered in a 'bcp' (not even an official IETF thing, just a hosters bible sort of thing) ? This problem is fixed by following the BCP regarding spoof filtering, if needed, doing the IP source filtering at the switchport instead of at the router level. Treat your colo customers the same way you would residential customers with the same security level. Whatever the customer himself can change, control. IP spoof filtering, and if your platform supports it, even rewrite the MAC address so it's local to the access cable and not used in your aggregation network (some DSLAM vendors do this, for instance). I haven't seen any switch vendors that does this yet, unfortunately. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Interesting new spam technique - getting a lot more popular.
JvO Date: Tue, 13 Jun 2006 21:35:14 -0700 JvO From: John van Oppen JvO It sure seems like this is a good demo of the best practice of JvO having customers on their own VLANs with their own subnets. We JvO have been doing this since we started offering colo services, is We actually go so far as to isolate certain services on their own subnet/VLAN. JvO this less common than I thought? I'm afraid so. I've worked on a good many networks where everything is in one VLAN; a common argument for the practice is IP assignment granularity. Rarely do I find MAC ACLs in place at the switch. (I'm actually trying to remember a specific installation that had MAC filtering set up by a prior engineer... I'm _sure_ I've encountered at least a couple.) Note that these observations are for small- and mid-sized networks. Maybe things are better in the larger networks. YMMV. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Interesting new spam technique - getting a lot more popular.
CLM Date: Wed, 14 Jun 2006 04:46:31 + (GMT) CLM From: Christopher L. Morrow CLM is it really that hard to make your foudry/extreme/cisco l3 switch vlan CLM and subnet??? Of course not. CLM Is this a education thing or a laziness thing? Both. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
