From owner-namedroppers@ops.ietf.org Fri Jul 01 02:40:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoFCs-0006vs-EP for dnsext-archive@megatron.ietf.org; Fri, 01 Jul 2005 02:40:58 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17503 for ; Fri, 1 Jul 2005 02:40:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DoF7C-000KKV-O8 for namedroppers-data@psg.com; Fri, 01 Jul 2005 06:35:06 +0000 Received: from [193.0.1.50] (helo=localhost.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DoF78-000KJM-HU for namedroppers@ops.ietf.org; Fri, 01 Jul 2005 06:35:02 +0000 Received: by localhost.ripe.net (Postfix, from userid 4133) id 6A22C7C068; Fri, 1 Jul 2005 08:35:01 +0200 (CEST) To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Message-Id: <20050701063501.6A22C7C068@localhost.ripe.net> Date: Fri, 1 Jul 2005 08:35:01 +0200 (CEST) From: olaf@x99.ripe.net (Olaf Kolkman) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 04 12:53:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpUBy-0002bC-Dr for dnsext-archive@megatron.ietf.org; Mon, 04 Jul 2005 12:53:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11676 for ; Mon, 4 Jul 2005 12:53:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DpU5P-000Fwy-1r for namedroppers-data@psg.com; Mon, 04 Jul 2005 16:46:23 +0000 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DpU5M-000Fwe-1I for namedroppers@ops.ietf.org; Mon, 04 Jul 2005 16:46:20 +0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j64GtF4l014370 for ; Mon, 4 Jul 2005 09:55:15 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j64GogSp023189 for ; Mon, 4 Jul 2005 11:50:42 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Jul 2005 12:46:17 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316DA0@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Cc: "'Edward Lewis'" Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Date: Mon, 4 Jul 2005 12:46:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk See below at @@@ -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Wednesday, June 29, 2005 10:31 AM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org; Ed.Lewis@neustar.biz Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt This message demarcation thing is a pain ;) so I've taken the liberty of removing the old context... At 20:58 -0400 6/28/05, Eastlake III Donald-LDE008 wrote: >Well, the current criteria for these parameters in RFC 2929 is "IETF >Consensus". RFC 2434 defines that as "new assignments are made via RFCs >approved by the IESG". So any change is likely to *reduce* the theoretic >load on the IESG. As to which working group the intent is the working group >whose protocol needs the value. Either way, I think we ought to be shielding the IESG from having to make operational (in the sense of moving the bureaucracy along) decisions. OTOH, if there is no DNS WG, I am not sure the other WGs are really prepared to make DNS related decisions - and in that case it falls to the shepherding AD anyway. @@@ The IESG is where the bulk of the athority and responsibility is in the IETF. There are limits as to how far we can "shield" them and, I'm sure, limits to the extent to which they want to be cut out of things. If we make Early Allocation of these DNS code points for WGs depending on WG consensus plus AD approval, I suppose we could, for individual requests, just require approval of two ADs... >Indeed, it is specifically prohibited to have anything in a standard or any >IANA allocation process depend on the perpetual existence of any working >group. If you are worried about some random working group approving some RR >Type without it going through DNSEXT you are asking for something not possible >within IETF procedure. It would be reasonable to add a provision that the >early allocation request also be approved by the WG's AD. The way I see it, there are two options in the event of there being no sitting DNS WG. 1) With or without DNS WG, IANA is given clear instructions and guidance for situations that have not been anticipated in the allocation of parameters. This is moving the bureaucracy out of the engineering department and into the operational registry function. I'm sure we can quantify some criteria for "innocuous" RR definitions that we will be confident can be easily, transparently, and clearly followed by someone without having to get involved in a debate. 2) In the absence of a DNS WG, recognize that the WG's AD, or maybe the document's shepherding AD, is the ombudsman that will make sure suitable DNS expertise is called in. The big trouble I have with this is that the calling of an expert is rarely an open process and doesn't tend to scale very well in engineering situations. @@@ I believe the best couse is to never assume the existence of DNSSEC or any similar WG. You can assume a mailing list. So it would be reasonable to add a requirement that notice be posted to namedroppers or its successor and no action be taken until people have had two weeks to comment. @@@ I'm not too enamored for technical criteria for "innocuous" RR definitions. I'd generally oppose requiring IANA to make technical judgements. >That depends on supply and demand. Some registries are essentially infinte and >first come first served works fine as the allocation rule. The great benefit >of having Jon Postel be the judge of all these things was that he generally >had reasonable judgement and could apply varying back pressure to assignment >requests depending on the code point space left and how rapidly requests were >arriving. We now have to guess and establish rules. But what people were >complaining about was that it was too hard to get an RR Type. So whatever we >adopt had better be easier than "Specification Required" has worked out to be >in practice. I didn't know Jon Postel personally, but I know he made a strong impression on many folks still active on this list. From anecdotal evidence, I'll proffer that he was a unique person in a unique era. Would someone of his talents, entering the Internet today, be available for the same post? Back in the day, the IANA function was a place to be a pioneer. Nowadays, the chains (and budget) on it make it a place where pioneering is not to be encouraged. I'll reiterate this - I am not commenting on the way IANA's staff is operating. I am commenting on the position the community places the "critical infrastructure staffs" in - that of a place where we want them to do "the job" in a fair manner above all else. This tends to discourage staff members from sticking their necks out at a conformant by unwise request. @@@ Well, my understanding is that, to a great extent, the trend to more precise mechanical procedures for IANA was instigated at IANA's request and to minimize legal liability, not imposed at the instigation of the community. But what matters is the current situation, not the history. Relying on a personality (as opposed to a person) to do a job does not scale - not in volume nor in time. @@@ Sure it does. Everything has either one person in change, like the Administrator of the (US) Federal Aviation Agendy, or a committee, like the (US) Federal Communications Commission. If they have too much to do, they rrecruit helpers or delegate to staff. >But the problem I thought we were trying to address is that after people >implement with a number they choose, their code escapes and/or they are too >lazy to ever doing anything else about allocation, so you end up with deployed >code with random code and no central record and, sooner-or-later, conflicts. I don't think the dynamic works that way, and, above that, I don't think that is the problem we face today. I think the problem is that implementers are rightfully choosing the path of least resistance to adding data to the DNS. And that path goes right through the TXT RR and name prefixes because doing the "right thing" is a pain becuase of the bureaucratic rules *we* have laid down. @@@ Well, there are a varity of problems. The problem you list is why we want allocation to be easier. The problem I was listing is why I think we want a coordination mechanism like fairly easy early allocation. I do think that implementers, seeing their code fly off the FTP servers, do want to make an official record of it. That's the early RFCs. And I think of the time the original coder of SSH came to the SSH WG meeting and pleaded for them to change the name so he could get a trademark on SSH. Successful efforts to get capped off. OTOH, it is the unsuccessful (or limited success) cases that are a pain. For this reason, all code ought to follow the "liberal in accept, conservative on transmit" bon mot. @@@ I'm not entirely sure what you are saying here. If people can get an RFC into the RFC Editor's queue, they should be able to get a permanent typde code in the Specification Required section. >Perhaps not laxer for permanent registry entries but the Early Allocation >idea is basicaly a temporary registry entry. Quoting from RFC 4020: > 5) IANA makes an allocation from the appropriate registry, marking it > as "temporary", valid for a period of one year from the date of > allocation. The date of allocation should also be recorded in the > registry and made visible to the public. I missed the one year term. But, requiring a high bar (like IESG consent) might work out to getting a one year lease two years after the code is first developed. I would suggest that getting a one-year lease be done with a simple request to IANA (subject to denial of registry service and subscriber fraud checks), that renewal of a lease take something more - maybe even an IESG ok. (But I'd prefer to give two year leases as some engineering cycles will take longer. That's conjecture on my part.) @@@ "denial of registry service" on what basis? @@@ WG + AD approval or 2 * AD approval for individual doesn't seem that hard to me. Annual renewals don't seem like that much of a burden and would serve to remind people they are on a temporary basis and will need to firm things up. Making renewal harder than initial allocation could encourage people who think they can't yet make the higher hurdle yet but still want to persue their development to just get a new initial allocation for a new code rather than renew. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar @@@ Thanks, @@@ Donald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 05 03:37:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dphzi-0000Sw-T9 for dnsext-archive@megatron.ietf.org; Tue, 05 Jul 2005 03:37:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09774 for ; Tue, 5 Jul 2005 03:37:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DphvM-00092v-2Y for namedroppers-data@psg.com; Tue, 05 Jul 2005 07:32:56 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DphvK-00092V-E1 for namedroppers@ops.ietf.org; Tue, 05 Jul 2005 07:32:54 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id B7FDB24734; Tue, 5 Jul 2005 09:32:51 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CC7642467E for ; Tue, 5 Jul 2005 09:32:48 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j657Wmmq001070 for ; Tue, 5 Jul 2005 09:32:48 +0200 Date: Tue, 5 Jul 2005 09:32:48 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Cross Area Review: draft-ietf-hip-dns-01 Message-Id: <20050705093248.7613d225.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 2.0.0beta3 (GTK+ 2.6.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -5.9 X-RIPE-Signature: 4a0c72eb1dad7e55e628dcb60470eda8 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear colleagues, Help from this group on reviewing draft-ietf-hip-dns-01 would be highly appreciated. Also see: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00863.html -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 05 15:34:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptBT-0005Ec-PJ for dnsext-archive@megatron.ietf.org; Tue, 05 Jul 2005 15:34:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12867 for ; Tue, 5 Jul 2005 15:34:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dpt6Y-000OHi-43 for namedroppers-data@psg.com; Tue, 05 Jul 2005 19:29:14 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dpt6X-000OHO-9H for namedroppers@ops.ietf.org; Tue, 05 Jul 2005 19:29:13 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j65JT1u2016611; Tue, 5 Jul 2005 15:29:02 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316DA0@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF238109316DA0@ma19exm01.e6.bcs.mot.com> Date: Tue, 5 Jul 2005 15:29:05 -0400 To: Eastlake III Donald-LDE008 From: Edward Lewis Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Cc: namedroppers@ops.ietf.org, "'Edward Lewis'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:46 -0400 7/4/05, Eastlake III Donald-LDE008 wrote @@@: >@@@ I'm not too enamored for technical criteria for "innocuous" RR >@@@ definitions. I'd generally oppose requiring IANA to make technical >@@@ judgements. The point of documenting criteria is to avoid the need for judgements. >Relying on a personality (as opposed to a person) to do a job does >not scale - not in volume nor in time. > >@@@ Sure it does. Everything has either one person in change, like the >@@@ Administrator of the (US) Federal Aviation Agendy, or a committee, like >@@@ the (US) Federal Communications Commission. If they have too much to do, >@@@ they rrecruit helpers or delegate to staff. The difference is between a "personality" and a "person in charge." To me, "personality" generally means that the person involved is inventive, a "person in charge" is a person making sure steps are checked off - whether that's a literal bureaucratic checklist or a sketchy details list. For scaling, you want a "person in charge" (or "person responsible") and not a "personality." (There's an expression "cult of personality" but there's no "cut of 'person in charge.'") >@@@ I'm not entirely sure what you are saying here. If people can get an RFC >@@@ into the RFC Editor's queue, they should be able to get a permanent type >@@@ code in the Specification Required section. That's putting the cart in front of the horse though. >@@@ "denial of registry service" on what basis? Flooding the registry with requests to deplete the parameter space. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 06 11:06:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBUC-0004bN-0K for dnsext-archive@megatron.ietf.org; Wed, 06 Jul 2005 11:06:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07190 for ; Wed, 6 Jul 2005 11:06:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqBOQ-000FzC-Nw for namedroppers-data@psg.com; Wed, 06 Jul 2005 15:00:54 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DqBOO-000FyZ-Tm for namedroppers@ops.ietf.org; Wed, 06 Jul 2005 15:00:53 +0000 Received: from [10.31.32.78] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j66F0kkk038410; Wed, 6 Jul 2005 11:00:47 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 11:00:53 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: new version of wcard coming Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In response to a gaggle of last call comments, another version was sent to the drafts- repository. It should appear any day now. There's a table of contents, but no pagination yet...that'll come last. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 06 23:48:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNNE-0001E3-Bl for dnsext-archive@megatron.ietf.org; Wed, 06 Jul 2005 23:48:28 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00717 for ; Wed, 6 Jul 2005 23:48:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqNJK-0005Sw-2U for namedroppers-data@psg.com; Thu, 07 Jul 2005 03:44:26 +0000 Received: from [204.9.221.21] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqNJJ-0005Sc-IQ for namedroppers@ops.ietf.org; Thu, 07 Jul 2005 03:44:25 +0000 Received: from [24.52.170.51] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 423832; Wed, 06 Jul 2005 23:38:41 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 23:41:45 -0400 To: int-area@ietf.org From: Margaret Wasserman Subject: NEW!! Internet Area Mailing List Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [This message is bcc:ed to all INT area WGs, the IESG and the IAB.] Hi All, We have created an Internet Area mailing list -- int-area@ietf.org. This list will be used to announce Internet area BOFs, to discuss Internet area WG charter updates and to discuss other issues related to the Internet Area, as they arise -- such as whether we should hold an Internet area meeting in Paris. If you wish to join the list, you can do so at: https://www1.ietf.org/mailman/listinfo/int-area The archives should be available at: http://www.ietf.org/mail-archive/web/int-area/index.html (Hopefully this will be the first message in the archive). If you are interested in issues concerning the overall structure or scope of the Internet area and/or are interested in influencing how the Internet area is managed, I hope you will join this list. Thanks, Margaret -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 07 00:38:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqO9Q-0002VM-KW for dnsext-archive@megatron.ietf.org; Thu, 07 Jul 2005 00:38:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03331 for ; Thu, 7 Jul 2005 00:38:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqO6r-000BYB-4j for namedroppers-data@psg.com; Thu, 07 Jul 2005 04:35:37 +0000 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqO6o-000BXV-83 for namedroppers@ops.ietf.org; Thu, 07 Jul 2005 04:35:34 +0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j674iXJc002815 for ; Wed, 6 Jul 2005 21:44:33 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j674e0oB002440 for ; Wed, 6 Jul 2005 23:40:01 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Jul 2005 00:35:31 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316DAE@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Cc: "'Edward Lewis'" Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Date: Thu, 7 Jul 2005 00:35:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ed, I think our discussion is headed off into a philosophical direction in areas where we seem to disagree. But, I don't think resolving all these questions is necessary to come to some consensus on what should be in 2929bis. See below at ### -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Tuesday, July 05, 2005 3:29 PM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org; 'Edward Lewis' Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt At 12:46 -0400 7/4/05, Eastlake III Donald-LDE008 wrote @@@: >@@@ I'm not too enamored for technical criteria for "innocuous" RR >@@@ definitions. I'd generally oppose requiring IANA to make technical >@@@ judgements. The point of documenting criteria is to avoid the need for judgements. ### "Judgments" was probably the wrong word. Perhaps I should have said "technical assessments". If there are technical criteria, you have to either (1a) assume these criteria are absolutely unambiguous and (1b) that all applicants are absolutely honest in self assessing whether they meet those criteria, or (2) have an authority that makes technical assessments. I content that there are problems with 1. 2 isn't terrible but the current ideal for IANA is, as far as I can tell, that IANA should be able to act as a clerk. The main exception seems to be the Specification Required IANA consideration which required the technical judgment as to whether a specification is adequate for interoperability, a judgment that I suspect IANA currently refers to a technical expert they select. ### So, I'm inclined to implement technical criteria by having a template to be filled out and posted to namedroppers at least two weeks before the early allocation occurs. >Relying on a personality (as opposed to a person) to do a job does >not scale - not in volume nor in time. > >@@@ Sure it does. Everything has either one person in change, like the >@@@ Administrator of the (US) Federal Aviation Agendy, or a committee, like >@@@ the (US) Federal Communications Commission. If they have too much to do, >@@@ they rrecruit helpers or delegate to staff. The difference is between a "personality" and a "person in charge." To me, "personality" generally means that the person involved is inventive, a "person in charge" is a person making sure steps are checked off - whether that's a literal bureaucratic checklist or a sketchy details list. ### I see no binary difference, only differences in degree. The most literal bureaucratic checklist is subject to interpretation. (cf: it depends what the meaning of "is" is) For scaling, you want a "person in charge" (or "person responsible") and not a "personality." ### No matter how precise the rules, when things get big, you have to delegate authority and provide for appeals, etc. If you choose to do this in an adversarial situation, the persons to who you delegate judgment are typically called Administrative Law Judges. If you do it directly, they are usually called bureaucrats. (There's an expression "cult of personality" but there's no "cult of 'person in charge.'") >@@@ I'm not entirely sure what you are saying here. If people can get an RFC >@@@ into the RFC Editor's queue, they should be able to get a permanent type >@@@ code in the Specification Required section. That's putting the cart in front of the horse though. ### Right, it seems clear that people want an easier way to get at least a temporary Early Allocation than Specification Required. >@@@ "denial of registry service" on what basis? Flooding the registry with requests to deplete the parameter space. ### Well, that's one thing you could do but there are others. Generally bureaucracies need a mean to defend themselves from abuse of process. Another example of a requirement for judgment. Perhaps you would deny the bureaucrat such direct authority but they at least need to decide when it is a reasonable to appeal to higher authority to determine is some action is an abuse of process. A case that comes to mind is where people inundated land registries in the western US with federal mineral rights claims (like tens of thousands of them). Despite clear regulations requiring the registries to process these, they ignored them, when to court, and generally got court orders backing them up and ordering the filers to cease. ### Trying to specify too much detail sometimes just ties you in knots. ### Donald -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 07 09:46:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWiN-0000KD-QC for dnsext-archive@megatron.ietf.org; Thu, 07 Jul 2005 09:46:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07636 for ; Thu, 7 Jul 2005 09:46:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqWdc-000PT1-DV for namedroppers-data@psg.com; Thu, 07 Jul 2005 13:42:00 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DqWda-000PSG-5E for namedroppers@ops.ietf.org; Thu, 07 Jul 2005 13:41:58 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j67Dfnil002410; Thu, 7 Jul 2005 09:41:50 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316DAE@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF238109316DAE@ma19exm01.e6.bcs.mot.com> Date: Thu, 7 Jul 2005 09:41:54 -0400 To: Eastlake III Donald-LDE008 From: Edward Lewis Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Cc: namedroppers@ops.ietf.org, "'Edward Lewis'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 0:35 -0400 7/7/05, Eastlake III Donald-LDE008 wrote: >I think our discussion is headed off into a philosophical direction in areas >where we seem to disagree. But, I don't think resolving all these questions >is necessary to come to some consensus on what should be in 2929bis. The questions for the document are: Can we allow coders to burn a number into code early in the development cycle and then lock that same number into the registry after review? What is the review? Who does it, what is looked at, how is it make public (so no other coders pick the same number)? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 07 10:20:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXEy-0003fY-N5 for dnsext-archive@megatron.ietf.org; Thu, 07 Jul 2005 10:20:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11269 for ; Thu, 7 Jul 2005 10:20:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqXCF-0004c7-Tw for namedroppers-data@psg.com; Thu, 07 Jul 2005 14:17:47 +0000 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DqXCD-0004be-54 for namedroppers@ops.ietf.org; Thu, 07 Jul 2005 14:17:45 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j67EHeSS010341; Thu, 7 Jul 2005 07:17:40 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j67EHeON010338; Thu, 7 Jul 2005 07:17:40 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 7 Jul 2005 07:17:40 -0700 (PDT) From: "william(at)elan.net" To: Edward Lewis cc: Eastlake III Donald-LDE008 , namedroppers@ops.ietf.org Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt In-Reply-To: Message-ID: References: <62173B970AE0A044AED8723C3BCF238109316DAE@ma19exm01.e6.bcs.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 7 Jul 2005, Edward Lewis wrote: > At 0:35 -0400 7/7/05, Eastlake III Donald-LDE008 wrote: > >> I think our discussion is headed off into a philosophical direction in >> areas >> where we seem to disagree. But, I don't think resolving all these questions >> is necessary to come to some consensus on what should be in 2929bis. > > The questions for the document are: > > Can we allow coders to burn a number into code early in the development cycle > and then lock that same number into the registry after review? Not for internal testing within one organization. But if they want their code used in experimental way by multiple parties on the internet than they should be allowed to do it. And note that experimental should not mean published experimental RFC but I think we should at least expect internet draft or some other similar type document publicly available. > What is the review? Who does it, what is looked at, how is it make public > (so no other coders pick the same number)? One way is to require them to register the number in provisional way (with very quick - within 30 days registration by IANA for very limited period), but provisional registration would be very brief, something like 6-12 months and continuing provisional registration longer then that could require technical review (which IANA can designate and would expect to be either namedroppers or if this WG is closed then some other appropriate WG or maybe directorate within IETF). BTW - These are all just some idea to though in for discussion... -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 07 10:48:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXfj-0001Ci-MP for dnsext-archive@megatron.ietf.org; Thu, 07 Jul 2005 10:48:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14040 for ; Thu, 7 Jul 2005 10:48:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqXbr-0007je-BX for namedroppers-data@psg.com; Thu, 07 Jul 2005 14:44:15 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DqXbm-0007is-Il for namedroppers@ops.ietf.org; Thu, 07 Jul 2005 14:44:12 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j67EhvfX002704 for ; Thu, 7 Jul 2005 10:43:57 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j67Ehv9C002703 for namedroppers@ops.ietf.org; Thu, 7 Jul 2005 10:43:57 -0400 (EDT) (envelope-from namedroppers) Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqUU4-00092B-Ls for namedroppers@ops.ietf.org; Thu, 07 Jul 2005 11:24:01 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 96DAE242AF; Thu, 7 Jul 2005 13:23:48 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CBFD224539; Thu, 7 Jul 2005 13:23:45 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j67BNjmq008574; Thu, 7 Jul 2005 13:23:45 +0200 Date: Thu, 7 Jul 2005 13:23:45 +0200 From: "Olaf M. Kolkman" To: Pekka Nikander , Julien Laganier Cc: namedroppers@ops.ietf.org Subject: Re: Cross Area Review: draft-ietf-hip-dns-01 Message-Id: <20050707132345.6e2f4f5c.olaf@ripe.net> In-Reply-To: <20050705093248.7613d225.olaf@ripe.net> References: <20050705093248.7613d225.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 2.0.0beta3 (GTK+ 2.6.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_50 X-RIPE-Spam-Status: U 0.496110 / -3.3 X-RIPE-Signature: 5a7cc1b5bafac12a3e03f22b96a91f91 X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Tue, 5 Jul 2005 09:32:48 +0200 olaf wrote to namedroppers: > > Help from this group on reviewing draft-ietf-hip-dns-01 would be highly > appreciated. Hello Julian and Pekka, I've CC-ed namedroppers to avoid to much duplication of effort. I'v read your document and most issues are "style" issues. I have not read the other HIP docs recently and I tried to understand this document as "self-contained", some of my remarks come from that. There are some "real" DNS issues that can be easilly dealth with. I've tried to provide document text wherever I could. Comments are in-line. I've tried to mark my comments starting with on lines with "*" Albeit the comments this is a very readable and complete document, congrats! --Olaf HIP Working Group P. Nikander Internet-Draft Ericsson Research Nomadic Lab Expires: August 21, 2005 J. Laganier LIP / Sun Microsystems February 20, 2005 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions draft-ietf-hip-dns-01 * (...) Abstract This document specifies two new resource records (RRs) for the Domain Name System (DNS), and how to use them with the Host Identity Protocol (HIP). These RRs allow a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Name or IP addresses of its Rendezvous Servers * (...) 1. Introduction This document specifies two new resource records (RRs) for the Domain Name System (DNS) [1], and how to use them with the Host Identity Protocol (HIP) [10]. These RRs allow a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its HI), and the Domain Name or IP addresses of its Rendezvous Servers (RVS) [13]. The current Internet architecture defines two global namespaces: IP addresses and domain names. The Domain Name System provides a two way lookup between these two namespaces. The HIP architecture [11] defines a new third namespace, called the Host Identity Namespace. This namespace is composed of Host Identifiers (HI) of HIP nodes. The Host Identity Tag (HIT) is one representation of an HI. This representation is obtained by taking the output of a secure hash function applied to the HI, truncated to the IPv6 address size. HITs are supposed to be used in the place of IP addresses within most ULPs and applications. +-----+ +-----+ | |-------I1------>| | | I |<------R1-------| R | | |-------I2------>| | | |<------R2-------| | +-----+ +-----+ The Host Identity Protocol [10] allows two HIP nodes to establish together a HIP Association. A HIP association is bound to the nodes HIs rather than to their IP address(es). * STYLE: At first reading this confused me a bit. The diagram above * commes out of the blue and is not refered to. I would rephrase this * a bit. And explain the I1, I2. * Something like: * The Host Identity Protocol [10] allows two HIP nodes to establish * together a HIP Association. A HIP association is bound to the * nodes HIs rather than to their IP address(es). * A HIP node initiates a HIP association through a 4 way handshake * where two parties, the Initiatior and Responder, exchange of I1, * I2, R1 and R2 HIP packets (see section 5.3 of [10]) * * * +-----+ +-----+ * | |-------I1------>| | * | I |<------R1-------| R | * | |-------I2------>| | * | |<------R2-------| | * +-----+ +-----+ Although a HIP node can initiate HIP communication "opportunistically", i.e., without a priori knowledge of its peer's HI, doing so exposes both endpoints to Man-in-the-Middle attacks on the HIP handshake and its cryptographic protocol. Hence, there is a desire to gain knowledge of peers' HI before applications and ULPs initiate communication. Because many applications use the Domain Name System [1] to name nodes, DNSSEC [3] is a straightforward way to * STYLE: I would not say "DNSSEC" is a straightforward way. * DNS is a straightforward way to provision nodes provision nodes with * the HIP informations (i.e. HI and possibly RVS) of nodes named in * the DNS tree, without introducing or relying on an additional piece * of infrastructure. Note that without DNSSEC[3] the * Man-in-the-Middle attack to privide a false HI has moved from the * HIP handshake to the DNS name resolution, also see . Nikander & Laganier Expires August 21, 2005 [Page 3] Internet-Draft HIP DNS Extensions February 2005 * * STYLE: move the diagram down a bit * The proposed HIP multi-homing mechanisms [12] allow a node to dynamically change its set of underlying IP addresses while maintaining IPsec SA and transport layer session survivability. The HIP rendezvous extensions [13] proposal allows a HIP node to maintain HIP reachability while it is changing its current location (the node IP address(es)). This rendezvous service is provided by a third party, the node's Rendezvous Server (RVS). * moved to here: +-----+ +--I1--->| RVS |---I1--+ | +-----+ | | v +-----+ +-----+ | |<------R1-------| | | I |-------I2------>| R | | |<------R2-------| | +-----+ +-----+ An initiator (I) willing to establish a HIP association with a responder (R) would typically initiate a HIP exchange by sending an I1 towards the RVS IP address rather than towards the responder IP address. Then, the RVS, noticing that the receiver HIT is not its own, but the HIT of a HIP node registered for the rendezvous Service, would relay the I1 to the responder. Typically the responder would then complete the exchange without further assistance from the RVS by sending an R1 directly to the initiator IP address. Currently, most of the Internet applications that need to communicate with a remote host first translate a domain name (often obtained via user input) into one or more IP address(es). This step occurs prior to communication with the remote host, and relies on a DNS lookup. With HIP, IP addresses are expected to be used mostly for on-the-wire communication between end hosts, while most ULPs and applications uses HIs or HITs instead (ICMP might be an example of an ULP not using them). Consequently, we need a means to translate a domain name into an HI. Using the DNS for this translation is pretty straightforward: We define a new HIPHI (HIP HI) resource record. Upon query by an application or ULP for a FQDN -> IP lookup, the resolver would then additionally perform an FQDN -> HI lookup, and use it to construct the resulting HI -> IP mapping (which is internal to the HIP layer). The HIP layer uses the HI -> IP mapping to translate HIs and their local representations (HITs, IPv4 and IPv6-compatible LSIs) into IP addresses and vice versa. This draft introduces the following new DNS Resource Records: - HIPHI, for storing Host Identifiers and Host Identity Tags - HIPRVS, for storing rendezvous server information Nikander & Laganier Expires August 21, 2005 [Page 4] Internet-Draft HIP DNS Extensions February 2005 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [4]. Nikander & Laganier Expires August 21, 2005 [Page 5] Internet-Draft HIP DNS Extensions February 2005 3. Usage Scenarios In this section, we briefly introduce a number of usage scenarios where the DNS is useful with the Host Identity Protocol. With HIP, most application and ULPs are unaware of the IP addresses used to carry packets on the wire. Consequently, a HIP node could take advantage of having multiple IP addresses for fail-over, redundancy, mobility, or renumbering, in a manner which is transparent to most ULPs and applications (because they are bound to HIs, hence they are agnostic to these IP address changes). In these situations, a node wishing to be reachable by reference to its FQDN should store the following informations in the DNS: * STYLE: allready introduce the RRs * o A set of IP address(es) through A and AAAA RRs * o A Host Identity (HI) and/or Host Identity Tag (HIT) through HIPHI * RRs * o An IP address or DNS name of its Rendezvous Server(s) (RVS) * through HIPRVS RRs When a HIP node wants to initiate a communication with another HIP node, it first needs to perform a HIP base exchange to set-up a HIP association towards its peer. Although such an exchange can be initiated opportunistically, i.e., without a priori knowledge of the responder's HI, by doing so both nodes knowingly risk man-in-the-middle attacks on the HIP exchange. To prevent these attacks, it is recommended that the initiator first obtain the HI of the responder, and then initiate the exchange. This can be done, for example, through manual configuration or DNS lookups. Hence, a new HIPHI RR is introduced. When a HIP node is frequently changing its IP address(es), the dynamic DNS update latency may prevent it from publishing its new IP address(es) in the DNS. For solving this problem, the HIP architecture introduces Rendezvous Servers (RVS). A HIP host uses a Rendezvous Server as a Rendezvous point, to maintain reachability with possible HIP initiators. Such a HIP node would publish in the DNS its RVS IP address or DNS name in a HIPRVS RR, while keeping its RVS up-to-date with its current set of IP addresses. * STYLE: I had to read this a couple of times. And what could be useful in * this stage of the document is to discribe the "query" behaviour for * the Initiator. * * * I'd replace the following paragraph Then, when some other node wants to initiate a HIP exchange with such a responder, it retrieves the RVS IP address by looking up a HIPRVS RR at the FQDN of the responder, and sends an I1 to this IP address. The I1 will then be relayed by the RVS to the responder, which will then complete the HIP exchange, either directly or via the RVS [13]. * by [and I hope I have correcty understood this]: * When an some HIP node wants to initiate a HIP exchange with a * responder it will perform a number of DNS lookups. * First the initiator will need to query for an A or AAAA record at * the responders FQDN. * * If the query for the A and/or AAAA was responded to with a DNS * answer with RCOCE=3 (Name Error) than the responder's information * is not present in the DNS and further queries SHOULD not be made. * * In case the query for the address records returned a a DNS answer * with RCODE=0 (No Error) the initiator sends out two queries. One * for the HIPHI and one for the HIPRSV type at the responders FQDN. * * Depending on the combinations of answer the situations described in * 3.1, 3.2 and 3.3 can occur. * [See text suggestions there too] * [From the diagrams I get the impression that you would like to * receive all this information through one query. That is not * possible. The "ANY" query is not suitable. I can explain if were not * aware of this] Note that storing HIP RR information in the DNS at a FQDN which is assigned to a non-HIP node might have ill effects on its reachability by HIP nodes. Nikander & Laganier Expires August 21, 2005 [Page 6] Internet-Draft HIP DNS Extensions February 2005 3.1 Simple static singly homed end-host * Moved the paragraph up A HIP node (R) with a single static network attachment, wishing to be reachable by reference to its FQDN (www.example.com), would store in the DNS, in addition to its IP address(es) (IP-R), its Host Identity (HI-R) in a HIPHI resource record. * The initiator would issue the following queries * * QNAME=www.example.com, QTYPE=A * * returned a DNS packet with RCODE=0 and one or more RRs A record * with the address of the responder (IP-R) in the answer section. * * QNAME=www.example.com, QTYPE=HIPHI * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPHI RRs with * the HIT and HI of the responder in the answer section. * * QNAME=www.example.com, QTYPE=HIPRSV * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and an empty answer section. [A? HIPRVS? HIPHI?] [www.example.com ] +-----+ +-------------------------------->| | | | DNS | | +-------------------------------| | | | [A? HIPRVS? HIPHI? ] +-----+ | | [www.example.com ] | | [A IP-R ] | | [HIPHI 10 3 2 HIT-R HI-R] | v +-----+ +-----+ | |--------------I1------------->| | | I |<-------------R1--------------| R | | |--------------I2------------->| | | |<-------------R2--------------| | +-----+ +-----+ Nikander & Laganier Expires August 21, 2005 [Page 7] Internet-Draft HIP DNS Extensions February 2005 3.2 Mobile end-host *Moved: A mobile HIP node (R) wishing to be reachable by reference to its FQDN (www.example.com) would store in the DNS, possibly in addition to its IP address(es) (IP-R), its HI (HI-R) in a HIPHI RR, and the IP address(es) of its Rendezvous Server(s) (IP-RVS) in HIPRVS resource record(s). The mobile HIP node also need to notify its Rendezvous Servers of any change in its set of IP address(es). * The initiator would go through the following DNS queries/answers: * * QNAME=www.example.com, QTYPE=A * * returned a DNS packet with RCODE=0 and one or more RRs A record * with the address of the responder (IP-R) in the answer section. * * QNAME=www.example.com, QTYPE=HIPHI * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPHI RRs with * the HIT and HI of the responder in the answer section. * * QNAME=www.example.com, QTYPE=HIPRSV * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPRSV RRs containing * an the FQDN or IP address of the RSV. [A? HIPRVS? HIPHI?] [www.example.com ] +-----+ +--------------------------------->| | | | DNS | | +--------------------------------| | | | [A? HIPRVS? HIPHI? ] +-----+ | | [www.example.com ] | | [HIPRVS 1 2 IP-RVS ] | | [HIPHI 10 3 2 HIT-R HI-R] | | | | +-----+ | | +------I1----->| RVS |-----I1------+ | | | +-----+ | | | | | | | | | | v | v +-----+ +-----+ | |<---------------R1------------| | | I |----------------I2----------->| R | | |<---------------R2------------| | +-----+ +-----+ A host wanting to reach this mobile host would then send an I1 to one of its RVS. Following, the RVS will relay the I1 up to the mobile node, which will complete the HIP exchange. Nikander & Laganier Expires August 21, 2005 [Page 8] Internet-Draft HIP DNS Extensions February 2005 3.3 Mixed Scenario * Moved up A HIP node might be configured with more than one IP address (multi-homed), or Rendezvous Server (multi-reachable). In these cases, it is possible that the DNS returns multiples A or AAAA RRs, * s/multiples/multiple as well as HIPRVS containing one or multiple Rendezvous Servers. In addition to its set of IP address(es) (IP-R1, IP-R2), a multi-homed end-host would store in the DNS its HI (HI-R) in a HIPHI RR, and possibly the IP address(es) of its RVS(s) (IP-RVS1, IP-RVS2) in HIPRVS RRs. * For example: * QNAME=www.example.com, QTYPE=A (QCLASS=IN is assumed and * ommitted from the examples) * * returned a DNS packet with RCODE=0 and one or more RRs A record * with the address of the responder (IP-R) in the answer section. * * QNAME=www.example.com, QTYPE=HIPHI * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPHI RRs with * the HIT and HI of the responder in the answer section. * * QNAME=www.example.com, QTYPE=HIPRSV * (QCLASS=IN is assumed and ommitted from the examples) * * Returned a DNS packet with RCODE=0 and one or more HIPRSV RRs containing * an the FQDN or IP address of the RSV. [A? HIPRVS? HIPHI?] [www.example.com ] +-----+ +--------------------------------->| | | | DNS | | +--------------------------------| | | | [A? HIPRVS? HIPHI? ] +-----+ | | [www.example.com ] | | [A IP-R1 ] | | [A IP-R2 ] | | [HIPRVS 1 2 IP-RVS1 ] | | [HIPRVS 1 2 IP-RVS2 ] | | [HIPHI 10 3 2 HIT-R HI-R] | | | | +------+ | | +-----I1----->| RVS1 |------I1------+ | | | +------+ | | v | v +-----+ +-----+ | |---------------I1------------->| | | | | | | I |<--------------R1--------------| R | | |---------------I2------------->| | | |<--------------R2--------------| | +-----+ +-----+ | ^ | +------+ | +-----I1----->| RVS2 |------I1------+ +------+ Nikander & Laganier Expires August 21, 2005 [Page 9] Internet-Draft HIP DNS Extensions February 2005 4. Overview of using the DNS with HIP 4.1 Storing HI and HIT in DNS Any conforming implementation may store Host Identifiers in a DNS HIPHI RDATA format. An implementation may also store a HIT along with its associated HI. If a particular form of an HI or HIT does not already have a specified RDATA format, a new RDATA-like format SHOULD be defined for the HI or HIT. 4.1.1 Different types of HITs * It would be good to indicate where those HIT types are described that would * help implementors: * Currently [REF] defines two types of HITs more HIT types may be * defined in the future; HIT types are maintained in the IANA registry * called "foo" There are _currently_ two types of HITs. HITs of the first type consists just of the least significant bits of the hash of the public key. HITs of the second type consist of a binary prefix Host Assigning Authority (HAA) field, and only the last bits come from a hash of the Host Identity. This latter format for HIT is recommended for 'well known' systems. It is possible to support a resolution mechanism for these names in directories like DNS. * this confuses me a bit... "a resolution mechanism for these names in * directories like DNS". I read it as that those names are mapped into some * domain, like IP5 into in-addr.arpa. But I do not think that is what you mean. * I'd remove the last sentence. * * If I am not mistaken than I think that the next sentence could be less * ambiguously phrased as: * Note that the format how HITs are stored in the HIPHI RRs may be (...) Note that the format how HITs are stored in the DNS may be different form the format actually used in protocols, the HIP base exchange [10] included. This is because the DNS RR explicitly contains the HIT type and algorithm, while some protocols may prefer to use a prefix to indicate the HIT type. The implementations are expected to use the actual HI when comparing Host Identities. 4.1.1.1 Host Assigning Authority (HAA) field The 64 bits of HAA supports two levels of delegation. The first is a registered assigning authority (RAA). The second is a registered identity (RI, commonly a company). The RAA is 24 bits with values assign sequentially by ICANN. The RI is 40 bits, also assigned sequentially but by the RAA. * 4.1.1.2 Storing HAA in HITHI Resource Records. 4.1.1.2 Storing HAA in DNS Any conforming implementation may store a domain name Host Assigning Authority (HAA) in a DNS HIPHI RDATA format. A HAA MUST be stored like a Type 2 HIT, while the least significant bits of the HIT extracted from the HI hash output are set to zero, the Host Identity Length is set zero, and the Host Identity field is omitted. If a particular form of a HAA does not already have an associated HIT specified RDATA format, a new RDATA-like format SHOULD be defined for the HIT/HAA. Nikander & Laganier Expires August 21, 2005 [Page 10] Internet-Draft HIP DNS Extensions February 2005 4.1.1.3 HI and HIT verification Upon return of a HIPHI RR, a host MUST always calculate the HI-derivative HIT to be used in the HIP exchange, as specified in the HIP architecture [11], while the HIT possibly embedded along SHOULD only be used as an optimization (e.g. table lookup). 4.2 Storing Rendezvous Servers in the DNS The HIP Rendezvous server (HIPRVS) resource record indicates an address or a domain name of a RendezVous Server, towards which a HIP I1 packet might be sent to trigger the establishment of an association with the entity named by this resource record [13]. An RVS receiving such an I1 would then relay it to the appropriate responder (the owner of the I1 receiver HIT). The responder will then complete the exchange with the initiator, typically without ongoing help from the RVS. Any conforming implementation may store Rendezvous Server's IP address(es) or DNS name in a DNS HIPRVS RDATA format. If a particular form of a RVS reference does not already have a specified RDATA format, a new RDATA-like format SHOULD be defined for the RVS. 4.3 Initiating connections based on DNS names On a HIP node, a Host Identity Protocol exchange SHOULD be initiated whenever an Upper Layer Protocol attempt to communicate with an entity and the DNS lookup returns HIPHI and/or HIPRVS resource records. If a DNS lookup returns one or more HIPRVS RRs and no A nor AAAA RRs, the afore mentioned HIP exchange SHOULD be initiated towards one of these RVS [10]. Since some hosts may choose not to have HIPHI information in DNS, hosts MAY implement support for opportunistic HIP. Nikander & Laganier Expires August 21, 2005 [Page 11] Internet-Draft HIP DNS Extensions February 2005 5. Storage Format 5.1 HIPHI RDATA format The RDATA for a HIPHI RR consists of a HIT type, an algorithm type, a HIT, and a public key. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HIT type | HIT algorithm | PK algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIT | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / Public Key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 5.1.1 HIT type format The HIT type field indicates the Host Identity Tag (HIT) type and the implied HIT format. The following values are defined: 0 No HIT is present 1 A Type 1 HIT is present 2 A Type 2 HIT is present 3-6 Unassigned 7 A HAA is present 5.1.2 HIT algorithm format The HIT algorithm indicates the hash algorithm used to generate the Host Identity Tag (HIT) from the HI. The following values are defined: 0 Reserved 1 SHA1 2-255 Unassigned 5.1.3 PK algorithm format The PK algorithm field indicates the public key cryptographic Nikander & Laganier Expires August 21, 2005 [Page 12] Internet-Draft HIP DNS Extensions February 2005 algorithm and the implied public key field format. This document reuse the values defined for the 'algorithm type' of the IPSECKEY RR [14] 'gateway type' field. The presently defined values are given only informally: 1 A DSA key is present, in the format defined in RFC2536 [5]. 2 A RSA key is present, in the format defined in RFC3110 [6]. 5.1.4 HIT format There's currently two types of HITs, and a single type of HAA. Both of them are stored in network byte order within a self-describing variable length wire-encoded (as per Section 3.3 of [2]): o A *Type 1* HIT: least significant bits of the hash (e.g., SHA1) of the public key (Host Identity), which is possibly following in the HIPHI RR. o A *Type 2* HIT: binary prefix (HAA) concatenated with a the least significant bits of the hash (e.g., SHA1) of the public key (Host Identity), which is possibly following in the HIPHI RR. o A HAA: binary prefix (HAA) concatenated with 0, up to the associated HIT length. 5.1.5 Public key format Both of the public key types defined in this document (RSA and DSA) reuse the public key formats defined for the IPSECKEY RR [14] (which in turns contains the algorithm-specific portion of the KEY RR RDATA, all of the KEY RR DATA after the first four octets, corresponding to the same portion of the KEY RR that must be specified by documents that define a DNSSEC algorithm). In the future, if a new algorithm is to be used both by IPSECKEY RR and HIPHI RR, it would probably use the same public key encodings for both RRs. Unless specified otherwise, the HIPHI public key field would use the same public key format as the IPSECKEY RR RDATA for the corresponding algorithm. The DSA key format is defined in RFC2536 [5]. The RSA key format is defined in RFC3110 [6] and the RSA key size limit (4096 bits) is relaxed in the IPSECKEY RR [14] specification. 5.2 HIPRVS RDATA format The RDATA for a HIPRVS RR consists of a preference value, a Nikander & Laganier Expires August 21, 2005 [Page 13] Internet-Draft HIP DNS Extensions February 2005 Rendezvous server type and either one or more Rendezvous server address, or one Rendezvous server domain name. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preference | type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rendezvous server | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2.1 Preference format * This is problematic. If you require the server to return data based * on preference than you expect the server to understand and parse all * the RDATA before shuffing it on the wire. That sort of special * processing is expensive. It is the DNS client that should do the * work, that scales better too. * I reworded the paragraph a bit: This is an unsigned 8-bit value, used to specify the preference given to the RSV in the HIPRSV RR amongst others at the same owner. RSVs with lower values are preferred. If there is a tie within some RR subset, the initiating HIP host should pick one of the RSV randomly from the set of RRs, such that the requester load is fairly balanced amongst all RSVs of the set. 5.2.2 Rendezvous server type format The Rendezvous server type indicates the format of the information stored in the Rendezvous server field. This document reuses the type values for the 'gateway type' field of the IPSECKEY RR [14]. The presently defined values are given only informally: 1. One or more 4-byte IPv4 address(es) in network byte order are present. 2. One or more 16-byte IPv6 address(es) in network byte order are present. 3. One or more variable length wire-encoded domain names as described in section 3.3 of RFC1035 [2]. The wire-encoded format is self-describing, so the length is implicit. The domain names MUST NOT be compressed. 5.2.3 Rendezvous server format The Rendezvous server field indicates one or more Rendezvous Server(s) IP address(es), or domain name(s). A HIP I1 packet sent to any of these RVS would reach the entity named by this resource record. This document reuses the format used for the 'gateway' field of the IPSECKEY RR [14], but allows to concatenate several IP (v4 or v6) Nikander & Laganier Expires August 21, 2005 [Page 14] Internet-Draft HIP DNS Extensions February 2005 addresses. The presently defined formats for the data portion of the Rendezvous server field are given only informally: o One or more 32-bit IPv4 address(es) in network byte order. o One or more 128-bit IPv6 address(es) in network byte order. o One or more variable length wire-encoded domain names as described in section 3.3 of RFC1035 [2]. The wire-encoded format is self-describing, so the length is implicit. The domain names MUST NOT be compressed. Nikander & Laganier Expires August 21, 2005 [Page 15] Internet-Draft HIP DNS Extensions February 2005 6. Presentation Format This section specifies the representation of the HIPHI and HIPRVS RR in a zone data master file. 6.1 HIPHI Representation The HIT Type, HIT algorithm, PK algorithm, and Public Key are REQUIRED. The HIT field is OPTIONAL. * I think that is not correctly phrased. It either contains Base64 data * or a "." but it is always there. The HIT Type, HIT algorithm, and PK algorithm are represented as unsigned integers. The HIT field is represented as the Base16 encoding [8] (a.k.a. hex or hexadecimal) of the public key. If no HIT is to be indicated, then the HIT algorithm MUST be zero and the HIT field must be ".". * I'd add '(a single dot character)' there will always be folk that * read such spec as 'a double-quote, a dot and a double quote' (I've * been there and I've done it, I'm affraid to confess :-) The Public Key field is represented as the Base64 encoding [8] of the public key. The complete representation of the HPIHI record is: IN HIPHI ( hit-type hit-algorithm pk-algorithm base16-encoded-hit base64-encoded-public-key ) * Since the HIT is rather short and the public key can become a beast. I'd say * whitespace is not allowed in the base16-encoded-hit while whitespace * is ignored in the base64-encoded-public-key 6.2 HIPRVS Representation The Preference and RVS Type fields are REQUIRED. At least one RVS field MUST be present. The HIT Type, HIT algorithm, and PK algorithm are represented as unsigned integers. The RVS field is represented by one or more: o IPv4 dotted decimal address(es) o IPv6 colon hex address(es) o uncompressed domain name(s) The complete representation of the HPIRVS record is: IN HIPRVS ( preference rendezvous-server-type rendezvous-server[1] ... rendezvous-server[n] ) Nikander & Laganier Expires August 21, 2005 [Page 16] Internet-Draft HIP DNS Extensions February 2005 6.3 Examples Example of a node with a HI but no HIT: www.example.com IN HIPHI ( 0 1 2 . AB3NzaC1kc3MAAACBAOBhKnTCPOuFBzZQX/N3O9dm9P9ivUIMoId== ) * With the ignore whitespace clause above you can actually sattisfy the * 72 characters ID criteria :-) * * www.example.com IN HIPHI ( 0 1 2 * . * AB3NzaC1kc3MAAACBAOBhKn * TCPOuFBzZQX/N3O9dm9P9iv * UIMoId== ) * Example of a node with a HI and a HIT: www.example.com IN HIPHI ( 1 1 2 120cf10ea842e0ba53320f1fe0ba5d3a3 AB3NzaC1kc3MAAACBAOBhKnTCPOuFBzZQX/N3O9dm9P9ivUIMoId== ) Example of a node with an IPv6 RVS: www.example.com IN HIPRVS ( 10 2 2001:0db8:0200:1:20c:f1ff:fe0b:a533 ) Example of a node with three IPv4 RVS: www.example.com IN HIPRVS ( 10 1 192.0.2.2 192.0.99.2 192.0.199.2) Example of a node with two named RVS: www.example.com IN HIPRVS ( 10 3 rvs.uk.example.com rvs.us.example.com ) Nikander & Laganier Expires August 21, 2005 [Page 17] Internet-Draft HIP DNS Extensions February 2005 7. Retrieving Multiple HITs and IPs from the DNS If a host receives multiple HITs in a response to a DNS query, those HITs MUST be considered to denote a single service, and be semantically equivalent from that point of view. When initiating a base exchange with the denoted service, the host SHOULD be prepared to accept any of HITs as the peer's identity. A host MAY implement this by using the opportunistic mode (destination HIT null in I1), or by sending multiple I1s, if needed. In particular, if a host receives multiple HITs and multiple IP addresses in response to a DNS query, the host cannot know how the HITs are reachable at the listed IP addresses. The mapping may be any, i.e., all HITs may be reachable at all of the listed IP addresses, some of the HITs may be reachable at some of the IP addresses, or there may even be one-to-one mapping between the HITs and IP addresses. In general, the host cannot know the mapping and MUST NOT expect any particular mapping. It is RECOMMENDED that if a host receives multiple HITs, the host SHOULD first try to initiate the base exchange by using the opportunistic mode. If the returned HIT does not match with any of the expected HITs, the host SHOULD retry by sending further I1s, one at time, trying out all of the listed HITs. If the host receives an R1 for any of the I1s, the host SHOULD continue to use the successful IP address until an R1 with a listed HIT is received, or the host has tried all HITs, and try the other IP addresses only after that. A host MAY also send multiple I1s in parallel, but sending such I1s MUST be rate limited to avoid flooding (as per Section 8.4.1 of [10]). Nikander & Laganier Expires August 21, 2005 [Page 18] Internet-Draft HIP DNS Extensions February 2005 8. Transition mechanisms * This paragraph only makes sense as long as there is no type * code. As soon as IANA has assigned type codes you can use the * RFC3597 notation if your server does not provide for a parser of * the HIPHI and HIPRVS presentation format. * * When this document andvances and you have a type code you can do without * this paragraph. I'd take it out. During a transition period, to allows to store the HIP informations of a node in a DNS server which does not support the HIPHI and HIPRVS RRs, A and AAAA RRs MAY be overloaded. A HIT would typically be stored in a AAAA RR and a RVS in either a A or AAAA RR. If such a situation occurs, the overloaded RRs MUST be returned as the last items of the returned RRs set (A or AAAA), to avoid as most as possible conflicts with non-HIP IPv6 nodes. Nikander & Laganier Expires August 21, 2005 [Page 19] Internet-Draft HIP DNS Extensions February 2005 9. Security Considerations Though the security considerations of the HIP DNS extensions still need to be more investigated and documented, this section contains a description of the known threats involved with the usage of the HIP DNS extensions. In a manner similar to the IPSECKEY RR [14], the HIP DNS Extensions allows to provision two HIP nodes with the public keying material (HI) of their peer. These HIs will be subsequently used in a key exchange between the peers. Hence, the HIP DNS Extensions introduce the same kind of threats that IPSECKEY does, plus threats caused by the possibility given to a HIP node to initiate or accept a HIP exchange using "Opportunistic" or "Unpublished Initiator HI" modes. A HIP node SHOULD obtain both the HIPHI and HIPRVS RRs from a trusted party trough a secure channel insuring proper data integrity of the RRs. DNSSEC [3] provides such a secure channel. In the absence of a proper secure channel, both parties are vulnerable to MitM and DoS attacks, and unrelated parties might be subject to DoS attacks as well. These threats are described in the following sections. 9.1 Attacker tampering with an unsecure HIPHI RR The HIPHI RR contains public keying material in the form of the named peer's public key (the HI) and its secure hash (the HIT). Both of these are not sensitive to attacks where an adversary gains knowledge of them. However, an attacker that is able to mount an active attack on the DNS, i.e., tampers with this HIPHI RR (e.g., using DNS spoofing) is able to mount Man-in-the-Middle attacks on the cryptographic core of the eventual HIP exchange (responder's HIPHI and HIPRVS rewritten by the attacker). 9.2 Attacker tampering with an unsecure HIPRVS RR The HIPRVS RR contains a destination IP address where the named peer is reachable by an I1 (HIP Rendezvous Extensions IPSECKEY RR [13] ). Thus, an attacker able to tamper with this RRs is able to redirect I1 packets sent to the named peer to a chosen IP address, for DoS or MitM attacks. Note that this kind of attacks are not specific to HIP and exist independently to whether or not HIP and the HIPRVS RR are used. Such an attacker might tamper with A and AAAA RRs as well. An attacker might obviously use these two attacks in conjunction: It will replace the responder's HI and RVS IP address by its owns in a spoofed DNS packet sent to the initiator HI, then redirect all Nikander & Laganier Expires August 21, 2005 [Page 20] Internet-Draft HIP DNS Extensions February 2005 exchanged packets through him and mount a MitM on HIP. In this case HIP won't provide confidentiality nor initiator HI protection from eavesdroppers. 9.3 Opportunistic HIP A HIP initiator may not be aware of its peer's HI, and/or its HIT (e.g., because the DNS does not contains HIP material, or the resolver isn't HIP-enabled), and attempt an opportunistic HIP exchange towards its known IP address, filling the responder HIT field with zeros in the I1 header. Such an initiator is vulnerable to a MitM attack because it can't validate the HI and HIT contained in a replied R1. Hence, an implementation MAY choose not to use opportunistic mode. 9.4 Unpublished Initiator HI A HIP initiator may choose to use an unpublished HI, which is not stored in the DNS by means of a HIPHI RR. A responder associating with such an initiator knowingly risks a MitM attack because it cannot validate the initiator's HI. Hence, an implementation MAY choose not to use unpublished mode. 9.5 Hash and HITs Collisions As many cryptographic algorithm, some secure hashes (e.g. SHA1, used by HIP to generate a HIT from an HI) eventually become insecure, because an exploit has been found in which an attacker with a reasonable computation power breaks one of the security features of the hash (e.g., its supposed collision resistance). This is why a HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from DNS, but SHOULD rather use HI-based authentication. * I'd add a paragraph like below. I am not a very strong security * considerations writer but I think it'l do. * 9.6 DNSSEC * * In absence of DNSSEC the HIPHI and HIPRVS RRs are subject to the * threads in rfc3833. Nikander & Laganier Expires August 21, 2005 [Page 21] Internet-Draft HIP DNS Extensions February 2005 10. IANA Considerations IANA needs to allocate two new RR type code for HIPHI and HIPRVS from the standard RR type space. IANA needs to open a new registry for the HIPHI RR HIT type. Defined types are: 0 No HIT is present 1 A Type 1 HIT is present 2 A Type 2 HIT is present 3-6 Unassigned 7 A HAA is present Adding new reservations requires IETF consensus RFC2434 [16]. IANA needs to open a new registry for the HIPHI RR HIT algorithm. Defined types are: 0 Reserved 1 SHA1 2-255 Unassigned Adding new reservations requires IETF consensus RFC2434 [16]. IANA does not need to open a new registry for the HIPHI RR type for public key algorithms because the HIPHI RR reuse 'algorithms types' defined for the IPSECKEY RR [14]. The presently defined numbers are given here only informally: 0 is reserved 1 is RSA 2 is DSA IANA does not need to open a new registry for the HIPRVS RR Rendezvous server type because the HIPHI RR reuse the 'gateway types' defined for the IPSECKEY RR [14]. The presently defined numbers are given here only informally: 0 is reserved 1 is IPv4 2 is IPv6 3 is a wire-encoded uncompressed domain name *** * No further comments... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 07 15:54:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqcSL-0005xe-7h for dnsext-archive@megatron.ietf.org; Thu, 07 Jul 2005 15:54:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14395 for ; Thu, 7 Jul 2005 15:54:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqcNn-000OrI-2N for namedroppers-data@psg.com; Thu, 07 Jul 2005 19:50:03 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DqcNm-000Oqm-Az for namedroppers@ops.ietf.org; Thu, 07 Jul 2005 19:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DqcNl-0001H4-9g; Thu, 07 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-08.txt Message-Id: Date: Thu, 07 Jul 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : The Role of Wildcards in the Domain Name System Author(s) : E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-08.txt Pages : 0 Date : 2005-7-7 This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-wcard-clarify-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-7123528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-7123528.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 07 17:18:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqdll-00041r-5p for dnsext-archive@megatron.ietf.org; Thu, 07 Jul 2005 17:18:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06160 for ; Thu, 7 Jul 2005 17:18:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dqdhg-000C4Z-TF for namedroppers-data@psg.com; Thu, 07 Jul 2005 21:14:40 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dqdhg-000C4A-3n for namedroppers@ops.ietf.org; Thu, 07 Jul 2005 21:14:40 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j67LEWv0005000 for ; Thu, 7 Jul 2005 17:14:32 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050707104636.03adf820@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 17:14:22 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: IETF-63 DNSEXT Agenda items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk We have requested 2+ hour slot for the meeting and we requested a room that is set up for more informal discussion than the standard IETF room. The focus of this meeting will be to select from the different key rollover proposals, please read the new versions of the drafts (when they get posted). Please send me other agenda requests. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 08 14:05:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqxEZ-0005st-Nu for dnsext-archive@megatron.ietf.org; Fri, 08 Jul 2005 14:05:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02028 for ; Fri, 8 Jul 2005 14:05:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dqx9a-000MdY-7R for namedroppers-data@psg.com; Fri, 08 Jul 2005 18:00:46 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dqx9Y-000MdC-HT for namedroppers@ops.ietf.org; Fri, 08 Jul 2005 18:00:44 +0000 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id CFBC0A7BB9 for ; Fri, 8 Jul 2005 14:00:43 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j68I0hWD029117; Fri, 8 Jul 2005 14:00:43 -0400 Message-Id: <200507081800.j68I0hWD029117@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: namedroppers@ops.ietf.org Subject: IANA registry for SRV record names Date: Fri, 8 Jul 2005 14:00:43 -0400 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I'd like to draw your attention to: Title : An IANA Registry for DNS SRV service names Author(s) : B. Fenner Filename : draft-fenner-iana-dns-srv-00.txt Pages : 5 Date : 2005-6-21 This document proposes a registry for service names used in DNS SRV records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fenner-iana-dns-srv-00.txt Basically, it proposes clarifying what I've always thought was a misunderstanding about which part of RFC 1700 was meant by RFC 2782 - people take it to mean what's now the port-numbers file, where I thought it might have originally meant what's now service-names. I'm interested in what people think of the plan, and particularly whether it makes sense to do the proposed wholesale copy of the names from the ports registry to the service-names one or a more complex migration is appropriate. Thanks, Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 08 14:51:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqxwS-0006v4-Pr for dnsext-archive@megatron.ietf.org; Fri, 08 Jul 2005 14:51:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06034 for ; Fri, 8 Jul 2005 14:51:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DqxuG-0000Yh-8I for namedroppers-data@psg.com; Fri, 08 Jul 2005 18:49:00 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DqxuE-0000YT-KJ for namedroppers@ops.ietf.org; Fri, 08 Jul 2005 18:48:58 +0000 Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 2AC23414F0; Fri, 8 Jul 2005 11:48:58 -0700 (PDT) Subject: Re: IANA registry for SRV record names From: Douglas Otis To: Bill Fenner Cc: namedroppers@ops.ietf.org In-Reply-To: <200507081800.j68I0hWD029117@bright.research.att.com> References: <200507081800.j68I0hWD029117@bright.research.att.com> Content-Type: text/plain Date: Fri, 08 Jul 2005 11:48:54 -0700 Message-Id: <1120848534.7732.17.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2005-07-08 at 14:00 -0400, Bill Fenner wrote: > This document proposes a registry for service names used in DNS SRV > records. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-fenner-iana-dns-srv-00.txt Perhaps this is too soon to consider, but it may also be worth having a list of protocols, in addition to the service name list. This could document the use of SRV records as a means to identify clients, rather than locating servers. For example, the CSV proposal uses the service-name "client" and protocol "smtp". Documenting the SRV protocols may entail having a "client" protocol list, and the normal "server" protocol list which lists transport protocols, rather than client protocols. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 08 15:46:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqynU-0004wL-3l for dnsext-archive@megatron.ietf.org; Fri, 08 Jul 2005 15:46:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11441 for ; Fri, 8 Jul 2005 15:45:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dqyj5-00054S-7e for namedroppers-data@psg.com; Fri, 08 Jul 2005 19:41:31 +0000 Received: from [207.65.203.98] (helo=goose.ntrg.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dqyj3-00054A-6u for namedroppers@ops.ietf.org; Fri, 08 Jul 2005 19:41:29 +0000 Received: from [10.29.41.112] (gmp-inet7-152.gmpexpress.net [72.9.7.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ntrg.com (Postfix ) with ESMTP id 1A973C517; Fri, 8 Jul 2005 14:41:28 -0500 (CDT) Message-ID: <42CED6EF.4010601@ehsco.com> Date: Fri, 08 Jul 2005 15:41:35 -0400 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Fenner CC: namedroppers@ops.ietf.org Subject: Re: IANA registry for SRV record names References: <200507081800.j68I0hWD029117@bright.research.att.com> In-Reply-To: <200507081800.j68I0hWD029117@bright.research.att.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 7/8/2005 2:00 PM, Bill Fenner wrote: > Title : An IANA Registry for DNS SRV service names > Basically, it proposes clarifying what I've always thought was a > misunderstanding about which part of RFC 1700 was meant by RFC 2782 - > people take it to mean what's now the port-numbers file, where I > thought it might have originally meant what's now service-names. > > I'm interested in what people think of the plan, and particularly > whether it makes sense to do the proposed wholesale copy of the names > from the ports registry to the service-names one or a more complex > migration is appropriate. We've been through this before. And while I haven't read the draft yet (sorry) I'll reiterate the point that I think the text in 2782 pretty much requires independent registration. I know this wasn't the intent of 2782's authors, but that's pretty much the way it boils out. As a simple example, consider the text about the Weight field. By default, it has no value, and is therefore more-or-less ignored, but 2782 also allows the Weight field to be defined when needed. Pre-declaring all registered protocols needs to be accompanied by a careful consideration for this stuff--what if implementations are released that use the null-weight value (because you told them to) but then some "real" spec comes out that says "weights override priority values in situation X"? You'll have conflicting implementations that produce different results from identical inputs, and both of them will be "standard" behaviors. That's really bad in the same sort of way that different intepretations of MX RRs would be bad. As another related example, I have been working on a lookup scheme for locating submission and retrieval (email) servers, using SRV. There are several ways to do this: you can take an input email address and try to find _proto._transport.localpart.domain.dom; or you can take the local subnet address and try to find _proto._transport.reverse.ip.addr; and so forth, with a variety of potential formula being used. As can be seen, trying to use a common label for this may require multiple algorithms that work based on a variety of different non-obvious switches and flags. As a result, my position here is that SRV prefixes have no significant meaning until they are explicitly defined. Therefore, and moreover, the prefixes SHOULD NOT be registered in the absence of a governing specification. In that context, pre-registrations are not only unhelpful they are somewhat harmful, and should be avoided. This is somewhat different from the intention of 2782 but that's the way I've seen it play out. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 08 17:59:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0sj-00088l-6Q for dnsext-archive@megatron.ietf.org; Fri, 08 Jul 2005 17:59:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07983 for ; Fri, 8 Jul 2005 17:59:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dr0ox-000GWP-7n for namedroppers-data@psg.com; Fri, 08 Jul 2005 21:55:43 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dr0ov-000GW7-NL for namedroppers@ops.ietf.org; Fri, 08 Jul 2005 21:55:41 +0000 Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 70DD8414F1; Fri, 8 Jul 2005 14:55:41 -0700 (PDT) Subject: Re: IANA registry for SRV record names From: Douglas Otis To: "Eric A. Hall" Cc: Bill Fenner , namedroppers@ops.ietf.org In-Reply-To: <42CED6EF.4010601@ehsco.com> References: <200507081800.j68I0hWD029117@bright.research.att.com> <42CED6EF.4010601@ehsco.com> Content-Type: text/plain Date: Fri, 08 Jul 2005 14:55:37 -0700 Message-Id: <1120859737.7732.30.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2005-07-08 at 15:41 -0400, Eric A. Hall wrote: > On 7/8/2005 2:00 PM, Bill Fenner wrote: > > As a result, my position here is that SRV prefixes have no significant > meaning until they are explicitly defined. Therefore, and moreover, the > prefixes SHOULD NOT be registered in the absence of a governing > specification. In that context, pre-registrations are not only unhelpful > they are somewhat harmful, and should be avoided. Could this concern be addressed by including a matrix with references to governing specifications? The protocol slot could offer references to the applicable sub-sets, if more than one protocol is used. ----------------------------------------------------- | service-name | protocol | governing specification | +--------------+----------+-------------------------+ | foobar | table A | rfcxxxx | +--------------+----------+-------------------------+ -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From IrwinLink@featheriness.com Sun Jul 10 01:13:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrU7i-0000s1-Tw for dnsext-archive@megatron.ietf.org; Sun, 10 Jul 2005 01:13:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18835 for ; Sun, 10 Jul 2005 01:13:01 -0400 (EDT) Received: from abo-164-227-68.guy.modulonet.fr ([85.68.227.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DrUZ6-0002QJ-NQ for dnsext-archive@ietf.org; Sun, 10 Jul 2005 01:41:42 -0400 Received: from wIG@localhost by NzD7.int (8.11.6/8.11.6); Sun, 10 Jul 2005 08:06:54 +0500 Message-ID: From: "Lincoln Parker" Reply-To: "Lincoln Parker" To: fcdbrohc-admin@ietf.org Cc: dnsext-archive@ietf.org Subject: Photoshop CS 8.0 $59.95 Windows Date: Sun, 10 Jul 2005 06:04:54 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: IrwinLink@featheriness.com Content-Type: multipart/mixed; boundary="--PNSGp0ysEw1BuAS" X-Spam-Score: 0.2 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 4y6A ----PNSGp0ysEw1BuAS Content-Type: text/html; Content-Transfer-Encoding: quoted-printable X
Opt-in Email Special Offer &n= bsp;   unsubscribe me
= <= /tbody>
<= td width=3D5 bgcolor=3D#000080>
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
= <= /tr>=

 = ON SALE NOW!

 1 Of= fice Pro 2003
 2 Windows= XP Pro
 3 Adobe Creat= ive Suite Premium
 4 Nort= on Antivirus 2005
 5 F= lash MX 2004
 6 Corel D= raw 12
 7 Adobe Acrobat= 7.0
 8 Windows 2003 S= erver
 9 Alias Maya 6 = Wavefrt
 10 Adobe Prem= iere
  See more by = this manufacturer
   Microsoft
  = Apple Software
  Customers also bought
   t= hese other items...



Microsoft Office Prof= essional Edition *2003*
Microsoft <= /span>
Choose:
 <= /td>
= = =
List Price:$899.0= 0
Price:$69.99
You Save:$830.01 (92%)



Availability: Available for = INSTANT download!
Coupon Code: ISe229
Media: CD-ROM = / Download

System requirements  |  Accessories  |  Other Ve= rsions

Features: =

  • Analyze and manage busine= ss information using Access databases
  • Exchange data with other systems using enhanced XML technology <= /font>
  • Control information sharing r= ules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marketi= ng materials
  • More than 20 pr= eformatted business reports
Sales Rank: #1
Shipping: International/US or = via instant download
Date Coupon Expires: June 30th, 2005
<= /span>Average Customer Review: 3D"5 Based on= 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longho= rn Edition
Mi= crosoft
Choo= se: 

List Price:$279.00
Price:$49.99<= /b>
You Save:$229.01 (85= %)



Availability: Av= ailable for INSTANT download!
Coupon Code: ISe229
Media:= CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:=

  • Designed f= or businesses of all sizes
  • M= anage digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files a= nd folders
  • Built-in voice, v= ideo, and instant messaging support
  • Integration with Windows servers and management solutions <= /li>

Sales Rank: #2
S= hipping: International/US or via instant download
Date Coupon E= xpires: June 30th, 2005
Average Custo= mer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9.0<= br> Adobe
=
Choose:
 

List Price: $599.00
Price:$69.99
You Save:$529.01 (90%)



Availabi= lity: Available for INSTANT download!
Coupon Code: ISe229 Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features= :

  • Customized workspace; save personalized workspace and tool settings; cre= ate customized shortcuts
  • Un= paralleled efficiency--automate production tasks with built-in or customiz= ed scripts
  • Improved file man= agement, new design possibilities, and a more intuitive way to create for = the Web
  • Support for 16-bit i= mages, digital camera raw data, and non-square pixels
  • Create or modify photos using painting, drawing,= and retouching tools

Sal= es Rank: #3
Shipping: International/US or via = instant download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D= Based on 498 r= eviews. Write a review.

----PNSGp0ysEw1BuAS-- From owner-namedroppers@ops.ietf.org Mon Jul 11 16:02:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds4TX-00010x-3s for dnsext-archive@megatron.ietf.org; Mon, 11 Jul 2005 16:02:00 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18017 for ; Mon, 11 Jul 2005 16:01:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds4PL-000OQ8-OK for namedroppers-data@psg.com; Mon, 11 Jul 2005 19:57:39 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Ds4PK-000OPR-N0 for namedroppers@ops.ietf.org; Mon, 11 Jul 2005 19:57:39 +0000 Received: from [10.31.32.139] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j6BJvJhi033789; Mon, 11 Jul 2005 15:57:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050705093248.7613d225.olaf@ripe.net> References: <20050705093248.7613d225.olaf@ripe.net> Date: Mon, 11 Jul 2005 15:57:19 -0400 To: Julien Laganier , pekka.nikander@nomadiclab.com From: Edward Lewis Subject: Re: Cross Area Review: draft-ietf-hip-dns-01 Cc: namedroppers@ops.ietf.org, ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:32 +0200 7/5/05, Olaf M. Kolkman wrote: >Dear colleagues, > >Help from this group on reviewing draft-ietf-hip-dns-01 would be highly >appreciated. > >Also see: > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00863.html My short comments to the authors are: 1) In section 5.1.1, are you talking bit positions or field values? 2) I think some of the introduction would be simplified if it was explained that domain names are not the source or target when mapping names to numbers but the vehicle by which this is done. I.e., a host's name is "mapped" to a domain name (usually 1:1 these days), and an address record is stored there. Conversely, an address is mapped to a domain name (i.e. under dot-arpa), and a "ptr" record is stored there. IOW, the "host identity" (value) space is mapped to addresses just like the host name space is mapped, just via a different set of records which allow needed flexibility. 3) Where there is discussion of multiple HIT RR's, it should be realized that the DNS (since RFC 2181) deals in sets of RR's at all times, whether the set has one member or many. 4) Using multiple RR records will mean multiple queries to retrieve them all. I haven't figured out the exact sequence of retrieving data from the DNS, but there is no way to get multiple record types in one shot. (QTYPE=ANY discussion could follow here again, and why that isn't QTYPE=ALL.) 5) In 5.2.2. and 5.2.3., you can't mix and match v4 and v6? 6) In the security sections, DNSSEC isn't the end-all of security. Secure dynamic update is also needed to protect against adding records maliciously, for example. Also DOS attacks can happen even with secure channels, and maybe even more disruptive. 7) What I am missing is a good idea of the frequency this data is retrieved - that is an amplifier for any pain that might be involved. Just some brief comments... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 11 18:52:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds78k-0001vX-Tz for dnsext-archive@megatron.ietf.org; Mon, 11 Jul 2005 18:52:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28480 for ; Mon, 11 Jul 2005 18:52:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds76B-000C2r-Ky for namedroppers-data@psg.com; Mon, 11 Jul 2005 22:50:03 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Ds76A-000C2M-QE for namedroppers@ops.ietf.org; Mon, 11 Jul 2005 22:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ds769-0008OT-VP; Mon, 11 Jul 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-2929bis-00.txt Message-Id: Date: Mon, 11 Jul 2005 18:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-2929bis-00.txt Pages : 17 Date : 2005-7-11 Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, RR types, operation codes, error codes, RR header bits, and AFSDB subtypes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-2929bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-2929bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-11163934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-2929bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-2929bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-11163934.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 11 19:24:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds7dM-0005ZG-25 for dnsext-archive@megatron.ietf.org; Mon, 11 Jul 2005 19:24:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07222 for ; Mon, 11 Jul 2005 19:24:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Ds7b0-000Ef1-Q9 for namedroppers-data@psg.com; Mon, 11 Jul 2005 23:21:54 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Ds7ay-000Eec-NV for namedroppers@ops.ietf.org; Mon, 11 Jul 2005 23:21:52 +0000 Received: from deneb.enyo.de ([2001:14b0:202:1::ab]) by albireo.enyo.de with esmtp id 1Ds7aw-0006gm-9T for namedroppers@ops.ietf.org; Tue, 12 Jul 2005 01:21:50 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.52) id 1Ds7ai-00067y-MP for namedroppers@ops.ietf.org; Tue, 12 Jul 2005 01:21:36 +0200 From: Florian Weimer To: namedroppers@ops.ietf.org Subject: Randomness requirements for message ID generation Date: Tue, 12 Jul 2005 01:21:36 +0200 Message-ID: <87br59dj3z.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Apologies if this is the wrong forum to ask such questions. What are the randomness requirements for message ID generation? Are simple time-dependent IDs acceptable? What about PRNGs which leak their internal state? Would you recommend different levels of randomness for stub and full resolvers? (I know it's just a 16-bit number, so we aren't in a very good position no matter what we do. But there's no reason to make things even worse, IMHO.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From howard@yahoo.com Mon Jul 11 22:58:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsAyk-0003kD-Bo for dnsext-archive@megatron.ietf.org; Mon, 11 Jul 2005 22:58:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19083 for ; Mon, 11 Jul 2005 22:58:35 -0400 (EDT) Received: from khp059140081182.ppp-bb.dion.ne.jp ([59.140.81.182] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DsBQn-0007Ga-Pw for dnsext-archive@ietf.org; Mon, 11 Jul 2005 23:27:42 -0400 Date: Î, 12 7 2005 11:58:17 +0100 From: "Gruber" To: Subject: Windows XP + Office XP = $80. Message-ID: <423F3FA9.4010405@expert> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050509040508030003060708" X-Spam-Score: 2.0 (++) X-Scan-Signature: 8008c49d41a52dffe8d48b494980a4a9 This is a multi-part message in MIME format. --------------050509040508030003060708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by drop.ux6.net id j2LLgHfF030444 Content-Transfer-Encoding: quoted-printable Opt-in Email Special Offer unsubscribe me=20 =09 *SEARCH* =09 =09 * TOP 10 NEW TITLES* =09 * ON SALE NOW!* 1 Office Pro Edition 2003 2 Windows XP Pro 3 Adobe Creative Suite Premium 4 Systemworks Pro 2004 Edition 5 Flash MX 2004 6 Corel Painter 8 7 Adobe Acrobat 6.0 8 Windows 2003 Server 9 Alias Maya 6.0 Wavefront 10 Adobe Premiere * See more by this manufacturer* Microsoft A pple Software * Customers also bought* these other items.. *Microsoft Office Professional Edition *2003** Microsoft *Choose:* =09 *List Price:* =09 $899.00 *Price:* =09 *$69.99* *You Save:* =09 $830.01 (92%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Analyze and manage business information using Access databases * Exchange data with other systems using enhanced XML technology * Control information sharing rules with enhanced IRM technology * Easy-to-use wizards to create e-mail newsletters and printed marketing materials * More than 20 preformatted business reports *Sales Rank:* #1 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 1,768 reviews.=20 Write a review . ------------------------------------------------------------------------ *Microsoft Windows XP Professional or Longhorn Edition* Microsoft *Choose:* =09 *List Price:* =09 $279.00 *Price:* =09 *$49.99* *You Save:* =09 $229.01 (85%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Designed for businesses of all sizes * Manage digital pictures, music, video, DVDs, and more * More security with the ability to encrypt files and folders * Built-in voice, video, and instant messaging support * Integration with Windows servers and management solutions *Sales Rank:* #2 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 868 reviews. Write=20 a review . ------------------------------------------------------------------------ *Adobe Creative Suite Premium* Adobe *Choose:* =09 *List Price:* =09 $1149.00 *Price:* =09 *$99.99 * *You Save:* =09 $849.01 (90%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * An integrated design environment featuring the industry's foremost design tools * In-depth tips, expert tricks, and comprehensive design resources * Intuitive file finding, smooth workflow, and common interface and toolset * Single installer--control what you install and when you install it * Cross-media publishing--create content for both print and the Web *Sales Rank:* #3 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 498 reviews. Write=20 a review . ------------------------------------------------------------------------ *Symantec SystemWorks 2004 Professional* Symantec *Choose:* =09 *List Price:* =09 $99.00 *Price:* =09 *$29.99 * *You Save:* =09 $69.01 (70%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Norton Utilities optimizes your PC=BFs performance and solves computer problems * Norton Password Manager keeps your passwords secure and easy to manage * Norton GoBack Personal Edition restores your PC after a serious problem * Norton CleanSweep removes unwanted programs and files that waste disk space * Norton Ghost protects your data from computer disasters *Sales Rank:* #4 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 217 reviews. Write=20 a review . --------------050509040508030003060708 Content-Type: multipart/related; boundary="------------030407060607010708020801" --------------030407060607010708020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Opt-in Email Special Offer     unsubscribe me
SEARCH

TOP 10 NEW TITLES

 ON SALE NOW!
  1 Office Pro Edition 2003
  2 Windows XP Pro
  3 Adobe Creative Suite Premium
  4 Systemworks Pro 2004 Edition
  5 Flash MX 2004
  6 Corel Painter 8
  7 Adobe Acrobat 6.0
  8 Windows 2003 Server
  9 Alias Maya 6.0 Wavefront
  10 Adobe Premiere
  See more by this manufacturer
    Microsoft
    Apple Software
  Customers also bought
    these other items..


Microsoft Office Professional Edition *2003*
Microsoft
Choose:
 
List Price:
$899.00
Price:
$69.99
You Save:
$830.01 (92%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft
Choose:
 

List Price:
$279.00
Price:
$49.99
You Save:
$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 868 reviews. Write a review.

Adobe Creative Suite Premium
Adobe
Choose:
 

List Price:
$1149.00
Price:
$99.99
You Save:
$849.01 (90%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • An integrated design environment featuring the industry's foremost design tools
  • In-depth tips, expert tricks, and comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and toolset
  • Single installer--control what you install and when you install it
  • Cross-media publishing--create content for both print and the Web

Sales Rank: #3
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 498 reviews. Write a review.

Symantec SystemWorks 2004 Professional
Symantec
Choose:
 

List Price:
$99.00
Price:
$29.99
You Save:
$69.01 (70%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions


Features:

  • Norton Utilities optimizes your PC¿s performance and solves computer problems
  • Norton Password Manager keeps your passwords secure and easy to manage
  • Norton GoBack Personal Edition restores your PC after a serious problem
  • Norton CleanSweep removes unwanted programs and files that waste disk space
  • Norton Ghost protects your data from computer disasters

Sales Rank: #4
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 217 reviews. Write a review.

--------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhLAEWANUAAP///+7uzAAAAIqKitbWuLu7u+fn4O3ty21tXq6urpiYhkVFRWdnXBcX FzMzM7y8o3d3beLiwktLR8vLr+/v7319cRERETExMSEhIT8/PVdXUZqamnNzaiIiIrCwmqqq qmZmZszMy6Skj1VVVd/f3/r6+erqydvb2M/Pz4mJeefnxs/PsnZ2dvb29M3Nzby8vN7exqqq lPHx8ImJiIKCggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAA AAAsARYAAAb/QIBwSCwaj8ikcslsOp/QqHRKrVqv2JA2hO16v+CweEwuLxvoBtfMVgra5Xez 1JIZ7vi8fs/v+/+AeyVNcnAAEIgNEIaMQ4WNXo9IJTInMCoHAZqbnJ2en6ChoqMBBxEEKy4G TJKGaJCMrbBVskQlBjCkuru8vZ0EDwaDSbVsEK8NAMnLAB0hr2UUBQVhxbNR1gC4oxMRvqET D5zh497fvx6rxNfQSM8dRBcjQhQCHwNvCwL7NAIDAAUEXBBygQURFgIvbBACwp6QgAIsjKi3 b98/JNbkCdlHAQCLgQsWAKBwAcOCf/geCqAmJKXKAiRNDsBX0Zq1Fis4KZAQIIKD/wcEJGjI oEDTzwAKGCB14EDChE4pHBDQFEGDBAZFq14tGnRo0QBHky4VhxUs06OlVHh44SZJQJb+ANQs 4BIATQwLlxw7pqzvMr5EXG6wYDefSCEL5tGkUI9lYZYdKVjAMA/gShRx5V5cl2QAYYgfAFz4 F7Jwx5Zy3g6p+xbfadSslBiYusnng50BKnAIMEEqWHFixXLYzUkCh68VlPbMrdybbt6+wypV kKFCgLJIlWs6YOJBXoxuV278l7nw6jf4SDBpAA9JOyEkHI4AYb50SwwATq788AgDfSIb4CWA em9hlld54IVHwgAhDdBYfiJt4M9pLqkG20sSOnhebEl00/9JchmIEEAGHmiiQVHSZRcAB9Zt MoEGHmigiQQlbkIjJySaiCJw0zEgQQTYicWJCSuk0BYSFsZVXl0p8aeeXuz55ZciRlwAQj2h paTPPtMMaEEBJzFIBIKiORgXROWRaUQ2AmwwwkwLBITYYSNERA1NFTnGmnh1fnnhkUjE4AkB TRklznU7qqgAUz9ykkIKPk2FlqGcoFVWikkpkKkmQm5iAgEcAGoEmhbJVZF5qC1gwX9LvLMG ER0kY4Rng8Fm33joNUjEqkRgdoGq+L3FAn7jLZHNAiBg0KWYEA5RQEmoWoiqZSw9S2xdnAVq DifY5RjAib8pykAEGRw6owYMOFD/1I021qiJt+BiOu5WnGpXSnehZjuqeJr1+yc+BTzZxDFp FEylEfHxWt9hiJkEwAcWCIACEQ1NzNAF00j4QYEO+avvEQNg8EY9FlxU2mksEFYhv9O+hTJh 035cxAS0cYvcbr1NJYGIFVgnXAoulvtABTImx4nRmzyXcwA75+azUhUQVS8npoiQb4JHJEne ZkxmY0QIiIQtdhL6hFZfRSjFRXIRFDR0wQU0lDyESao57DHWSApw2AUCuDAnQCa1GS3LeMa5 UgGB54Ut3kacYO4m2HUldQAiZMBABk+JJQJPmqRAXG8RaFWW6FwJNXnll2eu1APqTr2dCitU YKTMzvKr+GSehS9+DRQFWPyF17tziEQLQB1gPCge1vZ4L+S4+HjyVC0fivEqEKAAAt8dAXwZ EHSwyBDdfx88LeNbkY0BHnSjggkmGO/++/DHL//89Ndvv/EmqBDBCtfPcIKosIhVe4QgwPKR z4BT8NoJYiCCB9CMABCMoAQnSMEKWvCCGMwgKh4gggogYAYuGAbjIBE+IpQQgVLYHgrHxIQW nCABCtANAmZIwxra8IY4zKEOd8hDBDAAASzawAlEOMIVGvGI17iFC17wggQ48YlQjKIUp0jF Klrxik98wQlkgMQuevGLYAyjGMdIxjKa8YxoTKMa18jGNrrREEEAADs= --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhBQAFAIABAP///////yH5BAEAAAEALAAAAAAFAAUAAAIIhG8RqaD9QgEAOw== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhBQAFAIABAP///////yH5BAEAAAEALAAAAAAFAAUAAAIIhB1xqcD6QAEAOw== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhUgAOAMQAAP/umd1mM////4czIa5wSM+jaXYZEG4MCLmAU6RgPn8mGfPbjWYAAObH gMSSXpBCKtq0dJpRNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAABSAA4AAAX/YCAIIjmW6KmabNqubgzP7xsEwJ3jes//u6BPCBwai0ji 7gRoOp/QqHRKrVqvItx1y+16qVkn4bAoDACFwyABMEAKjELDACAYBgiAQzGAAAYHCnlNEWwF dGlrdQYGBE0DigAMTQiQg5B1jk0oYgYIZmhnTQ8OBAMEDg+ZTgMFT61PewAJhqKZC5OgTpNt Cwt0fwYNBJo5JE8ECa1nhwR5xA8E0Y6mBK5jDqyuTwwLCn7NzxGmAAsHDwtNuaKwpwnET2FN xO/MCgXgA3R31xFylAey/dnm5AGCA00K3PNjSoHABg8UqAv1yNWyd044zSMwh5ktAIHaIFz1 BONAKAgMW0RIaIsYBIlNcE3s9atiymLyNv5hpkaUgpUR591ho0xYRSgNGAhMdAbegQYQ9Gni VQlPRXPFjGn5wrWr101MvoodawVFkiNK0Ko9yzYt2xoy4NKIS3euXbktQgAAOw== --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQY GBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYa KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAAR CAC0AIwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3zW/Ekun6jJapbxuqBfmZj3FQ6b4plubo R3EUEKMv3snr2rA8cSGLXbhlTef3Yxn2FZnhKe5urmcXKWe7lUD52FGVWCn3r5CGPxMsd7Pm 05rfK56Lw8PYOduh3V5rd9ZMfOggMXaYFsD/AHvT+VNt/FDiXZewJEp6OpLCs+J5bV/Kh3R/ 9OdyeD/1yf8A9lqhqVxp9qyor/ZZXO02sybRn+n4fLX2b5FueQps7pL8um5UQqfQ1VudZeK6 gi8kHzEdic9Nu3/4quXtZ7iwfEQYp954JOv+8v8A8UKuNdxXt7ayQ7uI5d4PUfco5SuY211z NykPkruO7Pz9MVb+3lkysYz2ya4+eETa/blYvnRPv+Zt4/u4/wDHq6NcH7vNQh3HR60BOI5r fy88Z3/dPv8A40+XWVjnePyD8h253/7Oahnt0nGG27scf/E1jMDDcyxfMcHqe3yr8tNpAmxg 8eqxcf2fJ8jsv+sHY/SpB48i/wCfCX/vta4CPO+X5G/1j/8AoVPUH0UV8fXzXEwqOMX+R9PS y/DygpSR3y+OoP8Anzn/AO+hT18cWx/5dJ/0rglQ+v6U9Y/m+YtWX9s4nv8AgN5bh+x3v/Ca 2v8AFa3I/wC+f8aB43sO8Fx+n+NcIsY9KlVKX9t4nv8AgZvLaHY7r/hNLD/n3uv++B/jW3pt 7FqVmlzGjqrZADjnivLdvy16F4TXGhW/1f8A9CNejlmZ18RVcZ7WOLF4SnRinA4j4jyeTql5 IrAMojxubA7Vj+CboeQ92gSfeZFIYlwccf0qz8Vp5o9Xkitobad59kQjud2wsQMZx/DnGad4 JmTUkikuY1jjeN8pGem3+6a8em1HHWtvP9SJX9lvpY6eC4triPyonVFP/Ltc/Mh/3W7VzXjW 3ln02UWmzbEdziaTmNlbnY/fj+E1anmtjprXtvL5ke9k8uQYkzu29fun8cVka0PtVm1nb36w yyDebVyPnb+7/dNfe1LNWPEk7o3vCX214XGs/wClZHEcfDwj5fmVe/ruWn6lcW9vfQfZrmKR HDtvztcbeqt+dQeE5bJNG8uJ5g6HmC+m5Dhf4JP4K4XXr+0jvHRbK5RZIyyZ/u/L8u4f8C+b vWVSq4Q0HzWR2+lXaXGtQXENwnlSBkuCz87mX+H+H+Ku5gjSGFET7gHFeW/DuwiCebdXMW+b cyIXDlF2/wAQHT722uo0/X4kvmtNPk+1Kj7XTPA/3W/9lopS0uy4yOyX734ViXQ/064/3x/6 CtadjdR3SM8RzjqO4/3qoXP/AB+XH+//AOyrW62KZ58g+d/98/8AoVSqlRwJnf8A77f+hVZV K/N8S/3svU+0pP3ERqBTl61KqU5U+asOYqUiNR7VIoNPVKeqVPMZuQxUOK9B8KrjQrf/AIF/ 6Ea4XHFd94Z40S2/4F/6Ea93h3/eJen6o8zMX+7XqeSfGlRJf3cRGUkhYP8AuDNx5Y/gHJ/z 6U/4eebcaTZG3kSGU27MjxghBtHp6e1RfGkO+p3MaSNE7xYEgLjZ8g5+Qg/rWv4Cgjgu7eJE IXyWbY5yR8v3WJrilJRxsY96n6nM4/un6ElrpWsQA2d7Lb3VvLiUzvH8uQ3CsevNV9V8H3k9 7dR2UFvDZSfMJEPz+/X+L/61bevW8lppuoztqDmAfvUQncQ6t91T/d/2azvh74xTVoLy3u5U +1W5ZgHfaXWvu7LZnh6XszD0/TnuPItNMv7eHy9yXFrfPh/9/Hfr0Hy8Vzuv+HJ7JYI9TuFD 3D7I03/IPmUFlrrfEesaPMFu7XfBrMch2TRoGzt+UNu/u/7VecaxrGp6le5vXmufv7Ezk/N8 3yr9OtYzsZu2xv6jdWWjNcWek2k1pfxuyTSAlt4VeG3fd53V0vw006SNZ7xpcrJj9xIAz42/ eZeoU/N0/u1x+nPN4rvYImRo5zbyLIO7unKqo/U5rpPArppdzBpllPdXMsiedIPLAg2qzfd/ i/4EKml8V2aR3PSEt45JFkt3aGXsQev+6e/+6ai84/aZ45tvn55I6fdX8qLa6id8S/uXPaQ8 H8ejfj+dDZ8+4z97f3/3VruexsziLR8q21H++e3+1VpQ/wDc/WorHBRv98/+hVdUV+aYmX7y XqfYU5e4iJQ/otSKj7uq/lUqij+KufmCUhmw/wB5qbORBC8jbn2DdjPJqbKf31/OnSCKRGRw rqexGaUX73vGcpe7oc54c1+PVdQltlgxhN4JPOPpXrvh5QNGtgPQ/wDoRrwuzuLDwz4ncvdr JBdnyghhO9D/ALPH/AeK908OAto1sWPJ3f8AoRr6vKKahi3KC0cf1R4tSs5U7Setzyn4v2X9 pa/NZKYw00WB5iZQ/IOtavgsEarBHliwhZc+vy1T+Ix/4riD5FJ9d+0j93+tX/Ax/wCJ/F/1 zf8A9Brwqjl/aUI/3/8A246uX9xfy/QXXPDbx32o3EEl3JFP+9aySMsHb/ZbHDZ6N9a4GTwx qMj7pPD18qqW3ywxlXkP+593vj3r3PWdf0vRjCuq6hb2jS58sSPjfjrip9L1Wx1a2abTrqO6 hB2F4zkA197yx5rXPDnhJcvtGnbvbQ8V/sLXnG3+zryeGPbFC8kRRox3Kp6ZrL8PeENaXxXF carpN8bcFsyBHXH+0pHQ+lfRNMan7LUj6ujwrT/A+v2+qtPotmdOUvveS5G/f8ytu2f+y+or 0XwVpuqaVpUFpdxpNIlxJ5k8kflu+5s715967Bcin4O7NOMOUuNJIpSWSTK3mxKc+1ZK6ZcQ 3M/lIwgz8idvurXRqSV+YYpG/irS5djzSx8O6pHu328w5b+NP71aK6Jfd7d/xcf412q9KWvB nklCcnJt/h/kelHH1IrY49dDvP8An3/8fFC6Hebv+PdfzFdhRWX9hYfu/wAP8g+v1PI5RdGv P+eQH/AxTLrTb2CFnSBJHHRPMC5rrqilj8xMfKPeiORYa+7/AK+RLx1Q8s8R+EdZuNcs7/Sk sRgbnMxHDL8w+Xvz/FXpXgWyuLDwrY214EW4UOXCNuGWdm6/jTfLkjDbtvHStvTh/oUX0r1M Pg6dBWicNRuTueP/ABIz/wAJzDt3cDnGf+efer/gQ/8AFRRf9c3/AJVQ+JBX/hOF3NhgBgc8 /JV3wE3/ABUkH/XN/wCVfHTX/Cmv8X/tx7X/ADD/AC/Q3fF8MkXiXRdQNg95bRRTwyBADgvt x8p/3a5vxLHex2+pNpLapYNJ51xGlvJHCN+yLZu56Zb9GruPFcc7rYSQWb3ccc2ZYlxkjb7/ AO1WBd6brN45uLHSdPVD5kRt77CHBVcNuUN/dr69VKlPFXSv8tNv66nm16nPhlH5fjcb4t1e W1Oix21xq1zqdzbtKtlpcaSNIqAM8py4UKCQPvckqBXK6j8StISVPsviS+nWS3glAQwRZeZ8 JF87ghhyxz8qKPmbmtK403VPDep+Gb2yOlz6va6W+mzW91cPFCyO8ZWQSBCBh0xtbrnjmsjR vBcWkSWlp/aukTSCXTLl5BL9/wCzTPJct0+XcZlChjzXpK1tTj1PQPDPifRGsdPt5NVihvLh JHjt7u7R5nRHYFuHbj5G7/wn/arc0bXNL1u2a40e/tr2BH2GSB94Df3fyrxex8A3Vvpmp6TJ rHh02esKftEzfvp7Zx5qKsS9MfvFOcrs+frndXcfD63stDiv5tQ1HRhd3ZhZ/st7NcfIibEL PMxb17AAYXnrSdgVz0Ckbq1YjeKtLjEpeV0SOFJi5T5cMuQP72SPao4vFuiyp5hvUjTuZBtx /nj5unPWkWbS9KWsS68R2lvbW04juJ7e4fYskacb2JAT5sHOR6fL1OBVZ/F1qlvPL9ju9kHm b87Fw0TKsi/e+8Cyr7n7tZFnSUULyqn1oxUgFJS4pKRRWvELp8o3Vrab/wAeMP8Au1QkQFav aeP9Di+lXAhnjHxOP/FcxcDt36fu/wBa0fh+f+Kkg/65v/KqPxJiL+NXkEm1YwhIx1yn6U3w rfxWGt28s0nlq58lCR/G/AX86+LlHmzJf4v1PaemGv5foexUVz2oalPb2csjXGzA4JTdz9BW BZ+I73W9Nllhea1ns3DTBHRRN/s5PbH/AOuvt5vkdjwPaI6fWNAstWnaW8Te3keSOhCDdu3Y 9aypfBOmzMxlklJ3fJ9zCLlsDG3n7zDJ559q4Gfxfqh1po7LV7t7Ux7cTAZ2/N83Tg/N972F ZNj4114zO6XNyVnTyYFnkyQ/Tdtz/wChVl7dC9qj1I+AtKI2lrsxc/IHCDb6cD7vt0zzVyXw dpssDJK107vM8zv5vMjuAHZuMc4Xtx/DXK+AJtc+33Q1i8mmXZ+7zNvFdxJI+xOW71vD31cf NoVm8K6c/wBxrpFCInyTkcBNg5+99xiPxqNvCGjFPLa2laLZ5Wzz3wU4ynX7pwp2+oq/A5+b cW/GvG/jZ4i1PSb61TSr+WBZZJd4jfbn7vzVoqXMxTq8iueuy6Dp1xIkk8TsVDhf3rqOWy3G eue/sKY3h/R9rD7MvI2n9865z97v/F39f4s18sJ4y1m1Rf8ATJXbO4Zc8Cp08a6yAqNeTF36 neamWGq9Lf18ifrdM+tFkiRVCugUfKBkcUedH/z0T86+U7nxjqIhx9plLuf75wK5zWPGGsxx +ZaajcWzx/MjpIc5qJYSvbdB9bp9j7N+0QD/AJap+dMa7tx/y1T86+SZfFuszlXfU7su/U+Y VquvinVRcbG1C7279v8Arz/FUfU8T3X4h9dp9mfW8+qWkP3p0rX02VJrCCSEhkZcg18dv4m1 H5Ue9uX+fbzMf4q+pfhnM1z4A0CaYlne0Qkmt5Yf2cFz7ijX9o9DgPiMf+Kvuv8Adj/9Argf G11JaeHJbiGRo5454HRx2ZZVw1d38SD/AMVjdf8AXOP/ANArgvGM1lD4avJNVt5bm1Qoxjjk 8olt64+b618Oo/8ACkv8X6n0lT/c36fobui/G3TtUs72DULSbTtSjjLIIT5yP/tL0+b/AGa5 K88afa2d0Rk8z+K6kO9/94At+teUXd1pk13v0+yltmHzfPP5uf8Ax2r95f2YlU2ztI4RWkfI 2A/7NfcVI9JnzkOSaub13r7x6vb7zE8Un+uRAcY/+t1rbbW9It/3UF5bFpT9wAneW+orzC5u 0+0wD5t7nbWfaTE6pb85xMF/8eohCDvdCqx5LWPpf4Nakj+Kb8XEuyIWjYUnj761n+L/AIxa xYeJNUsNNS0S1tZ3ijzGWJVfl3M2a5D4d6xBpfibUZbsvsNvsAQZJbetcL4ovfP8XavKoKLJ dSuAeo3NW1GJFaT6G5r3xg8WalvT+0PsyfdxAm3/AMe+9XLWfiG8up3/ALRvZp1zuHnOXwT1 60y10WGSXdqFyQh+bZBjP5mteS10TTfIbT7eSRmXLvdlZDntj5cCtoxdznlKNtR6XSXW3yvn YfLhBup/2qMNneu2uj8L+ILdn+xSv5C3H7kSRjGxm+Xt/vVuy/BS2gleJ9TjLINz4lXj9aud odSIRc9kef8A22ORvvrTrrR7/UbDzLSLzEfphwpPze5rt2+EWhQJOZ/EDmUKSiQup5/9m+gp vhfTYrGyls4pJZFgkP8ArOoJ520QtN2HOLgrnK/YNQj+9aTfgA1VJZPJuGEw2SoeUf5cf71d rfHZKwrita0mzvNRmmuL14JTgbAvGAv3q1muUyhLmGvdx/LukXr619m/Cch/hr4aZehsYv5V 8hXPws1K30dtVd5FsBGs3neYn3D/ABbc5719d/CmAW/w08MQq28Jp8Q3evy1x1pXOulGxwPx MP8AxWd5/wBc4/8A0CvNfiWf+KK1D/ei/wDQ1r0f4nH/AIrS8/65x/8AoFeZ/Exv+KIv/wDe i/8AQ1r4WC/4UV/i/U+tqR/2J/4f0PJvCWj/ANu6x9la4+zgRPKZMZ6VoeIfDmlWkTxxatcT OevTbXKWd3JbXGYnI3gocelQ3N68jZZ6+9fJb3kfIKNS/usljRIUaNp3Ze2zqKm0mF59Xsre yilmkeZBHGBlyd3TiszeX7fL61o6LDcm/t5bITb0kBEicAH61jp0NXf7R694C8M6rd63eSy2 EsMEcPzyXKGJEO73+n8NJrHwo1LVdZnvdH1vQ72C4nO8W05lMO71VFOfwrZj+LkmhaLBYeIr O41K88vNvM77uOnznhtw/vL1qq/xZ06OcQXYkvYT997YO6D/AL+Pz+VCk4qwOz1Za0j4V6Ho +2fxDqt1fcMwSGHyISF67WJ3Hp/s143r+qRXOp3ElrEYYN58uFE+4nYflXuK/Gbwxbutylpq 13dW8LLbh4Y4UGdoK8MccfxY7V5r47+I2seL0e2uHS100vuFrCMA+m9vvPWsJMznGBT+Hhxd vqWx5fsh3PGvBA2tXU6V4hm8Q6i8Fjpel6lKh4F/MkROP9k/Nx/vVxngrWLbQr+eS6SV7eWP Y6IM5rQS+8NiZ5EnvYd77sG3DY/WicFPcqnV9n8J6JPpvieO2cfY/CGkZHDyTw5G786qa1qZ 0a2cy6wmuXkkaYS0RNkG3quVwCv+7XGwXfhjzk3382wdcwEfyFLq+s6VJJFFY3Ie3jj2glSv 8X0opQ5HuFes6kSZfEkMrZnhvI/96En+WajurnQ74ebdC7uph8iR2rlH29e64/Ostru2LfJO n510vhm7sk06Xzbm3DvJ0eQZ+7W05uxzQSuek6lqVlN8GbKC4d4/Ot4YXhWdPOQK3qcL/D/s 17j8NBEPh94d+ziVYvsEG0S7d+Ng+9jvXzD4nu7ObwxLFDcQvhEwBIG/u19QfDgbfh94bH/U Og/9AFctf3dDrovmVzzD4nn/AIra8/65x/8AoFeXfE58eBtR/wB6L/0Na9J+LUxh8a3RwCvl x5+bH8FeZ/ESTzvBN/tLR8xffH+2tfFqP/Cgn/e/U+tl/uf/AG7+h4Swf7x+THr1rQ0fQb3U 5FNvDtiP/Laf5U/+v+FMt4o0kVmQyEf3+n5V0Nrf3bpjLba+20lufJc3Y39F8JaPZFWv5kvr j0c4jH4d/wAa6W5t7Z2skiRAouE+502/NXH2sLz/AHzXQaZCE+dCdo+Uf/FVrFraxjK/c5r4 toBq2n7EwgtfT/bauKQj1H517Pc3UsIgEUrBSXz7/KtU2ut/+tgtZPeS3Q/0qZR1H0PKKcte oNHp0n+t0bTz7+Rt/lUP2Dw/Ny2kQp/uSSL/AFpC5TzdjTK9Ek0Lw5Jyttdx/wDXO63fzFV2 8M6A4+S71GFvfY/9BQHIcFSZruX8HaY6/udblHtJa5/k1Qt4GXrBrVof9+Jx/jU6hynIoalj 4NdP/wAINfDbs1DS3/7blP5rSf8ACDa5/BHaTf8AXO7jP9aoXKzFVxt6L+VffPwz/wCSd+Gf +wbb/wDota+H38GeI41b/iUXDr/0z2P/ACNfcfw9ieDwH4dhmjKSx6fbq6FcFT5a5FZVTow6 1Z5F8Wk3+N7wZYfu4+h/2K818bQOfB95FlTzFjaMfxrXpXxXP/FdXn/XOP8A9ArhfECJJo1w jjK/L/6EtfHr/fl/i/U+vnH/AGL/ALd/Q8ns9K9Rmtu2sUjHzCtCOEdFGKtRQp6V9nynxtyv bWm9l7LWpkRphe1PiREXpTJQhb5auKIkUp8u8Qx82Xb/AMdWomhJ5cMFFXVhP2lHYfIEOT7t t/8AialYIavlEZLjHaq7Rv1YYX+7Wu0I61VuR97jH+7RyjuYF3NIW+XcFqqtxKnGWrVuY8/d qhJbvWcihi3brUq3r+rVB5DjtUsdq7soRGLH0G6pGWVvnx99qmivX6ZqpJbmF2SUMjjqHG1h UsVu77dgZ2J2gAZyaYjSjvXCty1fZvhL5vCeiHPWxg/9FivjS70TU7LTYL26sriGzuBuhmdM I9fZng//AJFLRP8Arxg/9FrWdVmlM8Y+LB/4ru8/65w/+gVxGsc6VOP93/0Ja9M+KnhjWp/E Fxq1nYSXdk8aD/RzvkTAwcp1b8M15bqEySaddIj/ADphXT7pT5l+8v3hXy7ozWMUmuv6n1rq wngnFPaP6GCo9qsQAk/NUCED78iD6nbVmK6tE+9c2+708wV9dFHxhYUfL81CpzlttOjIueIU lm/65wu/8lq9b6Lq0wzbaLrMo/vJYTf4VXNEOWRRUZLU1k7tW/B4O8UT/wCq8N6p/wADjRP/ AEJxWjF8OfGMwX/iRFB/02u4R/JjR7WHcfJPscY0eage3J7V6Tb/AAo8XSH5oNLg/wCul4zf +gpWhF8HPEDf67UdIi/3BNJ/8TU+1h3H7OfY8ektCai+xf3hXusHwSuWX/SPEMS+0Vj/AIvV +1+CdgP+PrW9Rk/65xwp/wCymodWBfspnzy1l7V6H8O/F+l+FdDa2m0+4ubp7trrzEA+Rtmw bcn72C3516pH8GvDUf8ArZ9Vm/37kD/0FRWhD8J/B8Y50t5v+ut1Mf8A2aolViyo0pI8hl8f ael89zaaB98rlJkhYIN3zsrbC24hV6naPSoW+JhhhWJNKiGCW3vd7X+7t3ZRR857t9duN1e6 W3w68I24+Tw7px/34d/861YPDWh24/0fRtNi/wBy1Rf6VPPHsXyS7nyn4u8V3fiuGCO7jiHk l3AgdzksqL0z/sf+PNX1d4UXb4X0dcdLOEf+OCtCK3ihGIYkjH+woFS1Ep3HGFhKw9e8N6Hr U8f9saRYXzr0eeFWYfjRRUGo2Hwd4ZtVX7P4e0iP/ds4/wDCtC0srO3/AOPeztof9yMCiigC /RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//2Q== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcQAXANU5AP/MVf//zPz7+/vlmWZSX7uWWo1xXdDE0J2dwzQqZEtLk7Osm92qRO2+ VoiIVf3XdJiUaQQGavHu8srJ2nt6rAAAZu7s6goNdtTU5eno8t2xV0Q2YQAAXCIbZLihVMql Sy4uguLf58K9rqahftbM1v7PXsyjWB8feBEOZQsLav/RWLy3yv/+3xQUcFhYmfPHX7+sX87B zmBfndCyWuGxSuvFZ+7BWvrHU9nCcP///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAA AABxABcAAAb/wJxwSCwaj8ikcslsOpOCqIBEUZwiJwVlIghBHOCweEwum8/otJo8EpEsgqM0 Q4nY7xFOShYSsAKAgYKDhIWGh4iJioIDAzgwIwdRRVETIHiYeScrfouen6ChhwM1MCJwRAIZ l5mYHCcYAg8AtLW2t7i2Gia3BQ25wMHCwwAlDwMBAyUzCxJxQgJ1rZkcLhkBJcS1BgW5Bhu3 Fd3a5OW4xwM3ps5CEy0RXAgX8/T0dimcA+QmFeC43+HG0dJAwBw5A7yGlSDVYEQsIRQ4RFCA QEC9i3Y4yJCgTxsBAxV+1TKhASCABt3E2SpQQZfAWyg10EIpcuQvlcQePGhgCpUC/zvzok24 MLTohDsgMrAg18HEx1oEOiTYAM4Eig0EcAJgWaGCAQAGOmzoINNW2LEATIjt8BVAvw38uvob 9oDBjBF9clyJMK+iggt//265k6KPNrVgC6YNCWAqAAIFWb5kOZAxZFsNKiRM+yssrQqK3b4U VpcGBAwSctyZlyAa0dfR7nAwTMxAQQ2MTQJEMU7r1pZg/RXoYDYBrgIgPwv0LawEA9MkUu+l N2FoYAUCEtipEIH2sAQfDaD4qhscTt+Ug9NKT8tk+w6QgWtlHsw5AwgHUv/kOw87hf9bDLVd UksNo8F4BthWUHkA8KbcSsCZNFxxtnTQTXrzjVYfAx/gl/9aRPzNw4UUrt3hggQB1BYaPw2w 2Bg4l0kGYWW/XFYLbps5mJxotdAHzAscjhBdDkdVQA9F9SDw1x0VdSRMAi9Z+JhUVKV11QYO 1tIACgmQt1ZZ26wF1lVZPUjLWKHVRwMDHiyAWg4CyADUBRXJQ6cA8tihwDXZGGQLSZhpOJNA Ggh6ki8DgZkLosM0wCEEK+TVxQkSAaZkf3ly0AIXA6jg56eghmpLCY6yucAbcUSxAqXcTdNC RQHYcIOotNbaXAkvrMnmCDHkBWcUGLiQRyYdKMBFADUwoOyyzDbr7LPQRivttNQ++4EHvKL2 DJzOZLCCDJdwUAEILiCQwRQeVKth7rrstgvtB9dCsEAM2lIigTMSZBDCvhngK8IXawQs8MAE mwHBCAusQEII7BgRxb0kqhICCQdUbPHFGGes8cYcd+zxxxyTgEEIcGwLhQD3pqzyyiy37PLL MMcs88wrT2JEEAA7 --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhQAAMALMPAMSfavv49Kd0JrePU9zJreuYEefayMaONbGAN86wgPfGVfLq3vKwM8+I F92fOP///yH5BAEAAA8ALAAAAABAAAwAAAT/8MlJA6F4GTzN5k9gLOBDBGXaCSS3DEAJDChn IF8m5CoXAIIEyCA4tCgvxIWTCNYoCQTg2UMiCgjqY5E4NISY7gFMMQAaB15ogD2qRAMEosg4 COTxOYLhuMvlAgIODHoDeXR6CIcHCgd/ACcpAVEFDAoKBZmKMJWXmQ2KB50Mn3EDDgWXpAUC hqiemlM9FggNlgUNAhcvogqkRQGTV764CCQ3g765QjcHt6yRVRYNmQVjHWyfxhI/1JkHSw8J ANVfNQTZuAlakgkNuQ0OA9isteASZqAC1mQADvANALTwl8sLjSrc5kwZcIcbgTsECMgB81DX jSDcgBgBIOcDQxoANxy5UbFAF7cmJBbMaHEjhrgdEl4cvLFOwsMNC6ScY4FQBI8AGrZEi7lB hBujJtQQOGaAigd2EQAAOw== --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQABLAEsAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wgAR CAC3AJYDASIAAhEBAxEB/8QAGQAAAwEBAQAAAAAAAAAAAAAAAAIDBAEF/8QAGgEAAwEBAQEA AAAAAAAAAAAAAQIDAAQFBv/aAAwDAQACEAMQAAAB8dut9V4nG66orO6CTUYCRYAgX5jn5dTt 2TbDn6cz1458s6dc2cokx2ea8Z3RZtVkES4NDmhTs5YJVdTy6MEPRzUPnjHVNqrWadp2klHa swjUZNLthTDl+EZl0I2n0maZYbJXGc6UNKraaNXlojtCsjxmebz7UVordSIT0I6ZZao1XLLT G2zjFGpadpLWyWhnotZU65SdV8z0/I4PW833vD9rz2cnf1/Gzy0R74ZoaYXGcYqXvC8xe0rQ NapohcfrTtj8v2Mlm8n3Mur5n10p3n0HhxjePTzQheFlgdLHt89kGm0LQOvf5e7l7Ldi0724 nQzJxcuTxvfzEzlWPZ5soVhdJHCpLZ7DabZrRGnVhrCm58TTtsMorac6qydmTpLkXjWaQpG2 mKVPK5646bZayXVTNSW0tnZG0ERTVZ8IeazcdkSoOS7KxUQdlrnox0VzUmmmmV5jU2Zk2juc GuslOrNEbNPk3PZE6sEx2Whok0qM2HGOqrd71dw6oHeS44oiq2afKloT0oz5zhTe3UPnG8zM HtDoF8dAAA2OBsAHcAJ5wCwAd//EACUQAAMBAAIBAwUAAwAAAAAAAAABEQIDEhAEFCATISIx MhUwQf/aAAgBAQABBQL4QhCEIQhCH+O5me05h+l5jPoefb3l415hCEIQhCEIe95x+p5b7vmR 7zmH+/MIQhCEIQgl+WV2XVHVHJ+Jv+vEIQhCEIQhBL8uP7Z7OPSRyaWuPX9IQkQhCEIQhCCX 5ZaS1v7ab0M3/SEJCQkQhCEIQnh+Gyj/AGhCEvEIQhCEIQaGMfhCEIXxnxYxj8IQhC+Ot04+ TfuePk+pnWp4YxjGIQhC+G/tjeGuPHG8nEpj+uZjGMYxCEIQvPN9z1u5j0tzw/TU40oxjGMY hCEZIjr41xdt83oc8uVx/T5d7XXKmGMYxjEIQjjc3nMF+llGUrEdBcaPU5/Bp3/jGMYhCEIe 9N929Lf5LZ3Ozj3XvfYYxjGMQhCEfUPqHc7o7ndTyxjH4QhCF5pS/FjGPwhCE/FKUpSlKUbG MfhCEJlKUpSlKUo2NjH5XilKUpSlKUpS+H8aUpSlKUpSlKX40pSlKUpSlKUvwznSf2tydsHb B2yLWDtg7Yj1mfHtk7K61VGe64+3vOI5uVb1S/6qU7I7I7I//8QAJBEAAgICAQQBBQAAAAAA AAAAAAECEQMSIAUQEyEiBCMwMUH/2gAIAQMBAT8BbLLLLLLPtfwXjL5ojVHovjRXZT7XwSNR xGuSQkdOeLG3LIzqk8eXL8CaofBEY2KJRCGHxqzL7k2h8EYJpL2bRNojlAh9Z4vikSdvjGbX 6FlZ5WSnY3zssv8APqampoalFCRqUNsXosssssvv/8QAIhEAAgICAgEFAQAAAAAAAAAAAAEC EQMSBBAhFTFRYYEg/9oACAECAQE/AbLLLNiyyL5H0bcj6F7eRsbGzY2Ni/A5OyLdifgbGxyN jY2LKExDY2NllliYmJ9SJDGzmQy5Eo40ZORl4tRRwss8mLeYiPUiRJlmKcYyVnOyZsvIlSMU dYJCI9SJGReSmUypDw7eWRRHpkkSjZojQUaEhIiumhoaKKKEhISKGhoaNTU1FESEiiWaHybX 5R+H4fhRR7Cf116Xh+WcXDHFiUI/1RRqf//EAC8QAAIBAgQEBAQHAAAAAAAAAAABEQIhMDEy QRASIjMDUWFxIIGRoSNAQlBScJL/2gAIAQEABj8Cxv05SW8NsfQaY9x0vbHz+xNp84HEL2Rt nOWOiXW0d1neOnxHVjofU18jVV/k7j89I+tt+2OjU0dNdUl/yOSMkZIyX7jU5tsUqmre5MQL 1x2XsV+JKaiE1w9semnzfChfy6mb/UcLEzM+HNzNGppl8tiE7iWGiqnzI9JIkRffjCTlkOh8 3J9y+FS4yG4E4FbIuh+pdCxPl/QGh/Q7NR22dtmg0Gk0GktT8XbH+GWogyJ5nwtj7m5//8QA JRABAQEAAQMDBAMBAAAAAAAAAQARITFBURAgYTBxgZGh8PGx/9oACAEBAAE/IcgsgiH0QAA3 QZ7u/bp1t3PsH9+YYl4HLp/e0wMcd5/x9+bEjVjjsEEEQh9EAPhzWGXig65/l5rGeGd9E+Dv 3duSfMEEEQh7wDP3Fqpt+Weo5duHm0N3+mGB1PuXVggiEIQ9wDP3EnEfe27Z9v8ArtIOlrrz bXNHc6IwQ9AhCHtA1n7CQirdwiF+UJjXrCEEPYAQ9oGMSX+Ev+V/hT/iuemEIegEQh7AYx9A IQkhCEIQQWWejJJJIQhCSEIQhBBBZNy3LJoADwdshgAx5ZJCEIQ9gEIIIJbRBzjYGMPnZ3Qt ZvL1s66Hg7CHoP0RAi5PnG3g+0BPej58f8uv0/BNhhz18/TAQi4uXi4wPGQOjZXCGYTc+c6z 9iQF2wuqLHGX2Y+mAm/+YNhy0Liel0rUaamwNV15nY08uMkaC8d7VnR1zO9r4yfD5nNnxPk8 3Ie7OfeAvQpg/sjuYMsOwGWB1Xu27OXOlxOeVmOmHmwDMD5sbuc+ZS9kUpylC3jg4fxY568/ xZ3vkZdGxh167PA5/pLLLKUpSylKUoYfYNllllKUpZSl6AxCHsBjH0ClKWUpegQhD2Axj6gU pYZQxCEPbBrGMYspYYYYhCHuIYxjGLLDDEIQ+gAMYxZZYaqkzl4PHMidJ0edv9SOTn+405Wf e1uvH+LmeUZNe5MQp87ba2sr4nfDLZ+/M7hjTp1yJjV9r5H6jn0+MZY4/wCRZ04Wfm+xt+G3 4b8N+G/Dfhvw2/Db8Njw2fDfc9Zv/9oADAMBAAIAAwAAABCI2KgGK9Jr/wAWdz2Fp2QPO2YF mJb40ORQJai/LkhMXzd6sIwrc8Mw6Aw0v5OwGyyoYfvwMyy0b1if+1S9yARcC5Mms+ghNQkU U2cMnAXQ/ERdRB9cejBfhBcB/8QAIhEBAQEAAgEEAwEBAAAAAAAAAQARECExIEFR8GFxwaHR /9oACAEDAQE/EIY+gCKw7SPnZG9Syy222y7ghv3/AGcGe/38z2ll4zkOmQMIRdWe0vAcJrxI eeBIbZjmzjHgP7BHOAdnvGsIcvBhpKGsQCZcJZDpfRZSHHj++YfN+kY599rDAUSeT9/8tB+e WPRJ6+fAsWScDHCxeAskks9GQQWXb3k/M/nftPXzahW/lgfPBBi3Rhbt27duFDx//8QAIxEB AQABBAAGAwAAAAAAAAAAAQARECAhMUFRgaGx8DBh0f/aAAgBAgEBPxBjGutKJ5VKGD5ScPFs FdAjzQkH32nhTj7+ribLHQIZmIK5ZgwEsBspa4xnseGUp6DJHzhuA+IxbtficoeNQRxJep46 klNheOLNL0GsdQhO8LHcsZpMUw2AxCCOgPaaxj6bCA2WumfgvJXQNgYg3gPqWJwZPSViue0Z XEKV8hmXM4k+PcP5ZHMHnIbMWEGwv//EACgQAQACAQIFAwQDAAAAAAAAAAEAESExYRAgQVFx kdHhMIGhscHw8f/aAAgBAQABPxA4A5CBBPjPGO2MMOyAbhbXq0QKuokezHTU0NNOYCBawXUo by5YM4mJNyCF2BhaWGHuXLTzmoWNYecEE2Q4hl2xl2XMvR6FMZvH3r0IqyQvKxFazkY0xAAy wUFG7DvlXN5bl3YAwAakt1BfBEshaVrmPjYhJtnjwu2O3g2mllf3FE0hwFVep9/SAHJKpZoz rpa+kGUKXYJRdDr95QXJusFb3vAqOVpV6tc90OzCThsvC+h/3C7UEq9C773R/ssKak0Iltfp 6y6rIWlTdunY/P3MH4tAqUvTGGZng/R9BStDDbPGO3gbM9E/uAyFQlKVX6/EQVUoApg1pFC9 uDkeD9HMoO3wDbDhvGijZhGyeS5GBas2o9iuI6PIdsTYhwHkFWcimb6Ba6ScJ567+pM30ao1 JspLAvFGP4g7d6zI5bNNBmdKvS7GNUVpei/xyQa3CyQ6Qw45ooQUDsqL6fmUhLdrfgI6aWeF K8EB17wQ10uVX6leX/D14geAdYM8IhhgghgiRuwbHykJN0pH21lLAtWPEfkqAgDgWFtHeCCG HEMGeHonTOmYWFYXv0lbZNL6XPvSunvAhsiHaFh39SMnpjaXuMEgO3sA1l2JkaufMKqqsjs8 h0vDqjij0jlw1WD4cR6i8MhZ+4HbiO+kTpjsYMTDo6VoQCAUp0Z6xWUFH2qASMAACCKt9A3G bFjoa/iDsgDoddvq5uASrIF3esceI9Zqj0jmKPgH0KmAN3nPa51G+l0B5iamxr1xrCQgVCpi FjItcqrrBs1lbt3lPAorDPeUKgtXZb3gtqwrDNcSUesWeFpcgJHlQwAbw1hkF7XTpsNoO83K 6fMAMlUA/wC/xKgF0UuqZxLEGRWemR335XnUmtws30A104h+hffs30xbgHkFUTV4pn+gqU7v D5x+hTBc/NvW/wAAk3zzjv4G/wA3W5uf+HdhJwWXfN2b/wBOrBo3YSb558PnGXlhd8yTMDmL vTswRIHlBg59z0reGivyGiyzMwAEX33/AHrLGGJRTsYe6Ostf9u4wjIVS4V57/uN9YODKVDg 7Apevr3iylpEmpfsx7DHsPpO5ek/xoZbPqEen39KgqQIKZM5ya6bR+LUFDH4uPy6FoKg0mtv 8SqhGtb9vEW0qLqv3Nr1/MD8vzM/dPef0p7y35T3lvznvM/Oe8z857y09095/SnvK/Ke8fmT 3lPu/MexKPSNqP/Z --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACgAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAFBAQGRIZJxcXJzImHyYyLiYmJiYuPjU1NTU1PkRBQUFBQUFERERERERERERERERE RERERERERERERERERERERAEVGRkgHCAmGBgmNiYgJjZENisrNkREREI1QkRERERERERERERE RERERERERERERERERERERERERERERERERERE/8AAEQgArQCgAwEiAAIRAQMRAf/EAIwAAAID AQEBAAAAAAAAAAAAAAAEAQUGAwIHAQEAAwEBAQAAAAAAAAAAAAAAAQIDBAUGEAABAwIDBAYK AQMFAQAAAAABAAIDEQQhEgUxQVFxYcEiMhMG8IGRobHRQlJiFCNysiTh8YIzNEMRAQEAAgIC AgIDAQAAAAAAAAABEQIxEiEDQTJRcSJCBBP/2gAMAwEAAhEDEQA/ANmqfWdaGmZRkzufWmNN nt4q4WQ849+Hk/qQKT+a7ySvhhrB0Cp9/wAl40nUbm5vohLI5wJOFcNh3bFV29A0l9MnTtqn NFLTqEWUUbU/2lQtjxlvqoqUKFKqcx4ozHioUoJzHijMeKhCD1mKMxUIQesxRmKhCCcxRmK8 1Qg9ZyjOV5UIPRkpicAhsgdsoR0LjO3NGQPT4otzVo57/QIG1kPOPfh5P6lr1kPOPfh5P6kF BaVIdStRStBWoTWjZDqEPh1pU7eRSlrl+qm0Zdu31JvRw0ahFlNcT0Y0Kr8r36xvFKhCsoFK EIBCFKAQhSgEIUIBCEIIQhCDncdwn060Wwo0c/TcEXB/jci2rlFeO41QNrIece/Dyf1LXrIe ce/Dyf1IM/aPDagmhPZ204pjQsL+LmfgVxtPBjjfNM3xKFrWsJIGNcTTHCnvT2nNjbqcXg4M NHAVrSrK09ShOfGG4UIQpQlC8lwBAJxOxekApUKUApUIQSoQhAKEIQCEIQcZ2GQAA09q6xgi gdSvRgqrWHxuyRukYx+Lg2QkDnzG7bvTmmvD4s+YPzPeczdlSfp6PigsVkPOPfh5P6lr1kPO Pfh5P6kFdoIkzOcx+UVGAYHFxxNOIFBuxXPR8NSZX7nbORXrRmxuD2vrmOWmVriaY7Muz14E VCjSG5NSY2hbRzuydowKDdqVCCcoqdyCr1WUVawbRilG61JAQJBnb7Cuc7zK8vO9KvjDlhdr nMd+vrnWTZprS9iu25onVptB2hMrFBklu8SRGjhwWssbsXcQfSjtjm8Ctddsub2evrxwZQhC sxCErdXzLfA4u+0Kql1KWTYco/FVu0jTX17bfpePkbGKvIA6VLXBwDhsKzFS81canpWkgIdG 0jgEm2U7+vpI6FCEKzJXahDIaOYXE13Fgyin5A7V30yQyQguJJDnNOYtJwP4gBK3rJbh5gMQ cC4FkjmBzWtp2j/VXdyTentcyIMe0NLXOaKNyggHA03VQWCyHnHvw8n9S16yHnHvw8n9SCs0 VzgH94MBa5z2yCNraV7xpjy38FOlyCXU43iuLjtNanKcd21GhljXOc5xBOAAeGjYTjWoOzfh iuOlPy37HNNaOd68CieW/XmbuO5FKi8dvAK6i5jeKONK4YqMxbpZVE4LicF7lcAacEsZVg9G Tw6Fyf0u48OXIdj8PWq3NVDXFhDhtBqplNte0sbFK3tz+uyo7xwamGPD2hw3iqoNQuPFmPBv ZC12uI4PXp2288Qq9xcS4mpK8VUFy8rF34dWlX+nOzQjoJCz7Sr/AEwUh5kq+vLn931OoQha uNX6nNLEG+ESCTsaASabsd3GmKatHyObmlBaS51AdobXCvTRI6nmlAiyOIruYxxIp9OY4c9q Z00NbC1rQ4AEikhBdWvQf9kFksh5x78PJ/Utesh5x78PJ/Ugo7C3hmDjK4NyEONTQlgBrl4k mntUtdHHdB0GDaZgK1pVuyvQU3oRdlkDC5pq3tRlgO/7yMOSTt4i26DZBtqceBaTuUbcVfT7 T9njfS/cmbWWS5cWvOAFUxp+nsJc+RuZhwbmT0enQRuztBaTurgvL3/06a26+XoXaS8KbUAW EObsOCQDi48StHqVnnicYxUgbB0JKytxAKkfyHb0K/r92u2uYmbZ4c4bKQCshDRwOJVhBaxO wJJ9S8PdVeWOocNynvU3W2cr+JuSMNbuFBVZq5t5IXEPG3fxV7FPSBr3bzT3qJSJBR2IXTds yfpyaZ1tZkr0E/PaNrUYJN7A3eq5a/8AXWBq09vF4UTWbwPeqbS7YzSeI7uN95/0V+ttJ8ub 2b9uOAhChaMVVq8AcWyBmZwDtpcBQf078fcUzpJaYBlAaMzqZa0OO3tY4rjq+YtY1rgCSaBz iwEjHb0cDgU3Y5slXuDi5zndk1AqdgPQgfWQ849+Hk/qWvWQ849+Hk/qQVuiRh2Y0ZUFtDIz PxNBw2bdq5WP82oDO0Crn1a3YMClrHNn7Dyx27Lv943e5MaOyt+xvEuGHIqm8t1snKZ4raAB ow2ALkZsejiicOiwJw3FQcuXABfObeu63G88u2Yvl0jfWtFxuog5viN2/FLtYWOJY7vOrl4m noTyXaKQNIjBqQfT3q3W63trU8XMKxwySEUFBxKZZatZ3jmPQvd04MxSsNzV2Vd3rveSxe7W zPBi/d4NuwDCp+aQtLsk5XKx1eIuia0bR8lSwRuzigxXbZiqevF1tq2lNW1SVrZvu38Ix3nf L0wVwy1GWsmASc+txQdiFuamHAK01+a497MraKJsTQxgo0L2snL5iugey1gHInrXa08yuJAu GCn3M+S1m0ZtKheIpmTNEkZq07wvaslXXEoZI5tzG6SM0dGRHnAwxG+hr7arvpzXNi7TclXO c1lAMrScBhvovV08sZmaaUPR1rpbPdIA5284cvUoz5wt18djiyHnHvw8n9S16yHnHvw8n9Sl VQ2hox+3ZuPRw3rtoP8A7oeZ+BXKz7jz6bCu2hD/AD4uZ+BRLfOaHCjhUJR9g36DROIWe/r1 3+0TrvdeFJcxywdprTgKYY7fh079gSNjFLHK+ebDNSgOBwWpJA24Li+eD6ns9ZC57/n1xddb y2ntv4Zm/vC85WnZwStrIRK01+ofFaOVumSHt+ETzAPuSE9rZucBakl+2jcWinNX19U0kkTN 8/C2ummSQMbuC9RxRwHDF65+I9ozEULscy8CUNxKvtfn5Ri2YnDvO4lpqsnM05itDLdseMoK rZrepwWcrLfSxUvZVLkUVo+3c3clDbukcGsFXHAAKZWTvpV3cQyhkAz5trNx+XNbME0FcCq/ StMbZR1djK7vHh0em1WK6NYknctkqHA1oey0NqdnNdrSob2ttccKfNcbrxN5aGV2mtR6wV7s SCwUoRU4itD7a1Vf7N79Fish5x78PJ/Utesh5x78PJ/UrsVDaYseN1OHQV20H/3xcz/aVWpv Tbj9a4ZNSuWp9dCmUtzqOqR2Dau7T9zB6YLMu1+6uZMuYMbwb89qVmuDJmfIak4lV8JOeqzt y064w0Gdz8XuJPSUpcZVw8ZKXNxXshYzW2tbtJHeJuZ4WutbT9a2L3d9w9gWb8u2LryfxHf9 cfad0ncPTcthqLstu53CnxC2mvyy7Zsju1oyhpGFEncaeH/9bsp6cQnWGrQeIXpXslVm11vi qB+nXDTsB5Fdo7SYijm+8K5QqdIvt7btOtVrdPc7vED3pmC0jgNWjtH6t6YQrTWRgEFCCrJL XHjf/OmWnCp+Xx5LpagAYEnH6vQLopbtCjHnK3bxgwsh5x78PJ/Utesh5x78PJ/UpVZ9ti91 v+zmaGl/hUO2tKqLi1kspfDmFHDpBTFlOwsbDOD4VZO1uDnNDa/8etM2z2X+oReKA4Oa1rwd hIZTqRKqMlV48SmxbG48qWshrG50fLEe/wCaWHk5lcZ3U/oHzVeq/ZlvFJTFhpk2oyZIh2fq edjVrYPKtnEavzSH8jQe6iuY42QtDI2hrRuaKBJEXbLlZWcdlCIItg37yeK8akwyWsrRtyk+ zFNqCA4UOw4KypPSp/HtIpOLQPWMOpOqk8tuLYJIDtilez1K7QoUIQiAhCEAoJoK8FK8uFQQ N6E58lIb9s0Lp2tdlbyqaLvaXAuWiRoIB4pRtu6IRCJwLGdlzcMc2/2puzg8BojGwE05ElVm fltvNMfx/Pg8s55l0ya98N8VDkDgQemnyWjQrMXzuMXlg0sMVW1riK4+rkvekyCXUonBoZU9 0f0lbqXwvroq6T9PxBl7/wBOXagsqIoVX/xb/ER/BvzoLChUJD/G/Jeh+r0oHVGYcQlB+p0r 0P1EFXoxyXV7mwaZARXCveV2ZWfcPaFyH6q9f4vQg9eKz7h7Qo8aMfUPapH63QpH6/4oPHjx j6gj9iP7viuo8D8VP8P4oOH7Ef3e4/JBuI+PuKZHh9CkZOhBS/o2o3v9PUn7XIwCOOpA+5Od noXoU3IP/9k= --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD//gASQ29weXJpZ2h0IERDSSBBR//bAEMAAwICAgICAwIC AgMDAwMEBgQEBAQECAYGBQYJCAoKCQgJCQoMDwwKCw4LCQkNEQ0ODxAQERAKDBITEhATDxAQ EP/bAEMBAwMDBAMECAQECBALCQsQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEP/AABEIAMgAyAMBEQACEQEDEQH/xAAdAAABBQEBAQEAAAAAAAAA AAAFAAQGBwgDAQIJ/8QATBAAAQMDAwICBgQJCAkEAwAAAgEDBAUGEQAHEhMhIjEIFDJBUbMj YXF0FTY3QlJzgZGxFiQzNUNiocEXJTRjZIOTotEncoKyROHw/8QAHAEAAQQDAQAAAAAAAAAA AAAAAAMEBQYBAgcI/8QATxEAAQIEAgMIDQoFAgUFAAAAAgADAQQFEgYREyIyFCExQWFxgbEH FSM0NkJRUnKRstHwFjNic4KhwcLS4SRDU5KiNUQXJYPi8QgmVKPy/9oADAMBAAIRAxEAPwD9 U9CEtCEDvG5AtG3JlxuRSkjDQFVoSQVLkYj5r8OWdCFWUrfWY4ywwzFp8GbN63qkd15Dde6Q 83OA5TlwHuuM63tG63xkroitvUGXeLcCo1I4cmudAPcMZgGlwiZ88KvlrS21JIlKr1cdCPIW rTldPPjCUeV+zC/5awRCOuWyhVRvN6V0TYS4oVBuql3VPakMtvy5cCcGYoEvdEbcLLyiniVE Ue2oymVFmruOBL79kff7kq+BNN3K7bWvB656JTrht64JFRplXiNz4Mpk3CF+O4KEJoiqiplF 7ivkvbUuYW66btlcKk0So1gxRfWKguff9J/51ot0Vh1KY4/6oEh430FCJlCNXEFVVEJR5ZRF VFRCVMLhfhoQikeZKMOQyHE88ZMs9uy9s/HQhcHp85vl/Onv2OL/AJ6EJq5WqkgpxmPf9T/9 aEJm5clcBcevOJ9fJF/y0ITN68a+HsVAl/5aaEJkd+3O2PJJ37FEf/GhCbPbl3aA8hnN/wDS FdCE2Pdq7Wh7zGVX9QOhC6w93LoPJG9HJO3mwn/lNCEYh7m1940Awj58v6PGe2fjoQizN+Tj aRx5WQQs4yKJnHn5rrd3QtfOlkkHHhbRSDc8mYHUBWzHyyOFTKe7KaSGIlrAWaUA71J4xk7H acLzMEVftxrZbrroQloQloQloQoNvYuNrq9+ra+cGswQstXrYca83LTqEyQUZuhT5En1hp9W nUR2K6yTIqioq81cbz+r1BzRPNTzb92qfEn5zDbDNpihNq2Tb9Drx1CMMpyYwqtC9JkkRAPH iiInZMYT4anI6xJgGurUfLhHjrxxglXCfVpGclyfZcl/PhGH90EqNrRCSr/0jrOh7qWNPpLl luVWsOcW4qsw2ykG8vFAFHiwrI9+7iEiJ79cYwnJVzDVcelQ32jjw9PPyqyToy78jeBLjYvo 5RqHY239rVurFNkWtR41IqCgSA0YlIOVM6bipyITFx2J0hQctSDLlhMa7XbaSqwkJDqo9S/R qWlOR3qFuE9CJtyM8o/gNo2zJhmODa8Rkjjxx+quF9p09ZQiDPouwEedOJfTkMZMdmK56tSF acAGo7rQG04MlCbcFx43xJVIRMj8C8s6EK8LKo9RoNFbpM+pU+WjAADfqFK/B7SYFOovT6zv tmpn7XbljQhEJX52hCHO+zoQhsvQhDHPfoQo/VqtDgTIUCQMhXagRi10mlNE4Yyq48va0IUX XcG1X1aAJkpDdjpJEDgvIXTUeWVTj5492hCaz7toMY1afkSG1UUUVOG6gmijy7Lx9ye7QhM2 ropVXpsgKBcQx5LZNoj7kNwxbVSz4hIU7YRe/u0IT167pMfnUGdxKLHhxHcyOpSnF8PIlTA8 V80VEyK99CFJ5tKotTmg5cHTqQ0+mR55qTQiskEJ0SwI9kQiJvP2ap+IZNmZe0T5KEn9pTLb Ckx6DTapSYkcWm4dTNjiHs8hZY54z37lnUjh9sQZsHZgn0mNo2Grfhf7HH/VB/BNT6ervoQl oQloQloQoLvb+S6u/qmvnBoWYLNVys0+TSKe5Oeig+wSuwheIfG+j7CJxQlTOPfjURVtXQfH kUfOzHdBFArWh3VHuR5+vXNHkiuASNGjI02juE7qqpnH7dSk063LDpXSyFSANE/a0Csg5cd6 My6y8LiNGQur+gqIi9/s03lZ+XqA3yrl62flSlhsLjVQ7n7lbo2HuAY0OglULcbh0/m30D4t yyjVFx1DMQUkbJGG1c4qhITIoi+LT8NmxaNt9xsuTyDvbuJJNisBTbdj0Ol3LHosh9pqUS11 koMt4XIpOLxaafcYaBlU5eNwUUiTKaSsIUoYNtCNikO2e/V8XheNOocqz6CtLcqDNOkVWAUr pPE/HmPC/F6goKNtHFRpzmRZNVxxTGspNaLh+Ljn36EI3GARFcfDQhNpX52hCHO+zoQhsvQh DHPfoQhslSQVFCJE9+Cx/DQhD33XFHxPOL8fEvfz+GhCESCXmpl3Xz75XvjH8NCF7AcMvDy7 L2x7tCEaCqUiAcKHUqpBiHMeSPEakvttq++vkDSEqcj8l4jldCF8TYFiXccYpd1R+pMeWite pVkB9Ye5czip3VHHUVMq2niT3p4tRc/h6TqZaV0vj1Js7INuKcWJSqVSKQbdFqhVGNLfOaso pIPq84a4JUMey+z7vLW8hTWaYOiaJKtS7bGwrQhf7HH/AFQfwTUilF30IS0IS0IS0IUG3oHn tjXQ792W/JM+ToLqDxDVCotNdnwG6IZb3OUIfinchL7rmBa8qzU5V2ZENI0ik0+QsY8tOSG0 Imy5eY5TsuUTXHj7K846zfuYY5cF0LslavkvK3XzGSHiRtK455KpqDmCFS5JnkiChZyOFz27 e/VSrOK65XGyKacIQy2IRjAf7c1JS0lIsajQwiXlUjt9psKc5xHA+skqqg9/ZDvj7NdT7Ef+ lkYbWfvVZxA1dMaLyqBXjunuku5YbW7RwaaNThwxmTJc8cBhQ5YDkSCgj27+arrqEwRDqBwL mFXq88NQGl0wYRPL3csFZm2V2Xg3S2Kbu7VKHTrrOQ42xHi1ABV+MvHpE2HNVVVVD9n4a2bj YKlabMPCItVLUd61YI3HRwqTdBmV6GlRl4VmE5MAX385VMNkWSTsq/v0pepE3WWnNEbmtBeU vcrbufXFtqHf1uyKsHnBaqLSv58/JD7+XkirrUJhtYYqMiRDa9CKiFtekxQKzvhXdszmUCFb tIpgus1x2ooqT5akz9GCqqNoiI4fZF5ZH7dItzF7lir7WJGX6kUndCG97lZFy3zZNszY0C5L wotLkTMdBiXUGmTez5YQlymfs04vVhmqjLyxCw6UIGuVQrdGhSY8CdWqbHlTQ6sRl6Y2Bvh5 8gRfaTHvRdF6UOYbYcEHSHfggbN52ZU4lQnQLwocmLTP9tfZqTZBFyuE5rywiKvZFz3XWsTS G7ZW4bnob3Cqk333pqdg2tbl4WA9RaxTKrUjp8qQZddsMAhJxIDRELHPsqaTvUDWq85LNi7K 5RC7LP1KO70b+V/b3c1i1qPTaTJokaNBeqsh5tw3GEfNUXBCaImAwqZTz1jSptWsTOSNQFpg YRE7ejOKNPbkV2Rv3K2phwaa5RmKUk9Zacuvz6XUROXPigryDz92s3qUOsuP1YZARhAIDcUe j9lIY9wUCqyjptKr1NmzAyhx40lt1zKeeEQs9tLXqTanGXe5aSF0V9wK3b8d4mp1cp8dWXgZ dRyWAkBmvhBUUkwRe7trUj1U4jNS7XctIF4Rh9rNVFErN9bzxrptKtvWuxQ7fudmLUH5uYMl ung44vFh9BNG3Vcba5OLwXjlBJFLSDTt5KvYfq5VIps5goALZfq9y+XNgK9HoLdSK+ttYDUu mNW2zUDkmERjohEQKsySgnUmmsXxgCp24fSLx7uiO3aVgKclWta6HSr29F+jXjaNnSLXvS5L XqUSPPSPbL1FmdVp+A3GZAyFFIuKK4Jn0/aQicUva1ja1kE62XdRL1LSsNf5oz+rH+GsraBX LvoWyWhCWhCWhChO8/5Mq7+pD5oaqGPBuw+/9j2xUzh2H/Mm+n2YrHt3tT5FvSotFh+uVNw0 OBD6vS9bfaL1hGOSqiJyBhzKquMIWvPVAho5y67Nn+7/AB4fN4laK4OllyACyJQPb23Y8e8a JV/oZbLkCqTIs1lhuSDzr4Nsy3kkEKmKLKZkCgi4P9OHhNHuSWbEcyJSUwI7Op5YeW3V9XDD +3jgsOy8w1aLu/vxV82546Yfhz9MWU5f3Q9+rt2IdSllf5fesYo1XhtVe7pbRXRPutndXa+v FCumNHETY6nTWagDxy2SpjkqdlAkwWuozA3kuT4hos0U12xpbmTsIZlxcXPBVzfV61bdDaih b0uU9uJdG3tebg1A2GuKEDnBxt4U82/GmFHyQlLHnpKMbW7/ACKInZx6oU9ioulG9lzIumP/ AGqZpT5+83pBbh1213m+tRLQcgUiQ2YiCSn4yNNohqvZeb0hUVPJNZYEpn5pZaaer09Mm0X8 vV57RQf0dT2mtm77esPdbaqp2/fUOcIwKzJfeFt981JGxcaI0QUXPBCAVBfimtGxENRJ4eCR lJxuVnGIi6Ud7l3/AEVJtstmNrqv6X9+WBUrLhvW9QoLcyn0/wAaNRXxWCqEOCRVXLznZe3f SIBa5enMjTJf5RTDRDwD+IKu4dQt+9rk3hql8bY3Ne9frEyRApU6nU/1kKUQq+23yVTTp4UW 0TiirgdOL1ENmMzMPCbJGfF93Ivl+36hc57A2fuNTakwRyJ9GeYktnFkLBScAgKZwYoolxRf PjrXSEsxg4+5ItTQxhmHl9NSy3Nkts6n6Vl0bYyrb4WrTKa1LZpbMx0Q5I3HVEIs8nERXDVM l56xElLydDkyrz8qZasIR/FVxGpAPejTuQ2yPBu3r0hSYraGvgyLjBInJfeihldJ6yjJUBdo 73HAXPu1UdusI1+29vrecbkaRI9EFky7+FgmhPGfqDRaSUlpgavKzc60PBBq3oPf+5CriuGq vP7qXhSnnG3HaLQqUEgc8mwktx+aIqeRKLZp/wC3RrJJ2fe3PMzQeRsc/XCKLbnWHae2G3di 3rZlJGn12PJhOuTGXCR2SrsYnSQu+PNPd56VuUhO01mSk5KaazuPL8qkVB26tW//AEhtw0uq DIcSnSIc6MDTvR4PL0+5YRUXjnRrGKXpFPZqNVeddz1NH9+fuVb1+sTxh35RX3CiUW4NwGI1 YqCCpKy2JyiFF7d8qSkvb+zHSA3CWuoESbEX2LbA0kLo8msrk9JGw0odS29rUSwHrp29tanO QZVJhEaAGCyhKreVbQm1Euoid/eulp+4bdVT+J5AmCZmGm72YQhx8kOJXx6OibT1vbel1jbK 3SiUeNPlOx4k76Z+BNIvpxFwlX9Lsor5Lp2xDuatlIOTmZMSldn45FoeF/sbH6sfPuvkmlFK pxoQloQloQloQoRvOuNsq6v+5b+aGqljk4t0B8x+j7YqXoP+oN9PsxWN78t6Bc1tv02pViVS 2uu26EuNyUm3FJWkQgFU6rZo+YGHvQvPXnTC85uacEWhvz4YR+Nr/JWquSm7JMhuyy41HbTq Q1qpWI9xtnn/ACdmuesQKe62rgKshpuOzlUFhr+bo70VFcqLvsqKcrDXmhalZrh3zhvZ72fL DzuXeTKh7LYeTeVz2146c5gs83y7r3VciGug9ij/AEtzo/FR+KhEpob1D7ytz0gJ1zz5e3e4 lNhUepstMjEl55xFAOJE2StFxVV8WunOtOLmlWlappiCSc1I73xvrnbu3u32z+ztfsDcG9Ke j1ywJMuoOOuo0ryo2gh6u2XiJQJAVMd1Is9tJhC1lwCTUZCVplLelZpzXOES6YZ/qXL0SLOq UfY2v1ij1IqTWLsdfSFOUV5R0aDosuJhF7I4Ti6UlhJpu8U3wlKzUtS3JgC34/ujcTYHey9r 4ta4d8dxqDWadaEgXorcBokefVCElEl6YIPIhDJFnWbE4hQqo5UGZqou7Hx5UZu70e95v9NN c3d2e3IotAK5Y4tT0lNOE+2KgyLnAeBCvJWGyTumNbWJSaoc0NSKflXNrejzb3LyJjX9hN09 ubyuq/Nld26La9IuRz1ypNVjINR3FNSM0IgIERDNVQi445Y1rYk3cP1SUeJ+QfhbH48qfVHY rcK67h2lvOs39Br0mygV+p1HpOn+FMykeEmCEVDHBOKZLGixKu0Bx95h10syCHD6/en9q7bm m/Ff34p10UmqUOtwXaYyzBcV5wHmOm26imKK2vEo5oqCWUXsvlosT9ikaKpPTt23BQ23PR9n 0Sw9xdrZ9yUmZVbxdSqRgbaezEZVxUB5wCFFVOXZFHz0WKNk8PaKTelfP/Zd7B9H2r2htjd2 3lcqUWoS7tJ/+dMxnRbwrKAOUIeS8STPhRdFiWpeHBk6a9IeMSjtg7BRYO21y23cF0Q621dp RzbnQBLgAMBhkh5e0qEnu807aLE2kMLCxIusOl84hjWx97VI7dom4m4kWp21a8hHosWLDJqQ 6iJgRcIkRERE8Pv8OixDWGZhxxpp1/Ub/b6XIpxZViSqBuTdl+SKpDdZufpdKM004hsqCoq8 lVMLnGlAaU3TaN2vqD01pL4Rs/xQeJ6OUifam49uza5DecvSotVSE4LB8ae8064Yqefa/pFF ePu03NpQvyWIG5kS/mxzh/l+pSSRtRv87att0S198ItKlUekrR56pDcNqcCOZB1VIFXmLeG/ Lv55TSjsrMF805n8c6eTtEqD7IsNP8Xx4ytDYTayLszt+zZgVhypmD706VNMEbA3neKKgCq5 QUQE8++gibkW7ppyAdMFJUalFTZfRXRM/jnV5QSQoTBCqKitCqKnl5JrYHBdGBhHOEVJp1pV CWhCWhCWhChO835Mq9+pD5oaqOPPB+Y+x7YqSovfwdPVFYz3GapD9h1+PXpkqJBOG71X4jfU kN4MVEmg/OPlwwnx151wxpO2Qmw3C/6R2jwRV1reh3D/ABGdn0Ye5CrIfptxrS7it6mvQ6bT vw3Sz9bEmZCdWa48LANdFEUcq2an1OxN9Pgup7FTrkppJecchEzgBxsyiPB50I8PJb0qPw6U u+yLrAxshva2cI73OretzxQHeQ4+ncyidseENdG7EZNu08rfjhURigxJ4VIYC8FQk4/ZxTH7 tdbIyJV2wvOTG69rdv8AcdYTl7W23U3aflIzvVNswEschyBJlFwnnpApcXdtMZ+ky9Tt3Vv5 eTeU8olNptIgRqZR6ezCgw20ZjRWR4tstp5IKaUECEbAT1qXFhsWhHVgpBDHxpjw+72U/wDG tLvoxS0Su20aZbbITQ2xLn3XIouth1uRJaPVtUF3qsafuRtpXLGpUyLElVVIaNvygFxoEals vFyEhIS8LZ4EhVFXsvbSZ6njLcRtG1UxUvRduSmvx2LJv5yFAgVVomPWqrOaciwm2Ywg4DbA i11m3QmEjKCLK+t+Je2siJI0RecojR/RR3QtmlrR7f3GhsR44QvUIzNVnR4LJNSG3TbeYFgu u1yFxzHMFMnnEXj7et7VgmLB1iTt/wBHjdT8FuQx3GhvsBIk9KO7VaiXMHXpLjLrr4gBuPsq +24KoIiRMgJIQjz1kRHzvuzWB0YlfclI2Bv6DUIsmnbmMgK1yNWqq7KlTuq/0J8ySDjaJyRo kYkR2VEeIfRYzjzzovNz9STdJsnNrfVjWhQDtOz6VbMh5t1ymRuiTjWRE8m4SYRcdk5Y7ppI hLl/sSgMauoS7PJ3XgP14HKaQfmpeW76eg36UYQ61s3LPENgN8K9idTKGQ4T3p7l1Az+OcN0 oe6zrZ5+aQxy6IRT5qkzz42C3qwRhmosxwT6Pkvw1z2pdm6gyZWyoxd/x+/KKmmcLzj+2WS7 pc8wMJGZbbFPj4sfv1Q6r2dKw6NtLag3zwu/LBSkvhNsXL3UPk1GdMLMmY84KeSE4uPsx5a5 bUcV1qrldOTJ7/FCMYfdmrM1T5VrZbhnzQWgbV/Fmj/cI/y017TwhGJYdkCL+i17ArlNShbO vekXWi+rEmSWhCWhCWhChG835Mq7+pb+aGqjjyNuH3/se2KlqBb2wbu5fZisb7gS5ECyqzKh 9FJTTPOMTo8gbeR4EA1RFTPFV5J/eQdec6E0L9WFgx4vLbxErVXn3mKTpWi4OLK7yLrZtReq 9pUqpSakzUXZASDOYw10m5SrJdRXxBfZ6uOquO3JxdZxBKixPOMBs5Q2o5x5dryLOHJjdlPF 0srua1WBa7JLS3CEv/zC+WGntH7Iz2DJMWgZzz6M+m2PlWs/Rhni1UeZd6I8vf8ADVjY/wDU EP8ANkP/ALY/oTD5Guf1E+Zq/Rxlkj+wkHH79SH/AB8kS2paIcx3flgtCwe8Ow4ica5YYdnW ZSL9RJjT5js9UnxmTWPkfMf1ETj3zSG/EUOYqp7umP8A505/454d81z1LX5KTn9SCet7j0gQ 8FNmEvwURT/PST/Z2oLQ9ybOJcsFn5JTnjuQTdzcSCaLwpcpP/kKf5rqPPs8U0v9vH46Fn5I zH9RMHr2aMshS3vq+lRF1qfZ9lxG0JLP/qW/42JUcIlbruJk9dLji4Cmtpn3k6qp+7Gol3s/ kWxIZf8AU/7Es1hIRLWLVTQq7MLwmyy3z8sZ79vr+pNR0x2c6xbfLswD1foTn5MSqZHPmGfh cEPFlET498r9uoKZ7NuLX9lwQH0A67U5ZwvTw2hXAyfJcn7/APH3rqtTmPMTT12lmThn5ucP ZyUg3Rqe1sivEIV8XbunZfq1VnqtUH9WYmXI85kX4p01JMteLBeLjywqZ8kT/wDvr00uEtrW Ll3v/KdgIjsr32fLsv1/u0mette5Z3l8iTR9x4r9fn56zHSD4y1ycX2qY9oca1CHjraC0Pan 4s0f7hH+WOvfGD/B2Q+pa9gVx6qd/PekXWi+rGmKWhCWhCWhChG8/wCTKufqW/mhqm49j/7d md/LZ9sVLUL/AFBvp6orH93TIEa1au9UbiKhRwYNXakkZX1iDy7uo2iLyx5fYuvOFBa/5sye hjH6OcfJHj4Vb6seikXg0kA6Ifim23sn1yxKJI/CzlUHoOttzXGukshoJDoNnwwnHIinh92n WJmtFViG2zejvb8etN8NHpaeJ6SB8sModSsq1P6pe++F8oNUbEnesv0/lVhktokY1UlJJaEJ aEL7ECymlUkunH69FmlWkStXUGfzSHTtqXWl66eq/wB3TnchLSMxkugU4VNAdEVBVwSLnui9 vdrYZC4rSSbkwVurwqm5N6byFUG6PG21nOtNSXnH6i5BlMifCr9FttEFkhcbKIoGSj4lDmoq qiur8xhmgk2JvzEIb0NXP6G/40PG4OXhVfKpTQ3AAofTNwd9nEaCRtPKU5zzbrau0yUDUFha c06YGqFkuEkuGVJV9tFxx04msJ4ZK2ybhAYQ8vCV3P5vxvpBqsT1uu3x/HEhkXdveGqyqxR6 bt3DWp0N1pibCGlTTUHDgOvA4KkYtkBOADaChc0JxEx35a1jhOgsMtzDszqHs68NbXgPUlO2 88Xi6yLt1vf+Q5IpQ230FcSTyqMmnssqwqvuKyLPCUoOKLGBU8Y5d15cdN3KfhIXr3Hcow4r +Tm4yW+6KkfipzZlU39k23LlbgWfDiVOG7R1jsQnI5Py0GSz+EEQlfJteTCO4VSbXl5e0mmU /L4XGebCSehEI6S6PFsx0fLwpZqYqRCWqgtJmekrSgej/wAl49RZ/nCtuyJcU3hdMXBbRVKU XgAlawg4w2BmXic4C+mJXCb7Ym49AI/R6OTh4ftb3AN0WxFVmiuEV9P1z0lma/HoiUmkmjrD kn1hqkAccgV5hVaJ7rKAmDayFDxeNRDPHl4dRksHnK6W6MOLb3+CP3Z5ejyrLUxUCLWVgbfh uIMGpruKFNGR66pQfUWwAUjkOeCoJFniqY5qvJffqm1uNH0jY0vPg1t/P45lPyOm0ndVrK1P xZo/3CP8sde1sH+Dsh9S17ArmVU7+e9IutF9WNMUtCEtCEtCFCN5/wAmNd/Ut/NDVQx1Aiw/ MwH6PtipWh29sG7uXqisfXNMk0+3qrNhzqXDfYYNxuRVO8NtUJO7ye8cL5e9ca810GXF2cbB 0YxHPxc7lc6u/bJvaItb6UIZetCNr7hgV6z2XodSbqBRJD8eRJjxjZjuPKZvF0BNELppzwiq mpTF0ruSqWfR8ufFx58flTDCsxumniX4ZdXEratX+qnfvhfLDXPsQ60mx0/lVlkvnCRfVSUk vB1kRWpRtXQWkJM8tZtWL11ZAz78fLTgWkmZWp41GVe/H9mn0rKkRJqZ3IhHieXh1OsU65NT dT9qBy/N1Jt00iTMnV0GC2ZcHGxUF7Ei9uy+flpx2oSZvkI6nCqXqE/0knJUlilWXDcjnJqH QkyKewyTLLTihG6grM+kUw4OIoJj81URR1cToVCBkSf2tXjj8fHGohudmhJD7rZ9IKl7ly4t ux3Jlv1asw4NNclMQ5EZqIkEnHXgETA2vpANHCcUlXkAtgflrI0vDL8mOlHIoQjnrlw573H5 P/0kjfnLtVDGoHpQepQGXihtIwDSTknPxHnZTixFF0kIZCowiuNtinREU+lIsZTUTPS+D7uW GzlGOW1vc/2ko3u65Ngh+kixQDjx3Ka1UIDaiwyrsMkfRBgiGXnFcJV4+umpEuVJvuq5HUQ/ 8lovEbpa0Y8v0uLMfo8ClW4VC7a+PUvq3138g33RaddUh6ZQJz8l6XJgw4TjDIg1hth1wW0V sFXBCqYLlz747aQmxwy5JPHKiN4Q4yK6MS4x1v26VtdONvNiRcKthQVRVfIkTGPhhdcxiQ6T kVnbMtkl98yxheWFXOOS63iZLbRCvMe/34RFX441hvaWRG1aItT8WaP9wj/LHXvjB/g7IfUt ewK4/VO/nvSLrRfVjTFLQhLQhLQhQjef8mFe/Uh80NVDHd3yfmLfoe2KlqFb2wbu5eqKxlfr 9Hh2fW5VfjyJFPajKchuM70XlHqCicHMoja8lBeS+WvOWGN1dsm9E5oy86PH90VcK9ucqa9f rj5nHw/HHxJttk7VitkzrlS9fRZRrEL8IMznm46CPEHnmkQSNMrn87UljQYDVtm3ej0/S5iU bg63tWNpZ/hyfZVrWn/Uzn3tflBrnFf7zZ6fyq1yO0SM6qakV9NChZzrYVoa7NNkq/VrdJkS fxo5KmNT8nL3JobifSHqfR4oSqjKbjgZo0JuFxRTXyFFXtlcYTVrk6YKYRib5WNKB1Df63IT qMwKZImLw5oajwFUVlST7FRzAKnw76sMtICnjdEm3UYpW+NuOP8Aq1SgvRUwqq5xyiYAVTin mqkamKJ7kHUgDDYlYkJrDs8wNytSnHCng3PhyGX45OKgG0aEK4JEVUVMouFTT9pgblVHidhq Kgo9j+lFTq5VVpt3R0p9SmILTc2YxKGPHSWbgq31BJRUmi6aiiKnFBwiLhUtDo0XQiMwOt8c qjYuPXJUu0vSNq1pVmFuHKgzZEoKFIZjR6i3TDkI1I51GKj8MFJoTbEBR3lklXGBTTWEvRWb XdDn8c6UIpoy1ELkWB6UbINy5O5UEChc3FixjZNJCI24XFf5inLkfTUBQg4gvAlIslqtzDmH 2tQ5fr/UnrUZxDqdYvpBTaPTgr24DMWQ3HYnICzC6zEtSZVGXlajgLggguEWEQTJeHDiKOar k3PYZlJhyxjMuD4zOO/1eVPmpecLxk8suyd06FVKdPu6/wByrx2mHmZkV2YRtqqx2BbUU6QI pC6MheRJjgXfxeVbrlYosxKkzLy9peX1/SLkUpKSr0HhN0lYK48SAOPqTXP4wLVLggrBqiQ3 Ja1SyXw1uCytD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQloQoLvXhNr6 8pDn6Fvt5/2oaqGPIXYffhdlse2KlKN38HT1RWQrumSIe31dmR6g3CN11hlZDgiTUcCXiTpt nkVQEJS8XbXCaC1onC1eHxFaK73uSHbd02DR7WjjS/UVF9ySbr8FpG2JZtyHGUfEU8KdQWkP AeH4aZ4jd0tQH0fVvcC3w73iKtG1P6mcUeyeuL8oNUfEnerHT+VWCR+cJGdVNSKQj3TSZbSI xROIzzT69SktKkSYunkjMNtuKCyJTgtMtipOOEWBAU7qqr7kRNXSnUvWUQ85kNqzhdm4bVdC ddlVkOMUwA+gYXGUjguQEu+HCU8kip7i1c2KeQ2q50qWGVlb/GUVi1V+txpLoslTj9UecY4m ou9RQLCrjvlMafNyosPDalTfF9kiVf7R3fK/0ZUaoVecU9o8AsmQ4rhtovAVXK91QSXui/m6 mcQ0vTzBEHlTSmTtza0x6N19uRbuOzHp3OJVOQMsERmrEhsFJABF7Ngooar9fbTaVaK0WlE4 vkR0YzQcS06bIEiKPkvdNPNzrn65OxkIe3fTd+XSzR2ofJY93v8ALUFMS+0nrZqO1JpsEUnC wg5TK9k7fXqn1GTK1Ssu5dsqOvCyKmTTgmnbOCz2Xunl9uqdNNON3KUbiRENyYHyE11XSEjJ SFokKWsLZL4a3BZWh7U/Fmj/AHCP8sde98H+Dsh9S17ArjlU7+e9IutF9WNMUtCEtCEtCFBt 6E5bYV5M+bLfzQ1TcfiR4dmRDh1PbFSlGIRnm7uXqismVmNJmWVWIDNShwEmGLJyZbCOsNio Eiq4BYFR9yoXx7a4VSJoZNsTdzj7XuVwqMuU8JNNIZZ4T2bZpsOpDHKVHQ4rixWAZYTg64IK DYrgQUBBU+3UZWX2357StbOUepZozBS0rojVkWn4qI59+X5YaqGJu85fp/KpmS+cJGQHK99V ASuUhenDLXIvEOdOWJcnXEiZI1TmQ9r9ip/j/nq2yDVhWmox8013LeKmbaXMkci6xUqWjZI0 jq8kaLtwJURc/BVTOrZLujLTTbR+PFMGs35gSWOqXTG7gtuj8CFuI2LHNoeCpgOORwJkHZfc K4Re2e2ri5NbkeJg9ryrpsZcn5UbN5aRtv0Xm5tO9duOvvMSpQK4jEPhkAIVTBGQqirhe/H9 +njFLcBvSmWZLm83iFsSKXaHVVIbjejA9tPAi2vYj3K2pEhQCK86pmx1FRTNCxkkVU7iv7NN pmvORnCGdGPpb2Sl6PNNzLYtNDFE9tqF+DN5LEZVvg/NrnNOo26QCIR3TMOYHxAlETVOYqi4 XHfT+iPNz/dWh1Uvip3+BIfG/dbjkzoUTtMfaYRMd3FQfcvki9/dqZOLLfzpZLmoNuFsb64t VGmSlzCnR3vgjZZXsuPLTB12Xd2ChFbkDobYxQO+LigWfa9UumoNuKxToxPEAipEa54imByv clT7E76j5iVtG5OJKG6XhYDyrPQV+tV9tytXHVCRx8OsodXhHYFFMkBE7IiAhKKmvmnnqjzU 43NPbnaGMSXU5WRlac3vIfEr0cx9atutR3m1JR9ZiyReBcYRcKiqnZEQfs1FzVO3KJaceHgT xpiXmhK1Tq264lfpqzHY4svNGrcgfZBHExlA5d1Rc9u2qNWZDcbl4cagnwKWc0SJagEol8Nb gsrQ9qfizR/uEf5Y6974P8HZD6lr2BXHKp3896RdaL6saYpaEJaEJaEKEbzJjbKupj+xb+aG qfj6F2HZn7HtipWhFbUG+Lh4OaKyFdcJarYFapQwYMspptRkYnEqMGpJhFPCp2FfH5/m4/O1 wrD0wMsQiDhAXJ/4Vrq7JTjZaUbx5ULsG2IFrWwxTocGDGcdNXJawiImX3RJRR4VIl7GggWP cq41H4gqTlVqW6HSicYQiOZcO8sYdpzdMk9A0OQ53etWjaSf6lcT/jl7/wDLDVJxN3mx0/lU 9J7RI8IIK6p7KfJ3EHBpgc57ftXy1JSokbw2Js+Wqq23N3aSiJMi0yRmLCyDzzHjV/kBCbPB cYJCTsXJE+vXTqJSiccTuTpmUvuiYVLULeJdwgmW3BrL3rbkVxw21lJKb4K2rKo4rOUFUFcc dW+bopUxxuYd4oqYlYyEyPchyJV3tjuWtozf9G94C807HkjCjJIBGxDLhCHBrCAzGBtlXCI1 IyVzOrDWqQVREZpjay+OlN2KtuN4hfLMMlp6wd0a/HixIVq3uRU55tp2NHIgdTpPArjXHqpy HkKKSIv5vfVScmqvJloRFMpql0qeLSkKIXtvTadEpP4Wui6WZkhwY4Nr1UMWykA4Ucj4d0aM m1RXBFUTTIaNVq48UXd4c1FxJmmFlLqj9h5l3bwbvR9/GKb+B6XR2HGqOjzAK+56xFRCZ6iI iPIyb0jgXdU7ovHtq5z7o4Xke1slvlxx6cvvygmt3bNz+I2VpSsHKGlTqyEaVV58aO9JBjqq hynQAiFsVLKIRe7trm+lcqsxbMOZKUyGRHuQqH7cXRV78tGLdVyWNVLHqivG0NPkyS58RVCR xFQQXiSqqJyFPZXUjVpNuhvWSjl4olZjdjdrooduPvVSbusu5ttKPXm67X7ZlQJk+E0zIOQ2 01JaIx4tqCuqiY7Cae5Fz3zY6eM1ucXZ0dVyGQ9O9ypoxS2Wp68FFb4p7t/2RV7Up1acjLWY vFiWOSQM+JFVRzlFVMLjy8tVymPN0Wq3uirdP07dMrcBIR6O2w1y7W29XH7grUVxaxJZcbiR eRtR0aExN3xCniPknYf0dSeLa5L1wmRYHKzP78vcq/R2nKe4QFxq49vXWfw1dEOMQn6qsSPI IemuH0bJVElT6TKDjHNMKnl21zvF8tFppk1vNOaWYUyT6vLXPErzr34a3BC0Pan4s0f7hH+W Ove+D/B2Q+pa9gVxyqd/PekXWi+rGmKWhCWhCWhCg+9Wf9FtwcfPoDj7eoGqljnwfmPse2Kk 6N38309UVj272ZNSsms0inTmafJd4SWZjwZZjqHi5OL7hHjy/ZrgNAqrMi8JaPMldKlJOTzN t2S8tOjx7etyHQo0ht1mAr7TZNllBH1hwkH7RReK/Wmo+szvbCe09uW9HqWtGku18voLs99W JZ/iojv34vlhqpYl71Y54/lUzJbRI6OqflaSfRT5gkaaJ5UFFBUwqiuM596+7U/IiLVrvLBM XCvK1ZXcaod2yqrZ1zyikvNyZITWkdFh99rqcTIeOeKKpcORd189djaGYkWW51gdVW5wxdld Emrtv7W7UtuVu2aE/TWmoxNo07KB96QQ/SKAkqihLhMomnBzdQxC9Y7nbypKVkwpzXdMiJZp v23LjPcP+VrNF/1XXFQm5DMbgy+4hLzIgUiVF4qir7tdFpc02MroNJrwVPnWCKY0tuqmloXV Jpv4HZYnSG3HJlB9h0kVFKG40Oe/mnBU+pNPylhccu50pp7W00Ma1fECjwrepcyozPwXBaaA WjcMBN14RREX80V/Ymkm225InHTLj9ybu2kIrYlpbB2mdA22njOlR3LOZalB6k4PSlPEAEZO Eil3VQxyEsqKYyqdk5fUsSvOTU0wA5i553OpdiSbtHVUr3K3AqlJq8Chx6lKo1LWHJq1Zq8Z gHX2Iba8elGQ0UeqarlTUVVE8tR1GpUlPS+6jbgbufBHg+OlLPMRJvuW8obae8EG5apSJdpX RcFetm4Jq0hwK+0Pr9LqPS5gQuCidRoxROx8sKXZfzRk6pRCbZMH2wB0IXQs4MuLztZIyMuW jv8AFzU3WiUWLUZ1VjUOG1PqTKxpkkWkR19tfzTLsq+X26rrdSemWWbnI2wjD8FIiwzrFbC5 Udat7VWwqy5alVpYuUduYLcEG/CkVg5KMstimMCIMNumqJlVNe66u9QpTNWAXhLXy4Vlifca bt8VTJ/0kZUqlIzbNDdYmONphxz6RGiMJeCTKIiqBx21US7ELhe9E1GsYUbYtdeLPh+5Mjmd 0+LwK7NqqDKoNkxjqpEs2pPOTH0MzcVvmq8G+TmT4gnhRC8k7a5XjKoNzU9ohHVD9k0AiIlK k89UItpPeJe/DWQQtD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQloQoPv V+S6v/qW/mhqpY5y7QP3fQ9sVK0L/UG+nqise1zpFQayDsMpgHAmI5FRxR9Yb6ZKTSKKKSKW MeFM45Y15qke5zTdnnroRgJNleSHWCbZ2PRTbneuj0Xk9a9aOSL+JTydQXTETIDxyFSTlxVO 6+avsQjbUyExy3vy8ibyA2N+VWpZv9Ruffl+WGqViXvVjp/Kn0ntEj4LwLvqo7TmonxbKJgy ZxnE49lBURfrVNTbbTgio4jHSCsub4bN1w7oW8LTbJHnHglPNCXFeq3yIVFU7KRESefljXVc KYvl2pfcc/vD0x96nZOZG7X2VXVh7Dbn3nNhQq0LzTbSRWjN5xTTmwBtqq5XyIHD8XtfHVym sRyIiW5eqKbOzNuu6S1s5slDi29Ct6My2/FjMBG4uii5ABQUyv1omuXzE5UN0E6OcEzGsNlq EOqo4Hoi2nXZhPT6XFZVVz1GxTOeyISfWg9k1ZKdUqw+NhbPP+6bzlWl7dQVbVt7Obe7T2xU ZlqW3FjzfVTbWUA5eNFTCoheafXhU1aJgik6bpXSzJVgppyceEB9SoCnVS4ntp341n9Ny5ab DdgRwlAqgktpSAVPkXllPPKjlO5LhdVKaKXamWXZ0cmT4Ve7XtDaI66D2ZYW6d0Wjb1evGsU mnX7R3JHPnER2DLjOkiIzLZaJE5KI9ybLsvx1IzVVpUtMaKSbzl4w4eDf9X4JMhmGm9baU2g 7b3BKqbVy3I5a8eTSoziUul0aG41AblL7L7xGvMsKiJ4UHty811HTFYZEhalxjlGOtnHxUi2 6803ogUV28Ld2mWZU6rvW3S1qcSQ86ysBpvPqgCipyRvIrkvYXuWOy99OKh2sfmm2KVvjx8W t0wgn0m4TTZFMKB1Kv2HS6HQ6hfleotIWpOq5TnXeYLIAlFxHVbRsSaUeeC5CmPfjUzLy08b pMyYxPR7XJ8ZJXdjbbInMbwx4FZW3W0tsuVkHg9V6LSNPMNAQkL7aIrgk2qKquCnPPJO3i1X 6pW5wZewOLPNNZlxtobx41dkpAFFBoRQUTCInl21yepXGV475RTZhMtV9PEvhrcFlaHtT8Wa P9wj/LHXvfB/g7IfUtewK45VO/nvSLrRfVjTFLQhLQhLQhQfev8AJdX/ANS380NVHHXg/MfY 9sVJ0Xv4Onqish1FZAUmqvRphQ3GocpwJAcuTZI2aoScfFlF7+HxfDvrzRLfON+n7l0JzZJC LBkDKsahPipCJxS4NrJkvkwCPOILCuShB9VbFEaXqihIrePLC6kcSDZVXA5/JDi+jq+pIyHz atGzD/1K4P8AxpfLDVIxN3rL9P5U+k9olIw9tPh79VOX+cTzxVJacgOiAcey+/V0k7SGwlBT BEJJ2VBhzDUjHt8Ps1PS9IbLXSG7XGkRp9FgU8foI7YquMqn+OrI1JMtbCZPTbjvjIgLYlhE EdSkuw2RawpteSeNMoKZx31LNaNrYFIma51iJ69RpMPjnqtk3j7ffoqTRTMiQBxpNg9E8JLE 90SKxtNd8y4GIoyaZMIRq0TjguQIg+sDxRV5CHuwuUaQRRFJVWoUsBrEpuCY3jDZXS2nb2xd BWhYl/WNdcZuTR7ihuF3V1p0xB1lERSJCRV7ceJiq5xls/0VXTSaolQlnhCYHuXxyprNPuKJ be37uXAfut3fmLbdvUuNUEaoL7ElkEfaVwxLPEyUsIid1RFzyzx4rqWqtJlHGW2qQMYnx73N yCmDUwQEqH9I30lGLipsil2GMhLepDzL9WqLLpRZEsBMVIIppgmiROf0g90JFTiWUXVrwxhg ZS053LS+L6XLwpKcmnsk1v7buzvSQtq37hpF/U23rppsJmjVCM665PYy6ysoWBfIQV6UDaKr nf4ovs6dydSnMKvONEzFwDzjn/jHzskibBVBtu4srFbfo6R4TO4FPt63apHqNNta1AjnNkRy J6VHkI2rDjT2eDjZqK54plFDGq5iFuISTj8wNhORjHL1+9SU24JNtgPEtGTCVTVT9r364RUH Ru1UsxsofqCiniXw1sCytD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQlo QoPvUv8A6XV/9S380NVLHXg/MfY9sVKUSF083Dn6orINTpsGs0ufRqnHF+HUGXYshsvI2zRR JP2ouvMgvOSrwmzvFCN0OddDIbuldmGW40dqIw3wZjtAy0HJV4NgKCI5JVXsiJ5romnymXtK W1HNDDYtagKaWZ4aK8X/ABxfLDVexN3rLdP5UtJ7RL2ryr3bnSkoUWnmwvRSOcviKDlslcxl xFUuSImDFE+Go6SGkg2JP3XZ8Wfl5k1mjnf5HAiVtpuq3XI7lYlUP8Eiw0kltpxEeVzi31SF FRUQUVHFQcqviT4as0o5Tibuazjv8u8o583sxuH7lZbM1ptcPyo7RphFBx0RLKrxRO+PfqwS pOO6vB0JAwiY3gMfVFPwmsEfQNxtHC9gFLCqnxTPnqXAXGvnRyTWDLg6xJ037f16k2HR8RJx uu5E6B4+XHUm0+k4gKeR/H7WpNo7tpNXYWqqN0tqWbgBybCjirph4/76659VKa5T5gp2Xz5V bqLWWwHRPrIN+7CT2ZjhNUFyQ84KiIgKi44XEhQUVMZyKmP/AMsfnanKXicdHbNKxOuyr46q MWr6INDq8OPK3CrFQlJz6gQ0fJMtGpEqOK4nMSUnXeQ/pES58WsT+MHWyHcMBh9lRIy4kV6l N2ei5t1JtefSqBSWYjj8YG0GUSvNuI34kQvf4i8RKndV1GS2L6hCeHSlDKMfInEWhNYqtrb/ AHdoN0swZUGsUyXHrEqqmgkQMtvOsEIPJ3wKLywvbPHtrrp1eQcl4WZR3kx3A9pFsf0NLCLb a15NMfeJydOYjDNVHBNtkmQVOAEnfjyJS+1dcex5WCnntEBam+nJSYywitAyV55X4645OAIk nLKY6hk7S+GtwWVoe1PxZo/3CP8ALHXvfB/g7IfUtewK45VO/nvSLrRfVjTFLQhLQhLQhQbe r8l1f/Ut/NDVSx14Pv8A2PbFStD7/b6eqKyYnmf/ALl/iuvMJjc5qLoa8Xz1gh1uiPUtm9pT KzFxRnF+E9flhqCxNdueW6fypWT2iQm4jtVu6XlnbkSaNOZgAj8BJytoTGci5xXyVcL3Huv2 6c0mFQ3GJBJaQc9rLe9lKxrMnIdyft6U3p0na+XEdjnuVUp7LsJ5ooKTHcjGNxkTJG1FcKCm 2PdPLP8Ae1YGGq4wN25INjnv7PR4qjX8TS467Qh5eBeHXfR9gPpHqFTrBkKo4pOk6StKkZxx SJVwSYbVT7p7fBf0dWqVkq1o9RtuH9qiXcbOmWz/AIKytpVsCp09yvWAzOKIZlE68sTRTICV TEEJcpgl7rjumPdreoboa2skkdXcqfzvuVismRePl2Xsi/HSbTg2/SSZWp0yWf4/s0/aNIkn jZ+HIl5/DUmw7empjcvoTH85OWpAYsujY6OYpMQt8ZQDdsGPUaRTRg9VKrUhZeUYwOijQATh IaEqKgkoomR76r2IJOVYZ0rQ5KXpJuE9x5QVQ7vluJJt2LQNsykR6vWXyaKYw3zcYYEFIiHk mEVfLlqt4dGX3QTr45h/5VqMgHbLVVbbTRt+LBv2PaO586oVek11t9WXJfJ52K82HMVQ1yvE sYXC4+zU5XAp85I6WVb0Zw8u97lkHWz1wJTe6rPptcvSCDLkcJU+M8XHkKGaNKKqaCg8lXBI ikq4RB/var0hMPbncPyKS3QLQ66nlq2xFtiGjLI98eNOOqdOzROlcai3JkpkuZEHz+H7tVOc PWTlsU31HJwl8NbgsrQ9qfizR/uEf5Y6974P8HZD6lr2BXHKp3896RdaL6saYpaEJaEJaEKD 71fkur/6lv5oaqGPPB+Y+x7YqTovfwdPVFZRiRHZan0hLCEqqqe5Mr3XXm6XYcdIrF0SJ6Jt fEpgozitn9Xf7e+tItEwQgf0lpLHpRIlLbN/qR776Xyw1W8U/MsdP5U7kdokPrztHaug25+2 j1VP1Fomqo3BF5XCUv6BSLy4+ffUlRaWL9K0vbTRb/zV337Y+yo+alWXX7nWoEutvqT81uG3 s7Dp8eQxJSVJkNRhBUyCk1xEMuI5598D4e+pSYpsnKS5G7WjcLMMhGN2e9yO+LwJKMrLl/Kh BHaVcG4TMNtQ2xo6yUaXkTM5phlXkbQsY4KqIuVHuS9tSrDNNG0+2Lvqjq/5pmcnL+ajEKq7 0zVEX7bt2lgaTEIknesG250XFi/DKK6rSqvHyz2TU8y/htr+Y456/wBUU0cgHiLoxH35dFtT kWWgo0nWJGn+RmqoSKKeSCiIo4Xz1Iy07hfSDpdJl9r3rBxZa8ZErErF2x4/X3JuO3WpCstF 6jDeDMdw0z4yTArlc4wmF04qxUu4RkBjb0qPdmJeHAam0apw5JN9Gcy4bo5FEcFVVE81wi+S aaCWi1fItwMTHVT4TEV5ac6W0VgmrlS/pQSXKTQaBdrcVt4bfqqTC/mvrLohwUS6LSqgq4vs opLhM50xn3hmS3IezFTdBhrEPIu9v1tqdGj1qlyG8ImBJoxc4EiYcbJRyikPsrhfNNUsjepj 1obMFPPMC6NhrvW5sysk3JmCyqx+SNIgcUDkKcu/2axMVGYntRayMq3Kkq7sK5xufdiqxofU 9RtqmnFdJt3LRznHeLrRgQIQutoHmhYUXBXUlNs9rKUJltn8fj9yVnC0paqs6U8HNS9nsnlr mk66tWgtQ0zElymq9MOp8C56bJRL4a3BZWh7U/Fmj/cI/wAsde98H+Dsh9S17ArjlU7+e9Iu tF9WNMUtCEtCEtCFBd6/yW17JYTot9/+aGqdj6BFh6Ys+h7YqWoX+oN9PVFYivy57lp7zdOs lxtyfSIZ12pMtyQQ1badEejwL2lUVUuOuOYdlxtuIVfnWtK2rLu1qIDLM3ky162iONN9QRzl OS4RV92dGKacLBDNB5I6qYU4yEilzFELN8VEfx3/AJ4WP+mGuT4oO6Xl+n8qnJUdE4S+KnFv SZW3lolwQYsDoCpxnmhMwL85zui47eWceWmNNCn7iymmDM89obvVlBQdQZmt0XMTEAHoTJ2J ckWlzJNY3IpjEEITpFIVltsUHI8HnHEUVwKIqLxL+0z59tTRMSjetKyDmdw+f1b6ausvOf7m G9zL4U26OjtxVrfIWmH22nE6XDCsgrxo22COkpIQn34ipL08IvlicZdmJ3+HCnRhlx636VHP y5f/ACer3ro5UdrRGFSqhvR/rSjNSW1OPW2zmmT3SJVcbFSNCFuPw4qme5e/U5LhVBu/hNHz h7xTM9zjsv59H7qXUKwrPrlOGtw7kuaowJxo9HJ6c822rahxy2hAK8SEl+3SXbSaacsdbD1Q /Sl2JQZnaLNG12osaS+sqTClOEbLTBD62aCoNsiyGUHHkAAmn/bx50dmHx0IdpTKOUGy7Utl z1mh0luO+oK2r3IjNRVEQkySr540q3OkWuS3CT0Q2ipB1cr7WnW6NKNic2ITd9Ej3FQZNLle MHQzhcIiqnkiqqL2X36QnhvZ1dpb092MrMXrINTtLdjZip9OyZBSqMy4yqU5z+hGO24bjjAY yoo649kz7quMaJerU+oN6KpN2nDezz+/xVbzFqaje0SDJWPSL3CaaoNYei02G+DDMtthjCSE Vt5mS2vwB0XENP0SbHTmMzh+lazGuXLH1JXcmrfcr42p29ibc2uEBsepLdBsZMhzu85wFBHq F+cWE89UKvVsp8iO3LkTTaJSV53uo+edUGYfv1E8ELoJsWo0wuSojavdaLZL4a3BZWh7U/Fm j/cI/wAsde98H+Dsh9S17ArjlU7+e9IutF9WNMUtCEtCEtCFBd7EFdra+hJlOi12/wCaGqjj zwfmPse2KkqOejngLn6orAV9bIX/AHNcNRuq3bop9DjFy6zzYEjz0ByOnrKGqeaioILfxyuu b0WZaakd8Vet261iY1Gu1R6bTIs5yrQ4/rqLHjttIbikvEWyPii8WDx7vJR8++mc3bOC4HDk EepSjUuPzq0XZ3ipEjwj4p7nb3f0Ya4zicLJNjnj+VEuVzhKK3dbG1FSvB+oXRImN1lyA0y6 LT7wtvx0LIjgBVHO/wAe/u+rUxh16uDS8pIIGOfk/wC2Krs81Td1d1KMC5/3Q2i2vsZRzkza TSJhyggyUNSOUhNsK40RoBEqC2qKLapxVFTj2xjTubfxW4Vjrgw1h4h/Qk4jS+X1/uncahbM z33uG1YzZquk0YuRs+NTNxVQyNUwSkZck/S763OfxRLFacyMODiH9CbHGnjsMxj8c6sSkWHt /TYTkOnWDb9Pbl59YZj09oOSqKiqEojlcoqp56gxxLPEX8Q85HogpZqlSe2AqaxnW2mgBsBA AFGwABQRAU8hRE8kT3JrYJgXSvAo3LbQC3G0RRAJHh7afhMJIwXcJPhTxakmpgklYu3XHT4Z grVpYksxOKiXH7FwutTqVo2kkYy5EVwoVPCHL7vstmvbzH4Ln+OoiYJt0rxT1jTNChBx6dGV SjsMtqvngfrz/HUJMPCKkgi8W2mUx9XV9ry8tQDs4TqdswTA+3l79RjpJ6C81qt0tN0JfDW4 LK0Pan4s0f7hH+WOve+D/B2Q+pa9gVxyqd/PekXWi+rGmKWhCWhCWhCg29i8drLgL/cN/NDV Qx54PzH2PbFSdG7+Dp6orPtEJqTA9Wkt82nAJtwffxVCEkTt8F1ynD80OjIFaJ0O6Caz1Lti 67Z3dt2nBczlYg0+e+jzRirQwGSaIWS5d/WEMGTbUfzCRP0tPplxoZKY4iyipdo7vUtCWVgK E97kSYX5uFx0x9ya4linWk2B5/ypzIfOEudYum1YNxNW9PFTqZ9HgixEJAE1wJdRe2O+fq1B y1LqBy+kaLV54pKLsuMxrCh7m51otPtQYSTJ7xzgp6tx4eERw3BFFUiVB/tOfn7Kd9SDWHqg Y91cgO9dvlHyRQ5Ns3aoJxE3NhTYbcuDRK1MacijKZaYEDJ1rJIXDiSiSpjPBC7ppGGHpoXS B16G9HLhitN2B5i7JftweqNPNbZXA86/x6cbqihdJWhM3VLiojwUuKoq+fvXOnbdIlQLvqHx 70zOccHxV8/y23dOO+/A2rjm0s1Woj7lRDg/HUV4PryVETJJ5KWfEPbUqErTwtEpri8nH5E1 KcePxU9K69yH3CBI9m0ttI/0nrVXBwwlk52ZJEJRQFDxc8/nYxp+1LU/zjPoh70lGacQ2PfV 7SYdOjVK/bBpVUakj+EhaI3Y5R3muDaCSllDR1HSTv38OnzTUqN1jJxHi+M03N5y7aXCDcN3 1eqpTQ37oEl6ssq1T49PofTHmbb7g8XVyXZseaLyT2dSL70vLS5HCV2eWPN5VpcT/cruFSGo WjuNMdp7RbzVRmM02oSkjQ2mTcwo8CAh7oq4NF5L9fnqJOvSej+Zj8dKct0xxSWntuUylRqc 9VpNRcYAk9ZlHydcRTIk5L78IvH9mqrO1FuZcuaGwVMysuTQ2rk/JzkdQ7r6lWwTEi7aj3TT sYLzsvv0zIrltwJawsLzwfpazcSxrJDxLwp56APW2VqUSFaJtb8WaR9wj/LHXvnCHg7IfUte wK4/Uu/nvTLrRbVjTJLQhLQhLQhQbekVLbCvoI5Xot9k7/2oap+PoEWHpi36HtipKjjdOAPP 1RWZqFOVtzgvJCE1UMFjui99cDo05oHLCVznBuFAKnGrIXVMkvyI7tFUXX4aryR4HneKEJCu R4hg8EniXlqUq80I9w8aMFvJukWpbFTWyuBUR4R7j64WM+9OmGuZ4puFlnmj+VSkkJCRLyrU +7JdZju02bSG6YEiOToSoaOvG2Kor2Cx2UkTinftqDk5+ny7NrwRiXJH1JKYlJg3LwyQGBZO 4sf6M905ERpOtwGDGRC8bjhLyJVTkvdpU/RUVTumpZ7ENNiOpL5+lHqyj600CmvFtlBPqhZd 1Sqc9Gi7m1ht/ok1GNzqEIETiEpHxdQnMCnBEVe2c6byuIJJpy5yVG344PIle1bnnJ1/ISnu 1Ryqv1muSHjmFMBHphOC2qmRICIWfAgl0+P6P160LEhR2WQ4Mvjl40uVLEh2lwXa6z3z51KL MmGYdFTcdAMtcxNQ4tiIoiqCJ4URcZ76G8TTeVjAj9/4pIaMPnJ3H2s27RtyOVs9QHmI0R0n pTrpGwwXIG1UiXI5Vc/HTiGKqjwG5l0D7lmNLbFF27Tstl5TG2qOpGrSl1IwljpeJrHLPsr5 du37MaxGuzZa2mj6hWe1w+aizB06KjYRo8VkGscMNCPDCKiYXz7ISppidUJ0bNIlBkBHxV1S SZZRRcVVXw4FV7a03Y4Q6iWgFq89TqR9whSCT4oC4/fpsITRFbbGJcy207I7RQTd2O4B9J1x hk18xdktgqfaikmpFjDFanPmpYo9C0KpSbW05BfYUuQa4bIXV/3Ak98sV1JD2O8VP7EkX3e9 NzxBTw/mJ6zaVbkDlqnzF+r1N5P/ALCiakpLsRYqfLWl7PSjBIniaRHxk/a27ud4ERabKQfh xAV/7iTU8z2DsQFtuNw6f2TMsWSY7IxT6PtXX3B5ORnG/wC6440mftUSX+GpaX7BFS/nzLf+ XuTOOLx/pp9E2jqHPlJ6Ij9U1c/u6Wp9rsFSpD3eZ/tgkDxc6WyKs2lwfwfTYkBFz6swDSLn PsiieeE+Hw12+lSIUuRZkQ34NAIf2wyVTfcJ50nC445p9qRSSWhCWhCWhCY1Wl06t096lVWI 3JiSB4utGmRJM5/imk3GwcG04ZwWwGTZXCqzrno823MUnreq0ylu8cI27/OmfPPdDVHPf7jT VRqmBaPUyvNvKPIpBmrTTXjKuLj2KvumqrsWns1Rr9KC+irj9U6oqP2CR6odV7FsxEhKQcG2 HEeef3Kbk8QN3fxApnQaHU6NTXIlQiSorpSScRp6G+jipwFOwICr7vdnXNcRdj3ERaEGpS7L zYw5PLFTMvXKfdfvouNKqTiIjNHqz6F5dKkS/wCJNon+OopjsT4qm9uWs54j704PE1P86KIN 2XdDrROsW1WHFx2DpNtqX/UMcammewfiIob7jYdOfVBMyxZKt7IxindP27vOUPKTbciN8Eek R0X/ALHC1INdgaqF87Nt/wCXuSXywa/pxRONtRdDhfT0+ntB/eqpEv7kj/56npbsCS498Tcf sw96Yli97xW4J81s/WVLkdSpTIfo9B91f2qhh/DUsHYMo/8ANfcj/b+lIHiqaLZGEE/b2fPP 09fjoPvFinIn/wBzPUtL9hrDMvtiZc8fdBNTxHPF4yfjtPTekLJ1+pIKeaNBHbz+5rP+Oppj sX4VY/2kI88Y+9MzrE4f8xPWNsrdZDgciqO/WU4xX/tVNSjOB8OsbMm36kgdQmjG0nIp5HsK 1Y4KA051xF8+tKecz9vIl1MtUinsfNMjDogkdO55y7M2VaEcubdsUtC+KxAVf3qmnotNjsik 4kRInHptPipiJT47Cf7toR/gmlVhOURE8k0IXuhCWhCWhCWhCWhCWhCWhC//2Q== --------------030407060607010708020801-- --------------050509040508030003060708-- From owner-namedroppers@ops.ietf.org Tue Jul 12 05:22:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsGyh-0006kH-1c for dnsext-archive@megatron.ietf.org; Tue, 12 Jul 2005 05:22:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04333 for ; Tue, 12 Jul 2005 05:22:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsGuM-0005U7-Jr for namedroppers-data@psg.com; Tue, 12 Jul 2005 09:18:30 +0000 Received: from [195.54.233.67] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DsGuL-0005Tr-Jd for namedroppers@ops.ietf.org; Tue, 12 Jul 2005 09:18:30 +0000 Received: from [195.54.233.69] (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (8.12.10/8.12.10) with ESMTP id j6C9IFMN019976; Tue, 12 Jul 2005 10:18:16 +0100 (BST) In-Reply-To: <87br59dj3z.fsf@deneb.enyo.de> References: <87br59dj3z.fsf@deneb.enyo.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6bc84281bea1f77b3cfc6e130ee567cf@rfc1035.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Jim Reid Subject: Re: Randomness requirements for message ID generation Date: Tue, 12 Jul 2005 10:18:09 +0100 To: Florian Weimer X-Mailer: Apple Mail (2.622) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jul 12, 2005, at 00:21, Florian Weimer wrote: > What are the randomness requirements for message ID generation? The RFCs say nothing about this. Which is hardly surprising. The ID field is just to help a resolver match a response to an outstanding query. See Section 7.3 of RFC1035. > Would you recommend different levels of randomness for stub and full > resolvers? There doesn't seem much point. Even if better randomness helped. Stub resolvers typically only make one query during their lifetime so maintaining extra state so it could use "more random" IDs would be futile. And with only 16 bits to play with, it's easy to swamp a resolver with bogus responses that exhaust that name space. Besides, it would be wise to assume an attacker is able to see the queries (or responses) on the wire and either tamper with the replies or fake a response for the query that the resolver made. In that context, the randomness (or not) of the query ID is moot. > (I know it's just a 16-bit number, so we aren't in a very good > position no matter what we do. But there's no reason to make things > even worse, IMHO.) Randomising the query IDs barely raises the bar so IMO it's hardly worth resolvers investing in strong random number generation. And anyone who does this believing it improves security is kidding themself. [That said, resolvers should randomise the query IDs as it's the Right Thing To Do.] The real solution to this problem is to protect the integrity of the DNS data while it's on the wire. Fortunately there are two mechanisms for that: TSIG & SIG(0) which are based on crypto hashes and DNSSEC which uses public-key signatures over resource records. These raise the bar for attackers quite substantially because they now have to get the shared secret or private key before they'd be able to feed bogus data to the resolver. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 12 08:52:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsKFl-0007Nn-Vz for dnsext-archive@megatron.ietf.org; Tue, 12 Jul 2005 08:52:50 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18396 for ; Tue, 12 Jul 2005 08:52:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsKC7-000Mv9-OQ for namedroppers-data@psg.com; Tue, 12 Jul 2005 12:49:03 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DsKC5-000Muj-VS for namedroppers@ops.ietf.org; Tue, 12 Jul 2005 12:49:02 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j6CCmkiE038788; Tue, 12 Jul 2005 08:48:47 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <87br59dj3z.fsf@deneb.enyo.de> References: <87br59dj3z.fsf@deneb.enyo.de> Date: Tue, 12 Jul 2005 08:48:50 -0400 To: Florian Weimer From: Edward Lewis Subject: Re: Randomness requirements for message ID generation Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 1:21 +0200 7/12/05, Florian Weimer wrote: >Apologies if this is the wrong forum to ask such questions. This is probably the right one for this. >What are the randomness requirements for message ID generation? Are >simple time-dependent IDs acceptable? What about PRNGs which leak >their internal state? Would you recommend different levels of >randomness for stub and full resolvers? Shortened answer is - there's no requirement for randomness, but the less predictable the number is, the less chance a really lame attempt at message stuffing will succeed. It's similar to playing with the TCP sequence numbers. Another reason to alter the message id is for local-side message management. If you don't change it at all, you have more work in trying to match answer to question. That's probably a bigger consideration than defending an "attack." >(I know it's just a 16-bit number, so we aren't in a very good >position no matter what we do. But there's no reason to make things >even worse, IMHO.) As Jim replied, _message_ "security" is better done via TSIG or TKEY/SIG(0) (or to rely on something like IPSEC to protect the channel or a VPN). If you are asking in the context of implementing DNS code - my recommendation is to do something cheap to make the id unpredictable (or random) and spend time making TSIG/SIG(0) very easy to enable. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 12 11:01:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsMFv-0005Ia-EA for dnsext-archive@megatron.ietf.org; Tue, 12 Jul 2005 11:01:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01310 for ; Tue, 12 Jul 2005 11:01:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsMBj-0007aU-H9 for namedroppers-data@psg.com; Tue, 12 Jul 2005 14:56:47 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DsMBh-0007Zx-O7 for namedroppers@ops.ietf.org; Tue, 12 Jul 2005 14:56:46 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j6CEuVgU039233; Tue, 12 Jul 2005 10:56:31 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050712093437.03bd4d30@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 12 Jul 2005 10:56:27 -0400 To: Florian Weimer , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Randomness requirements for message ID generation In-Reply-To: <87br59dj3z.fsf@deneb.enyo.de> References: <87br59dj3z.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 19:21 11/07/2005, Florian Weimer wrote: >Apologies if this is the wrong forum to ask such questions. This is the right forum. >What are the randomness requirements for message ID generation? Are >simple time-dependent IDs acceptable? What about PRNGs which leak >their internal state? Would you recommend different levels of >randomness for stub and full resolvers? Good randomness should be used by all DNS resolvers on query ID. For Recursive resolvers, some people (in particular Dr. Bernstein) that advocate combining query ID and the use of different ports to make it harder to forge replies, i.e. expanding the 16 bit protection the QID provides. Recursive resolver that uses 8 different ports in random order, in practice has a 19 bit QID. RFC3833 discusses when Query ID offers protection and when it does not contribute to data protection, if the attacker can see the outgoing query QID contributes nothing. Having a BCP on things to do for security/reliability by DNS resolvers is a good thing. This includes query ID issues as well as the techniques used to preventing cache poisoning and message integrity protection. About 2 years ago I tried to get such a document written but it never materialized. Anyone willing and able to be an EDITOR for a document on this topic, please contact me. The word EDITOR is capitalized to emphasize the role of documenting the existing practice and working group knowledge, rather than propose new things or changes in protocol. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From shaffer@yahoo.com Tue Jul 12 23:15:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXi9-0005yn-Th for dnsext-archive@megatron.ietf.org; Tue, 12 Jul 2005 23:15:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20490 for ; Tue, 12 Jul 2005 23:14:59 -0400 (EDT) Received: from host217-42-237-95.range217-42.btcentralplus.com ([217.42.237.95] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DsYAN-0002Kn-62 for dnsext-archive@ietf.org; Tue, 12 Jul 2005 23:44:18 -0400 Date: Wed, 13 Jul 2005 04:20:22 +0100 From: "Hecht" To: Subject: cheap oem soft shipping worldwide Message-ID: <423F3FA9.4010405@expert> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050509040508030003060708" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 8008c49d41a52dffe8d48b494980a4a9 This is a multi-part message in MIME format. --------------050509040508030003060708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by drop.ux6.net id j2LLgHfF030444 Content-Transfer-Encoding: quoted-printable Opt-in Email Special Offer unsubscribe me=20 =09 *SEARCH* =09 =09 * TOP 10 NEW TITLES* =09 * ON SALE NOW!* 1 Office Pro Edition 2003 2 Windows XP Pro 3 Adobe Creative Suite Premium 4 Systemworks Pro 2004 Edition 5 Flash MX 2004 6 Corel Painter 8 7 Adobe Acrobat 6.0 8 Windows 2003 Server 9 Alias Maya 6.0 Wavefront 10 Adobe Premiere * See more by this manufacturer* Microsoft A pple Software * Customers also bought* these other items.. *Microsoft Office Professional Edition *2003** Microsoft *Choose:* =09 *List Price:* =09 $899.00 *Price:* =09 *$69.99* *You Save:* =09 $830.01 (92%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Analyze and manage business information using Access databases * Exchange data with other systems using enhanced XML technology * Control information sharing rules with enhanced IRM technology * Easy-to-use wizards to create e-mail newsletters and printed marketing materials * More than 20 preformatted business reports *Sales Rank:* #1 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 1,768 reviews.=20 Write a review . ------------------------------------------------------------------------ *Microsoft Windows XP Professional or Longhorn Edition* Microsoft *Choose:* =09 *List Price:* =09 $279.00 *Price:* =09 *$49.99* *You Save:* =09 $229.01 (85%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Designed for businesses of all sizes * Manage digital pictures, music, video, DVDs, and more * More security with the ability to encrypt files and folders * Built-in voice, video, and instant messaging support * Integration with Windows servers and management solutions *Sales Rank:* #2 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 868 reviews. Write=20 a review . ------------------------------------------------------------------------ *Adobe Creative Suite Premium* Adobe *Choose:* =09 *List Price:* =09 $1149.00 *Price:* =09 *$99.99 * *You Save:* =09 $849.01 (90%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * An integrated design environment featuring the industry's foremost design tools * In-depth tips, expert tricks, and comprehensive design resources * Intuitive file finding, smooth workflow, and common interface and toolset * Single installer--control what you install and when you install it * Cross-media publishing--create content for both print and the Web *Sales Rank:* #3 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 498 reviews. Write=20 a review . ------------------------------------------------------------------------ *Symantec SystemWorks 2004 Professional* Symantec *Choose:* =09 *List Price:* =09 $99.00 *Price:* =09 *$29.99 * *You Save:* =09 $69.01 (70%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Norton Utilities optimizes your PC=BFs performance and solves computer problems * Norton Password Manager keeps your passwords secure and easy to manage * Norton GoBack Personal Edition restores your PC after a serious problem * Norton CleanSweep removes unwanted programs and files that waste disk space * Norton Ghost protects your data from computer disasters *Sales Rank:* #4 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 217 reviews. Write=20 a review . --------------050509040508030003060708 Content-Type: multipart/related; boundary="------------030407060607010708020801" --------------030407060607010708020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Opt-in Email Special Offer     unsubscribe me
SEARCH

TOP 10 NEW TITLES

 ON SALE NOW!
  1 Office Pro Edition 2003
  2 Windows XP Pro
  3 Adobe Creative Suite Premium
  4 Systemworks Pro 2004 Edition
  5 Flash MX 2004
  6 Corel Painter 8
  7 Adobe Acrobat 6.0
  8 Windows 2003 Server
  9 Alias Maya 6.0 Wavefront
  10 Adobe Premiere
  See more by this manufacturer
    Microsoft
    Apple Software
  Customers also bought
    these other items..


Microsoft Office Professional Edition *2003*
Microsoft
Choose:
 
List Price:
$899.00
Price:
$69.99
You Save:
$830.01 (92%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft
Choose:
 

List Price:
$279.00
Price:
$49.99
You Save:
$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 868 reviews. Write a review.

Adobe Creative Suite Premium
Adobe
Choose:
 

List Price:
$1149.00
Price:
$99.99
You Save:
$849.01 (90%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • An integrated design environment featuring the industry's foremost design tools
  • In-depth tips, expert tricks, and comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and toolset
  • Single installer--control what you install and when you install it
  • Cross-media publishing--create content for both print and the Web

Sales Rank: #3
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 498 reviews. Write a review.

Symantec SystemWorks 2004 Professional
Symantec
Choose:
 

List Price:
$99.00
Price:
$29.99
You Save:
$69.01 (70%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions


Features:

  • Norton Utilities optimizes your PC¿s performance and solves computer problems
  • Norton Password Manager keeps your passwords secure and easy to manage
  • Norton GoBack Personal Edition restores your PC after a serious problem
  • Norton CleanSweep removes unwanted programs and files that waste disk space
  • Norton Ghost protects your data from computer disasters

Sales Rank: #4
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 217 reviews. Write a review.

--------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhLAEWANUAAP///+7uzAAAAIqKitbWuLu7u+fn4O3ty21tXq6urpiYhkVFRWdnXBcX FzMzM7y8o3d3beLiwktLR8vLr+/v7319cRERETExMSEhIT8/PVdXUZqamnNzaiIiIrCwmqqq qmZmZszMy6Skj1VVVd/f3/r6+erqydvb2M/Pz4mJeefnxs/PsnZ2dvb29M3Nzby8vN7exqqq lPHx8ImJiIKCggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAA AAAsARYAAAb/QIBwSCwaj8ikcslsOp/QqHRKrVqv2JA2hO16v+CweEwuLxvoBtfMVgra5Xez 1JIZ7vi8fs/v+/+AeyVNcnAAEIgNEIaMQ4WNXo9IJTInMCoHAZqbnJ2en6ChoqMBBxEEKy4G TJKGaJCMrbBVskQlBjCkuru8vZ0EDwaDSbVsEK8NAMnLAB0hr2UUBQVhxbNR1gC4oxMRvqET D5zh497fvx6rxNfQSM8dRBcjQhQCHwNvCwL7NAIDAAUEXBBygQURFgIvbBACwp6QgAIsjKi3 b98/JNbkCdlHAQCLgQsWAKBwAcOCf/geCqAmJKXKAiRNDsBX0Zq1Fis4KZAQIIKD/wcEJGjI oEDTzwAKGCB14EDChE4pHBDQFEGDBAZFq14tGnRo0QBHky4VhxUs06OlVHh44SZJQJb+ANQs 4BIATQwLlxw7pqzvMr5EXG6wYDefSCEL5tGkUI9lYZYdKVjAMA/gShRx5V5cl2QAYYgfAFz4 F7Jwx5Zy3g6p+xbfadSslBiYusnng50BKnAIMEEqWHFixXLYzUkCh68VlPbMrdybbt6+wypV kKFCgLJIlWs6YOJBXoxuV278l7nw6jf4SDBpAA9JOyEkHI4AYb50SwwATq788AgDfSIb4CWA em9hlld54IVHwgAhDdBYfiJt4M9pLqkG20sSOnhebEl00/9JchmIEEAGHmiiQVHSZRcAB9Zt MoEGHmigiQQlbkIjJySaiCJw0zEgQQTYicWJCSuk0BYSFsZVXl0p8aeeXuz55ZciRlwAQj2h paTPPtMMaEEBJzFIBIKiORgXROWRaUQ2AmwwwkwLBITYYSNERA1NFTnGmnh1fnnhkUjE4AkB TRklznU7qqgAUz9ykkIKPk2FlqGcoFVWikkpkKkmQm5iAgEcAGoEmhbJVZF5qC1gwX9LvLMG ER0kY4Rng8Fm33joNUjEqkRgdoGq+L3FAn7jLZHNAiBg0KWYEA5RQEmoWoiqZSw9S2xdnAVq DifY5RjAib8pykAEGRw6owYMOFD/1I021qiJt+BiOu5WnGpXSnehZjuqeJr1+yc+BTzZxDFp FEylEfHxWt9hiJkEwAcWCIACEQ1NzNAF00j4QYEO+avvEQNg8EY9FlxU2mksEFYhv9O+hTJh 035cxAS0cYvcbr1NJYGIFVgnXAoulvtABTImx4nRmzyXcwA75+azUhUQVS8npoiQb4JHJEne ZkxmY0QIiIQtdhL6hFZfRSjFRXIRFDR0wQU0lDyESao57DHWSApw2AUCuDAnQCa1GS3LeMa5 UgGB54Ut3kacYO4m2HUldQAiZMBABk+JJQJPmqRAXG8RaFWW6FwJNXnll2eu1APqTr2dCitU YKTMzvKr+GSehS9+DRQFWPyF17tziEQLQB1gPCge1vZ4L+S4+HjyVC0fivEqEKAAAt8dAXwZ EHSwyBDdfx88LeNbkY0BHnSjggkmGO/++/DHL//89Ndvv/EmqBDBCtfPcIKosIhVe4QgwPKR z4BT8NoJYiCCB9CMABCMoAQnSMEKWvCCGMwgKh4gggogYAYuGAbjIBE+IpQQgVLYHgrHxIQW nCABCtANAmZIwxra8IY4zKEOd8hDBDAAASzawAlEOMIVGvGI17iFC17wggQ48YlQjKIUp0jF Klrxik98wQlkgMQuevGLYAyjGMdIxjKa8YxoTKMa18jGNrrREEEAADs= --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhBQAFAIABAP///////yH5BAEAAAEALAAAAAAFAAUAAAIIhG8RqaD9QgEAOw== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhBQAFAIABAP///////yH5BAEAAAEALAAAAAAFAAUAAAIIhB1xqcD6QAEAOw== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhUgAOAMQAAP/umd1mM////4czIa5wSM+jaXYZEG4MCLmAU6RgPn8mGfPbjWYAAObH gMSSXpBCKtq0dJpRNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAABSAA4AAAX/YCAIIjmW6KmabNqubgzP7xsEwJ3jes//u6BPCBwai0ji 7gRoOp/QqHRKrVqvItx1y+16qVkn4bAoDACFwyABMEAKjELDACAYBgiAQzGAAAYHCnlNEWwF dGlrdQYGBE0DigAMTQiQg5B1jk0oYgYIZmhnTQ8OBAMEDg+ZTgMFT61PewAJhqKZC5OgTpNt Cwt0fwYNBJo5JE8ECa1nhwR5xA8E0Y6mBK5jDqyuTwwLCn7NzxGmAAsHDwtNuaKwpwnET2FN xO/MCgXgA3R31xFylAey/dnm5AGCA00K3PNjSoHABg8UqAv1yNWyd044zSMwh5ktAIHaIFz1 BONAKAgMW0RIaIsYBIlNcE3s9atiymLyNv5hpkaUgpUR591ho0xYRSgNGAhMdAbegQYQ9Gni VQlPRXPFjGn5wrWr101MvoodawVFkiNK0Ko9yzYt2xoy4NKIS3euXbktQgAAOw== --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQY GBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYa KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAAR CAC0AIwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3zW/Ekun6jJapbxuqBfmZj3FQ6b4plubo R3EUEKMv3snr2rA8cSGLXbhlTef3Yxn2FZnhKe5urmcXKWe7lUD52FGVWCn3r5CGPxMsd7Pm 05rfK56Lw8PYOduh3V5rd9ZMfOggMXaYFsD/AHvT+VNt/FDiXZewJEp6OpLCs+J5bV/Kh3R/ 9OdyeD/1yf8A9lqhqVxp9qyor/ZZXO02sybRn+n4fLX2b5FueQps7pL8um5UQqfQ1VudZeK6 gi8kHzEdic9Nu3/4quXtZ7iwfEQYp954JOv+8v8A8UKuNdxXt7ayQ7uI5d4PUfco5SuY211z NykPkruO7Pz9MVb+3lkysYz2ya4+eETa/blYvnRPv+Zt4/u4/wDHq6NcH7vNQh3HR60BOI5r fy88Z3/dPv8A40+XWVjnePyD8h253/7Oahnt0nGG27scf/E1jMDDcyxfMcHqe3yr8tNpAmxg 8eqxcf2fJ8jsv+sHY/SpB48i/wCfCX/vta4CPO+X5G/1j/8AoVPUH0UV8fXzXEwqOMX+R9PS y/DygpSR3y+OoP8Anzn/AO+hT18cWx/5dJ/0rglQ+v6U9Y/m+YtWX9s4nv8AgN5bh+x3v/Ca 2v8AFa3I/wC+f8aB43sO8Fx+n+NcIsY9KlVKX9t4nv8AgZvLaHY7r/hNLD/n3uv++B/jW3pt 7FqVmlzGjqrZADjnivLdvy16F4TXGhW/1f8A9CNejlmZ18RVcZ7WOLF4SnRinA4j4jyeTql5 IrAMojxubA7Vj+CboeQ92gSfeZFIYlwccf0qz8Vp5o9Xkitobad59kQjud2wsQMZx/DnGad4 JmTUkikuY1jjeN8pGem3+6a8em1HHWtvP9SJX9lvpY6eC4triPyonVFP/Ltc/Mh/3W7VzXjW 3ln02UWmzbEdziaTmNlbnY/fj+E1anmtjprXtvL5ke9k8uQYkzu29fun8cVka0PtVm1nb36w yyDebVyPnb+7/dNfe1LNWPEk7o3vCX214XGs/wClZHEcfDwj5fmVe/ruWn6lcW9vfQfZrmKR HDtvztcbeqt+dQeE5bJNG8uJ5g6HmC+m5Dhf4JP4K4XXr+0jvHRbK5RZIyyZ/u/L8u4f8C+b vWVSq4Q0HzWR2+lXaXGtQXENwnlSBkuCz87mX+H+H+Ku5gjSGFET7gHFeW/DuwiCebdXMW+b cyIXDlF2/wAQHT722uo0/X4kvmtNPk+1Kj7XTPA/3W/9lopS0uy4yOyX734ViXQ/064/3x/6 CtadjdR3SM8RzjqO4/3qoXP/AB+XH+//AOyrW62KZ58g+d/98/8AoVSqlRwJnf8A77f+hVZV K/N8S/3svU+0pP3ERqBTl61KqU5U+asOYqUiNR7VIoNPVKeqVPMZuQxUOK9B8KrjQrf/AIF/ 6Ea4XHFd94Z40S2/4F/6Ea93h3/eJen6o8zMX+7XqeSfGlRJf3cRGUkhYP8AuDNx5Y/gHJ/z 6U/4eebcaTZG3kSGU27MjxghBtHp6e1RfGkO+p3MaSNE7xYEgLjZ8g5+Qg/rWv4Cgjgu7eJE IXyWbY5yR8v3WJrilJRxsY96n6nM4/un6ElrpWsQA2d7Lb3VvLiUzvH8uQ3CsevNV9V8H3k9 7dR2UFvDZSfMJEPz+/X+L/61bevW8lppuoztqDmAfvUQncQ6t91T/d/2azvh74xTVoLy3u5U +1W5ZgHfaXWvu7LZnh6XszD0/TnuPItNMv7eHy9yXFrfPh/9/Hfr0Hy8Vzuv+HJ7JYI9TuFD 3D7I03/IPmUFlrrfEesaPMFu7XfBrMch2TRoGzt+UNu/u/7VecaxrGp6le5vXmufv7Ezk/N8 3yr9OtYzsZu2xv6jdWWjNcWek2k1pfxuyTSAlt4VeG3fd53V0vw006SNZ7xpcrJj9xIAz42/ eZeoU/N0/u1x+nPN4rvYImRo5zbyLIO7unKqo/U5rpPArppdzBpllPdXMsiedIPLAg2qzfd/ i/4EKml8V2aR3PSEt45JFkt3aGXsQev+6e/+6ai84/aZ45tvn55I6fdX8qLa6id8S/uXPaQ8 H8ejfj+dDZ8+4z97f3/3VruexsziLR8q21H++e3+1VpQ/wDc/WorHBRv98/+hVdUV+aYmX7y XqfYU5e4iJQ/otSKj7uq/lUqij+KufmCUhmw/wB5qbORBC8jbn2DdjPJqbKf31/OnSCKRGRw rqexGaUX73vGcpe7oc54c1+PVdQltlgxhN4JPOPpXrvh5QNGtgPQ/wDoRrwuzuLDwz4ncvdr JBdnyghhO9D/ALPH/AeK908OAto1sWPJ3f8AoRr6vKKahi3KC0cf1R4tSs5U7Setzyn4v2X9 pa/NZKYw00WB5iZQ/IOtavgsEarBHliwhZc+vy1T+Ix/4riD5FJ9d+0j93+tX/Ax/wCJ/F/1 zf8A9Brwqjl/aUI/3/8A246uX9xfy/QXXPDbx32o3EEl3JFP+9aySMsHb/ZbHDZ6N9a4GTwx qMj7pPD18qqW3ywxlXkP+593vj3r3PWdf0vRjCuq6hb2jS58sSPjfjrip9L1Wx1a2abTrqO6 hB2F4zkA197yx5rXPDnhJcvtGnbvbQ8V/sLXnG3+zryeGPbFC8kRRox3Kp6ZrL8PeENaXxXF carpN8bcFsyBHXH+0pHQ+lfRNMan7LUj6ujwrT/A+v2+qtPotmdOUvveS5G/f8ytu2f+y+or 0XwVpuqaVpUFpdxpNIlxJ5k8kflu+5s715967Bcin4O7NOMOUuNJIpSWSTK3mxKc+1ZK6ZcQ 3M/lIwgz8idvurXRqSV+YYpG/irS5djzSx8O6pHu328w5b+NP71aK6Jfd7d/xcf412q9KWvB nklCcnJt/h/kelHH1IrY49dDvP8An3/8fFC6Hebv+PdfzFdhRWX9hYfu/wAP8g+v1PI5RdGv P+eQH/AxTLrTb2CFnSBJHHRPMC5rrqilj8xMfKPeiORYa+7/AK+RLx1Q8s8R+EdZuNcs7/Sk sRgbnMxHDL8w+Xvz/FXpXgWyuLDwrY214EW4UOXCNuGWdm6/jTfLkjDbtvHStvTh/oUX0r1M Pg6dBWicNRuTueP/ABIz/wAJzDt3cDnGf+efer/gQ/8AFRRf9c3/AJVQ+JBX/hOF3NhgBgc8 /JV3wE3/ABUkH/XN/wCVfHTX/Cmv8X/tx7X/ADD/AC/Q3fF8MkXiXRdQNg95bRRTwyBADgvt x8p/3a5vxLHex2+pNpLapYNJ51xGlvJHCN+yLZu56Zb9GruPFcc7rYSQWb3ccc2ZYlxkjb7/ AO1WBd6brN45uLHSdPVD5kRt77CHBVcNuUN/dr69VKlPFXSv8tNv66nm16nPhlH5fjcb4t1e W1Oix21xq1zqdzbtKtlpcaSNIqAM8py4UKCQPvckqBXK6j8StISVPsviS+nWS3glAQwRZeZ8 JF87ghhyxz8qKPmbmtK403VPDep+Gb2yOlz6va6W+mzW91cPFCyO8ZWQSBCBh0xtbrnjmsjR vBcWkSWlp/aukTSCXTLl5BL9/wCzTPJct0+XcZlChjzXpK1tTj1PQPDPifRGsdPt5NVihvLh JHjt7u7R5nRHYFuHbj5G7/wn/arc0bXNL1u2a40e/tr2BH2GSB94Df3fyrxex8A3Vvpmp6TJ rHh02esKftEzfvp7Zx5qKsS9MfvFOcrs+frndXcfD63stDiv5tQ1HRhd3ZhZ/st7NcfIibEL PMxb17AAYXnrSdgVz0Ckbq1YjeKtLjEpeV0SOFJi5T5cMuQP72SPao4vFuiyp5hvUjTuZBtx /nj5unPWkWbS9KWsS68R2lvbW04juJ7e4fYskacb2JAT5sHOR6fL1OBVZ/F1qlvPL9ju9kHm b87Fw0TKsi/e+8Cyr7n7tZFnSUULyqn1oxUgFJS4pKRRWvELp8o3Vrab/wAeMP8Au1QkQFav aeP9Di+lXAhnjHxOP/FcxcDt36fu/wBa0fh+f+Kkg/65v/KqPxJiL+NXkEm1YwhIx1yn6U3w rfxWGt28s0nlq58lCR/G/AX86+LlHmzJf4v1PaemGv5foexUVz2oalPb2csjXGzA4JTdz9BW BZ+I73W9Nllhea1ns3DTBHRRN/s5PbH/AOuvt5vkdjwPaI6fWNAstWnaW8Te3keSOhCDdu3Y 9aypfBOmzMxlklJ3fJ9zCLlsDG3n7zDJ559q4Gfxfqh1po7LV7t7Ux7cTAZ2/N83Tg/N972F ZNj4114zO6XNyVnTyYFnkyQ/Tdtz/wChVl7dC9qj1I+AtKI2lrsxc/IHCDb6cD7vt0zzVyXw dpssDJK107vM8zv5vMjuAHZuMc4Xtx/DXK+AJtc+33Q1i8mmXZ+7zNvFdxJI+xOW71vD31cf NoVm8K6c/wBxrpFCInyTkcBNg5+99xiPxqNvCGjFPLa2laLZ5Wzz3wU4ynX7pwp2+oq/A5+b cW/GvG/jZ4i1PSb61TSr+WBZZJd4jfbn7vzVoqXMxTq8iueuy6Dp1xIkk8TsVDhf3rqOWy3G eue/sKY3h/R9rD7MvI2n9865z97v/F39f4s18sJ4y1m1Rf8ATJXbO4Zc8Cp08a6yAqNeTF36 neamWGq9Lf18ifrdM+tFkiRVCugUfKBkcUedH/z0T86+U7nxjqIhx9plLuf75wK5zWPGGsxx +ZaajcWzx/MjpIc5qJYSvbdB9bp9j7N+0QD/AJap+dMa7tx/y1T86+SZfFuszlXfU7su/U+Y VquvinVRcbG1C7279v8Arz/FUfU8T3X4h9dp9mfW8+qWkP3p0rX02VJrCCSEhkZcg18dv4m1 H5Ue9uX+fbzMf4q+pfhnM1z4A0CaYlne0Qkmt5Yf2cFz7ijX9o9DgPiMf+Kvuv8Adj/9Argf G11JaeHJbiGRo5454HRx2ZZVw1d38SD/AMVjdf8AXOP/ANArgvGM1lD4avJNVt5bm1Qoxjjk 8olt64+b618Oo/8ACkv8X6n0lT/c36fobui/G3TtUs72DULSbTtSjjLIIT5yP/tL0+b/AGa5 K88afa2d0Rk8z+K6kO9/94At+teUXd1pk13v0+yltmHzfPP5uf8Ax2r95f2YlU2ztI4RWkfI 2A/7NfcVI9JnzkOSaub13r7x6vb7zE8Un+uRAcY/+t1rbbW9It/3UF5bFpT9wAneW+orzC5u 0+0wD5t7nbWfaTE6pb85xMF/8eohCDvdCqx5LWPpf4Nakj+Kb8XEuyIWjYUnj761n+L/AIxa xYeJNUsNNS0S1tZ3ijzGWJVfl3M2a5D4d6xBpfibUZbsvsNvsAQZJbetcL4ovfP8XavKoKLJ dSuAeo3NW1GJFaT6G5r3xg8WalvT+0PsyfdxAm3/AMe+9XLWfiG8up3/ALRvZp1zuHnOXwT1 60y10WGSXdqFyQh+bZBjP5mteS10TTfIbT7eSRmXLvdlZDntj5cCtoxdznlKNtR6XSXW3yvn YfLhBup/2qMNneu2uj8L+ILdn+xSv5C3H7kSRjGxm+Xt/vVuy/BS2gleJ9TjLINz4lXj9aud odSIRc9kef8A22ORvvrTrrR7/UbDzLSLzEfphwpPze5rt2+EWhQJOZ/EDmUKSiQup5/9m+gp vhfTYrGyls4pJZFgkP8ArOoJ520QtN2HOLgrnK/YNQj+9aTfgA1VJZPJuGEw2SoeUf5cf71d rfHZKwrita0mzvNRmmuL14JTgbAvGAv3q1muUyhLmGvdx/LukXr619m/Cch/hr4aZehsYv5V 8hXPws1K30dtVd5FsBGs3neYn3D/ABbc5719d/CmAW/w08MQq28Jp8Q3evy1x1pXOulGxwPx MP8AxWd5/wBc4/8A0CvNfiWf+KK1D/ei/wDQ1r0f4nH/AIrS8/65x/8AoFeZ/Exv+KIv/wDe i/8AQ1r4WC/4UV/i/U+tqR/2J/4f0PJvCWj/ANu6x9la4+zgRPKZMZ6VoeIfDmlWkTxxatcT OevTbXKWd3JbXGYnI3gocelQ3N68jZZ6+9fJb3kfIKNS/usljRIUaNp3Ze2zqKm0mF59Xsre yilmkeZBHGBlyd3TiszeX7fL61o6LDcm/t5bITb0kBEicAH61jp0NXf7R694C8M6rd63eSy2 EsMEcPzyXKGJEO73+n8NJrHwo1LVdZnvdH1vQ72C4nO8W05lMO71VFOfwrZj+LkmhaLBYeIr O41K88vNvM77uOnznhtw/vL1qq/xZ06OcQXYkvYT997YO6D/AL+Pz+VCk4qwOz1Za0j4V6Ho +2fxDqt1fcMwSGHyISF67WJ3Hp/s143r+qRXOp3ElrEYYN58uFE+4nYflXuK/Gbwxbutylpq 13dW8LLbh4Y4UGdoK8MccfxY7V5r47+I2seL0e2uHS100vuFrCMA+m9vvPWsJMznGBT+Hhxd vqWx5fsh3PGvBA2tXU6V4hm8Q6i8Fjpel6lKh4F/MkROP9k/Nx/vVxngrWLbQr+eS6SV7eWP Y6IM5rQS+8NiZ5EnvYd77sG3DY/WicFPcqnV9n8J6JPpvieO2cfY/CGkZHDyTw5G786qa1qZ 0a2cy6wmuXkkaYS0RNkG3quVwCv+7XGwXfhjzk3382wdcwEfyFLq+s6VJJFFY3Ie3jj2glSv 8X0opQ5HuFes6kSZfEkMrZnhvI/96En+WajurnQ74ebdC7uph8iR2rlH29e64/Ostru2LfJO n510vhm7sk06Xzbm3DvJ0eQZ+7W05uxzQSuek6lqVlN8GbKC4d4/Ot4YXhWdPOQK3qcL/D/s 17j8NBEPh94d+ziVYvsEG0S7d+Ng+9jvXzD4nu7ObwxLFDcQvhEwBIG/u19QfDgbfh94bH/U Og/9AFctf3dDrovmVzzD4nn/AIra8/65x/8AoFeXfE58eBtR/wB6L/0Na9J+LUxh8a3RwCvl x5+bH8FeZ/ESTzvBN/tLR8xffH+2tfFqP/Cgn/e/U+tl/uf/AG7+h4Swf7x+THr1rQ0fQb3U 5FNvDtiP/Laf5U/+v+FMt4o0kVmQyEf3+n5V0Nrf3bpjLba+20lufJc3Y39F8JaPZFWv5kvr j0c4jH4d/wAa6W5t7Z2skiRAouE+502/NXH2sLz/AHzXQaZCE+dCdo+Uf/FVrFraxjK/c5r4 toBq2n7EwgtfT/bauKQj1H517Pc3UsIgEUrBSXz7/KtU2ut/+tgtZPeS3Q/0qZR1H0PKKcte oNHp0n+t0bTz7+Rt/lUP2Dw/Ny2kQp/uSSL/AFpC5TzdjTK9Ek0Lw5Jyttdx/wDXO63fzFV2 8M6A4+S71GFvfY/9BQHIcFSZruX8HaY6/udblHtJa5/k1Qt4GXrBrVof9+Jx/jU6hynIoalj 4NdP/wAINfDbs1DS3/7blP5rSf8ACDa5/BHaTf8AXO7jP9aoXKzFVxt6L+VffPwz/wCSd+Gf +wbb/wDota+H38GeI41b/iUXDr/0z2P/ACNfcfw9ieDwH4dhmjKSx6fbq6FcFT5a5FZVTow6 1Z5F8Wk3+N7wZYfu4+h/2K818bQOfB95FlTzFjaMfxrXpXxXP/FdXn/XOP8A9ArhfECJJo1w jjK/L/6EtfHr/fl/i/U+vnH/AGL/ALd/Q8ns9K9Rmtu2sUjHzCtCOEdFGKtRQp6V9nynxtyv bWm9l7LWpkRphe1PiREXpTJQhb5auKIkUp8u8Qx82Xb/AMdWomhJ5cMFFXVhP2lHYfIEOT7t t/8AialYIavlEZLjHaq7Rv1YYX+7Wu0I61VuR97jH+7RyjuYF3NIW+XcFqqtxKnGWrVuY8/d qhJbvWcihi3brUq3r+rVB5DjtUsdq7soRGLH0G6pGWVvnx99qmivX6ZqpJbmF2SUMjjqHG1h UsVu77dgZ2J2gAZyaYjSjvXCty1fZvhL5vCeiHPWxg/9FivjS70TU7LTYL26sriGzuBuhmdM I9fZng//AJFLRP8Arxg/9FrWdVmlM8Y+LB/4ru8/65w/+gVxGsc6VOP93/0Ja9M+KnhjWp/E Fxq1nYSXdk8aD/RzvkTAwcp1b8M15bqEySaddIj/ADphXT7pT5l+8v3hXy7ozWMUmuv6n1rq wngnFPaP6GCo9qsQAk/NUCED78iD6nbVmK6tE+9c2+708wV9dFHxhYUfL81CpzlttOjIueIU lm/65wu/8lq9b6Lq0wzbaLrMo/vJYTf4VXNEOWRRUZLU1k7tW/B4O8UT/wCq8N6p/wADjRP/ AEJxWjF8OfGMwX/iRFB/02u4R/JjR7WHcfJPscY0eage3J7V6Tb/AAo8XSH5oNLg/wCul4zf +gpWhF8HPEDf67UdIi/3BNJ/8TU+1h3H7OfY8ektCai+xf3hXusHwSuWX/SPEMS+0Vj/AIvV +1+CdgP+PrW9Rk/65xwp/wCymodWBfspnzy1l7V6H8O/F+l+FdDa2m0+4ubp7trrzEA+Rtmw bcn72C3516pH8GvDUf8ArZ9Vm/37kD/0FRWhD8J/B8Y50t5v+ut1Mf8A2aolViyo0pI8hl8f ael89zaaB98rlJkhYIN3zsrbC24hV6naPSoW+JhhhWJNKiGCW3vd7X+7t3ZRR857t9duN1e6 W3w68I24+Tw7px/34d/861YPDWh24/0fRtNi/wBy1Rf6VPPHsXyS7nyn4u8V3fiuGCO7jiHk l3AgdzksqL0z/sf+PNX1d4UXb4X0dcdLOEf+OCtCK3ihGIYkjH+woFS1Ep3HGFhKw9e8N6Hr U8f9saRYXzr0eeFWYfjRRUGo2Hwd4ZtVX7P4e0iP/ds4/wDCtC0srO3/AOPeztof9yMCiigC /RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//2Q== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcQAXANU5AP/MVf//zPz7+/vlmWZSX7uWWo1xXdDE0J2dwzQqZEtLk7Osm92qRO2+ VoiIVf3XdJiUaQQGavHu8srJ2nt6rAAAZu7s6goNdtTU5eno8t2xV0Q2YQAAXCIbZLihVMql Sy4uguLf58K9rqahftbM1v7PXsyjWB8feBEOZQsLav/RWLy3yv/+3xQUcFhYmfPHX7+sX87B zmBfndCyWuGxSuvFZ+7BWvrHU9nCcP///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAA AABxABcAAAb/wJxwSCwaj8ikcslsOpOCqIBEUZwiJwVlIghBHOCweEwum8/otJo8EpEsgqM0 Q4nY7xFOShYSsAKAgYKDhIWGh4iJioIDAzgwIwdRRVETIHiYeScrfouen6ChhwM1MCJwRAIZ l5mYHCcYAg8AtLW2t7i2Gia3BQ25wMHCwwAlDwMBAyUzCxJxQgJ1rZkcLhkBJcS1BgW5Bhu3 Fd3a5OW4xwM3ps5CEy0RXAgX8/T0dimcA+QmFeC43+HG0dJAwBw5A7yGlSDVYEQsIRQ4RFCA QEC9i3Y4yJCgTxsBAxV+1TKhASCABt3E2SpQQZfAWyg10EIpcuQvlcQePGhgCpUC/zvzok24 MLTohDsgMrAg18HEx1oEOiTYAM4Eig0EcAJgWaGCAQAGOmzoINNW2LEATIjt8BVAvw38uvob 9oDBjBF9clyJMK+iggt//265k6KPNrVgC6YNCWAqAAIFWb5kOZAxZFsNKiRM+yssrQqK3b4U VpcGBAwSctyZlyAa0dfR7nAwTMxAQQ2MTQJEMU7r1pZg/RXoYDYBrgIgPwv0LawEA9MkUu+l N2FoYAUCEtipEIH2sAQfDaD4qhscTt+Ug9NKT8tk+w6QgWtlHsw5AwgHUv/kOw87hf9bDLVd UksNo8F4BthWUHkA8KbcSsCZNFxxtnTQTXrzjVYfAx/gl/9aRPzNw4UUrt3hggQB1BYaPw2w 2Bg4l0kGYWW/XFYLbps5mJxotdAHzAscjhBdDkdVQA9F9SDw1x0VdSRMAi9Z+JhUVKV11QYO 1tIACgmQt1ZZ26wF1lVZPUjLWKHVRwMDHiyAWg4CyADUBRXJQ6cA8tihwDXZGGQLSZhpOJNA Ggh6ki8DgZkLosM0wCEEK+TVxQkSAaZkf3ly0AIXA6jg56eghmpLCY6yucAbcUSxAqXcTdNC RQHYcIOotNbaXAkvrMnmCDHkBWcUGLiQRyYdKMBFADUwoOyyzDbr7LPQRivttNQ++4EHvKL2 DJzOZLCCDJdwUAEILiCQwRQeVKth7rrstgvtB9dCsEAM2lIigTMSZBDCvhngK8IXawQs8MAE mwHBCAusQEII7BgRxb0kqhICCQdUbPHFGGes8cYcd+zxxxyTgEEIcGwLhQD3pqzyyiy37PLL MMcs88wrT2JEEAA7 --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhQAAMALMPAMSfavv49Kd0JrePU9zJreuYEefayMaONbGAN86wgPfGVfLq3vKwM8+I F92fOP///yH5BAEAAA8ALAAAAABAAAwAAAT/8MlJA6F4GTzN5k9gLOBDBGXaCSS3DEAJDChn IF8m5CoXAIIEyCA4tCgvxIWTCNYoCQTg2UMiCgjqY5E4NISY7gFMMQAaB15ogD2qRAMEosg4 COTxOYLhuMvlAgIODHoDeXR6CIcHCgd/ACcpAVEFDAoKBZmKMJWXmQ2KB50Mn3EDDgWXpAUC hqiemlM9FggNlgUNAhcvogqkRQGTV764CCQ3g765QjcHt6yRVRYNmQVjHWyfxhI/1JkHSw8J ANVfNQTZuAlakgkNuQ0OA9isteASZqAC1mQADvANALTwl8sLjSrc5kwZcIcbgTsECMgB81DX jSDcgBgBIOcDQxoANxy5UbFAF7cmJBbMaHEjhrgdEl4cvLFOwsMNC6ScY4FQBI8AGrZEi7lB hBujJtQQOGaAigd2EQAAOw== --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQABLAEsAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wgAR CAC3AJYDASIAAhEBAxEB/8QAGQAAAwEBAQAAAAAAAAAAAAAAAAIDBAEF/8QAGgEAAwEBAQEA AAAAAAAAAAAAAQIDAAQFBv/aAAwDAQACEAMQAAAB8dut9V4nG66orO6CTUYCRYAgX5jn5dTt 2TbDn6cz1458s6dc2cokx2ea8Z3RZtVkES4NDmhTs5YJVdTy6MEPRzUPnjHVNqrWadp2klHa swjUZNLthTDl+EZl0I2n0maZYbJXGc6UNKraaNXlojtCsjxmebz7UVordSIT0I6ZZao1XLLT G2zjFGpadpLWyWhnotZU65SdV8z0/I4PW833vD9rz2cnf1/Gzy0R74ZoaYXGcYqXvC8xe0rQ NapohcfrTtj8v2Mlm8n3Mur5n10p3n0HhxjePTzQheFlgdLHt89kGm0LQOvf5e7l7Ldi0724 nQzJxcuTxvfzEzlWPZ5soVhdJHCpLZ7DabZrRGnVhrCm58TTtsMorac6qydmTpLkXjWaQpG2 mKVPK5646bZayXVTNSW0tnZG0ERTVZ8IeazcdkSoOS7KxUQdlrnox0VzUmmmmV5jU2Zk2juc GuslOrNEbNPk3PZE6sEx2Whok0qM2HGOqrd71dw6oHeS44oiq2afKloT0oz5zhTe3UPnG8zM HtDoF8dAAA2OBsAHcAJ5wCwAd//EACUQAAMBAAIBAwUAAwAAAAAAAAABEQIDEhAEFCATISIx MhUwQf/aAAgBAQABBQL4QhCEIQhCH+O5me05h+l5jPoefb3l415hCEIQhCEIe95x+p5b7vmR 7zmH+/MIQhCEIQgl+WV2XVHVHJ+Jv+vEIQhCEIQhBL8uP7Z7OPSRyaWuPX9IQkQhCEIQhCCX 5ZaS1v7ab0M3/SEJCQkQhCEIQnh+Gyj/AGhCEvEIQhCEIQaGMfhCEIXxnxYxj8IQhC+Ot04+ TfuePk+pnWp4YxjGIQhC+G/tjeGuPHG8nEpj+uZjGMYxCEIQvPN9z1u5j0tzw/TU40oxjGMY hCEZIjr41xdt83oc8uVx/T5d7XXKmGMYxjEIQjjc3nMF+llGUrEdBcaPU5/Bp3/jGMYhCEIe 9N929Lf5LZ3Ozj3XvfYYxjGMQhCEfUPqHc7o7ndTyxjH4QhCF5pS/FjGPwhCE/FKUpSlKUbG MfhCEJlKUpSlKUo2NjH5XilKUpSlKUpS+H8aUpSlKUpSlKX40pSlKUpSlKUvwznSf2tydsHb B2yLWDtg7Yj1mfHtk7K61VGe64+3vOI5uVb1S/6qU7I7I7I//8QAJBEAAgICAQQBBQAAAAAA AAAAAAECEQMSIAUQEyEiBCMwMUH/2gAIAQMBAT8BbLLLLLLPtfwXjL5ojVHovjRXZT7XwSNR xGuSQkdOeLG3LIzqk8eXL8CaofBEY2KJRCGHxqzL7k2h8EYJpL2bRNojlAh9Z4vikSdvjGbX 6FlZ5WSnY3zssv8APqampoalFCRqUNsXosssssvv/8QAIhEAAgICAgEFAQAAAAAAAAAAAAEC EQMSBBAhFTFRYYEg/9oACAECAQE/AbLLLNiyyL5H0bcj6F7eRsbGzY2Ni/A5OyLdifgbGxyN jY2LKExDY2NllliYmJ9SJDGzmQy5Eo40ZORl4tRRwss8mLeYiPUiRJlmKcYyVnOyZsvIlSMU dYJCI9SJGReSmUypDw7eWRRHpkkSjZojQUaEhIiumhoaKKKEhISKGhoaNTU1FESEiiWaHybX 5R+H4fhRR7Cf116Xh+WcXDHFiUI/1RRqf//EAC8QAAIBAgQEBAQHAAAAAAAAAAABEQIhMDEy QRASIjMDUWFxIIGRoSNAQlBScJL/2gAIAQEABj8Cxv05SW8NsfQaY9x0vbHz+xNp84HEL2Rt nOWOiXW0d1neOnxHVjofU18jVV/k7j89I+tt+2OjU0dNdUl/yOSMkZIyX7jU5tsUqmre5MQL 1x2XsV+JKaiE1w9semnzfChfy6mb/UcLEzM+HNzNGppl8tiE7iWGiqnzI9JIkRffjCTlkOh8 3J9y+FS4yG4E4FbIuh+pdCxPl/QGh/Q7NR22dtmg0Gk0GktT8XbH+GWogyJ5nwtj7m5//8QA JRABAQEAAQMDBAMBAAAAAAAAAQARITFBURAgYTBxgZGh8PGx/9oACAEBAAE/IcgsgiH0QAA3 QZ7u/bp1t3PsH9+YYl4HLp/e0wMcd5/x9+bEjVjjsEEEQh9EAPhzWGXig65/l5rGeGd9E+Dv 3duSfMEEEQh7wDP3Fqpt+Weo5duHm0N3+mGB1PuXVggiEIQ9wDP3EnEfe27Z9v8ArtIOlrrz bXNHc6IwQ9AhCHtA1n7CQirdwiF+UJjXrCEEPYAQ9oGMSX+Ev+V/hT/iuemEIegEQh7AYx9A IQkhCEIQQWWejJJJIQhCSEIQhBBBZNy3LJoADwdshgAx5ZJCEIQ9gEIIIJbRBzjYGMPnZ3Qt ZvL1s66Hg7CHoP0RAi5PnG3g+0BPej58f8uv0/BNhhz18/TAQi4uXi4wPGQOjZXCGYTc+c6z 9iQF2wuqLHGX2Y+mAm/+YNhy0Liel0rUaamwNV15nY08uMkaC8d7VnR1zO9r4yfD5nNnxPk8 3Ie7OfeAvQpg/sjuYMsOwGWB1Xu27OXOlxOeVmOmHmwDMD5sbuc+ZS9kUpylC3jg4fxY568/ xZ3vkZdGxh167PA5/pLLLKUpSylKUoYfYNllllKUpZSl6AxCHsBjH0ClKWUpegQhD2Axj6gU pYZQxCEPbBrGMYspYYYYhCHuIYxjGLLDDEIQ+gAMYxZZYaqkzl4PHMidJ0edv9SOTn+405Wf e1uvH+LmeUZNe5MQp87ba2sr4nfDLZ+/M7hjTp1yJjV9r5H6jn0+MZY4/wCRZ04Wfm+xt+G3 4b8N+G/Dfhvw2/Db8Njw2fDfc9Zv/9oADAMBAAIAAwAAABCI2KgGK9Jr/wAWdz2Fp2QPO2YF mJb40ORQJai/LkhMXzd6sIwrc8Mw6Aw0v5OwGyyoYfvwMyy0b1if+1S9yARcC5Mms+ghNQkU U2cMnAXQ/ERdRB9cejBfhBcB/8QAIhEBAQEAAgEEAwEBAAAAAAAAAQARECExIEFR8GFxwaHR /9oACAEDAQE/EIY+gCKw7SPnZG9Syy222y7ghv3/AGcGe/38z2ll4zkOmQMIRdWe0vAcJrxI eeBIbZjmzjHgP7BHOAdnvGsIcvBhpKGsQCZcJZDpfRZSHHj++YfN+kY599rDAUSeT9/8tB+e WPRJ6+fAsWScDHCxeAskks9GQQWXb3k/M/nftPXzahW/lgfPBBi3Rhbt27duFDx//8QAIxEB AQABBAAGAwAAAAAAAAAAAQARECAhMUFRgaGx8DBh0f/aAAgBAgEBPxBjGutKJ5VKGD5ScPFs FdAjzQkH32nhTj7+ribLHQIZmIK5ZgwEsBspa4xnseGUp6DJHzhuA+IxbtficoeNQRxJep46 klNheOLNL0GsdQhO8LHcsZpMUw2AxCCOgPaaxj6bCA2WumfgvJXQNgYg3gPqWJwZPSViue0Z XEKV8hmXM4k+PcP5ZHMHnIbMWEGwv//EACgQAQACAQIFAwQDAAAAAAAAAAEAESExYRAgQVFx kdHhMIGhscHw8f/aAAgBAQABPxA4A5CBBPjPGO2MMOyAbhbXq0QKuokezHTU0NNOYCBawXUo by5YM4mJNyCF2BhaWGHuXLTzmoWNYecEE2Q4hl2xl2XMvR6FMZvH3r0IqyQvKxFazkY0xAAy wUFG7DvlXN5bl3YAwAakt1BfBEshaVrmPjYhJtnjwu2O3g2mllf3FE0hwFVep9/SAHJKpZoz rpa+kGUKXYJRdDr95QXJusFb3vAqOVpV6tc90OzCThsvC+h/3C7UEq9C773R/ssKak0Iltfp 6y6rIWlTdunY/P3MH4tAqUvTGGZng/R9BStDDbPGO3gbM9E/uAyFQlKVX6/EQVUoApg1pFC9 uDkeD9HMoO3wDbDhvGijZhGyeS5GBas2o9iuI6PIdsTYhwHkFWcimb6Ba6ScJ567+pM30ao1 JspLAvFGP4g7d6zI5bNNBmdKvS7GNUVpei/xyQa3CyQ6Qw45ooQUDsqL6fmUhLdrfgI6aWeF K8EB17wQ10uVX6leX/D14geAdYM8IhhgghgiRuwbHykJN0pH21lLAtWPEfkqAgDgWFtHeCCG HEMGeHonTOmYWFYXv0lbZNL6XPvSunvAhsiHaFh39SMnpjaXuMEgO3sA1l2JkaufMKqqsjs8 h0vDqjij0jlw1WD4cR6i8MhZ+4HbiO+kTpjsYMTDo6VoQCAUp0Z6xWUFH2qASMAACCKt9A3G bFjoa/iDsgDoddvq5uASrIF3esceI9Zqj0jmKPgH0KmAN3nPa51G+l0B5iamxr1xrCQgVCpi FjItcqrrBs1lbt3lPAorDPeUKgtXZb3gtqwrDNcSUesWeFpcgJHlQwAbw1hkF7XTpsNoO83K 6fMAMlUA/wC/xKgF0UuqZxLEGRWemR335XnUmtws30A104h+hffs30xbgHkFUTV4pn+gqU7v D5x+hTBc/NvW/wAAk3zzjv4G/wA3W5uf+HdhJwWXfN2b/wBOrBo3YSb558PnGXlhd8yTMDmL vTswRIHlBg59z0reGivyGiyzMwAEX33/AHrLGGJRTsYe6Ostf9u4wjIVS4V57/uN9YODKVDg 7Apevr3iylpEmpfsx7DHsPpO5ek/xoZbPqEen39KgqQIKZM5ya6bR+LUFDH4uPy6FoKg0mtv 8SqhGtb9vEW0qLqv3Nr1/MD8vzM/dPef0p7y35T3lvznvM/Oe8z857y09095/SnvK/Ke8fmT 3lPu/MexKPSNqP/Z --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACgAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAFBAQGRIZJxcXJzImHyYyLiYmJiYuPjU1NTU1PkRBQUFBQUFERERERERERERERERE RERERERERERERERERERERAEVGRkgHCAmGBgmNiYgJjZENisrNkREREI1QkRERERERERERERE RERERERERERERERERERERERERERERERERERE/8AAEQgArQCgAwEiAAIRAQMRAf/EAIwAAAID AQEBAAAAAAAAAAAAAAAEAQUGAwIHAQEAAwEBAQAAAAAAAAAAAAAAAQIDBAUGEAABAwIDBAYK AQMFAQAAAAABAAIDEQQhEgUxQVFxYcEiMhMG8IGRobHRQlJiFCNysiTh8YIzNEMRAQEAAgIC AgIDAQAAAAAAAAABEQIxEiEDQTJRcSJCBBP/2gAMAwEAAhEDEQA/ANmqfWdaGmZRkzufWmNN nt4q4WQ849+Hk/qQKT+a7ySvhhrB0Cp9/wAl40nUbm5vohLI5wJOFcNh3bFV29A0l9MnTtqn NFLTqEWUUbU/2lQtjxlvqoqUKFKqcx4ozHioUoJzHijMeKhCD1mKMxUIQesxRmKhCCcxRmK8 1Qg9ZyjOV5UIPRkpicAhsgdsoR0LjO3NGQPT4otzVo57/QIG1kPOPfh5P6lr1kPOPfh5P6kF BaVIdStRStBWoTWjZDqEPh1pU7eRSlrl+qm0Zdu31JvRw0ahFlNcT0Y0Kr8r36xvFKhCsoFK EIBCFKAQhSgEIUIBCEIIQhCDncdwn060Wwo0c/TcEXB/jci2rlFeO41QNrIece/Dyf1LXrIe ce/Dyf1IM/aPDagmhPZ204pjQsL+LmfgVxtPBjjfNM3xKFrWsJIGNcTTHCnvT2nNjbqcXg4M NHAVrSrK09ShOfGG4UIQpQlC8lwBAJxOxekApUKUApUIQSoQhAKEIQCEIQcZ2GQAA09q6xgi gdSvRgqrWHxuyRukYx+Lg2QkDnzG7bvTmmvD4s+YPzPeczdlSfp6PigsVkPOPfh5P6lr1kPO Pfh5P6kFdoIkzOcx+UVGAYHFxxNOIFBuxXPR8NSZX7nbORXrRmxuD2vrmOWmVriaY7Muz14E VCjSG5NSY2hbRzuydowKDdqVCCcoqdyCr1WUVawbRilG61JAQJBnb7Cuc7zK8vO9KvjDlhdr nMd+vrnWTZprS9iu25onVptB2hMrFBklu8SRGjhwWssbsXcQfSjtjm8Ctddsub2evrxwZQhC sxCErdXzLfA4u+0Kql1KWTYco/FVu0jTX17bfpePkbGKvIA6VLXBwDhsKzFS81canpWkgIdG 0jgEm2U7+vpI6FCEKzJXahDIaOYXE13Fgyin5A7V30yQyQguJJDnNOYtJwP4gBK3rJbh5gMQ cC4FkjmBzWtp2j/VXdyTentcyIMe0NLXOaKNyggHA03VQWCyHnHvw8n9S16yHnHvw8n9SCs0 VzgH94MBa5z2yCNraV7xpjy38FOlyCXU43iuLjtNanKcd21GhljXOc5xBOAAeGjYTjWoOzfh iuOlPy37HNNaOd68CieW/XmbuO5FKi8dvAK6i5jeKONK4YqMxbpZVE4LicF7lcAacEsZVg9G Tw6Fyf0u48OXIdj8PWq3NVDXFhDhtBqplNte0sbFK3tz+uyo7xwamGPD2hw3iqoNQuPFmPBv ZC12uI4PXp2288Qq9xcS4mpK8VUFy8rF34dWlX+nOzQjoJCz7Sr/AEwUh5kq+vLn931OoQha uNX6nNLEG+ESCTsaASabsd3GmKatHyObmlBaS51AdobXCvTRI6nmlAiyOIruYxxIp9OY4c9q Z00NbC1rQ4AEikhBdWvQf9kFksh5x78PJ/Utesh5x78PJ/Ugo7C3hmDjK4NyEONTQlgBrl4k mntUtdHHdB0GDaZgK1pVuyvQU3oRdlkDC5pq3tRlgO/7yMOSTt4i26DZBtqceBaTuUbcVfT7 T9njfS/cmbWWS5cWvOAFUxp+nsJc+RuZhwbmT0enQRuztBaTurgvL3/06a26+XoXaS8KbUAW EObsOCQDi48StHqVnnicYxUgbB0JKytxAKkfyHb0K/r92u2uYmbZ4c4bKQCshDRwOJVhBaxO wJJ9S8PdVeWOocNynvU3W2cr+JuSMNbuFBVZq5t5IXEPG3fxV7FPSBr3bzT3qJSJBR2IXTds yfpyaZ1tZkr0E/PaNrUYJN7A3eq5a/8AXWBq09vF4UTWbwPeqbS7YzSeI7uN95/0V+ttJ8ub 2b9uOAhChaMVVq8AcWyBmZwDtpcBQf078fcUzpJaYBlAaMzqZa0OO3tY4rjq+YtY1rgCSaBz iwEjHb0cDgU3Y5slXuDi5zndk1AqdgPQgfWQ849+Hk/qWvWQ849+Hk/qQVuiRh2Y0ZUFtDIz PxNBw2bdq5WP82oDO0Crn1a3YMClrHNn7Dyx27Lv943e5MaOyt+xvEuGHIqm8t1snKZ4raAB ow2ALkZsejiicOiwJw3FQcuXABfObeu63G88u2Yvl0jfWtFxuog5viN2/FLtYWOJY7vOrl4m noTyXaKQNIjBqQfT3q3W63trU8XMKxwySEUFBxKZZatZ3jmPQvd04MxSsNzV2Vd3rveSxe7W zPBi/d4NuwDCp+aQtLsk5XKx1eIuia0bR8lSwRuzigxXbZiqevF1tq2lNW1SVrZvu38Ix3nf L0wVwy1GWsmASc+txQdiFuamHAK01+a497MraKJsTQxgo0L2snL5iugey1gHInrXa08yuJAu GCn3M+S1m0ZtKheIpmTNEkZq07wvaslXXEoZI5tzG6SM0dGRHnAwxG+hr7arvpzXNi7TclXO c1lAMrScBhvovV08sZmaaUPR1rpbPdIA5284cvUoz5wt18djiyHnHvw8n9S16yHnHvw8n9Sl VQ2hox+3ZuPRw3rtoP8A7oeZ+BXKz7jz6bCu2hD/AD4uZ+BRLfOaHCjhUJR9g36DROIWe/r1 3+0TrvdeFJcxywdprTgKYY7fh079gSNjFLHK+ebDNSgOBwWpJA24Li+eD6ns9ZC57/n1xddb y2ntv4Zm/vC85WnZwStrIRK01+ofFaOVumSHt+ETzAPuSE9rZucBakl+2jcWinNX19U0kkTN 8/C2ummSQMbuC9RxRwHDF65+I9ozEULscy8CUNxKvtfn5Ri2YnDvO4lpqsnM05itDLdseMoK rZrepwWcrLfSxUvZVLkUVo+3c3clDbukcGsFXHAAKZWTvpV3cQyhkAz5trNx+XNbME0FcCq/ StMbZR1djK7vHh0em1WK6NYknctkqHA1oey0NqdnNdrSob2ttccKfNcbrxN5aGV2mtR6wV7s SCwUoRU4itD7a1Vf7N79Fish5x78PJ/Utesh5x78PJ/UrsVDaYseN1OHQV20H/3xcz/aVWpv Tbj9a4ZNSuWp9dCmUtzqOqR2Dau7T9zB6YLMu1+6uZMuYMbwb89qVmuDJmfIak4lV8JOeqzt y064w0Gdz8XuJPSUpcZVw8ZKXNxXshYzW2tbtJHeJuZ4WutbT9a2L3d9w9gWb8u2LryfxHf9 cfad0ncPTcthqLstu53CnxC2mvyy7Zsju1oyhpGFEncaeH/9bsp6cQnWGrQeIXpXslVm11vi qB+nXDTsB5Fdo7SYijm+8K5QqdIvt7btOtVrdPc7vED3pmC0jgNWjtH6t6YQrTWRgEFCCrJL XHjf/OmWnCp+Xx5LpagAYEnH6vQLopbtCjHnK3bxgwsh5x78PJ/Utesh5x78PJ/UpVZ9ti91 v+zmaGl/hUO2tKqLi1kspfDmFHDpBTFlOwsbDOD4VZO1uDnNDa/8etM2z2X+oReKA4Oa1rwd hIZTqRKqMlV48SmxbG48qWshrG50fLEe/wCaWHk5lcZ3U/oHzVeq/ZlvFJTFhpk2oyZIh2fq edjVrYPKtnEavzSH8jQe6iuY42QtDI2hrRuaKBJEXbLlZWcdlCIItg37yeK8akwyWsrRtyk+ zFNqCA4UOw4KypPSp/HtIpOLQPWMOpOqk8tuLYJIDtilez1K7QoUIQiAhCEAoJoK8FK8uFQQ N6E58lIb9s0Lp2tdlbyqaLvaXAuWiRoIB4pRtu6IRCJwLGdlzcMc2/2puzg8BojGwE05ElVm fltvNMfx/Pg8s55l0ya98N8VDkDgQemnyWjQrMXzuMXlg0sMVW1riK4+rkvekyCXUonBoZU9 0f0lbqXwvroq6T9PxBl7/wBOXagsqIoVX/xb/ER/BvzoLChUJD/G/Jeh+r0oHVGYcQlB+p0r 0P1EFXoxyXV7mwaZARXCveV2ZWfcPaFyH6q9f4vQg9eKz7h7Qo8aMfUPapH63QpH6/4oPHjx j6gj9iP7viuo8D8VP8P4oOH7Ef3e4/JBuI+PuKZHh9CkZOhBS/o2o3v9PUn7XIwCOOpA+5Od noXoU3IP/9k= --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD//gASQ29weXJpZ2h0IERDSSBBR//bAEMAAwICAgICAwIC AgMDAwMEBgQEBAQECAYGBQYJCAoKCQgJCQoMDwwKCw4LCQkNEQ0ODxAQERAKDBITEhATDxAQ EP/bAEMBAwMDBAMECAQECBALCQsQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEP/AABEIAMgAyAMBEQACEQEDEQH/xAAdAAABBQEBAQEAAAAAAAAA AAAFAAQGBwgDAQIJ/8QATBAAAQMDAwICBgQJCAkEAwAAAgEDBAUGEQAHEhMhIjEIFDJBUbMj YXF0FTY3QlJzgZGxFiQzNUNiocEXJTRjZIOTotEncoKyROHw/8QAHAEAAQQDAQAAAAAAAAAA AAAAAAMEBQYBAgcI/8QATxEAAQIEAgMIDQoFAgUFAAAAAgADAQQFEgYREyIyFCExQWFxgbEH FSM0NkJRUnKRstHwFjNic4KhwcLS4SRDU5KiNUQXJYPi8QgmVKPy/9oADAMBAAIRAxEAPwD9 U9CEtCEDvG5AtG3JlxuRSkjDQFVoSQVLkYj5r8OWdCFWUrfWY4ywwzFp8GbN63qkd15Dde6Q 83OA5TlwHuuM63tG63xkroitvUGXeLcCo1I4cmudAPcMZgGlwiZ88KvlrS21JIlKr1cdCPIW rTldPPjCUeV+zC/5awRCOuWyhVRvN6V0TYS4oVBuql3VPakMtvy5cCcGYoEvdEbcLLyiniVE Ue2oymVFmruOBL79kff7kq+BNN3K7bWvB656JTrht64JFRplXiNz4Mpk3CF+O4KEJoiqiplF 7ivkvbUuYW66btlcKk0So1gxRfWKguff9J/51ot0Vh1KY4/6oEh430FCJlCNXEFVVEJR5ZRF VFRCVMLhfhoQikeZKMOQyHE88ZMs9uy9s/HQhcHp85vl/Onv2OL/AJ6EJq5WqkgpxmPf9T/9 aEJm5clcBcevOJ9fJF/y0ITN68a+HsVAl/5aaEJkd+3O2PJJ37FEf/GhCbPbl3aA8hnN/wDS FdCE2Pdq7Wh7zGVX9QOhC6w93LoPJG9HJO3mwn/lNCEYh7m1940Awj58v6PGe2fjoQizN+Tj aRx5WQQs4yKJnHn5rrd3QtfOlkkHHhbRSDc8mYHUBWzHyyOFTKe7KaSGIlrAWaUA71J4xk7H acLzMEVftxrZbrroQloQloQloQoNvYuNrq9+ra+cGswQstXrYca83LTqEyQUZuhT5En1hp9W nUR2K6yTIqioq81cbz+r1BzRPNTzb92qfEn5zDbDNpihNq2Tb9Drx1CMMpyYwqtC9JkkRAPH iiInZMYT4anI6xJgGurUfLhHjrxxglXCfVpGclyfZcl/PhGH90EqNrRCSr/0jrOh7qWNPpLl luVWsOcW4qsw2ykG8vFAFHiwrI9+7iEiJ79cYwnJVzDVcelQ32jjw9PPyqyToy78jeBLjYvo 5RqHY239rVurFNkWtR41IqCgSA0YlIOVM6bipyITFx2J0hQctSDLlhMa7XbaSqwkJDqo9S/R qWlOR3qFuE9CJtyM8o/gNo2zJhmODa8Rkjjxx+quF9p09ZQiDPouwEedOJfTkMZMdmK56tSF acAGo7rQG04MlCbcFx43xJVIRMj8C8s6EK8LKo9RoNFbpM+pU+WjAADfqFK/B7SYFOovT6zv tmpn7XbljQhEJX52hCHO+zoQhsvQhDHPfoQo/VqtDgTIUCQMhXagRi10mlNE4Yyq48va0IUX XcG1X1aAJkpDdjpJEDgvIXTUeWVTj5492hCaz7toMY1afkSG1UUUVOG6gmijy7Lx9ye7QhM2 ropVXpsgKBcQx5LZNoj7kNwxbVSz4hIU7YRe/u0IT167pMfnUGdxKLHhxHcyOpSnF8PIlTA8 V80VEyK99CFJ5tKotTmg5cHTqQ0+mR55qTQiskEJ0SwI9kQiJvP2ap+IZNmZe0T5KEn9pTLb Ckx6DTapSYkcWm4dTNjiHs8hZY54z37lnUjh9sQZsHZgn0mNo2Grfhf7HH/VB/BNT6ervoQl oQloQloQoLvb+S6u/qmvnBoWYLNVys0+TSKe5Oeig+wSuwheIfG+j7CJxQlTOPfjURVtXQfH kUfOzHdBFArWh3VHuR5+vXNHkiuASNGjI02juE7qqpnH7dSk063LDpXSyFSANE/a0Csg5cd6 My6y8LiNGQur+gqIi9/s03lZ+XqA3yrl62flSlhsLjVQ7n7lbo2HuAY0OglULcbh0/m30D4t yyjVFx1DMQUkbJGG1c4qhITIoi+LT8NmxaNt9xsuTyDvbuJJNisBTbdj0Ol3LHosh9pqUS11 koMt4XIpOLxaafcYaBlU5eNwUUiTKaSsIUoYNtCNikO2e/V8XheNOocqz6CtLcqDNOkVWAUr pPE/HmPC/F6goKNtHFRpzmRZNVxxTGspNaLh+Ljn36EI3GARFcfDQhNpX52hCHO+zoQhsvQh DHPfoQhslSQVFCJE9+Cx/DQhD33XFHxPOL8fEvfz+GhCESCXmpl3Xz75XvjH8NCF7AcMvDy7 L2x7tCEaCqUiAcKHUqpBiHMeSPEakvttq++vkDSEqcj8l4jldCF8TYFiXccYpd1R+pMeWite pVkB9Ye5czip3VHHUVMq2niT3p4tRc/h6TqZaV0vj1Js7INuKcWJSqVSKQbdFqhVGNLfOaso pIPq84a4JUMey+z7vLW8hTWaYOiaJKtS7bGwrQhf7HH/AFQfwTUilF30IS0IS0IS0IUG3oHn tjXQ792W/JM+ToLqDxDVCotNdnwG6IZb3OUIfinchL7rmBa8qzU5V2ZENI0ik0+QsY8tOSG0 Imy5eY5TsuUTXHj7K846zfuYY5cF0LslavkvK3XzGSHiRtK455KpqDmCFS5JnkiChZyOFz27 e/VSrOK65XGyKacIQy2IRjAf7c1JS0lIsajQwiXlUjt9psKc5xHA+skqqg9/ZDvj7NdT7Ef+ lkYbWfvVZxA1dMaLyqBXjunuku5YbW7RwaaNThwxmTJc8cBhQ5YDkSCgj27+arrqEwRDqBwL mFXq88NQGl0wYRPL3csFZm2V2Xg3S2Kbu7VKHTrrOQ42xHi1ABV+MvHpE2HNVVVVD9n4a2bj YKlabMPCItVLUd61YI3HRwqTdBmV6GlRl4VmE5MAX385VMNkWSTsq/v0pepE3WWnNEbmtBeU vcrbufXFtqHf1uyKsHnBaqLSv58/JD7+XkirrUJhtYYqMiRDa9CKiFtekxQKzvhXdszmUCFb tIpgus1x2ooqT5akz9GCqqNoiI4fZF5ZH7dItzF7lir7WJGX6kUndCG97lZFy3zZNszY0C5L wotLkTMdBiXUGmTez5YQlymfs04vVhmqjLyxCw6UIGuVQrdGhSY8CdWqbHlTQ6sRl6Y2Bvh5 8gRfaTHvRdF6UOYbYcEHSHfggbN52ZU4lQnQLwocmLTP9tfZqTZBFyuE5rywiKvZFz3XWsTS G7ZW4bnob3Cqk333pqdg2tbl4WA9RaxTKrUjp8qQZddsMAhJxIDRELHPsqaTvUDWq85LNi7K 5RC7LP1KO70b+V/b3c1i1qPTaTJokaNBeqsh5tw3GEfNUXBCaImAwqZTz1jSptWsTOSNQFpg YRE7ejOKNPbkV2Rv3K2phwaa5RmKUk9Zacuvz6XUROXPigryDz92s3qUOsuP1YZARhAIDcUe j9lIY9wUCqyjptKr1NmzAyhx40lt1zKeeEQs9tLXqTanGXe5aSF0V9wK3b8d4mp1cp8dWXgZ dRyWAkBmvhBUUkwRe7trUj1U4jNS7XctIF4Rh9rNVFErN9bzxrptKtvWuxQ7fudmLUH5uYMl ung44vFh9BNG3Vcba5OLwXjlBJFLSDTt5KvYfq5VIps5goALZfq9y+XNgK9HoLdSK+ttYDUu mNW2zUDkmERjohEQKsySgnUmmsXxgCp24fSLx7uiO3aVgKclWta6HSr29F+jXjaNnSLXvS5L XqUSPPSPbL1FmdVp+A3GZAyFFIuKK4Jn0/aQicUva1ja1kE62XdRL1LSsNf5oz+rH+GsraBX LvoWyWhCWhCWhChO8/5Mq7+pD5oaqGPBuw+/9j2xUzh2H/Mm+n2YrHt3tT5FvSotFh+uVNw0 OBD6vS9bfaL1hGOSqiJyBhzKquMIWvPVAho5y67Nn+7/AB4fN4laK4OllyACyJQPb23Y8e8a JV/oZbLkCqTIs1lhuSDzr4Nsy3kkEKmKLKZkCgi4P9OHhNHuSWbEcyJSUwI7Op5YeW3V9XDD +3jgsOy8w1aLu/vxV82546Yfhz9MWU5f3Q9+rt2IdSllf5fesYo1XhtVe7pbRXRPutndXa+v FCumNHETY6nTWagDxy2SpjkqdlAkwWuozA3kuT4hos0U12xpbmTsIZlxcXPBVzfV61bdDaih b0uU9uJdG3tebg1A2GuKEDnBxt4U82/GmFHyQlLHnpKMbW7/ACKInZx6oU9ioulG9lzIumP/ AGqZpT5+83pBbh1213m+tRLQcgUiQ2YiCSn4yNNohqvZeb0hUVPJNZYEpn5pZaaer09Mm0X8 vV57RQf0dT2mtm77esPdbaqp2/fUOcIwKzJfeFt981JGxcaI0QUXPBCAVBfimtGxENRJ4eCR lJxuVnGIi6Ud7l3/AEVJtstmNrqv6X9+WBUrLhvW9QoLcyn0/wAaNRXxWCqEOCRVXLznZe3f SIBa5enMjTJf5RTDRDwD+IKu4dQt+9rk3hql8bY3Ne9frEyRApU6nU/1kKUQq+23yVTTp4UW 0TiirgdOL1ENmMzMPCbJGfF93Ivl+36hc57A2fuNTakwRyJ9GeYktnFkLBScAgKZwYoolxRf PjrXSEsxg4+5ItTQxhmHl9NSy3Nkts6n6Vl0bYyrb4WrTKa1LZpbMx0Q5I3HVEIs8nERXDVM l56xElLydDkyrz8qZasIR/FVxGpAPejTuQ2yPBu3r0hSYraGvgyLjBInJfeihldJ6yjJUBdo 73HAXPu1UdusI1+29vrecbkaRI9EFky7+FgmhPGfqDRaSUlpgavKzc60PBBq3oPf+5CriuGq vP7qXhSnnG3HaLQqUEgc8mwktx+aIqeRKLZp/wC3RrJJ2fe3PMzQeRsc/XCKLbnWHae2G3di 3rZlJGn12PJhOuTGXCR2SrsYnSQu+PNPd56VuUhO01mSk5KaazuPL8qkVB26tW//AEhtw0uq DIcSnSIc6MDTvR4PL0+5YRUXjnRrGKXpFPZqNVeddz1NH9+fuVb1+sTxh35RX3CiUW4NwGI1 YqCCpKy2JyiFF7d8qSkvb+zHSA3CWuoESbEX2LbA0kLo8msrk9JGw0odS29rUSwHrp29tanO QZVJhEaAGCyhKreVbQm1Euoid/eulp+4bdVT+J5AmCZmGm72YQhx8kOJXx6OibT1vbel1jbK 3SiUeNPlOx4k76Z+BNIvpxFwlX9Lsor5Lp2xDuatlIOTmZMSldn45FoeF/sbH6sfPuvkmlFK pxoQloQloQloQoRvOuNsq6v+5b+aGqljk4t0B8x+j7YqXoP+oN9PsxWN78t6Bc1tv02pViVS 2uu26EuNyUm3FJWkQgFU6rZo+YGHvQvPXnTC85uacEWhvz4YR+Nr/JWquSm7JMhuyy41HbTq Q1qpWI9xtnn/ACdmuesQKe62rgKshpuOzlUFhr+bo70VFcqLvsqKcrDXmhalZrh3zhvZ72fL DzuXeTKh7LYeTeVz2146c5gs83y7r3VciGug9ij/AEtzo/FR+KhEpob1D7ytz0gJ1zz5e3e4 lNhUepstMjEl55xFAOJE2StFxVV8WunOtOLmlWlappiCSc1I73xvrnbu3u32z+ztfsDcG9Ke j1ywJMuoOOuo0ryo2gh6u2XiJQJAVMd1Is9tJhC1lwCTUZCVplLelZpzXOES6YZ/qXL0SLOq UfY2v1ij1IqTWLsdfSFOUV5R0aDosuJhF7I4Ti6UlhJpu8U3wlKzUtS3JgC34/ujcTYHey9r 4ta4d8dxqDWadaEgXorcBokefVCElEl6YIPIhDJFnWbE4hQqo5UGZqou7Hx5UZu70e95v9NN c3d2e3IotAK5Y4tT0lNOE+2KgyLnAeBCvJWGyTumNbWJSaoc0NSKflXNrejzb3LyJjX9hN09 ubyuq/Nld26La9IuRz1ypNVjINR3FNSM0IgIERDNVQi445Y1rYk3cP1SUeJ+QfhbH48qfVHY rcK67h2lvOs39Br0mygV+p1HpOn+FMykeEmCEVDHBOKZLGixKu0Bx95h10syCHD6/en9q7bm m/Ff34p10UmqUOtwXaYyzBcV5wHmOm26imKK2vEo5oqCWUXsvlosT9ikaKpPTt23BQ23PR9n 0Sw9xdrZ9yUmZVbxdSqRgbaezEZVxUB5wCFFVOXZFHz0WKNk8PaKTelfP/Zd7B9H2r2htjd2 3lcqUWoS7tJ/+dMxnRbwrKAOUIeS8STPhRdFiWpeHBk6a9IeMSjtg7BRYO21y23cF0Q621dp RzbnQBLgAMBhkh5e0qEnu807aLE2kMLCxIusOl84hjWx97VI7dom4m4kWp21a8hHosWLDJqQ 6iJgRcIkRERE8Pv8OixDWGZhxxpp1/Ub/b6XIpxZViSqBuTdl+SKpDdZufpdKM004hsqCoq8 lVMLnGlAaU3TaN2vqD01pL4Rs/xQeJ6OUifam49uza5DecvSotVSE4LB8ae8064Yqefa/pFF ePu03NpQvyWIG5kS/mxzh/l+pSSRtRv87att0S198ItKlUekrR56pDcNqcCOZB1VIFXmLeG/ Lv55TSjsrMF805n8c6eTtEqD7IsNP8Xx4ytDYTayLszt+zZgVhypmD706VNMEbA3neKKgCq5 QUQE8++gibkW7ppyAdMFJUalFTZfRXRM/jnV5QSQoTBCqKitCqKnl5JrYHBdGBhHOEVJp1pV CWhCWhCWhChO835Mq9+pD5oaqOPPB+Y+x7YqSovfwdPVFYz3GapD9h1+PXpkqJBOG71X4jfU kN4MVEmg/OPlwwnx151wxpO2Qmw3C/6R2jwRV1reh3D/ABGdn0Ye5CrIfptxrS7it6mvQ6bT vw3Sz9bEmZCdWa48LANdFEUcq2an1OxN9Pgup7FTrkppJecchEzgBxsyiPB50I8PJb0qPw6U u+yLrAxshva2cI73OretzxQHeQ4+ncyidseENdG7EZNu08rfjhURigxJ4VIYC8FQk4/ZxTH7 tdbIyJV2wvOTG69rdv8AcdYTl7W23U3aflIzvVNswEschyBJlFwnnpApcXdtMZ+ky9Tt3Vv5 eTeU8olNptIgRqZR6ezCgw20ZjRWR4tstp5IKaUECEbAT1qXFhsWhHVgpBDHxpjw+72U/wDG tLvoxS0Su20aZbbITQ2xLn3XIouth1uRJaPVtUF3qsafuRtpXLGpUyLElVVIaNvygFxoEals vFyEhIS8LZ4EhVFXsvbSZ6njLcRtG1UxUvRduSmvx2LJv5yFAgVVomPWqrOaciwm2Ywg4DbA i11m3QmEjKCLK+t+Je2siJI0RecojR/RR3QtmlrR7f3GhsR44QvUIzNVnR4LJNSG3TbeYFgu u1yFxzHMFMnnEXj7et7VgmLB1iTt/wBHjdT8FuQx3GhvsBIk9KO7VaiXMHXpLjLrr4gBuPsq +24KoIiRMgJIQjz1kRHzvuzWB0YlfclI2Bv6DUIsmnbmMgK1yNWqq7KlTuq/0J8ySDjaJyRo kYkR2VEeIfRYzjzzovNz9STdJsnNrfVjWhQDtOz6VbMh5t1ymRuiTjWRE8m4SYRcdk5Y7ppI hLl/sSgMauoS7PJ3XgP14HKaQfmpeW76eg36UYQ61s3LPENgN8K9idTKGQ4T3p7l1Az+OcN0 oe6zrZ5+aQxy6IRT5qkzz42C3qwRhmosxwT6Pkvw1z2pdm6gyZWyoxd/x+/KKmmcLzj+2WS7 pc8wMJGZbbFPj4sfv1Q6r2dKw6NtLag3zwu/LBSkvhNsXL3UPk1GdMLMmY84KeSE4uPsx5a5 bUcV1qrldOTJ7/FCMYfdmrM1T5VrZbhnzQWgbV/Fmj/cI/y017TwhGJYdkCL+i17ArlNShbO vekXWi+rEmSWhCWhCWhChG835Mq7+pb+aGqjjyNuH3/se2KlqBb2wbu5fZisb7gS5ECyqzKh 9FJTTPOMTo8gbeR4EA1RFTPFV5J/eQdec6E0L9WFgx4vLbxErVXn3mKTpWi4OLK7yLrZtReq 9pUqpSakzUXZASDOYw10m5SrJdRXxBfZ6uOquO3JxdZxBKixPOMBs5Q2o5x5dryLOHJjdlPF 0srua1WBa7JLS3CEv/zC+WGntH7Iz2DJMWgZzz6M+m2PlWs/Rhni1UeZd6I8vf8ADVjY/wDU EP8ANkP/ALY/oTD5Guf1E+Zq/Rxlkj+wkHH79SH/AB8kS2paIcx3flgtCwe8Ow4ica5YYdnW ZSL9RJjT5js9UnxmTWPkfMf1ETj3zSG/EUOYqp7umP8A505/454d81z1LX5KTn9SCet7j0gQ 8FNmEvwURT/PST/Z2oLQ9ybOJcsFn5JTnjuQTdzcSCaLwpcpP/kKf5rqPPs8U0v9vH46Fn5I zH9RMHr2aMshS3vq+lRF1qfZ9lxG0JLP/qW/42JUcIlbruJk9dLji4Cmtpn3k6qp+7Gol3s/ kWxIZf8AU/7Es1hIRLWLVTQq7MLwmyy3z8sZ79vr+pNR0x2c6xbfLswD1foTn5MSqZHPmGfh cEPFlET498r9uoKZ7NuLX9lwQH0A67U5ZwvTw2hXAyfJcn7/APH3rqtTmPMTT12lmThn5ucP ZyUg3Rqe1sivEIV8XbunZfq1VnqtUH9WYmXI85kX4p01JMteLBeLjywqZ8kT/wDvr00uEtrW Ll3v/KdgIjsr32fLsv1/u0mette5Z3l8iTR9x4r9fn56zHSD4y1ycX2qY9oca1CHjraC0Pan 4s0f7hH+WOvfGD/B2Q+pa9gVx6qd/PekXWi+rGmKWhCWhCWhChG8/wCTKufqW/mhqm49j/7d md/LZ9sVLUL/AFBvp6orH93TIEa1au9UbiKhRwYNXakkZX1iDy7uo2iLyx5fYuvOFBa/5sye hjH6OcfJHj4Vb6seikXg0kA6Ifim23sn1yxKJI/CzlUHoOttzXGukshoJDoNnwwnHIinh92n WJmtFViG2zejvb8etN8NHpaeJ6SB8sModSsq1P6pe++F8oNUbEnesv0/lVhktokY1UlJJaEJ aEL7ECymlUkunH69FmlWkStXUGfzSHTtqXWl66eq/wB3TnchLSMxkugU4VNAdEVBVwSLnui9 vdrYZC4rSSbkwVurwqm5N6byFUG6PG21nOtNSXnH6i5BlMifCr9FttEFkhcbKIoGSj4lDmoq qiur8xhmgk2JvzEIb0NXP6G/40PG4OXhVfKpTQ3AAofTNwd9nEaCRtPKU5zzbrau0yUDUFha c06YGqFkuEkuGVJV9tFxx04msJ4ZK2ybhAYQ8vCV3P5vxvpBqsT1uu3x/HEhkXdveGqyqxR6 bt3DWp0N1pibCGlTTUHDgOvA4KkYtkBOADaChc0JxEx35a1jhOgsMtzDszqHs68NbXgPUlO2 88Xi6yLt1vf+Q5IpQ230FcSTyqMmnssqwqvuKyLPCUoOKLGBU8Y5d15cdN3KfhIXr3Hcow4r +Tm4yW+6KkfipzZlU39k23LlbgWfDiVOG7R1jsQnI5Py0GSz+EEQlfJteTCO4VSbXl5e0mmU /L4XGebCSehEI6S6PFsx0fLwpZqYqRCWqgtJmekrSgej/wAl49RZ/nCtuyJcU3hdMXBbRVKU XgAlawg4w2BmXic4C+mJXCb7Ym49AI/R6OTh4ftb3AN0WxFVmiuEV9P1z0lma/HoiUmkmjrD kn1hqkAccgV5hVaJ7rKAmDayFDxeNRDPHl4dRksHnK6W6MOLb3+CP3Z5ejyrLUxUCLWVgbfh uIMGpruKFNGR66pQfUWwAUjkOeCoJFniqY5qvJffqm1uNH0jY0vPg1t/P45lPyOm0ndVrK1P xZo/3CP8sde1sH+Dsh9S17ArmVU7+e9IutF9WNMUtCEtCEtCFCN5/wAmNd/Ut/NDVQx1Aiw/ MwH6PtipWh29sG7uXqisfXNMk0+3qrNhzqXDfYYNxuRVO8NtUJO7ye8cL5e9ca810GXF2cbB 0YxHPxc7lc6u/bJvaItb6UIZetCNr7hgV6z2XodSbqBRJD8eRJjxjZjuPKZvF0BNELppzwiq mpTF0ruSqWfR8ufFx58flTDCsxumniX4ZdXEratX+qnfvhfLDXPsQ60mx0/lVlkvnCRfVSUk vB1kRWpRtXQWkJM8tZtWL11ZAz78fLTgWkmZWp41GVe/H9mn0rKkRJqZ3IhHieXh1OsU65NT dT9qBy/N1Jt00iTMnV0GC2ZcHGxUF7Ei9uy+flpx2oSZvkI6nCqXqE/0knJUlilWXDcjnJqH QkyKewyTLLTihG6grM+kUw4OIoJj81URR1cToVCBkSf2tXjj8fHGohudmhJD7rZ9IKl7ly4t ux3Jlv1asw4NNclMQ5EZqIkEnHXgETA2vpANHCcUlXkAtgflrI0vDL8mOlHIoQjnrlw573H5 P/0kjfnLtVDGoHpQepQGXihtIwDSTknPxHnZTixFF0kIZCowiuNtinREU+lIsZTUTPS+D7uW GzlGOW1vc/2ko3u65Ngh+kixQDjx3Ka1UIDaiwyrsMkfRBgiGXnFcJV4+umpEuVJvuq5HUQ/ 8lovEbpa0Y8v0uLMfo8ClW4VC7a+PUvq3138g33RaddUh6ZQJz8l6XJgw4TjDIg1hth1wW0V sFXBCqYLlz747aQmxwy5JPHKiN4Q4yK6MS4x1v26VtdONvNiRcKthQVRVfIkTGPhhdcxiQ6T kVnbMtkl98yxheWFXOOS63iZLbRCvMe/34RFX441hvaWRG1aItT8WaP9wj/LHXvjB/g7IfUt ewK4/VO/nvSLrRfVjTFLQhLQhLQhQjef8mFe/Uh80NVDHd3yfmLfoe2KlqFb2wbu5eqKxlfr 9Hh2fW5VfjyJFPajKchuM70XlHqCicHMoja8lBeS+WvOWGN1dsm9E5oy86PH90VcK9ucqa9f rj5nHw/HHxJttk7VitkzrlS9fRZRrEL8IMznm46CPEHnmkQSNMrn87UljQYDVtm3ej0/S5iU bg63tWNpZ/hyfZVrWn/Uzn3tflBrnFf7zZ6fyq1yO0SM6qakV9NChZzrYVoa7NNkq/VrdJkS fxo5KmNT8nL3JobifSHqfR4oSqjKbjgZo0JuFxRTXyFFXtlcYTVrk6YKYRib5WNKB1Df63IT qMwKZImLw5oajwFUVlST7FRzAKnw76sMtICnjdEm3UYpW+NuOP8Aq1SgvRUwqq5xyiYAVTin mqkamKJ7kHUgDDYlYkJrDs8wNytSnHCng3PhyGX45OKgG0aEK4JEVUVMouFTT9pgblVHidhq Kgo9j+lFTq5VVpt3R0p9SmILTc2YxKGPHSWbgq31BJRUmi6aiiKnFBwiLhUtDo0XQiMwOt8c qjYuPXJUu0vSNq1pVmFuHKgzZEoKFIZjR6i3TDkI1I51GKj8MFJoTbEBR3lklXGBTTWEvRWb XdDn8c6UIpoy1ELkWB6UbINy5O5UEChc3FixjZNJCI24XFf5inLkfTUBQg4gvAlIslqtzDmH 2tQ5fr/UnrUZxDqdYvpBTaPTgr24DMWQ3HYnICzC6zEtSZVGXlajgLggguEWEQTJeHDiKOar k3PYZlJhyxjMuD4zOO/1eVPmpecLxk8suyd06FVKdPu6/wByrx2mHmZkV2YRtqqx2BbUU6QI pC6MheRJjgXfxeVbrlYosxKkzLy9peX1/SLkUpKSr0HhN0lYK48SAOPqTXP4wLVLggrBqiQ3 Ja1SyXw1uCytD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQloQoLvXhNr6 8pDn6Fvt5/2oaqGPIXYffhdlse2KlKN38HT1RWQrumSIe31dmR6g3CN11hlZDgiTUcCXiTpt nkVQEJS8XbXCaC1onC1eHxFaK73uSHbd02DR7WjjS/UVF9ySbr8FpG2JZtyHGUfEU8KdQWkP AeH4aZ4jd0tQH0fVvcC3w73iKtG1P6mcUeyeuL8oNUfEnerHT+VWCR+cJGdVNSKQj3TSZbSI xROIzzT69SktKkSYunkjMNtuKCyJTgtMtipOOEWBAU7qqr7kRNXSnUvWUQ85kNqzhdm4bVdC ddlVkOMUwA+gYXGUjguQEu+HCU8kip7i1c2KeQ2q50qWGVlb/GUVi1V+txpLoslTj9UecY4m ou9RQLCrjvlMafNyosPDalTfF9kiVf7R3fK/0ZUaoVecU9o8AsmQ4rhtovAVXK91QSXui/m6 mcQ0vTzBEHlTSmTtza0x6N19uRbuOzHp3OJVOQMsERmrEhsFJABF7Ngooar9fbTaVaK0WlE4 vkR0YzQcS06bIEiKPkvdNPNzrn65OxkIe3fTd+XSzR2ofJY93v8ALUFMS+0nrZqO1JpsEUnC wg5TK9k7fXqn1GTK1Ssu5dsqOvCyKmTTgmnbOCz2Xunl9uqdNNON3KUbiRENyYHyE11XSEjJ SFokKWsLZL4a3BZWh7U/Fmj/AHCP8sde98H+Dsh9S17ArjlU7+e9IutF9WNMUtCEtCEtCFBt 6E5bYV5M+bLfzQ1TcfiR4dmRDh1PbFSlGIRnm7uXqismVmNJmWVWIDNShwEmGLJyZbCOsNio Eiq4BYFR9yoXx7a4VSJoZNsTdzj7XuVwqMuU8JNNIZZ4T2bZpsOpDHKVHQ4rixWAZYTg64IK DYrgQUBBU+3UZWX2357StbOUepZozBS0rojVkWn4qI59+X5YaqGJu85fp/KpmS+cJGQHK99V ASuUhenDLXIvEOdOWJcnXEiZI1TmQ9r9ip/j/nq2yDVhWmox8013LeKmbaXMkci6xUqWjZI0 jq8kaLtwJURc/BVTOrZLujLTTbR+PFMGs35gSWOqXTG7gtuj8CFuI2LHNoeCpgOORwJkHZfc K4Re2e2ri5NbkeJg9ryrpsZcn5UbN5aRtv0Xm5tO9duOvvMSpQK4jEPhkAIVTBGQqirhe/H9 +njFLcBvSmWZLm83iFsSKXaHVVIbjejA9tPAi2vYj3K2pEhQCK86pmx1FRTNCxkkVU7iv7NN pmvORnCGdGPpb2Sl6PNNzLYtNDFE9tqF+DN5LEZVvg/NrnNOo26QCIR3TMOYHxAlETVOYqi4 XHfT+iPNz/dWh1Uvip3+BIfG/dbjkzoUTtMfaYRMd3FQfcvki9/dqZOLLfzpZLmoNuFsb64t VGmSlzCnR3vgjZZXsuPLTB12Xd2ChFbkDobYxQO+LigWfa9UumoNuKxToxPEAipEa54imByv clT7E76j5iVtG5OJKG6XhYDyrPQV+tV9tytXHVCRx8OsodXhHYFFMkBE7IiAhKKmvmnnqjzU 43NPbnaGMSXU5WRlac3vIfEr0cx9atutR3m1JR9ZiyReBcYRcKiqnZEQfs1FzVO3KJaceHgT xpiXmhK1Tq264lfpqzHY4svNGrcgfZBHExlA5d1Rc9u2qNWZDcbl4cagnwKWc0SJagEol8Nb gsrQ9qfizR/uEf5Y6974P8HZD6lr2BXHKp3896RdaL6saYpaEJaEJaEKEbzJjbKupj+xb+aG qfj6F2HZn7HtipWhFbUG+Lh4OaKyFdcJarYFapQwYMspptRkYnEqMGpJhFPCp2FfH5/m4/O1 wrD0wMsQiDhAXJ/4Vrq7JTjZaUbx5ULsG2IFrWwxTocGDGcdNXJawiImX3RJRR4VIl7GggWP cq41H4gqTlVqW6HSicYQiOZcO8sYdpzdMk9A0OQ53etWjaSf6lcT/jl7/wDLDVJxN3mx0/lU 9J7RI8IIK6p7KfJ3EHBpgc57ftXy1JSokbw2Js+Wqq23N3aSiJMi0yRmLCyDzzHjV/kBCbPB cYJCTsXJE+vXTqJSiccTuTpmUvuiYVLULeJdwgmW3BrL3rbkVxw21lJKb4K2rKo4rOUFUFcc dW+bopUxxuYd4oqYlYyEyPchyJV3tjuWtozf9G94C807HkjCjJIBGxDLhCHBrCAzGBtlXCI1 IyVzOrDWqQVREZpjay+OlN2KtuN4hfLMMlp6wd0a/HixIVq3uRU55tp2NHIgdTpPArjXHqpy HkKKSIv5vfVScmqvJloRFMpql0qeLSkKIXtvTadEpP4Wui6WZkhwY4Nr1UMWykA4Ucj4d0aM m1RXBFUTTIaNVq48UXd4c1FxJmmFlLqj9h5l3bwbvR9/GKb+B6XR2HGqOjzAK+56xFRCZ6iI iPIyb0jgXdU7ovHtq5z7o4Xke1slvlxx6cvvygmt3bNz+I2VpSsHKGlTqyEaVV58aO9JBjqq hynQAiFsVLKIRe7trm+lcqsxbMOZKUyGRHuQqH7cXRV78tGLdVyWNVLHqivG0NPkyS58RVCR xFQQXiSqqJyFPZXUjVpNuhvWSjl4olZjdjdrooduPvVSbusu5ttKPXm67X7ZlQJk+E0zIOQ2 01JaIx4tqCuqiY7Cae5Fz3zY6eM1ucXZ0dVyGQ9O9ypoxS2Wp68FFb4p7t/2RV7Up1acjLWY vFiWOSQM+JFVRzlFVMLjy8tVymPN0Wq3uirdP07dMrcBIR6O2w1y7W29XH7grUVxaxJZcbiR eRtR0aExN3xCniPknYf0dSeLa5L1wmRYHKzP78vcq/R2nKe4QFxq49vXWfw1dEOMQn6qsSPI IemuH0bJVElT6TKDjHNMKnl21zvF8tFppk1vNOaWYUyT6vLXPErzr34a3BC0Pan4s0f7hH+W Ove+D/B2Q+pa9gVxyqd/PekXWi+rGmKWhCWhCWhCg+9Wf9FtwcfPoDj7eoGqljnwfmPse2Kk 6N38309UVj272ZNSsms0inTmafJd4SWZjwZZjqHi5OL7hHjy/ZrgNAqrMi8JaPMldKlJOTzN t2S8tOjx7etyHQo0ht1mAr7TZNllBH1hwkH7RReK/Wmo+szvbCe09uW9HqWtGku18voLs99W JZ/iojv34vlhqpYl71Y54/lUzJbRI6OqflaSfRT5gkaaJ5UFFBUwqiuM596+7U/IiLVrvLBM XCvK1ZXcaod2yqrZ1zyikvNyZITWkdFh99rqcTIeOeKKpcORd189djaGYkWW51gdVW5wxdld Emrtv7W7UtuVu2aE/TWmoxNo07KB96QQ/SKAkqihLhMomnBzdQxC9Y7nbypKVkwpzXdMiJZp v23LjPcP+VrNF/1XXFQm5DMbgy+4hLzIgUiVF4qir7tdFpc02MroNJrwVPnWCKY0tuqmloXV Jpv4HZYnSG3HJlB9h0kVFKG40Oe/mnBU+pNPylhccu50pp7W00Ma1fECjwrepcyozPwXBaaA WjcMBN14RREX80V/Ymkm225InHTLj9ybu2kIrYlpbB2mdA22njOlR3LOZalB6k4PSlPEAEZO Eil3VQxyEsqKYyqdk5fUsSvOTU0wA5i553OpdiSbtHVUr3K3AqlJq8Chx6lKo1LWHJq1Zq8Z gHX2Iba8elGQ0UeqarlTUVVE8tR1GpUlPS+6jbgbufBHg+OlLPMRJvuW8obae8EG5apSJdpX RcFetm4Jq0hwK+0Pr9LqPS5gQuCidRoxROx8sKXZfzRk6pRCbZMH2wB0IXQs4MuLztZIyMuW jv8AFzU3WiUWLUZ1VjUOG1PqTKxpkkWkR19tfzTLsq+X26rrdSemWWbnI2wjD8FIiwzrFbC5 Udat7VWwqy5alVpYuUduYLcEG/CkVg5KMstimMCIMNumqJlVNe66u9QpTNWAXhLXy4Vlifca bt8VTJ/0kZUqlIzbNDdYmONphxz6RGiMJeCTKIiqBx21US7ELhe9E1GsYUbYtdeLPh+5Mjmd 0+LwK7NqqDKoNkxjqpEs2pPOTH0MzcVvmq8G+TmT4gnhRC8k7a5XjKoNzU9ohHVD9k0AiIlK k89UItpPeJe/DWQQtD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQloQoPv V+S6v/qW/mhqpY5y7QP3fQ9sVK0L/UG+nqise1zpFQayDsMpgHAmI5FRxR9Yb6ZKTSKKKSKW MeFM45Y15qke5zTdnnroRgJNleSHWCbZ2PRTbneuj0Xk9a9aOSL+JTydQXTETIDxyFSTlxVO 6+avsQjbUyExy3vy8ibyA2N+VWpZv9Ruffl+WGqViXvVjp/Kn0ntEj4LwLvqo7TmonxbKJgy ZxnE49lBURfrVNTbbTgio4jHSCsub4bN1w7oW8LTbJHnHglPNCXFeq3yIVFU7KRESefljXVc KYvl2pfcc/vD0x96nZOZG7X2VXVh7Dbn3nNhQq0LzTbSRWjN5xTTmwBtqq5XyIHD8XtfHVym sRyIiW5eqKbOzNuu6S1s5slDi29Ct6My2/FjMBG4uii5ABQUyv1omuXzE5UN0E6OcEzGsNlq EOqo4Hoi2nXZhPT6XFZVVz1GxTOeyISfWg9k1ZKdUqw+NhbPP+6bzlWl7dQVbVt7Obe7T2xU ZlqW3FjzfVTbWUA5eNFTCoheafXhU1aJgik6bpXSzJVgppyceEB9SoCnVS4ntp341n9Ny5ab DdgRwlAqgktpSAVPkXllPPKjlO5LhdVKaKXamWXZ0cmT4Ve7XtDaI66D2ZYW6d0Wjb1evGsU mnX7R3JHPnER2DLjOkiIzLZaJE5KI9ybLsvx1IzVVpUtMaKSbzl4w4eDf9X4JMhmGm9baU2g 7b3BKqbVy3I5a8eTSoziUul0aG41AblL7L7xGvMsKiJ4UHty811HTFYZEhalxjlGOtnHxUi2 6803ogUV28Ld2mWZU6rvW3S1qcSQ86ysBpvPqgCipyRvIrkvYXuWOy99OKh2sfmm2KVvjx8W t0wgn0m4TTZFMKB1Kv2HS6HQ6hfleotIWpOq5TnXeYLIAlFxHVbRsSaUeeC5CmPfjUzLy08b pMyYxPR7XJ8ZJXdjbbInMbwx4FZW3W0tsuVkHg9V6LSNPMNAQkL7aIrgk2qKquCnPPJO3i1X 6pW5wZewOLPNNZlxtobx41dkpAFFBoRQUTCInl21yepXGV475RTZhMtV9PEvhrcFlaHtT8Wa P9wj/LHXvfB/g7IfUtewK45VO/nvSLrRfVjTFLQhLQhLQhQfev8AJdX/ANS380NVHHXg/MfY 9sVJ0Xv4Onqish1FZAUmqvRphQ3GocpwJAcuTZI2aoScfFlF7+HxfDvrzRLfON+n7l0JzZJC LBkDKsahPipCJxS4NrJkvkwCPOILCuShB9VbFEaXqihIrePLC6kcSDZVXA5/JDi+jq+pIyHz atGzD/1K4P8AxpfLDVIxN3rL9P5U+k9olIw9tPh79VOX+cTzxVJacgOiAcey+/V0k7SGwlBT BEJJ2VBhzDUjHt8Ps1PS9IbLXSG7XGkRp9FgU8foI7YquMqn+OrI1JMtbCZPTbjvjIgLYlhE EdSkuw2RawpteSeNMoKZx31LNaNrYFIma51iJ69RpMPjnqtk3j7ffoqTRTMiQBxpNg9E8JLE 90SKxtNd8y4GIoyaZMIRq0TjguQIg+sDxRV5CHuwuUaQRRFJVWoUsBrEpuCY3jDZXS2nb2xd BWhYl/WNdcZuTR7ihuF3V1p0xB1lERSJCRV7ceJiq5xls/0VXTSaolQlnhCYHuXxyprNPuKJ be37uXAfut3fmLbdvUuNUEaoL7ElkEfaVwxLPEyUsIid1RFzyzx4rqWqtJlHGW2qQMYnx73N yCmDUwQEqH9I30lGLipsil2GMhLepDzL9WqLLpRZEsBMVIIppgmiROf0g90JFTiWUXVrwxhg ZS053LS+L6XLwpKcmnsk1v7buzvSQtq37hpF/U23rppsJmjVCM665PYy6ysoWBfIQV6UDaKr nf4ovs6dydSnMKvONEzFwDzjn/jHzskibBVBtu4srFbfo6R4TO4FPt63apHqNNta1AjnNkRy J6VHkI2rDjT2eDjZqK54plFDGq5iFuISTj8wNhORjHL1+9SU24JNtgPEtGTCVTVT9r364RUH Ru1UsxsofqCiniXw1sCytD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQlo QoPvUv8A6XV/9S380NVLHXg/MfY9sVKUSF083Dn6orINTpsGs0ufRqnHF+HUGXYshsvI2zRR JP2ouvMgvOSrwmzvFCN0OddDIbuldmGW40dqIw3wZjtAy0HJV4NgKCI5JVXsiJ5romnymXtK W1HNDDYtagKaWZ4aK8X/ABxfLDVexN3rLdP5UtJ7RL2ryr3bnSkoUWnmwvRSOcviKDlslcxl xFUuSImDFE+Go6SGkg2JP3XZ8Wfl5k1mjnf5HAiVtpuq3XI7lYlUP8Eiw0kltpxEeVzi31SF FRUQUVHFQcqviT4as0o5Tibuazjv8u8o583sxuH7lZbM1ptcPyo7RphFBx0RLKrxRO+PfqwS pOO6vB0JAwiY3gMfVFPwmsEfQNxtHC9gFLCqnxTPnqXAXGvnRyTWDLg6xJ037f16k2HR8RJx uu5E6B4+XHUm0+k4gKeR/H7WpNo7tpNXYWqqN0tqWbgBybCjirph4/76659VKa5T5gp2Xz5V bqLWWwHRPrIN+7CT2ZjhNUFyQ84KiIgKi44XEhQUVMZyKmP/AMsfnanKXicdHbNKxOuyr46q MWr6INDq8OPK3CrFQlJz6gQ0fJMtGpEqOK4nMSUnXeQ/pES58WsT+MHWyHcMBh9lRIy4kV6l N2ei5t1JtefSqBSWYjj8YG0GUSvNuI34kQvf4i8RKndV1GS2L6hCeHSlDKMfInEWhNYqtrb/ AHdoN0swZUGsUyXHrEqqmgkQMtvOsEIPJ3wKLywvbPHtrrp1eQcl4WZR3kx3A9pFsf0NLCLb a15NMfeJydOYjDNVHBNtkmQVOAEnfjyJS+1dcex5WCnntEBam+nJSYywitAyV55X4645OAIk nLKY6hk7S+GtwWVoe1PxZo/3CP8ALHXvfB/g7IfUtewK45VO/nvSLrRfVjTFLQhLQhLQhQbe r8l1f/Ut/NDVSx14Pv8A2PbFStD7/b6eqKyYnmf/ALl/iuvMJjc5qLoa8Xz1gh1uiPUtm9pT KzFxRnF+E9flhqCxNdueW6fypWT2iQm4jtVu6XlnbkSaNOZgAj8BJytoTGci5xXyVcL3Huv2 6c0mFQ3GJBJaQc9rLe9lKxrMnIdyft6U3p0na+XEdjnuVUp7LsJ5ooKTHcjGNxkTJG1FcKCm 2PdPLP8Ae1YGGq4wN25INjnv7PR4qjX8TS467Qh5eBeHXfR9gPpHqFTrBkKo4pOk6StKkZxx SJVwSYbVT7p7fBf0dWqVkq1o9RtuH9qiXcbOmWz/AIKytpVsCp09yvWAzOKIZlE68sTRTICV TEEJcpgl7rjumPdreoboa2skkdXcqfzvuVismRePl2Xsi/HSbTg2/SSZWp0yWf4/s0/aNIkn jZ+HIl5/DUmw7empjcvoTH85OWpAYsujY6OYpMQt8ZQDdsGPUaRTRg9VKrUhZeUYwOijQATh IaEqKgkoomR76r2IJOVYZ0rQ5KXpJuE9x5QVQ7vluJJt2LQNsykR6vWXyaKYw3zcYYEFIiHk mEVfLlqt4dGX3QTr45h/5VqMgHbLVVbbTRt+LBv2PaO586oVek11t9WXJfJ52K82HMVQ1yvE sYXC4+zU5XAp85I6WVb0Zw8u97lkHWz1wJTe6rPptcvSCDLkcJU+M8XHkKGaNKKqaCg8lXBI ikq4RB/var0hMPbncPyKS3QLQ66nlq2xFtiGjLI98eNOOqdOzROlcai3JkpkuZEHz+H7tVOc PWTlsU31HJwl8NbgsrQ9qfizR/uEf5Y6974P8HZD6lr2BXHKp3896RdaL6saYpaEJaEJaEKD 71fkur/6lv5oaqGPPB+Y+x7YqTovfwdPVFZRiRHZan0hLCEqqqe5Mr3XXm6XYcdIrF0SJ6Jt fEpgozitn9Xf7e+tItEwQgf0lpLHpRIlLbN/qR776Xyw1W8U/MsdP5U7kdokPrztHaug25+2 j1VP1Fomqo3BF5XCUv6BSLy4+ffUlRaWL9K0vbTRb/zV337Y+yo+alWXX7nWoEutvqT81uG3 s7Dp8eQxJSVJkNRhBUyCk1xEMuI5598D4e+pSYpsnKS5G7WjcLMMhGN2e9yO+LwJKMrLl/Kh BHaVcG4TMNtQ2xo6yUaXkTM5phlXkbQsY4KqIuVHuS9tSrDNNG0+2Lvqjq/5pmcnL+ajEKq7 0zVEX7bt2lgaTEIknesG250XFi/DKK6rSqvHyz2TU8y/htr+Y456/wBUU0cgHiLoxH35dFtT kWWgo0nWJGn+RmqoSKKeSCiIo4Xz1Iy07hfSDpdJl9r3rBxZa8ZErErF2x4/X3JuO3WpCstF 6jDeDMdw0z4yTArlc4wmF04qxUu4RkBjb0qPdmJeHAam0apw5JN9Gcy4bo5FEcFVVE81wi+S aaCWi1fItwMTHVT4TEV5ac6W0VgmrlS/pQSXKTQaBdrcVt4bfqqTC/mvrLohwUS6LSqgq4vs opLhM50xn3hmS3IezFTdBhrEPIu9v1tqdGj1qlyG8ImBJoxc4EiYcbJRyikPsrhfNNUsjepj 1obMFPPMC6NhrvW5sysk3JmCyqx+SNIgcUDkKcu/2axMVGYntRayMq3Kkq7sK5xufdiqxofU 9RtqmnFdJt3LRznHeLrRgQIQutoHmhYUXBXUlNs9rKUJltn8fj9yVnC0paqs6U8HNS9nsnlr mk66tWgtQ0zElymq9MOp8C56bJRL4a3BZWh7U/Fmj/cI/wAsde98H+Dsh9S17ArjlU7+e9Iu tF9WNMUtCEtCEtCFBd6/yW17JYTot9/+aGqdj6BFh6Ys+h7YqWoX+oN9PVFYivy57lp7zdOs lxtyfSIZ12pMtyQQ1badEejwL2lUVUuOuOYdlxtuIVfnWtK2rLu1qIDLM3ky162iONN9QRzl OS4RV92dGKacLBDNB5I6qYU4yEilzFELN8VEfx3/AJ4WP+mGuT4oO6Xl+n8qnJUdE4S+KnFv SZW3lolwQYsDoCpxnmhMwL85zui47eWceWmNNCn7iymmDM89obvVlBQdQZmt0XMTEAHoTJ2J ckWlzJNY3IpjEEITpFIVltsUHI8HnHEUVwKIqLxL+0z59tTRMSjetKyDmdw+f1b6ausvOf7m G9zL4U26OjtxVrfIWmH22nE6XDCsgrxo22COkpIQn34ipL08IvlicZdmJ3+HCnRhlx636VHP y5f/ACer3ro5UdrRGFSqhvR/rSjNSW1OPW2zmmT3SJVcbFSNCFuPw4qme5e/U5LhVBu/hNHz h7xTM9zjsv59H7qXUKwrPrlOGtw7kuaowJxo9HJ6c822rahxy2hAK8SEl+3SXbSaacsdbD1Q /Sl2JQZnaLNG12osaS+sqTClOEbLTBD62aCoNsiyGUHHkAAmn/bx50dmHx0IdpTKOUGy7Utl z1mh0luO+oK2r3IjNRVEQkySr540q3OkWuS3CT0Q2ipB1cr7WnW6NKNic2ITd9Ej3FQZNLle MHQzhcIiqnkiqqL2X36QnhvZ1dpb092MrMXrINTtLdjZip9OyZBSqMy4yqU5z+hGO24bjjAY yoo649kz7quMaJerU+oN6KpN2nDezz+/xVbzFqaje0SDJWPSL3CaaoNYei02G+DDMtthjCSE Vt5mS2vwB0XENP0SbHTmMzh+lazGuXLH1JXcmrfcr42p29ibc2uEBsepLdBsZMhzu85wFBHq F+cWE89UKvVsp8iO3LkTTaJSV53uo+edUGYfv1E8ELoJsWo0wuSojavdaLZL4a3BZWh7U/Fm j/cI/wAsde98H+Dsh9S17ArjlU7+e9IutF9WNMUtCEtCEtCFBd7EFdra+hJlOi12/wCaGqjj zwfmPse2KkqOejngLn6orAV9bIX/AHNcNRuq3bop9DjFy6zzYEjz0ByOnrKGqeaioILfxyuu b0WZaakd8Vet261iY1Gu1R6bTIs5yrQ4/rqLHjttIbikvEWyPii8WDx7vJR8++mc3bOC4HDk EepSjUuPzq0XZ3ipEjwj4p7nb3f0Ya4zicLJNjnj+VEuVzhKK3dbG1FSvB+oXRImN1lyA0y6 LT7wtvx0LIjgBVHO/wAe/u+rUxh16uDS8pIIGOfk/wC2Krs81Td1d1KMC5/3Q2i2vsZRzkza TSJhyggyUNSOUhNsK40RoBEqC2qKLapxVFTj2xjTubfxW4Vjrgw1h4h/Qk4jS+X1/uncahbM z33uG1YzZquk0YuRs+NTNxVQyNUwSkZck/S763OfxRLFacyMODiH9CbHGnjsMxj8c6sSkWHt /TYTkOnWDb9Pbl59YZj09oOSqKiqEojlcoqp56gxxLPEX8Q85HogpZqlSe2AqaxnW2mgBsBA AFGwABQRAU8hRE8kT3JrYJgXSvAo3LbQC3G0RRAJHh7afhMJIwXcJPhTxakmpgklYu3XHT4Z grVpYksxOKiXH7FwutTqVo2kkYy5EVwoVPCHL7vstmvbzH4Ln+OoiYJt0rxT1jTNChBx6dGV SjsMtqvngfrz/HUJMPCKkgi8W2mUx9XV9ry8tQDs4TqdswTA+3l79RjpJ6C81qt0tN0JfDW4 LK0Pan4s0f7hH+WOve+D/B2Q+pa9gVxyqd/PekXWi+rGmKWhCWhCWhCg29i8drLgL/cN/NDV Qx54PzH2PbFSdG7+Dp6orPtEJqTA9Wkt82nAJtwffxVCEkTt8F1ynD80OjIFaJ0O6Caz1Lti 67Z3dt2nBczlYg0+e+jzRirQwGSaIWS5d/WEMGTbUfzCRP0tPplxoZKY4iyipdo7vUtCWVgK E97kSYX5uFx0x9ya4linWk2B5/ypzIfOEudYum1YNxNW9PFTqZ9HgixEJAE1wJdRe2O+fq1B y1LqBy+kaLV54pKLsuMxrCh7m51otPtQYSTJ7xzgp6tx4eERw3BFFUiVB/tOfn7Kd9SDWHqg Y91cgO9dvlHyRQ5Ns3aoJxE3NhTYbcuDRK1MacijKZaYEDJ1rJIXDiSiSpjPBC7ppGGHpoXS B16G9HLhitN2B5i7JftweqNPNbZXA86/x6cbqihdJWhM3VLiojwUuKoq+fvXOnbdIlQLvqHx 70zOccHxV8/y23dOO+/A2rjm0s1Woj7lRDg/HUV4PryVETJJ5KWfEPbUqErTwtEpri8nH5E1 KcePxU9K69yH3CBI9m0ttI/0nrVXBwwlk52ZJEJRQFDxc8/nYxp+1LU/zjPoh70lGacQ2PfV 7SYdOjVK/bBpVUakj+EhaI3Y5R3muDaCSllDR1HSTv38OnzTUqN1jJxHi+M03N5y7aXCDcN3 1eqpTQ37oEl6ssq1T49PofTHmbb7g8XVyXZseaLyT2dSL70vLS5HCV2eWPN5VpcT/cruFSGo WjuNMdp7RbzVRmM02oSkjQ2mTcwo8CAh7oq4NF5L9fnqJOvSej+Zj8dKct0xxSWntuUylRqc 9VpNRcYAk9ZlHydcRTIk5L78IvH9mqrO1FuZcuaGwVMysuTQ2rk/JzkdQ7r6lWwTEi7aj3TT sYLzsvv0zIrltwJawsLzwfpazcSxrJDxLwp56APW2VqUSFaJtb8WaR9wj/LHXvnCHg7IfUte wK4/Uu/nvTLrRbVjTJLQhLQhLQhQbekVLbCvoI5Xot9k7/2oap+PoEWHpi36HtipKjjdOAPP 1RWZqFOVtzgvJCE1UMFjui99cDo05oHLCVznBuFAKnGrIXVMkvyI7tFUXX4aryR4HneKEJCu R4hg8EniXlqUq80I9w8aMFvJukWpbFTWyuBUR4R7j64WM+9OmGuZ4puFlnmj+VSkkJCRLyrU +7JdZju02bSG6YEiOToSoaOvG2Kor2Cx2UkTinftqDk5+ny7NrwRiXJH1JKYlJg3LwyQGBZO 4sf6M905ERpOtwGDGRC8bjhLyJVTkvdpU/RUVTumpZ7ENNiOpL5+lHqyj600CmvFtlBPqhZd 1Sqc9Gi7m1ht/ok1GNzqEIETiEpHxdQnMCnBEVe2c6byuIJJpy5yVG344PIle1bnnJ1/ISnu 1Ryqv1muSHjmFMBHphOC2qmRICIWfAgl0+P6P160LEhR2WQ4Mvjl40uVLEh2lwXa6z3z51KL MmGYdFTcdAMtcxNQ4tiIoiqCJ4URcZ76G8TTeVjAj9/4pIaMPnJ3H2s27RtyOVs9QHmI0R0n pTrpGwwXIG1UiXI5Vc/HTiGKqjwG5l0D7lmNLbFF27Tstl5TG2qOpGrSl1IwljpeJrHLPsr5 du37MaxGuzZa2mj6hWe1w+aizB06KjYRo8VkGscMNCPDCKiYXz7ISppidUJ0bNIlBkBHxV1S SZZRRcVVXw4FV7a03Y4Q6iWgFq89TqR9whSCT4oC4/fpsITRFbbGJcy207I7RQTd2O4B9J1x hk18xdktgqfaikmpFjDFanPmpYo9C0KpSbW05BfYUuQa4bIXV/3Ak98sV1JD2O8VP7EkX3e9 NzxBTw/mJ6zaVbkDlqnzF+r1N5P/ALCiakpLsRYqfLWl7PSjBIniaRHxk/a27ud4ERabKQfh xAV/7iTU8z2DsQFtuNw6f2TMsWSY7IxT6PtXX3B5ORnG/wC6440mftUSX+GpaX7BFS/nzLf+ XuTOOLx/pp9E2jqHPlJ6Ij9U1c/u6Wp9rsFSpD3eZ/tgkDxc6WyKs2lwfwfTYkBFz6swDSLn PsiieeE+Hw12+lSIUuRZkQ34NAIf2wyVTfcJ50nC445p9qRSSWhCWhCWhCY1Wl06t096lVWI 3JiSB4utGmRJM5/imk3GwcG04ZwWwGTZXCqzrno823MUnreq0ylu8cI27/OmfPPdDVHPf7jT VRqmBaPUyvNvKPIpBmrTTXjKuLj2KvumqrsWns1Rr9KC+irj9U6oqP2CR6odV7FsxEhKQcG2 HEeef3Kbk8QN3fxApnQaHU6NTXIlQiSorpSScRp6G+jipwFOwICr7vdnXNcRdj3ERaEGpS7L zYw5PLFTMvXKfdfvouNKqTiIjNHqz6F5dKkS/wCJNon+OopjsT4qm9uWs54j704PE1P86KIN 2XdDrROsW1WHFx2DpNtqX/UMcammewfiIob7jYdOfVBMyxZKt7IxindP27vOUPKTbciN8Eek R0X/ALHC1INdgaqF87Nt/wCXuSXywa/pxRONtRdDhfT0+ntB/eqpEv7kj/56npbsCS498Tcf sw96Yli97xW4J81s/WVLkdSpTIfo9B91f2qhh/DUsHYMo/8ANfcj/b+lIHiqaLZGEE/b2fPP 09fjoPvFinIn/wBzPUtL9hrDMvtiZc8fdBNTxHPF4yfjtPTekLJ1+pIKeaNBHbz+5rP+Oppj sX4VY/2kI88Y+9MzrE4f8xPWNsrdZDgciqO/WU4xX/tVNSjOB8OsbMm36kgdQmjG0nIp5HsK 1Y4KA051xF8+tKecz9vIl1MtUinsfNMjDogkdO55y7M2VaEcubdsUtC+KxAVf3qmnotNjsik 4kRInHptPipiJT47Cf7toR/gmlVhOURE8k0IXuhCWhCWhCWhCWhCWhCWhC//2Q== --------------030407060607010708020801-- --------------050509040508030003060708-- From owner-namedroppers@ops.ietf.org Wed Jul 13 02:33:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsao5-0005n9-Lh for dnsext-archive@megatron.ietf.org; Wed, 13 Jul 2005 02:33:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04741 for ; Wed, 13 Jul 2005 02:33:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsajR-000971-I0 for namedroppers-data@psg.com; Wed, 13 Jul 2005 06:28:33 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DsajP-00096c-Qg for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 06:28:31 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DsajO-0004QO-EB for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 02:28:30 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6D6SRO32193 for ; Tue, 12 Jul 2005 23:28:28 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 12 Jul 2005 23:28:27 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 90: Multiple Replies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 90 is enclosed below. LLMNR Issues are tracked on the LLMNR Issues page: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The proposed resolution is as follows: In Section 2.2, delete: "The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would." In Section 2.7, change: " Because an LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received." To: "An LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response. However, an LLMNR sender can consider a multicast query answered after the first response is received if that response has the 'C' bit clear. However, if the first response has the 'C' bit set, then the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. Since it is possible for a response with the 'C' bit clear to be followed by a response with the 'C' bit set, an LLMNR sender SHOULD be prepared to process additional responses for the purposes of conflict detection and LLMNR_TIMEOUT estimation, even after it has considered a query answered." --------------------------------------------------------------------------- Issue 90: Multiple Replies Submitter: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: May 25, 2005 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html Document: LLMNR-40 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would. This means that, even when a query is successfully answered in (say) just 10ms, the sender has to wait for the full LLMNR timeout before returning results to the caller, in case there are other responses coming? [BA] If a response is received with the 'C' bit clear, then the responder has indicated that it believes that the name is unique. In this case the sender can return an answer to the caller without having to wait for additional responses. However, if the response has the 'C' bit set, or if no response is received, then it should wait for LLMNR_TIMEOUT. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 13 02:35:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsaqM-0005wy-3z for dnsext-archive@megatron.ietf.org; Wed, 13 Jul 2005 02:35:42 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06346 for ; Wed, 13 Jul 2005 02:35:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dsaou-0009Zh-39 for namedroppers-data@psg.com; Wed, 13 Jul 2005 06:34:12 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dsaol-0009Z4-BR for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 06:34:03 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dsaok-0005Zt-8e for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 02:34:02 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6D6Xw432614 for ; Tue, 12 Jul 2005 23:33:59 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 12 Jul 2005 23:33:58 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 88: Names vs. RRSETs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 88 is enclosed below. This and other LLMNR issues are tracked on the LLMNR Issues page: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The proposed resolution is as follows: In Section 2.1.1, change: " In an LLMNR response, if one or more resource records in the answer section is UNIQUE, then the 'C' bit is clear, otherwise it is set." To: " In an LLMNR response, if the name is considered UNIQUE, then the 'C' bit is clear, otherwise it is set." In Section 4, change: "The uniqueness of a resource record MAY depend on the nature of the name in the query and type of the query. For example, multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster). By default, a responder SHOULD be configured to behave as though all RRs are UNIQUE on each interface on which LLMNR is enabled." To: "By default, a responder SHOULD be configured to behave as though its name is UNIQUE on each interface on which LLMNR is enabled. However, it is also possible to configure multiple responders to be authoritative for the same name. For example, multiple responders MAY respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster)." In Section 4.1, change: "Prior to including a UNIQUE resource record in a response with the 'T' bit clear, for each UNIQUE resource record in a given interface's configuration, the host MUST verify that there is no other host within the scope of LLMNR query propagation that can return a resource record for the same name, type and class on that interface. Once a responder has verified the uniqueness of a UNIQUE resource record, if it receives an LLMNR query for that resource record, with the 'C' bit clear, it MUST respond, with the 'T' bit clear. Prior to verifying uniqueness, a responder MUST set the 'T' bit in responses." To: "Prior to sending an LLMNR response with the 'T' bit clear, a responder configured with a UNIQUE name MUST verify that there is no other host within the scope of LLMNR query propagation that is authoritative for the same name on that interface. Once a responder has verified that its name is UNIQUE, if it receives an LLMNR query for that name, with the 'C' bit clear, it MUST respond, with the 'T' bit clear. Prior to verifying that its name is UNIQUE, a responder MUST set the 'T' bit in responses." In Section 4.2, change: " If the query is for UNIQUE resource record(s), then the responder MUST send its own query for the same name, type and class, with the 'C' bit clear. If a response is received, then a conflict has been detected." To: "If the query is for a UNIQUE name, then the responder MUST send its own query for the same name, type and class, with the 'C' bit clear. If a response is received, then a conflict has been detected." -------------------------------------------------------------------------- Issue 88: Names vs. RRSETs Submitter: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: May 25, 2005 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html Document: LLMNR-40 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Since LLMNR responders only respond to LLMNR queries for names for which they are authoritative... Is this NAMES for which they are authoritative, or RRSETs (i.e. name+type+class) for which they are authoritative? In some places the document implies that a responder 'owns' a name exclusively, for all types and classes with that name, and in others it seems to assume that the unit of logical ownership is the RRSET. [BA] It is NAMES, not RRSETs. That way a host does not have to attempt to track which RRSETs are in conflict. It can send a uniqueness verification query for any RRSET and if it gets a response, it doesn't have to parse the answer section. As a result, the type and class are not relevant for conflict detection. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 13 02:46:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsb1D-000352-4e for dnsext-archive@megatron.ietf.org; Wed, 13 Jul 2005 02:46:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07149 for ; Wed, 13 Jul 2005 02:46:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dsayr-000ATK-P6 for namedroppers-data@psg.com; Wed, 13 Jul 2005 06:44:29 +0000 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dsayq-000AT5-OP for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 06:44:29 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j6D6iLKu027901; Wed, 13 Jul 2005 08:44:24 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200507130644.j6D6iLKu027901@bartok.nlnetlabs.nl> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair cc: namedroppers@ops.ietf.org Subject: Re: Randomness requirements for message ID generation In-reply-to: Your message of Tue, 12 Jul 2005 10:56:27 -0400. <6.2.1.2.2.20050712093437.03bd4d30@localhost> Date: Wed, 13 Jul 2005 08:44:21 +0200 From: Jaap Akkerhuis X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Having a BCP on things to do for security/reliability by DNS resolvers is a good thing. This includes query ID issues as well as the techniques used to preventing cache poisoning and message integrity protection. About 2 years ago I tried to get such a document written but it never materialized. Isn't dnsops a more appropriate WG? jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 13 03:13:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbQV-0005lV-Ht for dnsext-archive@megatron.ietf.org; Wed, 13 Jul 2005 03:13:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08732 for ; Wed, 13 Jul 2005 03:13:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsbOc-000DK6-Rj for namedroppers-data@psg.com; Wed, 13 Jul 2005 07:11:06 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DsbOa-000DJg-Rz for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 07:11:05 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DsbOZ-000CpE-M2 for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 03:11:03 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6D7B1r02322 for ; Wed, 13 Jul 2005 00:11:02 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 13 Jul 2005 00:11:01 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 87: Timeout Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 87 is enclosed below. LLMNR Issues are tracked on the LLMNR Issue page: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The proposed resolution is as follows: Change Section 2.7 to: "2.7. Retransmission and Jitter An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine when to retransmit an LLMNR query. Rather than using a static timeout, an LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT for each transmission, on a per-interface basis. For example, the algorithms described in RFC 2988 [RFC2988] compute an RTO (including exponential backoff), which is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). Recommended values for constants (including LLMNR_TIMEOUT if it is set statically) are given in Section 7. In order to take slow responders into account, an LLMNR sender SHOULD include responses received after LLMNR_TIMEOUT in the computations. If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. Queries with the 'C' bit set MUST be sent over multicast UDP and MUST NOT be retransmitted. Responses to queries with the 'C' bit set are not taken into account within retransmission timeout computations. An LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response has been received, or if it is necessary to collect all potential responses, such as if a uniqueness verification query is being made. Otherwise an LLMNR sender SHOULD consider a multicast query answered after the first response is received, if that response has the 'C' bit clear. However, if the first response has the 'C' bit set, then the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. Since it is possible for a response with the 'C' bit clear to be followed by a response with the 'C' bit set, an LLMNR sender SHOULD be prepared to process additional responses for the purposes of conflict detection and LLMNR_TIMEOUT estimation, even after it has considered a query answered. In order to avoid synchronization, the transmission of each LLMNR query and response SHOULD delayed by a time randomly selected from the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by responders responding with names which they have previously determined to be UNIQUE (see Section 4 for details)." ---------------------------------------------------------------------------- Issue 87: Timeout Issues Submitter: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: May 25, 2005 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html Document: LLMNR-40 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). If TCP connection setup cannot be completed after how long? [BA] If the destination is off-link, connection setup will typically terminate immediately, due to a TTL or hopcount exceeded message. Otherwise, I don't think a time value needs to be mandated here; this can be left up to the implementation. An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT for each transmission. For example, the algorithms described in RFC 2988 [RFC2988] (including exponential backoff) compute an RTO, which is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). For this computation, does it use the first or last response received? Or the average? [BA] It uses each response received. Is the RTO value computed as a single global? Per interface? Per responding device? (Some devices are slower than others.) [BA] It is a per-interface RTO value. In any case, this approach has the flaw that the computed RTT estimate converges to zero. Suppose you wait for t seconds before giving up. All responses you get necessarily arrive in less than t seconds (ones that arrive later are not seen). The average arrival time is therefore always less than t, so on the next iteration you compute a smaller RTT estimate. As RTT shrinks, more and more of the slower responses are lost, causing RTT to be estimated only from the fast-responding set. A specification of how to do dynamic RTT estimation in a multicast scenario like this needs much more than just a reference to RFC 2988. [BA] This assumes that responses are not included in the RTT and RTO calculation if they arrive after the timeout has expired. That is not what is intended. If the LLMNR sender receives a response after the timeout has expired, it still includes that response in the RTT and RTO calculations. Therefore the RTT is not estimated only from the fast-responding set and does not converge to zero. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 13 03:20:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbXY-00027Y-K5 for dnsext-archive@megatron.ietf.org; Wed, 13 Jul 2005 03:20:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09581 for ; Wed, 13 Jul 2005 03:20:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsbVn-000E56-Vz for namedroppers-data@psg.com; Wed, 13 Jul 2005 07:18:31 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DsbVn-000E4t-3a for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 07:18:31 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DsbVl-000EKU-Ul for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 03:18:30 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6D7IOK02799 for ; Wed, 13 Jul 2005 00:18:25 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 13 Jul 2005 00:18:24 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 86: NITs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 86 is enclosed below. This and other LLMNR Issues are tracked on the LLMNR web site: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The proposed resolution is as follows: In Section 2.1, change: "LLMNR implementations MUST accept UDP queries and responses as large as the smaller of the link MTU or 8192 octets." To: "LLMNR implementations MUST accept UDP queries and responses as large as the smaller of the link MTU or 9000 octets." In Section 2.1.1, change: "T Tentative. The 'T'entative bit is set in a response if the responder is authoritative for the name, but has not yet verified the uniqueness of one or more of the resource record(s) in the answer section. A responder MUST ignore the 'T' bit in a query, if set. When a response with the 'T' bit set is received in response to a uniqueness query, a conflict has been detected and a responder MUST resolve the conflict as described in Section 4.1." To: "T Tentative. The 'T'entative bit is set in a response if the responder is authoritative for the name, but has not yet verified the uniqueness of one or more of the resource record(s) in the answer section. A responder MUST ignore the 'T' bit in a query, if set. If a uniqueness query elicits a response with the 'T' bit set, a conflict has been detected and a responder MUST resolve the conflict as described in Section 4.1. Otherwise, a response with the 'T' bit set is silently discarded by the sender." In Section 2.1.1, change: "If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. This will cause the query to be resent using TCP, and allow the inclusion of a non-zero RCODE in the response to the TCP query. Responding with the TC bit set is preferable to not sending a response, since it enables errors to be diagnosed." To: "If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. This will cause the query to be resent using TCP, and allow the inclusion of a non-zero RCODE in the response to the TCP query. Responding with the TC bit set is preferable to not sending a response, since it enables errors to be diagnosed. Errors include those defined in [RFC2845], such as BADSIG(16), BADKEY(17) and BADTIME(18)." In Section 2.3, change: "An SOA RR is synthesized only when a responder has another RR as well; the SOA RR MUST NOT be the only RR that a responder has." To: "An SOA RR is synthesized only when a responder has another RR in addition to an SOA RR; the SOA RR MUST NOT be the only RR that a responder has." In Section 4.1, change: " If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the query." To: " If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received, the sender MUST check if the source address matches the address of any of its interfaces; if so, then the response is not considered a conflict, since it originates from the sender. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the query." ----------------------------------------------------------------------------------- Issue 86: NITs Submitter: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: May 25, 2005 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html Document: LLMNR-40 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Some other general comments and questions: LLMNR implementations MUST accept UDP queries and responses as large as the smaller of the link MTU or 8192 octets. I suggest 9000 bytes, the Ethernet jumbo frame size, as a natural packet size to pick. Allowing 40 bytes for IPv6 header and 8 for UDP header, that leaves 8952 for the DNS message, which allows for an 8K resource record to be carried (should such a thing ever be needed in future). [BA] OK. T Tentative. The 'T'entative bit is set in a response if the responder is authoritative for the name, but has not yet verified the uniqueness of one or more of the resource record(s) in the answer section. A responder MUST ignore the 'T' bit in a query, if set. When a response with the 'T' bit set is received in response to a uniqueness query, a conflict has been detected and a responder MUST resolve the conflict as described in Section 4.1. The document says nothing about how response with the 'T' bit set are to be interpreted by senders. Should they be ignored, or used in answer to the question? [BA] If a sender receives a response to a normal query with the 'T' bit set, the response is ignored. If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. What kind of error is this anticipating? Either the responder knows the answer, or it does not. Some example of a plausible error would motivate this section. [BA] Examples include error codes sent in response to TSIG queries. Upon configuring an IP address, responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR as well Another RR in addition to A, AAAA and PTR? [BA] Another RR in addition to SOA. If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the query. This suffers from auto-immune response, in the case where a machine has both Ethernet and wireless connections, and (unknown to the machine) the Ethernet and wireless networks are bridged together. [BA] Right. The check need only be done if the source address is different than the address of one of the host's interfaces. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 13 05:20:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdPR-00088h-P8 for dnsext-archive@megatron.ietf.org; Wed, 13 Jul 2005 05:20:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17832 for ; Wed, 13 Jul 2005 05:20:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsdMB-000OEO-Kv for namedroppers-data@psg.com; Wed, 13 Jul 2005 09:16:43 +0000 Received: from [213.97.128.69] (helo=pc-p1-informatica.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DsdM2-000ODB-WA for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 09:16:35 +0000 Date: Wed, 13 Jul 2005 10:15:46 +0000 To: "Namedroppers" From: "Ogud" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wfglndyssxxkboryxrgd" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, HTML_SHORT_LENGTH,MSGID_SPAM_LETTERS autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ----------wfglndyssxxkboryxrgd Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [MP3.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/13/2005 09:10 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------wfglndyssxxkboryxrgd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >The snake


----------wfglndyssxxkboryxrgd-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 13 10:50:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsiYs-0007KI-Hj for dnsext-archive@megatron.ietf.org; Wed, 13 Jul 2005 10:50:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13174 for ; Wed, 13 Jul 2005 10:50:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DsiU4-0002Fl-QR for namedroppers-data@psg.com; Wed, 13 Jul 2005 14:45:12 +0000 Received: from [192.20.225.110] (helo=mail-white.research.att.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DsiU3-0002FL-6x for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 14:45:11 +0000 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id 7DE65A7AD1; Wed, 13 Jul 2005 10:45:10 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j6DEjAg9026038; Wed, 13 Jul 2005 10:45:10 -0400 Message-Id: <200507131445.j6DEjAg9026038@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ehall@ehsco.com Subject: Re: IANA registry for SRV record names Cc: namedroppers@ops.ietf.org References: <200507081800.j68I0hWD029117@bright.research.att.com> <42CED6EF.4010601@ehsco.com> Date: Wed, 13 Jul 2005 10:45:10 -0400 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >We've been through this before. Sure, which is why I'm proposing doing something about it this time ;-) >I think the text in 2782 pretty much >requires independent registration. I know this wasn't the intent of 2782's >authors, but that's pretty much the way it boils out. If this is the WG consensus, I'm happy to update the draft (well, effectively write a whole new one, I guess ;-) to reflect this. The transition to this seperate registry will be more work, since it'll require actually identifying the protocols that use SRV records, but it will be more useful in the long run. Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 13 11:15:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsix8-0000VG-NO for dnsext-archive@megatron.ietf.org; Wed, 13 Jul 2005 11:15:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19574 for ; Wed, 13 Jul 2005 11:15:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dsiue-0005MK-Lw for namedroppers-data@psg.com; Wed, 13 Jul 2005 15:12:40 +0000 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dsiuc-0005Lz-Ld for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 15:12:38 +0000 Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id B776D7FD0; Wed, 13 Jul 2005 17:12:31 +0200 (CEST) Subject: Re: IANA registry for SRV record names From: Jeroen Massar To: Bill Fenner Cc: ehall@ehsco.com, namedroppers@ops.ietf.org In-Reply-To: <200507131445.j6DEjAg9026038@bright.research.att.com> References: <200507081800.j68I0hWD029117@bright.research.att.com> <42CED6EF.4010601@ehsco.com> <200507131445.j6DEjAg9026038@bright.research.att.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CuIpeudqdIE+pPd0ydi4" Organization: Unfix Date: Wed, 13 Jul 2005 17:12:27 +0200 Message-Id: <1121267547.26848.54.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=-CuIpeudqdIE+pPd0ydi4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-07-13 at 10:45 -0400, Bill Fenner wrote: > >We've been through this before. >=20 > Sure, which is why I'm proposing doing something about it this time ;-) >=20 > >I think the text in 2782 pretty much > >requires independent registration. I know this wasn't the intent of 2782= 's > >authors, but that's pretty much the way it boils out. >=20 > If this is the WG consensus, I'm happy to update the draft (well, effecti= vely > write a whole new one, I guess ;-) to reflect this. The transition to th= is > seperate registry will be more work, since it'll require actually > identifying the protocols that use SRV records, but it will be more > useful in the long run. Having a consistent registry for SRV records and how to use them for the various protocols is of course useful. The dns-sd.org one already provides one which is nice and central, but politically it should be done by IANA of course. On a related note, my means of using SRV records in an extended way: http://www.ietf.org/internet-drafts/draft-massar-dnsop-service-00.txt http://www.ietf.org/internet-drafts/draft-massar-v6ops-tunneldiscovery-00.t= xt Greets, Jeroen --=-CuIpeudqdIE+pPd0ydi4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBC1S9bKaooUjM+fCMRAnWUAJ0WYenmEpJO/5Zx/eYYE/KOMGDM5gCgptFl bwp4zDS39UZjr5+pKGtBWSY= =PUtu -----END PGP SIGNATURE----- --=-CuIpeudqdIE+pPd0ydi4-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 13 22:06:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dst7J-0005fp-79 for dnsext-archive@megatron.ietf.org; Wed, 13 Jul 2005 22:06:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02396 for ; Wed, 13 Jul 2005 22:06:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dst3c-000Atv-8Y for namedroppers-data@psg.com; Thu, 14 Jul 2005 02:02:36 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dst3a-000Atb-Fg for namedroppers@ops.ietf.org; Thu, 14 Jul 2005 02:02:34 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dst3Z-000MIj-26 for namedroppers@ops.ietf.org; Wed, 13 Jul 2005 22:02:33 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6E22UO07514 for ; Wed, 13 Jul 2005 19:02:31 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 13 Jul 2005 19:02:30 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 89: Failed lookups Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 89 is enclosed below. This and other LLMNR Issues are tracked on the LLMNR Issues Web site at: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The proposed resolution is as follows: In Section 2, change: " An LLMNR sender may send a request for any name. However, by default, LLMNR requests SHOULD be sent only when one of the following conditions are met: [1] No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution mechanism. For dual stack hosts configured with DNS server address(es) for one protocol but not another, this implies that DNS queries SHOULD be sent over the protocol configured with a DNS server, prior to sending LLMNR queries. [2] DNS servers do not respond. For a dual stack host, the host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, prior to use of LLMNR. [3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section." To: " An LLMNR sender may send a request for any name. However, by default, LLMNR requests SHOULD be sent only when one of the following conditions are met: [1] No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution mechanism. For dual stack hosts configured with DNS server address(es) for one protocol but not another, this implies that DNS queries SHOULD be sent over the protocol configured with a DNS server, prior to sending LLMNR queries. [2] All attempts to resolve the name have failed after exhausting the searchlist, either because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. A dual stack host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, prior to use of LLMNR." ---------------------------------------------------------------------- Issue 89: Failed Lookups Submitter: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: May 25, 2005 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html Document: LLMNR-40 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: An LLMNR sender may send a request for any name. However, by default, LLMNR requests SHOULD be sent only when one of the following conditions are met: [3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. This seems to imply that *every* single failed name lookup on a LLMNR-enabled host has to suffer the full LLMNR timeout before returning to the caller. For example, when I look up "foo" today, the DNS resolver client rapidly runs through my searchlist getting authoritative no-answer or NXDOMAIN responses for each one. With LLMNR, *every* single one of those failed lookups would have to wait a second or two for LLMNR to time out. What used to take mere milliseconds could now take 5-10 seconds to complete. [BA] Sending an LLMNR query after *every* single failed name lookup is not required, and is undesirable for the reasons you state. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 14 04:49:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DszPW-0002Av-Hq for dnsext-archive@megatron.ietf.org; Thu, 14 Jul 2005 04:49:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19045 for ; Thu, 14 Jul 2005 04:49:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DszKn-000CaF-4B for namedroppers-data@psg.com; Thu, 14 Jul 2005 08:44:45 +0000 Received: from [213.97.128.69] (helo=pc-p1-informatica.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DszKl-000CZj-FJ for namedroppers@ops.ietf.org; Thu, 14 Jul 2005 08:44:43 +0000 Date: Thu, 14 Jul 2005 09:43:51 +0000 To: "Namedroppers" From: "Ogud" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------zuobsohcrekmpffikuxa" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, HTML_SHORT_LENGTH,MSGID_SPAM_LETTERS autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ----------zuobsohcrekmpffikuxa Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Cool_MP3.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/14/2005 08:38 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------zuobsohcrekmpffikuxa Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >The snake


----------zuobsohcrekmpffikuxa-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 14 15:54:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9mx-00011k-4c for dnsext-archive@megatron.ietf.org; Thu, 14 Jul 2005 15:54:31 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14679 for ; Thu, 14 Jul 2005 15:54:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dt9io-0008Oo-91 for namedroppers-data@psg.com; Thu, 14 Jul 2005 19:50:14 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dt9in-0008OO-L7 for namedroppers@ops.ietf.org; Thu, 14 Jul 2005 19:50:13 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9id-0006FV-Mc; Thu, 14 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dns-name-p-s-00.txt Message-Id: Date: Thu, 14 Jul 2005 15:50:03 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Derivation of DNS Name Predecessor and Successor Author(s) : G. Sisson, B. Laurie Filename : draft-ietf-dnsext-dns-name-p-s-00.txt Pages : 25 Date : 2005-7-14 This document describes two methods for deriving the canonically- ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC-secured zone. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-name-p-s-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dns-name-p-s-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dns-name-p-s-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-14132858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-name-p-s-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-name-p-s-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14132858.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 15 10:16:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQzO-0007Sh-IM for dnsext-archive@megatron.ietf.org; Fri, 15 Jul 2005 10:16:31 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08741 for ; Fri, 15 Jul 2005 10:16:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtQud-000FrC-ER for namedroppers-data@psg.com; Fri, 15 Jul 2005 14:11:35 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DtQuc-000Fqr-Mh for namedroppers@ops.ietf.org; Fri, 15 Jul 2005 14:11:34 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j6FEBPvb061854; Fri, 15 Jul 2005 10:11:26 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050715100508.045695c0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 10:11:03 -0400 To: Jaap Akkerhuis From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Randomness requirements for message ID generation Cc: namedroppers@ops.ietf.org In-Reply-To: <200507130644.j6D6iLKu027901@bartok.nlnetlabs.nl> References: <200507130644.j6D6iLKu027901@bartok.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02:44 13/07/2005, Jaap Akkerhuis wrote: > > Having a BCP on things to do for security/reliability by DNS resolvers > is a good thing. This includes query ID issues as well as the techniques > used to preventing cache poisoning and message integrity protection. > About 2 years ago I tried to get such a document written but it > never materialized. > > >Isn't dnsops a more appropriate WG? > Though call, but IMHO the cache poisoning documentation is clearly in the protocol camp, random ID and port usage recommendation can be in either group. So far no person has stepped forward and expressed interest in working on these items. I take this as no one cares and the WG should not bother with this. Olafur (who by policy will not write ID for WG's he chairs) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 15 23:51:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtdhv-0006u1-6r for dnsext-archive@megatron.ietf.org; Fri, 15 Jul 2005 23:51:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01371 for ; Fri, 15 Jul 2005 23:51:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dtdcy-000G9e-Oz for namedroppers-data@psg.com; Sat, 16 Jul 2005 03:46:12 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dtdcw-000G9O-W5 for namedroppers@ops.ietf.org; Sat, 16 Jul 2005 03:46:11 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dtdcv-000CSl-MQ for namedroppers@ops.ietf.org; Fri, 15 Jul 2005 23:46:09 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6G3k8t28860 for ; Fri, 15 Jul 2005 20:46:08 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Fri, 15 Jul 2005 20:46:07 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 92: Use of TCP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 92: Use of TCP Submitter: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: May 25, 2005 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html Document: LLMNR-40 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). If TCP connection setup cannot be completed after how long? [BA] Perhaps LLMNR_TIMEOUT is an appropriate value for the timer. [Yi Zhao] For the case of a PTR RR query it should not be necessary to wait for LLMNR_TIMEOUT if the destination is off-link. As I understand it, one reason for sending PTR queries via unicast was in order to get immediate feedback if the destination is off-link. However, ICMP "TTL Exceeded" is treated as a soft error by TCP, and as a result, setting TTL=1 on TCP connections does not result in senders receiving immediate notification if the destination address is off-link. This issue can be better handled with unicast queries sent via UDP. Looking over the discussion on TCP vs. UDP for unicast queries, I am not convinced that UDP unicast queries should be outlawed. I understand why PTR RR queries should be sent via unicast. In order to prevent unicast queries from propagating beyond the local link, unicast queries should have TTL should be set to 1. However, I do not buy the argument that using TCP improves security significantly. Unicast PTR RR queries will only be answered by a single host -- there is no opportunity for magnification attacks here. Just because the response is larger than the query does not mean that a significant DoS attack opportunity exists. Even if UDP unicast queries are outlawed, an LLMNR sender still needs to listen for UDP unicast responses, so the opportunity for spoofed requests and responses still exists. It seems to me that TCP was selected because UDP queries are to be sent with TTL=255: "For UDP queries and responses, the Hop Limit field in the IPv6 header and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Bonjour [Bonjour]." However, LLMNR and Bonjour use different link-scope multicast addresses and ports. in Issue 87, Stuart indicates that Bonjour compatibility has not been tested. The protocols are very diffent. So what is the value of this? I would propose that the following sentences be changed from: " Unicast LLMNR queries MUST be done using TCP and the responses MUST be sent using the same TCP connection as the query. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries. If the sender of a TCP query receives a response to that query not using TCP, the response MUST be silently discarded. Unicast UDP queries MUST be silently discarded." To: "Where unicast LLMNR queries are sent using TCP, the response MUST be sent using the same TCP connection as the query. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries. If the sender of a TCP query receives a response to that query not using TCP, the response MUST be silently discarded." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 15 23:53:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtdkS-0008F7-6N for dnsext-archive@megatron.ietf.org; Fri, 15 Jul 2005 23:53:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01491 for ; Fri, 15 Jul 2005 23:53:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dtdih-000Glg-QN for namedroppers-data@psg.com; Sat, 16 Jul 2005 03:52:07 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dtdif-000GlK-Vt for namedroppers@ops.ietf.org; Sat, 16 Jul 2005 03:52:06 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dtdie-000CzJ-TD for namedroppers@ops.ietf.org; Fri, 15 Jul 2005 23:52:05 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6G3q2n29166 for ; Fri, 15 Jul 2005 20:52:03 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Fri, 15 Jul 2005 20:52:02 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 91: Clarifications Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR issue 91 is enclosed below. This and other LLMNR Issues are tracked on the LLMNR Issues Page: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The proposed resolution is as follows: In Section 2, change: "However, a host configured as a responder MUST act as a sender to verify the uniqueness of names as described in Section 4." To: "However, a host configured as a responder MUST act as a sender, if only to verify the uniqueness of names as described in Section 4." Change: " [2] All attempts to resolve the name via DNS have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. A dual stack host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, prior to use of LLMNR." To: "[2] All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. A dual stack host SHOULD attempt to reach DNS servers over all protocols on which DNS server address(es) are configured, prior to use of LLMNR." In Section 2.1.1: Change: "In an LLMNR query, the RCODE MUST be zero, and is ignored by the responder. " To: "In an LLMNR query, the sender MUST set RCODE to zero; the responder ignores the RCODE and assumes it to be zero." Add to NSCOUNT: "LLMNR responders MUST silently discard LLMNR queries with NSCOUNT not equal to zero." In Section 4.2, change: "After stopping the use of a name, the responder MAY elect to configure a new name. However, since name reconfiguration may be disruptive, this is not required, and a responder may have been configured to respond to multiple names so that alternative names may already be available." To: "After stopping the use of a name, the responder MAY elect to configure a new name. However, since name reconfiguration may be disruptive, this is not required, and a responder may have been configured to respond to multiple names so that alternative names may already be available. A host that has stopped the use of a name may attempt uniqueness verification again after the expiration of the TTL of the conflicting response." ------------------------------------------------------------------------------ Issue 91: Clarifications Submitter: Yi Zhao Submitter email address: yizhao@microsoft.com Date first submitted: July 14, 2005 Reference: Document: LLMNR-40 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Here are some questions. 1. Page 7 Regarding C bit: what happens if in the first response C=1, and in the second response C=0? Is a conflict detected with discard as Page 19 suggests? [BA] Since the first Response is C=1, the sender waits for LLMNR_TIMEOUT. On receiving the second one, a conflict is detected and the sender resends the query with the 'C' bit set. The sender concatenates both responses together and returns the answer. 2. Page 8 Regarding RCODE: In an LLMNR query, the RCODE MUST be zero, and is ignored by the responder. What does ignored mean here? Discard of the query by responder? If not, why MUST RCODE be zero? [BA] Ignored means "act as though the RCODE is zero" in a query. 3. Page 8 Regarding NSCOUNT: what should the responder do to sanity check this? Should the responder discard the query if the NSCOUNT is not zero as with ANCOUNT? [BA] The responder should silently discard the packet. 3.1 Page 9 Regarding ARCOUNT: what should a responder do to sanity check this? Should responder discard query if C-bit is not set and ARCOUNT is non-zero like ANCOUNT? I assume it is only used by responders. [BA] ARCOUNT may be non-zero even in queries where the 'C' bit is clear. See section 2.9. 4. Page 5 Regarding configuration: However, a host configured as a responder MUST act as a sender to verify the uniqueness of names as described in Section 4. It does not mean the host must resolve names as a sender, right? The host could be configured as a responder but send queries to verify uniqueness. [BA] Yes. It should say "MUST act as a sender, if only to verify the uniqueness of names as described in Section 4." 5. Page 5 Regarding when LLMNR is used. As a failover method, how do we define a failure in DNS? If I received any records, it is not a failure, right? Is it possible to receive records from one DNS server on one interface, but fail on another interface? Can we say that response from any DNS server is complete for all interfaces and protocols? I am just not clear here. [BA] Yes, if RRs are received from any DNS server on any interface or protocol then LLMNR should not be used. 6. Page 19: Regarding conflict detection and defense: Is that a MUST or SHOULD for the sender to send back notification? Is that a "MAY"? [BA] It is a SHOULD in Section 4.2: " In order to enable ongoing detection of name conflicts, when an LLMNR sender receives multiple LLMNR responses to a query, it MUST check if the 'C' bit is clear in any of the responses. If so, the sender SHOULD send another query for the same name, type and class, this time with the 'C' bit set, with the potentially conflicting resource records included in the additional section." 7. Page 18 & 19: Regarding conflict detection: If the host finds a conflict and stops answering queries for its name, how can the host enable itself again since it has no clue if the conflicting host is still present? [BA] The host can continue to answer queries for non-conflicting names and also can do uniqueness verification again, if any of the events described in section 4.1 occur. After the TTL of the conflicting RR expires, the host can also attempt uniqueness verification again. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 16 00:02:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtdtA-0004f3-Jw for dnsext-archive@megatron.ietf.org; Sat, 16 Jul 2005 00:02:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01895 for ; Sat, 16 Jul 2005 00:02:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DtdrC-000Hvr-By for namedroppers-data@psg.com; Sat, 16 Jul 2005 04:00:54 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DtdrA-000HvO-4p for namedroppers@ops.ietf.org; Sat, 16 Jul 2005 04:00:52 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dtdr8-000EEQ-WA for namedroppers@ops.ietf.org; Sat, 16 Jul 2005 00:00:51 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6G40m829755 for ; Fri, 15 Jul 2005 21:00:49 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Fri, 15 Jul 2005 21:00:48 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 85: General Comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 85 is enclosed below. This and other LLMNR issues are tracked on the LLMNR issues page: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The proposed resolution is as follows: Move the following sentence from Section 2 to Section 1: "IPv4 administratively scoped multicast usage is specified in "Administratively Scoped IP Multicast" [RFC2365]." In Section 2.5, change: "2.5. "Off link" Detection For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. For IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or one belonging to a prefix that a Router Advertisement indicates is on-link [RFC2461]. A sender MUST select a source address for LLMNR queries that is "on link". The destination address of an LLMNR query MUST be a link- scope multicast address or an "on link" unicast address. A responder MUST select a source address for responses that is "on link". The destination address of an LLMNR response MUST be an "on link" unicast address." To: "2.5. "Off link" Detection A sender MUST select a source address for LLMNR queries that is assigned on the interface on which the query is sent. The destination address of an LLMNR query MUST be a link-scope multicast address or a unicast address. A responder MUST select a source address for responses that is assigned on the interface on which the query was received. The destination address of an LLMNR response MUST be a unicast address." Add the following sentence to Section 2.6: "IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local addresses are defined in [RFC2373]." Delete references to [RFC2460] and [RFC2461]. ---------------------------------------------------------------------------- Issue 85: General Comments Submitter: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: May 25, 2005 Reference: Document: LLMNR-40 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Reading draft-ietf-dnsext-mdns-40.txt, the problem I ran into was trying to understand what problem it is trying to solve. The abstract states that it is for "ad-hoc networks operating without a Domain Name System (DNS) server." Superficially that sounds all well and good, but what does it really mean? When it says, "DNS server", does it mean "authoritative name server", or "recursive name server"? The document needs to say clearly which it is talking about, because they are very different problems. One scenario is a device that has a name, but no authoritative server to answer for that name. The other is a resolver client that wants to look up a name, but has no recursive server to ask. There are several problems I can imagine this document *might* be trying to solve: 1. A device that has a conventionally allocated, properly delegated, fully-qualified domain name, but there is no (authoritative) name server to answer for that name. 2. A device that has *no* conventionally allocated, properly delegated, fully-qualified domain name, because the user doesn't know how to do that, or doesn't want to pay the annual fee to register a domain, or simply because the device has just shipped from the factory, and doesn't even have a human owner yet to go through the steps of allocating and assigning a unique FQDN for it. 3. A client that wants to look up a host name, but there is no authoritative name server for that name. 4. A client that wants to look up a host name, but there is no recursive name server available for the client to talk to. 5. A client that wants to look up a host name, and there is an authoritative name server for that name, but for whatever reason it's not responding right now. These are all very different scenarios, and the document needs to state clearly which, if any (or all) of them it is addressing. Right now reading the document feels a bit like playing the shell game, where you try (usually unsuccessfully) to keep track of which shell has the pea underneath as they slide around. Reading the document, I kept finding things that didn't work for one or more of the above scenarios, but it wasn't clear if that was a problem because it wasn't clear if the document was seeking to solve that particular problem. [BA] A host implementing IPv6 may require LLMNR for name resolution in each of the scenarios you describe. For example, an IPv6-only host may not have a DNS server configured, or it may have an anycast DNS server address configured, but there is no server present listening on that address that is reachable from the hosts's location. There is also an additional scenario not listed, which is that a host may have an authoritative name server which may not answer for all RR types. For example, a home gateway may have a DNS server built-in which may support DDNS via DHCPv4. However, the DNS server may only answer with A RRs, not AAAA RRs, and it may not answer queries over IPv6. Scenario 1 cannot necessarily be distinguished from Scenario 5, or even Scenario 4. For example, with IPv6, anycast addresses can be configured for DNS servers, so that a DNS server address can be configured but there is no DNS server listening on the anycast address. Also, it is possible that a DNS server may have been configured, but the host has moved to an adhoc network where that server is no longer reachable. Perhaps if you would provide a list of things that you found that didn't work, then we could better address the issue. For example, a host configured to have computer name "host1" and to be a member of the "example.com" domain, and with IPv4 address 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the following records: host1. IN A 192.0.2.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 This seems to be the most egregious pollution of the top level of the DNS namespace. If I call my television "tv.myhouse.", then that means it answers for the name "tv." How does that coexist with the global DNS records for Tuvalu? [BA] Since there is no concept of delegation in LLMNR, configuring a host to answer LLMNR queries for "tv.myhouse" or even "tv" will not cause a responder to answer queries for "foo.tv" or any other name within the tv TLD. 2.5. "Off link" Detection For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. How does a given device *know* what subnets are on the local link? To know this, a device has to have perfectly accurate configuration information, but the whole point of LLMNR is for scenarios where configuration infrastructure has failed, and the device is left to fend for itself as best it can. To be useful, the device has to be able to operate even if some or all of its configuration information is wrong. [BA] Section 2.5 should only relate to what source addresses a host can use in responding to an LLMNR query. However, there are also two instances where it also talks about whether a destination address is "on link". By removing those two instances we can remove the need for the host to know what prefixes are on the link, and only depend on its knowing what addresses have been assigned on which interfaces. Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the response to one (1). The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder. A common enterprise configuration is to have two or more IP subnets overlayed on the same physical link. (You can argue that this is misconfiguration, but it is still common.) This means that two laptops sitting next to each other on the same Ethernet hub can be apparently two hops from each other. Setting the TTL to 1 means that half of the LAN becomes unreachable from the other half. Also, how does this interact with multi-link subnets? [BA] In this scenario, the router could send an ICMP redirect if it wanted the host to treat the other subnet as local. It is also possible that the router would include a built-in DNS server so that LLMNR would not be necessary. With respect to "multi-link" subnets, some instances of these do not decrement TTL and others (MANET) do. In those that do, my understanding is that LLMNR queries will not propagate beyond the link scope either. Since DNS PTR queries frequently fail, applications need to be prepared for this. So using TCP and setting the TTL field to 1 for PTR RR queries shouldn't have much negative impact. For UDP queries and responses, the Hop Limit field in the IPv6 header and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Bonjour [Bonjour]. Has this compatibility been tested? I don't have access to any LLMNR implementation. (I don't even know if there are any LLMNR implementations). Windows users can easily test this by just downloaded Bonjour for Windows. If one of the LLMNR supporters could try it, that would be very useful information. [BA] To my knowledge compatibility has not been tested. Since you submitted the original comment that lead to the incorporation of this text, can you suggest something more appropriate? IPv4 administratively scoped multicast usage is specified in "Administratively Scoped IP Multicast" [RFC2365]. Does LLMNR use Administratively Scoped IP Multicast? The IPv4 link- scope multicast address a given responder listens to, and to which a sender sends queries, is 224.0.0.252. Why this address? My mDNS protocol uses link-local address 224.0.0.251 for consistency with Administratively Scoped Multicast addresses, which are allocated from the top down. 239.x.x.251 was the Administratively Scoped address group originally allocated for mDNS; for consistency I picked 224.0.0.251 as its link-local counterpart. The Administratively Scoped address group 239.x.x.252 is allocated for MZAP, which does not (as far as I know) have anything to do with LLMNR. [BA] 224.0.0.252 was the address assigned by IANA. The "252" has no broader significance. LLMNR does not use Administratively Scoped IP Multicast. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From MaureenDelarosa@sinful-mail.com Sat Jul 16 03:15:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtgt7-00074k-Q0 for dnsext-archive@megatron.ietf.org; Sat, 16 Jul 2005 03:15:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00218 for ; Sat, 16 Jul 2005 03:15:04 -0400 (EDT) Received: from [61.149.71.16] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DthLs-0005uL-MD for dnsext-archive@ietf.org; Sat, 16 Jul 2005 03:45:02 -0400 Received: from Cwim@localhost by MgI.int (8.11.6/8.11.6); Sun, 17 Jul 2005 06:41:26 +0600 Message-ID: From: "Giselle Sutton" Reply-To: "Giselle Sutton" To: dnsext-archive@ietf.org, eugenia.snider@ietf.org Subject: Out of this WoRLD $aving$ on all Symantec titles Date: Sat, 16 Jul 2005 18:40:26 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MaureenDelarosa@sinful-mail.com Content-Type: multipart/mixed; boundary="--9TIwJFyvaFeXihyREKNG" X-Spam-Score: 3.4 (+++) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad jJ72 ----9TIwJFyvaFeXihyREKNG Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable 3
Opt-in Email Special Offer   = ;  unsubscribe me
<= tr>=
SEARCH
<= /table>

<= font size=3D1> =

TOP 10 NEW TITLES

<= img src=3Dhttp://g-images.amazon.com/images/G/01/icons/eyebrow-upper-right= -corner.gif width=3D5 height=3D5>
<= td width=3D4> 

 = ON SALE NOW!

 1 Office Pro 2003
 2 Adobe Photoshop 9.0
 3= Windows XP Pro
 4 Adobe Acrobat 7 Pro
&nb= sp;5 Flash MX 2004
&n= bsp;6 Corel Draw 12
&= nbsp;7 Norton Antivirus 2005
 8 Windows 2003 Server
9 Alias Maya 6 Wavefrt
 10 Adobe Illustrator 11
  S= ee more by this manufacturer
=    Microsoft=
   Symantec
   Adobe
  Customers also bou= ght
 =   = these other items...

Microsoft Off= ice Professional Edition *2003*
Microsoft

Choose:=
 

<= td class=3Dsmall height=3D18 width=3D105>$69.99<= /tr><= /tr>
List Price:$499.00=
Price:
You Save:$429.01 (86%)



Availability: Available f= or INSTANT download!
Coupon Code: 7PYbq
 

Sales Rank: #1
<= a href=3Dhttp://flybynightsoft.net/?o>System requirements  | = ; Other Versions
Date Coupon Expires: August 31st, 2005
<= font class=3Dtiny>Average Customer Review:3D"5= Based on 158422 = reviews. Write a review.=

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$5= 99.00
Price:<= /td>$69.99<= /td>
You Save:$529.01 (90= %)



Availability:<= /b> Available for INSTANT download!
Coupon Code: MHizF
&nbs= p;

Sales Rank: #2
System requirements  |  Other Versions=
Date Coupon Expires: August 31st, 20= 05
Average Customer Review:3D"5 B= ased on 16245 reviews. Write a revi= ew.

Microsoft Windows XP Professional or Lo= nghorn Edition
Microsoft

Choose:
=  

<= tr><= /table>



Availability: Available for IN= STANT download!
Coupon Code: 0Lnq2jvQY
 

= Sales Rank: #3
System requirements  | = Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D"5 Based on 195863 r= eviews. Write a review.<= /p>

List Price:$279.00
Price:$49.99
You Save:$229.01 (85%)

Adobe Acrobat Professional V 7.0
= Adobe

Choose:<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 width=3D164>
 

List Price:$499.00
Price:$69.99
You Save:= $429.01 (85%)



Ava= ilability: Available for INSTANT download!
Coupon Code: 6rN= Ig
 

Sales Rank: #4=
System req= uirements  |  Other V= ersions
Date Coupon Expires: Augu= st 31st, 2005
Average Customer Review:3D"5 Based on 15247 reviews. W= rite a review.

----9TIwJFyvaFeXihyREKNG-- From owner-namedroppers@ops.ietf.org Mon Jul 18 15:54:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DubhV-0000U9-Nz for dnsext-archive@megatron.ietf.org; Mon, 18 Jul 2005 15:54:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10831 for ; Mon, 18 Jul 2005 15:54:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dubcs-0008Vb-8c for namedroppers-data@psg.com; Mon, 18 Jul 2005 19:50:06 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dubcr-0008Uz-GM for namedroppers@ops.ietf.org; Mon, 18 Jul 2005 19:50:05 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dubcn-0002H9-SQ; Mon, 18 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-41.txt Message-Id: Date: Mon, 18 Jul 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : B. Aboba, et al. Filename : draft-ietf-dnsext-mdns-41.txt Pages : 28 Date : 2005-7-18 The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-41.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-41.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-41.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-18150224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-41.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-41.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-18150224.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 18 18:07:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dudlp-0007Xl-Fs for dnsext-archive@megatron.ietf.org; Mon, 18 Jul 2005 18:07:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03521 for ; Mon, 18 Jul 2005 18:07:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dudj4-000MqZ-8g for namedroppers-data@psg.com; Mon, 18 Jul 2005 22:04:38 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dudj2-000MqG-Cw for namedroppers@ops.ietf.org; Mon, 18 Jul 2005 22:04:36 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1Dudj1-000L93-6Z for namedroppers@ops.ietf.org; Mon, 18 Jul 2005 18:04:35 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6IM4WW17547 for ; Mon, 18 Jul 2005 15:04:33 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Mon, 18 Jul 2005 15:04:32 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 92: Use of TCP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 92 is enclosed below. This and other LLMNR Issues are tracked at: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The proposed resolution is to reject the issue. The issue relates to the recommended value of an application timer on TCP queries. Application layer timers are not defined for DNS clients, so I'm not clear why LLMNR would need to define it either. The other part of this issue is whether to allow UDP queries for PTR RRs. LLMNR is designed so as to prohibit queries from off-link senders, in order to prevent the protocol from being exploited by a worm if implementation vulnerabilities were discovered. Therefore the only types of queries allowed are UDP queries to a link-scope multicast address or TCP queries with TTL=1. So you could conceivably use UDP multicast for a PTR RR query, but not UDP unicast. UDP multicast PTR RR queries are not prohibited, since Section 2.0 says: "A sender SHOULD send LLMNR queries for PTR RRs via unicast, as specified in Section 2.4." Since multicast PTR RR queries are already legal there is no change required to support them. > Issue 92: Use of TCP > Submitter: Stuart Cheshire > Submitter email address: cheshire@apple.com > Date first submitted: May 25, 2005 > Reference: > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html > Document: LLMNR-40 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > > If TCP connection setup cannot be completed in order to send a > unicast TCP query, this is treated as a response that no records of > the specified type and class exist for the specified name (it is > treated the same as a response with RCODE=0 and an empty answer > section). > > If TCP connection setup cannot be completed after how long? > > [BA] Perhaps LLMNR_TIMEOUT is an appropriate value for the timer. > > [Yi Zhao] > > For the case of a PTR RR query it should not be necessary to wait > for LLMNR_TIMEOUT if the destination is off-link. As I understand > it, one reason for sending PTR queries via unicast was in order to > get immediate feedback if the destination is off-link. > > However, ICMP "TTL Exceeded" is treated as a soft error by TCP, and as a > result, setting TTL=1 on TCP connections does not result in senders > receiving immediate notification if the destination address is off-link. > This issue can be better handled with unicast queries sent via UDP. > > Looking over the discussion on TCP vs. UDP for unicast queries, I am > not convinced that UDP unicast queries should be outlawed. > I understand why PTR RR queries should be sent via unicast. > In order to prevent unicast queries from propagating beyond > the local link, unicast queries should have TTL should be set to 1. > > However, I do not buy the argument that using TCP improves security > significantly. Unicast PTR RR queries will only be answered by a > single host -- there is no opportunity for magnification attacks here. > Just because the response is larger than the query does not mean that > a significant DoS attack opportunity exists. Even if UDP unicast > queries are outlawed, an LLMNR sender still needs to listen for UDP > unicast responses, so the opportunity for spoofed requests and responses > still exists. > > It seems to me that TCP was selected because UDP queries are to be sent > with TTL=255: > > "For UDP queries and responses, the Hop Limit field in the IPv6 header > and the TTL field in the IPV4 header MAY be set to any value. However, > it is RECOMMENDED that the value 255 be used for compatibility with > Apple Bonjour [Bonjour]." > > However, LLMNR and Bonjour use different link-scope multicast addresses > and ports. in Issue 87, Stuart indicates that Bonjour compatibility has > not been tested. The protocols are very diffent. So what is the value of > this? > > I would propose that the following sentences be changed from: > > " Unicast LLMNR queries MUST be done using TCP and the responses MUST > be sent using the same TCP connection as the query. Senders MUST > support sending TCP queries, and responders MUST support listening > for TCP queries. If the sender of a TCP query receives a response to > that query not using TCP, the response MUST be silently discarded. > > Unicast UDP queries MUST be silently discarded." > > To: > > "Where unicast LLMNR queries are sent using TCP, the response MUST > be sent using the same TCP connection as the query. Senders MUST > support sending TCP queries, and responders MUST support listening > for TCP queries. If the sender of a TCP query receives a response to > that query not using TCP, the response MUST be silently discarded." > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 18 19:31:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duf4i-0007uP-IM for dnsext-archive@megatron.ietf.org; Mon, 18 Jul 2005 19:31:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22289 for ; Mon, 18 Jul 2005 19:31:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Duf1h-0005M2-DC for namedroppers-data@psg.com; Mon, 18 Jul 2005 23:27:57 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Duf1f-0005Lp-QJ for namedroppers@ops.ietf.org; Mon, 18 Jul 2005 23:27:55 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Duf1e-00023T-T3; Mon, 18 Jul 2005 19:27:54 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Handling of Unknown DNS Resource Record (RR) Types' to Draft Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Mon, 18 Jul 2005 19:27:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the dnsext WG to consider the following document: - 'Handling of Unknown DNS Resource Record (RR) Types ' RFC 3597 as a Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-11. The file can be obtained via http://www.ietf.org/rfc/rfc3597.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 18 21:42:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duh7U-0004C8-Ng for dnsext-archive@megatron.ietf.org; Mon, 18 Jul 2005 21:42:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07878 for ; Mon, 18 Jul 2005 21:42:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Duh2b-000Gkf-6y for namedroppers-data@psg.com; Tue, 19 Jul 2005 01:37:01 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Duh2Y-000GkF-C7 for namedroppers@ops.ietf.org; Tue, 19 Jul 2005 01:36:58 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id BAA9017F for ; Mon, 18 Jul 2005 21:36:56 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1B1164187 for ; Mon, 18 Jul 2005 21:36:56 -0400 (EDT) Date: Mon, 18 Jul 2005 21:36:56 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Updated nsid draft MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050719013656.1B1164187@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The updated copy of draft-austein-dnsext-nsid that I submitted last week bounced back to me this afternoon with a cover note complaining about the boilerplate. I submitted a fixed copy, but don't know whether it'll be construed as having made the cut or not. Anyway: The new version (complete with new typos) is available at: http://www.hactrn.net/ietf/dns/nsid/draft-austein-dnsext-nsid-02.txt There's also an htmlwdiff against the previous version at: http://www.hactrn.net/ietf/dns/nsid/changes-draft-austein-dnsext-nsid-01-02.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 18 23:06:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuiRM-0003yL-5j for dnsext-archive@megatron.ietf.org; Mon, 18 Jul 2005 23:06:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12215 for ; Mon, 18 Jul 2005 23:06:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DuiOQ-000NV8-Mw for namedroppers-data@psg.com; Tue, 19 Jul 2005 03:03:38 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DuiOO-000NUc-Ss for namedroppers@ops.ietf.org; Tue, 19 Jul 2005 03:03:37 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j6J33EiU018317; Mon, 18 Jul 2005 23:03:17 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Mon, 18 Jul 2005 23:03:33 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Fwd: I-D ACTION:draft-ietf-dnsext-wcard-clarify-08.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is after WG last call comments. I added one section in response to Peter Koch's suggestion to document the rejected "* NS" approaches, that's in section 4.2.1. All other changes ought to be wording only. I plan to add page breaks, but one contributor said that it isn't all that necessary. >Subject: I-D ACTION:draft-ietf-dnsext-wcard-clarify-08.txt >Date: Thu, 07 Jul 2005 15:50:01 -0400 > Title : The Role of Wildcards in the Domain Name System > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-08.txt -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 19 09:51:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DusVm-0006am-Ft for dnsext-archive@megatron.ietf.org; Tue, 19 Jul 2005 09:51:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14678 for ; Tue, 19 Jul 2005 09:51:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DusSq-0008cw-Eo for namedroppers-data@psg.com; Tue, 19 Jul 2005 13:48:52 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DusSp-0008cj-CU for namedroppers@ops.ietf.org; Tue, 19 Jul 2005 13:48:51 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DusSo-000MXu-7A for namedroppers@ops.ietf.org; Tue, 19 Jul 2005 09:48:50 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6JDmm010867 for ; Tue, 19 Jul 2005 06:48:49 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 19 Jul 2005 06:48:48 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: Proposed resolution to LLMNR Issue 86: NITs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Here is a revised resolution: In Section 2.1, change: "LLMNR implementations MUST accept UDP queries and responses as large as the smaller of the link MTU or 8192 octets." To: "LLMNR implementations MUST accept UDP queries and responses as large as the smaller of the link MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 octets for the header, VLAN tag and CRC)." In Section 2.1.1, change: "T Tentative. The 'T'entative bit is set in a response if the responder is authoritative for the name, but has not yet verified the uniqueness of one or more of the resource record(s) in the answer section. A responder MUST ignore the 'T' bit in a query, if set. When a response with the 'T' bit set is received in response to a uniqueness query, a conflict has been detected and a responder MUST resolve the conflict as described in Section 4.1." To: "T Tentative. The 'T'entative bit is set in a response if the responder is authoritative for the name, but has not yet verified the uniqueness of one or more of the resource record(s) in the answer section. A responder MUST ignore the 'T' bit in a query, if set. If a uniqueness query elicits a response with the 'T' bit set, a conflict has been detected and a responder MUST resolve the conflict as described in Section 4.1. Otherwise, a response with the 'T' bit set is silently discarded by the sender." In Section 2.1.1, change: "If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. This will cause the query to be resent using TCP, and allow the inclusion of a non-zero RCODE in the response to the TCP query. Responding with the TC bit set is preferable to not sending a response, since it enables errors to be diagnosed." To: "If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. This will cause the query to be resent using TCP, and allow the inclusion of a non-zero RCODE in the response to the TCP query. Responding with the TC bit set is preferable to not sending a response, since it enables errors to be diagnosed. Errors include those defined in [RFC2845], such as BADSIG(16), BADKEY(17) and BADTIME(18)." In Section 2.3, change: "An SOA RR is synthesized only when a responder has another RR as well; the SOA RR MUST NOT be the only RR that a responder has." To: "An SOA RR is synthesized only when a responder has another RR in addition to an SOA RR; the SOA RR MUST NOT be the only RR that a responder has." In Section 4.1, change: " If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the query." To: " If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received, the sender MUST check if the source address matches the address of any of its interfaces; if so, then the response is not considered a conflict, since it originates from the sender. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the query." On Wed, 13 Jul 2005, Bernard Aboba wrote: > The text of LLMNR Issue 86 is enclosed below. This and other LLMNR Issues > are tracked on the LLMNR web site: > http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > > The proposed resolution is as follows: > > In Section 2.1, change: > > "LLMNR implementations MUST > accept UDP queries and responses as large as the smaller of the link > MTU or 8192 octets." > > To: > > "LLMNR implementations MUST > accept UDP queries and responses as large as the smaller of the link > MTU or 9000 octets." > > In Section 2.1.1, change: > > "T Tentative. The 'T'entative bit is set in a response if the > responder is authoritative for the name, but has not yet verified > the uniqueness of one or more of the resource record(s) in the > answer section. A responder MUST ignore the 'T' bit in a query, if > set. When a response with the 'T' bit set is received in response > to a uniqueness query, a conflict has been detected and a responder > MUST resolve the conflict as described in Section 4.1." > > To: > > "T Tentative. The 'T'entative bit is set in a response if the > responder is authoritative for the name, but has not yet verified > the uniqueness of one or more of the resource record(s) in the > answer section. A responder MUST ignore the 'T' bit in a query, if > set. If a uniqueness query elicits a response with the 'T' bit set, > a conflict has been detected and a responder MUST resolve the conflict > as described in Section 4.1. Otherwise, a response with the 'T' bit > set is silently discarded by the sender." > > In Section 2.1.1, change: > > "If an LLMNR responder is authoritative for the name in a multicast > query, but an error is encountered, the responder SHOULD send an > LLMNR response with an RCODE of zero, no RRs in the answer section, > and the TC bit set. This will cause the query to be resent using > TCP, and allow the inclusion of a non-zero RCODE in the response to > the TCP query. Responding with the TC bit set is preferable to not > sending a response, since it enables errors to be diagnosed." > > To: > > "If an LLMNR responder is authoritative for the name in a multicast > query, but an error is encountered, the responder SHOULD send an > LLMNR response with an RCODE of zero, no RRs in the answer section, > and the TC bit set. This will cause the query to be resent using > TCP, and allow the inclusion of a non-zero RCODE in the response to > the TCP query. Responding with the TC bit set is preferable to not > sending a response, since it enables errors to be diagnosed. Errors > include those defined in [RFC2845], such as BADSIG(16), BADKEY(17) > and BADTIME(18)." > > In Section 2.3, change: > > "An SOA RR is synthesized only when a > responder has another RR as well; the SOA RR MUST NOT be the only RR > that a responder has." > > To: > > "An SOA RR is synthesized only when a > responder has another RR in addition to an SOA RR; > the SOA RR MUST NOT be the only RR > that a responder has." > > In Section 4.1, change: > > " If no response is received, the sender retransmits the query, as > specified in Section 2.7. If a response is received with the 'T' bit > clear, the responder MUST NOT use the name in response to LLMNR > queries received over any protocol (IPv4 or IPv6). If a response is > received with the 'T' bit set, the responder MUST check if the source > IP address in the response, interpreted as an unsigned integer, is > less than the source IP address in the query." > > To: > > " If no response is received, the sender retransmits the query, as > specified in Section 2.7. If a response is received, the sender > MUST check if the source address matches the address of any of its > interfaces; if so, then the response is not considered a conflict, > since it originates from the sender. > > If a response is received with the 'T' bit clear, the responder > MUST NOT use the name in response to LLMNR queries > received over any protocol (IPv4 or IPv6). If a response is > received with the 'T' bit set, the responder MUST check if the source > IP address in the response, interpreted as an unsigned integer, is > less than the source IP address in the query." > > ----------------------------------------------------------------------------------- > Issue 86: NITs > Submitter: Stuart Cheshire > Submitter email address: cheshire@apple.com > Date first submitted: May 25, 2005 > Reference: > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html > Document: LLMNR-40 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > Some other general comments and questions: > > LLMNR implementations MUST > accept UDP queries and responses as large as the smaller of the link > MTU or 8192 octets. > > I suggest 9000 bytes, the Ethernet jumbo frame size, as a natural packet > size to pick. Allowing 40 bytes for IPv6 header and 8 for UDP header, > that leaves 8952 for the DNS message, which allows for an 8K resource > record to be carried (should such a thing ever be needed in future). > > [BA] OK. > > T Tentative. The 'T'entative bit is set in a response if the > responder is authoritative for the name, but has not yet verified > the uniqueness of one or more of the resource record(s) in the > answer section. A responder MUST ignore the 'T' bit in a query, if > set. When a response with the 'T' bit set is received in response > to a uniqueness query, a conflict has been detected and a responder > MUST resolve the conflict as described in Section 4.1. > > The document says nothing about how response with the 'T' bit set are to > be interpreted by senders. Should they be ignored, or used in answer to > the question? > > [BA] If a sender receives a response to a normal query with the 'T' bit > set, the response is ignored. > > If an LLMNR responder is authoritative for the name in a multicast > query, but an error is encountered, the responder SHOULD send an > LLMNR response with an RCODE of zero, no RRs in the answer section, > and the TC bit set. > > What kind of error is this anticipating? Either the responder knows the > answer, or it does not. Some example of a plausible error would motivate > this section. > > [BA] Examples include error codes sent in response to TSIG queries. > Upon configuring an IP address, responders typically will synthesize > corresponding A, AAAA and PTR RRs so as to be able to respond to > LLMNR queries for these RRs. An SOA RR is synthesized only when a > responder has another RR as well > > Another RR in addition to A, AAAA and PTR? > > [BA] Another RR in addition to SOA. > If no response is received, the sender retransmits the query, as > specified in Section 2.7. If a response is received with the 'T' bit > clear, the responder MUST NOT use the name in response to LLMNR > queries received over any protocol (IPv4 or IPv6). If a response is > received with the 'T' bit set, the responder MUST check if the source > IP address in the response, interpreted as an unsigned integer, is > less than the source IP address in the query. > > This suffers from auto-immune response, in the case where a machine has > both Ethernet and wireless connections, and (unknown to the machine) the > Ethernet and wireless networks are bridged together. > > [BA] Right. The check need only be done if the source address is > different than the address of one of the host's interfaces. > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 19 09:51:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DusVn-0006bH-AM for dnsext-archive@megatron.ietf.org; Tue, 19 Jul 2005 09:51:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14681 for ; Tue, 19 Jul 2005 09:51:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DusRA-0008S6-MX for namedroppers-data@psg.com; Tue, 19 Jul 2005 13:47:08 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DusR7-0008RS-8I for namedroppers@ops.ietf.org; Tue, 19 Jul 2005 13:47:05 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DusR6-000M2z-0s for namedroppers@ops.ietf.org; Tue, 19 Jul 2005 09:47:04 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6JDl2310744 for ; Tue, 19 Jul 2005 06:47:02 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 19 Jul 2005 06:47:01 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: Proposed Resolution of LLMNR Issue 85: General Comments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Here are additional changes made to resolve this issue: Change the abstract to: "The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS." In Section 1, change: " This document discusses Link Local Multicast Name Resolution (LLMNR), which utilizes the DNS packet format and supports all current and future DNS formats, types and classes. LLMNR operates on a separate port from the Domain Name System (DNS), with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. These include scenarios in which hosts are not configured with the address of a DNS server, where configured DNS servers do not reply to a query, or where they respond with errors, as described in Section 2. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS." To: "This document discusses Link Local Multicast Name Resolution (LLMNR), which is based on the DNS packet format and supports all current and future DNS formats, types and classes. LLMNR operates on a separate port from the Domain Name System (DNS), with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Usage scenarios (discussed in more detail in Section 3.1) include situations in which hosts are not configured with the address of a DNS server; where the DNS server is unavailable or unreachable; where there is no DNS server authoritative for the name of a host, or where the authoritative DNS server does not have the desired RRs, as described in Section 2." Move the following sentence from Section 2 to Section 1: "IPv4 administratively scoped multicast usage is specified in "Administratively Scoped IP Multicast" [RFC2365]." On Fri, 15 Jul 2005, Bernard Aboba wrote: > The text of LLMNR Issue 85 is enclosed below. This and other LLMNR issues > are tracked on the LLMNR issues page: > http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > > The proposed resolution is as follows: > > Move the following sentence from Section 2 to Section 1: > > "IPv4 administratively scoped multicast usage is specified in > "Administratively Scoped IP Multicast" [RFC2365]." > > In Section 2.5, change: > > "2.5. "Off link" Detection > > For IPv4, an "on link" address is defined as a link-local address > [IPv4Link] or an address whose prefix belongs to a subnet on the > local link. For IPv6 [RFC2460] an "on link" address is either a > link-local address, defined in [RFC2373], or one belonging to a > prefix that a Router Advertisement indicates is on-link [RFC2461]. > > A sender MUST select a source address for LLMNR queries that is "on > link". The destination address of an LLMNR query MUST be a link- > scope multicast address or an "on link" unicast address. > > A responder MUST select a source address for responses that is "on > link". The destination address of an LLMNR response MUST be an "on > link" unicast address." > > To: > > "2.5. "Off link" Detection > > A sender MUST select a source address for LLMNR queries that is > assigned on the interface on which the query is sent. The destination > address of an LLMNR query MUST be a link-scope multicast address or a > unicast address. > > A responder MUST select a source address for responses that is assigned > on the interface on which the query was received. The destination > address of an LLMNR response MUST be a unicast address." > > Add the following sentence to Section 2.6: > > "IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 > Link-Local addresses are defined in [RFC2373]." > > Delete references to [RFC2460] and [RFC2461]. > > ---------------------------------------------------------------------------- > Issue 85: General Comments > Submitter: Stuart Cheshire > Submitter email address: cheshire@apple.com > Date first submitted: May 25, 2005 > Reference: > Document: LLMNR-40 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > > Reading draft-ietf-dnsext-mdns-40.txt, the problem I ran into was trying > to understand what problem it is trying to solve. The abstract states > that it is for "ad-hoc networks operating without a Domain Name System > (DNS) server." Superficially that sounds all well and good, but what does > it really mean? When it says, "DNS server", does it mean "authoritative > name server", or "recursive name server"? The document needs to say > clearly which it is talking about, because they are very different > problems. One scenario is a device that has a name, but no authoritative > server to answer for that name. The other is a resolver client that wants > to look up a name, but has no recursive server to ask. > > There are several problems I can imagine this document *might* be trying > to solve: > > 1. A device that has a conventionally allocated, properly delegated, > fully-qualified domain name, but there is no (authoritative) name server > to answer for that name. > > 2. A device that has *no* conventionally allocated, properly delegated, > fully-qualified domain name, because the user doesn't know how to do > that, or doesn't want to pay the annual fee to register a domain, or > simply because the device has just shipped from the factory, and doesn't > even have a human owner yet to go through the steps of allocating and > assigning a unique FQDN for it. > > 3. A client that wants to look up a host name, but there is no > authoritative name server for that name. > > 4. A client that wants to look up a host name, but there is no recursive > name server available for the client to talk to. > > 5. A client that wants to look up a host name, and there is an > authoritative name server for that name, but for whatever reason it's not > responding right now. > > These are all very different scenarios, and the document needs to state > clearly which, if any (or all) of them it is addressing. Right now > reading the document feels a bit like playing the shell game, where you > try (usually unsuccessfully) to keep track of which shell has the pea > underneath as they slide around. Reading the document, I kept finding > things that didn't work for one or more of the above scenarios, but it > wasn't clear if that was a problem because it wasn't clear if the > document was seeking to solve that particular problem. > > [BA] A host implementing IPv6 may require LLMNR for name > resolution in each of the scenarios you describe. For > example, an IPv6-only host may not have a DNS server > configured, or it may have an anycast DNS server address > configured, but there is no server present listening on > that address that is reachable from the hosts's location. > > There is also an additional scenario not listed, which > is that a host may have an authoritative name server > which may not answer for all RR types. For example, > a home gateway may have a DNS server built-in which > may support DDNS via DHCPv4. However, the DNS > server may only answer with A RRs, not AAAA RRs, and > it may not answer queries over IPv6. > > Scenario 1 cannot necessarily be distinguished > from Scenario 5, or even Scenario 4. For example, with IPv6, > anycast addresses can be configured for DNS servers, so that a DNS > server address can be configured but there is no DNS server > listening on the anycast address. Also, it is possible that > a DNS server may have been configured, but the host has moved to > an adhoc network where that server is no longer reachable. > > Perhaps if you would provide a list of things that you found > that didn't work, then we could better address the issue. > For example, a host configured to have computer name "host1" and to > be a member of the "example.com" domain, and with IPv4 address > 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be > authoritative for the following records: > > host1. IN A 192.0.2.1 > IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 > > This seems to be the most egregious pollution of the top level of the DNS > namespace. If I call my television "tv.myhouse.", then that means it > answers for the name "tv." How does that coexist with the global DNS > records for Tuvalu? > > [BA] Since there is no concept of delegation in LLMNR, configuring > a host to answer LLMNR queries for "tv.myhouse" or even "tv" will > not cause a responder to answer queries for "foo.tv" or any other name > within > the tv TLD. > > 2.5. "Off link" Detection > > For IPv4, an "on link" address is defined as a link-local address > [IPv4Link] or an address whose prefix belongs to a subnet on the > local link. > > How does a given device *know* what subnets are on the local link? To > know this, a device has to have perfectly accurate configuration > information, but the whole point of LLMNR is for scenarios where > configuration infrastructure has failed, and the device is left to fend > for itself as best it can. To be useful, the device has to be able to > operate even if some or all of its configuration information is wrong. > > [BA] Section 2.5 should only relate to what source addresses a host > can use in responding to an LLMNR query. However, there are also two > instances where it also talks about whether a destination address > is "on link". By removing those two instances we can remove the > need for the host to know what prefixes are on the link, and only > depend on its knowing what addresses have been assigned on which > interfaces. > > Section 2.4 discusses use of TCP for LLMNR queries and responses. In > composing an LLMNR query using TCP, the sender MUST set the Hop Limit > field in the IPv6 header and the TTL field in the IPv4 header of the > response to one (1). The responder SHOULD set the TTL or Hop Limit > settings on the TCP listen socket to one (1) so that SYN-ACK packets > will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This > prevents an incoming connection from off-link since the sender will > not receive a SYN-ACK from the responder. > > A common enterprise configuration is to have two or more IP subnets > overlayed on the same physical link. (You can argue that this is > misconfiguration, but it is still common.) This means that two laptops > sitting next to each other on the same Ethernet hub can be apparently two > hops from each other. Setting the TTL to 1 means that half of the LAN > becomes unreachable from the other half. > Also, how does this interact with multi-link subnets? > > [BA] In this scenario, the router could send an ICMP redirect > if it wanted the host to treat the other subnet as local. It > is also possible that the router would include a built-in DNS > server so that LLMNR would not be necessary. > > With respect to "multi-link" subnets, some instances of these > do not decrement TTL and others (MANET) do. In those that do, > my understanding is that LLMNR queries will not propagate > beyond the link scope either. > > Since DNS PTR queries frequently fail, applications need > to be prepared for this. So using TCP and setting > the TTL field to 1 for PTR RR queries shouldn't have much > negative impact. > > For UDP queries and responses, the Hop Limit field in the IPv6 header > and the TTL field in the IPV4 header MAY be set to any value. > However, it is RECOMMENDED that the value 255 be used for > compatibility with Apple Bonjour [Bonjour]. > > Has this compatibility been tested? I don't have access to any LLMNR > implementation. (I don't even know if there are any LLMNR > implementations). Windows users can easily test this by just downloaded > Bonjour for Windows. > > > > If one of the LLMNR supporters could try it, that would be very useful > information. > > [BA] To my knowledge compatibility has not been tested. Since > you submitted the original comment that lead to the incorporation > of this text, can you suggest something more appropriate? > > IPv4 administratively scoped multicast usage is specified > in "Administratively Scoped IP Multicast" [RFC2365]. > > Does LLMNR use Administratively Scoped IP Multicast? > > The IPv4 link- > scope multicast address a given responder listens to, and to which a > sender sends queries, is 224.0.0.252. > > Why this address? My mDNS protocol uses link-local address 224.0.0.251 > for consistency with Administratively Scoped Multicast addresses, which > are allocated from the top down. 239.x.x.251 was the Administratively > Scoped address group originally allocated for mDNS; for consistency I > picked 224.0.0.251 as its link-local counterpart. The Administratively > Scoped address group 239.x.x.252 is allocated for MZAP, which does not > (as far as I know) have anything to do with LLMNR. > > [BA] 224.0.0.252 was the address assigned by IANA. The "252" has no > broader significance. LLMNR does not use Administratively Scoped IP > Multicast. > > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 19 15:54:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuyAN-00043I-PI for dnsext-archive@megatron.ietf.org; Tue, 19 Jul 2005 15:54:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28586 for ; Tue, 19 Jul 2005 15:54:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Duy78-000OFN-T6 for namedroppers-data@psg.com; Tue, 19 Jul 2005 19:50:50 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Duy78-000OEz-72 for namedroppers@ops.ietf.org; Tue, 19 Jul 2005 19:50:50 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Duy6N-0002NP-9N; Tue, 19 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2536bis-dsa-06.txt Message-Id: Date: Tue, 19 Jul 2005 15:50:03 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DSA Keying and Signature Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2536bis-dsa-06.txt Pages : 8 Date : 2005-7-19 The standard method of encoding US Government Digital Signature Algorithm keying and signature information for use in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2536bis-dsa-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19130349.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2536bis-dsa-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19130349.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 19 15:54:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuyAW-0004CH-9v for dnsext-archive@megatron.ietf.org; Tue, 19 Jul 2005 15:54:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28639 for ; Tue, 19 Jul 2005 15:54:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Duy6Y-000OAc-Ml for namedroppers-data@psg.com; Tue, 19 Jul 2005 19:50:14 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Duy6Y-000OAO-2H for namedroppers@ops.ietf.org; Tue, 19 Jul 2005 19:50:14 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Duy6N-0002NY-BW; Tue, 19 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2539bis-dhk-06.txt Message-Id: Date: Tue, 19 Jul 2005 15:50:03 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Storage of Diffie-Hellman Keying Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2539bis-dhk-06.txt Pages : 10 Date : 2005-7-19 The standard method for encoding Diffie-Hellman keys in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2539bis-dhk-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19130533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2539bis-dhk-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19130533.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 19 15:54:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuyAY-0004Cz-UZ for dnsext-archive@megatron.ietf.org; Tue, 19 Jul 2005 15:54:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28675 for ; Tue, 19 Jul 2005 15:54:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Duy7v-000OKO-6d for namedroppers-data@psg.com; Tue, 19 Jul 2005 19:51:39 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Duy7u-000OK4-Hw for namedroppers@ops.ietf.org; Tue, 19 Jul 2005 19:51:38 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Duy6N-0002NF-7E; Tue, 19 Jul 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-07.txt Message-Id: Date: Tue, 19 Jul 2005 15:50:03 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Elliptic Curve KEYs in the DNS Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-07.txt Pages : 16 Date : 2005-7-19 The standard method for storing elliptic curve cryptographic keys and signatures in the Domain Name System is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ecc-key-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ecc-key-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19130054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19130054.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 20 12:39:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHbM-0004Yo-Hg for dnsext-archive@megatron.ietf.org; Wed, 20 Jul 2005 12:39:21 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07544 for ; Wed, 20 Jul 2005 12:39:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvHX9-000Kyq-TE for namedroppers-data@psg.com; Wed, 20 Jul 2005 16:34:59 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DvHX6-000KyU-2g for namedroppers@ops.ietf.org; Wed, 20 Jul 2005 16:34:56 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DvHX4-000HU0-Ia for namedroppers@ops.ietf.org; Wed, 20 Jul 2005 12:34:55 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6KGYrQ12630 for ; Wed, 20 Jul 2005 09:34:53 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 20 Jul 2005 09:34:53 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 93: Extensibility Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 93: Extensibility Submitter: Markku Savela Submitter email address: msa@burp.tkv.asdf.org Date first submitted: July 20, 2005 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00852.html Document: LLMNR-41 Comment type: T Priority: S Section: 2.1.1, 6 Rationale/Explanation of issue: LLMNR assigns meaning to two bits in DNS message. Wasn't there a discussion about IANA and assigning bits in DNS message a while back in namedroppers list? LLMNR is just reusing the format, but will it be a problem if some future DNS (or already existing) uses the same bits for something else, perhaps something that could also be useful in LLMNR? [Bernard Aboba] The thread (referenced above) talks about parameter assignment. IANA assignments are described here: [1] http://www.iana.org/assignments/dns-header-flags [2] http://www.iana.org/assignments/dns-parameters [3] http://www.iana.org/assignments/dnskey-flags Here is the DNS header format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Here is the LLMNR header format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Therefore the AA bit and RD bits are being reused. LLMNR will never need the AA bit since responders only answer queries for which they are authoritative. Similarly, LLMNR will never need the "Recursion Desired" bit, since there is no concept of recursion in LLMNR. There is one "Reserved" bit left in DNS, which is also "Reserved" in LLMNR. So assuming that this bit is eventually used in DNS, it can also be used in LLMNR, assuming that the usage would make sense. Note that LLMNR also supports EDNS, which has additional reserved bits. EDNS Header Flags (16 bits) per [RFC2671] ----------------------------------------- Bit 0 DO DNSSEC answer OK [RFC3225], [RFC4035] Bit 1-15 Reserved Here is what Section 6 (IANA considerations) says about allocation of LLMNR header bits: "This specification creates one new name space: the reserved bits in the LLMNR header. These are allocated by IETF Consensus, in accordance with BCP 26 [RFC2434]." I don't think we necessarily want to automatically allocate LLMNR header bits based on DNS header changes, so this seems like the best we can do. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 20 15:54:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKeX-0007vt-1W for dnsext-archive@megatron.ietf.org; Wed, 20 Jul 2005 15:54:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26178 for ; Wed, 20 Jul 2005 15:54:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvKbS-000C5u-Of for namedroppers-data@psg.com; Wed, 20 Jul 2005 19:51:38 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DvKbS-000C5d-2y for namedroppers@ops.ietf.org; Wed, 20 Jul 2005 19:51:38 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZw-0007oM-EC; Wed, 20 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-experiments-01.txt Message-Id: Date: Wed, 20 Jul 2005 15:50:04 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC Experiments Author(s) : D. Blacka Filename : draft-ietf-dnsext-dnssec-experiments-01.txt Pages : 14 Date : 2005-7-20 In the long history of the development of the DNS security extensions [1] (DNSSEC), a number of alternate methodologies and modifications have been proposed and rejected for practical, rather than strictly technical, reasons. There is a desire to be able to experiment with these alternate methods in the public DNS. This document describes a methodology for deploying alternate, non-backwards-compatible, DNSSEC methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-experiments-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-experiments-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-20145414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-experiments-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-experiments-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20145414.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 20 16:59:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvLfE-0000xP-Gn for dnsext-archive@megatron.ietf.org; Wed, 20 Jul 2005 16:59:36 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22289 for ; Wed, 20 Jul 2005 16:59:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvLcE-000IOH-GJ for namedroppers-data@psg.com; Wed, 20 Jul 2005 20:56:30 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DvLcD-000INp-2A for namedroppers@ops.ietf.org; Wed, 20 Jul 2005 20:56:29 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZw-0007oX-G1; Wed, 20 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-07.txt Message-Id: Date: Wed, 20 Jul 2005 15:50:04 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC Opt-In Author(s) : D. Blacka, et al. Filename : draft-ietf-dnsext-dnssec-opt-in-07.txt Pages : 17 Date : 2005-7-20 In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC 4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-opt-in-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-20145555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-opt-in-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20145555.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 20 18:52:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNQh-0004dY-S6 for dnsext-archive@megatron.ietf.org; Wed, 20 Jul 2005 18:52:43 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05838 for ; Wed, 20 Jul 2005 18:52:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvNOA-0002oj-MF for namedroppers-data@psg.com; Wed, 20 Jul 2005 22:50:06 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DvNOA-0002o9-0m for namedroppers@ops.ietf.org; Wed, 20 Jul 2005 22:50:06 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvNO6-0001v7-1g; Wed, 20 Jul 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-insensitive-06.txt Message-Id: Date: Wed, 20 Jul 2005 18:50:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-06.txt Pages : 13 Date : 2005-7-20 Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034 and 1035. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-insensitive-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-insensitive-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-20160730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-insensitive-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-insensitive-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20160730.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 21 15:42:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvgwH-0005qd-GY for dnsext-archive@megatron.ietf.org; Thu, 21 Jul 2005 15:42:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02930 for ; Thu, 21 Jul 2005 15:42:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DvgqA-0008Iq-Dt for namedroppers-data@psg.com; Thu, 21 Jul 2005 19:36:18 +0000 Received: from [144.189.100.103] (helo=motgate3.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dvgq9-0008Ia-Gl for namedroppers@ops.ietf.org; Thu, 21 Jul 2005 19:36:17 +0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j6LJmanE027356 for ; Thu, 21 Jul 2005 12:48:37 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j6LJfVUN022588 for ; Thu, 21 Jul 2005 14:41:31 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Jul 2005 15:36:10 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF23810A1FCCCE@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-dnsext-insensitive-06.txt Date: Thu, 21 Jul 2005 15:36:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, This draft revision is intended to respond to IESG comments. (You can find these comments via the ID Tracker https://datatracker.ietf.org/public/pidtracker.cgi.) I consider the most significant IESG comment to be that related to label case insensitivity in new CLASSes. I believe that it was always intended that classic labels be case insensitive for all CLASSes. This is essential for a recursive server to handle unknown CLASSes, for example. If you want labels that act differently, for example to be case sensitive, I think you need to define a new label type, whether these hypothetical new labels are being used in a new CLASS or an existing CLASS. There was also some confusion among some IESG members concerning the part of the draft where the draft pointed out that if you "input" names with inconsistent case, a server can keep the case of the first input or let later input override the case or keep inconsistent case internally. But "input" in this instance means loading from a master file or dynamic update or the like. Some IESG members seem to have interpreted "input" as also including queries and somehow believed that I was saying you might get case dependent partial RR sets in your answer, exactly the opposite of "case insensitivity". I've tried to be much clearer in this version. There are also some minor changes. See appendix in the drafts. Thanks, Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, July 20, 2005 6:50 PM To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-insensitive-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-06.txt Pages : 13 Date : 2005-7-20 Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034 and 1035. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-insensitive-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-insensitive-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 23 12:25:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwMoV-0001nM-6a for dnsext-archive@megatron.ietf.org; Sat, 23 Jul 2005 12:25:23 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06560 for ; Sat, 23 Jul 2005 12:25:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DwMi2-000FGd-Gt for namedroppers-data@psg.com; Sat, 23 Jul 2005 16:18:42 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DwMi0-000FGQ-L7 for namedroppers@ops.ietf.org; Sat, 23 Jul 2005 16:18:40 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j6NGEYBO008668 for ; Sat, 23 Jul 2005 12:14:34 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0Eaq7q; Sat, 23 Jul 05 12:14:31 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j6NGGTd0005763 for ; Sat, 23 Jul 2005 12:16:29 -0400 (EDT) Date: Sat, 23 Jul 2005 12:16:29 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: comments on nsec3-02 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Having compared nsec3-02 to -01, I only found a few substantive changes. If I've missed any, I hope someone will point them out. The ones I spotted were: -- resolver instructions WRT wildcards, in 6.2 -- identity hash number allocated, in 8 (but not described anywhere) -- truncation signaling method, last paragraph of 6.4.3 Everything else I saw was editorial (perhaps important, but not changing the protocol in any way). Again, if I missed something, please let me know. I'm most concerned by a couple of missing pieces, and I'll send a separate message suggesting a way forward for each: -- the lack of specification of a signaling mechanism for indicating that NSEC3, rather than NSEC, is in use. I think we agreed this could be deferred, but the selection is necessary for implementation to go forward. -- the lack of clarity re: which hash algorithms are required/mandatory and/or a way to signal which may be in use in a given zone, which may be needed to prevent a downgrade attack. (Or drop to a single algorithm, and remove the field.) I remember discussing the above at some length on the list, and I think we concluded that we'd require a set of mandatory algorithms (maybe even just one) and anything outside that list would be treated as a protocol violation. Unfortunately, this draft still has an IANA registry for these numbers (and still doesn't specify an assignment policy), which suggests that new algorithms might be added later -- we need to tighten this up. http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00492.html http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00581.html And, lastly, I'm surprised by: -- the continued inclusion of opt-in (the authoritative-only bit). I haven't gone through the doc with a fine-toothed comb yet. I'll send more detailed comments later. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 23 12:46:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwN8d-0000Ml-F8 for dnsext-archive@megatron.ietf.org; Sat, 23 Jul 2005 12:46:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07575 for ; Sat, 23 Jul 2005 12:46:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DwN67-000Gus-9n for namedroppers-data@psg.com; Sat, 23 Jul 2005 16:43:35 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DwN65-000Gue-J7 for namedroppers@ops.ietf.org; Sat, 23 Jul 2005 16:43:33 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j6NGdNB0010447 for ; Sat, 23 Jul 2005 12:39:25 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA01ayru; Sat, 23 Jul 05 12:39:11 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j6NGf99o006225 for ; Sat, 23 Jul 2005 12:41:09 -0400 (EDT) Date: Sat, 23 Jul 2005 12:41:09 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: NSEC3 signalling mechanism In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 23 Jul 2005, Samuel Weiler wrote: > -- the lack of specification of a signaling mechanism for indicating > that NSEC3, rather than NSEC, is in use. I think we agreed this > could be deferred, but the selection is necessary for > implementation to go forward. > > -- the lack of clarity re: which hash algorithms are > required/mandatory and/or a way to signal which may be in use in > a given zone, which may be needed to prevent a downgrade attack. > (Or drop to a single algorithm, and remove the field.) dnssec-trans-02 recommends a partial typecode roll, rolling the NSEC and DS types as well as the DNSSEC-OK bit. As I recall the joy of finding a new protocol bug every two months in late 2002 with DS, I find myself longing for something else. I propose: We use the DS message digest number field for signaling BOTH: 1) that NSEC3 is in use in the child zone, and 2) which SINGLE hash algorithm is used by those NSEC3 RRs. This requires a new DS message digest assignment (in a Standards Action registry), whether using SHA-1, as before, or something new. It also depends on resolvers treating DS's with unknown digest algorithms as they would DS's with unknown public key algorithms, which is not described in 4035, but is described in bis-updates section 3.1. We could also then remove the NSEC3 hash algorithm field along with the need to have rules for handling unknown values in that field. Simiplicity is a good thing. It also removes the need for a new IANA registry. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 25 10:05:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3Zm-0002Bs-Ub for dnsext-archive@megatron.ietf.org; Mon, 25 Jul 2005 10:05:03 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21846 for ; Mon, 25 Jul 2005 10:05:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dx3Tl-0000rh-1m for namedroppers-data@psg.com; Mon, 25 Jul 2005 13:58:49 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dx3Tj-0000rK-78 for namedroppers@ops.ietf.org; Mon, 25 Jul 2005 13:58:47 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j6PDwgOJ066248 for ; Mon, 25 Jul 2005 09:58:43 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.3.4.2.20050725094647.02d10e90@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 25 Jul 2005 09:58:41 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Namedroppers moderation update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Due to overlapping vacation schedules of both DNSEXT chairs/moderators in August, the chairs have appointed Edward Lewis as a list moderator for that month. Olafur and Olaf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 25 13:16:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6Yn-0004Vl-Np for dnsext-archive@megatron.ietf.org; Mon, 25 Jul 2005 13:16:13 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08256 for ; Mon, 25 Jul 2005 13:16:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dx6VC-000Jqk-6m for namedroppers-data@psg.com; Mon, 25 Jul 2005 17:12:30 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dx6VA-000JqI-CU for namedroppers@ops.ietf.org; Mon, 25 Jul 2005 17:12:28 +0000 Received: from [10.31.32.145] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j6PHCFRY066995; Mon, 25 Jul 2005 13:12:16 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.1.2.2.20050712093437.03bd4d30@localhost> References: <87br59dj3z.fsf@deneb.enyo.de> <6.2.1.2.2.20050712093437.03bd4d30@localhost> Date: Mon, 25 Jul 2005 13:12:16 -0400 To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT__co=2Dchair?= From: Edward Lewis Subject: Re: Randomness requirements for message ID generation Cc: Florian Weimer , namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 10:56 -0400 7/12/05, =D3lafur Gu=F0mundsson /DNSEXT co-chair wrote: >Good randomness should be used by all DNS resolvers on query ID. During some recent testing, I looked at the=20 message ID's used by a popular and recent release=20 of DNS software. Over the time period I looked,=20 some id numbers were used 6 times, a lot of the=20 numbers were not. Not all that random - without loss of=20 functionality. Although not random, the id=20 numbers were somewhat unpredictable. Well, come=20 to think of it, no single id number ever had two=20 simultaneously outstanding requests. It's=20 certainly not random, and you can predict that a=20 number won't appear if it's outstanding. I know that this is a dead issue in the WG=20 (fortunately), but I had some real data to throw=20 in. And I wanted to kill once and for all the=20 notion that the message id had to be "random." -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 25 13:40:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6wG-0000jj-SD for dnsext-archive@megatron.ietf.org; Mon, 25 Jul 2005 13:40:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09515 for ; Mon, 25 Jul 2005 13:40:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dx6tV-000Lrw-FM for namedroppers-data@psg.com; Mon, 25 Jul 2005 17:37:37 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dx6tQ-000LrV-QX for namedroppers@ops.ietf.org; Mon, 25 Jul 2005 17:37:32 +0000 Received: from [81.200.65.83] (terminus.ddns.nominum.com [81.200.65.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 4B36E568B9; Mon, 25 Jul 2005 10:37:32 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: References: <87br59dj3z.fsf@deneb.enyo.de> <6.2.1.2.2.20050712093437.03bd4d30@localhost> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FFB6A3E-B46C-4D41-BFE3-BDFB0823949A@nominum.com> Cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT__co-chair?= , Florian Weimer , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: Randomness requirements for message ID generation Date: Mon, 25 Jul 2005 10:37:29 -0700 To: Edward Lewis X-Mailer: Apple Mail (2.733) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jul 25, 2005, at 10:12 AM, Edward Lewis wrote: >> Good randomness should be used by all DNS resolvers on query ID. ... > I know that this is a dead issue in the WG (fortunately), but I had > some real data to throw in. And I wanted to kill once and for all > the notion that the message id had to be "random." Hmm. Perhaps this has been mentioned: http://madchat.org/reseau/tcp-ip/tcpip-seqnb/#otherp In terms of specification, I believe having query ids be as random as possible should be a MUST. Anything else increases the likelihood of spoofability. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 25 14:07:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7M3-0006Ek-0g for dnsext-archive@megatron.ietf.org; Mon, 25 Jul 2005 14:07:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11357 for ; Mon, 25 Jul 2005 14:07:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dx7IV-000OLI-42 for namedroppers-data@psg.com; Mon, 25 Jul 2005 18:03:27 +0000 Received: from [66.119.143.51] (helo=mail.rfburst.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dx7IT-000OKo-93 for namedroppers@ops.ietf.org; Mon, 25 Jul 2005 18:03:25 +0000 Received: from localhost.localdomain (rfb.rfburst.com [66.119.143.249]) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id j6PI32ac016553; Mon, 25 Jul 2005 12:03:03 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id j6PI2YWc012310; Mon, 25 Jul 2005 12:02:34 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id j6PI2YMe012306; Mon, 25 Jul 2005 12:02:34 -0600 Date: Mon, 25 Jul 2005 12:02:34 -0600 Message-Id: <200507251802.j6PI2YMe012306@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: Ed.Lewis@neustar.biz Cc: namedroppers@ops.ietf.org In-reply-to: Yourmessage Subject: Re: Randomness requirements for message ID generation X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > some id numbers were used 6 times, a lot of the > numbers were not. That's consistent with randomness. You should mention the sample size, though. It couldn't have been more than 6*2^16, for example. The restriction to choose from the set of unused numbers should be mentioned explicitly in requirements ("drawing without replacement"), that will smooth out the distribution as the number of ids in use at any given time increases. Hilarie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From WendyThurman@wwwmotorcycle-superstore.com Mon Jul 25 14:55:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx86Q-0007LL-63 for dnsext-archive@megatron.ietf.org; Mon, 25 Jul 2005 14:55:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14161 for ; Mon, 25 Jul 2005 14:54:58 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx8bG-0004cm-5u for dnsext-archive@ietf.org; Mon, 25 Jul 2005 15:26:56 -0400 Received: from 159.234.97-84.rev.gaoland.net ([84.97.234.159]) by mx2.foretec.com with smtp (Exim 4.24) id 1Dx86D-0003hz-1X for dnsext-archive@ietf.org; Mon, 25 Jul 2005 14:54:49 -0400 Received: from IWu@localhost by T5m.int (8.11.6/8.11.6); Mon, 25 Jul 2005 18:24:54 -0200 Message-ID: <6jNvEbEyOVFH4DHVA164MMX@peripeteia.net> From: "Roxanne Akers" Reply-To: "Roxanne Akers" To: dnsext-archive@ietf.org Subject: Thousands of academic software titles, 80 % 0ff Date: Tue, 26 Jul 2005 01:27:54 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: WendyThurman@wwwmotorcycle-superstore.com Content-Type: multipart/mixed; boundary="--ms0sRQXKRJSfxUx" X-Spam-Score: 0.2 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 qirC ----ms0sRQXKRJSfxUx Content-Type: text/html; Content-Transfer-Encoding: quoted-printable g
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: XcHJD2j7
 

Sales R= ank: #1
System requirements  |  Other Versions
Date Coupon Expires:<= /b> August 31st, 2005
Average Customer Re= view:3D"5 Based on 16878 reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 <= /td>

<= img height=3D150 src=3Dhttp://images.amazon.com/images/P/B00081I6JI.01._PE= 7_SCMZZZZZZZ_.jpg width=3D144 align=3Dleft border=3D0 name=3Dprod_image>

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: 4CmTIn
 

Sales Rank: #2
System requirements  = |  Other Versions
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"= Based on 132552= reviews. Write a review.

=
Microsoft Windows XP Professional or Longhorn Edition=
Microsoft

Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)



Ava= ilability: Available for INSTANT download!
Coupon Code: GSJ= V1Rp
 

Sales Rank: #3
System requir= ements  |  Other Versions<= /a>
Date Coupon Expires: August 31st,= 2005
Average Customer Review:3D"5 Based on 1143 reviews. Write a review<= /a>.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: CUHcufDND
 = ;

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 18243= reviews. Write a review.

=

<= /form> ----ms0sRQXKRJSfxUx-- From owner-namedroppers@ops.ietf.org Mon Jul 25 15:03:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8Ez-0000Ro-Fn for dnsext-archive@megatron.ietf.org; Mon, 25 Jul 2005 15:03:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14839 for ; Mon, 25 Jul 2005 15:03:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dx8Bf-0003EU-EZ for namedroppers-data@psg.com; Mon, 25 Jul 2005 19:00:27 +0000 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dx8BY-0003DT-Ir for namedroppers@ops.ietf.org; Mon, 25 Jul 2005 19:00:20 +0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j6PJ9mFZ020899 for ; Mon, 25 Jul 2005 12:09:48 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j6PJ6eja003747 for ; Mon, 25 Jul 2005 14:06:41 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Jul 2005 15:00:18 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF23810A2B2C1A@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: Randomness requirements for message ID generation Date: Mon, 25 Jul 2005 15:00:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I can't see the justification for a MUST. A SHOULD would be reasonable = as it would mean that you need a good justification to do anything = else. If you want secure DNS transactions you have to use TSIG or SIG(0).=20 Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org = [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of David Conrad Sent: Monday, July 25, 2005 1:37 PM To: Edward Lewis Cc: =D3lafur Gu=F0mundsson /DNSEXT co-chair; Florian Weimer; = namedroppers@ops.ietf.org Subject: Re: Randomness requirements for message ID generation On Jul 25, 2005, at 10:12 AM, Edward Lewis wrote: >> Good randomness should be used by all DNS resolvers on query ID. ... > I know that this is a dead issue in the WG (fortunately), but I had=20 > some real data to throw in. And I wanted to kill once and for all = the=20 > notion that the message id had to be "random." Hmm. Perhaps this has been mentioned: http://madchat.org/reseau/tcp-ip/tcpip-seqnb/#otherp In terms of specification, I believe having query ids be as random as = possible should be a MUST. Anything else increases the likelihood of = spoofability. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 25 19:07:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxC31-0005UR-E1 for dnsext-archive@megatron.ietf.org; Mon, 25 Jul 2005 19:07:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05554 for ; Mon, 25 Jul 2005 19:07:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxByM-000Ok3-03 for namedroppers-data@psg.com; Mon, 25 Jul 2005 23:02:58 +0000 Received: from [204.14.90.61] (helo=mail1.fluidhosting.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DxByK-000Ojd-2E for namedroppers@ops.ietf.org; Mon, 25 Jul 2005 23:02:56 +0000 Received: (qmail 56020 invoked by uid 399); 25 Jul 2005 23:02:54 -0000 Received: from mail1.fluidhosting.com (66.150.201.101) by mail1.fluidhosting.com with SMTP; 25 Jul 2005 23:02:54 -0000 Received: (qmail 31168 invoked by uid 399); 25 Jul 2005 23:02:53 -0000 Received: from unknown (HELO ?192.168.15.100?) (dougb@dougbarton.net@67.20.70.103) by mail1.fluidhosting.com with SMTP; 25 Jul 2005 23:02:53 -0000 Message-ID: <42E56F9A.30005@dougbarton.net> Date: Mon, 25 Jul 2005 16:02:50 -0700 From: Doug Barton User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050722) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "The Purple Streak, Hilarie Orman" CC: Ed.Lewis@neustar.biz, namedroppers@ops.ietf.org Subject: Re: Randomness requirements for message ID generation References: <200507251802.j6PI2YMe012306@localhost.localdomain> In-Reply-To: <200507251802.j6PI2YMe012306@localhost.localdomain> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The Purple Streak, Hilarie Orman wrote: > The restriction to choose from the set of unused numbers should be > mentioned explicitly in requirements ("drawing without replacement"), > that will smooth out the distribution as the number of ids in > use at any given time increases. Would "drawing without replacement up to 1/N of the space" be better, for the right value of N? Doug -- If you're never wrong, you're not trying hard enough -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 25 20:39:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxDTe-0006J2-D5 for dnsext-archive@megatron.ietf.org; Mon, 25 Jul 2005 20:39:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10471 for ; Mon, 25 Jul 2005 20:39:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxDQa-0007MD-Bb for namedroppers-data@psg.com; Tue, 26 Jul 2005 00:36:12 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DxDQY-0007Lw-LX for namedroppers@ops.ietf.org; Tue, 26 Jul 2005 00:36:10 +0000 Received: from [81.200.65.114] (terminus.ddns.nominum.com [81.200.65.114]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 1A6C1568DF; Mon, 25 Jul 2005 17:36:10 -0700 (PDT) (envelope-from david.conrad@nominum.com) In-Reply-To: <62173B970AE0A044AED8723C3BCF23810A2B2C1A@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF23810A2B2C1A@ma19exm01.e6.bcs.mot.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: David Conrad Subject: Re: Randomness requirements for message ID generation Date: Mon, 25 Jul 2005 17:36:08 -0700 To: Eastlake III Donald-LDE008 X-Mailer: Apple Mail (2.733) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable In theory, you're right. In practice, it has been my experience that =20= many developers treat "SHOULD" as "DON'T HAVE TO". However, maybe =20 I'm too cynical. Rgds, -drc On Jul 25, 2005, at 12:00 PM, Eastlake III Donald-LDE008 wrote: > I can't see the justification for a MUST. A SHOULD would be =20 > reasonable as it would mean that you need a good justification to =20 > do anything else. > > If you want secure DNS transactions you have to use TSIG or SIG(0). > > Donald > > -----Original Message----- > From: owner-namedroppers@ops.ietf.org [mailto:owner-=20 > namedroppers@ops.ietf.org] On Behalf Of David Conrad > Sent: Monday, July 25, 2005 1:37 PM > To: Edward Lewis > Cc: =D3lafur Gu=F0mundsson /DNSEXT co-chair; Florian Weimer; =20 > namedroppers@ops.ietf.org > Subject: Re: Randomness requirements for message ID generation > > On Jul 25, 2005, at 10:12 AM, Edward Lewis wrote: > >>> Good randomness should be used by all DNS resolvers on query ID. >>> > ... > >> I know that this is a dead issue in the WG (fortunately), but I had >> some real data to throw in. And I wanted to kill once and for all =20= >> the >> notion that the message id had to be "random." >> > > Hmm. Perhaps this has been mentioned: > > http://madchat.org/reseau/tcp-ip/tcpip-seqnb/#otherp > > In terms of specification, I believe having query ids be as random =20 > as possible should be a MUST. Anything else increases the =20 > likelihood of spoofability. > > Rgds, > -drc > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org =20 > with the word 'unsubscribe' in a single line as the message text body. > archive: > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org =20 > with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 26 01:20:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxHri-0005xF-Nv for dnsext-archive@megatron.ietf.org; Tue, 26 Jul 2005 01:20:31 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25179 for ; Tue, 26 Jul 2005 01:20:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxHn1-000695-Jg for namedroppers-data@psg.com; Tue, 26 Jul 2005 05:15:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DxHmz-00068o-NR for namedroppers@ops.ietf.org; Tue, 26 Jul 2005 05:15:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j6Q5FSs21814; Tue, 26 Jul 2005 08:15:30 +0300 Date: Tue, 26 Jul 2005 08:15:28 +0300 (EEST) From: Pekka Savola To: David Conrad cc: Eastlake III Donald-LDE008 , namedroppers@ops.ietf.org Subject: Re: Randomness requirements for message ID generation In-Reply-To: Message-ID: References: <62173B970AE0A044AED8723C3BCF23810A2B2C1A@ma19exm01.e6.bcs.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 25 Jul 2005, David Conrad wrote: > In theory, you're right. In practice, it has been my experience that many > developers treat "SHOULD" as "DON'T HAVE TO". However, maybe I'm too > cynical. As a customer, I've observed the same. If Foo is not implemented and it's SHOULD in the spec, the vendor typically says "we don't need to do it (or we could, but it's a low priority item for us)". If it's MUST in the spec, I can require that either the vendor implements Foo immediately or doesn't claim compliancy with RFC XXXX. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 26 03:36:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJz4-0008N9-L7 for dnsext-archive@megatron.ietf.org; Tue, 26 Jul 2005 03:36:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24175 for ; Tue, 26 Jul 2005 03:36:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxJuQ-000Hvo-B6 for namedroppers-data@psg.com; Tue, 26 Jul 2005 07:31:26 +0000 Received: from [63.208.196.171] (helo=outbound.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DxJuO-000HvV-E4 for namedroppers@ops.ietf.org; Tue, 26 Jul 2005 07:31:24 +0000 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DxJuM-000Igh-Ew for namedroppers@ops.ietf.org; Tue, 26 Jul 2005 03:31:22 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j6Q7VKH19723 for ; Tue, 26 Jul 2005 00:31:21 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 26 Jul 2005 00:31:20 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 94: Security Considerations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 94: Security Considerations Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: July 20, 2005 Reference: Document: LLMNR-41 Comment type: T Priority: S Section: 5 Rationale/Explanation of issue: The Security Considerations section appears to be out of date. It refers to setting TTL=1 in multicast queries (no longer recommended), and does not mention the measures taken to avoid the reception of LLMNR queries from off-link attackers. Also, the authentication section does not make it clear that the LLMNR can support existing DNS security mechanisms such as TSIG (this has actually been implemented), provided that a suitable trust model can be deployed. The proposed resolution is to replace Section 5 with the following: "5. Security Considerations LLMNR is a peer-to-peer name resolution protocol designed for use on the local link. While LLMNR attempts to limit the vulnerability to off-link senders, the risk from off-link responders is more difficult to contain. In scenarios such as public "hotspots" attackers can be present on the same link. These threats are most serious in wireless networks such as 802.11, since attackers on a wired network will require physical access to the home network, while wireless attackers may reside outside the home. Link-layer security can be of assistance against these threats if it is available. This section details security measures available to mitigate threats from on and off-link attackers. 5.1. Authentication LLMNR is a peer-to-peer name resolution protocol, and as a result, it is often deployed in situations where no trust model can be assumed. This makes it difficult to apply existing DNS security mechanisms to LLMNR. It is difficult to use DNSSEC with LLMNR since LLMNR does not support "delegated trust" (CD or AD bits) and LLMNR and DNS resolver implementations utilize separate caches. As a result, unless LLMNR senders are DNSSEC aware and all required RRs can be obtained via LLMNR queries, use of DNSSEC with LLMNR is not feasible. If authentication is desired, and a pre-arranged security configuration is possible, then the following security mechanisms may be used: [a] LLMNR implementations MAY support TSIG and/or SIG(0) security mechanisms. "DNS Name Service based on Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes the use of TSIG to secure LLMNR responses, based on group keys. [b] IPsec ESP with a null-transform MAY be used to authenticate unicast LLMNR queries and responses or LLMNR responses to multicast queries. In a small network without a certificate authority, this can be most easily accomplished through configuration of a group pre-shared key for trusted hosts. Where these mechanisms cannot be supported, responses to LLMNR queries may be unauthenticated. 5.2. Scope Restriction LLMNR is designed to prevent reception of queries sent by an off-link attacker. LLMNR requires that responders receiving UDP queries check that they are sent to a link-scope multicast address; responders receiving TCP queries set TTL to one, to prevent successful setup of connections by an off-link sender. However, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. While it is difficult for an off-link attacker to send a query to a responder, it is still possible for an attacker to spoof a response to a query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender. Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP response may enable denial of service attacks across the Internet. However, since LLMNR responders only respond to queries for which they are authoritative, and LLMNR does not provide wildcard query support, it is believed that this threat is minimal. 5.3. Denial of Service and Forgery With LLMNR it is possible that responders will allocate conflicting names for a period of time, and as a result LLMNR supports conflict detection. Attackers may take advantage of this by allocating the same name, denying service to other LLMNR responders, or allowing an attacker to receive packets destined for other hosts. Since an LLMNR queries can be sent when DNS server(s) do not respond, an attacker can execute a denial of service attack on the DNS server(s) and then poison the LLMNR cache by responding to an LLMNR query with incorrect information. To some extent, these vulnerabilities exist today, since DNS response spoofing tools are available that can allow an attacker to respond to a query more quickly than a distant DNS server. Since LLMNR queries are sent and responded to on the local-link, an attacker will need to respond more quickly to provide its own response prior to arrival of the response from a legitimate responder. If an LLMNR query is sent for an off-link host, spoofing a response in a timely way is not difficult, since a legitimate response will never be received. The vulnerability is more serious if LLMNR is given higher priority than DNS among the enabled name resolution mechanisms. In such a configuration, a denial of service attack on the DNS server would not be necessary in order to poison the LLMNR cache, since LLMNR queries would be sent even when the DNS server is available. In addition, the LLMNR cache, once poisoned, would take precedence over the DNS cache, eliminating the benefits of cache separation. As a result, LLMNR is only used as a name resolution mechanism of last resort. 5.4. Cache and Port Separation In order to prevent responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for LLMNR on each interface. The use of separate caches is most effective when LLMNR is used as a name resolution mechanism of last resort, since this minimizes the opportunities for poisoning the LLMNR cache, and decreases reliance on it. LLMNR operates on a separate port from DNS, reducing the likelihood that a DNS server will unintentionally respond to an LLMNR query." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 26 09:41:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPgO-000186-3N for dnsext-archive@megatron.ietf.org; Tue, 26 Jul 2005 09:41:20 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18296 for ; Tue, 26 Jul 2005 09:41:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxPbN-000NdI-VA for namedroppers-data@psg.com; Tue, 26 Jul 2005 13:36:09 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DxPbL-000Nd0-So for namedroppers@ops.ietf.org; Tue, 26 Jul 2005 13:36:08 +0000 Received: from [10.31.32.145] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j6QDZwMf071558; Tue, 26 Jul 2005 09:35:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <62173B970AE0A044AED8723C3BCF23810A2B2C1A@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF23810A2B2C1A@ma19exm01.e6.bcs.mot.com> Date: Tue, 26 Jul 2005 09:35:58 -0400 To: Eastlake III Donald-LDE008 From: Edward Lewis Subject: RE: Randomness requirements for message ID generation Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MIME_QP_LONG_LINE autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable A while back I wrote a tool to test the health of=20 a portion of the DNS tree. The tool sent out=20 many simultaneous queries, the way I was able to=20 manage them in memory while they were outstanding=20 was to encode a couple of numbers in the message=20 ID. The message ID's as sent appeared to be=20 unpredictable although they were not=20 random(ized). I.e., there was no obvious=20 "counting" in the numbers. If we require that the message ID be "random"=20 (whatever that means), then my testing tool would=20 be - by specification - a non-conforming=20 implementation. Yet it seemed to be=20 interoperable with many DNS servers in use at the=20 time. If the goal of the IETF is interoperable=20 specifications, is demanding "random" message=20 ID's within scope? I can see that randomized message ID's would=20 boost the reliability of caches, but not all DNS=20 implementations are caches. I'm replying to=20 Donald's message because I agree with his=20 statement(s). I'd add - use DNSSEC too. If I were to write the DNS specification today,=20 I'd only mention randomizing, or at least making=20 unpredictable, the message ID as a recommendation=20 in the Security Considerations section. I don't=20 see that a random message ID helps in=20 interoperability. At 15:00 -0400 7/25/05, Eastlake III Donald-LDE008 wrote: >I can't see the justification for a MUST. A=20 >SHOULD would be reasonable as it would mean that=20 >you need a good justification to do anything=20 >else. > >If you want secure DNS transactions you have to use TSIG or SIG(0). > >Donald > >-----Original Message----- >From: owner-namedroppers@ops.ietf.org=20 >[mailto:owner-namedroppers@ops.ietf.org] On=20 >Behalf Of David Conrad >Sent: Monday, July 25, 2005 1:37 PM >To: Edward Lewis >Cc: =D3lafur Gu=F0mundsson /DNSEXT co-chair; Florian=20 >Weimer; namedroppers@ops.ietf.org >Subject: Re: Randomness requirements for message ID generation > >On Jul 25, 2005, at 10:12 AM, Edward Lewis wrote: >>> Good randomness should be used by all DNS resolvers on query ID. >... >> I know that this is a dead issue in the WG (fortunately), but I had >> some real data to throw in. And I wanted to kill once and for all the >> notion that the message id had to be "random." > >Hmm. Perhaps this has been mentioned: > >http://madchat.org/reseau/tcp-ip/tcpip-seqnb/#otherp > >In terms of specification, I believe having=20 >query ids be as random as possible should be a=20 >MUST. Anything else increases the likelihood of=20 >spoofability. > >Rgds, >-drc > > >-- >to unsubscribe send a message to=20 >namedroppers-request@ops.ietf.org with the word=20 >'unsubscribe' in a single line as the message=20 >text body. >archive: > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 27 10:19:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxmkb-0006Bj-SM for dnsext-archive@megatron.ietf.org; Wed, 27 Jul 2005 10:19:14 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01593 for ; Wed, 27 Jul 2005 10:19:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DxmeT-000J6A-7P for namedroppers-data@psg.com; Wed, 27 Jul 2005 14:12:53 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DxmeP-000J5e-0V for namedroppers@ops.ietf.org; Wed, 27 Jul 2005 14:12:49 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j6RECbjm083869; Wed, 27 Jul 2005 10:12:38 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.3.4.2.20050726235217.04a29660@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 27 Jul 2005 10:12:34 -0400 To: namedroppers From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT@IETF63 Agenda Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSEXT @ IETF-63 in Paris Date: 2005/08/03 Wednesday Time: 14:00 - 16:30 Location: ???? Chairs: Olafur Gudmundsson ogud@ogud.com Olaf Kolkman olaf@ripe.net Agenda Bashing and appointment of scribes: Olaf Kolkman Documents Status: Olafur Gudmundsson 10 minutes Documents Advanced: LLMNR: Last call completed, one small open issue remaining before handing back over to IESG. http://ietf.org/internet-drafts/draft-ietf-dnsext-mdns-41.txt Case Insensitive: Advanced to IETF done, some comments from IESG. http://ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-06.txt CERT RR: http://ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-03.txt Last call completed waiting for chair: Wildcard-clarify: http://ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-08.txt TSIG-SHA: http://ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-04.txt Drafts ready for last call: Scheduled for August Derivation of DNS Name Predecessor and Successor http://ietf.org/internet-drafts/draft-ietf-dnsext-dns-name-p-s-00.txt Minimally Covering NSEC Records and DNSSEC On-line Signing http://ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-online-signing-00.txt Evaluating DNSSEC Transition Mechanisms http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-02.txt Last Calls: Scheduled for September DNSSEC experiments http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-01.txt DSA Keying and Signature Information in the DNS http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-06.txt Storage of Diffie-Hellman Keying Information in the DNS http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2539bis-dhk-06.txt Elliptic Curve Keys in the DNS http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-07.txt Ongoing Clarifications and Implementation Notes for DNSSECbis http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-01 Domain Name System (DNS) IANA Considerations http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-00.txt DNSSEC Hash Authenticated Denial of Existence http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-02 NSEC replacement Requirements New version promised soon. Meeting main topic IPR issue Update: Olafur Gudmundsson Automated Updates of DNSSEC Trust Anchors: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-timers/draft-ietf-dnsext-trustupdate-timers-00.txt An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors. http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-threshold/draft-ietf-dnsext-trustupdate-threshold-00.txt We hope to have lively discussion on the advantages and disadvantages of each approach and be able to take a straw man proposal to the mailing list on which proposal one to select or on a different direction. Other Draft discussion: EDNS NSID Extension: Rob Austein http://www.hactrn.net/ietf/dns/nsid/draft-austein-dnsext-nsid-02.txt Domain Name System (DNS) IANA Considerations: Donald Eastlake http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-00.txt Interoperabilty testing reports: DNS Compliance test suite: Nobumichi Ozoe http://www.tahi.org. Drafts from other WG's requesting review: None at this point -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 28 04:51:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy46v-0004Fh-4G for dnsext-archive@megatron.ietf.org; Thu, 28 Jul 2005 04:51:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06887 for ; Thu, 28 Jul 2005 04:51:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dy42L-000EJK-LK for namedroppers-data@psg.com; Thu, 28 Jul 2005 08:46:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dy42J-000EJ0-Lr for namedroppers@ops.ietf.org; Thu, 28 Jul 2005 08:46:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j6S8kYq17266; Thu, 28 Jul 2005 11:46:34 +0300 Date: Thu, 28 Jul 2005 11:46:34 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: namedroppers@ops.ietf.org Subject: Re: RFC2181 section 9.1: TC bit handling and additional data In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-851554963-1122540394=:17233" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-851554963-1122540394=:17233 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA06887 On Thu, 28 Jul 2005, JINMEI Tatuya / [ISO-2022-JP] =BF=C0=CC=C0=C3=A3=BA=C8= wrote: >> Specific questions (offlist responses are also fine): > > Did you get sufficient information about these questions? As far as I > know, there has been no public response on the list. If there has > been no off-list response either, I'll try to answer the questions on > one implementation I know of a bit. There has been no response at all. I guess everyone is hoping someone=20 else will be responding. I'd really appreciate any responses. Thanks! --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-851554963-1122540394=3D:17233-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: --1589707168-851554963-1122540394=:17233-- From owner-namedroppers@ops.ietf.org Thu Jul 28 14:06:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyClg-0004nY-N3 for dnsext-archive@megatron.ietf.org; Thu, 28 Jul 2005 14:06:04 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17593 for ; Thu, 28 Jul 2005 14:06:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DyCgh-000Khw-Me for namedroppers-data@psg.com; Thu, 28 Jul 2005 18:00:55 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DyCgf-000KhY-KX for namedroppers@ops.ietf.org; Thu, 28 Jul 2005 18:00:53 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id DA3A624072; Thu, 28 Jul 2005 20:00:52 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C3A7023FD1 for ; Thu, 28 Jul 2005 20:00:51 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j6SI0pmq029409 for ; Thu, 28 Jul 2005 20:00:51 +0200 Message-Id: <200507281800.j6SI0pmq029409@birch.ripe.net> To: namedroppers@ops.ietf.org Subject: WGLC: white lies documents Date: Thu, 28 Jul 2005 20:00:51 +0200 From: Olaf Kolkman X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.021965 / -5.9 X-RIPE-Signature: e06b1750c244e8cbafc4d48ebf03eb85 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear Colleagues, This message starts the working group last call for draft-ietf-dnsext-dnssec-online-signing-00 and draft-ietf-dnsext-dns-name-p-s-00 The first draft describes the mechanism of what has been called white lies. The second draft describes one specific function that can be used to implement the scheme. The editors off draft-ietf-dnsext-dnssec-online-signing-00 have reported that except for a few minor editorial changes the document is technically solid. After rereading the document we think it is ready for last call. There are two particular issues that we want working group guidance on. They are of a somewhat bureaucratic nature. 1st issue. The document indicates it updates 4034 and 4035. Sam Weiler has paraphrased the changes as: - RFC4034 Section 4.1.1 describes how the NSEC "next domain name" field contains the next owner name in the canonical ordering of the zone. Again, Epsilon does something different. - RFC4035, Section 2.3, 3rd paragraph requires (with a 2119 MUST NOT) that an NSEC RR not be the only RR at a given owner name. When Epsilon NSEC RRs are synthesised to cover a non-existing name, that constraint is violated. This should not require any changes to deployed code, but it is a change in 2119 language. It has been argued that it is impossible to determine with certainty that the NSEC is generated by an "epsilon generating server" or by a a server that is serving NSECs generated off-line. The question to the working group is: Should this specification update 4034 and 4035? That question is related to the second issue. 2nd issue. Should this document be targeted as experimental or follow the standards track. We had some discussion with one of the editors. There are arguments for this document to be published as experimental. + We are not aware of anybody who is willing to use this technology in production. Some of the people that showed interest earlier have been telling us that an on-line key is prohibitive to deployment. + There has only been one reported proof-of-concept implementation. + We are not aware of any implementation that plans to include this technology. On the other hand the technology is not seen as dangerous and there is "neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard." [2026 Section 4.1.1]. Our interpretation of RFC2026 section 6.3 is that if this document updates 4034 and 4035 it will need to go on the standards track. The chairs favor the document to be published as experimental, with removal of the "update notice" and a small addition to the introduction of the document along the lines off. This document is based on a relaxed interpretation of requirements in RFC 4034 and 4035 that does not noticeable on the wire and does not lead to changes in deployed DNS clients. If the technique described herein would be published on the "standards track" the document would update 4034 and 4035. The chairs also think the second draft "dns-name-p-s" is to appear as experimental. Hereby we issue a working group last call that will terminate September 1, 2005. This is longer than normal since it is vacation time. Your chairs, Olaf and Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: