[DNSOP] review of draft-ietf-dnsop-as112-ops-00
I note that there are more ways to manage the local routing config of an AS112 node (due largely to local administrative constraints), but appreciate and prefer the simplicity and directness of defining and exampling BGP. I would like it if the fields in the example config files did not load (due to syntax errors) unless the mandatory to change fields had been updated (passwords, SOA records, etc). But I can't think of a good way to do that, without probably giving the examples a poor aesthetic. If the authors are more clever, then. I do not believe that there are any technical errors in explaining as112 deployment, and find that the advice this draft gives is all sound. I have nothing to add to it. -- David W. Hankins"If 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 pgpuw8JvUmye2.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
[DNSOP] review of draft-ietf-dnsop-as112-under-attack-help-help-00
In section 6, service (DoS) attack. In some case the source ports used by I suggest the author intended either 'in some cases' or 'in one case', and I would like to submit my claim at this time for the "Joe Abley's Typographical Error of the Year" trophy. I note that the document has failed to capture the angst and bitterness of the authors' cumulative lifetimes spent answering phonecalls from people who think as112 is 'haxing their base'. This is a feature. I am concerned that the document as read is appropriate for an IETF audience, rather than the target audience (people who think they are under attack). The ~16 year old voice-cracking operator of a network of several hundred desktops in Dallas I spoke with most recently would not get past page 1 before being distracted, and most certainly would not be able to read the 4 options described in section 7 and understand that the draft is actually recommending only one of them, and not the first one. Or maybe I don't give him enough credit. Anyway, the point is I'm not really sure this is something I would have used to explain the situation when I did field those phonecalls. It's quicker to give the short explanation, using small words, than to field a second phonecall later. I certainly would have been able to use this as additional information to support may 'claims' that I am not a 'hax', but would still have done the usual "here's what's wrong, and here's how to fix it" spiel. Honestly, the biggest timesink in these calls is just getting the caller to stop talking long enough to answer. One major point about prisoner.iana.org (covered in the other as112-ops document) is that people who complain about prisoner.iana.org are sending what is coloquially referred to (among the target audience) as 'updates', not 'queries'. I think this point is missing from this document (or I missed it), and without it I don't think the target audience can be convinced that they are doing something to cause the responses from prisoner. But, there is nothing factually wrong in this document, and my opinion of it is positive overall. I recognize that the above are matters of personal preference or taste, and would not be moved to object if the authors disagree. -- David W. Hankins"If 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 pgpqBUVLolCqE.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for
On Fri, Jul 20, 2007 at 07:45:10PM +0200, Peter Koch wrote:
> as WGLC reviewers. After the meeting, two reviews were already posted with
> general support, the only concern raised that the document might still be
> "too technical" for the target audience. There was no further discussion.
And one typo ("in some case ...").
I presume it will be remembered in editing.
> Please review the draft and comment on this list, preferrably including
> proposed text if you'd like to see changes.
I support advancing this document.
--
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
--
David W. Hankins"If you don't do it right the first time,
Software Engineeryou'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
pgpPVwuj04DuC.pgp
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Confirmation of Chicago decision on draft-anderson-reverse-dns-status
On Tue, Aug 07, 2007 at 07:00:36PM -0400, Andrew Sullivan wrote: > I note that I asked explicitly about two sets of remarks from the > -anderson- draft that the current editors thought were possible > candidates for inclusion in the current working group draft, and > received no feedback in the meeting for such inclusion. In lieu of searching the minutes for them, perhaps you could repeat them? -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins"If you don't do it right the first time, Software Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgphahh78Cbxh.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Confirmation of Chicago decision on draft-anderson-reverse-dns-status
On Fri, Aug 10, 2007 at 11:28:51AM -0400, Andrew Sullivan wrote: > Sure. They're both on slide 8 from the Chicago meeting. The first > was whether we ought to include references to RFC 1788, noting that > there were alternative proposals for how to do this. Nobody came > forward in support of this idea, and some people mentioned explicitly > that they thought it irrelevant. (My own opinion is also that it's > irrelevant, but this is a WG draft and I'm happy to be overruled.) I think that experiment is old enough (and still experimental) that to provide guidance in that direction may be a bum steer. So, I say leave it out. > The other was a bit of text lifted from section 3.6 of the -anderson- > draft, which says this: > >Delegate all addresses in block. Do not assume that everyone >uses ethernet. > > I suggested that this was a clearer and starker statement of the > principle than was anywhere in the current WG draft, and so it might > be included. There is language in the WG draft to this effect, > however. Nobody came forward in support of this proposal either. The problem is possibly more complex than 'ethernet vs everything else'. Even with ethernet, someone may want ot name their network or broadcast. I'm thinking of 9 years ago, when I encountered a problem with using the first addresses in a network delegated as a dynamic pool to dial access equipment (so, PPP). I'm getting old now, but I vaguely remember; x.y.z.0/20-or-so was routed to null0 on the routers so that they would produce ICMP unreachables (the dial access gear wouldn't, they'd pass it back to the default router!). These statics were redistributed into the IGP. x.y.z.0/32 was advertised by dial access equipment via RIP, which carried static assignments as well as dynamic. We discovered (during my 5am shift) that, with the routers we were using, we could not hold a more specific RIP route on the same division as a statically held route redistributed into our IGP. Something about having the same "name", but I really am getting too old to remember this point with any clarity. My rather long winded point here is, there are a lot of strange things in networks we can't and shouldn't presuppose. To get into them is a hairball. To overly simplify it to the point of admonishing assumptions about ethernet is disingenuous, or at least incomplete. So, I say keep or simplify the existing text. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. Hankins"If you don't do it right the first time, Software Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgplhTLPXn46n.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Reflectors are Evil was Re: Anycast was Re: Cache poisoning on DNSSEC
[For brevity, this is intended as a message in support of Joe's position. I think my original got eaten in the earlier mail server event announced on ietf@, so apologies for any duplicates.] On Tue, Sep 02, 2008 at 03:46:48PM -0400, Joe Abley wrote: > My point is that there are a large number of distributed denial of > service attacks happening every day, on a scale large enough to > involve multiple providers and cross-organisational teams for > mitigation. For informational purposes, I'd like to point out that yesterday on the NANOG mailing list, it was asserted that DNS Amplification attacks are being observed by one security worker (Gadi Evron) on a seemingly daily basis, frustrated by the lack of adoption of BCP 38 (which is proposed as the root cause). [1] Let me say that it is entirely right to suggest that in this case, if you are engaged in a dialogue of logical deduction, then in the face of the claim that something does not exist, the responsibility of argument is to prove that thing does exist, on the basis that one cannot reasonably prove non-existence of any physical object (or event) with Aristotelian tenacity. Which is problematic because such a proof (with Aristotelian tenacity) in this case would require publishing of normally witheld and guarded data in provably unaltered forms. This may not even be possible. This would appear then to be an impasse if the IETF required such tenacity. Fortunately, the IETF works on a basis of consensus among practicioners, not on a basis of Aristotelian deductive proofs of draft contents and volunteers' opinions. I'm content to agree with the other WG participants that DNS Amplification attacks do persist in the modern day, and that it is useful to write and publish a document that seeks mitigation. I hope that the WG's consensus will be so measured by the chairs. [1] - http://www.merit.edu/mail.archives/nanog/msg11131.html -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins"If you don't do it right the first time, Software Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgpSNWpTlJTMr.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns data exchanged between host and local dns-sever
On Thu, Apr 23, 2009 at 05:37:22PM +, bmann...@vacation.karoshi.com wrote: > i happen to agree w/ David here. there really is no serious technical I would generally encourage that trend. > the downsides are the LEOS (protecting our security), and the Shylocks > who need to collect what remains of the lunch money. I do not particularly disagree with your conclusion, but I believe your assessment of the 'downsides' is incomplete in at least one regard; The system in place currently has a benefit in that it is trivially simple. Very few implementations have gotten this wrong over the years, and when they have it was trivially simple to debug. Query, reply. Comparatively, DNSSEC recursive resolution is significantly more complex, and the scope of the deployment of that resolution becomes a multiplier in the costs to deploy and maintain a web of interoperating systems. That said, I think recursive resolution can and should be pushed into the end hosts, but that solution may not be universal, and it may be discovered to be intractable, so it is also wise to invest in an interim solution that can potentially be maintained for an extended period. I believe some ideas for that were mentioned already. -- David W. Hankins"If you don't do it right the first time, Software Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgpiUiPCidN8N.pgp Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
