From 823c5a49e5a2f5ec4325889c975e84608eee9f9d Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Wed, 18 Nov 2009 00:19:05 +0000 Subject: [PATCH 01/18] update --- doc/private/SRCID | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/private/SRCID b/doc/private/SRCID index adf150b57d..24117f2f72 100644 --- a/doc/private/SRCID +++ b/doc/private/SRCID @@ -1,6 +1,6 @@ -# $Id: SRCID,v 1.12 2009/11/17 06:16:53 tbox Exp $ +# $Id: SRCID,v 1.13 2009/11/18 00:19:05 tbox Exp $ # # This file must follow /bin/sh rules. It is imported directly via # configure. # -SRCID="( $Date: 2009/11/17 06:16:53 $ )" +SRCID="( $Date: 2009/11/18 00:19:05 $ )" From af52d6ddd75b059194e47d07d3edaab82f26e662 Mon Sep 17 00:00:00 2001 From: Evan Hunt Date: Wed, 18 Nov 2009 00:30:37 +0000 Subject: [PATCH 02/18] prep for release of 9.7.0b3 --- CHANGES | 2 ++ lib/dns/api | 4 ++-- lib/dns/win32/libdns.def | 1 + lib/isc/api | 2 +- version | 4 ++-- 5 files changed, 8 insertions(+), 5 deletions(-) diff --git a/CHANGES b/CHANGES index 40c3e4feaa..0e2440074d 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,5 @@ + --- 9.7.0b3 released --- + 2772. [security] When validating, track whether pending data was from the additional section or not and only return it if validates as secure. [RT #20438] diff --git a/lib/dns/api b/lib/dns/api index acbd59ffa6..737fa9b946 100644 --- a/lib/dns/api +++ b/lib/dns/api @@ -1,3 +1,3 @@ -LIBINTERFACE = 61 +LIBINTERFACE = 62 LIBREVISION = 0 -LIBAGE = 0 +LIBAGE = 1 diff --git a/lib/dns/win32/libdns.def b/lib/dns/win32/libdns.def index a2c99f6099..12e6e6ffed 100644 --- a/lib/dns/win32/libdns.def +++ b/lib/dns/win32/libdns.def @@ -230,6 +230,7 @@ dns_journal_next_rr dns_journal_open dns_journal_print dns_journal_rollforward +dns_journal_rollforward2 dns_journal_write_transaction dns_journal_writediff dns_keydata_fromdnskey diff --git a/lib/isc/api b/lib/isc/api index 5146f4d5d9..ba292fc675 100644 --- a/lib/isc/api +++ b/lib/isc/api @@ -1,3 +1,3 @@ LIBINTERFACE = 61 -LIBREVISION = 0 +LIBREVISION = 1 LIBAGE = 1 diff --git a/version b/version index 8cbe283a03..236052e4a8 100644 --- a/version +++ b/version @@ -1,4 +1,4 @@ -# $Id: version,v 1.49 2009/10/27 05:49:31 each Exp $ +# $Id: version,v 1.50 2009/11/18 00:30:37 each Exp $ # # This file must follow /bin/sh rules. It is imported directly via # configure. @@ -7,4 +7,4 @@ MAJORVER=9 MINORVER=7 PATCHVER=0 RELEASETYPE=b -RELEASEVER=2 +RELEASEVER=3 From 850853340a7b3cd1a55f595e815ab9bccbeb4fc5 Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Wed, 18 Nov 2009 00:38:26 +0000 Subject: [PATCH 03/18] regen --- doc/arm/Bv9ARM.pdf | 5116 ++++++++++++++++++++++---------------------- 1 file changed, 2558 insertions(+), 2558 deletions(-) diff --git a/doc/arm/Bv9ARM.pdf b/doc/arm/Bv9ARM.pdf index 2391897a1f..fd6d9c259b 100755 --- a/doc/arm/Bv9ARM.pdf +++ b/doc/arm/Bv9ARM.pdf @@ -1316,7 +1316,7 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 768 0 obj << -/Length 2890 +/Length 2892 /Filter /FlateDecode >> stream @@ -1340,7 +1340,9 @@ l ,@$ 0!p)C!V$2oqE% ٓQBJXL1Bi{l#Q467Oݚ6ǮxOASo×#25V˄,⻪Y~r{w$zYĘzbC",E=fR7+l1z(vMib9}!jt3dgȐg_⠴'u7r>ljCwv_n|Hd!%>N?%~$J| ug `m^n`OR_d;J}J ()Øo8ujg*ChG/}YT?]`ەoF|dՑ!%;={$JxJX*ɠ<|uyUD{-]Wwre`f"w9deȐg<9}\BSa8=j$zD<`}>Z![Y@ X H X"t@_WEnŵ'E^g Bty `G1T  ("(\0 ~- gur?PW >(dHeA1Ez4cF$PcXغom:l]}-RPb*eȎ L0 @t % В薳p:s=6"SICviXoiGIA?,[ƒBʻSُ`T>SQߟXv@=s_jEyz??<\ -Gendstream +=PAbjo9 CcXfHca.eY~A̵W4DR o2Ȑ#ǛbqPpaY4P@sa%6ES9Æg[RCXg02ŕ (S98<'1gϗ7PAP}5`LR3X.Fڇ㖓MSpaˍ,>2ďAOzķn= Ijk,`GO=z g[L崺{Q/KUpklRو:2dǹtA OzW \%:/> >> endobj @@ -1661,7 +1663,7 @@ endobj 815 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [527.6238 124.7562 539.579 133.7623] +/Rect [527.6238 124.6566 539.579 133.6129] /Subtype /Link /A << /S /GoTo /D (subsection.4.5.4) >> >> endobj @@ -3510,26 +3512,31 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 1115 0 obj << -/Length 3448 +/Length 3424 /Filter /FlateDecode >> stream -xڥZKs8W6tUĐ@{$NfU;]~{#cx DN)$6ꈅ$kH?n͎6'SEqTþxҵ(J^|þ*j/LӼ"[u0בVJ%, A`??Cߚƙ|V͇- >ukz'،<ݖԶ;4n;}dUYOL{|Aa.m&&S UK42Q+ -hUQ}$a/Ό~M5Nada_tXOiFJmSV.HȠ)\9O%A$8SP{<f‹[^ -fV!&߀_ƭ^XQ@Mv5{U۪9 !Vc>!d[hwt6d@-aL 'B,@+Ƽ:zֳ!Jo軫X [),ifdk>!STFoW$l0DPhzM:mTI^ZӺ7^|s9 %+Ͱ ЙvȀhfMȂXufɓo ە<֘%nkڧXds8;h ҡ|؛vT=A'!qvCKl|8HXS [(Rځ 2 -fC0 -"2t8à][8HOhG 6Xj@՜`Y5^ >=  3ݚmG`zAk upvlHi`$/yrv -\3sgƳ7مE<)1n̂.$J䜖mɧ c_bd -e.աF9X葩~d:xؚgd/@#;#tܴճ)^r&t3=9xQ)QVL<6R$8Q>&K2ZA|a@6EfYv$zܺKE;XcL<"1vZKH|:[\S^`%7S^H+k:2,Z,U@h%wLcq wavSZw>NX;._8KldbS*Gw2Ӄ0yC/'g3G *hwYˤ7\v_ A=l"I$$̀!HM^piZ8UYUzwu tLUmQ GR.߬v+"*C5=9ɎRWHtŔ^OC/ =NW3Ea `OS#ɩ=dkvM @k] _8\W/'Vvlk8rzm<6.gp@9EyiFHPbd0 h. -5, -JNvE@+(F䞠Rx$a8eJf:&e=sg6TВ̫v`Z z2mŹ -',|1x|3&.0(8Na?U` q -fGKdN)h*ibZDߝ-b Ë0?׆:d$|^ઈ KqgS|0@.mA [y~~~ vPfk*Ur5hߐf^i}k+8F5X0 A -н8l)U"LY2Z ɠ{ޣO ;{dj^(&*r& qv(Ja1 fWFhr. ,ŶX+7`=_*nO@!HC }fsL+? 7]ߔxղ`:!HE!P.N vV@⎺.iC6DCiA -c£`Ïնn˯7RPf/wD83::^2d~b%]qȭ]<^@qȰ k'9m_LfjN YȢώu~sxO4Kml'TKHf85 cN z練iWF\hoGcM 쓢ʅ*]AC3{ SVE U_X#MXP?%Bָ ;ϊh;gr TCT.GϤK=&u^qKcg l\ʹ 6 m^Lzao;:d+=ڿ5`po0 5h2mI:Y,2"J<8ws]}s'&$J6O{Vin5Pnq{tbHޏRᑪ?2߻[{O3՛л>3\_׿( mKnR@#w`:h3ζEx99g <#Ca8L%K0yb4P_9ɮMnuq0q=4q[6jn#A_PQӦC8 jǩp>kކ@b[8'y2xd[92",Ht4*/=ys LMUB\K׌?\<&XJ`~ XP&a_z(*]l9 @N7PCzw!2i('cY^vDa&@c0B +NZfu'M˼R ܵE e#\ +rE%aq 'kkiշ_Ư ]E{:̉r_0~HRۏ+O? x6 +c,rLEX͡A\hJe۔%1u;u]) 0p,uEC3`*D03i,[.ab

Y}X`~a9Lt:W˝])MT3ҙ]ama{KǂxNJ W"Ne@!ф*" ]@; $'N0"Na3fF9gl4L9Ѕ6T07t{-T/+!C6z68Lrr.bWt"ɔ^WW .U˧1,* cf0zn9Vn  +GCy< T1!&ጵ86ll-z+OuW34V9cvX0@q"3;˒ +ewiCki`}fd:h#җ2G|*R蒳(o p7/rD@_8bLc9.Ju {-6TdbP[_*Xsऋ)W,';/ XI[a +pzS9L؏ӓ…, +bwGS;9Jr #{낍c?UQ:08ݟYkV̼^CdAϺ~6!Ϻ;#d5ǜf)E&^0x%0/y4 )#g2l5 )u`p+#52JpA(AT!X%23]q13%^;`>gZB姮+-jQ[sN)hco3-E0B1+ae'M +Gd\ 8"`xb-8Z"$yOAC]O=  MKp0<KRBH+G|֘_h G&^~|yPɂDUrf ! زXB*]{Fkr<5Df`/A~4'`֜[_lSrlj.͖ӥPX[4m4mr  l$P7V +E0Zƫ}TBȥ5RR!?+w >y6==v(jkIÁ{D{1O{"~I `= cO'7 2dG($du2m\TQaɐՂ`f{ƺKMwj/>wT)” >s̫/|Ȏ]]xdFN'B8d/"o*^Q\ǵ&6mlp<[XJS:9NUV (fP|z"R@BGg޲?{ lendstream endobj 1114 0 obj << /Type /Page @@ -3542,14 +3549,14 @@ endobj 1118 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [464.1993 465.6151 511.2325 477.6747] +/Rect [464.1993 416.3401 511.2325 428.3997] /Subtype /Link /A << /S /GoTo /D (proposed_standards) >> >> endobj 1119 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [55.6967 454.6761 105.4 465.7196] +/Rect [55.6967 405.4011 105.4 416.4445] /Subtype /Link /A << /S /GoTo /D (proposed_standards) >> >> endobj @@ -3557,51 +3564,44 @@ endobj /D [1114 0 R /XYZ 56.6929 794.5015 null] >> endobj 146 0 obj << -/D [1114 0 R /XYZ 56.6929 531.1808 null] +/D [1114 0 R /XYZ 56.6929 488.287 null] >> endobj 1117 0 obj << -/D [1114 0 R /XYZ 56.6929 497.8268 null] +/D [1114 0 R /XYZ 56.6929 451.1363 null] >> endobj 150 0 obj << -/D [1114 0 R /XYZ 56.6929 342.6181 null] +/D [1114 0 R /XYZ 56.6929 282.1132 null] >> endobj 1120 0 obj << -/D [1114 0 R /XYZ 56.6929 307.0547 null] ->> endobj -154 0 obj << -/D [1114 0 R /XYZ 56.6929 119.358 null] ->> endobj -1121 0 obj << -/D [1114 0 R /XYZ 56.6929 92.1345 null] +/D [1114 0 R /XYZ 56.6929 242.7532 null] >> endobj 1113 0 obj << /Font << /F37 827 0 R /F23 762 0 R /F41 969 0 R /F21 738 0 R /F55 1070 0 R /F48 985 0 R /F39 927 0 R >> /ProcSet [ /PDF /Text ] >> endobj -1125 0 obj << -/Length 3046 +1124 0 obj << +/Length 3172 /Filter /FlateDecode >> stream -x]۶~ޢD>L8I|m3M2SJ-:Ry'_; HQ]3}xb߻q'fF3d \YxE ۫ϿV,gy*a1]<xv)xk!śn^7oi͋,&omonnmWHoW?gkԷW^8y.gwWVL'J۫hnVi# H5Te~2iZ8ɶ\uUSK=;4[):U{(mܖnbwV+1|˳DZ -o>wm _~n`ih؋[EJf^]-MU`6|.K%0mc4mWwWx;B6E!f OBkM=Tl+(|Z e^5w~b64a=G-tnxp؋ժl rUmoćW',zHbgSXg -:)VMjPnB],Pi<+dh -@źP mnjQv€P!8ݖMރC -+-M!8wQ ?[j I18>x/\b " k{=bUAVq=lm`wH-.8P5,yDBJʺVwF C>jg'KM\"+تpN+i٠YoLjTyTCoW#e{o#"b,I_'L/\˯i#<5eM -r_V9MNu<(AJSB۪+ d{\XjR?H`\c`"Y>PJK ,qiE#|O>BJdJ:BYԠh55d -bPAZy-%Ƒ^eWz:PL',%¤X1_Qr׎gCn8,r3Rg("iIR.QL)j{p@3cj HiV)&@'4!珐۸ly*p'" FP^pgjwBÔdi.K:f\<ˑbơHvM7 : kS#E_.!iri OKL _0r*%x8.p dz_ν}.4 Tyx$.mEdG}$z8 Y -l"j RH -D\ W%xٚIPb&Wp4C` *^Whh*'ؔbHy3>פ ؤ Iw&UEΎ_DGrISH:Z+9BmRj֫5{FxJ+Saň$|9D+.˵K\6@A`ɛB{AH_*K?Q``x(-k|4R0a# :}]n-wp_wh\k˞"ZyEc"Dd٨qnSӀS/6M;qSѠUatƑo9<΢&n#Ed$ s,jigcR,Q 97׋f| -NOH} -vu9GagifI85M}4݆\zO ]"xqn,S&h!?V<' #nzIwߐ.Ƕΰ!A@ qQKGDؕ?.ͼ[5nOu Ӱx"5=a-Q?\iBo`n̨\ ]m{ <3${C}.s> q‚#f1%O/)$މcc>I1jZU*iގ̲ĶwU*q[ 7[ e 0]wY_%;l0E zz'|3jDg" ɨC?ӫQz30ũ e ٳ5c(LQ.D6>s9O$J3ruWO(g$ptX某%3JNK0@]S{ ;)K ^ BiQA?(a 3De\duF ϝ r| c.#NJ̠<ϫ IZ2'I1}vT/9<je s$K(6q_]q73lv`xpSp.վZO4edJ'91EfQ>9*F_cy/3GM>6BQQ_[cNa&Qf&28?Fc>ƋxN1qDM -~'sd_c\gbe8ڤ*;O -~D0cJՖZ~>/8Seq0OKS%8@k,,]x,6<2fǩRL3!T)fN9( MGBiTa1vendstream +x]sݿBo3'vL9Lr6$3%ޙ=TD:XKfу_$_0)ZdJ5z` ahCO_lfq>eSf-_\N/BDKmX/97_^Wo૫Jp“~zxo.{Np&.~-po.X*s{X](-S +w?]t" \k1S#tq8'c,Tm7%nn"xh@-#ɳl +p~[vK-q%Kl/]&20r |gԈsr H^׫t WG~a, @2< hKB"W3ti|x-ʇrWlhjvfWt%UWz“%5+XZUݕ1L'uGFKn-w A=V2uM׬E-X4,u)fa]U`Ů=K"h_}OOz~B5][KZuUSӤyOGUjS7*ȼC*pc.LuyRFZզ*{d oJ%fAmvxW<>q^B)lH,ٖ8F%[ ]3F$a.0)6mC V`̢#<@Vevm*w]Qs(,zHZGl&SqoWM7k@=f$06޼[:ks9k,gxu A2;X#H7U{omQh X+d[n{+h>l|_d?nVOjɲ[5T5m`0u\y-8LSʇG<,sK7X[VFo<ԖGfMkUxcwt8Ԏ +ƾ'uβRMW0Nl&,xUS˜pOg_Ӫ3G$5!(ݗtirۍvzsd4&8P<>VBBa1q4O'b sSr8*#=D.l +A< 9K C&WJU4h ~Er 5,P~ g=Z-<6*2wMЁAtqa>¦[G~b)feYVlbCGei$N HghT*H80qTUj{\$xI ''@ɞ|LfϜa0iwj +,LDg"RYj5SL/_W-8fO3J`{V:Ljq'yq> tA ^mUw Q/N5It@AiFf? ƥK%pxB +\Ev+`(1eva +WŽ 2 +WA{AP' /?Q\A`/š+jdit(XpǾ.7C;8'b7?.N#t}$ ][*C0wԦB9oK?]TZF=nGS]ImbǚE&0 +X_c'̛˥a9` HG ڗ:[ݨ|v~#r[l5".ͪIx @CV6O܃ztڝt}E~;e}T֐ǞθA~~|-wK<(.VCj #kܗvz]o3y[:i߹:!K9yy\<}o`G^ʸ%} =m <1C "ħn5 +f0rXA7c:="mR$>DcU 2f97ުݨߥp/o'Ğw,* y( C8X w̥h?!R]‚g^?,5?x r;2FZ_{,"7*?|~JPqES{N EI:E-R'i<;Z\,%PYO.{)enLZ )Bg1SK>7Wa8ZjW@yI4]P]¿'hyԣ"7ȱӻ ys(2'->6Ӡ(C-˩I+PU.8}i6w412~?ph܇xQdq 9_S\+biY57qxc(8;Y\vpl +7kż$3y3pendstream endobj -1124 0 obj << +1123 0 obj << /Type /Page -/Contents 1125 0 R -/Resources 1123 0 R +/Contents 1124 0 R +/Resources 1122 0 R /MediaBox [0 0 595.2756 841.8898] /Parent 1107 0 R /Annots [ 1127 0 R ] @@ -3609,25 +3609,30 @@ endobj 1127 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [417.8476 169.1947 466.5943 181.2543] +/Rect [417.8476 110.3446 466.5943 122.4042] /Subtype /Link /A << /S /GoTo /D (sample_configuration) >> >> endobj -1126 0 obj << -/D [1124 0 R /XYZ 85.0394 794.5015 null] +1125 0 obj << +/D [1123 0 R /XYZ 85.0394 794.5015 null] >> endobj -1123 0 obj << -/Font << /F37 827 0 R /F23 762 0 R /F39 927 0 R /F41 969 0 R /F14 765 0 R >> +154 0 obj << +/D [1123 0 R /XYZ 85.0394 769.5949 null] +>> endobj +1126 0 obj << +/D [1123 0 R /XYZ 85.0394 749.3028 null] +>> endobj +1122 0 obj << +/Font << /F37 827 0 R /F21 738 0 R /F23 762 0 R /F39 927 0 R /F41 969 0 R /F14 765 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1130 0 obj << -/Length 776 +/Length 736 /Filter /FlateDecode >> stream -xڽWMs0+B>6ɤ1%Ɂb9 D"_W !glIv߾}ˬ $p kU62VC>$3=3\5|>2 p8-[؅Bp~*ϕ!4W|68|1yX#mf )`g\ H@q pBIb,&=>&nɟT\ \nn){p1?lôN%|.02.a&C A!ɪN_M㾚nXTAJ(K=)lהB?^bi\ 2e6;ZW,KnjVIہU_CYRO"]WX -VUi7Dn -Rc  ++4s#L?v]o"VxEWJbm;։PDL y=_jگ#yp|߷Z9uO2Xk|,- B@;U((}23(M\P̿2yp&>'xN*Pwy /Tbendstream +xW[S@~W0>n&OƶNc eB\Vޅ%qFw.$Gl"M׃^@s8E5@x P F 1 <ˇ.-:5?1quyn;o~3iW7clM?ΎZ.lj+z61 J۷Ve^\Kw[q@13q)tJ%5Ɨ&`me#HG48XG@Zũ > endobj 1134 0 obj << -/Length 1487 +/Length 1364 /Filter /FlateDecode >> stream -xڥXKo8W=@ŐzksJnK[DDer(B'p8̓ClJMӈ Ih'tfeQۗz iF؏rOWJh4{ՇGttvqל16y}uK7xsu1OWL/w߾ܷɧ/tZ+&YM`B 2Q@0FN58cpolu$ -R~J\A2~`jŔN5NᎫN6'7[6JW=Hhh5-ա%#YS !d>?>;C7@WUu-U)Z}ZC㮭=r%'zV \;Ꞩ5Ev`kenM<_0mem3~~T?C8VAO{' )YsuՖ%pdF⅒`D|7 -Hެ_z0MZ`SCDҡ8Nش[|=Dݙix͞]CؐDMkPzo`^%x0.'lB~2K|b}WO?=cS }$aXp=Fw.!~JBl6jNlB k:Y/qop\᭡ˏ6 5vҙ&tR4:H0y5qA,´W7BwfYrh7̨Ƭ6gJer4SYnw>:x0c DR& -Yj>zJ KW: -6fScnX<'%9jnAU v $zuZ\az R]#N|H"*׼ՀSo6PwZQc CӦlr^M&D4d}l̖޲jÂ0N-͹OR{l^s(.hL2P !${6az5dVPEXoNr BgPhM,[Y! ֎da] n)u߈V6 $HMF$ -ZTzkўCh#~;0Peoz_Ѳ>7%qn 5;>jFm+dm{LE; w@;F!a1i[rK3M/_&P"?‚Jendstream +xڥWݏ8_J$ۧ]qл@ț8mtiRdf~3aNy,B'B/be{Px"}^~7NNQju:Ps/"q?^.I]-u޻}'U"T4-m#uԑqRo˾ J!K1=}|d7nTʶNDIXG;ʍ\&ɂ'uqR?;̇N8ȯ;q5gX[mZ([L%ܓ_/oO)r-l0Y,џ'%)VɲA]^jI6T'dαOx6ڊW.'-pS7ۖ'-`l;@)-aȍ,i?P݉Z6>NjӘf1X]!\lFls$΋0 7>`r-ԁ5ЖXm*>?(hP둌*$qʾ5} ;W 8adE#[t. +g2 & q0&N5(<~o4g7<"ozTyWݢ̀G|#a GϚ 2LF@O8> +& nDQmӍWJjz((mӋZbiGDm`-fh +"u^\U7DQƓnp{GǑIV[U>հAݡ$| o eŐsbǐvh\gJ$H̓`]S`>\gS뉫JI*`F3! Y p%d|VٱSs{ (GS-Ph*a#FurBEK!̶,nn蚟AQ-n%P,e N*7B%({8tB|)K6Pƹ/z'I(MOU.BIzb߼qMp1gJQxn"Π v݆݉\`{voE#.$}xom,R?KFf?8v96Eendstream endobj 1133 0 obj << /Type /Page @@ -3668,30 +3671,25 @@ endobj /D [1133 0 R /XYZ 85.0394 794.5015 null] >> endobj 158 0 obj << -/D [1133 0 R /XYZ 85.0394 263.5848 null] +/D [1133 0 R /XYZ 85.0394 223.4026 null] >> endobj 1136 0 obj << -/D [1133 0 R /XYZ 85.0394 220.0831 null] +/D [1133 0 R /XYZ 85.0394 185.2496 null] >> endobj 1132 0 obj << -/Font << /F37 827 0 R /F41 969 0 R /F23 762 0 R /F21 738 0 R >> +/Font << /F37 827 0 R /F23 762 0 R /F41 969 0 R /F21 738 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1139 0 obj << -/Length 2256 +/Length 2266 /Filter /FlateDecode >> stream -xڥY[w6~K%^qbM}iIĔGx {|s&!Ii$ddU_-`fo'Y?..{óIiN^y9,x ߼л}X\$)4aSƘ7{y^j6booW韋.NXQNp.€y2F&E 9=nި^:ODlXP$I4JR) -, Cl^t:߉\|PDm=Wb#(M_u:x.$=ǞFS{LTԿ5i]Kߥi,ew/eCbǣQTȃb@Z6"mEXIYVKFF Μ۝4Ƹ7kHL_^4D#j9< -+dz, d1Y01b}_`qjHZVnRۘ)mg F/⻫b>"swGDAs'yӪ>1C<" 2kRDdR;D7CijL<8=V{ #Cz@lŸ-` ] lm cq'r=]~zLbBCM0p,U9+orO~ '7hn)FT;)fpJ6CШL JcЬR-1}4jHV@ 4w0}ݎa3#`X #X'3示N3+%۽-}!rH'Yt蒽k)b;_x>\5ŬѕP6R=w5@󔀚'`V5tU{+Ocp5 hpF$.2M4(%`)UmC\qeN -M3/uzF5Q'+ykiڲ[=6榁X=b#](oI/t{B7؂-GA< e?} -"ꅊ v2E~D ȍ!MsyļyIM ;7H\O8Z`\҄΍š,y|7yXm}%^6}`YrbI;0LA2Pޙ17v["vQs00 &(Vc:#9_NRYs9D=;oXۀzH|i?tp$7<%s endstream +xڥY[w6~K%Aumf+4}$Zb‹BRv{ HN|s,>10%YdlS]{}n~^]J$eqVZ) ҔV?=8@!V˛s?ax׋w?`*B/1{W/˷KZ̓[/W+'<(ܧ? +f[/Y*g0 ϲpV]DR0 aWʋ[}tR'<` bJ)2cWMS휧^S}dށfw65{ ;FaF]*д}w.]h[ѐ?Yq3,0`q92d(L"|Y&eh^UHSc,F͡/3E}ڀV米'nO*BH#|JDan:RH1 /σ ^uޢ8˽jss_s[{+*M XYy/":`0yysI lzsvNfy^"<̘5҆˂=cJq: N$iIxT[>7@?_ cG0, O@6‣ zйMMm41<f"aa(ǾT_l̗CwD(,澨w4u,isx)Zai>(x04~׋PZm8PfνX[aZ(.5.K::>)7WN+r {E{fsWJ}.cxРp׎&P_r[r#:$LkTpұy84"[w| + ) +z+5IbMO0Y0'_̙{L#nȜ&^0i ,RU& FܸCX< n:T2<ŏHp4^;M_1!tV@+2I=hx PHIR&9T.#UqD&MI[@8Ÿ3 +adSR k4"Q8H!pnz+-Y3vcA=fLbSR,.ϓTdci~^g?k:SO?} yygj~B2d/xH(:e'56*FGU!X&J +|=׋==ZƐ>7Duu0ECu`̻4aX^ڦa#LTYlE:>ILuݱ"p\,=Se_R'?ԓ~vfLFC]3)f#CM(M JS#q}έ`L\`Ѭ{+~]cWMv>nDb_蓼8_l}LĀ)LƮSԣt&^)luՍr\"5D 9 iՀՖmvB2v[]P2Y`D厈RDTX4&d$_P~i-iCfue٠-"''2tjݝS1IitAޞ=1^H_'>.OLD iNf9žl$Xiendstream endobj 1138 0 obj << /Type /Page @@ -3704,66 +3702,59 @@ endobj /D [1138 0 R /XYZ 56.6929 794.5015 null] >> endobj 162 0 obj << -/D [1138 0 R /XYZ 56.6929 769.5949 null] +/D [1138 0 R /XYZ 56.6929 726.8027 null] >> endobj 1141 0 obj << -/D [1138 0 R /XYZ 56.6929 749.2418 null] +/D [1138 0 R /XYZ 56.6929 697.6944 null] >> endobj 166 0 obj << -/D [1138 0 R /XYZ 56.6929 703.0989 null] +/D [1138 0 R /XYZ 56.6929 648.8841 null] >> endobj 1142 0 obj << -/D [1138 0 R /XYZ 56.6929 680.1552 null] +/D [1138 0 R /XYZ 56.6929 624.769 null] >> endobj 170 0 obj << -/D [1138 0 R /XYZ 56.6929 533.6481 null] +/D [1138 0 R /XYZ 56.6929 472.4047 null] >> endobj 1143 0 obj << -/D [1138 0 R /XYZ 56.6929 510.7044 null] +/D [1138 0 R /XYZ 56.6929 448.2896 null] >> endobj 174 0 obj << -/D [1138 0 R /XYZ 56.6929 421.9372 null] +/D [1138 0 R /XYZ 56.6929 356.0575 null] >> endobj 1144 0 obj << -/D [1138 0 R /XYZ 56.6929 391.3503 null] +/D [1138 0 R /XYZ 56.6929 324.2991 null] >> endobj 178 0 obj << -/D [1138 0 R /XYZ 56.6929 345.2074 null] +/D [1138 0 R /XYZ 56.6929 275.4888 null] >> endobj 1145 0 obj << -/D [1138 0 R /XYZ 56.6929 317.2705 null] ->> endobj -182 0 obj << -/D [1138 0 R /XYZ 56.6929 120.3964 null] ->> endobj -1146 0 obj << -/D [1138 0 R /XYZ 56.6929 92.4595 null] +/D [1138 0 R /XYZ 56.6929 246.3805 null] >> endobj 1137 0 obj << -/Font << /F37 827 0 R /F21 738 0 R /F23 762 0 R /F39 927 0 R /F48 985 0 R /F41 969 0 R >> +/Font << /F37 827 0 R /F23 762 0 R /F21 738 0 R /F41 969 0 R /F39 927 0 R /F48 985 0 R >> /ProcSet [ /PDF /Text ] >> endobj -1149 0 obj << -/Length 3003 +1148 0 obj << +/Length 2935 /Filter /FlateDecode >> stream -xڥZ[sܶ~ׯطf 4O-Nb'7$y1T\j.v: -"[$~ٝ-}wgVcodEYlf4W4ՋuۋחW+E+뿟k^]>ry_.2sQ,#?\gA(ܟgl3,{hHgYΜwJ}oÄ^:iS̀(.$aPrܟbDLd/B(,V>]`bv^1KW'cGʪ(I^L4ILNeW6 ~y}蹫mja%M)錄RE[ʈk6}^5LY+7Qٞ$o9xjgN#f@b?m[ H*UV" -,XJQybq -L㾭M#Gӿ|}oy]tfgυ@@RSpe7 3ZTUO1MW?r(Pd9r: 'AIi7F8offJ93?͒E61a?ffHZMN}eq0<`f& Vv`!Ѓhڡ6/9UXp҃:PLݵ49jdvݒφ!HKv"}E ~,fQ ՞<=6Mp .x&S dnC,(UNρ8 p4;}Ov >wM6UOK4ats{?&!p E`7g24zF<>S8.(Dz<*\9ptѨ{.r5Jx%l`#0jHqe) -29Aw|@Em]7֞Bc[~0T~|ڃ6&Xjֶ][W+׆8I.BXLBB/v=ٜD]k2`2(7GA6yH!r8,0Qy=lKPG:2[ǫHtǑM۬iރ}MIO! d4t( q@܈Rҳ"se: -p2 gP9l7IfLS`_2&d:i(wp1 -nQp#0H%d(UO&ԌcnZ0WS$7<ϙDfj*X1?ʮ Vk`G2#|jGt -N2M:JBa"YfF9V˔PY5>h577mQ2[W2Eˋ6QA(s9 z 4ȟR? kXyMA'$} -M1lĴ#g"8+~@ʀ3QE0ZP&miJ&B BvfS3q v1B1x/~qbhN^PwU7\~+$ L aVJVdX5^R1@C MXl!P_ -y Qq Ă8২Xt+S ¾*a.BPy@%Ѥ<  㼐΢Oqy9xzX3{Cw"ghah޲?^~%ح>DM_m*8(HyCYG8! O'Ag`I]5:v<lvL p C۲)KR,зKm{Go=eJcT6QF(NcvpFr̤!x+S=Af$z-&V-2Iu2yR"LP=;b-/5 b,pooJHNmNGн7fkH4ڗe]:M Ku ",JXCzHAVFe " ף= R^yo-JgWlǍ!t8Psrc7m9rB (Ʒ0?`J[o#eCUjL$W&"!JQM QB|^6}Jl5Jeg -OݩO̔'ىIOLn*ػeS02xx06xzǯk -N/bbg)齦;"q~k)ʺ1䇆b!yOa\xE?W O='ml~ac^ >?gPݜF[J|3f{MJb+|X'Sc؉FcTnRvL╀,>Ȋ?VEiQw}E`+ٽ )38DžcvZ}P}e*B4:zު M0p59~efcē@C]|dU*_" WP)a/VcJɈ)L#n@-r> {j<,¾oԪ|{G GK:5_?X8B%MS3'JM^O%~X5e}endstream +xڥZ[s~ׯ[n͓l˱I%34I@!@jtgs\3?=HEl=S{L˜g^}Φ<̖w,RYg,/&Vs/D/\k=-xÕw穛/?]_baY-<\g"spTd,=BCE:l{bZ߳99@0S6̤=:،P(*"r _5]ۯguŕjIg姮:S6`t҆7uVeSǵbw9un-͒on-Wm<_AXf:a}3[ۍao=+\=pY<_fph<5lɺ(K L9xhk:0\np j" 1|ץI/j wRU\׍;@UOiĽhF/S;»n6cEX~@a͝"ј4xu ɒoD*8Nz99S*1qU?ulq +,M J-o~83Ty]t^+/Výk7/<>blyAðľ\jJ슆 U#3@ȪśqpQ̈́RxO ti"E!p%r22=MQ!'4RVAwW&@ktAgbcXC f`"7MD\h6&|]PŁ0ZC $P%K:%$%bMmkÒϤ7ߑ +6ʧT$0e%Dd 8V I +"ԚxZWB[|~zA( ^#9 #:@iDXʓ +х®/ŦF[LoʿU Kgʳcrz1Pȱ+@V#daPU)!;ag#@1AXk!p1~abhI\̣pz+C7t 萰%5ɿm k~rXGz,C14bW@]^}|-P]nщ#q܂8Dt+c 'T<-Cn! t@kR*STȆӎՁ.dhSu^OkB 3u9^|X_C;^U,Z ab$\D*8QԅM8,{.߷10>uݖ{9F~`f}T&)`)у'}x|OA=ư,QE$# ` 2(91`H)퓌gJIA({g$;i%ZY<|YWy2B'×%'ĽxP\ҋMwUb-M!䇆c>{/aB"}{C= SjHjf3pg +41_NY7endstream endobj -1148 0 obj << +1147 0 obj << /Type /Page -/Contents 1149 0 R -/Resources 1147 0 R +/Contents 1148 0 R +/Resources 1146 0 R /MediaBox [0 0 595.2756 841.8898] /Parent 1155 0 R /Annots [ 1152 0 R ] @@ -3771,59 +3762,66 @@ endobj 1152 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [101.3082 428.2743 169.9802 440.1745] +/Rect [101.3082 379.428 169.9802 391.3282] /Subtype /Link /A << /S /GoTo /D (dynamic_update_policies) >> >> endobj +1149 0 obj << +/D [1147 0 R /XYZ 85.0394 794.5015 null] +>> endobj +182 0 obj << +/D [1147 0 R /XYZ 85.0394 769.5949 null] +>> endobj 1150 0 obj << -/D [1148 0 R /XYZ 85.0394 794.5015 null] +/D [1147 0 R /XYZ 85.0394 749.2913 null] >> endobj 186 0 obj << -/D [1148 0 R /XYZ 85.0394 599.3467 null] +/D [1147 0 R /XYZ 85.0394 546.785 null] >> endobj 1151 0 obj << -/D [1148 0 R /XYZ 85.0394 570.7212 null] +/D [1147 0 R /XYZ 85.0394 519.0032 null] >> endobj 190 0 obj << -/D [1148 0 R /XYZ 85.0394 411.9765 null] +/D [1147 0 R /XYZ 85.0394 364.477 null] >> endobj 1153 0 obj << -/D [1148 0 R /XYZ 85.0394 386.1565 null] +/D [1147 0 R /XYZ 85.0394 339.5007 null] >> endobj 194 0 obj << -/D [1148 0 R /XYZ 85.0394 219.8396 null] +/D [1147 0 R /XYZ 85.0394 175.6792 null] >> endobj 1154 0 obj << -/D [1148 0 R /XYZ 85.0394 186.413 null] +/D [1147 0 R /XYZ 85.0394 143.0963 null] >> endobj -1147 0 obj << -/Font << /F37 827 0 R /F41 969 0 R /F23 762 0 R /F39 927 0 R /F21 738 0 R /F14 765 0 R >> +1146 0 obj << +/Font << /F37 827 0 R /F21 738 0 R /F23 762 0 R /F41 969 0 R /F39 927 0 R /F14 765 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1158 0 obj << -/Length 3066 +/Length 3228 /Filter /FlateDecode >> stream -xڥZQs6~ط^EjIznM+ګVRW?Ү|}L!eO.ty/HH4Bǒg8,y†Qa/Zn[m0Uc(atR(GD`qÂ߮j][zN-Ӷ<þ L|l<Mf!W`I-2oAVX)vۧ6=hһO05bB2J1+b%L'[ ( -58Joy<2sL9Ug*|bZ* K1Eł-yKSUg4@~u~Dz;ԵI'~P3ȣWmޘj,,p\e R&^!Czu&ySAӣg9"2*o"!Չ0kSkpDi; QG.LԒ 1oN^81'&𬟏/Hl4t~qV܉(&zZq -ߎ^BqF^H(Kl;y2P6 -b8q޴@$^m_#:e0o9wwhL밵D^ /8+v$U-#&f[%!,kJvPS΄'z+r"טw.*SN @!t2<:icq_d39۪;-Ts; ml8jA|Qe;> ͆1.ұiGQD7؂)IU<%,͜}E}"Yi ->h(I:w8xٺCu|OtL,hC; -'dKLӜ)aV~x -:nx~p[e8K<p'L6aLu-0[vڎ -;T(̓WБ=ulEciІW2$tSeCh@q2fLIׯ\L@!ξM˱Qg'4&Je6mpb1  2p pM"_;>$nfi=kL* -Oi(K5wq7*>֖iл0`IN<`b0wgkxzlUmoDQFR^QU I8D-կt31tqoB"њw:1O-F4gv)-ou!p2͘TʜnN\]TBf/wQHJ29пq] *B ~]W[t@"= vn޽=g; 7scO߀P3 -, -RM0X~bp^kSWE@{͸q_?|og/jF\Ҁ",:U -H*7kh"g4"2cbV9+CwpyVMq: -1LECC8{!2V?FEIѥkmLVeQ$h uOatMb5u,P$S BחH>Q L<&D$>eӂdy }-J\5~-0T^)K|":='/bf>jPd&B)7[×gc#3/efl,RI\],f}|9.PvԽwd,pel˱&@l+0EF/}W:o3E&OǿuHH}",I6\RwHendstream +xڥ]sܶ]Bo&>[NLRi>x$GGew'LG3X/\, +Y\Ekj!.`q6i37*,"l/ c˻( +vZ\mU绛0P $߽yMSRUFw|s{ݏ7w9/PH䇋_5ㅈUa# D_Z:UCڋۋ gnlKH&]ę)"P%u;nHs# D}ejt5횩)'[p-a6=,G{D]tc+Y\/,hO/IUOP=00Mąҭ-p@faIGpHƑThS>n)/bQEקw ѾJf[X䌼B0cӶn*Γ\bg) 0aC&QXN9aF`^Yt}?!ˈ:Фg?U{@eE~¡ta_N ԓl@ɢj 4pqgܱjۊKT'L&. >خq+W/W6}mAΣlGGg3fLlMi7l ZTmeB^*$ˊ$hfS- l4tQ쭠 q +r BlxW;@gUNr)AI $OGM"Yz. 12޾{eQA;l[G&<no^2!d:ƈA`%o5jBjhx7|J~Plg>C*CU + VpܶM xFȅB[A|Ap;"BFeˤ` ?)y˽$ls~ (-l/!/4}TQcg;=B\pA[ֶkmOeaf הp&s$dN.z6ulfhW?2b[ٔplFĝ5XYoe #߃³[Y2 w3_'2aU wly `_pt_+:욊i(ZgBsPd#C?Ͷ45QjOnmu<4PD*+2l,"ad!,4nNFw3pNxgH3u1A*B)FeDX0r1o+Ux j`vY مk+q CH!PΊQT;;ݟ |BSDr +@8v!;ó0ΏgNyi'pb &;0,tG=KnymGt B4s0|.*r9\sN-m:Y +.BaB[ea}?Gl>r +N +*άr6eZf[Nxt3 +/4G~6%><@Zuwq&f>|f'r@vI2afby'ŭCMkRu;㖆H**ZԻ2]E?_ ǜ%}:-zit7zM#: 9p +8oHD,?Wd,O!g-mrŠy>"<-&ɓH/`Le;?vHu8!\WC +Ѿ?4I) i(e 5mMhx%=+TDR+JyS)xB(bxyPf9֪%|;.T8:UPr,WAo)ӄi`qŹs"HvJ1p,6y07 ]eD9,׮dMif!nם]j7MQV[=xؿHlaoHeԻ݄S/ad((B;?9MsidR +jmC%xzUm8F"=ge(޼p:x y4au>}N?0?aNg1 I'PI7{Ce62C :_JtA Dw#"a1[ +b8 ;"^]D.̞RUII*JEtS5Oxf #tϺ,@h-tD{^secN=/+T϶sz]R!BozG™Qf&.D(~o% _vMCIǑŨ㝀W:s6*w]mN +1cPIf^X*@>Ww{B^ЄDߤLkIMB'!֣`kKβcz4~pW9^p| +P!Q; -]EIMYgN~ɟW%QETV˸/@˛F" ^tٔpK-0vz 2u'?U +Sb军oOs +EceoWd".cq$k!׉TQ+yKŹ^H@}/%} 8W(^qVոPX){{+q@W3?L>8lӂ5.w?}KKw.\J)jiIu+_3̄&ja冧):2I@mo5͡󤝪x~+Ӝ,b$i4$x>%D5zfa?§D'WPMuo> endobj 198 0 obj << -/D [1157 0 R /XYZ 56.6929 714.3337 null] +/D [1157 0 R /XYZ 56.6929 678.9507 null] >> endobj 1160 0 obj << -/D [1157 0 R /XYZ 56.6929 679.6003 null] +/D [1157 0 R /XYZ 56.6929 644.5195 null] >> endobj 202 0 obj << -/D [1157 0 R /XYZ 56.6929 548.3115 null] +/D [1157 0 R /XYZ 56.6929 514.5361 null] >> endobj 1161 0 obj << -/D [1157 0 R /XYZ 56.6929 514.8119 null] +/D [1157 0 R /XYZ 56.6929 481.3387 null] >> endobj 206 0 obj << -/D [1157 0 R /XYZ 56.6929 311.7264 null] +/D [1157 0 R /XYZ 56.6929 279.5586 null] >> endobj 1162 0 obj << -/D [1157 0 R /XYZ 56.6929 283.0279 null] +/D [1157 0 R /XYZ 56.6929 251.1623 null] >> endobj 1156 0 obj << /Font << /F37 827 0 R /F23 762 0 R /F21 738 0 R /F39 927 0 R /F41 969 0 R /F48 985 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1165 0 obj << -/Length 3191 +/Length 3214 /Filter /FlateDecode >> stream -xڥV8s&te}4$ =;N$n|It؟*؉8KRTR`6гl.@g3os;cjP/vW7вÐN>}9 씦N?;: 0Lx} g'\ݴvol/{?\ńp=r1x`gVn5IN`MbsB,,eLX.Ck⢮!YϪ2ϢI=]"euA9qU'1AMIYF^RE a:n|U6dn twr` !ױp+Zk oMh4_D֎E"v"Ā%#DEO - !qmkc+ | 4T@ptAY1P6\-__MZd1&1 w\V@VZgڬ{8WQ66GkrSUbFDj#[ހZTFTx`>c=G*ʲ,v+ DMOsZLTH9CxPQ]vgڨiA mC$6f4,ef -,O$: ppR&8EQꊤ{:"DE:]u} d -G:- ݨSQA.7g" 3{0,iN$ӭ3~G \5UCV(¨sUW$)~k Vߨf#ixXnRD92(Yn~[nRj[uѳT^x['. QMѠBɒ;D* &- qk#FlG&Z$}G*AߠԲ`f110W.Q䊆&T3Q ,pIJi)m4k.}n[j#>6u!m٨`E7谭I}!&a`\L5$IPoνb9V*-˴hq5n[sU|U8~C ~ 2p`QFgC{@%tpSyNQD;B$¥9Hɥ:Z輻vURZ0vb)gN ,^*9py% -VWuӯ*9;]M21nGj\זLJm%V]7r-ssS}4냧J@E5VW,G8r^Q(*!.r˞{'FHnR08jF*+F:QPMղP)3)a^0hBNezVó$,RFLjETL۴Mu.k6HR5x͏9: -&PֆBK8m%vZVPgG =K9Cӷ罢ă2hof-}o}]2F0\,fI0HWq2aIGi\6zZzei@h4:zeWJ~r#}~p/vxZ+-'Q3tP%N6 #aF[}))PHH%-'IyAg*]H(ϔ-2U96$F[EN*}fHx+hCi{i=d[y5wDٶkK^·z\VMC@RIL A"[\yL#FOlL6qH|S=oy -7Ma-q/Ki3NiNu redl*ωX=8Y G*9;0DGq)@HgkB{•(VdeS=&C@)QҏE0B6 巤kֶvR)%2xG3Rw -\ rj^gCt 4z~B\R| ..!N:d'0/* t*ؿ#@>3*pԆOPd*3c^2@ܨmm*iժ<}v+H\tI$1CtBۀe Ǻ,;R }fQ8&քMe4Mx\=bA ]={F1bZzx o0{˶&A+i%d/eUuyZ'za-30ňPİZ,Yr햾>,[*rb!+S{PNyځZ˩t&F%I${~dc } -ͯt__pZMeC {'NbrIgg+>FiL/=\~^~-L'CvwdU8=qnEm.c.?߯c)+ڹ[}Q$Q=ο4Y};Z~f?;˪C=\>~RBwvt8IN?&^8\?AW?ǻt~M 8+m}e n|5j50/nSHa -}~_c/* -< bp|sD+:6?v_*endstream +xڥr8_ڪw" xa|%qd|d%Rc#o7AvK@w7%mгl@g p؇s{s x,wWвPޞ|>;=rۣOGB9M_Qn/"INXvsqvw-[["yo0˼;-B^lK('-ϕ@[Yu+ -/t8r-| SȖ#JqITQEE, AfA $P ՑG24i/۳'#1jvD%zsR4;'6pWz#ZL"FTIfe>F{BX 9G5j'K!p%:rZ\uL@լ*,$X!Ra0;U#a(鹪FMIy >-ьuj48^?35Y9ulA~KoF6m;YRKa.,cUG)4O h"O:{b*A uOzcڣjSGbT/^5h7 m ŏibݥ/v fIۓk:+`7}F8oهc׶-a_u&V,pmnyo`?8.g ?P}ᘧaANrк:E9/hѳN)ߒUb3 QǁhD ݧq)'R[c4eY)8EC05p^ ,Wl.lA`/ `&+Gce4bd )q=WvXZ +]:ϒ4!9V +^k 0slcW"&JtW!ȯWĚ=&,d׶lv~3@rC0j./35A!(]??·B[(d2&1tFC'07݋ڢ{ lu#_>𜓬k0"H麖5aeGql ,tM&b|$R: ZSMC*0z;ӆ5-L z<LXBtFҼoQ̆\S67rw 'h5,Hg!(qN4\Dkoed*]SZI(xQW>V@fxӑn(gf%=Ӡb9`[YyEOTj" ^/YZǃTo~0Gw1C{͠ ,7k) |z:rC_ƴ,f/1ġ~;A|'5 r SEQ !F9=8 NC 3-: (,O"F׎958HAO:!~mˮ gm6LK찬j g^GږFIN~q_ۅ04ɳQ7谝}!wC}o85IpԐʞz6H+vq2-[{F{KNUb4&IU@n +}G9 +TiJ制miGP84*Gz-ƿWI3tJ]ZI:-N WWnݼW,PYww%(ݤn`dF&](wJ4 ŒxzyuN(H%]a&`%!4TaQ1]o3xCOTeae/iy&1 ڛ Ce^2\u`iԝRfIch\ŅtңNʥq-j*o^bei@`:j0Ϋh ?YN?[DKWY-u)G'TI SD(Kk݅o10AU.}((Rb `K -'Inh>ɷT[bԷ-2㪾ѵlJM5y2: (FQBGh2}HeKƈn;c4u#{;USΧӦeCՒіBiDg4l!D[8&Է(%l!Ӥd'J'F7R󲿨#Lq,q9]库Hv&wE>c}|1n4)Hrg@D =ʂee3Z]"`m`TdBPH׼`6. d |zid2n/RFҩ^>8HIn}TRaȗzA3)tu_>޻ ee@8Ath5G\IIࠢVf`=Ij8 Fb "fUSSyJ̣"}b钞dHZTƎzk6]O9=(v X=sncjyII G(g5h\ll .Bxgr{mM"T4WZK\yrubh7;@ +d#.B6Xiiɏ9Nd=ږ5Ab% oZwq(e˱ՁWTSOz:%IDz*o~ܶ{9hEڤQ6ֽX8^@{tzu>V*ٻ_>v>/'MP_\iv=y>uL;wߪ7Q~Yǧw 5ޝ7'o ry}9w*xToOWI!5+>dvr~f(~Ƿo~>5,χb?ȪC=_~89Ep==Irv|/!ҳw?d@e:2sT`{:.JI/)Iendstream endobj 1164 0 obj << /Type /Page @@ -3885,35 +3878,41 @@ endobj /D [1164 0 R /XYZ 85.0394 794.5015 null] >> endobj 210 0 obj << -/D [1164 0 R /XYZ 85.0394 701.5077 null] +/D [1164 0 R /XYZ 85.0394 672.4905 null] >> endobj 1167 0 obj << -/D [1164 0 R /XYZ 85.0394 671.1418 null] +/D [1164 0 R /XYZ 85.0394 642.5136 null] >> endobj 214 0 obj << -/D [1164 0 R /XYZ 85.0394 474.6626 null] +/D [1164 0 R /XYZ 85.0394 448.2445 null] >> endobj 1168 0 obj << -/D [1164 0 R /XYZ 85.0394 446.9467 null] +/D [1164 0 R /XYZ 85.0394 420.9177 null] >> endobj 1163 0 obj << /Font << /F37 827 0 R /F23 762 0 R /F21 738 0 R /F41 969 0 R /F48 985 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1171 0 obj << -/Length 1997 +/Length 2035 /Filter /FlateDecode >> stream -xڭXٓH˜u:(bluv} -m?fh<~K8AFrIyHJ~L.T{z^oX,ɜ, mlI$XҬ<'qjljVjP&DkM+5Db" e^fKaKToFE˚>m*k@8wxwPh0aY"3}eTڽs_f/jZ8T>Q[2$0Y^釖>ţ,/n"R52uYU}]۫SS23ټaM\֦5}4pt{o_~dtD 4[C4(D8ڇ}+5?21^$į&dQ -'d (Y݄#㝈#nF_و,r ;.pcy35$`@,~͝}1v{p1'AƹhМ 9WBRޫP CZ> ]m-hLwZx){u^z_wMsڜP;h{{8.Bm,/!nכƎ?y։iY/MokǗD&wn._ Ceט&x]fV۪5ѳ;ǏwaÜV/>9|b*.ºO~g/ҷuRXS{G1&Ov۟cFx(@Q0נ6UuGL' nYQ3^l2h0 >]ȸVV`$-d‚VR -0lmcq3 \]ՙre(~[װuoꪢR"*?x~S4A<.Ҟ&me}gq}bmQl,{5`q.I޵"J} ޫ -ְ>;e6V -) DIul_4YHXNO4֮mk=}'܏>xMF#4ɂ:u+yCso^Ow1m - mfՎ!EOY}MV藡.hBGA!8Y&|0D(bzɻWS$2DG`8,BfX`1Jc$etȢtEIi`YQ=3&XJP6&^1zX?s1*)!pr?A:S)_T -F:JrIR9qsGKǪt9z]܋Ǯ`Pf [2ҩH9-,ڄ1O݀xPNYw؋dݛ%ȯ,i@1[t0wj3vgk[Lw">Ӂy0 OZ(Y({:HČ<2rcx>=,عoĀRYMQg3-kt_)a$mKiI|yg\F9wtz:;%CJt2|dH1=zqL_ED? Q/.hZ>$y3oP6)#_JOI+̂fWY(s:\,/2iH 3nx OE:('< -isEt 3$C.KH*rYendstream +xڥےH˜*K[m׍)(ff#NtDWXJgx J%A\2ol&xjC}}"$1VAI5+sT)JQ cTnt5T!f e7g@>jDvQU\Yզ-{kO ^%~-ę Iĥ ` I0b0)oS`n- +`xX, #X4.؝}ےb ~S4y6wV-QY0n澏V9B鯷VJdtl᭵Ǣh5!+y2xy5Nvm8+>Ojen(W{Qb+lG{ou?E⋽m_MuQ5q^Uc(. o˶ +38}B缹,; ¶B`\7rKsz3Gg7T;!큠YcT.%v+Qd}}@ֵU500B{Q[mvO]ܱ׸'v%paݘ_]]mrYX n19s>>JCu]ݥg5q-(ƪJu?Ͼ{C +Uj:[ad}5C`p@APNA&9!UtRgF-zE +wk]{>&=ŠA,jcs_Y (W,,|w3pڪ?jP'{ +eUlݗu|6}!~waf零̈\}l*m?Ity_̻Er-wpY o~u[dFW^ͣ=:Y>h,{6I Y{H޲s&yLUc5m ϓ +%wgP׎e=mϷ]9xG#$^mb!@,Fo\-w ޳~YF5͊ Y\3ϾcVMb G<&3HG1b@r,kYtKdecǫA ܭtr%pl9vG`2a3' 'S]"8^b(|\]%%{>_yMJ7 (ܱCJ|o'iJ~~ +  + +HcNFe}J ,]d7EGGxm-#~h=B&aCo/ۧ:I*~'DD7Q(EPMPQ)B^gʣ\ˏ0$1'r~@f4yXѓ)hv)Ꮢ!J(GDE╄Hwt};SFH n.S +mZ8 |z.A4ǥmzu:-=`> stream -xڥ]s6ݿB@X>~On9MhPBRֹvɴ{3gX.(1'ff\,cг`pibxwJg9V,w7<|m.ί_|W|8qtVHs;yy[Bx?U?^^9ϻ_N.FIBiW(Ʒ?3gz g"l}kt_OnO~ FJLV!YxV>[4e-Z'U4? -3J@WWp*} 4iC#Ci*z# ǘrcs[IqU%*QgΓ|ط:ńh)f"f*NdWX@I9vO#n6m7Фj&Aת9ȫ5hXmm9KhiOQo%Miل}}3Ž9ZD -5͎g\Otiw +Gu|'(dS -ہVĤIGb ! Q8ƸzSPjǩ VepDl{$OX*2*6GbX!_UHeKSj6`~p+`N^?nshMkN=u['"a5(=Ep4lgSf ZZn;H]r1@9 M05vU%nKJjQʚnT/VoeW*sKf̷d{%jpqQ_ótA1J3B .G݃Vu|-H|/nU:g|@qJw8u̕[s>GUL76+:]ڰ`;^Zmx2&ºM]}5DZC&o7fYa ~*UBkBP ?dS3-0aAbqhO=OU>1~uT|+Mp PYyiyR mȀYjpg >>zRAuճ^(aBٯr $qNC#nar֚{dWKC#`*_{Nox0 `qW${i&_A[ed.14"WG7POȄGu0N2J\_S<|!Hw|5!ϟ>}4x[xs4\\?ҊH^{4+A_.PY< +EB*RnH[[,3NO)y(XBr}IeEUDSCKj 4o. ^φGc^7m _ՖLCRazZ]l!4TN6F@q1[qjf^xQ +pTP&:Eiq"(-"\ Ou["uuf]iLsEHl=hN$yB9 *:@.B iYښUFK+0W2|ܬC8oxLbJH%!Be۵sG׸ì" z ir!e%hʞv0,"ƾlۣԝs Hx\cw/ܴ/2/!VpTncvN$;XGz-}YWzaʧ9f9'>/PO0=уO8/Rj"lxaOvkQզD#rKe|aŔJ(E).%+f(&FUkt D+| 턛A(S pxӤ=#V +ҘUUuF1šcs[R[U)>7wV Xy#᎖bE҉+8,RjjY0oa-jvvrd{R-$P*#og'=-=GՊ˖.!vh) H,`ϛ(W[D}{ÚWw,+]%Ai?7WFsg-׮X`<_4,mX3|YJf+P{K`M9 |N6_O06N]A$ z Hw2(ls-Lp9e 2tU];-44я U6|Oh`߱[6#WvƖ40JRt2)mbAmW PA?4 )22ETbXσR UE@Ka\ȱ`L͜ +6,>Ge^)u7!sүXNzY[`D' )ޑt0J\8Q/@J6T%/T59e/$4LeE= z +01ɤYPU|w\XmDV1 +l7$Kp_ő>${`ogj[Tm]zada}έ"8gYTGbijGN{b+lPN lMMЕZf[I懶TdPl5b!_UHeKC5`~tA0I +'pּ8r5rG^aA٨fKSM~ %X^0*CՅsto;ť1@9}(c#D`* : Jܖ,}(!D{pnT/Vt^5=Wfϣ'ݵ-nD .5rg㽯TA1ИӒ[P'~^3G5.jTW [Ș':b Ԑs_  +4r@O:0IJXt%s6KZD{}E^|rҜ$=ص قh'u0IV5uѧw |^5 +OSG\]~V}I +n~hBN->PY:_#pE-oŴS<|G)mC[)2j\]a{~OzH&z6EiRQYRC]iK.Ki2z}BK s @>V*o߮!$Y97ExSџd[O! u!9oyFʸ%)E9os=Cj%ݖ/ENT{Q؊\, +`|/-$^#͏Q AcF;7Z''d!:!bzYSY]=F$q.Lhc&9تv?bt@Y}ƾH1jrr};Mac͉3h tvbJ0kv^Z%t⺎0\oo: UV}DI> >> endobj @@ -3966,22 +3969,22 @@ endobj /D [1174 0 R /XYZ 85.0394 794.5015 null] >> endobj 218 0 obj << -/D [1174 0 R /XYZ 85.0394 558.7948 null] +/D [1174 0 R /XYZ 85.0394 526.6811 null] >> endobj 1180 0 obj << -/D [1174 0 R /XYZ 85.0394 526.9277 null] +/D [1174 0 R /XYZ 85.0394 493.9549 null] >> endobj 222 0 obj << -/D [1174 0 R /XYZ 85.0394 332.8718 null] +/D [1174 0 R /XYZ 85.0394 296.1882 null] >> endobj 1182 0 obj << -/D [1174 0 R /XYZ 85.0394 303.8962 null] +/D [1174 0 R /XYZ 85.0394 266.3534 null] >> endobj 226 0 obj << -/D [1174 0 R /XYZ 85.0394 175.3419 null] +/D [1174 0 R /XYZ 85.0394 134.6732 null] >> endobj 1183 0 obj << -/D [1174 0 R /XYZ 85.0394 146.3662 null] +/D [1174 0 R /XYZ 85.0394 104.8385 null] >> endobj 1173 0 obj << /Font << /F37 827 0 R /F23 762 0 R /F62 1100 0 R /F65 1179 0 R /F21 738 0 R /F39 927 0 R /F41 969 0 R >> @@ -3989,14 +3992,13 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 1187 0 obj << -/Length 317 +/Length 383 /Filter /FlateDecode >> stream -xڥ?o0w -ΐ4%2T@ہV~h$TYL n,X/=ϼda_-'=5A`7cqJsO:GMdF:Sz,xDC)KWI':> endobj 1312 0 obj << -/Length 1151 +/Length 1157 /Filter /FlateDecode >> stream xڽX]6}T} &OwfӸ! `䀼Wl6M{8:Ca AŅ d=.@7[ 8tQr!r]lM 4~wswj7w۷W._~'S`% f<_Gx_Kul!3dfoR2볹A Af2H4c~Xݚ6$! ڸ" FfSL@Ua+/P~lƆ7CnS1bU& έgU j -/dy6UcC9]&a hS4'},H9,5\i- H:%xvYV:ǚ HrF.bq.EO]vяmZl#(#VJEFscUBu{]4C3aeEQjD/N2:\JbS4h0~ʸ7Le`Q1'uslyyEyXӲ#}(EaeeW*YzGYb 7xYp^nC >T>]]lRm*5\@J8k( -ΝPע㹝gm{=C jZ;.HNV7*W/W f \/JK#[Cýeh\8Oj~a+.6 /_A@9 VpH9O^KBj qL*;D'sp'^*#YK=6Cv)tK-BXq^&H@A~=c!<]IL;rly:޿]8՞%Hzq?m}f ϗSJ'Ri77M4:"gFlWzR^@ێ;azz-gNtk>01 -Y ͒XuUQOP' JY1H%YqUsN`v8p*/>-mʸ.oZ9$܅k@ +/dy6UcC9]&a hS4'},H9,5\i- H:%xvYV:ǚ HrF.bq.EO]vяmZl#(#VJEFscUBu{]4C3UiZ&^tFg}:t!åabT4h0~ʸOLe`jQ1'uslyyEypĄCGP=TT8Xˮ;-Tr_>}*odKݽ.݆&}}bko2k^|*UjݹpP;͵,Eŝ5s&{fS߇*A4x\4oxdn{Uv_X^ 1GN{i<8;`и}Z#V:\l@ #o_Rs2rrbR,82˙TwN,0$.O(U Gٳ*zmR\~[/[W=GLeH=4*{42fC.ͳy~ _v'j+0ѾE횈Ʃ/aGҋl}f ϗSJ'R77M4:"gFlWzR^@ێ;azz-gNtk>01 +Y ͒XuUQOP' JY1H%YqUN`vDp6/> -mʸ.rZ9$܅k@ R -maԓendstream +m+'endstream endobj 1311 0 obj << /Type /Page @@ -4879,20 +4880,18 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 1316 0 obj << -/Length 2010 +/Length 2088 /Filter /FlateDecode >> stream -xڭYs6 _GnHI).-2rEǺɒ'Iݭ%GMw)@|r"࿜Ċ ? &Qp%,gbrޜIZ&nvM^8-{b.XNf.~]ޞ3Oiϙ -o/Σ`:~{C˫˛חLJyÍ.i/n~ZMwj^}Yej -jHgҎ啕'ÈOء4)о,rgYјA'$> WZ)mLlNFKR XfeY 1+wzX nxEY4zќ|cYi#Ǫb/{Y'h%K͚&?5|]LMc<䟮##v'3il>^= C}L4*k`|''y&+ <8y "}Mon7 -v! -&Ʃ{3h"cj2=&$ yZ -C}q?MSn>/_ `:7@mRwlc -1+vH- F)4[é%Fo﷕&;U2^Yxj ddž1D~ٳlEto@v ʤs"*/>f8*#*&BCHȚy 9U.< .RpnǿsOю ԁrf(w\#~%Cy^>pdu0JwIS![ܦs(H\R `ڭUYJXh`w&DoՅKmClIk^+mj۽pW黋2N#):~rQ][#M-{`'s9;AZ Z/H׎2XHB{?ͺ)'3"P]gܑ*).D0KdA`Yk+ mCڎ;i &'< En]* MWߎuI$D%,nË#< -ɶOq՘ҳ(W- -ym.[ Rlд8Fuz T|"K@(B,D@)w$h#Jj"=UEqIcDiQph\qOBftlh-ޑ \tgfp -8f sW)$2p¼%:ұs)e~I}˧%{Z0J:JD'ȺGo70< C@n@(S%1҈~K[jV|Kj[0#_U;}[pW.;ڌ0^%)lV[HhΧiwKՏx4|0$b2>L%FғxsaR:޾yeN7o }7n.=H}+o3#/\]~|1w<@CO20 ΂4=_;/ s}UߗzƂDOJoZ+-kO5^UK}‚`K֫Z7kǧm~0Q^dDS,lo *rW*U]m<3R-/ ZcfV}ZT5^Ynu恑+nJI0yU=K>X@e%]v7zo!u]N +ًie۞),Ue K +0Ł޴z}Ẕq$*U˗Vʹ ݯ>ks;(z ^@ӎ'ߑoЗF,Zt3.茠ŁNra׹v"p1./vr$h)2RbEAMaW+.CLAHӛ!zH.rrql$Mŷ=S xL:'EQ-$pbʘpDK0^%-X"!5.yQd'=KBL/\GmcGJ)]|Չpga$wT#dACWEQI4݀w-|zu:f$I( C{5\3e:$Z wfCǘb9efzQ:L;P *0<]1tB+:{Sk kfƎ/*}%b[I'5U:2`qkSqa1p]t1@ےڇTF 5M(:l1| *-Bl,KX7mej{㖰Gs-8v@-sW4o%d2wec5`B@ǑOUK((RXja$Bs u2!6Xle2$FA7Oi 1oٷa!ʶ}oHW7NUG&Ft}aur<6b[`h{ ^Ny'sruh|_ڦlFăuSoxn`f_튌U%t x$̻@e۲?Tl2ZN2A)nxViU/rSi("? KK7Y~t=]}s14cW6d~R9C mv*cZU!T_6icdggwry)Y$V)t{jT endstream endobj 1315 0 obj << /Type /Page @@ -4905,32 +4904,35 @@ endobj /D [1315 0 R /XYZ 85.0394 794.5015 null] >> endobj 350 0 obj << -/D [1315 0 R /XYZ 85.0394 310.7111 null] +/D [1315 0 R /XYZ 85.0394 324.4359 null] >> endobj 1074 0 obj << -/D [1315 0 R /XYZ 85.0394 278.4988 null] +/D [1315 0 R /XYZ 85.0394 293.3322 null] >> endobj 1314 0 obj << /Font << /F37 827 0 R /F41 969 0 R /F21 738 0 R /F23 762 0 R /F53 1062 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1321 0 obj << -/Length 3418 +/Length 3340 /Filter /FlateDecode >> stream -xڽZs_QSI$O>wu8N'L)9HNb ݥbX,~P|g2bYD 7|ᇫs{GꊍwwEЏ7o>]~XxE_/~V.XT^\p2 -"K)/>]e8C,8t0FLy D xUc(LmݶŢ-md]QWYDjzʲ~!RF_yGzmʒEr }̚9Oe|4*YV6 +JP/dvY' 5Cӓq*_Ͷ/`W_Gz3vм;̪5 uU̘w嵏u_C,zJx6_uA" >:\$JP~u0ާm )iczKgD 3 -+ree\? 5<i|p |\J W_Qk tc:mְ>fϹn-ajmXaό}r#_pr&ьZeT c{Zz˾uT(N*@D5Z쬌u~Cm4ă9|m(ZhqV[6$Dځz* b6Ghݘ K41V#̳ -VsV:D&I T}Uնϖ|hCRLgŊXPXL!=#!q<=C앀:biX$xdP\uV^ !<] a{?A|,8A &-ojN - C+ڠ8@1DXĉ;Z{a4`: M`"Čp [BwGjtuLVv01JlP ZcWDJa\Ґ0$4[Z,tUSAku hqỠ煔^ RԭdҾ1ﮉňzN#/[6ӆ#P43ai=8fɫ4)`iNyEa7]G{զ@2Ғ{cz9Z%~.`!. W;oK\7^^L0 6cm-m3OF@z)Gׇ0[Ay<2DvGL;Ȏ.Dnv3Z29fgI#3{':2ADߛQ)W6ǃ^6@H@jXE[}gxYH~^㉬H)m2F:oPUD^"Ƙ 2C)+r#_g}ّ^Z5?46 ׺ﶽEEl"mg^o>}Sڧe#>uWt4a9U㻈x "a9SF&:NMTEP.Ruz|je4<1\K<&5 g[uˁ&* Z~|8-HLcj p )6?.y q$r NDn?^֘ΆJy{7WG7 uK}#])MasVTD3Ȋ>P Z[4823c"`fJPM*--q/\up8~H\؁7AȥͥMVg$onYHD]pܔ+h~&ޝdl#hlC8i?-J ls -g:>iDD[j ~tZ4ƉjR~B&Ͱ@D -^8٪=΢g2ت.1|(*>ek -"PC0nu.A)N>p9fWAegng-dy\+[&|G8 6W:,fT2 x -7),<9,ttU -Xۼ;]Brq?tuC ]( aq1R[ VQ#Ϛd{f*j4 7I?խD&,Қ97CdUJE -!B~ˤ(_!f`gJk?8怖/i?ɽ[KJQIGʕ4ٝU[)]+Y :uJ)Wou18ƪxa!+Bp3g!++[f-dr"D#Q¶X1y8Jپ2~jx*j4 .)Qn7bO@(œq\VnvCwu8N'L)9HNb(ݵ X,~P|g* +"-,2Prsf0[Cwo߇L:~=,I~"]x_?^cx7b?Pǫ~8ywǫ?|xw{-hz`Ǜ/]{7O + B k-f @0t=ŧ f8 D pJk5P'^֦y9XycԬ^l2]>f (Jkܗ,u?Xk:|i;>KCͫKzϴ\Q*s04sh^XuyIk6-f-`'J2t$,Ӷab*WI#YjUIf$ZW)Fw44@LuVy`Ůh \^*sN2ۥUkڅNC0ÁEy_]}E{zoI7LmWچyzxAV#T7Ss}רrۋ՛8}3 e۸> UP#'JyҖZ3הVk`ަk,cֶ*huKU̘xtQ899б$tG+kh-)h`~aIT-Q";r)ů]N([c]Eblć>ă9ڹm'dN7a*8. +B'PO b=I,|Df"cK{9MI~2+y g,8QllemujցJg1[1_LaKxt0m;? -+ `Ï5oS.Lɽ|Ɵk>f,d~/+S!(X[h (6cwUkB l0֤a;#ĮYLkDuא! ?8)>ˁ=5x \kd+^,h ^)9`L2g$ca7n!L6VNiNd%$n(+ҳfnC%u٨/XbpQhe T.XemYS|>8V6)`NeYI%7SG{Ron;M^=šƎX{ vGCbeC\6>wߖo4^L9z5ZUeʎY+M=OE_㕛n.ajŃh&dE'R!"T T"Mzw%C0 #7}bkra"5St#fdlYq7꒬ޜ&i\0ԍgCGb@α#EqtҍPP +omz +!T8^ƴ9Y F!b[<% v[3jSXY~ʬ$,;:0zqLIݢp`.JNΟ8h }tsMlGOF+b4ؔs4C[DW<co ɸA&N>*\%&5=6ʊ}kէ4!4jX*a6i)X-7 4I$XFw clќEdSe'>]`b2XV`I;HZbkq'pB@'œʼn!iz_< d=<~Ow2Lw2Qr`:-quc3Ė+2 4Me .ۜ*N#Pb SSM2򢑀HpLR' fBV0G iQ,]J)2m붰v@\a3kgk&,-_ +'Bkz +;zAjhLc +5{Nʝm> d҇*foJ}( @tP.-* qVW3%6M}喨{8'.v P\rrz\FbSdSPt1 +rS;E_] TJ&@PBH+g2I ӷ{pr6Arġ1.lvxs-$ xPdO=sc-N1ȇD_!5%̥([Yמ:"݀49 ϭ/=6i-Y2[YW&ݵ4YPǰB6̄CVf(W4@񱆐 c*. ܝ+x.\GCl5hhD1b3ő˸%!]ԦQմ\aJ #Dj^޸hYhO(eS`%a6Jē龎2 ~ht:!`[^" +!R{~Ť_!j'A2QNXZ: Ƒ܏~į /yY-1 c?e#Tw-~h% -Nh g5Q+5VFbFMk,CoR611 +owePq@'s?\_r`5.i'dk'.e߻|T{HC:\'e>*q+f٫Mس^?Ym9! qȵ#8_O#0fS3?5L #tD-6Lw8D{qd G+;( +ntWu!t UQ^g :!bWʵ +N+T kW^a$'!J +եqav,F dendstream endobj 1320 0 obj << /Type /Page @@ -4947,22 +4949,26 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 1325 0 obj << -/Length 3572 +/Length 3655 /Filter /FlateDecode >> stream -xڽZݓ۶BoX8|cgi3$;q"HHQRL;A`,Č?1 *׳4paf =hhS}psFLfZY&f/W߽pv! 'va>ԓO߼{Ǘ?=usۅȌҭpf›w?SǗ?o?oWp3gf^8y.gm3Z)߳t`4jNOH%2g܀,QZ)K1%eOR.5P)ID>'ZE[ -@y:]?ފl+Z|Wm6ۢl|YCWԵt=UjO}K}OUS틾n]qZ"U;j}5Ѭ6u߭n܊ HfP yˍp-qLG\` A@V&S&a0I ߍzˍkYȦ-Jz&4$:u֣a%ieXoN(MՑ# =i7h|i\ᥬI%B)ܴmk? Zŀغn6%Ո :k_wd)K9]Dt< -iUՂDut$0ttӁ&ֵW{>{'zf3ɫu{?옋; ;Ѥ%Xne]5Ԫfêٵff!rq7ʹ"pU.'O"4<럏#Kvժ;iY=M nqS -kW)&DPH,ϲl:.ŠxIk + d٤6| ->tœw`N6kYt5db&g8Ɵg؜J7a0Ev`L"l01y T.ϙȘT:w|`&R1 |jjzǰM4X }%:h(Jk8`#]syvA2ys;YM.&\e A3!'I$ң'a'fv#̌-8d/_=})UOM°tnl6g5 !L}0^u/B?~E (5pvc5mSM.Zx\Ꭶ85 -z(0yAV~H2[~7] S"iMF:mP#0XyiV'm BTfݘ L3Ҷ nu. -8RLP׎q -9>֭4YmZ:FG=1ڟ ly@Sjuy\ 9&A`a 5bҭ1q5Ϊߊ6ks̸vu0+T -EO439koR;㑀"[)Y6ڵٷvx=Ϡ]Ь07(j*\fRH7@KhhWp, -R~փɄ!-K#;c(nQY4<L+r% fn_Nmt]|q6 ȗ G'>q$J舨.O;.唘_f PMp0ʉsbJ{ z V]60~_nBYMmp(I~a7: Ax=,ϣPpzTEQi:iLcл:t]:6'7]WPY30Mòzo2g -mC]կ}Vx+ݘ*7++wj]f!PM04!7󦐔7B&Ʀ8h}Y׫]xƦfAOR}1+l;^|]s0%XXXH:acr3dv v x-JF SG)8 :`Pvh<ԻaME*, 067u2OfWr'_f7^u;W1}OB﩮q2Q9[]w{'@,q:>ƎTzE-v^M+Qd>#ЪVŶ4{6PϹ7vgRA2iFה!Lo VHŲ=>> 4s,"eLu>Q@줠 H \d PMp0,hgKdȂVBZrVݝr$hᮨ B_a]̕qG:f\*-Qik2 W'C[(!#:# zT#=ӬLT #$&\ 9j橅RUVaU=A*ıBTq>-6uIE<|Yoբ[wWSR!^PO&yAiߣ1Pȶ4Xdt8Ny ƏF|e֐(f#ژA=XDt<.^' L⮘]2el2&.hRK4>` ^."T$CEИF^*g+3EEL'CNID As`""t8?b<$96͹cMv)K8&SytOk+Lq̭BcW|1T:Q`kV~,z^} ys.t4<<{? %}@2U-6cE=;)Ch;ݸEE -rCJ@6MF9:0lk4mQ7T(K8UZ6 q %0FWkFI8ڋٯ9.MUn[|Q~n^|U~xڴ- ?CWQyD -6ne\&bBށtaBоE+w_%ϥ#[\)šEbhjm7үjm O䨳|h`c<{?tih[HMWE0C%x!8箪O͕#Wܹܹ-9"0Ͻ j3 m-D+hobE:DhoNh1⟅g8G"|F2 X%X |ftdfY͸7l}ooYxE$OE:{x2 3ʟ篾{Bh6OۅNw_%ǫ߿y/o35x{"s7p7vO_ˏ>|s3 |lV²a̍}<2JJO|{0굟NOihBĤ0ƤY4hm{&f7[֩ bIĬJ_!N^3M=T*1ܺ|Wk@|'w;b1T!Wэ>*X;rK/몡VtcYTgT6Ɲc7ʹ%HU.'BQ*A!Y_}CVa8l`vv +5Sx9Px4`Y:KA\rG1pc"0N*\`L* ؍<(윗j+^q]υ3nm} ιK e)ׄI!.r|"7t|;LDQ{[ ôaۇxrid =LW1NktmFdIc9{f|-9qMb01y \8.ϙ 7*< HogPm잞*RhL`sFq1^*„CG c5>0NF -ƭ5YmZ:Fnj=Бڟ|YϮЈB\GUώa @ؑ#(j[-{`nj mQ0BQ*zmW")HRlirvmmf;g.gpVOG6j*\DgR@K2@V̮aXjI/vuްAW$VxlEׄ zQ +=C!(1cx9EBĀ u#ŒSWT=u롛N\ ) Q$&T +RW5W +~;D*6WuD*i/eaιxXXZ :acr'"5v@<񑛧t)>,똂tF kN;s(008͍*Ie2~%yE?avQO +&Q'd :5uMP[ +Ad{@}M':mt;c)˄?Ybnv +c=j o&= ܳiWŔJyiwV.`X!E?g ?PY +Yu!zQ@줠 H!\ pMH0,hȥY:][K9-}9+WYj4HpʅJ$PspX)5sk*rbY3JcKTʚ• th %$yd<Es^1b:i4%9x,*oB*[o􈛇dyHA}amal[,mX%vJsE.8Қ]=΋R + +JcTi< aAN=Rc[a?e4?E\pNCVi-ӊ;o]7Tټ" 3uQ#:av %JQ6fq,a.&T]q[0PvPAcyiSSwVUqseBC6MGg:a77Y0 mQ7T(K$UZ;7`q 0F l@vOkE%rNEqw響pv=4~<Ӧ]nHPX%Xl#\ +fne\&҂L8ô1WPk<ǻ {OUdD@s.Rs,[cҪW6p_ؾ@ڷP0\)Jz7ҡC~yBN,8\,RqV!9+> >> endobj 1328 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [108.9497 330.8321 178.334 342.8918] +/Rect [108.9497 345.1114 178.334 357.171] /Subtype /Link /A << /S /GoTo /D (dynamic_update_policies) >> >> endobj @@ -4994,23 +5000,26 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 1332 0 obj << -/Length 3473 +/Length 3615 /Filter /FlateDecode >> stream -xڥ]s6ݿB'z& fXɹ;۹NZ,N(R)+.!QN;L$bi_2iG&Y0ygqi❊'j'Z$<,~/sX!~}wyznϧ2 -w?zwyssyw>I$쎆49nvvvg,@A>[0Y8 |&di*'0R~*z FQJJc`"(MIV0 Eo WDHxPׯA WYM\x|Ye1 ू˪!ޘy+9+vS^#/ޅw ~.bjMȃ3CͨQPmk2 EaMBiIa>rߔ - "L7lEPlK@Y -NA>$2%eD1MWLR}25f-ͼb'F#"&SJ;/& -yU-=E-fl 7ٶmkè%k>cMHic!4$ iTBllf1}BI<^H woF_)XIʤN!95/CJ%!T[꺄?,YMңY"(4DZ y:Z"ZV;"#b䤫lZ`zSH"d:k-23(~}YYNFfnE礘i- b:-f-j@ dlZˑEhڅzkE/C:mJTB0`KY[~2;$vOW5#jC݅y6OY^$amΰ;kHbk\Ɩ}7+w,S/bF l -4VVs\Sl/VM2G]g 3Pޛّv6 {N0Vnc 8OM]qP##Qey|3 ~Eߣ[NҴjnNv X EΣ>\^[sp ˛ ylnƙ%*4J=kԁF~Bg"~VU->x f kG} l*ǂXq5fK3&5ఙW ZyZ[$ExlpD۾$>òR{j%踺q 2d5k%O^1_ۑEVӊ5BHh -L7h\!=q#۹zx%D;nD`蘫wwwz-ϰa%!%C #KXujǗ S9r,?#)L -+5j7/نذJ8fMaUnVnYqS֨uIɔ'ʤu㛊ȻnȝSi<ݞ yabM t%2.Kv)4/4g@WR+3Tݝd"@yƓKuNJkx1(aqVB Ũ[ymCG -@1p53Gk@VҠe+ޡkYyUGzlkKBqy9 #a9` -g'fc۟υ(n++'!j2[th3!b tJmgb;?'e}~!J8'!m|I)9=`(J@ ++tA.~" vR -|s \j[olk˞T(H쩏u:{jpK2sY.`rPihFNXu -!ePqETek&U?m\goiGMQ"ES ra~OB{p;b%/TrMi )g} fS-րb]ծ6w)nͦ܎ L0:-d-JYCP1-SV?1q&Sb01 B i%8Eb%$^c2vKjڇYcCUhr Pe eF6[xk#/Rukp$r͎ -<*ҜV@-, @~_Wm+ǽn &VKfQ,*W<&#q.Fifcf"aONy;ݎe]:'yJB>f uk|Bz[y1Tz]nĈڜHgMô/m zn;qH5bukBx .Խ8d>7ԎBUJq'p9`S\ NNURFS? _ My[yNj^ JoIN'S|k.TVNKq4V[Ɔ}ʪiMdS c TD}<‡0qnbj\jDS)bFFY|y g 5\f;&ى PUI&=)KN;C=2Wkn 5 [jifAD!zzG({J_fےĔWVb&ȡᲴ. "hkhd~=DV:d%̗M%Ru yuUx5dZ* -h0%{Nh$H'arjM~y=I .DbQ<9b/@ XXB iOhE0 ~8Mmlv",PQ0Q_Wrlv%:CtEq‰z zVT/!J3:/Y?ƘFqDQ PW_mW4 ixb>yplҧPȯ C(KCیmLeOZO+y֏zk?5o)h܎eR+_$*F&U n뛩YTs0/!-{ۯ{RӖ 8|k͹ 9AVj_H>ir /IӞi?/+)uD$a0QȽHOWcǤ^/endstream +xڥZ_s6􉞉7vrnv TEʊ{sv h'Kf.vY,I4,0D2[lN=;3wL!'ߪly*j0#vK2<͇>^fqp{t.(x{Q޿?> ~{qMM)9yf닷Wo.N֯e^)\'͖NP:"ls'*Lb\Murs?vԟBR9@ +"L/m3m癶ߠ-K 3,`Lnr,E}呾&ʮg*/c!:!#i/  +2|lu\Lތ;fѮc%YZ0mKN%#8<0j}ձGh&S-{͖Y(AySt 5 $nmm}7ĒNCȬr ,sR &n `OX@:*\_\c,B2 qmk\q盥;&O[Ono\q~7ASɓJ0#r4z>y\8%DqD9`iRXq%/&N8z,9I{1T vj 5m6zH9a@;S5/HA\%"x˾SHb{;jJsWJ|zcC8]B6b7t8uHnm 9Gn$Ȥ S 2  s\V+u 1żjOE TfQ_sM0A!2o%9ݫ6Fa,3yhx(rYt6R"@,QQAQE4Y M?S&cp.w\toTq*t+:ĕwe׷ gM0V=.m45m7s +W\H9w+s#f@{ tPBۚ~YuTd#yhא`~"fi+M[ J*P@D5#>|<fbjh0W䓤u7h9z Cےo8PJ9 js V ^&T/pB;MO@q~5_ ױN@Zwݶါ v޿njo|_mHDʣ"aj4sԏ1;x4QNEHakQK2-gzZS(\@ !+ڴRN (Tu; +&ڪP|}κ1聝-?_p"oٖdf^i֛H* +%r_v`XJ%ڮMȏ?)g K(J~75$@nk +Xwf8X/ X8 WJP>(.Tv5`dn3stl܁ GŷWmǘLU(_dtJqLŪY~? ·~2H'xϻs >r1 3ah{C4D*;wowj-J S_0 6`2ug@wǗI&0ʋ2xc!FWxeHLxWPg/XI!%QV[ +|î]I)eFK\dGXq (8͔5) kQ?eINF ߸a>Gs~=h+ C(^B +"=1ʛ ڦ17* z`KBӰc PD2pX> >> endobj 1333 0 obj << /D [1331 0 R /XYZ 56.6929 794.5015 null] >> endobj 1330 0 obj << -/Font << /F37 827 0 R /F23 762 0 R /F41 969 0 R /F21 738 0 R /F48 985 0 R /F11 1336 0 R >> +/Font << /F37 827 0 R /F23 762 0 R /F21 738 0 R /F41 969 0 R /F48 985 0 R /F11 1336 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1340 0 obj << -/Length 3513 +/Length 3422 /Filter /FlateDecode >> stream -x]sݿogN._Lki3IhؓHG츿%ߥ4boBssoW>wf s>_{x͙ ,!eCnξ|yr+݀g{q~i毯~s",Ȍ峯#y|yw޿pzvs:|{E&0_#^2B߼w_rM~W_~/`ߞqroΟg"LŌV*>} S䧍gFj{)ͼRZLάSRNX(Eݶ<[mv[f6ޅw,ҝ8`ÚC dC9-rSl.lӲ/#F趌fCo -"Q7{agH o\EMcŶ\`( -0p/P.}O妍/j'#eƣ9޳I-u3 81jlo"gq!fY<d.gU5HGY -ͬXP#U@N$zg$dW.@͒[T؟9AʢYA -: &l'+&1$jZ"X>Oi8\fф.8=2*ipCXUs PVMhE9+]@AVu[=lbLRL -݅e=-iVeQGbP=wN>ӂv9XXku]foh,#p1GSܓ-UIAĹh%~z.D2+mEznVYgrk8pϯ}:>-1X>. h ҖG0Z$B &wcOcQw=dŬA#O][Vؓἱ/{dIҮڸHz1_} i eHEEٵE!3f6.:ms}"r"*P @]4/VVWń0gs);f&)Ff>:nVpw%9ɬ7Ѿ[ü4i: &s#.n~hSq:^y(M˺]+/Ǩ /P@B4+4v[Жէ&}sn?or K\Ljz/ˁSi*#PH$3N[l }dawդ -*)}>54-.WeK -E@TyT5@{kN_WU]/3YNnSǵ%iAsNk' b{8P{w.gZÚXx(sP6HyG+Of;Y><9ﲈ0uض]wSiC‘> 5M& T$w" 1tFYcYAbdnP2e jGLL*sL \Z⊻6HXCy)}UKŒ"Q#c腯E-@UoǥSXI8s<%4jd ”Qa`Jzkl =aqm..*z@` iYM}\*[H1.Uۄ*SvP;/b)竘7:y*9[6.wPɵ!Ca!CIZ"m2C$fݞ#Zrp)N^w*'?A! TT -ޘMI෬)r#yWѧ'QGXP(} 4&XAۮ|ʧ NaULnʫ.G4Ay~S!owSPčlyzA”ZѦZd3Q(8><Jt>"pP!@>pk )K+4i6= r8;pAd%"Ooc0/m"F n ]p2ذd{ꦒi5Ħ|Icjo}TW'dGY*M1q xYLZv2`uiglQ V™E_KU:(=3i9 t,I&Vt -#g0ZC;D q~*hR3L~1T<Ȧ\&[7ηM2OQ=Nݑ@!d|VjIu*ZX,* \Ohht? >pmPywPi dWa.+ȱ4A6ўre䠳]n !uq*9:gk;Z=}'\ٱ<m ~g lw|iyW|hӽ2oݧq8:%S{9̘.o`*N;pG"?kl05EQFG'wGMiόO24.z{շk >OY %L)Jd}YT-v@2s7ABH Z:۲S>+8ߣyhfIeݦ̓HCbt :?C,BҦiI+.TT 5p`.mx.;車 gdQx -/->c)J_a]D3NJOS/|uΜh7>$ M kƟY٤eܗ%s$]}996\'6,04+KY'^H^TS9vq$F/ C\/e~GIkǟX\k@|A\"~d] G"w 0Ng;ycx{wN@$HP)&ѯoc՘_߆XǿuX-P|, - M@6w&VB #ƫ_|gU\n o5E|V݊ԑDmVe8wO {^} Hd"|Bcf9NJ!UL*O#&;} d UNΗjwx-Zj`с*?Sb}jͺ1:lcZIɮTګԵl-\ItlsVm^+ Bb/O߉6?R*n`nݨnendstream +x]sݿog(A>]_LkgLZ-$R);.DIfzbo_6cեR]N!֗y'er-〖e~쫿U"tUta$߾ǻWFo߆ww׷_]_%f pd»_蛻}o/﻽ S_lۋf/'e`)#߷[P$ez;A V:S.8=mF.UdaQ5 dU\5l +glPg1og&J$N 8'Bq4+@գ9L0kBJXA-]wX\w2~'[g "8|5,vcT@QnJS 8pRYtU&EeL(i۷St5(e̬l³X7 U{{sm6p!ݳ#1 z EC_ +? O0l@AaExtAA_xn]o_:qqbxyX5c|j2kR;OQ.@xzg9mT;:Cah4˦-A+\wX>3fB9K\Ljj/ˁ_Y8=AB&\E-ڰ7!>Cߥ9Y,p5d!#LS|ߩOy Ŕc K歹kHH8jbh~z몬^|IEpr{T+HՍ== '$ +b<:N-!:9de'yO)с2N2M(&^\k&">n5N&-"!7tFAcY8b޻J U}:DfLʇsL[fPwO6X|DySYH "QcE-JOU)89G8s<Vid dA~uCLau55RG0o!*jhꈋ^ ^!XB)*VS`ɥ7|1eM[r15;(ضI4v!oT Qb7q^m)Ԑ!O!$a-fCq1-F^HB!%XUrp1*d9zD j)΋nHĦ#p[Znz?̪c[ʥ#a܋6r`d)Հϥ{Dd]W᦬s@ שo'1q#mx$$xPJcmGrq;>F`ڎσNxVRO+-i)B|@Yt.P[伯Y ~~.7yL:K'wĂ%D -6,VA#{biUĦpicll}TW Gp?7)5-d1jɤI%Uݢ&R1 +XKS92{6UŕĴ-ڛ1@@<_yw0kXx6!Wgd# "ބ0[4!T&TD \P@ RGZsI {z'sGr@I^hH\0PjXFMpoʾuJZX,J \Ohht?5}B%5ЍwPswPigWa.Kȱ456ј2 lt+pc n9nנUv7VOJV(f&z,M4wl-cBvMP_|+ YJ=2oէq8:%S{9,˺8p#;G!|R֨ )&y2=bnR'.(sKIM M8;n1k󘕞PŤf$HݗE`ϰ9L${v#)ݤZ0@>ʱ3 +fEFA(a^ +G1&t6c9HC`tq%+z6L &Fޥ <2pTPA2)m$`#_zA;ϔ<-<^:X }SbS(}Bu߀Y~Z@{ nh0a2v.C0KUC~x'e>|*{_%/%tlmd铔>I1x`J}A8P!A|UFg.o[&;mu[Xqdm׹9x58g| Ż'jf߄/Kַma/r[#[U?4spI>?^]A&lS},Z ,cX 腆1I ੳt]H.OF$/+؜ʣSЫ&JNY7FL- +0 ;ټSY%:MdP$ ΢m칙ARGΊuM;l3ٰ"54Tri?;PTh،T,Ep:mmv{eg9{@yԊo<]3?<ҧ6jwz'f ֐7,⍡+N4!tr1hPl&[ +G.TT3+S(LxC6Cendstream endobj 1339 0 obj << /Type /Page @@ -5063,42 +5070,39 @@ endobj /D [1339 0 R /XYZ 85.0394 794.5015 null] >> endobj 354 0 obj << -/D [1339 0 R /XYZ 85.0394 705.9314 null] +/D [1339 0 R /XYZ 85.0394 729.8418 null] >> endobj 1111 0 obj << -/D [1339 0 R /XYZ 85.0394 681.0697 null] +/D [1339 0 R /XYZ 85.0394 704.98 null] >> endobj 1342 0 obj << -/D [1339 0 R /XYZ 85.0394 286.3101 null] +/D [1339 0 R /XYZ 85.0394 310.2204 null] >> endobj 1343 0 obj << -/D [1339 0 R /XYZ 85.0394 274.3549 null] +/D [1339 0 R /XYZ 85.0394 298.2652 null] >> endobj 1338 0 obj << -/Font << /F37 827 0 R /F21 738 0 R /F23 762 0 R /F48 985 0 R >> +/Font << /F37 827 0 R /F23 762 0 R /F21 738 0 R /F48 985 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1346 0 obj << -/Length 3653 +/Length 3535 /Filter /FlateDecode >> stream -xڭ]s۸ݿo'D<|>rNimw:=eqBHEq}w (io<-v7(/KDI4##,/}3H!O?eJ.Hd|X:K"] -b{{ƳOWse_ pǷwWs9{}gĢwo]_CpRhȗ_ /"yf.wsu|XkS__-,8uS'OHDM҃dd\& CxOMls%Yٵ[ޢu:~բSv!h\emWu+ƳEWmck^,pa.e܎VUGvGS-JZbA}~-al]Gbє_a.S#qQ*er4R.wi>ĢۓSp j)y̻ն_(˓<+k$44ݻ֚Xk5ksٕwZ8P~ёZmI YY}uR3o>z~|COjyED~B14A6/tYYDBOݦ{n>p9x J~-?TƊ6-/?:ooB9)fIGY"fCb.ż#R 3&8mVHY i2kdY@R,I}|Q]$F(EJPOMLNpnd*$HH-FD)sA@|5 \[-{jᛐ488NR9$2vm]儮dYdR5JnzL7ێN<Édzh-5@g\1aPOM ZO$ (HH$ En\J T_/!%)\ oPs7Ʉ,x^Q@F!4ǘZ]W67q&K0/UHv?!7z[ۮ*ɣ,CJ޴_!&=B,NxǀqLyb;jg[7gҲ, >%N17ˉ!̒™ggnR4Nzβ2P֚mSPr狀G8Xn!')dj!Ǖ!,Lq.jŎyy -EV<P~Fѓ14udݪxڀZa帀=:+*)ܧ%7U̻ulk/̫HpT&"-.u7 - N]rj[ 7)֑_&菶3 .1CxO](#'дuG#zb!۷IUbhǪrnJwJ;Vmmy I{PYX^i@`l/숐wkl*ʻpl-ב-h+W@BeȰU@ lUZdK)!WxuF=Vy,4z -!d'MuJFF,.M -8d)Ɍ6(kg:p$[ C -3"z0jE UY_ -u6>\̦+3ȰDu18$/c#W%wC Fh]38@M%G^x5$#l .L # q_!5n0.`;TQDie|…ZǾcѶ+4 -%Mh|tǁnB⍁IU :jP:Ӷ@\ZDA[C;!bC6w1D Wk͝r{UC">f9Q,aWtO|VQ ˄O$Im]WEOpQD\zTW⅒8j|-rqxVjeSDI 84Ԣ^s ՄtcCֿ'Wz_< q!ҥDNyJ9L5{Є2lB -#DcI,- 'DFk@Xur.V} -vXX`A΅o6`cs@BσʯU>$j*&0ynxe;:rYMw3h)T]a -t\h /u5D]XI 1=ኍV'C.&T=P N\k/w=Q& \8K>`M[I LjoǓ󱗈H||/ZJd@*?`xS"c~ O8lLBkp gu`.->D# -jT> >PD?|EMmˋWX][W\%zE`-R/鄲$0:a>:}}\BIu|jw%gci ˰tV\v'F"=S!OJ <ӧz3SWaQA] \uWz1JG'Cf۾'3˘ -"cU8p>m N- T6Jn@uF Nۨ۲n:4sܳ=u1VWǔO&*.Ypח+kH."@˖mr*lew?W4ϟ}p)]i>\1Qd+q~]A3~S3]2 -t;ǁykRJTz E 8݆1ϐ' 5-m/4>brŬzF29* ж%8v迱qEFۗ1YjD&QxL Qt̝HGM5l:V6͂nz (_=͵zbv1%#$:),8?q@{ dM;Od~ tM m=a l/>~h&UW)|aAG =;jKrnnmKY,Xֽi۵,Ly\}/&>ȬR.HI+ht1ZIY8V)endstream +xڭZs_3OLt$4[IEsb)Qrx<vo3rf(T6K82BY|!fO0B2"-T?_A,kHX+g_IKXAp.x~r>޾BZ#W4?^D=X2ܯ7/tfl"Yfё=~FF d*)(REZp:@zۮnj.zѮݲՇlij!#Qz Y@MS;+W_.n尡uZyqp_R[zZn56]ʗ~wA >}OOjxeLnL{-2*ؔ2c1_IQ֮^z^Gݦ\ J߯wmC$jÇJ +Z7y D)7kPI{^D,!U[*]ݵGthSYH߯Jԗ47ljjr,Aٰu+?+ %wL%ز]HA+IXnh=?`s3PeI*Z#Gҽ&La`%.O=zx[wt!GOu,d@{ڸwئ>=oڦr (YZuGƶs%]CKy.)f+*~M^zQTBuQ4uA#_b1@̑#xa7dF9YIP@A}vV;RlxZ7m[M>FkepAŔ-$=4Py*xom݄UI*]zӼKG{o & Yހ*o{e]>b5D8wkcgE&dt,e6m_v;&ExբDsօxر'ak~V(f4uJ}rI c-ё"˷ 1̌ [5qe)-EyH +B"7}XM߷eWaSW +_Q +hlj98>K0nn9`| gSF,VE vTͮf[(!/ +=֑& +&`đ|_G:hS|Ȓ!vвD5jvܤF U=ͻOWd*pd1clnJtJ_ʦy I㧛;@V/s^[@`|/PmXcSR#~$ +poZ6vCӭp9ཡ6٪'%f +'[!0?*~(1au@q!g<3a*mRDBHcڅTIz +16%m&|O"3m',(EP l?kEd z#GkZyk1JxCN.W#hp4Лp„;9ZsP8@MGzS!jR@1&qmVNKn<%ﮧīW +#",|k;Jkzb?uE u)MM?ZFHR|y=p:FᘰoE@"*2N#D RT/$8j|+bT]S8y֤er yC;$ S!<3+I'u?@A2!G (!06ח{f|Ӗ%A}UDp3:֜|_zUYY`}ŷʎ~o6as@!{P](>$zED]Zt~eWGe3xx)Taa.*ӠF脠{PU TWb=,.:(M FDfYNBbwC3)PMnsaMsDGI ڏǜOCcڡOe*^dkA?}>Q=]QE…EA$LrDAEv ed# ;v%q1oMJF2eh[mGZ{byaBEKWR +P*s͇QYy'P>"bϹ/~Ҝ"'b1Ѓ@@f_yf1v5շ_"죢S[ nS҇2"o> >> endobj @@ -5119,7 +5123,7 @@ endobj /D [1345 0 R /XYZ 56.6929 794.5015 null] >> endobj 1344 0 obj << -/Font << /F37 827 0 R /F23 762 0 R /F21 738 0 R /F48 985 0 R /F39 927 0 R >> +/Font << /F37 827 0 R /F21 738 0 R /F23 762 0 R /F48 985 0 R /F39 927 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1351 0 obj << @@ -5200,30 +5204,19 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 1362 0 obj << -/Length 3422 +/Length 3416 /Filter /FlateDecode >> stream -xڥMw6_*լDtL6}i [tYr-9i @}YN: H7]]D$̮M Fz -a컫iVh5\g"Kdr͕0M R a퍉?ܬ#OU(xLJO40=.Lݧn~{xQp#_[x] -R} /L^bꧫFݧKu*d,Be)GD8qd/e-ISy٭`U^G۶o>2R(LW8㣧Z`D*)'[\q:"MEC # 1v6Ȕ4LA5@Q>!"a ms$bp(/+7!}l}WlScW2#XMv7'W<~M4zЁ4j]=!@Az(U @B4T^,+vӜ-ę g?R4{Ù.;Ӟ -k -v;\jܛ*,_gZd! +dJRBp(9Ha'ГN^D&B}4CY9 nG:s.HIZmbZTq ^~F(H!\tdq@U<l Q4ΫKU #}G(O ˄Asgl5eʁ-kgp Ia1؄#cD>`OfODJ; K? -g2a饰H9=i#=jL{KzL8T~yϵ`zL)5DzTɎ[J."zG^5fA + dD#FL܈ō/U$x - H@l8l@-cm;ΉViU %%d\f$0?vB͵?uCӔ[<ں,kVր䌤k6MEl7Hg-eyNr/gM`feXCa)Ӈ9PI>GDj$y݇KlGK&B "}}'˅8|ls7;2? )4Jl _ M,.C Q>|&ЕjN_e)Dn֜nOA؟eyK/4[(L{OVX?ZmH4]I d[x:̉UdSQk#w̲0q6\h`"*qt3Rݾ( ^{?S~o T3B\`.lendstream +xڥMw6_*ժDtL6}L [tYr-9i  a9&A D :?Vi"y(VכUtc]LrD17W_:T\YeY|Po`(xӻF'OnVBE݇p3o}pRw&DžI?ܽpo?\=xYƑDA~Bg^0sqJ U"W'O,T"IA?}AqhtPPVp0(ˣ:e+#FbCٔ-$fa"# 1v6[K+E~g,(y)a9#"e :!&"7 GDu#(C0xR²gXL=An4l#/shj r4#kFVHiî A{@icus{Dќ(S流qNzv޸o7{f© 6ʼn 1I,S^O A Fd`VIxcd%=COJUh(+UMcc'do͓9bj+d4TM'frdjg2Ю[:Ek'"XSQ/7q#Phv;jkqemӱx4ex9PIBG1hP_H J*o6+ؘy8 ZΈZd +#L V0b00IA8 PN߸6P6dU##y:{2N:&;޳YFv&mQ-l>ˎK/MO֑J9T"4 yK}H?j.SƼZFHcCX{wy2c+˴ إVeY( KƃAI[V0d}#toDz}׷EOAix +%< n۝Ms]b8ɈY1.y/R-'M\}txnRVZ]ݴ5aCߔMdVs1_-`o6:k +J@vC>T#J69vl0SGSˎ&xf;PO#.ʳTCFeu B 'rHOOOb,T\O+ɦDSUO[|&h3NS4-i:bGت!G9r"mfPȠ$+#eBvhs%# "cg8A=E6P}υ )n'$Ch{Y2LRvdtT`9wi \6Kapfb6`R> u;D=Y{Y4ōHgX;{&<1n!PbdgQ}&-@MlcEwoUz4r/e(\mLuP*cVc_ek,4ޔ# 'WT LjOJS˛2?a j1+b8۹ J>29S"Lc 4b?"]  m,E%q + '>:)h؃=ZĆڞpd<95c*PQRp鋚Y" q=*jȰX4Dl!eXǬscH<!f'㽔ؖ7;#3S)cRЊhHxN_s͒lu $:pPJ;QV$zq{0uC0A OA*I($96³lڨ:h}X,s@$#X C M זk~$B`z(̫ dxFm&5j3[ +5jI U[|e`8[(! ޼gh7B0Til-bJRHrL nWh!!Uۋ^' C{PRP\Vv(On\E塜Űԍ획=CewDn\vrUĭe#j]p A6kmcWtJ~5_}ƙL\y֛=W!\@5dnS]OzknslV6,)Yug;99_ Z8XPi:JSЮEq+"騨׮P9!KG/5jw]!͘@$Cob0Ӯ rN݌ v7;tYoG݂qIq*Ut$)Хb/|slk_*B-xַ'{`m@y|Kq_OrX+L1]h<_<*zhyC* +iz Y"fsD!1՟0ttѮAcѕ!eN>#W\QYe> endobj 1366 0 obj << -/Length 3521 +/Length 3625 /Filter /FlateDecode >> stream -xZs6_Gy&bOsOnn''iH͉L"eoDI3Db ,!&13QR=IRX,A3<4s}s{J&iZi'X.7^|Ϥ6:O~K~|~w_DOo>^y~r~y|&Kj_|p1?v-XB~;xewG*uf q$TNδQJ퀽^qNf,PZ؀fԱl,ŘjyYueE&_]8YiԤ?-׈'pidck\x gJ\)xZwelV}^RS)V/EyGoon.P{"Bp{S2_e5OZԸ -, Q -/{YˊX t,0&o/"9|zldj52o -M 6BȄ2TyyԲ]Qbwg0"b7uI셞_@ˆ`Щɏ¶u- -6߼=JűgnFld8ct(l <":vGڮ9gZm|َRmOcqzujdX"mm@j_;ȀB^^(bMfȨX;!.~c/_eۢFP+ ,&<<~-;/LV;,YU0Vj E+Fԝ!Ye `?pጋ|e`;f]zbkdlL뽘iҶ3;lE=B>du~.̓K_&JD[^ig^VԆR - T22]H|jU)btMA⴯+8B ^cUցHxe+O艖2o|yl?SF,irĠm!I'r؇wCfY2 &{U`8 S H-"sMZXKT^E`pib[C \MFɟM968ezŞ~M೐7<ࡇ_b, 0Lǜ3ۂlz4ԪڌD)&}9Ap1 } m%M -UӕW&]&}U7l^D`pkx95,Iղ RV1 c  !9#Z*;296QzP=-Eu]?҇8e)ubzW+~Cڋ7>=-ՈtޛϘ82JuqDP(f/5~yԬ?#F5/Ga5 EOhvd:rZyt1tJ5OdwIйĐ hM\3ń=gnFZgsQWJ2#D4jmj~3ځ'~\.9v RՋ3qVÔ@}K_*4E!.)[osFYp#r -̉#N b$B3pU&9>a\prmOm\# iP1 4h[/~xhRFY3| -/Աf4\jI7W;6KĠ sRc`2xnmd;m >B`诘(YՋk?1:"V<) -c',flEKKӮ,N@#йx8J@(] [nAP4mMk`%d2l:)g=KF?@m;k΀`k_- -uLyfПSzDq=!%,^򚺼o-2'Ǯκ˧^Q{AM*O ! ;C__%D+,Oiloט[;Q,i%1 ty.PM u匷 -l] 'Vaj̪U;Lf$Ucp,m~}`Xψ5k%S}520Pi׵>RZHN漠~E}|lօ1Ǔ9٧AݎhQ9yd#DsS|SjVW٬iY=?~8*@5"p/I$J E! mP@>wٶj2k'T w$ox'RO%l<D_#PnoT&Xn߿x$Nj(kw,tZGB%ߓ+""\ro1*8.F5"2b ?_li4bfxC:@G6cG۽)_Azk@Uz4Zn @R'wRDN sˬ%Ͼ_)>oCD8bBb KT?lAȋ{j|.x o/ђL"udq' - R)\u֬‡n颡s]lS@+~c螁Q(pM-8'1<kOڅi]hH>C' d0/;=V$$%K4AnYLp ])-Z-sB ?cmP{>G9}Kc eW1%og`VpM=עEAZ TNښ̡^!LJT:V }= RZK!-M7hGXu[?THë3,$"d2"$.endstream +xZs6_Gy&b/{r'u8#Q']$%Jn}x& `a?Ĺ5Q2}f:20Y|uL=ӴWoUzEY"E/֊ϓ\~JObjxdwH o^^ݼ +kÑoһ/o/~>̥?_+og?aߞőʬ98Y&gڨh^7 #2iJ-^ml= +ۮ>$cOF,&pM1t(l>TFRd{zw9U|*۶^*Y,^^;ec1B]z1ҭNԾ*:ᕑ lU<Py}bT,%e1_TD0W|}2/b.+'wvQ͘R/Xxa$&*'wԨn~Bd:#ΖV, 6Jxo{gŔ΂SbH5f@ +P-g-8 Ueg-n7Ņ0O^͉y qm]b%~M<"22O{03.f z{u1GtBz;YT 9tyQie7&8x"A'vsP&jpxWD[Mk@Hd \ =eDΌ3rX)xP|]خ$7tV 茨5:c}Oo~fEgqSSмeD~/_Q%# +] THT$VL[WM ;1nMy-Sâ'57Dr.~o^Q%ZD0f/8ǵqiWDSo, >c& S/Q7T*y3-W_5Qn#,~s=YS!%`՜#7NjL:9dv:W]ܣ]:Rۅ_\CmtB#8&ñ_بK&v6#D4jonQ#&s?sl>cyű +y0h6!řFJn2K!fM4eHAծ`y>!ּzһ1#n|Iƀ u$SI7pu}*WY=<1:JujNFFl%t@*j@v.Ӈ"P$G9Tgc~iũjJ;W%\S[-2?7Ywmvj ]>]dCIѡП1Qy;[RDԵlk4#^GJ%#Dx)em/pE1kqjY%FPBCA i#!T)xe(tuʲ(:`ZC+>ޔQ"*fǖ%]{XHl\.x}>ĐaN F$nbgv(b u:DCTs!X UDXAƦ8V1@uNrU>vM do=*ذ ۏdRafPXΆDX5DQ( RQfG@%a>qPnIT FPe"A +RQXFUyTɣ*UU@C:;D4TB PMk"@ieKW}\=hA拁O nrz520Piu2PXH N渠yEu|x%`B }nEyR:ayL?Vub%= يm=iSӶ] +kDZHk)| ɁxحP]Ĝ2oGTK%ﾐ(mpIUd[4 qZ5"Qb ? :WiĆ5t~546,J6Gֽ?A_k@XUf&",@PR/VQ\'Vs4k3$Bap 1#?Rеj\ FI^wiz vGN?wwQS,n8y(xxL23KGY" ++ J^<{6v{{wÚ.Ƀu D!]~ +m 04sMN7T wn\cx* R/HP]0 uXTmٝ($- d7-&4Tiu_8*WF'[˺ Gw`@!}qon7ooqPZ |S|q!S:~>tEZvV8""/Ep䄉L V-@k4A{#*W%(KH فz2[/zx^zLQ?6W7]}Jta0"eɝ*hp#-_|;씯[|vsQ^azLC-G^UYѱGD2y/_~ݽxgXr|BL/Q62V#ۈ:endstream endobj 1365 0 obj << /Type /Page @@ -5275,23 +5268,20 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 1370 0 obj << -/Length 3204 +/Length 3319 /Filter /FlateDecode >> stream -xڥ]s6ݿBo'τ,A$xon\ӜM)cJTEʊoH۹LZ,~N$IPGBOf˫hc(S}p{N0Kd0e1y(~&a^ -O}:UӇ>]}KЇb_7ni(50},z~}DAhR?\ĚG,'+eS_}_7jODa,xD)ЈPg:  Cd:MݢfWn#S櫂PaPbն,@pZ!'Uaul5% ]Wv uW5ׁ`FBja! - brNO۲AȲr8 -uYa&irF^bqhǒ9[v ͺg>{ful(_͞FTbI#: 4ʌhZ8z4iԴZך>}x ;x6lj/ 4i`lwsρ2ֺ%$kz£5X [TtѺlޗ ? 8UÈeٽ9L._5Al` -[-r^'qa*T&΄ zDPHDvD{`Bs4z2L.N8؛δώ k.DDB#wuwe0[gd S# qǦ[D:{*_uuVv4FjDY(cB`oDT v#jW!Q:`!fXq@I -82AU['б8~кfs~d0^^*mvv4i'vbڋYLT,bVeϫU h">:08 9^}XP3"rYfYCX&MYfƜ4"3(4ʦ^}p<ևyk($DpJ=Tj>uwCCvc{'̇Tp6kcBhs9·zOeq:ؔM.Nb} 4̀`8$C3ȵ:a.ιX6 cFmKo?u0lMUcW5XR5{*7 8`wcUWZawI 6'з_y(Ue^)U)iџ3 nI.m7e5A"BHYpD#, 6 pS- -~"Mj+OPZci4j9w}UxqOߢˎRT%8U]#!2v TBշE -R eC0tQMB -S)Q鎪u>#װ|EGB1֟TQ~4\O,]U4:gwșr3 6-2>b;cF[ų|ܼC<hٴ֕U^v/KxWrH]GXR½mz Xkp g쉎`~lPm")ꨂfely S@ܭPNHW OIu<]Qe#)`QG `'*Jl~=Kf3*EGke:;ƕ.o6nք+٢\S41UpyA;O|6HGrS -D[Ahd~ 6[f/2kz.`e5|[ӈMؙՕ@-H>rROo[^s9ΫMۍ8 T"*N{u@d(Ub/Q`h ˈ˄Uu8f, 2݄* Z$g"4?:G6nޜZ>pmkmVQ|QrJsbx𒲞É)|Q?8X0e$P&82.g,2 d)8Tqvxxܜo|ul\\(74x>9ɟ,9Ҵa -.'W!h|%C&*s1%0R̀+\|ѓ \qIC`(;qiB}=}ПpZb`!FTITq.HBX*G mлm^mϞI/\k'Jf~.o9j,aDƶt4B]sfkKfSD=wo35P揮WŊ-ڑ^+֛޶iPj}y5g$C -fݫ V"MBy9gLOe3A{8,SFo8< 2Ti*eQCE@8>]86v:25&g6v!74 I >'s H[Kf{s+'`m L04~QӺp -|6[ Xk _|8Yu 4P9e_wSq͹Tޟb,ՠz?Xc#GOhʾʥ}uK!ѝ -ٿwI!'=Әwn Cq`z_[K,mjN˫n`[e4v)Xnj:?#oE_ -JUi̙85"Dgp[endstream +xڥZKs6WrՈ!ɽ93dV^Z,)R){~ (yS[S5l ׀,b2ũPD*=AwWyiꛏ*Aj=zs%A$b67 apO:󇻟>]/d?o~z!H=uۻO%ϙIo?~z{W~/PFpö +&~HS9\HVʵTW_'ڡa  +DQF8J uQ_/Tͻu"Ͷ+nhuv nZ2 "'=-1 q*0;.jɼ7 fnUd{moٕ/<8fGDRԛUOͮ% r* t(DFO[]z^}*;QQf ":u꺶Ŏy`󻕗k kݔpz~x]5tHѼK"6p u {7LN_VQxvi(:Y{[;b!,@3ӢE B=u VxnM] #TzY5!4RCC(FC5p"@oͳX,73኉ +D%XDâ.oLE4 [~[TF!`h}y>6(;REc`[0p#b?ط8mq4s|D|mwO)y]H]Ev{luBf䶩ی6#f䷩yfoVYYYxp щ!b"q>̥>Ԍ>o[n*sAqrD -־`3ƐiܲllhFt# NA1P*}pˋUaTV#(nɺb:AĚxUW󩻫($`ۣ~>5c>&0a,/>p﹬9n]ծh'^~(皐`iNP2(6e5wZ3[ +3~ ]YcX$@`̋cjf]XVewBvlaz +eހ:HJџ1 Xc.DIx.~W,fQD4Y4!pP%CnyE=yeh]V'X Z9G=EUtzVn38m*yˑ0@oI)[$*J|i(?(0Dv9nt HT8LCTh:%Xf55?JbYHuwFMĭp ]fK'D+d,S#8U)O_HV{T>n^lm{nRt^|]UZg(^+8uJjۆG +)X Gpāx >rn $K1r]'c(Eme ShqQ kiCϫy&j%FRhE*Pf0x|p$k{YgƊGil]G=TDfܟWbëU@٣`|⹼6kz3~2 vQK}~C{U8v-tdvjkLinACnRCpЇ24ZC['RZ20ejRǩu׭ _\jufAual7- S3ECBJͭ51 =gT%xǹ$ +d$D[p"[^uO/I"I: ?+pZֽ{,j8[)}Swz;Ae˗@^eGPt@PZ4u;+9zCQmWl[ ;hP!R'/NCQ4_rp_1XWlsw]VVІt| [J. y۝Po<.3Q (8 eLk$R~R7)m.VK5e-I=P q鞃NIQ3BwBjY&6\e?:4GSЄ@Uq jIν*?Z'H@G:f&H5{% +|H.!.)5eOqP~Dge xP(9SNE/Yendstream endobj 1369 0 obj << /Type /Page @@ -5304,14 +5294,14 @@ endobj 1373 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [339.2005 278.3354 400.4005 290.2356] +/Rect [339.2005 315.2719 400.4005 327.1721] /Subtype /Link /A << /S /GoTo /D (zone_statement_grammar) >> >> endobj 1376 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [455.0966 73.4705 511.2325 85.5301] +/Rect [455.0966 115.8271 511.2325 127.8867] /Subtype /Link /A << /S /GoTo /D (address_match_lists) >> >> endobj @@ -5319,43 +5309,42 @@ endobj /D [1369 0 R /XYZ 56.6929 794.5015 null] >> endobj 358 0 obj << -/D [1369 0 R /XYZ 56.6929 515.5793 null] +/D [1369 0 R /XYZ 56.6929 549.7266 null] >> endobj 1372 0 obj << -/D [1369 0 R /XYZ 56.6929 486.6636 null] +/D [1369 0 R /XYZ 56.6929 521.5601 null] >> endobj 362 0 obj << -/D [1369 0 R /XYZ 56.6929 261.7462 null] +/D [1369 0 R /XYZ 56.6929 299.8786 null] >> endobj 1374 0 obj << -/D [1369 0 R /XYZ 56.6929 237.772 null] +/D [1369 0 R /XYZ 56.6929 276.6535 null] >> endobj 366 0 obj << -/D [1369 0 R /XYZ 56.6929 119.8679 null] +/D [1369 0 R /XYZ 56.6929 160.9654 null] >> endobj 1375 0 obj << -/D [1369 0 R /XYZ 56.6929 96.0532 null] +/D [1369 0 R /XYZ 56.6929 137.8998 null] >> endobj 1368 0 obj << -/Font << /F37 827 0 R /F23 762 0 R /F21 738 0 R /F41 969 0 R >> +/Font << /F37 827 0 R /F23 762 0 R /F41 969 0 R /F21 738 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1380 0 obj << -/Length 2678 +/Length 2761 /Filter /FlateDecode >> stream -xZ_s6[噈ӧ4qr\{jH͉D"o @$EɾKzs\,K|tdf6Wf\ϖ36g<,"Ӣ欄YnrsnV/7 d m˫D͇wyܪ+"__zsqNsx_4z__~MKIgf+Og,ӳGx`s1ۜ)-3dz{))2--4i;me1 V[X 6%+ >eȅV.qQ7]u42W,˥C+J>sp*oݺ8fYa"9?7@-{v[ziCOVrQ cuϤ>4nǮNd!yikB0 އS0KY,Qbg]Uu}Wi -vzǝJ"י0N Ah3"f:q>t;y#SN'`-?"$)B8DЧoѿpV(5i9燹 LB#:D իbsx 6pȌ/FrQF_cV7K-vPj - ȸ[w`(9Y',b~q`XT -.4D 1oy.7[܈4o+/e)F :%R s='͟byɽh˱::p?=Z -ܐ~l@}P,@G-"ցofFŽu!,CѼ׺_ g8 1+xA(2꽁ib["ӡ`=nj܃ Ͳ -֣GmEM<#$ -!,C1Yb9.ZuvAR҆Q-S}ZcE-!RZ/#*9)CS/.֋b WӮj{ko P(ʥ ]uTlXM}V^XǗf9W~+ #n8`*pqq -buzHb -㕉a'W],ܳ47#'8ĘKfG?ΆG?L_C_~C9ɘ¿D_Kr)Ő?s'1_i k5Ndk\^D5M̴5vL0(E?ċixWvanmxo'jSoZb;LPdR7UlKS2;Z, PX%;fr۶tW8y>G6 -X$ov ImKoN38]> u 6SjA4bLƝ2׀wV%\c u0SFٵ/ 5yϸ~'DoL>%rʬx+q2(/DjN/UP\e‰GaBe9sOFk2M]Ddi-ׄ|ST=wfSIxawU ERJEH;`@ -1PTvr jtk1S'ʲ,{5ռ<㊹wN8)z59&oOư~]®ϸk넻F#9xxe6ȏLWfC40iz \pPx} e߸'GB_{ӠBQi EpƜʐ Jr =1 $?dB|$/VaH!֞O(%d/np3ON}nب@C1pl|$xR N D츔u8l.8~3Ʀ L G" n:˼U1PGxo1jH%̕ϧzCGhÏ0W9*e*7\;^ SDsiU:O_$/LiQ8ŒA/融gre(y{FN$ykm2``=c6xdîsX;ZGJM+QCjgPF+*_4 +bPo0xBp-}~?cRV_ =֠KIXCE0D(y5] 6q({_sB +{e83 缿=TJB2 7a ?x!1K'^k6͝BrH VZ3f ]Łv O!)NO!O!w[ )6 1q}A 50!_|:RO`I9FInX*-&sQbD3pM5j&?~TYxZf@40`ț?-yS'7M %#їд?;ۻP}WjT3(k \AQB@%r=1˱&?ֹ&\Y6Z/ð'78}B)} 7EwN;ǴC 0C98(8zO9i.:J.Dku8Z{Q H ֌bt|V C"xO-:u6ÕXJ?&=Hʥ%{'A}Xdթuq zҤ_yxM9' ''Š*|;<"穉W_P?lUYέFv[d|endstream endobj 1379 0 obj << /Type /Page @@ -5368,7 +5357,7 @@ endobj 1382 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [213.0783 74.7457 261.825 85.5301] +/Rect [213.0783 118.3725 261.825 129.1569] /Subtype /Link /A << /S /GoTo /D (dynamic_update_security) >> >> endobj @@ -5376,29 +5365,33 @@ endobj /D [1379 0 R /XYZ 85.0394 794.5015 null] >> endobj 1378 0 obj << -/Font << /F37 827 0 R /F21 738 0 R /F23 762 0 R /F63 1103 0 R /F62 1100 0 R >> +/Font << /F37 827 0 R /F23 762 0 R /F21 738 0 R /F63 1103 0 R /F62 1100 0 R /F48 985 0 R >> /XObject << /Im2 1089 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1386 0 obj << -/Length 3193 +/Length 2982 /Filter /FlateDecode >> stream -xڭ]sFݿB&X KyrS;u璦o%'(;X `-I$2Ie:SD&E8yqi͍'ii&ZI&ܯ~@3Nfq6Q85]}pu7$w?^}-4ARz!zw}s}w.,]yEP?.~=@.@I4y0i*'  J9/`g~:?%A$̕8\"8JZbL m6[eM>~UCE,$G0F8QNDl8{|0y way],״\Wul?4d?_KSѳ>,ECe-3-Hz&{Q<HHiI~'.rz'!_+ l -gMGkT"޻U6 5F'IiPhgszKG=-}Co.)2ge̮3>dIC ҡhsҍ 2+lj3:> R@v(mY*e0?KBPczJE ")Y \]fiq3e5T8}64\W`{ZօJ0ɟi qlG1`yeu(wjaơhFaGSdp{7Y!'\"2uLXm$}2X֔z -e2k^M$cisf̳laA.z[U6 ppxC =r5?2Ѻ%~Rł|F(x(l`LPഁI&m b7x#H[K_%Xk0$Z @'ԕ.-[@h80zY=3d+#A)G-D1?Q)#t;jC?qpf_X# @FP9ZF%ZLF/-|CyXX2 -ǴZkj3fUDW}*-_*!6Pԓ8Vʤlr*u+[c³Y(9|*Z0a)aecQOp5,YmW0 (j_lp8 $ܵ+笏NԎ p gԗ -#;hG>VudđG45ޫ@8}y[|PJu9-D(2΋zӃ{>@Q*)mM)h )%]𕞔gޟ%׎}H~ld -[JjTܱK~gB)/DNF%3rصc刦i/tf<8qݩB^6c'J @kuC!Y! i.mlGd;J簱vKS-׬Gqs- :xmQ?ơk ]>&AJCyUH>En4u -f}('Ȫ<"M/.(bG3PWI'Z $IsOq%icN?lO,@>2AȤ\N>6(y^R`E\ c)E38}'M.i.A:AF֯{9Ràb!ľb0U-$$~(+q k5#~4O XQcΣx@cIo7F_pUQȬ0/$ĕt P9eH,-|(5)@nOQ`ob #N]o7FdF34c}:7ȇm6g95k{HZsL%__([vI@3.#!hX6ٞI1~vnQba~W2 -$ !xx":^e:^ή&=Ipٝh<m|OQq'.zrNq!{A3bY9|{BCՙV×Z"7J]t*|BH]%xVKb-ؓ`oI1~W1 jk&:iLB\(xi W -n JzZ5z7CVX{#DʖBqroTv~:cDe:"̔Tw(̔#7endstream +xڭ]sFݿB&DW֝KD[H*Rv}7X`W$E)ipb,@?5bg:$Td'J1#ͻX>\5$YcV*di,9}ۻy=KǏ74Ç\=MLۻ'HF3Donoo>C+dbp%h/R,ӓ핍1@3떎OIMGhӎS%,&IhَxcTPJƼd!l^eY3Na9G:Qc\)Ev$x 6e,j2p=uDfWWM(7eJ C8Vy˫h/j-1!XpKT^v=y7m`jUGtNj6sш04Ȋ>Ȯ)vK2 ~+FX {DqA+oǮn +$qM_0 +"ۆ,gY520OW+VvCE+'T@[3R;zkbJL"E$V4&4>3(Ų-̉0CVJD}^NP VK!8@o뮾WE2^U"Q*ĉ2Vg";HĎV<2~_̟yZ6e3_Y S +Q6ij{<1 $;>a!9I alڅs6T<}[W3$g^ \܋#SkWmU.lEiJD;.*߿vqF1i6~)1I %fbApuQ@^,!ތńt辛ڥ(-FxQ;ꋁD缨L&v(G% z8rG hAgg7!ev{oB/$Ps.oF9͢=5Z SՏ.~Q!G?a9Wtxнꇮ[Ǘ=[BD$ v2?'${"9kBR\hppۗD \¤kXPԅ.UHU>RWz2O${pY-mf (>a34 =X+AR$i!#$PrΠpn%':$j?uX%H }& ?((*Re=e rB{.lce|89 ]xXB-f{KvTUřZ 4 &eS!u~@ڏ$܎,E,{ L(6-9)|]cё/ 2 1?l oYWzԩ `lfdo.Qd sHY9DR%3GwPZ򗚱Ĥs +nn@ HU%!j ^S%˲4㞋b?cwR:RyD@y3vv;?|@ טR[.|OWv?`rj7P0FH7:q +pCֻR=Q sN1x7gܳ +~"rR<4؊69?zYxЅk^Ü -c +lLT@>63`^3__BdP[s@~y; +",TDh)7E7o~U#-Fr@#l, +`bgy.hsC_I !+H/Ѭs bV q5ģ"Vʬho8HYpdBS&?hw2: +K/9qJD(/\*T|1Zai H(*w>=G{{g7&[~6C?9^b*=EK')a\T~?c endstream endobj 1385 0 obj << /Type /Page @@ -5411,7 +5404,7 @@ endobj 1388 0 obj << /Type /Annot /Border[0 0 0]/H/I/C[1 0 0] -/Rect [369.8158 666.0366 418.5625 678.0962] +/Rect [369.8158 701.0858 418.5625 713.1454] /Subtype /Link /A << /S /GoTo /D (dynamic_update_security) >> >> endobj @@ -5419,33 +5412,36 @@ endobj /D [1385 0 R /XYZ 56.6929 794.5015 null] >> endobj 370 0 obj << -/D [1385 0 R /XYZ 56.6929 501.733 null] +/D [1385 0 R /XYZ 56.6929 532.4192 null] >> endobj 1389 0 obj << -/D [1385 0 R /XYZ 56.6929 479.2364 null] +/D [1385 0 R /XYZ 56.6929 508.7234 null] >> endobj 1384 0 obj << -/Font << /F37 827 0 R /F21 738 0 R /F23 762 0 R /F48 985 0 R /F41 969 0 R >> +/Font << /F37 827 0 R /F48 985 0 R /F23 762 0 R /F21 738 0 R /F41 969 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1392 0 obj << -/Length 3228 +/Length 3193 /Filter /FlateDecode >> stream -xڭZKsWf*e{m#W,*)%ԒM7tOA\WOO7_PNIj33Iv\#}{%,6[}p['Y9&Xi"TNL͏gʊKg։Wwߐ$?ܿw7L~'۷n￾Jx3J߾w׿=|wuЮ^)4._~%,+,G$2dseN:JWW4#Tz̀6K*4u5-j/BS잋zOu싊5~|v,Z.w2M9IM⭑=̟lЈF rBLM7Tg>GD(8w+Hms*xaSs2%Nظ˰jl fW!Tĥ&Rԁl ֖m 2imΖTuX>]&Igegc"q܄ k>0aR&^/OA}ip_74$ZߛY+?-}3txg Dnv4tQ Hq_6ORvgɶnOIkrn/jh IGR@oYzc#݈hN@t(v7P4 #!A Ab.뢩>S~9jW aM}rC` Aho%F,va@G3f@D+!4knQ,x68z:)#Ւ -ezGxJT,@~66`1.*&s i@mʨIw/m3~!%j ϚgLĤtz:Rx_TKiAWaEq+PNOѶ (̴ޔ=4 +開7c)ٱ.vcUI"\ib}X#Uұ}[9s].?f X1ᰭ 20/ L*58*"gubf~I/+vPl eHHv#Jo@O&xՒ*H[\u1MDwUjSeI6$zQvIk=O)Kǩ$WC8jatxxuaQyK%g۞nGxx1/ {k ƴ(m%RvMv;,k+lq(![ ΂G<îwD-5ءq_EՒ }we}`64d^Nh#t -VkTŴEB{ ?*B庀tDP - ,$耇Z0a2-L9 {ӬJx0܋lf+KKT9uMfqPFU"a)ؔf./[-][O!U# [э)`9}7uˊ+\uN_!z/x 3-@G [#1'Im|NW(|i/F uccnFzHA!|驜# ^ѷ7,NDaG23T∰| q? -DPx_F9o -ko !WDa|g"NݕπsQ1FQLX.B2WTBNIB`d|s 蝃v~0 -{ -i!e{95@XƛŞpOQoTS0u[pb.ୟӕG" '<- Y UBɐؐ$e{Epܰ#QW:/|O<[g_1ɉxJrE^ *|UD0ꀥ 5M/Bu\V@xխO -E>NyH52_U(@dSHw9 frn+>C5OsUoD}n,- Ui[aN0X/XI4ƒ#Zm# $ϭތPB""'x*CC-"#fMxCQ`(<rqQ"2j$sn3J/pLsɝTRG:Y 㚟eӱCl.>_Nm{@>:B F.)VI.]D͌1ன|k7 - V66GIӃ8]ZF8T ~McS(ڜKl35:}?}·p~xIѩ'x@`e(.Ùq2dzvq0eKl:IkHXi/6:a`P{JYzMGS#ZmV5|HS5>-\G2pש# endstream +xڭZs~_ȝo''$NrufI@I9TD>X"%v@jo?|td&Pf\O 6.xɒR⫷N0L\Μ㓻oovLh65e ~}s-I +z|ۛ~}wui[~{ˌ;͡#kzՏ?^n-r&q!^,`_\NOyQBik%e.~K7`5t.N*>@]F +ڝefuS77ίBhlI3%h#nš[,DnvdӁɍI쪦ln1_DLwTZ}[zV+P7;$L3 n~Fbn8^$Wc6ZGZL2`$a?9A_0wġ6/$ Ykhfr,Vc/0ҕ};ި\E8(8ܗ1-̧Y&MMMݑDK䁝.˹oeL[ ub ,]>ֹ!zN/{}&:Q "Mѥ!%|Z4Qy:-tAP~-&䋴zZASI. Gюy0%B`#emȂN=z:)U=LFl)M}ll <moBGm_ǡr70`_ S%KRM-w~#H +S*<1E((PBP@Y@S!:Z칡Mq RqpM5Onı(ǝpPknNgDAa)A=D6qYnctZ@rGAA *uR@ҙ`dbcX^S64BRZ-,Mn{3J"HLH!"(?~QHe$<%<1iQCw*xT9T#v8l/ȪBH=,/: 1(]W)i؏†1~5Kzɩj_W +s/ڪJpd/UW48!ΥzéWL'\TP1U(ؤ&){ X'ȝH/ њ~79<%seDGNd:c:XwxsG'£㟄K +2-";DylPzp8Գ 7~L% +/m Ѕ355QQk"6xc'u R^r&D6<@A <)Iv +cj|/hY'b7EH /~ȕEZE ;Cΰ +N-cYʏmSj6Yp` +6$f@`{I9BygTرpB* +UX?dqTqy ҎIzu"WތR.{.'c|t6|q,Jwb.&s(kKTH~VOsjzEMV[ \˧qpr[5(ܔ٘!'=Du(ЊOg{ /O  Vh6ifF{ݕq4F"nS +P(U$-C+8cD Ō=Ӭچ9Y%O0hJdb+#8C횆:\㠌)G +pDvP ^1a=Dg)$@hG5k 7:}fU>s3sՔt9$.2)GzhQ+>Dc9 yEhhr(@?%IOX;ta!Y`!O˶bǪ& +7](蝦-bL !/Ìb2+x'HpnQݷā392Hb=$kiC5ClE y1*%=f%ynQ?Md&@ \#?0EȖ~DVo^ Q`yk0aCO3уlGc(&҂Y I@ > ႑ρ|q@)!WឰBSJ)*94@ӯ_~GM(H"TRP0s8242/Ue[.}T}xNj\?V5P(n3^uUO|^=5;Y1q?b__U ^xVL3 ӑc.sb&3>F`U9YjƜ>)~_AX, !8IgSl뮤AAH gTHFPڅdg~^B%fZǡ(A0VqeҢXbF$3J/p<C3!L_]=qg ~/Q%l]ZJzl-0=9-A3%6EW_[nKQR +ՙaM7#Zw2Z⩴=L +Q©5ht~ S uG;Xd dFS'd=_LϏL_2S:` X;PSb^,Y $#n9J"sȡ [WȗtN 8,듸sߤXw? Åsb|y܉&?dNM/?aendstream endobj 1391 0 obj << /Type /Page @@ -5458,13 +5454,13 @@ endobj /D [1391 0 R /XYZ 85.0394 794.5015 null] >> endobj 374 0 obj << -/D [1391 0 R /XYZ 85.0394 671.9496 null] +/D [1391 0 R /XYZ 85.0394 686.6286 null] >> endobj 1394 0 obj << -/D [1391 0 R /XYZ 85.0394 644.3125 null] +/D [1391 0 R /XYZ 85.0394 657.5011 null] >> endobj 1390 0 obj << -/Font << /F37 827 0 R /F23 762 0 R /F41 969 0 R /F21 738 0 R >> +/Font << /F37 827 0 R /F41 969 0 R /F23 762 0 R /F21 738 0 R >> /ProcSet [ /PDF /Text ] >> endobj 1398 0 obj << @@ -6052,25 +6048,24 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 1477 0 obj << -/Length 3930 +/Length 3935 /Filter /FlateDecode >> stream xڥ:r㸱 -?U#@dwfSl2=ɩ>%3#HTO7lRzFAqO\;fkuj2aׇzc?^ VY{e}s_mG\9'6$?߽x&Kfe,>ooNn@޿nV%cQǏoo~ջ,LAy˯,Uޙ'd^^QJE_zѰtF8iň"s^[\I8*ϲ|lN4Zχu~ö+!Ro -ce%UKd^I7%\[Zئ<ѽ|ꊮ{LLM; -7"dF_ma±0?VӒrT(3֓t_RΧ.zz͗@^rX͐x^z$M,AT~U: ;jN"hEn9&5^SQpWFE}nv! -;oQ,,msj0(xΟX2)ب _.FکN.mR?Dp;I͒tb0K8ȼ,!lf S9J&p.+t> -cUZת3o\#$m>clIGZWލOza|BzlmMt40_r W/bkRޛ:U?kCs#⹥Ssx>)=)H/s'SfsA"rmP+gI>WC9ȅ;=z?HAgfRx{2^U!s-u߄h64p5>93h.PEn/t/}P*L$vX1XAt};O/k7ɻ>|g ,g^p4TfV#n!Lɦ9b%rfRf y 20٫$^9_Kua fSc))-~< цk[`UWQKMܸqeq)E2Z1 In%2 C\642 FH" ɷOl9wT!b0WBh"b<􏁈?`6YKV䎰lJ%ٞc0`)ñt6`K0n-{~@:E|ޑGhđtIZC3< "{/̍L,!KE8Խfll1Jpz{Q(DȡU槳~g>b]p>P'Ҍ6:?4@xFxe>SSP%Bm\,6 -Fqp]*8G]Z -_إ_5} ƔbUmfe]4. - zJ ubFDJQ/ -4[뉟_|%=GϾEm\ *nf,m1K"K:4L%X'm_@\`ceG74iGV9htb%TL+٤:d\6%RI>ʄUˏ`da+Q*sc>Mǧg%u4ɽϔ˂%!*<=ͫ#YJ+^TTD^jFF~}./LyACڳQ Yl©T&$~h!JBH-߿;疿~[WcӶY, ZvʲP GX:v0R\Sfƀ93Mnn6X؇_ @|n/!胾䙟} ϼd0@tl947.99Xmf+b,yj6}W<qb4?#<821J W4vԾ&lP왋wr2dr srٜ`B(<}a_:endstream +?U#@dwfSl2=ɩ>%3#HTO7lRzFAqO\;kubRa7ǫzc?^ Y{e}3]F\:'ﶿ{f-Mʒo?@O?|{c>|f-^2 ~Oz׻?\2>HW^oJ坹~NJT>]G8 KgKvZ(Rx5>ɔTܬ4]+ϧܮOu}Xc;+] xcWPtmepZ#&(=xj l4 K85MqǢjC4UٖuER& +v:>agPd.500/qIඅi#RmECC~7i ۚ ϛޔfK};*uUy) R .Z&+OiBkōXU{!ܖv2 C*POŦĵ B̪}(J `95 +454-H'ҲJUW?Ug8M;yChzi@TkxE~:ʂ o5Xf)txIiM7LM℟j|,JAJlAG}UZmn L %X;pFU/Z0|2t6dr^B'i;[7M s[6Iox֛0X-2>*`lm!Ѽ|,=[ os\WY3zq<.1hugR!c0$`P4aP.ZݢJa8ZqEYe O/j"2 v{J=e-D^Ol[<L-5sۢEo:zz(C'轲nu7!l5i 7 yӎ&x095ڐiDa}"Ba!! _nb S@z#l"ПJ O@Ly ^CJik\!\Jʥೣ~. *'JgFtvi%!5 918MS.t8Y>{ME]>qj؅( 8NGm=gFàY8R`ɼr&gO,Uj;\O9: +鱵w|Pʍ2\iLyo(*6uw@*!OsC5'8>ة;(<)H/s'fsA"rmP+gI>WC9ȅ;=z?HAgfRx{2^U!s-u_h64pț>93h.PEŶj.t/}P*L$vX1XAt}[OO-/7w?|+(X8 +^p4TfV#n!LI9b%2Rf Y 20٫$^Һ۞M0E3l1C@?ghCv A--d%r&TfܸݢT_- 5zHN͌$~z{!9[QJCP#$AI +" -ɷ_=5EݵT!d0WBh"b<􏁈?:0\[,%+rGXu:\%u1 ee@X:n!xN-7`Ǝ=?E xGq">h#4gHt_$-TWzrơF@`h=>oFpW&%ui"j_ elqh6%RI~(["cV~LS[ .Kyԉ4ee K~pqDhc_ZrBչ2QFy_RcHE*P8H@%^dPQNU$X)H~8b + 𹪟%?SV<.\?5ן&ޫlT%J[R *+jPdDO5ԸlmFpM9RB&]§ $-B=]zH9QsJ2x+\VSw r|słp9.^|@$s + :dݑWzbNl8rh?KGX f^?.C +?bAOBZZ6АKNE2K5"`^s]:ں2@< .0 +a)o7(G T(O8db@3W48z̻gpA_64FH^"KS^Kk{POv]LױͬLR׿%TaA/4"@I}c~_<ڈH@)~Vfk=D6QK)DM쾘3"fIPr|I h6@1 llQjӝxaeu_wA+bZ M'&iG/JQ&Z~%^aRןG{i8><.oI}|\, Pi^XD^r&ԇW 02s|`L Ҟ-!gN%z6'C !P"Bo +N&9 ܺǸ bijİsPJ ?ұЗ*Z23̙mrs&>xJZ+pk|@TbYIO?ߊ~ΖAÃX 8'OgXOEYp)QcJ^|缲 s@֜ljN.Z.+_ ._/L_hi~u|(ܩ+*i0ٞ}]_g1}ϰh3})ݮ!6XGE(pB0$J VhNuI(uReHJ徬򶷳#G Ɖ3O-}_Wq9!bX}{ȯCS&s~> endobj -1122 0 obj << +1121 0 obj << /D [1763 0 R /XYZ 85.0394 651.9592 null] >> endobj 1775 0 obj << @@ -9558,15 +9553,20 @@ endobj /ProcSet [ /PDF /Text ] >> endobj 2134 0 obj << -/Length 1717 +/Length 1697 /Filter /FlateDecode >> stream -xڵXrH}WQ -ryTl%q6Z'!D뷇A܄rV{Nwi c 3#o7#1Yuԫk=65[.®Kƫdvy9_=Whj '콺w9dfZ!`d1;Z'o'sO?ލ*z3ֿOxMa\Vjw6%vX0%c=u@AُTT Vz00JcF t8TK' 믑 G dOz6R"6:dT%eSQQR^imp᱆ ҠT2ӝr\ P=#mz_0,5rU-EkE7TlT8ly`}Dp-msuw"7 .ar rZ2-ԙ9jZk -NfˡQUmn/vySHL[4& (|_^챏X`1M1Ǽzis)Tt8J~SWFs?ف8t%+\{L\m1^b@%pX$ ΎX$M4+]w mp˰bR~7Zes D SBkNOlL8풕IhA0Oh&50"M}cõ)I(o(90?( {D)O+T{SˆXOfuWTC -{iC0=i!y7Tx*P.*G,ZΉ8rZscE}\Rnuߘ*G߳׉K^z<~iWͼǦlipϋmu|G48 mjǼ-#JQ\z}ɯ=+PuLq ˑ#&(?azN^Űendstream +xڭXrH}WQ +ryTl%q6Z'!DȎ nBR 9}LcGƮ@y|x L8Gx| mc#nj5z9cy6ǫM͗j}3]^gN-*Zlq={]N=:/q%`Dd1;Z'o'wO?ލ*z3ַ'<^&ލ0b+Əp<:G\0$8cv]9Z>ڇ`..uzdL bLow_Din;Ua,- La٩)FXyl0 g6V]FVV2u e izB yS +yEI]wqgOD~ +t +=r:ƪDP)Dp4QE +r#܁'yzIEv3lJI*˰7)R.o hP7Va#שv靯GIݭCudlp=6Ibv7U{{ s/HQB$%Ve#ݖԝt}~jj϶nPaf@ A(V0*[c#!QOFPK,d˨p@c[WX6_in!88tđԬ +`uCI_#dhaZ ץumm mZau]?Lj~&Qo&fW%OJiYy Pa5 +?zZ1m01 j!F< yf{akMuk^jtc?/r#ML-6n_PP=,` &dxMK qjԌҩA`!!y19ۨj> "|65uw" 7[ +˰^tA ]WX@ QW//zG, ȋژR]\c^\2::[*'NcG t77՚|n4Iq8C7]b̵iBxn 8,PWtgGku&y.އ6~8yw-`j;L  9=K;MYY4a@ pp%>F먨spZi) 4LEuHmE$ϣ6Fz`BPR^y視 ֟Z}VߪC +{iCG̨l<(W~E b?GYt|]㠢S> endobj 2136 0 obj << -/D [2133 0 R /XYZ 85.0394 752.2309 null] +/D [2133 0 R /XYZ 85.0394 752.1005 null] >> endobj 2137 0 obj << -/D [2133 0 R /XYZ 85.0394 690.3554 null] +/D [2133 0 R /XYZ 85.0394 688.8865 null] >> endobj 2138 0 obj << -/D [2133 0 R /XYZ 85.0394 411.014 null] +/D [2133 0 R /XYZ 85.0394 406.5386 null] >> endobj 2139 0 obj << -/D [2133 0 R /XYZ 85.0394 349.1385 null] +/D [2133 0 R /XYZ 85.0394 343.3246 null] >> endobj 2140 0 obj << -/D [2133 0 R /XYZ 85.0394 287.2629 null] +/D [2133 0 R /XYZ 85.0394 280.1107 null] >> endobj 702 0 obj << -/D [2133 0 R /XYZ 85.0394 249.1153 null] +/D [2133 0 R /XYZ 85.0394 241.0331 null] >> endobj 2141 0 obj << -/D [2133 0 R /XYZ 85.0394 216.4533 null] +/D [2133 0 R /XYZ 85.0394 207.9626 null] >> endobj 2142 0 obj << -/D [2133 0 R /XYZ 85.0394 181.2399 null] +/D [2133 0 R /XYZ 85.0394 172.3408 null] >> endobj 2143 0 obj << -/D [2133 0 R /XYZ 85.0394 116.4425 null] +/D [2133 0 R /XYZ 85.0394 106.205 null] >> endobj 2132 0 obj << /Font << /F37 827 0 R /F21 738 0 R /F23 762 0 R /F55 1070 0 R /F41 969 0 R /F39 927 0 R /F53 1062 0 R >> /ProcSet [ /PDF /Text ] >> endobj 2146 0 obj << -/Length 2716 +/Length 2724 /Filter /FlateDecode >> stream -xZ[w6~#}NJnt8nm{) E:";QJelsNdY%E8r}0 q2R?^ TBjK",%Y\oT?Οח1I %勋?Nc*0ȃ0ѫ]*t'׽eC fڬ'oE#X<FD)Xp/y5O%\# B JPJH -FY('!@E/}Y7uq'8[Ǿo-5?v3Q X06s,m -2oEHCJmO꨾UYg]@X21f2_'"&)!W.m|_߇ ;WgktI}mB"t{9j_qwؼˮ< -hJJ_RW@ 4v ՀS8S8FIe8׋ח[9")f&X~0ξ0\ԳH`QwWǺ>άmgYwmrvԆUƴ*LbpR]t01ࢻvv(kdL"B׬3S -1JŨ)rɣv.LFwekه"dI>ФcЧT=mն8a^rBEխDFnpz6s -ك`j!;׶Nml+?b؜A< ];3XtԁP_Ոq fM0w/ Bh:Xbز7^=h..XtLFO# +(A#Hp2(PPÉt%HR6 PnYW\9Mz/GQluHmKskIJe& dbiū~4nQh/,KҡIsTlO{M>3K9\LZ:A'_e6g=TAq@/GJF1s8!b"jsvRŁIH$WwN o;u. 4^a{,aTu P}f{BJ 5VcOxaCi*G*JB$p) Jrs^*315 68N\ d&6hw]O"_%yһZo~=">L9@Ոٟu;LXĎ`95M8 #=X#"#DI"L8T$PGVm_*iX.q3A4۲bX$>M)b)޻ 7b.XeUVnӒ5uB]"h0hg:4쨹Fjކ_kLrʏ[Mz;S%^Hͺ*Ut|e'-mUOlپڲ705 摨a'g]O͉8cI|yB>]1起lbҎYpB{/)1 u$; F'_¼Ptbx!>Յ?)OLNg'%?)=\? ^O`B{}hQNKQزp)묙eW&J_SPpivoI:A Tb7)tKUR3M\ O^<b߉sDaHal M EddY&;%y;5OtoJ 5{d1"FDqLN j1e$2%ց@f7|5{~imGv;XiXW -{/Rܟ1,Dt?YuDVʙGSMQ;’׋ Лendstream +xZ[w6~У|NJnt8nm{) E:";QsٳۜSp0`4Y`G"Fj(&bڜ-tBL䅢ԏ'?dB!xqKI又`t +*?ΟחI%˳FT`a.}/wu7>9,[O0f}vO]kQ%EXcUMcQNS< Fx}:CRm#}vCNˀƈ|'_wǝ <פ 'cMB"t},9'j=jlVlU[oJG1l҇]XD0kEa) Q̼aO!zʑz2708׋חKI1#.0ϻ|DOB9_lAĖ]|muխ~ːv`:'ty}W4vl~C&DNM:}BgҮ׻ ؆yʡ +U\t㷑Sh֪8T#xO4KV>WQliMQfdց HQEc3Y.ovhTi>:5-5aC5m^^v;󕇝Ĝbp=T΋/Z@՚I<˲-*-SB^#ʬ(/ M|g Tv?ecoo]j}T{Zv a\wFUEYMnݙmݥNڢ[4LcNH0pIwMZ iCfW(th:g֏ [ ڻ[oݾ݆+IC!.>충&czbIC5y5-i\i 0"C_4T?tRz(O *92 +Lه*:")ϫt-Z4rPDb8/5NʬnnV>2Wp{ƮIo=]wM}ttgE;'mxtA,:ܣ32N_vE19iE{lk Օ(YBӓ:2|#tudJ/rFє!@t1&s j-qp%Sg&}oK3r}ytR'`D Dl8=́%}gwGn۴3Fݶ҇9<ҦmApn=z)  H&WA}T$a^(`L 97 _?@LyCT//XURy9=!%VJS+QT'ǠѴkz^%PC5Y].POBpu[ vݖS%o +& 0ptHKx@&+a=Mm[>к-wNKe Mwt4F{36i9`GmU F[4Rdeq32;o/79oLmbz;1ԛܳDN|j}lͫ{<Zi~=y 9GTr~, /O_hܥYѸ#ƖE@=az%6ۧc\^D +\Ma b|Bſ*̻M[|"S]'bŸ +Ho%:lTNKD9R:kNO`KO\oQN Qвp묙b7&K_SPpi߶oI>>A Tͷ tKU3\w O^.;bۉsDaHa! M Eod`Y&;%x;5OtOK? 7 կ;d1"FDqLNj1e$2%ց@f7|5{yfir;=_kX*so_T_AD`"=}_C"+L𣉀(atwŘl1endstream endobj 2145 0 obj << /Type /Page @@ -9632,10 +9634,10 @@ endobj /D [2145 0 R /XYZ 56.6929 794.5015 null] >> endobj 2148 0 obj << -/D [2145 0 R /XYZ 56.6929 687.5403 null] +/D [2145 0 R /XYZ 56.6929 677.5149 null] >> endobj 2149 0 obj << -/D [2145 0 R /XYZ 56.6929 540.8661 null] +/D [2145 0 R /XYZ 56.6929 533.7824 null] >> endobj 2144 0 obj << /Font << /F37 827 0 R /F41 969 0 R /F53 1062 0 R /F21 738 0 R /F23 762 0 R /F55 1070 0 R >> @@ -10302,7 +10304,7 @@ endobj stream xte\6 tݡ0 00 R"t ȋ>??w^Z׺75 rpr tP(W琅CfL9g0]#5@ xDDD0rp'/g+_.+ .[ ;9a@=0j@`YIPC@` `w@:@p5\8d\@y {N!v l0f[G3{$ӆ!NǬtypGOk8`4+s=]!.NPcG2'gn.@gk(wuuO= ' .` '&cNcn[ lnN -{fXE0lɥ w}L `u?@# ܿ,vNjxcߏs:B^F4;Wc!d` (B<W} SL70};A`?6x.CmrA˂GP9pro:# ?de^7=*7tux^psr?Fr~sOo4 +{fXE0lɥ w}L `u?@# ܿ,vNjxcߏs:B^F4;Wc!d` (B<W} SL70};A`?6x.}y##mrA˂GP9pro:# ?de^7=*7tux^psr?Fr~sOo4 0a֏Oo?x= a.Ab9Y /z{xœ*2#Dj,8Ey;on Aߋ(X>.3vmsW`gϨ" rn蚗ߡRw9_ҹ_8=e4%v>oFk(?`Lٽ`4&9[~;26cL|r)Sjl( b7Vh9,IRe߷R%= t(%LǏ)>1٥^2O %>pjÕr{2wBx(S|Duޡ{:ґ2G9C{ɕ<|?K@F),w? ah%ٱo^{6 @-%~jwXjz1i%u3^g`d+K[De]Y?>Hj,kѸh8 v_ [J֮9m=?\k>ଇ*ѳ,Y W7}C#ZR$`bGοa9gS%\/hC|?s ؅g)m}vk.b&O +uqf`a,I㯽/ݛ'P6ߢH?ٹ9mHr7:pMRY# 'WKC|-mW躖nᲶ03=j-,nebi;Hl<)L.Yڷ)wL=(L|)='-@.Y[a-Zypx9>穾*|,4 = a{ZwLVqCo,H;_7Gg[Gx dD*~JS/ *FjQjw ]_-q;,1t2ߥƐ{:֧o$c-Nߍ tz"t'>(hSM]ۅ0 SPKDdOj n|KHtޑ+㢟S'@6iC,g3BpΡφn;ɦc _7T,Q1TiHBWL8 ,. u2)=Oڴ, Aqr^T!12)N\)Rb6Cb5ޛ;mHL^Ȭݸ {>m@zN׻B]@)p[j6덶BSHQר.ثN`Gz^n)?892x%3ZJ]\^SXAr}[(0@elmiEW9QѲCۯA=g>MF{Q=*k+ki@ħW:x<"}<=ѥ䃏DKXx( {jdqXPvπiA;@y*oLOxOc -@YUʳ;BiM.\r;UR')眄 @i/_ Ar0FxYjCĞjbnU?uW#,MߥJBQlX-ebtx]s<:XQw-N;N?VlvG,%9'bη9|1.!]D=RԌݬIg=h_5r/  tv;0Տendstream +*s"}Y ;҉{Y]pݯXo}UZ: h)8fEDsqTM:ùɸX!l ΄,17bg&fܽY'jeAt ]wV^%RtΏl阦jϸ3m>YjCĞjbnU?uW#,MߥJBQlX-ebtx]s<:XQw-N;N?VlvG,%9'bη9|1.!]D=RԌݬIg=h_5r/  tv;0Yendstream endobj 1716 0 obj << /Type /Font @@ -10334,14 +10336,14 @@ endobj /FirstChar 67 /LastChar 85 /Widths 2267 0 R -/BaseFont /VEQPAA+URWPalladioL-Bold-Slant_167 +/BaseFont /TDQWWP+URWPalladioL-Bold-Slant_167 /FontDescriptor 1714 0 R >> endobj 1714 0 obj << /Ascent 708 /CapHeight 672 /Descent -266 -/FontName /VEQPAA+URWPalladioL-Bold-Slant_167 +/FontName /TDQWWP+URWPalladioL-Bold-Slant_167 /ItalicAngle -9 /StemV 123 /XHeight 471 @@ -10365,7 +10367,7 @@ x yaha pJH( @B0Y $DB@ #H CXnxX9rYzD"0̓;!o(ׁZi@! u %5Hf@ 0dw9qYa_!n b xZAA gyA [W H8 -rt%n-~tݐiH+ ɪ!+NWnmn5# YE/k'ĹFu/5|Q2vPk|rUm̑=GC>hZ ش?^ R3Ӣ{w| 'V)o_=h!E\U)a􄹫cOwٯp1"])ʕUwĂ_)x :7D/P'ƀ,? NvIn+\}Z(^XrLGXrMߗdcwK +rt%n-~tݐiH+ ɪ!+NWnmn5# YE/k'ĹFu/5|Q2vPk|rUm̑=GC>hZ ش?^ R3Ӣ{w| 'V)o_=h!E\U)a􄹫cOwٯp1"])ʕUwĂ_)x :7D/P'ƀ,? NvIn+\}Z(^XrLGXrMߗdcwK e[ă4f)ƻ'c*2uMׁE;k"{!6ga1.Զ3S?pU!?='g$NV;;l"=+jy4&}ʡ QĴf'8{@|[n.\ex~jS jrk}6KiIs=Z9;/7[;_N[BrwmF][hy;I|P_(\{Er},4JШw5Z!tҦ(2x<κgr>0.;2qaZ.EL_GHx5tՍ;T1\,k?nҸnT at̋]%2{ )>#l6o;^LUjIp(FӮ~}=z8>ߐ0?u>gv[? 3Mĺ??6GK让Qtȡf8 ?; {=tvWuR^.ȋzYt+@^V^MloJfE([]'#|'OF֡3~.IZH)Ljrg=utq,x3-pL܉'AC0[&{C iNJy)>eLc%/FTU¨5 sJk "C 3cU4eHH~0+EOY^݈F͎TUhDǝ8I{BDWRFVfʦqǴLJGЧzTł뗍JM ;2N6OH vzygg)Ղ?YѼN-f_6G w8IwpY%K:-@2GrM 4oP-*ksj#}Ǫq.!ŝpY2 t( ]C;hbЀ16gRtVw>o;#mY0zuk @@ -10387,7 +10389,7 @@ V1-S CwɓZpO>/l4nlU-oMٓ o:|y7MT{ =i3RVHA9jQr3a3X_dhE/O\KɬO_ &$ubsAytN.`.bʥ܆6l}g|wRhXsL84G} 1Ymgzӌ$9Nh͔ŸXsm{g"'HRU\O<>lS" t.CB|(z?п)|8csa4y=~U+j*8ӓ&w?,Ip7o#qw}eJUl]RmLغ=kKJ;uY8:B.C\0&Xs;2`#"tkg\i.(TR-ɳ/%|qWru?̦hΑ7U^K:%į vA7p1tOn4 +`Rp36FŊݹ%:b0&Swj VC%#N^ۙKuy,Eq&8{D LG8UTm5leU?666!-+T(wu9eQ:Jm4 _}~NOkڋֻM}ɲưq`+5׭d[%˦[M#ߦT\*wqg$d]|y9?)#Iiw%z:3KzWFcm={8uLwY|U&n{ebL=Xy*wSY"FNj'> endobj 1700 0 obj << /Ascent 728 /CapHeight 669 /Descent -256 -/FontName /JCKXBI+URWPalladioL-BoldItal +/FontName /VBKIDL+URWPalladioL-BoldItal /ItalicAngle -9.9 /StemV 114 /XHeight 469 @@ -10419,18 +10421,18 @@ endobj /Length1 771 /Length2 1151 /Length3 532 -/Length 1712 +/Length 1713 /Filter /FlateDecode >> stream -xRkTRIzXyL4  OyHLȔd$ J,b%OQQ**RK-p kU*og|g3\"dLo@pdB,HR ԙá1"'Q @'P - y+<>4H>I!PR9B4T \ dEH jvF:X#D&h`TA H -ؓ$706(6%P"aS(i8 PW5姜K^Aպ&-D aSc7fhg%\*DXLh% Z@I -(td -G0xʿ)pI4(JFQԥ!{*)T 9,~{JL)pR !Ѩ!"C`D -p(gr'hl5>29{{_k\V^ #Ƈ2mD)OD(h{{OmWwvO_XzxKǹ'KY}׈"~j1z̮d$+6Oz{kɽrlpBҌKmilkZlNkx;A*Hڛ7^>Mov*%߃DNѕx5n4?aSW&z[Czϋ9wrO]l-ʄz^(4I=.t)}GS#]pAQ@\CDֵj| 5 ]\b(icmKƯKv|y߳z~nό.qrwI_H*C~-cR+tg&.p\_u_7w'؇UjM - -K>yR]@Ǻ栠%ͳA. ډ̑@tG[t_u6ہ71@ JM#=Zm^u?rsauɺ.- Gf3M=VVM{$稠!dU};e9Q6>]XiW*Eim||\=zwBʫkwm|Eӄ6zӒ[F{3l&gg~Է^?c0H=GQh90[4uN |_fr6Jw'2/vtzT)}/ۓ<_vj.[`W `m9s M,%7mDj1-ّ|ws -CO012s/0qv.,O8:4) /T~ "6KTew-hpǦ-˔U~??3loηT$sbH\s 宸7$wX.ysYwګX2|Ktm7[\SV[:a;v:. (}>N_Fxr׺"(05< ⁶Xyy2;GTI~¢d}sIRd Bd 4nFXgx& 1)%6©JaMj* .]*3HQkJ&"! ( &7dM/h*姜K^E46]G8bө[qRBtY J^G2B= E"R T +M<(4] ߔVT'R0JLiлX°VR71O^+Sf?puhߜ9w*x}ӢlQlqtWzNLqny59JH̚[7_=Mgu*$YnՉaXfץnrhpBo[ޗk.TL4V-i p]7I8 ԻE]x㋎ }v$8rgQЖi};Qb=iq޲}Pt6#j_񚈚Zc8v瞊~PE+bӳ6چ+ )L<>lK+'ƍܳl%8Pqo\cE3 ?/}u'L,njO؇;fi@ ?VE1Ϊh#[]h?A+n4mr"n~/yZMC W'JU|<5cBTTrZfƝcOJ^ 7oWD5s2R˙RMlo|UA9/tS>'/_65nDB٪۷_w.wr +G:)\M~֍ׅy)+]/{mnݶ,0WҨl7XY\F+n'oY=,k8a:knA;7xYs9{..RPrɡ"q{?|g2IYsaAubNѭ=.MSui 9n"俻Y8uu©nR8!ݦGa-k H ⸶ѥ-'* 꺱kDq,4F@h? +h/ͺϿK]$]r4j'5EO*b(Uݼy֍O"WQkDVUi,endstream endobj 1336 0 obj << /Type /Font @@ -10439,14 +10441,14 @@ endobj /FirstChar 60 /LastChar 62 /Widths 2270 0 R -/BaseFont /LIJMFU+CMMI10 +/BaseFont /QXVXMW+CMMI10 /FontDescriptor 1334 0 R >> endobj 1334 0 obj << /Ascent 694 /CapHeight 683 /Descent -194 -/FontName /LIJMFU+CMMI10 +/FontName /QXVXMW+CMMI10 /ItalicAngle -14.04 /StemV 72 /XHeight 431 @@ -10466,23 +10468,22 @@ endobj /Length1 1199 /Length2 2269 /Length3 544 -/Length 3058 +/Length 3057 /Filter /FlateDecode >> stream -xWiF:a4v*c1fd(NI{Z,S6zu~{|x_}-u -,&Dczh C$1li<'.@ N2%] О tGB>A< Ecmݑ6= \͠3!"BA& cAV  P - س¢tZ@xliXXXr4& -"@+l1D2A6T8eї@%9PŶDE¨$!9T$tb{V"PcѨ4 a"1KBT:= -/ @' F m6p"SG_A̢Ĥń*Tc8y`\̿1B's@Ov RI\6= -C#h ^|AKa1?]H {y쭷T?_fx~k+57֊'O.Q/F .@~(3e*ԣ5QyHvSYk{?/Z We#kr[{:?V1|$j`%/ѻXCi|a_JOL${ٚs44DoΗ`sܧ:ip/Y' jƆ52ϱL'ˤUSyќ֝1ʲ1ҼD JV"T|aU1I$άрӋߌ%Wݻy@&+OUrY'@u߬pbD=#jEl@H]Py.ˌ|?L]_fI4PZ"Fjn˭fȣ\%򂕄r@}ʺ6Ց61mKgMr7i((>cR(;6}BezatTo -F))c mW^Iw)hC^X.z xts9tM,* W*-m䫽tb/?[tOu/\gHlfq&Q3@JE:±Cef52Ԥ\zFEx/ jj~s<މ{=ZPHP({Q _O2^?jTlzd! +|un̿-Et/kg'[_$hŢ%ij`{~SLs7дU,[-#?+X"āD4h69Ѯ)Fvܸ}MՌJtH5˱ D1ZV -Tw -BcۏkɻM*zbTap,P"Ck잲c-r3AJ{ym(k3-w!:YBwEP٬nw"\!HMwO {v|V+\yFzM;Fu&֌ S -{a.cYGS-?a?:kKz b_X*$|_ 41ܒ{>f+`);گ1U)b>^O]JOUwioYk{BVE`^ (g{8=zZ%KaMrRT*=|41a˺GҊ]%Еo 3e2"hFQ5 ݌>yd'hɧ>9{X`Y/o0UzYr"Q't^'GV]36PIOvMH /tnKu(c)nJ鿿{]d/,١Лχ羯uQMt/ВNc(Cf}A2ۚ+*:PXTpM4gxNY73MF Qݑ0 0Y JAN`4O f@!@*\;3`NaP,YEUUm``x|G ȤitlHP_, oAV,? B6$, X ќB臡0@XZA5!F\mpQؠ5i#,@2@`5VR; zŌC Oe}L| l0<߁h4@XH';dI6x (@?V%iԐx?psXO33:D54@GWz|bՊSҚFZV `B + VG['-E!ytPA|!5%J]UM҄ VTBgE +?~jq::.tMid*5)LKJ0HRXo]nt&eC!:_0o +2СB KR N(AaX li{*A|Nyԧh%S t翲eT1$wovޜ~zmTf=W\E^Yrpxɷ˻l 7OmBtO$SOHd1\ټ=!\]4rۢ۫v0) +^*bKP# a9OL|RWvAIȳN8+8zKʵDϰu%%^j]Tψ\bz+rL0}K{*J2[ 6B: 붸Ep.%L&. ge>fdL|r:-ۓW"%Ty>fuWȄ<πMGYU R[b:ƿ*;lȺiC5gZڳH4'?銪/sqj}}T +󎷛uO'G oVY(@VnӪqh"4nb$^M;N|Vàh l u|w0z\]K2DŽSޗ׍:2?M`vgHQo9̡N9aU[5w}tvyc|%Jfk;w7XSX}2Gu{Y$"kS]NɂG7Z,5=fy(ݳ3K=s5Vn+Rtaf_$DZsVR4QH,HmKrJYxۈY~1频IL9G8V`E~Hܩ֡u͌!wy_>Y&e=#y5gTZ7 $ۺNqu/aE[9 yy»{f`m +WM{]hV#X:cTA&4E61eR"e92Ȼ LiΑdգLJs2 bRGϥI@H>5L,<0&*.IYW ;;B>\Y|Mz=~ED]oO6;scF]OQKlIG7?hl\,J=`§ИըAĜ.8lLtgWo߹°5I;"M>:-eD<'Uo",V*PbweQMocln x i#J^\vȇk^deTϢG4lNO. +=C͒_9.Ş,wvi~V<ch,(9A zU®Af/#%I䄬FUzl Y+x N\_JwscJX'E +k?~p&E/ PlR/{>*"tD]Q{Gw'\5_ʐ8g/Ի\sn^kq{,n~x}K2\ds?!7_+H ɲt[g_c>c6?R=Ę&6ψ==%;T)Wn |?xykD %8vѾ=~Qù%ng/KOv +=aw6\c^wrR]>fx){bZ$NqO?A@xgC \7 @endstream endobj 1179 0 obj << /Type /Font @@ -10491,14 +10492,14 @@ endobj /FirstChar 97 /LastChar 110 /Widths 2271 0 R -/BaseFont /FWVKMX+NimbusSanL-ReguItal +/BaseFont /ZPLWDI+NimbusSanL-ReguItal /FontDescriptor 1177 0 R >> endobj 1177 0 obj << /Ascent 712 /CapHeight 712 /Descent -213 -/FontName /FWVKMX+NimbusSanL-ReguItal +/FontName /ZPLWDI+NimbusSanL-ReguItal /ItalicAngle -12 /StemV 88 /XHeight 523 @@ -10521,7 +10522,7 @@ stream xvgPTݶ-HPPə&ə&K(HQH s 9#$sn}zvծkιsVmVF-]^Yp@4`(]EXYP0pPOP@jXGw$ 1w۝( G8Cз㍺P(m XP1HCP:@`8@(('ZP|X(rZnAݬ]<G(B~`( 쀾9X! ڭ9"[0- Bр۬Z -JDۂѿs`n6r]-̭ 9hw.K(C9o?4Q01 6`$Enanw_u[`GG݈?QCpk>mN+mnA9X#@g\? =3$Zk з)3s"$'5o{ ko p{àjw M 1w 4 6R e`nP me o{Ǯ"0譖ͧg sb\Pߙ7o?QZoW?1nO^WH@ ĄżM?@h$ ho0V9E Oo3y~[? +JDۂѿs`n6r]-̭ 9hw.K(C9o?4Q01 6`$Enanw_u[`GG݈?QCpk>mN+mnA9X#@g\? =3$Zk з)3s"$'5o{ ko p{àjw M 1w 4 6R e`nP me o{Ǯ"0譖ͧg sb\Pߙ7o?QZoW?1nO^WH@ ĄżM?@h$ ho0V9E Oo3y~[? uZ|BXLLIBQdt ( ?V1x+w^9eІڥu7N/.')0Pke R ]8s&s߱|*#>cկ EymeAƀ>8m 14jrXd8V>M7&N\*JO8^J%q .&;XB0cVK0-S۷ߌG?E((˚=+y\J6.޻^eނV(b*$=AmEa9oR3S!89rţC™\-ղk͝8 @@ -10553,7 +10554,7 @@ QH; {__b.}ttQRD!$DrG1A Y .#_#wŹ|S?Z::fגʵhXafڜ3BuቇϾʉltp)&T+pe ZM31ILcG"HxS$_*[n~OYgC LI8GUB\{S7M;䃵h0GQ& <"_AzeN2PJ"u]Ls.}QiH5qLUj[ =1YHOoq!Rү%~u 0׷6;>nE=ma\{\cQq&T/b^}m A陈O/I>cb%& mJ;7b{6eC_<@bW+Q'Uݧ/+˰a*/5 JԆ'l 0Kf/^OM [IfC `b1}U*i g#H+"2X|F#Lq؏٪r#g 4>TGG$ 7LIu`UJ2΃79~flΚW 5?|':U.rJo l5AxE3ǕT#Kt.iKW@/ɛ j&Q Șth-ؤ1b?eF Xr/&jzrAMre.2e%ͣ6"5[(H4 :\mdb[i:P20JѻphQQQ_7;mA^;  v*Hߐ,QtT}bWgx$ӬGי'}uiD;xԡư~. %4O ޻B\ -vm$tLd?+햫I&VZ"-35MG74>auAWr`HW{w1ۮE^["W%B>M#nNCuyH %T,T0]4.dk0Pa5Y F?U'?Ջf֤qCra1j,2ӓ=D4eI vvbd)x)\+"oܴD1[|)h$eGUe?auAWr`HW{w1ۮE^["W%B>M#nNCuyH %T,T0]4.dk0Pa5Y F?U'?Ջf֤qCra1j,2ӓ=D4eI vvbd)x)\+"oܴD1[|)h$eGUe?> endobj 1101 0 obj << /Ascent 722 /CapHeight 722 /Descent -217 -/FontName /WQKHFR+NimbusSanL-Bold +/FontName /NBPOSN+NimbusSanL-Bold /ItalicAngle 0 /StemV 141 /XHeight 532 @@ -10591,7 +10592,7 @@ endobj stream xzUX\[mܡpww.+pp$ !www'.s?ݷO}o{?Ƙ{9ǚTbt299rqTnP-3GeVM5Cڃ~!! 3W mP18BB/k BurA/U A  ꥲ vrm\ :z,B8^1l{Y읜"!rA^#VLGWWg!vvg+3 bs3*h)dKS^?`+-Y98]@oe'Bf rrpqrp@. )Af>N+3{(lzy@AW'} [A//d+ 0`pqserN^ -W5sإ5j3FII9HrXx_&EQ/DS'ǿ$:Z9΋@_f3]_l0kt8x9^_G:X!fo+  {39 c:o] {,6\;;A|VN^οq6` ;GrR G˿up;Z\_ bO yzy@d0d!d[rS)I=ŧsFe۩JhWB“[ 1SF}FN&$D6NP 'V!FDUa8arW eV? pwE 4 YmoQ.XMOCazM6 4U~^ZtS֊m:3-?"Z}jNbP/6ug]s"KO ~fB (TH6QfC5.M|/32^ǔy;.HwM< :zq]˚fߥVO;pٮ:Vn)S!]ǩNP |FdxV3d(C@ذ]_lsXȜgOl[.r.m]O'Ok:t=?=ŷydwaȈ)lFLx5fn; $4RD䯡x >%fA noX+JGFIW +W5sJ*J2FII9HrXx_&EQ/DS'ǿ$:Z9΋@_f3]_l0kt8x9^_G:X!fo+  {39 c:o] {,6\;;A|VN^οq6` ;GrR G˿up;Z\_ bO yzy@d0d!d[rS)I=ŧsFe۩JhWB“[ 1SF}FN&$D6NP 'V!FDUa8arW eV? pwE 4 YmoQ.XMOCazM6 4U~^ZtS֊m:3-?"Z}jNbP/6ug]s"KO ~fB (TH6QfC5.M|/32^ǔy;.HwM< :zq]˚fߥVO;pٮ:Vn)S!]ǩNP |FdxV3d(C@ذ]_lsXȜgOl[.r.m]O'Ok:t=?=ŷydwaȈ)lFLx5fn; $4RD䯡x >%fA noX+JGFIW BF )εqb`1߭3_Ǭ8hJ7 yaH9cRClKQI_Qt)25iX٫ؐ/uc䈄Xm.d=(`&5UƔh3rO>6I!MlI6e>?fV57O!饟s3$2B- -8X/(tݫj{טsɏ6V\_LqF/ ]cF)@*n'(i(Zp<'ۢ0ߒv\o; oژ 3Ogs7.-~@`mڎ}~aIiBX;ѐLv4ޯ~,5ìm|h?⸄3ߞ.Je[3J"kv}]<3'j>QTzTNZ~?p5v66JZ4滫h//y _ƷIrNl|8jʥױ907ڈ ~h b.dkП%):+2X:͖$4^t+hܕ vӘ5]Y%e6xsٯ]?kv o< @@ -10625,7 +10626,7 @@ A t9WM@ǖdٗnC+Q'++%6|b`eʮ\` TB,kt䪻!z}u` `48N6ξ:kMk0/4Jh'lMc]#6!k)&LҴ43{^vԎT4]NTn h^<϶Я-\.Y4!8%Xzʇ$=,8K#me/P_A1T+QykG͞ԃkm%׹Qg["NtQ?12wD qٗQ #o;#HK7W y‚JڹHOQaJnK|$` 3$Y޸#M*C3q'&߇EuE[gC@>n$"5LYЧ7c?UGrV#zX}j1Mawft7nK\s{|RQ1QDGx,uXP 3:A|endstream +g~؟¾?H̪Y.#kEND10KLOJhA:ߓw}YKdN! IJՍn~斶Z:]ړsn4ËaRZk-x>n$"5LYЧ7c?UGrV#zX}j1Mawft7nK\s{|RQ1QDGx,uXP 3:AnQendstream endobj 1100 0 obj << /Type /Font @@ -10634,14 +10635,14 @@ endobj /FirstChar 2 /LastChar 151 /Widths 2273 0 R -/BaseFont /CQIVNT+NimbusSanL-Regu +/BaseFont /GIAJNA+NimbusSanL-Regu /FontDescriptor 1098 0 R >> endobj 1098 0 obj << /Ascent 712 /CapHeight 712 /Descent -213 -/FontName /CQIVNT+NimbusSanL-Regu +/FontName /GIAJNA+NimbusSanL-Regu /ItalicAngle 0 /StemV 85 /XHeight 523 @@ -10661,49 +10662,45 @@ endobj /Filter /FlateDecode >> stream -xweP\.-84N@548HpwwK>3u9nݮ]]ZwUm -U w3 ] 7ssQ8(H@,TWFtC A 2pr8iG/g+^K]?*3 .`+;hrp}j@WklH)e 39@lrp1,!sOj.\\@#j49 g{;r:;۹Y Un + Ggȫ+J -qqu1w;^J5o+ XjZ@J.W_f Wn.`F pY-@..4<%{_֐3 Βէo+2۟as8[9s9U ?3`Y")C\_]g]f5K-5_{_.>+2u^2-(El`;_u@G_19Wk99Xo1E P[,vK`r;^WA_Ӵ:)?_cm_I)KJH1w/Mpr%HH@<>,N>~?7; ?J@Wg''v0X Wlݿnk85 'yib.jZih\ʠv(̱^KA`; =rS:aRkiWqo]w*$ďki/͸-X'tVq>/ָq#QԢңcX(&)W|W򮰾U&Fo b~UyO| E 󕌈q;>޽Y/=eH#1qwm)<5lmf`ES$x1>?^`_0I ӥĨ`0C<>}>דrIQTpKngV5˜n5>˶S}f-l[u(0<%' -xTZn&{2n` %7h*.%bpnR}8\wNO=`Sܖ}< KpRʳRaeS$1r}rN*VC*44;3Y1IohHtC{-3`SJKeA''1iQھj)!cvB~ՓYfT̘z71AlkRҏ؜o||xwA)ŗm)Sw!~.ۑ&2+}ߣ[c8>}q3I!eg@LM|`VajYRl~O.BF̶fl`[c/ˌr4*%3eɓB|Ȗ{D}Tܼ&1a>Qʨ%^=o7@x,V^{%8j9` 1Aɫqr~mbiEjK -o9~vFTVBr!-ZKQ9 n|տ~/#f<!:u\Dľh&Vڤ5s73[FtΖQZ!XxBj^Z‘ MmSXiL) Պ%ŗCwCp'v/8:L- =L{_vDJSR,%)QohoypeWW C?DsQ[t,-4ul>y5ԙX|ƨ}d>`vȏGZ¥Ά7 -.8M~lfN4}9ÿڂIO-c,E5+'t].%}=n*bu#Q1:}5uF)J薾P>jW㌾\~L#\1d%W^&h"[=BVyu'bPm6(/ެ^̏ -4+ 7SY3H46"3ˎ.v :f,Rnf~c>j1%0@R5$$2 Xv]uBGuHL/ϓyG5iX1Q|f |m r.ݗkV_j6ZNObf ?%Hc$XV9t T -iY!Xc[!;8,5r #*̮By0,Ք^`'l- KL(" -x"u#9bt谈~uǛM("1Ģw3]S}C͂^)gxY>( tpVr=a8|./`;y:Um(M -ҎccXl;^ے>@y>c̻~W)/nB|"Fnn Ajn䢘u4~\FcL -b$<,#@RvP9眴SnDyKϤ`@#OawKTQR !J|fۗVIG{)̪qK3[ !~ŌѮ^4Ң~=L*Ɯ!óyw .h \hܙ= -T ? $X xd6?M,W_3'}ex#[&ɋzv -pJvu|v|:͎Rpˤ)M;)qD%1-[{?Bq} ->7B\$%`Q"ͤP}kZE+< -  }Vڔbv<]'*~ͦoz7݄`"s4Iʢ+찗\@A7%XV kICx_ST#OG~ޫbVV 42 z YJLMt1?#1It'-ܘnš'29s^XfM%^C9(k+{Phit| huKeugq%@ӭ>MLMl ~0 KGBxpmIWzVtRD/K Ɖ\' I Ѩ]ϵ630a[^!)S -@G -޲+kt~ j:F<*I7UV\<$iB vڇg5~0B ܑRÕ[&x} gхy^iV|qG\ ;py#Ŗ_&EE E* O;)`L둩'>^pA({/rqĉ) k#4bq"(ى>LV; tvfQO|,Y(L~q{ȫΉ/WxWs((5R & Ҭx<+1LV$%5[-_Qau[g&^h& JK@H&@p?\s>xRv}7j]/q}_Ac d9}6%A,zS(ZFM,G>$%s/n -=[DSh\+{/^HwZoǍ^*aW,*Dj U7IB)QNɱ ب5leXߺRz9pMufrxgE~Ҷj& eu?GQbgr7uZV#r ^"bXW[K6rV@ߏ[-w6tF8D?jm}RfLΞZsL0S1ѵ98tbQ<I JQdV>xD0㋪ -} bX&nLJ =%杜$DA(ι7e"pwZhqn!PNPA&e!=[\$N3`WDySIe zh nL VIyy<ċjRafDP*ڽ~tPs-i Bo G gOdoI3LI_2'_s+E? &hA7?.]|Ty~Ie}?j{hr@0˗4%Qڱ<|USrRG-g$noދzmNIƦ}pjut":uBDo.igE%jRƛ1HZ-L&Ltʶ] -O-Z! %|'K_0Rt9;yFgTJC!z=%[ wW)ḻ(wp16"K iz\Hk7\)uRl|['CyC ^fެ&P^| Lr:mV3<5~i L <ڌmωt/c@fhFS襱Ɯ\?۲'Paz;r# $[+ƟwWFTedh؃$M4UvevXwgtMZYA!9N 4HfXګV/on@ mRr`dc,L .YC3  ]Y8!ib2*O [ -[H"*Rqéқw,&oWYrUǩE)aw|:=0;fI; ι̝H;{󄘛d>4ݏ 4_+4){L+z:zA;_wƪDW1'>eI !Ut+5 qc8O-|mb%%? -( FY# -+?uu&Dt2'4mDGP:&;jNv8Xқtߔ,pTk@mU,\PAiԩ -_kd0 'zyֹ;$&y4)BGm9q~el{93j(#ĿvI/z྽` Zć.1%Z ElAQa!Xa{TuA}wXm@Ma -IyD& )頳![P@_$ <#?{62Sͽh_bRf&2 &c%4(ƛZ/uD^pܻʨI`rߜܸtxG(P7$}MM&vo)f4m>4 -Fտӓ3m U+o],_[ːQւpslX%8KkjxFP܂F [vZcX:emOD/Cs 8~xh#%ޮ'_vLpQqChTb7 ŢX8C5-: {皧DO>y8ްVw38' -b|V#ވF/aK1ybO#M]pQ_Ky3r2/HxB H>z|'ۀӥ|\Srriᰦ*l[V'KRcqMc^Z\J|GĺYZf 5 KgFE}>5M-IEB>Kfj3eܣeW'5Fή(F(k٥s8Xa#B'Wk/x˦-#&Yys{`8Ϫ7W Z/LFSG$`7Vek2Z5i<V/W{GVhcR8nB"#,ţ" y]|N?d -WF -v7w-m} ml'%bAHWnV'iT8X$>?%NaPS%(q$BQ Uާ j^Gy폚8rgB]È赃&OnQQ jGƐ*jz -ii?7X b̠>—iu]TtyrhfX[ɾյdiOr7џUgYdy3X׋'VF/-I8q>V6-~7~vQwJ*zWd1UoTf& -= -׌lZ1$Kiu(s?H{$3T?7L]شӸg=VY5EP.L{i{ %'rj"[X?bMHDa8Ob @lJ4U??U*'lt)a -G,*yќ>]-GOF܎S #SAW嶯 N!H@ㄾe78гq⅊ɠⳓB P;QsUmWv€&x:_m(w tf/f 9jGwjiglР's\}-J9H!︻f8#:@UX̲7-utHt>Eqzk%[h]xuA:ڙGczݱj~d|pk䂠֕/|IA{5ҳ'˻e 7(ϛkE‡'Ulڪ4-fҝ_{Ծ[H$1 ?SLX'fR7d#*NzwGɩʷzdP7n]сgZ~B SCDil -x*9,RZaaS-ӉA !!ZvLyuXr;7:6ut&7$#|SB"AP.i8 Z#;p{ԺR/a3x =6gK%Fϡ]ؐL'e!9{'qonhX:΁4 -7(M:5O^U/*[A}_/LNHN͝+P۞fX0Why)h낵B`N+x\%.a<+=o. E GB@`wHbZt`A4G4sY ㇠iZ>Vm6J)!Gk|y/jy(.JfS&N+OZ^HR^s*1y(&)`z~}šf Vwr^NI%i " -$36׀L)[wr)L{:+qC +$[ 73yҹI -5UNVl?($bN~o 0챤^ck4)SmA祒G7 =9^l ([6ԫNLTiD㖯.qm%EFD}?l5KG9ΘK|ˑK#c =f<̠Šv#=J#n%D7R$w&XGުEˋ+ߜ}P0s_XTutaPB"ƙ>U\0R;"d?]7j 팓ʔY~^? +tqqs:*of667>ĝ]׈^ ׃O9jXJ;J+Q&V_Ttu3VPnOwp賚̭My:(x.< !v[a'\k -m;M1A>]89l|TBk=X"x۾r-}|. tFsJր,G |"vMg|tF'dEAF..'#]X&l_=ԈGyX_pEshF8@U/(A` ,5r:>ی.G%"eg>j%J8 \<_ȥ YZ\TYQ䲃Ѹ7>ߖ -L_LyiZ)) r@pMGo[k47m)p Z(bz>-VR}|oםw L(!^S':p{Ts5 D+Y_+ -SP]B/N}e}S%A/$g0(%>y ]}Wyc.C;*Wu+*CUxvDr}Ir/up2wsºus!Bk[]-Q0FSK9dDi-EvxZ?.pG3ֆڋV0Jy+:Ցo(XӶ3)~HkjfQ--{gl0iL[5X-P{ٔXn1k47IS#|]]U=`[nڧ"Iɽ kNاBAV5 ^8]UPv=pLb[Bb&m%"$O2b\AYՊxiuvr#Bd̎f]T')Ec?^Yyΰ/ s;btEendstream +xweP\.-84N@548Hpww,{L;fί[v~׳ֳ]UBU $qpe`e(\ ,; 3;0At])+HHd$le +Ra`bb +ȫ @8ڃ\_)dž ہ*zrʲzYe-, bP\@ K3` +;2L9}+$\R4[YU2k]O$D|}Y V/ + 3DGf'~d'6h^ħX+F ZfX|2-fO,םS3eyOR-TXIi\ocy> + rĎLVLz2y]k ا”ĸҹRm IL{齶zJ1P%FdcV-ӦEMLP';#!69>ޝpPJe)y[f]EHKvɤLƊmh+uO_XLiHـ;>26S_6@mZV ii+>p!?iK &.2c,.MJd%QuL{b>>F|^{tY^^C UwgZ`ɟ_({se8SIJ &l/xF7OFKDz|=vE8I8hBO<+ׯILإ.k2jmzt~-=.*^c6NAg?#~x?dLP*;huEuZr}Z4R$7[{Gm;hEQ#UՄР\壤f gT4:;č$s,'"ġќU#s1J49: ~ffK2#jX < OHYK]K8~W"Bm +K1)%aZwSxnXŕbG3)Aiv`/X>>tzxH 3ѭ!HTM@^\n=f5nT?;[A%HJ=>3A>qI1w']2x&zY~ +C^Z;RAdqn|p˹s^m_Z%MIp3.*Oo\χ!3F{HR9~Ua9Cgi78$pAqgNxW(lR-$3lc')4Ut+TE7wͰFxlJ $/ʽss`+)aNսCJ!!`4;J9..ں4e!_DŽOn>nlG b)h@6ro=Nc8s! L0Ge2nsxz6Bah *|Q$dITJu~ؠ+FwCG 0gVQmۜ@l/i)[ 6IAM&Zaq/p5p{*o)f'T=N3oXc"Qݍ&jlr-xy ̐^cmJxN~'r]]]­D]NjQ4]8>* ']T nW%qd +]ؙ(Ѯ-.7CzD͠rdu\EY\74;~GM7KUgk/1Skl=f J3{jBܥD'5·? ɈHR)8.}Ep18 Jd&[ȒR5ˤ +M A4 ֗[7h=-Ui53t\}JP $T)nګBGC{cճ:etoɅ +_}.^M7a_r&(H8MRd +;%.hq XI<C_2ґP-ޥ. fG)vq⚲z=:O>9:c#iCr+^g\{hQE[m*= r>/z5"iv_'8864P`V)Γ:!(u:c Pk~YcٕTmfNGxjlo1 Pw%-M8dzVtRD/K ډn.$hTZ`ir_r)#oٕw5:ŚO{#$A߲WMɛ*+GRkw!ALac[TSmHf -i<~>KV_ݳePQZk0MTAP;Yh Vb jS%=HuCKj˷Zcr( +Vau['v^h& JK@H&@p9qׯJnY8f12@V F+HY]K<#\ 7&W!*z}syKy<5q8D0?-SbC6هe7 գ>W,*Dj U7IB)QNɱ ب5_leXߺRz9pM / Xmma L ʼ9vGQbr7uZV#r ^"bXWċ6 rV@ߏ-w6tF8DK黵X>HWFE&}gY9TX`9=1(uwV +~2o+h^O =Q= ~sf{$Օq4N uN!aɭH6*_uۮmܼzFn1Uu柂!is,,c9pO=ggp$-g˖*/ ܋-'e+Mz;ìEԾz$_XD!QcK; j?Ӥ +tcӾPR 8QFl:U!p~"7߽KnYpQnf|5v)V 8-9Fb+1tրpg{1LvL}nn}loůޠE8GO$•uFJ:[3;>s+Jo<߯ |8R,mBzZv<=!M/WJw.Pvz:$=&<7&~l 1O !G{c5u2FGwS6js" &` +45ޘg[V_|*L;cG5f}d J:kQ&㻹kYe-ڀ.&7FMU](BV-uVkoH3SM>*ut[,k/2G~{0‚~qX1 ӂK֐LBa2pWNh{SzEMT\jx=p&>-Ii\qjaJ-;y|NMk₄s.sg:,< n 6Rz٭`M7I%vϛ)^^,JuxKfj3eܣeW-'5Fή(F(緫٥8Xa#B'W/xK-#&sYy;`8Ϫ7W Z/LFS$`Ľ7Ve2Z5i<V/W;VhcR8nB"#,ţ"y]3|N2ˀSFo\tC[ۖ6>߇6G6jq~%bAHoV&iT8XV%>?%NaPS%(q$BQ Uާ j^Gwy8sC]È赃&OnQQ jGƐ*jz +ii?7oX b̠>—io8̰ʓ= ֫k,o 3&,ƿ4N^[ғq`)?V6-|7~vQwJ*zWd1UoTf& += +׌lZ1$Kiu(s?H{$3T?7L]شӸ;cm TA3i+xNIw~uS{~o!L?ϰg1bb>6Ҹ '/Whv3%;&.ONݛ,(Uֳ_&q:nD΁fi O{ /VO />})dAJk9҇ϿNN' +'<|`hE2%aEZߤE3!)I rbvOÙg2U݂sOvq֕ +~x ǣ5o93Xle .1zH̎ k{Rw{FX|MpєSUeq2%4/+t99lH+ lsyu>^h.X+DVd(ΥQ-]P@ެ|*p,}@)HD3~D3UX3~AW˃~٧ڪ FB)S|iʗrdn6elRx`.>[ +WRh2zWp'^n +ˆnu'n饔 wNg12t, b1IlqzA2[F3ֱ}=83?)FOQHhOn%}X1Y_we[CXYt.6=0XIEEX@q+UW3 +mQc KbrA+&QdxiZpoZزB&Ha{*}%=CR} .B~aF OY˘ցtfRG|V%;YUbTSKq:5I& .°ǒz=ѐOJ!$PjhU6m[Pf;1Q&[~t 6aÚq}Hl,I8c.A//̏Ѧ2h0ڍ|+a`)*X}Q?*{x,r$k}Ct?ngn|oٮB7 ̑9@aWɾexµ ж]v)nJzz|af۸ dGW%_)!ktI@4G8d HRP'"(O״}ggYgtHY*Yp\Da4r.8eUxAnRKSi0AxW;UyW4at_;?%vn4KuFH:$r ҆>1-W+4r)?%UVla4ƍ7cA~/SS^3~,fJJBm$\Sͦu"A +D"O-w}xaT_'ug~JDה-8\^/lM!@CA֗f]E'n[cI +k/ƙtF. JIwO=h,`@mUoٷjzCjq<>tEecõBŽh[O =In㚼{T(z|ڪfD~ p]+jʮ'sQlB^dѽD/OIF q+9AV"rxae]sc/3Y7UsIʪ-@iј)loꏅW'tvmʝendstream endobj 1070 0 obj << /Type /Font @@ -10712,14 +10709,14 @@ endobj /FirstChar 35 /LastChar 122 /Widths 2274 0 R -/BaseFont /DNCEWD+NimbusMonL-BoldObli +/BaseFont /JSBTVR+NimbusMonL-BoldObli /FontDescriptor 1068 0 R >> endobj 1068 0 obj << /Ascent 624 /CapHeight 552 /Descent -126 -/FontName /DNCEWD+NimbusMonL-BoldObli +/FontName /JSBTVR+NimbusMonL-BoldObli /ItalicAngle -12 /StemV 103 /XHeight 439 @@ -10744,7 +10741,7 @@ x www4XpNpysu7^ko͵撹GC"n` q Tv.J, KWUS[0 Ft!`{) $@f;???2 @likk2011 ߑH= dhQ5A ۂjUd*Y=h Ps}k 6ٻfZsa}w. 3[  p9ہ]\`36lofjWov rtvx{\ .f`G-?X!v7Os3׿Z{yC!@ 08=r9:.lo - K-Ohw^Q`Efxiym Gײ[8a7wuw "s[JOe=$_ER˸ڪ q(gl΀'Wz G<6q{7aX9XaȀ=@j`h6 g[=Mۿ//7. u -OG*;/ 7 ;cg/2Mϳ2 ӿHۛ99۲/M㿿ڃ@ 3_f!ٙoyR=]0ZE&5 sG/; + K-Ohw^Q`Efxiym Gײ[8a7wuw "s[JOe=$_ER˸ڪ q(gl΀'Wz G<6q{7aX9XaȀ=@j`h6 g[=Mۿ//7.*u -OG*;/ 7 ;cg/2Mϳ2 ӿHۛ99۲/M㿿ڃ@ 3_f!ٙoyR=]0ZE&5 sG/; C]tiR ݅XmLAJ2ucfaytv7G5J8޻R:c66oxp{)7F 6:)DT_;iv";)mq*?15_N[ǯ="/LI}klB-|oRk&[&reDQn?[K797//_!mџ ʓH]yA8\ٟ.hBj{ȣt= !DږbOt8&#-L.Ii\hR xNL Vμ0':n]k+QbP2,鼕8S>mLp]_1,bMz\#m-$ӓS4cW"?^aǢ;P<֋2&<Adޡ*1)n>,Ua4U/ CԽ!L0Bk؟fRkSGD:,aX}K+ɥa5b=LA!. ;EF`;[a9\@~3ű RIPEPʕ!.lbl!3Ԫʝ=:5ħ"/pg7<_ ¤(LFR.31s[\('t;w&YM?cmbU*X/2I y^TAHAmf ɏ9ۑa_ˮar;zp=@[>`SWNta7&%XΒ{ w1 $tL+Qz4m_aBkzKH-M_p:4 1NYIzW۝y 3TÁu&6Ӧ0mBwQIRSj>ŧҗQFbp5S7ulI*(>$i wi!Q4…vU|Y wuNWdt[Km8~=i5]SMj. qyѿZ6kşZzI :N=qo+BdAYgOtN.Emv]4}Ұ'~Rfv5cى)8js;CL~%P"U^6P'% ' Nurp~Q }:|lLǎH|wA nT:z( !ɯ_vE|E#uU9x.dv!:8ـ;pJ#WT ª^'HmAFr4,=gK3M(R @@ -10776,7 +10773,7 @@ L u{1Tt+jNpC4@f:)0tuw`J_fp@ cCrjRPQ[C2J~?.p޻VXz%^ε'RxE#ET`T*4d ;Qͷeɍŵ-~jͶŏ`k(va ឆ*lNfrNJ1|/04jȿ>VE" OZz,q!]3*؜>ŭ{+$vfx[VaXݸ#O fegsBgtD1?Bmbv9'2S☟/]`k$:DK$r[[/oᇦ~fwHCn E6Kzv $g8qx!]`b6#2P֊>)ЦʈQІ)C(Ճ}R~_>{u9;ƃn'\ =i{,eb=Źۈ6߮܀AŃlϺΛv6 5Rj8ph. 1,Sd^5 O iᔚ8ᧈCMIrd#588ꯦc9f-mD{nʢ,BdK*FΑt028!ۙh"}8B"f]M<"$[nwYŗu6G=G(fjwf_YmP'MWuKj\EE}SycPc UW΅{gV)qBPg jJ!O^=F~Hץ[ ɻy<]REx{r.SzNrcOd6F ZŻpLllӞhs,"Tq^Or,şE/*f#J8\TH6Vq_(7QNQK7Vӯv!YԫΓQڗ>mНNYJ5I^T3Ey+fۥ԰ H7۳k 9?b& =eG"kM孕XaI\mh]T8NKmp?Q㷰U[y|Z&AL(^X&*H̷lg"o aT'z^u?%tc VuA|ה6>1'2ogo KT3r bBWnPZ)dBTʹA5S5TU:ꋰzBnm`L !H+ISqS&bF gVYb(X]>)FV`/#߾!Ȏb>"*2007T} fTMEf>5qրm)~tL({C^m'y؈~ EqTCy+vFZpZU1촂D4Bg9{PSv$ \xll5i$TlFڗ}Gf< Ƞ-%2bh{agCW{e1F'G)a.BG=(CjHk_iPtk7zet9)U1M6 4*k?<ꮢN|P.n||U+3FMhƜ 9?hHnr -0ŇUPA7Fw'@P)BFp=(LN-Y.F1N4.{H/B0N%@&ZѻBhٜ큄W$K[it9;*FPkxOy/OwpB"6l:UeP -^; Xޟbk*G/O3(|hɛ%Y6M~O }%K|9W+[XP˸bh~АT:JM,Ԛf4nh~1}ޮ[/0,1 4E]MIw1x}؀`dt.]^بH(kOGɯQ"gϟuAh{f{iv٦=9)ԕ#KT+"dXkS.]l't8mkendstream +^; Xޟbk*G/O3(|hɛ%Y6M~O }%K|9W+[XP˸bh~АT:JM,Ԛf4nh~1}ޮ[/0,1 4E]MIw1x}؀`dt.]^بH(kOGɯQ"gϟuAh{f{iv٦=9)ԕ#KT+"dXkS.]l't8m?endstream endobj 1062 0 obj << /Type /Font @@ -10785,14 +10782,14 @@ endobj /FirstChar 34 /LastChar 122 /Widths 2275 0 R -/BaseFont /TGVXWF+NimbusMonL-ReguObli +/BaseFont /FRFDIO+NimbusMonL-ReguObli /FontDescriptor 1060 0 R >> endobj 1060 0 obj << /Ascent 625 /CapHeight 557 /Descent -147 -/FontName /TGVXWF+NimbusMonL-ReguObli +/FontName /FRFDIO+NimbusMonL-ReguObli /ItalicAngle -12 /StemV 43 /XHeight 426 @@ -10816,76 +10813,81 @@ xڬ .F #['*#Ҝb 9 N&Fc؛8X89X8 l`akdbOvJ__0;'g'#G {gߨ bN;ӿvF./_Vg ['? MNcwW.Nf-/__u =u_^+ g'kSz&16agP$mMLODPM`lb g7$e>(o!7rs3;^0 g| l,=f O  dk -Fz+-,M,{/_.F#ؔ-li:ۿM&_z78ny)eYobY;%!,lce1sp9L>ha/YdF?t懭?Sl`kw_>u?ڲOe :ܑIQ>&БF^]JivsC)꣱> kT|<-N@R hE0MvFգIş%ӝ,P7/T$hFi q]HM@(uI/CGG{qirx\ɣrp4U*"3'1/zG$917™y*G|1O`GG\.=q;Lɻ;ēn\YN1LFb$]#bbaOcxwK%&Bo"侲UU(d? j\InQ9~5\Ys 4;>ꪅc`r *1I>T --KC]@e Re78X ^bfiW6h("?$VS̓-}DJ2$~TD:Nq#5" 󧈼QჶLȵc؉/WX2x-[F7sW{4B -pǀLVE`KV֞\ͪk:K?>1y9d5 @P2Ͱ]6(9`~ ̢ +9yƢ]J* gK]?eC(m -D\NԴ|ǦUf - )&"Q86ƅ9xV6jxl2^ -| ;c glt_jP Tm=- - ˍ /?&ío -%]óVɵ#hirX2K?Njt3VSӯSAǩ-;%eiHfaP$DC&AC ѾB&eQ/MNQgN8o?ˈR(iOz~ذʀ#!4uU KqV!rɜtn"/PH<8̝%!*bhOoCdQ>N{k=.8}"Ux~ʩjGSYc[kёpr)hx7󗊛]BTx0c}0pA17y,UK,ZSVKd=Ӈj;ס+JRPl3y4x_oHԷvS_ Ag_݄~w?@4Q("[Eqsi5׳ȗD|̟|Km@e) -$TArDUx,mCF˄vhVod%ͼcRk97AaloDK{[1_s LZ|L/:OMz}ÔKH~-_t 뭋W$AƘ3lr,y&0jmq[L6Qb~+P-s$* OӅJY[Sk[m}6LO[򽼃NOp:H7CĬ]y>Փa'Mq b_w ]4n +: 8cJR[2mXw}y7ˆLeD$,?Yh{BkiК1;eTn|)949uХx R ->]oM%G)4kbZ~`_[h8<4}$.Ă(u&ay2ԻT+JҙçJJ,v\TPi psFã!nT)^"R' q)J4`s]ZG ҏ(Bq(v&3UςB bZ Ir2Ÿվ ě7X)c5&O2nϝGӯ?74׳ ŭTj(Es &RѵL3puy67k‰}To"wlsE2'jQ,H]ct? ,Ga2^d0NUx$"e`%~7*挭{cl?hZFCH7U*܋ǂy|8.XAuf".-_Z M뙤‡÷[\DZQRx¼K))pDÍmH <_1kH/)(_|2,Bi4VCY5B2Eyy47hB\=mr94Ojwi_w vM[4꩗T\ӯrN1c-8!ΤұtzK,בZ5Cg J=|ʏ,u,YغBެ\SM Lۺp`i5U])UtPڟhlA6`q"~g226d`{#CnW!wILwdkJ)K"&V0fӡ?r83)J$4?$E첛: -(i- 7~SLck!.0Y:7 `hPojlGvj8ǫ6nN'3XH%zl T~}wlz(D:ooVe@Xrݪ# d4C:GnxҤXd^gk}{WF;h`7d HN7G5- 1d \(&%g Rq[.ʡ\G&1G!r؎HD!ee2 ![@81JRJE]w{D1_ ӿ\ýzDd$!ݖ#/$VrlAՄ:@RhVTWi&VQb$?^JjvQձ:FRK}GLA8)d䱔ZNuQw_ Lpė9Qk`Eih[5?M )'Q*4yΊC[I&rx/`x0osss弫诗% \҄-qB ^ n u^CE ĶAX@mҒJf)ˋMRVSi#w6VBQk1#9q?VAAו .5.Qw'z7#|X#cr"UtRϳd0{)ut6Avz»`~L%̷,"QW^CDDa. BvUav~%#D@ʞH e7t6O_pŸ)#lt.jLtʁv)n>Tn%K]^s'lٲk2]5#Įj@o^'|p?yI߻7 J\pAF#jY\a@DY>Sa? -) ND]*ԟ .ka:r\e&D%_$$3}98$ȢgיZuΐ8ר=~a#L]gyi+.6{jSksqD ~ͯ{ӷm'v;?A%q7"pM!(x[],u0~ݛotvmo/yS}"Im@aw9Z I÷,`ImJ /!UՆ[ni$%wjyڪ?8?4q5g7}EllRg{ 2. nL^JY(?f2ci<ɐ""@ !k 5+V=QA+͸;v% F+s*)Xs9NߙѥL[Yyt x:ts` [x(rvrӠvW+.my=̆Q54xaT`` ^3>5UaHc'x.lg~uF8 b .%۠P*L;.w_</o ov~88Vqf -`qoa:}˒I šH`Ru3}(-DwttW4#URwXPƯY4gFRߠvue&+W-\O+Ncȫd簟u^%oH]G,js'#~3JݒJENA_l 1Uc3 Gm+V|-`lf$ګ̞˚vy7tUZl,N@%NRsP[P?ߔIeo w@!&/8Ќl<%.ҙ{A@lAƍ? wR,SQ,HuQ>UAﻵ/&/օJV9@(t\ F;tHa|Z)b4Hbtܩ. -D2IÔnEYe):VU>иɚq:mɲUNYB&ü]R*Î=*nѽKvhf0;! .&fRڄ&ee}|x$ӽ;kg=yg+a.)`NiߜʼnWU*i/W 6> t6 p2/z=h>` -n5TєX"GE.4&؅'|PLar 0N1foU" *0$]s>Ά'⏾f6q썩)}mZ͐IN -@PD # V{%V|3ȔJE3)&N{_ m31o S/b~O8/*Zφ(.PdXu on{DGy}(l &S}f 7 ;!)P_cE_ϓTYjS({ d - ǥ0ұ`/I PhZhtDcxBkzU1-C^@\#f]O5 hCGc(hƼ<@e/]ygT BW:ŋ"p+EE|7p<*6~R{N f.]&MNsr'=d/UMzW8=nvDM=אArY8sf("vj;7/]\ٔ7azgg)R%H}!iRe<Ѡ7%ad:gteI* -oO'xd"뙂T3z ^~LIBcP/giй.^ԡ/jXQ -Ԧ4{ٷhgZ'F.$2B 07JF |mv"n0j8xBQ٫|jiulQ5%zŌv>GNv.Y= "k E),$i{;vS SWBPPj+{gL/ -,6:^X'9UfkM6t^(2gIyղR(.cBMSav/u!&jdR *!BSJ㐠!DˢFT=Bm+䒅0mI}ATZS =r!v} |8, - ~o8Lć4Dl':Y'ϵ:XȃKKr97 d2 -{Fu3o2C7jy-@,dL//K̰FYʄ9řV\GZL63:g:RB/vKH[mS%{ D4uBޅ,&~F?\WɡrgUqq6Mgy0#ϕ`&~[鰌n#u"%`rgey#HZ@#FXTl2XQ[ľN1D͸b{dE͞T߯Y4v̪ߔc>㦴ƽ;U>.Y'.NLM-͕߈x6w\uT*tX6{AFi D}pK?N2%-MK2{%,)Ph5WtK/%( V?uEw]Jb $d+_wZ+MV3FhG{>0 { [^ O0~`1Y -*ozPG30 ?)^)w8:B-sFD.amwBUz8s3&J|$9 -[BKdH*y" zX>WѤi$&NyuBIsoLIDǕlE)O̍:O-h/_c:u* (9}y}F)]>9]%8[p ڈ4eAo# ҹYI[up)D l})joa%h1lPEöd#!Yq4NaB#@3ܴ*Fև[>z2MDn wKY(iXd9L,^^Y%)4Z\tWi 7,qK-?E@#&+0ء045֖W/fLƉߋ0šuyu:{[ĸ2} cu' )Z``\cٱ{ODrm;Ll} J܄6 n>nxPc=6pÊ)L[+%}'Pa45lG>(E&-#kijE "mUSvL =A2_5JU_OVml= -7q3` t.cNwZKGԛ.(^՗w[.,Z -cGM}!;4Cn2'?@9'Ѯp]C-CD]QP-}yhzqc+ߙA;tocn-OWӕ۞:]#_fbȰg PچPŎO£dU 6dpbƩ\;&{",O_9V47M=a]:mGAP.43d&ɖ*HfńM:k(g -4ZjH sGV Y).jcP̍ntwRTBA4MgwsI2Cɳ/CRjD[879(ԠR?Jf;V32yګ2: ;QU8xtn -vKӿ½~?קSɞ6.KH?Rynv8ax9:&ov|癱Bu:XXv9nn*ݎ#*%)-u3?N ` -;ƊF*Cb&Znf]CN6., W91iK;m+bTSpGsuk&ALH^֙FV{$ kMbx6aY卛a5J0˚ -ӆ"Sz_S@ l솁D/Bc0b( -s.xP\ nJN*7A^fnc#|<a=L¹t}N9@2򓺬;Ԓ`瘓gۖ (kwHfz# TU5aQW.;tTK!b6ڱA2-|MU5j2~^]ie-^Weo~ʄCw= {}N)҄\*J|WMo- kȓZ6"ٙ\W7ϧG}Vcڪ4XoM7wPcՒl{lY B/T?+ŒsGv5?֧B<wsصD9 ߥK_ݻ`]} nhD\&*NNk0 Ժ9}Q}lD0j2wJvvz,}"ijy cOqpd:3չ$c_W#41祆 z,8D-h5C ͧ_%wҪu #ǔg!]7/B]ehIK2WTuʌk84ͥ0A;b1bmH;>nϢR /#NqH0gڅ>tVa/ |sYq,ƙ( ^ς~>ʧwHv;øM$e _ژXKZ)\u2vK XE7G":1V G&(19?3FRGcM-,k!u7;rV+r“l 4{k{#"KMaby l/W^o<9[T&8ew'}'rW M7#X1nf ~2*U %:DM|.c:)Iˏ*ο:r2:ҩiWL=wJ5d'XZ;U[+j"dgO5!nYm/`Z 9LcZp)ʛQ$7nX튌X,O'ؾe6\0`2L brQu -reA5n!]ػOWH:ԅuk2Q:ɝdf $E8fN@G}\=_W/nb0^8U>=O?gU̧[a;SXgL.v@/&i:dk0GurB7gOw KY&j 7r 2WNxhҿ7LVC@]*-ŠA;}viCU.Zl ?cHոu!W/\HvqbfOy3;Ф 'IܯE| p:C9c!VC7ò2]2⪳,}%(rɆfQ{3u7(;>D`'xN?1jaXDOOTYeS;&b感"=_L+e)P -g}qۨN/wNъ”⃞(i.JY{o&X -|TN!{ La` K=ETBSEATMb -Q~JlQRZB{g ^xmL1p%k\~}O8uqV*Gj9OVutCv.ޯU=rI3 ͢O7( S~Ȕ ۚt`l/Y37ۦ; &ymr-ɽ.oEB91!D4B\\. b.=qs,|?~8 -l " j`Zohb}0o*˯޵/~ 'K@Tk5{[˥ߺ1ʮaYF5PYa|3bM@Nyav.hnņRŗȬŒWyt7OkBC@odρIZ}\ŒgBTbM+5HzJfyq -Cޕ/aLdU,[gWСXV7~QȢ%+?צ!Uk5&ZQɁ [x-buP#E@qI$;V$#ktJ\p5r$|H{UK]N}ED -F- 6 ߸nV^]Mg\KǷ 9/7oмS'QBe|i[_ݑ6.'c䏽Mr\S>K䃔tC稶h5uRELUҐOzVNj;'SOX;WEeԠ#:0BU,b -2p^ن:0|&e,?HFkJU'!qYw߳Hԫ;3[@hurnL;=by7E>=Hzs|Ӑ߶`KA -_P-'HS -Л'y Rei[22Q%Zm-cLPeo=i:'r^ѭ{?z$&aM%*i ڋ%4#6 -!;hGj2|OD ?w`Ӣc򢆉ηa툗62Aw(s/A'vi.]7*4'O vF34gOu.trs}/ۺ#=drԏVLWVKS.(;h"}R>ls쳲!lAE:y&h22+ٮHѳ0AnL@y[q8^:Zchj-B _JT5j9ȫ>)ۻnSj=XrHl_r:0)]F: t,,pQsҜx.!Mdَ%󌥢>בth;N}O~x[[)`Ǚ[zХ;b ZۏW=mVD׮9, e,Kj} J,b32h=U,j% -׾ 92kG`K{|*)҈RACDӮ҉svѬ>cj -6mpHr\Ik[xi$H$S<]H;"] h!K  wكa!WotQ21e}DM&"1IpQ{AۻkJ46O*Y*A"ձ  reK$a^HFN)7i?: " -y5x ?8,%*%q$G]%\Lz*"7U0$ הq*櫸\~ghL[ rY{ky9_-ߣ|ҜZ.zb>1aN–K!5hI?K3< ,$j:=zm_N4Fq -胱T5ja"Э'7k]AuSepZ%¬=~P*+VddqɈEXdJH+:})#@ײ!R -;\e7Hxl [sH[XUNi Xثc47\A0<{ Evg]8xp[lZщ5rGm*N:Q+|g}\dO>hDGXn +b;tƌ6lĔ>40a= zb6x{I)K[7ـ jP8b*Gw4V2Όfu3^L9OOW3Pq*z5la:> ?3zL~Ԋ+qqjo 2^6Mck~HOgi$q5|/̾3.7,s[|E9 + -Qk|/9xP7l© 敱<6Ͷ= 3TI@T07I`5lco|](^6Cތ lڴa1Μ3ʖ#ƆyLhm+Ub'#G,Ga<,s9a|I@> nñ m?qJ.C{s oB(df|842(ph7Ӂd5DIl]B'IѥF܊!FL`0\ۘQu3!skA$TBɰ` % Aowٺ bCL?<: _i 8eT)D~H7ces6$|ŘË IPkfVB( -/KnEK(xww\3k!lQe8nh8tr|BUwQ)gϣW@P񄥾LZ7(fl9 bf rᷚP}p -*yB/1;A23SswoVv{Xc9'*:҈V)BSz)X_ӊpm{zu)c)+H2Qi'ڱ׉b@akEvBakR:F~Ȓ̍mg4v~\I -^<[7-%q5mʞtBdc;|W7xSy4v Q2Rwr\CVD -`5y@k"5)1R-DH »DdMo3w5Gv`L2uobr[v^^P]QS^?_ 'C2T5y [<;}hL4mMméҎ/}"B0%VE~b(e峕UiNi܄{X#=d[娽 OHV vGJMGLX^9ymiZPpB5#sW+*)OD_*y81sY/NI8w֦.v.r͞Ṉ;7{EVY|WN`WپshI(x^m+O':QGr[XFR;jI5A0 {Ab8ATQmO@ iVlӸCX;$aPgakq*{ngl2G Y.ߓSl-%-eppW8בfš=ΆKb/$',endstream +Fz+-,M,{/_.F#ؔ-li:ۿM&_z7U%9ܦR˺GvKCXEcs289|_;@oɌL*|%[#;D`/?f#Gǿ|-qw#e;#`_u#Z}L#!E5v~\!MK_RGc}&x>$T[4G j^72;`쌪G{?uK>!;Yn^I\ H|лP +/ȓN_)~ ށAG; +hTzEP/gOZc^0Hr>bo3lU\cޟ+)\Z9z' %v4wWw~'ݸH᭳ c.׍HFd; T3R[&~n<箌hř*6Q?+`yV{=4tUt~|b(r2k$damQr\MAEV6"rshE$~UQΤ'2~$Q "Hi0#>MCJ/߁1)FSQ+LEt-*Tql !sl5 u%d,Aw^h+ՠ`-7x-f{Z^PLN@[IJjgk G|be(dSfxVNj'1,8oДm6ꖒSAj8* 5y;p.p2Zw@J )=Ή虑Vմi[W2$jG;DWbp_!8kwji';EȮ<⽴#s +?wt@FIk R,z&ePͧw6Drw_B9%!iD^Všxp b?;KB&T…О 56PoA |R%'ہת{;\pD?3NSHr?Ƕ֢#8Rn/7 ~ `X +`dEbnXEo X2J.z@?w*D%?CW",>f1hXzio)즾ʥ0 %~$iQEXAjg)X/ ?qXۀzS%-I= .XXۆ (XͻJnyChSsnpy@~kݥ3T/!l@`5]&=g)H:v*7c /˻eGD2.&~:I=i踒;a w + 2z9ﳊW0S)"!C7OOw7"(.ŒS^,I#yb[EVsxPKػPUE:MjJKm,Z70xc_r;UF&&|3 yYCkmDFox +趍fYGVw>|,rӏz^[N|?emklCx[яv0zRXqg9s޲ٍF#w]NIQNumc_}ވ4cR-I<((j#3N_t)ߗ:Z࿊Ml>A[[˃&I01sg^9ٮX?yTk1okuҖXA]A !@wN1ie̮WP?SB7L> !Dvp% m!`e22_f0-ℎc79V|JM`*eڴ٣4lhWr[!kIUTJ Mѳ1#sS0lџfd{y׍t;(oY'zim}'oO6z],*/e4j;?_nhJgd[P,+ALgk"gdmRoքQ#H1ߔEh@?7Ze2LO\Y ɷ~YfK[eH`*,HIDRE2Y#Mlu`̦CpfRIi~H@*ie7_u>Q +[t1@n꧘׊C\`u.)k +t%o2Vk,[2K b7 \QpY]MK6+H8%]C:LcCڱ鱉|Cʐ5d^UZCҁpc SånIgbHA%e{^AO3_1HB)-G^I.ق =[o-tXѬxM<"MaH +T@s_0󺧺E?K3s6!oY^ڔ^~C HJ0jԄ۟+ %U@qK1pV.5i,kjnlr&٤ &Reba?]Ts/|QS̨eҶyL!KyED.A9*C jVz4V :.j0hݕ*>/fJ#|jJtú2O]')`2v"<q8/)\pKAwUBv\y<_p?FFpq"߭l;&$ʵ !2$u:%BCb:A |!D^dg6%W1QZ=!@-xt6fYx0Aێ(i6ҐBb;B;*7mz_p>U)!4NJ2W@\1ܺظltOGNfl}ˈv7#̅X +t kjgdmr8$eD^iOq$ |ggt<R+;A-{ +AzSo p8|ZwVyA kFd B-XtK_1$vM)]!816y$sP]<6lqM\]S4X?*^ Ia+:t?:^U.N@`Sʎp_k4hx kD49Pgm>ߐuLA @k@X +v96X6뢴_}Bwk_Fe[37M^ sP79@v9Z[S\ilqS]e?DE),Ћ8Reu@4}q57t +ڒemcwG$V[c$&KDfi*|lA",e^! {&|bj5ף)%D]h,M,jyA O|abymE7T`I(P} )O}+8lSSBڴ5!N@F~K.f)&fRL$Af2c@-A&1*_Vpq^T2e! Q\O=;ɨH}xOsS/4al_`: B T`}Gs1o,&Ck-~laӈ +Is3౉'7KwJ/&e8A8>>]"lqĮ`\͠f#Aq1E8ڰmߡ63U„oĻ [QC1;]3=?}x6yӫ~1Rv6bY| U 2?>4"P4QU`bI QV~Bꤶ4|=.Q AM˧̈ SwoV魽*>wBRR Ɗ 9$'%^7ngBƠ^Ҡs]%C_RZ[Mio δxOTN]dId=`n>#&\oiE`Tq^)7;W:0[:&6CkKǝJ }ށ+2\{A5EL~R*63YH4v즧8 9~ +W>X558_sYlt0Ns~9֚lx?1ѽQeB6e1Q\džl¦P_sCL"JTCh#!ACEz,=V6% aE[{֓|A {5CN@p+X:y$'L=ph.v4 lٔOhuNku,s+rn +eB 8og< %'dnN7p[Y6^^D aܕ gs3ԭST赮|[ۂK]g:)r| taX'`ǕbT,@-(g`DBS:~S$G ptZ؍6cs]^9– l$p4gLJIB)r~%/ +z<(4'h}3@T%Ǐ+ЋR/Cu0mZ^ƄuT AQsR|r|Y5K [qjA?iʂȳ߀GsɳxR*S<͉BR4 +4,xuޘ-@7Jb*Z (mB7FCch„DGgiUˍ<-;|x'e +"DPF%HsA_ +X4'=ZJRji諯^[DoX$& +)[~ +*GxMV.apCqaht9k-7&ʩ_l͘ѿ7Kafyu34|Cb!`/t_\$qe$AleO@RL- +A9X/c `Av6q m"?}`OtzmS Wv) KTN~(`#%hj +Pَz}PLZFoՊD>=۪14 O{Td>m4jln`!2zofL\9=+ڻ4tM7]P%2̫/\X*ƎBvh48]eN!\~@_rO]Ẇ[x[ +МS-]W633v44$I?6Z>+u==uGĐa" GUɪ@&mȚ SL;S[wFMD=X8,vsxi oz*/2štڜߏ7\h(Ug/M*-Ů ytPh6,o쑵Րnow;ѭ6R\Ơ K%wݼx=/h dz}=\#́g_2>yk{oN& p\;Hg '{p*8Ɏɥ>h0*@lj8gqp[nufCS;$D_qKZ> BcnN=^]hU5 $eJ +OӷF$p"#ཽUOUbd= ~|jYQ>Ô],癇Ua7QFZ +D0e~jָͪcO,"ݎ@μӮ!Q=591'϶-w4&Q&WFWj¢\vO邩BmPcd\ [Fjd"ZnQ<޲ = ](ze59S {UbCcZ֐'ѵbmD3&nO.NUiޚ:o7V%:ز(2S_4} ,[1Ba5+4W}%9Z ?jl OӅy$檍k?&MIs>Kǿw7%=Vk݆ш LT$ +Ia8 w3K6u1sZ9Ua>9d'_kC9ӇjX;YE$ىg6oA$cy*̟.ptfYsI~FitcXK XpZA*%ktOJU~A(GH))B"n|_ReL +>ph̛Ka39w*c,`ۚ"(v}E^Ftaδ }aOl@1_?JγQf'Y3Q\)~96D[},O;V?v"qiŝ;H2ii1 ,jʁS-e 8A ˋo4$)BEtbF׭za)M,Qc>7sfg0ˏƚZX"׬C0+^c9ow +{W'VE)f1i:FE-0n$Fb8qeUBNJ6)u-]WUt4\;SU=guetSӮzD+[j@NvߣWFEΞjBܲ+ۤ^:MA s$RR7HnݰX&1GO} l`0eř..8t/ʂjB# +ٻQuw)u />dt ;;X5EjIqb=2ŝ+8s(zaQQy^.Ŷq7(^3`pH}|{~`6}OwL)ϴios]^.M)tȞ`F# +P':s4ZtrBLeoeeed;Ug{Y JP $ (% ͢Uf,$nQv } +a N(`b汈pvL ?EzV"R&GQ6*K+ݓ_( Z y?Q 4/ҝZ/)=/(P1\ +׿'=LƱʩXBlA* W3@z&N9آmN=R +^2}QcJ4!ҹHzqn㞹vȔpsџy ڵ`J/mk3Nn}%6\^3_e;)Az( nfEsnP2Ƒ)V5(5]z^Lgn6-:M5A=v7x,"\C" +)ix%J`XPfCBANyB%\"W;XGt :RP0]x }L,L[ʓ{]No9E>y=rb Bh]z> \}{2'Xxip:Fww#f[=m#@E*զ +*jʟa.?ߜU_k?k^N_jxv/ZVj;UWco-1jn:1: W Dw&  ][ᐩf\ +$=L^JY~% C_trTT# 5E7yp \-x8K]s 5{2gIk55SA YIRZ$+ө՘-e"AYJпf+ lnsEC|osȘ;e.D".ԧ 6X{-^~~1ZGqYJ+ާv;G5~)(N~9 Ugv*'~WbxθX":~iT`z@Cka5x2,a0Y)3 p/O+V]:apھLwܤ`3ZNRu{XUi'~){_2ڛģqʗKucz1]ò?Vj6ÒfCR\Zܯ ]eC/Y1>M%nքX95[> +G/| Iw\IF lj<!# t#EI>(BX ?9`7ZllRA5( q ݬȽ +A4y}oArn_8F7ox}3|y[O<)\Y)h 3`5<)q# m]Np{z˫带|)NQmjꤊN[!?1@wXIO§ 3$'5\7M3wj˨AG&t`q#8TY e u$`LLY~֔ ̫NC⌳jg/mdv Q '/^NҲ]koT$iJOD`!fhNC).D~?X!]x']-^p!4)u1Gz/ZU33\&AQw4D$|*ٞ^geClقtL&9v eReV]g?Qah4`&pt@[LL-Qu;N5 jrW |S$Dw!ݦ>zf%ؾ.u^aRt.(YYFd+9\CTc /vA5ȲKKE}Z#v25@S3.Kwkqo:czڬ]sXV>g9X,3 @xY\g?*eyA[zXKӯ}sd^jT)Sե҃܇ԉh]1 Yk}l2Fֶ4ҮIx5HxZvD +B*8)CNԣ"ebpM=8&/UDM֋Eϛc/w?֔gi`mݟVU&U>fDcWH˖SI¼687ޝS&*ojw ~LuH]OE/Lxk"p-* YK4yUJ&$HKq_cITZE>n66)`zU(jt}~gܩD|[-?W(d ݙId6mnH0 +g⩒an0jx,HǟQBKkumC5|/4ijc39gB.r/ϑ3-G #GVrcO1GYxYH s,xFCن݋񬑋',[`׭DH[!5 ̞wJiqBi,yTA;O)u1 T=VܧQl/֛ɩqVzP &U\3׊I->fVdy|<797 PVd|NKj}X "?ݼcbyy5!0]‡pޠ -*QZsqh43dKQ<,=3njى5j͓غOKPIC4' `1}rfBւH'!a?,X)-KrEy?!w[}uaĆ~yt1!p2RP:z ;nʠ3lj3I&1#͓Q4_ЋQ/#LfJרC6:7>p>$q^*&SϞGtK3* K}+nQsXAno56"5U6ۿ'^cveg6c?"ކ&ۿ:y_s^%,sN2Tt6SS2/Nxq/cbSrSWdnOc-ŀ֔~D풇֤u6 PՑ%\h848Rqmy!nZKhkŗ=m&vo,ʑihMVi1 esQZk1vӁ8DD3kRcn[wyȚ fvkeK?_.6.P~P   Td %ye@*]'[[JZz_o.9fqR#͊C){ _HO$><'2X̙endstream endobj 985 0 obj << /Type /Font @@ -10894,14 +10896,14 @@ endobj /FirstChar 34 /LastChar 125 /Widths 2276 0 R -/BaseFont /OZWMVG+NimbusMonL-Bold +/BaseFont /EVSCCN+NimbusMonL-Bold /FontDescriptor 983 0 R >> endobj 983 0 obj << /Ascent 624 /CapHeight 552 /Descent -126 -/FontName /OZWMVG+NimbusMonL-Bold +/FontName /EVSCCN+NimbusMonL-Bold /ItalicAngle 0 /StemV 101 /XHeight 439 @@ -10922,7 +10924,7 @@ endobj >> stream xڬct&۶mWTc۶mb۶]*[sqn/}{ߚx33c) 813rͭ:;)Mlpdd"@C's[QC' 7@h L\\\pd[;wsS3' Y t6.@+[;k_D d[" -RJ y5`hPtien578&F6HK`pMq掎SC3pY9C_lFXSutr4r0s(*oNfNv4ؚ45r:8nN ;Y_4mL-hj`ltt W{C;;+e+q0wrZ11i ?"ecb `b\?;C;h o$Ne>$oEF%{ZJ}al+CW!?5&#dwB6agQ hhdd01;lV6k:&F𩚙Y3z6IHΠ,$*'Io꿢jnhEuxt,9_g9C's7ߖI?`ll'C yעn@#߶F$oEF%{ZJ}al+CW!?5&#dwB6agQ hhdd01;lV6k:&F𩚙Y3z6IH &(Ao꿢jnhEuxt,9_g9C's7ߖI?`ll'C yעn@#߶FF{1(zR$T}4 z%gQWZJzPߧ;X`H\ I|Rc1:QA'?=R @’@ G hUxSA7!ݴ_}jt{呑FX˾*ٴ˾'A &9HWJZw&smŸ 쿝$ Ʉ'~w 󬵮~C]Q,wm'c wDis$Y1f&>.j蝳95uV?m=8ib/4ll֒$):Srt#/syd _vX"4]Ԇf-FÕFGs!kt> @@ -11003,7 +11005,7 @@ i ^h hZ/_7+P&&$+Nȶp ~I(cڟYg%p%>HiL\(_8CR{ r0{Q2Za*7cJI]1=SMXGMP:*OT9D*z*ڞ_hg 9j"J7ޮ(hT(ʙċVq -o] }9B7 H{i`T&Vs"VMoi׈{C^;_g`,2 n R ɫǶ]juibV!Q>aO$y"--ŵ q ֈ"[ mcA"t8Q+PKєh_ $+S$ؙezv~7EhZނӪHݝmݑ("wnꛝՔ^y$33i=+iWum<Ⱥ][QgShSݻSXw@`z>ېB"Ʈ.(AN|w3n1eq޸XL%1;M*^OUyoRѩ lպRyQ̷XY2P+$o7SDEGGv.գPH^ ujzZ+3ƴNc"endstream +o] }9B7 H{i`T&Vs"VMoi׈{C^;_g`,2 n R ɫǶ]juibV!Q>aO$y"--ŵ q ֈ"[ mcA"t8Q+PKєh_ $+S$ؙezv~7EhZނӪHݝmݑ("wnꛝՔ^y$33i=+iWum<Ⱥ][QgShSݻSXw@`z>ېB"Ʈ.(AN|w3n1eq޸XL%1;M*^OUyoRѩ lպRyQ̷XY2P+$o7SDEGGv.գPH^ ujzZ+3ƴNcLendstream endobj 969 0 obj << /Type /Font @@ -11012,14 +11014,14 @@ endobj /FirstChar 33 /LastChar 125 /Widths 2277 0 R -/BaseFont /RAJTMH+NimbusMonL-Regu +/BaseFont /DUMRPG+NimbusMonL-Regu /FontDescriptor 967 0 R >> endobj 967 0 obj << /Ascent 625 /CapHeight 557 /Descent -147 -/FontName /RAJTMH+NimbusMonL-Regu +/FontName /DUMRPG+NimbusMonL-Regu /ItalicAngle 0 /StemV 41 /XHeight 426 @@ -11039,7 +11041,7 @@ endobj /Filter /FlateDecode >> stream -xڬct].v*Icul'[bb۶m۶cw>cjk^s^Z5FQ)0%lA ,<5e ECkkC ;Y)5௙Rh3y@ jghafP堡/?.#@F:Y}pZmA)U@0D%ԒjI-oFY c`j`lgkbOkN'{01`tpr p9ڂd5v6vSdh/L dhaͪ(&:A憠r;Yv=M쌝i__( eX8[_e8;YؚWG5/__} m/6eD`71on3 [vg\?{o&v)oJʌs"H?"owCz; _Ac. =5Rhlm ۚUV ' 7`jhwVٚ-l58 , S50g&2x&q)9-^_A@DC?ع<X8 ߃/"Z-̌,53gǨ mMn4;;:_ov݀+vƼAi:ܑ)1>ȑ`Fբ^ߴ]J`ƦҴGc}8T)|"o +xڬct].v*Icul'[bb۶m۶cw>cjk^s^Z5FQ)0%lA ,<5e ECkkC ;Y)5௙Rh3y@ jghafP堡/?.#@F:Y}pZmA)U@0D%ԒjI-oFY c`j`lgkbOkN'{01`tpr p9ڂd5v6vSdh/L dhaͪ(&:A憠r;Yv=M쌝i__( eX8[_e8;YؚWG5/__} m/6eD`71on3 [vg\?{o&v)oJʌs"H?"owCz; _Ac. =5Rhlm ۚUV ' 7`jhwVٚ-l58 , S50g&2x&%E1aE^_A@DC?ع<X8 ߃/"Z-̌,53gǨ mMn4;;:_ov݀+vƼAi:ܑ)1>ȑ`Fբ^ߴ]J`ƦҴGc}8T)|"o tGLzQ7K;P?8ՏJ>`g:Yni(\ <٣6bw5a_|M<}~?$ˉuBC(CBi{Ju glC(bZjfpC@VBj+s^"pjmHNZ;o{O}qM g@ @@ -11113,7 +11115,7 @@ K pӺXk)iKqkٲ{԰!1s3 B Џ2t%]Au"2. xs,)k>hbyZ-$b;* #6^*jj}5ʭtg =)G;RVwV*M\hn`Pٺz'I~V;&븙iw c3:Sa40Z: Mo~#YcVIF^v&Bozҽ<@ !VoC鷳s~A)4jsYɉ cxg4Hc=|(3qr1~tәsV;ˁ}I=*!8 {JhJ$2tKcZ=P)w,cm#dxu!^ 9i7JcԌ]+ jƻ_[hIY0*껪ݳj`?8sGx9g3èt:n:SluHxPoJAh߾W'B qJ`ka殴bg>MOB8uk7)ܿ5GVQ(Pm-FG*TAWK2z) ?3̏QOl sx5W˖zG?yD86<,yʜ%ɾajr L.!e&Ay!q`ۮ8 &CᰈPKMZQR!Vx3'l{x|#,9r&t| a3saw uݙv&R;Ƴo5$r%iav4 E;E6'h;7\oqk*u+NcO -%jendstream +%j+endstream endobj 927 0 obj << /Type /Font @@ -11122,14 +11124,14 @@ endobj /FirstChar 2 /LastChar 151 /Widths 2278 0 R -/BaseFont /OEBIMY+URWPalladioL-Ital +/BaseFont /QOPDAP+URWPalladioL-Ital /FontDescriptor 925 0 R >> endobj 925 0 obj << /Ascent 722 /CapHeight 693 /Descent -261 -/FontName /OEBIMY+URWPalladioL-Ital +/FontName /QOPDAP+URWPalladioL-Ital /ItalicAngle -9.5 /StemV 78 /XHeight 482 @@ -11152,7 +11154,7 @@ stream xڬcx]-vfǶm$+6:ضm;cul}\_ۿ=kTYZj"@I{WFV&^9AQ̉@I) 4q9؋yZ@s8 `+%@di AKO_\^tY>m)Հ@`Ĕud4R)=fj 2ȃ̀.@Z3 9蟭0q\fa@O3?lrq ,M]7u3v /L UY\uZ8X4w0sgKE]M@.W?LsA*do_0&@4_@.@[ &V9\#03*2Vs:A4 "Lm@ fE׿)4o*3ω? #kSK*; 璱?M@^7wWW+W&@. O2 -`abWk؛mAFV[li>!LY\WDALWlΗ+#N#i)8>QQO7#+dc|`L\A=&ֿ? F#ao`쨹؛49;U_7_zV9[ge O B868o4~ ajhZ:q|ߗ;ñM^?d6,E8Պ\߂b<ؙTQ5,y!dw| w/ xpD3KkBkèqrJt@=462>7 +`abWk؛mAFV[li>!LYVEFQRWlΗ+#N#i)8>QQO7#+dc|`L\A=&ֿ? F#ao`쨹؛49;U_7_zV9[ge O B868o4~ ajhZ:q|ߗ;ñM^?d6,E8Պ\߂b<ؙTQ5,y!dw| w/ xpD3KkBkèqrJt@=462>7 **)PHWBUmWOr]Vɕ $qy"zf<0f}/>bF,VUdՃJlNo+OX1-c-N1ipݛ\A?{G.'޽$5^oDҒj8R/y࣑<`^ `uvd,RH$kK>&Y ۔O&okƜmW /[B`tNGfĈHmVDϓY_k+1pҨjDj @@ -11214,7 +11216,7 @@ MI n$r XDt Ӆ2nsmOƄ;shuU9֏&;y-sP~K*z4rnp})RB+>cIw hz\mmMH<|&ws+\?V˴<=yHM'67Co+A5x5x'_ c!v~4bIpP]H^nkLYل,)tCr iϱm$hn.OW[{OFCh'W*6L1g^H]ua3g@TL_1@d7:XF.fb1\S٣֮TISҎ{9.vP_$ Ù.TjR.ziX^;-kw0HMKySc-tkk'a.*b ۶4d&*qɟX"c4 *+93 cELg%K=g~Q)ue7@`cs2e/5I*[rHD4;"hntRɴc݄u { }hx;lqf d79R2)iG&ިCeV]~T}Yd`X~T={cW 6͆Ij˂{Al s 蹔L q=*YKT&92sʛ=Ix=7v[Chw(l*q bfY YR |)U-*[rᇻw8me-PsQWNv{e=Ee>*xQu_R I?dYa/KzcgZ6q3p0, HIM,*M,i@fendstream +41{QlPg;($@QQ~:4 /e't>~T={cW 6͆Ij˂{Al s 蹔L q=*YKT&92sʛ=Ix=7v[Chw(l*q bfY YR |)U-*[rᇻw8me-PsQWNv{e=Ee>*xQu_R I?dYa/KzcgZ6q3p0, HIM,*M,fendstream endobj 827 0 obj << /Type /Font @@ -11223,14 +11225,14 @@ endobj /FirstChar 40 /LastChar 90 /Widths 2279 0 R -/BaseFont /DZAMCL+URWPalladioL-Roma-Slant_167 +/BaseFont /JQINFY+URWPalladioL-Roma-Slant_167 /FontDescriptor 825 0 R >> endobj 825 0 obj << /Ascent 715 /CapHeight 680 /Descent -282 -/FontName /DZAMCL+URWPalladioL-Roma-Slant_167 +/FontName /JQINFY+URWPalladioL-Roma-Slant_167 /ItalicAngle -9 /StemV 84 /XHeight 469 @@ -11246,23 +11248,21 @@ endobj /Length1 862 /Length2 1251 /Length3 532 -/Length 1860 +/Length 1861 /Filter /FlateDecode >> stream -xUkTgnJ+ŀ -2@ ,;"(R $$@,PAEJi F4 -& X -Kڳ3}{g;33!8` n>A2833gD\D4'qRBQpf3.E!`ɢp( 7HāX&|&Ix/ްF#apW#-:b` oHb 'fxRq$w Ɯ7Ll"!bC|.OF" -VJesn0+d"e: Bx0@mdk2p%0˓+br6K8,`ŷdgfK'KaNTj,%+D2Ą+pf +(T[BQHNVQh -X%cQ%M FPXAkL\h]&)D` -1a3l^;!e0!rG#h b?5߄L1[`X3q!)4:"sRݫ_ePzJGWa -ϙ'u_N^VTOm"ॉi5G -VҚЇgٶwz[\Y~\`FKzk /xܹu6.Nĭ{ O%\vfّ -׈S]>k~GzSqiٳVrLZa75wR2g5ӯ ܖ']W26=f.(kU>׉5Z%Fe~[=ڇ<dsVtJffp%-:!8uty+Nc)":>q]=*Q8aƜ(#s`KӐ.E|\{/ 7QFm5 xk̝pj}lU*Z@NK٨nB-kw˭Q!Z`^O CM _^͆D$'=p`l$6/4L}0kv|*tW<>gQGT#k#FkW9ٕj:.I9ڸp|W#Ɖ鮧5ZcY6hAqOLFS67?|po?!T!4 /Vendstream +xUkTgnJ+ՠ +2@ , +$ Ʉ $$\(XѠB"Pi^E +r(`+ǮkyyΆ@b +0 I d>;A*;;O * aStƠQt7FbHH8x~6#rC"XCb #< 0bf e0 _ሔ@qĖ +Qm(R10&Mܢc,$P|Q|/w0~s/X IfϦ' 7 +T +`L43 }-)  t!Ss"B"@e,K[5B:,Ʌ|{l Pߩgk]!J JRA\oxm +i8@AD*SRT/h!f +:>0fjv0"H .T#_=cWdj̢̅Czr{165S[x%{x5k;$5YNM.u?hҭqˉݏwm==o6(ʴ +7AgaLPLF19&zk[k:Jv:ko΢+|US{9ю_zeˡȂ#֛EibVy[OK/M.-7~QhbIQ\P]\Znm)},lw_jYQVc_Q4[UW/JJ&2UﴂCYs#eG¯j{cRU*uqP2RNd|%nKqx OW 5/zFeC\ 'Z4:+VQaz(ntؾH}E{Ɠ}V.=qj=ˬmCni1 *Y s][ӬsU=LSR$*tv[pd?+cRSnc#+?'Qf X寳,|7`輩=}zS}a~-^E knҵ{V^T\anv?$) :?wxTU_^;#j>eLa§^C#!D 3(ujsZҪ,U1:Vby{ӳL5ȢU/Plm ,mNM޸h(Hn^IpϷ6?o+bSYE1yӿn,eOŬZW10mo;K*֚bCAGڲnh ?yQhnd"\_8jR8XbVN,n?'k[Y5\ {[߾ Tϋ7\a~Wـf`Ś +&0qӪ]<+(˒T&o`-8U?E|L0گuh4̯͖hǟ=t6ZkkӚm;٬8]tpcp,F]ji剂K.XNE{BQJT0H3~uC@X$_Ϲoendstream endobj 765 0 obj << /Type /Font @@ -11271,14 +11271,14 @@ endobj /FirstChar 13 /LastChar 110 /Widths 2281 0 R -/BaseFont /URCRWW+CMSY10 +/BaseFont /LVKOPN+CMSY10 /FontDescriptor 763 0 R >> endobj 763 0 obj << /Ascent 750 /CapHeight 683 /Descent -194 -/FontName /URCRWW+CMSY10 +/FontName /LVKOPN+CMSY10 /ItalicAngle -14.035 /StemV 85 /XHeight 431 @@ -11302,7 +11302,7 @@ endobj /Filter /FlateDecode >> stream -xڬc]%\],۶mvuٶm۶mU]Ν;o~ZωcGsb'3Ih MDlhh9*jv4v6f(!' ;[a'N1@`"ٻ;X;bPPQQzt0}p11u Qdn06kHȊdUb&&ygCk # ` ?9pM,n3q32E 7qpt p9:큓vwaL 7t27p'_7o?% d`ap2qs' o`pv5/3ckGǿ0 _7vwݿQ)-ߜFNsYBsT$lM a7vOÿ "P%a`lgk061s@2;HD'k\C:[[ؘ 3 go6f$0N[!`kWzZ0Z8Z[8L __=m%-li<Ll;˜NUSLXTI/Q\"(ha`e03r f&Ck-c`[6=ÿt?EFu-?u7#vF\AiNu#SZ} #E~5via8*?jif8ݗ?$)ЬzSLq( H;٨tKaբqg: )\ +xڬc]%\],۶mvuٶm۶mU]Ν;o~ZωcGsb'3Ih MDlhh9*jv4v6f(!' ;[a'N1@`"ٻ;X;bPPQQzt0}p11u Qdn06kHȊdUb&&ygCk # ` ?9pM,n3q32E 7qpt p9:큓vwaL 7t27p'_7o?% d`ap2qs' o`pv5/3ckGǿ0 _7vwݿQ)-ߜFNsYBsT$lM a7vOÿ "P%a`lgk061s@2;HD'k\C:[[ؘ 3 go6f$0N[!`kWzZ0Z8Z[8L __=m%-li<Ll;˜NJYTCTI/Q\"(ha`e03r f&Ck-c`[6=ÿt?EFu-?u7#vF\AiNu#SZ} #E~5via8*?jif8ݗ?$)ЬzSLq( H;٨tKaբqg: )\ P|RbQ IOȆGG{orbp’FTjUmb3]s l~^Hbاٮ岞NH C h1R^iC{AֈqwxyWcy'OT񴚟wusPMTUN(5 Mc,]EI[Y ˆ0^ Mm} 3@ 0Gƺ>KyETh6Jw_[c B8xվVkԂIgk+(}Ő+dP9,UD&w("ZUD|y)Ղ0)` 6l¬N&W W[.N5ZS @@ -11396,7 +11396,7 @@ A u|8t^/Mp_<{*>Jn 6sRaƋrׁ]9:(`\lA7ĦK9z8nb64jE$1V|ZBX#YͪföWqYlf/8Fj_X1n (N1C9(AEޖɀf}_J:J$<BSUMYr`Q?ٱVݎhكXԇ7Ӷ,!FE^F xB*vR&N<`+N gʾ2f~mm}ixuƜx\t{C  ȷ'5' zqvipdkj@:w?bVs,%IPSÅAD`,{rfYAEϡ+LN^,YB9dbTC4JLWl0k ^T򫾦t^/3S蚇dQv(C쇵%#j075pEZ,O(CZb4PΓ{5k`JpfAvs,p̈.goP9:,'c|1ehM~fQd9LN0"/|8׃ҿ]/ z$[<~q#2 'P4Iץ?`bFH. R}#] iA7F5q6O /WbFq- ]xk%Ötdμr?qEGlq_O1L$Hlӂ|ś:v ؛<2g87%j L/ARWm )C&(q14ED;jdW q8't{r`z$~ЗV-r#Qcɹ=HECIՌaYuz8UGݡHJP+dGR]IؘNd'DN'[qIĵF,;ŗd7W_FktΘ ~ yTjnUN6\e>:3t{^p*k!13/t|eWQ#`Ib$PXSKU` AŞm%NY ʡK_`sYG,4HC'89c[ 2?N #0g,. j?xG# +.ă-c-YoUV15һc@@A LUɅԿZςSUn9mbf[T8D14#hqךE9{ЬubM'?/Gε%G3 ?hayӀ^`׏z\vP{ѕIh~`50fM -&oH[A9f˕+J'1yC \<yʇfiX. oA#3ї;_;rwĽzi+Yxhz5xu5)spy}M~ ؚ9v3r߳;endstream +&oH[A9f˕+J'1yC \<yʇfiX. oA#3ї;_;rwĽzi+Yxhz5xu5)spy}M~ ؚ9v3r=Pendstream endobj 762 0 obj << /Type /Font @@ -11405,14 +11405,14 @@ endobj /FirstChar 2 /LastChar 216 /Widths 2282 0 R -/BaseFont /VZGDFG+URWPalladioL-Roma +/BaseFont /KTFYFY+URWPalladioL-Roma /FontDescriptor 760 0 R >> endobj 760 0 obj << /Ascent 715 /CapHeight 680 /Descent -282 -/FontName /VZGDFG+URWPalladioL-Roma +/FontName /KTFYFY+URWPalladioL-Roma /ItalicAngle 0 /StemV 84 /XHeight 469 @@ -11432,7 +11432,7 @@ endobj /Filter /FlateDecode >> stream -xڬzSm]eٶ]uʶm۶m)۶m):nS}Xkf92G{G,RBy%c;CQ;[gZzNE5ykkc ;iA;kc3 ) '1##)3Y !0N' 3[Wk;{[J&&&&Brbb*b&&.FF&N&v 054',''{#m&F& Mm,~ , lzlG`akdbݿ;D~휜- ~ Ogsr;Y L"\)_? M- <~r;Z1&p413p46qr;U'Vǿv+?9X8;XB104rmfa EϨHؚ0?|&j?3CCڃN'%ʴs"H?"wC{;ɿ6C M%XX{{ɿqH84BG zZ3Z8Z[8Xt_v[cGk [5HzS60,25q:95) QAFW?;\"(hNEH@Ds~p0_2 2ΎZ?ek`Dl%g[O?n#GUuj}Έ+2wszȔ@H}irQ]_zGGmm W#I>4_&8>dlTǁtj^7Kһ S +xڬzSm]eٶ]uʶm۶m)۶m):nS}Xkf92G{G,RBy%c;CQ;[gZzNE5ykkc ;iA;kc3 ) '1##)3Y !0N' 3[Wk;{[J&&&&Brbb*b&&.FF&N&v 054',''{#m&F& Mm,~ , lzlG`akdbݿ;D~휜- ~ Ogsr;Y L"\)_? M- <~r;Z1&p413p46qr;U'Vǿv+?9X8;XB104rmfa EϨHؚ0?|&j?3CCڃN'%ʴs"H?"wC{;ɿ6C M%XX{{ɿqH84BG zZ3Z8Z[8Xt_v[cGk [5HzS60,25q:q% EFW?;\"(hNEH@Ds~p0_2 2ΎZ?ek`Dl%g[O?n#GUuj}Έ+2wszȔ@H}irQ]_zGGmm W#I>4_&8>dlTǁtj^7Kһ S %`3L7)] QH|P \%}54>:2{MI KͧR!RDzݞe}"\ʤ!g?5 kT $f}Q}}7aIzQ`{1ʛ9sr5<#=364+Ǿap:"|:[5P6#\2߻O 6.'p$i2;LۖO Fy)~ C뭄a ѫGhg [&<1X{i_bf)T GAe!gFUa!*Z0/ a0~wo fJxw aL0 ^ `8 4 ϩ4V"]B3p෽_)I\H$sX{b^Z,6 R2CNJt(O79`e @y%0jAR~x4w5ֱm}=tRX[>͔ҞR "Hl/_r> endobj 736 0 obj << /Ascent 708 /CapHeight 672 /Descent -266 -/FontName /OWKYFB+URWPalladioL-Bold +/FontName /HSYMAR+URWPalladioL-Bold /ItalicAngle 0 /StemV 123 /XHeight 471 @@ -11581,13 +11581,13 @@ endobj /Type /Pages /Count 6 /Parent 2284 0 R -/Kids [1091 0 R 1114 0 R 1124 0 R 1129 0 R 1133 0 R 1138 0 R] +/Kids [1091 0 R 1114 0 R 1123 0 R 1129 0 R 1133 0 R 1138 0 R] >> endobj 1155 0 obj << /Type /Pages /Count 6 /Parent 2284 0 R -/Kids [1148 0 R 1157 0 R 1164 0 R 1170 0 R 1174 0 R 1186 0 R] +/Kids [1147 0 R 1157 0 R 1164 0 R 1170 0 R 1174 0 R 1186 0 R] >> endobj 1196 0 obj << /Type /Pages @@ -13061,7 +13061,7 @@ endobj /Count -4 >> endobj 2291 0 obj << -/Names [(Access_Control_Lists) 1709 0 R (Bv9ARM.ch01) 977 0 R (Bv9ARM.ch02) 1023 0 R (Bv9ARM.ch03) 1040 0 R (Bv9ARM.ch04) 1094 0 R (Bv9ARM.ch05) 1193 0 R (Bv9ARM.ch06) 1205 0 R (Bv9ARM.ch07) 1708 0 R (Bv9ARM.ch08) 1734 0 R (Bv9ARM.ch09) 1749 0 R (Bv9ARM.ch10) 1970 0 R (Configuration_File_Grammar) 1229 0 R (DNSSEC) 1161 0 R (Doc-Start) 735 0 R (Setting_TTLs) 1634 0 R (acache) 1030 0 R (access_control) 1375 0 R (acl) 1237 0 R (address_match_lists) 1210 0 R (admin_tools) 1063 0 R (appendix.A) 626 0 R (appendix.B) 662 0 R (bibliography) 1757 0 R (boolean_options) 1111 0 R (builtin) 1455 0 R (chapter*.1) 770 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 582 0 R (chapter.8) 606 0 R (cite.RFC1033) 1885 0 R (cite.RFC1034) 1769 0 R (cite.RFC1035) 1771 0 R (cite.RFC1101) 1867 0 R (cite.RFC1123) 1869 0 R (cite.RFC1183) 1829 0 R (cite.RFC1464) 1907 0 R (cite.RFC1535) 1814 0 R (cite.RFC1536) 1816 0 R (cite.RFC1537) 1887 0 R (cite.RFC1591) 1871 0 R (cite.RFC1706) 1831 0 R (cite.RFC1712) 1927 0 R (cite.RFC1713) 1909 0 R (cite.RFC1794) 1911 0 R (cite.RFC1876) 1833 0 R (cite.RFC1912) 1889 0 R (cite.RFC1982) 1818 0 R (cite.RFC1995) 1776 0 R (cite.RFC1996) 1778 0 R (cite.RFC2010) 1891 0 R (cite.RFC2052) 1835 0 R (cite.RFC2065) 1939 0 R (cite.RFC2136) 1780 0 R (cite.RFC2137) 1941 0 R (cite.RFC2163) 1837 0 R (cite.RFC2168) 1839 0 R (cite.RFC2181) 1782 0 R (cite.RFC2219) 1893 0 R (cite.RFC2230) 1841 0 R (cite.RFC2240) 1913 0 R (cite.RFC2308) 1784 0 R (cite.RFC2317) 1873 0 R (cite.RFC2345) 1915 0 R (cite.RFC2352) 1917 0 R (cite.RFC2535) 1943 0 R (cite.RFC2536) 1843 0 R (cite.RFC2537) 1845 0 R (cite.RFC2538) 1847 0 R (cite.RFC2539) 1849 0 R (cite.RFC2540) 1851 0 R (cite.RFC2671) 1786 0 R (cite.RFC2672) 1788 0 R (cite.RFC2673) 1929 0 R (cite.RFC2782) 1853 0 R (cite.RFC2825) 1897 0 R (cite.RFC2826) 1875 0 R (cite.RFC2845) 1790 0 R (cite.RFC2874) 1931 0 R (cite.RFC2915) 1855 0 R (cite.RFC2929) 1877 0 R (cite.RFC2930) 1792 0 R (cite.RFC2931) 1794 0 R (cite.RFC3007) 1796 0 R (cite.RFC3008) 1945 0 R (cite.RFC3071) 1919 0 R (cite.RFC3090) 1947 0 R (cite.RFC3110) 1857 0 R (cite.RFC3123) 1859 0 R (cite.RFC3225) 1802 0 R (cite.RFC3258) 1921 0 R (cite.RFC3445) 1949 0 R (cite.RFC3490) 1899 0 R (cite.RFC3491) 1901 0 R (cite.RFC3492) 1903 0 R (cite.RFC3596) 1861 0 R (cite.RFC3597) 1863 0 R (cite.RFC3645) 1798 0 R (cite.RFC3655) 1951 0 R (cite.RFC3658) 1953 0 R (cite.RFC3755) 1955 0 R (cite.RFC3757) 1957 0 R (cite.RFC3833) 1804 0 R (cite.RFC3845) 1959 0 R (cite.RFC3901) 1923 0 R (cite.RFC4033) 1806 0 R (cite.RFC4034) 1808 0 R (cite.RFC4035) 1810 0 R (cite.RFC4074) 1820 0 R (cite.RFC974) 1773 0 R (cite.id2507701) 1964 0 R (clients-per-query) 1685 0 R (configuration_file_elements) 1206 0 R (controls_statement_definition_and_usage) 1081 0 R (diagnostic_tools) 1011 0 R (dynamic_update) 1104 0 R (dynamic_update_policies) 1075 0 R (dynamic_update_security) 1383 0 R (empty) 1457 0 R (historical_dns_information) 1751 0 R (id2466552) 978 0 R (id2466576) 979 0 R (id2467534) 980 0 R (id2467544) 981 0 R (id2467716) 993 0 R (id2467737) 994 0 R (id2467771) 995 0 R (id2467856) 998 0 R (id2467948) 991 0 R (id2470253) 1005 0 R (id2470277) 1008 0 R (id2470375) 1009 0 R (id2470396) 1010 0 R (id2470426) 1016 0 R (id2470530) 1017 0 R (id2470556) 1018 0 R (id2470590) 1024 0 R (id2470617) 1025 0 R (id2470630) 1026 0 R (id2470724) 1029 0 R (id2470734) 1035 0 R (id2470766) 1042 0 R (id2470782) 1043 0 R (id2470805) 1049 0 R (id2470822) 1050 0 R (id2471227) 1058 0 R (id2471233) 1059 0 R (id2473198) 1086 0 R (id2473210) 1087 0 R (id2473636) 1120 0 R (id2473654) 1121 0 R (id2474087) 1141 0 R (id2474104) 1142 0 R (id2474142) 1143 0 R (id2474161) 1144 0 R (id2474171) 1145 0 R (id2474276) 1146 0 R (id2474333) 1151 0 R (id2474382) 1153 0 R (id2474533) 1154 0 R (id2474582) 1160 0 R (id2474718) 1162 0 R (id2474797) 1167 0 R (id2475015) 1168 0 R (id2475197) 1180 0 R (id2475328) 1182 0 R (id2475349) 1183 0 R (id2475382) 1194 0 R (id2475597) 1207 0 R (id2476558) 1215 0 R (id2476586) 1220 0 R (id2476792) 1221 0 R (id2476807) 1222 0 R (id2476837) 1228 0 R (id2477048) 1230 0 R (id2477514) 1236 0 R (id2477557) 1238 0 R (id2477704) 1240 0 R (id2478064) 1248 0 R (id2478149) 1254 0 R (id2478172) 1255 0 R (id2478196) 1256 0 R (id2478286) 1260 0 R (id2478412) 1265 0 R (id2478465) 1266 0 R (id2479158) 1277 0 R (id2479824) 1288 0 R (id2479954) 1289 0 R (id2480343) 1295 0 R (id2480417) 1300 0 R (id2480549) 1303 0 R (id2480593) 1304 0 R (id2480608) 1305 0 R (id2483505) 1342 0 R (id2485548) 1372 0 R (id2485607) 1374 0 R (id2486317) 1389 0 R (id2487452) 1408 0 R (id2487512) 1414 0 R (id2487866) 1422 0 R (id2488437) 1437 0 R (id2489946) 1467 0 R (id2490766) 1486 0 R (id2490921) 1487 0 R (id2490972) 1488 0 R (id2491019) 1494 0 R (id2491070) 1495 0 R (id2491443) 1500 0 R (id2493016) 1518 0 R (id2493024) 1519 0 R (id2493029) 1520 0 R (id2493588) 1527 0 R (id2493621) 1533 0 R (id2495464) 1593 0 R (id2495886) 1603 0 R (id2495905) 1604 0 R (id2495925) 1607 0 R (id2496230) 1609 0 R (id2497400) 1619 0 R (id2497528) 1621 0 R (id2497549) 1622 0 R (id2497912) 1629 0 R (id2498117) 1631 0 R (id2498135) 1632 0 R (id2498539) 1635 0 R (id2498664) 1641 0 R (id2498679) 1642 0 R (id2498791) 1644 0 R (id2498813) 1645 0 R (id2498829) 1646 0 R (id2498958) 1651 0 R (id2499028) 1652 0 R (id2499064) 1653 0 R (id2499140) 1658 0 R (id2499651) 1665 0 R (id2500086) 1673 0 R (id2500091) 1674 0 R (id2501696) 1682 0 R (id2501702) 1683 0 R (id2502078) 1690 0 R (id2502084) 1691 0 R (id2503100) 1697 0 R (id2503132) 1698 0 R (id2503474) 1703 0 R (id2503716) 1718 0 R (id2503865) 1719 0 R (id2503993) 1720 0 R (id2504073) 1735 0 R (id2504078) 1736 0 R (id2504158) 1737 0 R (id2504176) 1738 0 R (id2504237) 1750 0 R (id2504409) 1756 0 R (id2504665) 1761 0 R (id2504667) 1767 0 R (id2504676) 1772 0 R (id2504699) 1768 0 R (id2504723) 1770 0 R (id2504759) 1781 0 R (id2504786) 1783 0 R (id2504811) 1775 0 R (id2504836) 1777 0 R (id2504859) 1779 0 R (id2504915) 1785 0 R (id2504941) 1787 0 R (id2504968) 1789 0 R (id2505030) 1791 0 R (id2505060) 1793 0 R (id2505090) 1795 0 R (id2505116) 1797 0 R (id2505191) 1800 0 R (id2505198) 1801 0 R (id2505225) 1803 0 R (id2505261) 1805 0 R (id2505326) 1807 0 R (id2505392) 1809 0 R (id2505457) 1812 0 R (id2505465) 1813 0 R (id2505491) 1815 0 R (id2505559) 1817 0 R (id2505594) 1819 0 R (id2505635) 1827 0 R (id2505640) 1828 0 R (id2505698) 1830 0 R (id2505735) 1838 0 R (id2505770) 1832 0 R (id2505825) 1834 0 R (id2505863) 1836 0 R (id2505889) 1840 0 R (id2505914) 1842 0 R (id2505941) 1844 0 R (id2505968) 1846 0 R (id2506007) 1848 0 R (id2506037) 1850 0 R (id2506067) 1852 0 R (id2506109) 1854 0 R (id2506142) 1856 0 R (id2506169) 1858 0 R (id2506193) 1860 0 R (id2506250) 1862 0 R (id2506275) 1865 0 R (id2506282) 1866 0 R (id2506308) 1868 0 R (id2506330) 1870 0 R (id2506354) 1872 0 R (id2506400) 1874 0 R (id2506423) 1876 0 R (id2506473) 1883 0 R (id2506481) 1884 0 R (id2506504) 1886 0 R (id2506531) 1888 0 R (id2506557) 1890 0 R (id2506594) 1892 0 R (id2506634) 1895 0 R (id2506640) 1896 0 R (id2506672) 1898 0 R (id2506717) 1900 0 R (id2506821) 1902 0 R (id2506848) 1905 0 R (id2506866) 1906 0 R (id2506956) 1908 0 R (id2506982) 1910 0 R (id2507008) 1912 0 R (id2507031) 1914 0 R (id2507077) 1916 0 R (id2507100) 1918 0 R (id2507127) 1920 0 R (id2507153) 1922 0 R (id2507190) 1925 0 R (id2507196) 1926 0 R (id2507254) 1928 0 R (id2507281) 1930 0 R (id2507317) 1937 0 R (id2507329) 1938 0 R (id2507368) 1940 0 R (id2507395) 1942 0 R (id2507425) 1944 0 R (id2507450) 1946 0 R (id2507477) 1948 0 R (id2507513) 1950 0 R (id2507549) 1952 0 R (id2507576) 1954 0 R (id2507603) 1956 0 R (id2507648) 1958 0 R (id2507689) 1961 0 R (id2507699) 1963 0 R (id2507701) 1965 0 R (incremental_zone_transfers) 1117 0 R (internet_drafts) 1960 0 R (ipv6addresses) 1184 0 R (journal) 1106 0 R (lwresd) 1195 0 R (man.ddns-confgen) 2254 0 R (man.dig) 1971 0 R (man.dnssec-dsfromkey) 2019 0 R (man.dnssec-keyfromlabel) 2038 0 R (man.dnssec-keygen) 1585 0 R (man.dnssec-revoke) 2081 0 R (man.dnssec-settime) 1586 0 R (man.dnssec-signzone) 2104 0 R (man.host) 2004 0 R (man.named) 2161 0 R (man.named-checkconf) 2129 0 R (man.named-checkzone) 2141 0 R (man.nsupdate) 2184 0 R (man.rndc) 2209 0 R (man.rndc-confgen) 2238 0 R (man.rndc.conf) 2222 0 R (notify) 1095 0 R (options) 1074 0 R (page.1) 734 0 R (page.10) 1015 0 R (page.100) 1696 0 R (page.101) 1707 0 R (page.102) 1713 0 R (page.103) 1724 0 R (page.104) 1729 0 R (page.105) 1733 0 R (page.106) 1744 0 R (page.107) 1748 0 R (page.108) 1755 0 R (page.109) 1765 0 R (page.11) 1022 0 R (page.110) 1825 0 R (page.111) 1881 0 R (page.112) 1935 0 R (page.113) 1969 0 R (page.114) 1978 0 R (page.115) 1984 0 R (page.116) 1990 0 R (page.117) 1994 0 R (page.118) 1999 0 R (page.119) 2010 0 R (page.12) 1034 0 R (page.120) 2015 0 R (page.121) 2027 0 R (page.122) 2037 0 R (page.123) 2046 0 R (page.124) 2051 0 R (page.125) 2061 0 R (page.126) 2066 0 R (page.127) 2071 0 R (page.128) 2079 0 R (page.129) 2091 0 R (page.13) 1039 0 R (page.130) 2100 0 R (page.131) 2110 0 R (page.132) 2116 0 R (page.133) 2120 0 R (page.134) 2125 0 R (page.135) 2135 0 R (page.136) 2147 0 R (page.137) 2153 0 R (page.138) 2159 0 R (page.139) 2169 0 R (page.14) 1048 0 R (page.140) 2174 0 R (page.141) 2181 0 R (page.142) 2191 0 R (page.143) 2196 0 R (page.144) 2200 0 R (page.145) 2208 0 R (page.146) 2218 0 R (page.147) 2229 0 R (page.148) 2234 0 R (page.149) 2246 0 R (page.15) 1057 0 R (page.150) 2252 0 R (page.151) 2262 0 R (page.16) 1067 0 R (page.17) 1079 0 R (page.18) 1085 0 R (page.19) 1093 0 R (page.2) 759 0 R (page.20) 1116 0 R (page.21) 1126 0 R (page.22) 1131 0 R (page.23) 1135 0 R (page.24) 1140 0 R (page.25) 1150 0 R (page.26) 1159 0 R (page.27) 1166 0 R (page.28) 1172 0 R (page.29) 1176 0 R (page.3) 769 0 R (page.30) 1188 0 R (page.31) 1192 0 R (page.32) 1200 0 R (page.33) 1204 0 R (page.34) 1214 0 R (page.35) 1219 0 R (page.36) 1227 0 R (page.37) 1235 0 R (page.38) 1245 0 R (page.39) 1253 0 R (page.4) 824 0 R (page.40) 1264 0 R (page.41) 1270 0 R (page.42) 1276 0 R (page.43) 1282 0 R (page.44) 1287 0 R (page.45) 1294 0 R (page.46) 1299 0 R (page.47) 1309 0 R (page.48) 1313 0 R (page.49) 1317 0 R (page.5) 888 0 R (page.50) 1322 0 R (page.51) 1326 0 R (page.52) 1333 0 R (page.53) 1341 0 R (page.54) 1347 0 R (page.55) 1352 0 R (page.56) 1363 0 R (page.57) 1367 0 R (page.58) 1371 0 R (page.59) 1381 0 R (page.6) 951 0 R (page.60) 1387 0 R (page.61) 1393 0 R (page.62) 1399 0 R (page.63) 1403 0 R (page.64) 1407 0 R (page.65) 1413 0 R (page.66) 1421 0 R (page.67) 1427 0 R (page.68) 1435 0 R (page.69) 1442 0 R (page.7) 976 0 R (page.70) 1448 0 R (page.71) 1454 0 R (page.72) 1462 0 R (page.73) 1466 0 R (page.74) 1472 0 R (page.75) 1478 0 R (page.76) 1483 0 R (page.77) 1493 0 R (page.78) 1499 0 R (page.79) 1504 0 R (page.8) 990 0 R (page.80) 1509 0 R (page.81) 1513 0 R (page.82) 1517 0 R (page.83) 1525 0 R (page.84) 1532 0 R (page.85) 1552 0 R (page.86) 1567 0 R (page.87) 1590 0 R (page.88) 1598 0 R (page.89) 1602 0 R (page.9) 1004 0 R (page.90) 1614 0 R (page.91) 1618 0 R (page.92) 1628 0 R (page.93) 1640 0 R (page.94) 1650 0 R (page.95) 1657 0 R (page.96) 1663 0 R (page.97) 1670 0 R (page.98) 1680 0 R (page.99) 1689 0 R (proposed_standards) 1122 0 R (query_address) 1394 0 R (rfcs) 1000 0 R (rndc) 1249 0 R (root_delegation_only) 1528 0 R (rrset_ordering) 1053 0 R (sample_configuration) 1041 0 R (section*.10) 1894 0 R (section*.100) 2182 0 R (section*.101) 2183 0 R (section*.102) 2185 0 R (section*.103) 2186 0 R (section*.104) 2187 0 R (section*.105) 2192 0 R (section*.106) 2201 0 R (section*.107) 2202 0 R (section*.108) 2203 0 R (section*.109) 2204 0 R (section*.11) 1904 0 R (section*.110) 2210 0 R (section*.111) 2211 0 R (section*.112) 2212 0 R (section*.113) 2213 0 R (section*.114) 2219 0 R (section*.115) 2220 0 R (section*.116) 2221 0 R (section*.117) 2223 0 R (section*.118) 2224 0 R (section*.119) 2225 0 R (section*.12) 1924 0 R (section*.120) 2230 0 R (section*.121) 2235 0 R (section*.122) 2236 0 R (section*.123) 2237 0 R (section*.124) 2239 0 R (section*.125) 2240 0 R (section*.126) 2241 0 R (section*.127) 2242 0 R (section*.128) 2247 0 R (section*.129) 2248 0 R (section*.13) 1936 0 R (section*.130) 2253 0 R (section*.131) 2255 0 R (section*.132) 2256 0 R (section*.133) 2257 0 R (section*.134) 2258 0 R (section*.135) 2263 0 R (section*.136) 2264 0 R (section*.14) 1962 0 R (section*.15) 1972 0 R (section*.16) 1973 0 R (section*.17) 1974 0 R (section*.18) 1979 0 R (section*.19) 1980 0 R (section*.2) 1760 0 R (section*.20) 1985 0 R (section*.21) 1995 0 R (section*.22) 2000 0 R (section*.23) 2001 0 R (section*.24) 2002 0 R (section*.25) 2003 0 R (section*.26) 2005 0 R (section*.27) 2006 0 R (section*.28) 2011 0 R (section*.29) 2016 0 R (section*.3) 1766 0 R (section*.30) 2017 0 R (section*.31) 2018 0 R (section*.32) 2020 0 R (section*.33) 2021 0 R (section*.34) 2022 0 R (section*.35) 2023 0 R (section*.36) 2028 0 R (section*.37) 2029 0 R (section*.38) 2030 0 R (section*.39) 2031 0 R (section*.4) 1774 0 R (section*.40) 2032 0 R (section*.41) 2039 0 R (section*.42) 2040 0 R (section*.43) 2041 0 R (section*.44) 2042 0 R (section*.45) 2047 0 R (section*.46) 2052 0 R (section*.47) 2053 0 R (section*.48) 2054 0 R (section*.49) 2055 0 R (section*.5) 1799 0 R (section*.50) 2056 0 R (section*.51) 2057 0 R (section*.52) 2062 0 R (section*.53) 2067 0 R (section*.54) 2072 0 R (section*.55) 2073 0 R (section*.56) 2074 0 R (section*.57) 2080 0 R (section*.58) 2082 0 R (section*.59) 2083 0 R (section*.6) 1811 0 R (section*.60) 2084 0 R (section*.61) 2085 0 R (section*.62) 2086 0 R (section*.63) 2087 0 R (section*.64) 2092 0 R (section*.65) 2093 0 R (section*.66) 2094 0 R (section*.67) 2095 0 R (section*.68) 2096 0 R (section*.69) 2101 0 R (section*.7) 1826 0 R (section*.70) 2102 0 R (section*.71) 2103 0 R (section*.72) 2105 0 R (section*.73) 2106 0 R (section*.74) 2111 0 R (section*.75) 2112 0 R (section*.76) 2126 0 R (section*.77) 2127 0 R (section*.78) 2128 0 R (section*.79) 2130 0 R (section*.8) 1864 0 R (section*.80) 2131 0 R (section*.81) 2136 0 R (section*.82) 2137 0 R (section*.83) 2138 0 R (section*.84) 2139 0 R (section*.85) 2140 0 R (section*.86) 2142 0 R (section*.87) 2143 0 R (section*.88) 2148 0 R (section*.89) 2149 0 R (section*.9) 1882 0 R (section*.90) 2154 0 R (section*.91) 2155 0 R (section*.92) 2160 0 R (section*.93) 2162 0 R (section*.94) 2163 0 R (section*.95) 2164 0 R (section*.96) 2165 0 R (section*.97) 2175 0 R (section*.98) 2176 0 R (section*.99) 2177 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 494 0 R (section.6.4) 550 0 R (section.7.1) 586 0 R (section.7.2) 590 0 R (section.7.3) 602 0 R (section.8.1) 610 0 R (section.8.2) 618 0 R (section.8.3) 622 0 R (section.A.1) 630 0 R (section.A.2) 638 0 R (section.A.3) 646 0 R (section.B.1) 666 0 R (section.B.10) 702 0 R (section.B.11) 706 0 R (section.B.12) 710 0 R (section.B.13) 714 0 R (section.B.14) 718 0 R (section.B.15) 722 0 R (section.B.16) 726 0 R (section.B.2) 670 0 R (section.B.3) 674 0 R (section.B.4) 678 0 R (section.B.5) 682 0 R (section.B.6) 686 0 R (section.B.7) 690 0 R (section.B.8) 694 0 R (section.B.9) 698 0 R (server_resource_limits) 1416 0 R (server_statement_definition_and_usage) 1359 0 R (server_statement_grammar) 1474 0 R (statistics) 1664 0 R (statistics_counters) 1672 0 R (statschannels) 1485 0 R (statsfile) 1329 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 330 0 R (subsection.6.2.12) 334 0 R (subsection.6.2.13) 338 0 R (subsection.6.2.14) 342 0 R (subsection.6.2.15) 346 0 R (subsection.6.2.16) 350 0 R (subsection.6.2.17) 430 0 R (subsection.6.2.18) 434 0 R (subsection.6.2.19) 438 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 442 0 R (subsection.6.2.21) 446 0 R (subsection.6.2.22) 450 0 R (subsection.6.2.23) 454 0 R (subsection.6.2.24) 458 0 R (subsection.6.2.25) 462 0 R (subsection.6.2.26) 466 0 R (subsection.6.2.27) 470 0 R (subsection.6.2.28) 474 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 498 0 R (subsection.6.3.2) 510 0 R (subsection.6.3.3) 514 0 R (subsection.6.3.4) 518 0 R (subsection.6.3.5) 522 0 R (subsection.6.3.6) 542 0 R (subsection.6.3.7) 546 0 R (subsection.6.4.1) 558 0 R (subsection.7.2.1) 594 0 R (subsection.7.2.2) 598 0 R (subsection.8.1.1) 614 0 R (subsection.A.1.1) 634 0 R (subsection.A.2.1) 642 0 R (subsection.A.3.1) 650 0 R (subsection.A.3.2) 654 0 R (subsection.A.3.3) 658 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.10.3) 326 0 R (subsubsection.6.2.16.1) 354 0 R (subsubsection.6.2.16.10) 390 0 R (subsubsection.6.2.16.11) 394 0 R (subsubsection.6.2.16.12) 398 0 R (subsubsection.6.2.16.13) 402 0 R (subsubsection.6.2.16.14) 406 0 R (subsubsection.6.2.16.15) 410 0 R (subsubsection.6.2.16.16) 414 0 R (subsubsection.6.2.16.17) 418 0 R (subsubsection.6.2.16.18) 422 0 R (subsubsection.6.2.16.19) 426 0 R (subsubsection.6.2.16.2) 358 0 R (subsubsection.6.2.16.3) 362 0 R (subsubsection.6.2.16.4) 366 0 R (subsubsection.6.2.16.5) 370 0 R (subsubsection.6.2.16.6) 374 0 R (subsubsection.6.2.16.7) 378 0 R (subsubsection.6.2.16.8) 382 0 R (subsubsection.6.2.16.9) 386 0 R (subsubsection.6.2.28.1) 478 0 R (subsubsection.6.2.28.2) 482 0 R (subsubsection.6.2.28.3) 486 0 R (subsubsection.6.2.28.4) 490 0 R (subsubsection.6.3.1.1) 502 0 R (subsubsection.6.3.1.2) 506 0 R (subsubsection.6.3.5.1) 526 0 R (subsubsection.6.3.5.2) 530 0 R (subsubsection.6.3.5.3) 534 0 R (subsubsection.6.3.5.4) 538 0 R (subsubsection.6.4.0.1) 554 0 R (subsubsection.6.4.1.1) 562 0 R (subsubsection.6.4.1.2) 566 0 R (subsubsection.6.4.1.3) 570 0 R (subsubsection.6.4.1.4) 574 0 R (subsubsection.6.4.1.5) 578 0 R (table.1.1) 982 0 R (table.1.2) 992 0 R (table.3.1) 1051 0 R (table.3.2) 1088 0 R (table.6.1) 1208 0 R (table.6.10) 1608 0 R (table.6.11) 1610 0 R (table.6.12) 1620 0 R (table.6.13) 1623 0 R (table.6.14) 1630 0 R (table.6.15) 1633 0 R (table.6.16) 1636 0 R (table.6.17) 1643 0 R (table.6.18) 1659 0 R (table.6.19) 1666 0 R (table.6.2) 1231 0 R (table.6.20) 1675 0 R (table.6.21) 1684 0 R (table.6.22) 1692 0 R (table.6.23) 1699 0 R (table.6.3) 1239 0 R (table.6.4) 1278 0 R (table.6.5) 1290 0 R (table.6.6) 1343 0 R (table.6.7) 1438 0 R (table.6.8) 1521 0 R (table.6.9) 1594 0 R (the_category_phrase) 1272 0 R (the_sortlist_statement) 1428 0 R (topology) 1423 0 R (tsig) 1136 0 R (tuning) 1443 0 R (types_of_resource_records_and_when_to_use_them) 999 0 R (view_statement_grammar) 1458 0 R (zone_statement_grammar) 1377 0 R (zone_transfers) 1112 0 R (zonefile_format) 1450 0 R] +/Names [(Access_Control_Lists) 1709 0 R (Bv9ARM.ch01) 977 0 R (Bv9ARM.ch02) 1023 0 R (Bv9ARM.ch03) 1040 0 R (Bv9ARM.ch04) 1094 0 R (Bv9ARM.ch05) 1193 0 R (Bv9ARM.ch06) 1205 0 R (Bv9ARM.ch07) 1708 0 R (Bv9ARM.ch08) 1734 0 R (Bv9ARM.ch09) 1749 0 R (Bv9ARM.ch10) 1970 0 R (Configuration_File_Grammar) 1229 0 R (DNSSEC) 1161 0 R (Doc-Start) 735 0 R (Setting_TTLs) 1634 0 R (acache) 1030 0 R (access_control) 1375 0 R (acl) 1237 0 R (address_match_lists) 1210 0 R (admin_tools) 1063 0 R (appendix.A) 626 0 R (appendix.B) 662 0 R (bibliography) 1757 0 R (boolean_options) 1111 0 R (builtin) 1455 0 R (chapter*.1) 770 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 582 0 R (chapter.8) 606 0 R (cite.RFC1033) 1885 0 R (cite.RFC1034) 1769 0 R (cite.RFC1035) 1771 0 R (cite.RFC1101) 1867 0 R (cite.RFC1123) 1869 0 R (cite.RFC1183) 1829 0 R (cite.RFC1464) 1907 0 R (cite.RFC1535) 1814 0 R (cite.RFC1536) 1816 0 R (cite.RFC1537) 1887 0 R (cite.RFC1591) 1871 0 R (cite.RFC1706) 1831 0 R (cite.RFC1712) 1927 0 R (cite.RFC1713) 1909 0 R (cite.RFC1794) 1911 0 R (cite.RFC1876) 1833 0 R (cite.RFC1912) 1889 0 R (cite.RFC1982) 1818 0 R (cite.RFC1995) 1776 0 R (cite.RFC1996) 1778 0 R (cite.RFC2010) 1891 0 R (cite.RFC2052) 1835 0 R (cite.RFC2065) 1939 0 R (cite.RFC2136) 1780 0 R (cite.RFC2137) 1941 0 R (cite.RFC2163) 1837 0 R (cite.RFC2168) 1839 0 R (cite.RFC2181) 1782 0 R (cite.RFC2219) 1893 0 R (cite.RFC2230) 1841 0 R (cite.RFC2240) 1913 0 R (cite.RFC2308) 1784 0 R (cite.RFC2317) 1873 0 R (cite.RFC2345) 1915 0 R (cite.RFC2352) 1917 0 R (cite.RFC2535) 1943 0 R (cite.RFC2536) 1843 0 R (cite.RFC2537) 1845 0 R (cite.RFC2538) 1847 0 R (cite.RFC2539) 1849 0 R (cite.RFC2540) 1851 0 R (cite.RFC2671) 1786 0 R (cite.RFC2672) 1788 0 R (cite.RFC2673) 1929 0 R (cite.RFC2782) 1853 0 R (cite.RFC2825) 1897 0 R (cite.RFC2826) 1875 0 R (cite.RFC2845) 1790 0 R (cite.RFC2874) 1931 0 R (cite.RFC2915) 1855 0 R (cite.RFC2929) 1877 0 R (cite.RFC2930) 1792 0 R (cite.RFC2931) 1794 0 R (cite.RFC3007) 1796 0 R (cite.RFC3008) 1945 0 R (cite.RFC3071) 1919 0 R (cite.RFC3090) 1947 0 R (cite.RFC3110) 1857 0 R (cite.RFC3123) 1859 0 R (cite.RFC3225) 1802 0 R (cite.RFC3258) 1921 0 R (cite.RFC3445) 1949 0 R (cite.RFC3490) 1899 0 R (cite.RFC3491) 1901 0 R (cite.RFC3492) 1903 0 R (cite.RFC3596) 1861 0 R (cite.RFC3597) 1863 0 R (cite.RFC3645) 1798 0 R (cite.RFC3655) 1951 0 R (cite.RFC3658) 1953 0 R (cite.RFC3755) 1955 0 R (cite.RFC3757) 1957 0 R (cite.RFC3833) 1804 0 R (cite.RFC3845) 1959 0 R (cite.RFC3901) 1923 0 R (cite.RFC4033) 1806 0 R (cite.RFC4034) 1808 0 R (cite.RFC4035) 1810 0 R (cite.RFC4074) 1820 0 R (cite.RFC974) 1773 0 R (cite.id2507832) 1964 0 R (clients-per-query) 1685 0 R (configuration_file_elements) 1206 0 R (controls_statement_definition_and_usage) 1081 0 R (diagnostic_tools) 1011 0 R (dynamic_update) 1104 0 R (dynamic_update_policies) 1075 0 R (dynamic_update_security) 1383 0 R (empty) 1457 0 R (historical_dns_information) 1751 0 R (id2466552) 978 0 R (id2466576) 979 0 R (id2467534) 980 0 R (id2467544) 981 0 R (id2467716) 993 0 R (id2467737) 994 0 R (id2467771) 995 0 R (id2467856) 998 0 R (id2467948) 991 0 R (id2470253) 1005 0 R (id2470277) 1008 0 R (id2470375) 1009 0 R (id2470396) 1010 0 R (id2470426) 1016 0 R (id2470530) 1017 0 R (id2470556) 1018 0 R (id2470590) 1024 0 R (id2470617) 1025 0 R (id2470630) 1026 0 R (id2470724) 1029 0 R (id2470734) 1035 0 R (id2470766) 1042 0 R (id2470782) 1043 0 R (id2470805) 1049 0 R (id2470822) 1050 0 R (id2471227) 1058 0 R (id2471233) 1059 0 R (id2473198) 1086 0 R (id2473210) 1087 0 R (id2473642) 1120 0 R (id2473660) 1126 0 R (id2474162) 1141 0 R (id2474179) 1142 0 R (id2474285) 1143 0 R (id2474304) 1144 0 R (id2474314) 1145 0 R (id2474350) 1150 0 R (id2474476) 1151 0 R (id2474525) 1153 0 R (id2474539) 1154 0 R (id2474588) 1160 0 R (id2474657) 1162 0 R (id2474872) 1167 0 R (id2475021) 1168 0 R (id2475204) 1180 0 R (id2475334) 1182 0 R (id2475355) 1183 0 R (id2475388) 1194 0 R (id2475672) 1207 0 R (id2476565) 1215 0 R (id2476593) 1220 0 R (id2476798) 1221 0 R (id2476813) 1222 0 R (id2476843) 1228 0 R (id2476986) 1230 0 R (id2477521) 1236 0 R (id2477563) 1238 0 R (id2477710) 1240 0 R (id2478070) 1248 0 R (id2478155) 1254 0 R (id2478179) 1255 0 R (id2478202) 1256 0 R (id2478293) 1260 0 R (id2478419) 1265 0 R (id2478471) 1266 0 R (id2479164) 1277 0 R (id2479898) 1288 0 R (id2480028) 1289 0 R (id2480418) 1295 0 R (id2480491) 1300 0 R (id2480555) 1303 0 R (id2480599) 1304 0 R (id2480682) 1305 0 R (id2483572) 1342 0 R (id2485543) 1372 0 R (id2485602) 1374 0 R (id2486312) 1389 0 R (id2487379) 1408 0 R (id2487507) 1414 0 R (id2487929) 1422 0 R (id2488432) 1437 0 R (id2489941) 1467 0 R (id2490761) 1486 0 R (id2490916) 1487 0 R (id2490967) 1488 0 R (id2491014) 1494 0 R (id2491065) 1495 0 R (id2491437) 1500 0 R (id2493079) 1518 0 R (id2493086) 1519 0 R (id2493092) 1520 0 R (id2493582) 1527 0 R (id2493616) 1533 0 R (id2495459) 1593 0 R (id2495881) 1603 0 R (id2495899) 1604 0 R (id2495920) 1607 0 R (id2496225) 1609 0 R (id2497326) 1619 0 R (id2497454) 1621 0 R (id2497612) 1622 0 R (id2497975) 1629 0 R (id2498180) 1631 0 R (id2498198) 1632 0 R (id2498602) 1635 0 R (id2498727) 1641 0 R (id2498742) 1642 0 R (id2498922) 1644 0 R (id2498945) 1645 0 R (id2498961) 1646 0 R (id2499021) 1651 0 R (id2499091) 1652 0 R (id2499195) 1653 0 R (id2499271) 1658 0 R (id2499782) 1665 0 R (id2500217) 1673 0 R (id2500222) 1674 0 R (id2501758) 1682 0 R (id2501765) 1683 0 R (id2502141) 1690 0 R (id2502147) 1691 0 R (id2503163) 1697 0 R (id2503195) 1698 0 R (id2503537) 1703 0 R (id2503779) 1718 0 R (id2503928) 1719 0 R (id2504056) 1720 0 R (id2504136) 1735 0 R (id2504141) 1736 0 R (id2504153) 1737 0 R (id2504170) 1738 0 R (id2504369) 1750 0 R (id2504540) 1756 0 R (id2504796) 1761 0 R (id2504798) 1767 0 R (id2504807) 1772 0 R (id2504830) 1768 0 R (id2504854) 1770 0 R (id2504890) 1781 0 R (id2504917) 1783 0 R (id2504942) 1775 0 R (id2504967) 1777 0 R (id2504990) 1779 0 R (id2505046) 1785 0 R (id2505073) 1787 0 R (id2505099) 1789 0 R (id2505161) 1791 0 R (id2505191) 1793 0 R (id2505221) 1795 0 R (id2505248) 1797 0 R (id2505322) 1800 0 R (id2505330) 1801 0 R (id2505356) 1803 0 R (id2505393) 1805 0 R (id2505458) 1807 0 R (id2505523) 1809 0 R (id2505588) 1812 0 R (id2505596) 1813 0 R (id2505622) 1815 0 R (id2505690) 1817 0 R (id2505725) 1819 0 R (id2505766) 1827 0 R (id2505771) 1828 0 R (id2505829) 1830 0 R (id2505866) 1838 0 R (id2505901) 1832 0 R (id2505956) 1834 0 R (id2505994) 1836 0 R (id2506020) 1840 0 R (id2506045) 1842 0 R (id2506072) 1844 0 R (id2506099) 1846 0 R (id2506138) 1848 0 R (id2506168) 1850 0 R (id2506198) 1852 0 R (id2506241) 1854 0 R (id2506274) 1856 0 R (id2506300) 1858 0 R (id2506324) 1860 0 R (id2506381) 1862 0 R (id2506406) 1865 0 R (id2506413) 1866 0 R (id2506439) 1868 0 R (id2506461) 1870 0 R (id2506485) 1872 0 R (id2506531) 1874 0 R (id2506554) 1876 0 R (id2506604) 1883 0 R (id2506612) 1884 0 R (id2506635) 1886 0 R (id2506662) 1888 0 R (id2506689) 1890 0 R (id2506725) 1892 0 R (id2506765) 1895 0 R (id2506771) 1896 0 R (id2506803) 1898 0 R (id2506849) 1900 0 R (id2506884) 1902 0 R (id2506979) 1905 0 R (id2506997) 1906 0 R (id2507019) 1908 0 R (id2507113) 1910 0 R (id2507139) 1912 0 R (id2507162) 1914 0 R (id2507208) 1916 0 R (id2507232) 1918 0 R (id2507258) 1920 0 R (id2507284) 1922 0 R (id2507321) 1925 0 R (id2507328) 1926 0 R (id2507385) 1928 0 R (id2507412) 1930 0 R (id2507448) 1937 0 R (id2507460) 1938 0 R (id2507499) 1940 0 R (id2507526) 1942 0 R (id2507556) 1944 0 R (id2507581) 1946 0 R (id2507608) 1948 0 R (id2507644) 1950 0 R (id2507681) 1952 0 R (id2507707) 1954 0 R (id2507734) 1956 0 R (id2507779) 1958 0 R (id2507820) 1961 0 R (id2507830) 1963 0 R (id2507832) 1965 0 R (incremental_zone_transfers) 1117 0 R (internet_drafts) 1960 0 R (ipv6addresses) 1184 0 R (journal) 1106 0 R (lwresd) 1195 0 R (man.ddns-confgen) 2254 0 R (man.dig) 1971 0 R (man.dnssec-dsfromkey) 2019 0 R (man.dnssec-keyfromlabel) 2038 0 R (man.dnssec-keygen) 1585 0 R (man.dnssec-revoke) 2081 0 R (man.dnssec-settime) 1586 0 R (man.dnssec-signzone) 2104 0 R (man.host) 2004 0 R (man.named) 2161 0 R (man.named-checkconf) 2129 0 R (man.named-checkzone) 2141 0 R (man.nsupdate) 2184 0 R (man.rndc) 2209 0 R (man.rndc-confgen) 2238 0 R (man.rndc.conf) 2222 0 R (notify) 1095 0 R (options) 1074 0 R (page.1) 734 0 R (page.10) 1015 0 R (page.100) 1696 0 R (page.101) 1707 0 R (page.102) 1713 0 R (page.103) 1724 0 R (page.104) 1729 0 R (page.105) 1733 0 R (page.106) 1744 0 R (page.107) 1748 0 R (page.108) 1755 0 R (page.109) 1765 0 R (page.11) 1022 0 R (page.110) 1825 0 R (page.111) 1881 0 R (page.112) 1935 0 R (page.113) 1969 0 R (page.114) 1978 0 R (page.115) 1984 0 R (page.116) 1990 0 R (page.117) 1994 0 R (page.118) 1999 0 R (page.119) 2010 0 R (page.12) 1034 0 R (page.120) 2015 0 R (page.121) 2027 0 R (page.122) 2037 0 R (page.123) 2046 0 R (page.124) 2051 0 R (page.125) 2061 0 R (page.126) 2066 0 R (page.127) 2071 0 R (page.128) 2079 0 R (page.129) 2091 0 R (page.13) 1039 0 R (page.130) 2100 0 R (page.131) 2110 0 R (page.132) 2116 0 R (page.133) 2120 0 R (page.134) 2125 0 R (page.135) 2135 0 R (page.136) 2147 0 R (page.137) 2153 0 R (page.138) 2159 0 R (page.139) 2169 0 R (page.14) 1048 0 R (page.140) 2174 0 R (page.141) 2181 0 R (page.142) 2191 0 R (page.143) 2196 0 R (page.144) 2200 0 R (page.145) 2208 0 R (page.146) 2218 0 R (page.147) 2229 0 R (page.148) 2234 0 R (page.149) 2246 0 R (page.15) 1057 0 R (page.150) 2252 0 R (page.151) 2262 0 R (page.16) 1067 0 R (page.17) 1079 0 R (page.18) 1085 0 R (page.19) 1093 0 R (page.2) 759 0 R (page.20) 1116 0 R (page.21) 1125 0 R (page.22) 1131 0 R (page.23) 1135 0 R (page.24) 1140 0 R (page.25) 1149 0 R (page.26) 1159 0 R (page.27) 1166 0 R (page.28) 1172 0 R (page.29) 1176 0 R (page.3) 769 0 R (page.30) 1188 0 R (page.31) 1192 0 R (page.32) 1200 0 R (page.33) 1204 0 R (page.34) 1214 0 R (page.35) 1219 0 R (page.36) 1227 0 R (page.37) 1235 0 R (page.38) 1245 0 R (page.39) 1253 0 R (page.4) 824 0 R (page.40) 1264 0 R (page.41) 1270 0 R (page.42) 1276 0 R (page.43) 1282 0 R (page.44) 1287 0 R (page.45) 1294 0 R (page.46) 1299 0 R (page.47) 1309 0 R (page.48) 1313 0 R (page.49) 1317 0 R (page.5) 888 0 R (page.50) 1322 0 R (page.51) 1326 0 R (page.52) 1333 0 R (page.53) 1341 0 R (page.54) 1347 0 R (page.55) 1352 0 R (page.56) 1363 0 R (page.57) 1367 0 R (page.58) 1371 0 R (page.59) 1381 0 R (page.6) 951 0 R (page.60) 1387 0 R (page.61) 1393 0 R (page.62) 1399 0 R (page.63) 1403 0 R (page.64) 1407 0 R (page.65) 1413 0 R (page.66) 1421 0 R (page.67) 1427 0 R (page.68) 1435 0 R (page.69) 1442 0 R (page.7) 976 0 R (page.70) 1448 0 R (page.71) 1454 0 R (page.72) 1462 0 R (page.73) 1466 0 R (page.74) 1472 0 R (page.75) 1478 0 R (page.76) 1483 0 R (page.77) 1493 0 R (page.78) 1499 0 R (page.79) 1504 0 R (page.8) 990 0 R (page.80) 1509 0 R (page.81) 1513 0 R (page.82) 1517 0 R (page.83) 1525 0 R (page.84) 1532 0 R (page.85) 1552 0 R (page.86) 1567 0 R (page.87) 1590 0 R (page.88) 1598 0 R (page.89) 1602 0 R (page.9) 1004 0 R (page.90) 1614 0 R (page.91) 1618 0 R (page.92) 1628 0 R (page.93) 1640 0 R (page.94) 1650 0 R (page.95) 1657 0 R (page.96) 1663 0 R (page.97) 1670 0 R (page.98) 1680 0 R (page.99) 1689 0 R (proposed_standards) 1121 0 R (query_address) 1394 0 R (rfcs) 1000 0 R (rndc) 1249 0 R (root_delegation_only) 1528 0 R (rrset_ordering) 1053 0 R (sample_configuration) 1041 0 R (section*.10) 1894 0 R (section*.100) 2182 0 R (section*.101) 2183 0 R (section*.102) 2185 0 R (section*.103) 2186 0 R (section*.104) 2187 0 R (section*.105) 2192 0 R (section*.106) 2201 0 R (section*.107) 2202 0 R (section*.108) 2203 0 R (section*.109) 2204 0 R (section*.11) 1904 0 R (section*.110) 2210 0 R (section*.111) 2211 0 R (section*.112) 2212 0 R (section*.113) 2213 0 R (section*.114) 2219 0 R (section*.115) 2220 0 R (section*.116) 2221 0 R (section*.117) 2223 0 R (section*.118) 2224 0 R (section*.119) 2225 0 R (section*.12) 1924 0 R (section*.120) 2230 0 R (section*.121) 2235 0 R (section*.122) 2236 0 R (section*.123) 2237 0 R (section*.124) 2239 0 R (section*.125) 2240 0 R (section*.126) 2241 0 R (section*.127) 2242 0 R (section*.128) 2247 0 R (section*.129) 2248 0 R (section*.13) 1936 0 R (section*.130) 2253 0 R (section*.131) 2255 0 R (section*.132) 2256 0 R (section*.133) 2257 0 R (section*.134) 2258 0 R (section*.135) 2263 0 R (section*.136) 2264 0 R (section*.14) 1962 0 R (section*.15) 1972 0 R (section*.16) 1973 0 R (section*.17) 1974 0 R (section*.18) 1979 0 R (section*.19) 1980 0 R (section*.2) 1760 0 R (section*.20) 1985 0 R (section*.21) 1995 0 R (section*.22) 2000 0 R (section*.23) 2001 0 R (section*.24) 2002 0 R (section*.25) 2003 0 R (section*.26) 2005 0 R (section*.27) 2006 0 R (section*.28) 2011 0 R (section*.29) 2016 0 R (section*.3) 1766 0 R (section*.30) 2017 0 R (section*.31) 2018 0 R (section*.32) 2020 0 R (section*.33) 2021 0 R (section*.34) 2022 0 R (section*.35) 2023 0 R (section*.36) 2028 0 R (section*.37) 2029 0 R (section*.38) 2030 0 R (section*.39) 2031 0 R (section*.4) 1774 0 R (section*.40) 2032 0 R (section*.41) 2039 0 R (section*.42) 2040 0 R (section*.43) 2041 0 R (section*.44) 2042 0 R (section*.45) 2047 0 R (section*.46) 2052 0 R (section*.47) 2053 0 R (section*.48) 2054 0 R (section*.49) 2055 0 R (section*.5) 1799 0 R (section*.50) 2056 0 R (section*.51) 2057 0 R (section*.52) 2062 0 R (section*.53) 2067 0 R (section*.54) 2072 0 R (section*.55) 2073 0 R (section*.56) 2074 0 R (section*.57) 2080 0 R (section*.58) 2082 0 R (section*.59) 2083 0 R (section*.6) 1811 0 R (section*.60) 2084 0 R (section*.61) 2085 0 R (section*.62) 2086 0 R (section*.63) 2087 0 R (section*.64) 2092 0 R (section*.65) 2093 0 R (section*.66) 2094 0 R (section*.67) 2095 0 R (section*.68) 2096 0 R (section*.69) 2101 0 R (section*.7) 1826 0 R (section*.70) 2102 0 R (section*.71) 2103 0 R (section*.72) 2105 0 R (section*.73) 2106 0 R (section*.74) 2111 0 R (section*.75) 2112 0 R (section*.76) 2126 0 R (section*.77) 2127 0 R (section*.78) 2128 0 R (section*.79) 2130 0 R (section*.8) 1864 0 R (section*.80) 2131 0 R (section*.81) 2136 0 R (section*.82) 2137 0 R (section*.83) 2138 0 R (section*.84) 2139 0 R (section*.85) 2140 0 R (section*.86) 2142 0 R (section*.87) 2143 0 R (section*.88) 2148 0 R (section*.89) 2149 0 R (section*.9) 1882 0 R (section*.90) 2154 0 R (section*.91) 2155 0 R (section*.92) 2160 0 R (section*.93) 2162 0 R (section*.94) 2163 0 R (section*.95) 2164 0 R (section*.96) 2165 0 R (section*.97) 2175 0 R (section*.98) 2176 0 R (section*.99) 2177 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 494 0 R (section.6.4) 550 0 R (section.7.1) 586 0 R (section.7.2) 590 0 R (section.7.3) 602 0 R (section.8.1) 610 0 R (section.8.2) 618 0 R (section.8.3) 622 0 R (section.A.1) 630 0 R (section.A.2) 638 0 R (section.A.3) 646 0 R (section.B.1) 666 0 R (section.B.10) 702 0 R (section.B.11) 706 0 R (section.B.12) 710 0 R (section.B.13) 714 0 R (section.B.14) 718 0 R (section.B.15) 722 0 R (section.B.16) 726 0 R (section.B.2) 670 0 R (section.B.3) 674 0 R (section.B.4) 678 0 R (section.B.5) 682 0 R (section.B.6) 686 0 R (section.B.7) 690 0 R (section.B.8) 694 0 R (section.B.9) 698 0 R (server_resource_limits) 1416 0 R (server_statement_definition_and_usage) 1359 0 R (server_statement_grammar) 1474 0 R (statistics) 1664 0 R (statistics_counters) 1672 0 R (statschannels) 1485 0 R (statsfile) 1329 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 330 0 R (subsection.6.2.12) 334 0 R (subsection.6.2.13) 338 0 R (subsection.6.2.14) 342 0 R (subsection.6.2.15) 346 0 R (subsection.6.2.16) 350 0 R (subsection.6.2.17) 430 0 R (subsection.6.2.18) 434 0 R (subsection.6.2.19) 438 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 442 0 R (subsection.6.2.21) 446 0 R (subsection.6.2.22) 450 0 R (subsection.6.2.23) 454 0 R (subsection.6.2.24) 458 0 R (subsection.6.2.25) 462 0 R (subsection.6.2.26) 466 0 R (subsection.6.2.27) 470 0 R (subsection.6.2.28) 474 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 498 0 R (subsection.6.3.2) 510 0 R (subsection.6.3.3) 514 0 R (subsection.6.3.4) 518 0 R (subsection.6.3.5) 522 0 R (subsection.6.3.6) 542 0 R (subsection.6.3.7) 546 0 R (subsection.6.4.1) 558 0 R (subsection.7.2.1) 594 0 R (subsection.7.2.2) 598 0 R (subsection.8.1.1) 614 0 R (subsection.A.1.1) 634 0 R (subsection.A.2.1) 642 0 R (subsection.A.3.1) 650 0 R (subsection.A.3.2) 654 0 R (subsection.A.3.3) 658 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.10.3) 326 0 R (subsubsection.6.2.16.1) 354 0 R (subsubsection.6.2.16.10) 390 0 R (subsubsection.6.2.16.11) 394 0 R (subsubsection.6.2.16.12) 398 0 R (subsubsection.6.2.16.13) 402 0 R (subsubsection.6.2.16.14) 406 0 R (subsubsection.6.2.16.15) 410 0 R (subsubsection.6.2.16.16) 414 0 R (subsubsection.6.2.16.17) 418 0 R (subsubsection.6.2.16.18) 422 0 R (subsubsection.6.2.16.19) 426 0 R (subsubsection.6.2.16.2) 358 0 R (subsubsection.6.2.16.3) 362 0 R (subsubsection.6.2.16.4) 366 0 R (subsubsection.6.2.16.5) 370 0 R (subsubsection.6.2.16.6) 374 0 R (subsubsection.6.2.16.7) 378 0 R (subsubsection.6.2.16.8) 382 0 R (subsubsection.6.2.16.9) 386 0 R (subsubsection.6.2.28.1) 478 0 R (subsubsection.6.2.28.2) 482 0 R (subsubsection.6.2.28.3) 486 0 R (subsubsection.6.2.28.4) 490 0 R (subsubsection.6.3.1.1) 502 0 R (subsubsection.6.3.1.2) 506 0 R (subsubsection.6.3.5.1) 526 0 R (subsubsection.6.3.5.2) 530 0 R (subsubsection.6.3.5.3) 534 0 R (subsubsection.6.3.5.4) 538 0 R (subsubsection.6.4.0.1) 554 0 R (subsubsection.6.4.1.1) 562 0 R (subsubsection.6.4.1.2) 566 0 R (subsubsection.6.4.1.3) 570 0 R (subsubsection.6.4.1.4) 574 0 R (subsubsection.6.4.1.5) 578 0 R (table.1.1) 982 0 R (table.1.2) 992 0 R (table.3.1) 1051 0 R (table.3.2) 1088 0 R (table.6.1) 1208 0 R (table.6.10) 1608 0 R (table.6.11) 1610 0 R (table.6.12) 1620 0 R (table.6.13) 1623 0 R (table.6.14) 1630 0 R (table.6.15) 1633 0 R (table.6.16) 1636 0 R (table.6.17) 1643 0 R (table.6.18) 1659 0 R (table.6.19) 1666 0 R (table.6.2) 1231 0 R (table.6.20) 1675 0 R (table.6.21) 1684 0 R (table.6.22) 1692 0 R (table.6.23) 1699 0 R (table.6.3) 1239 0 R (table.6.4) 1278 0 R (table.6.5) 1290 0 R (table.6.6) 1343 0 R (table.6.7) 1438 0 R (table.6.8) 1521 0 R (table.6.9) 1594 0 R (the_category_phrase) 1272 0 R (the_sortlist_statement) 1428 0 R (topology) 1423 0 R (tsig) 1136 0 R (tuning) 1443 0 R (types_of_resource_records_and_when_to_use_them) 999 0 R (view_statement_grammar) 1458 0 R (zone_statement_grammar) 1377 0 R (zone_transfers) 1112 0 R (zonefile_format) 1450 0 R] /Limits [(Access_Control_Lists) (zonefile_format)] >> endobj 2292 0 obj << @@ -13080,7 +13080,7 @@ endobj >> endobj 2295 0 obj << /Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords() -/CreationDate (D:20091103215715Z) +/CreationDate (D:20091118003151Z) /PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4) >> endobj xref @@ -13091,728 +13091,728 @@ xref 0000000004 00000 f 0000000000 00000 f 0000000009 00000 n -0000073714 00000 n -0000809178 00000 n +0000073715 00000 n +0000809444 00000 n 0000000054 00000 n 0000000086 00000 n -0000073838 00000 n -0000809106 00000 n +0000073839 00000 n +0000809372 00000 n 0000000133 00000 n 0000000173 00000 n -0000073963 00000 n -0000809020 00000 n +0000073964 00000 n +0000809286 00000 n 0000000221 00000 n 0000000273 00000 n -0000074088 00000 n -0000808934 00000 n +0000074089 00000 n +0000809200 00000 n 0000000321 00000 n 0000000377 00000 n -0000078413 00000 n -0000808824 00000 n +0000078414 00000 n +0000809090 00000 n 0000000425 00000 n 0000000478 00000 n -0000078537 00000 n -0000808750 00000 n +0000078538 00000 n +0000809016 00000 n 0000000531 00000 n 0000000572 00000 n -0000078662 00000 n -0000808663 00000 n +0000078663 00000 n +0000808929 00000 n 0000000625 00000 n 0000000674 00000 n -0000078786 00000 n -0000808576 00000 n +0000078787 00000 n +0000808842 00000 n 0000000727 00000 n 0000000757 00000 n -0000083075 00000 n -0000808452 00000 n +0000083076 00000 n +0000808718 00000 n 0000000810 00000 n 0000000861 00000 n -0000083203 00000 n -0000808378 00000 n +0000083204 00000 n +0000808644 00000 n 0000000919 00000 n 0000000964 00000 n -0000083331 00000 n -0000808291 00000 n +0000083332 00000 n +0000808557 00000 n 0000001022 00000 n 0000001062 00000 n -0000083459 00000 n -0000808217 00000 n +0000083460 00000 n +0000808483 00000 n 0000001120 00000 n 0000001162 00000 n -0000086441 00000 n -0000808093 00000 n +0000086442 00000 n +0000808359 00000 n 0000001215 00000 n 0000001260 00000 n -0000086569 00000 n -0000808032 00000 n +0000086570 00000 n +0000808298 00000 n 0000001318 00000 n 0000001355 00000 n -0000086697 00000 n -0000807958 00000 n +0000086698 00000 n +0000808224 00000 n 0000001408 00000 n 0000001463 00000 n -0000089639 00000 n -0000807833 00000 n +0000089640 00000 n +0000808099 00000 n 0000001509 00000 n 0000001556 00000 n -0000089767 00000 n -0000807759 00000 n +0000089768 00000 n +0000808025 00000 n 0000001604 00000 n 0000001648 00000 n -0000089895 00000 n -0000807672 00000 n +0000089896 00000 n +0000807938 00000 n 0000001696 00000 n 0000001735 00000 n -0000090023 00000 n -0000807585 00000 n +0000090024 00000 n +0000807851 00000 n 0000001783 00000 n 0000001825 00000 n -0000090150 00000 n -0000807498 00000 n +0000090151 00000 n +0000807764 00000 n 0000001873 00000 n 0000001936 00000 n -0000091227 00000 n -0000807424 00000 n +0000091228 00000 n +0000807690 00000 n 0000001984 00000 n 0000002034 00000 n -0000092886 00000 n -0000807296 00000 n +0000092887 00000 n +0000807562 00000 n 0000002080 00000 n 0000002126 00000 n -0000093013 00000 n -0000807183 00000 n +0000093014 00000 n +0000807449 00000 n 0000002174 00000 n 0000002218 00000 n -0000093141 00000 n -0000807107 00000 n +0000093142 00000 n +0000807373 00000 n 0000002271 00000 n 0000002323 00000 n -0000093269 00000 n -0000807030 00000 n +0000093270 00000 n +0000807296 00000 n 0000002377 00000 n 0000002436 00000 n -0000095715 00000 n -0000806939 00000 n +0000095716 00000 n +0000807205 00000 n 0000002485 00000 n 0000002523 00000 n -0000099053 00000 n -0000806822 00000 n +0000099054 00000 n +0000807088 00000 n 0000002572 00000 n 0000002618 00000 n -0000099181 00000 n -0000806704 00000 n +0000099182 00000 n +0000806970 00000 n 0000002672 00000 n 0000002739 00000 n -0000099309 00000 n -0000806625 00000 n +0000099310 00000 n +0000806891 00000 n 0000002798 00000 n 0000002842 00000 n -0000099438 00000 n -0000806546 00000 n +0000099439 00000 n +0000806812 00000 n 0000002901 00000 n 0000002949 00000 n -0000111314 00000 n -0000806467 00000 n +0000111315 00000 n +0000806733 00000 n 0000003003 00000 n 0000003036 00000 n -0000116624 00000 n -0000806335 00000 n +0000116625 00000 n +0000806601 00000 n 0000003083 00000 n 0000003126 00000 n -0000116753 00000 n -0000806256 00000 n +0000116754 00000 n +0000806522 00000 n 0000003175 00000 n 0000003205 00000 n -0000116882 00000 n -0000806124 00000 n +0000116883 00000 n +0000806390 00000 n 0000003254 00000 n 0000003292 00000 n -0000117011 00000 n -0000806059 00000 n +0000117012 00000 n +0000806325 00000 n 0000003346 00000 n 0000003388 00000 n -0000121386 00000 n -0000805966 00000 n +0000121363 00000 n +0000806232 00000 n 0000003437 00000 n 0000003496 00000 n -0000121515 00000 n -0000805834 00000 n +0000121491 00000 n +0000806100 00000 n 0000003545 00000 n 0000003578 00000 n -0000121644 00000 n -0000805769 00000 n +0000125405 00000 n +0000806035 00000 n 0000003632 00000 n 0000003681 00000 n -0000128461 00000 n -0000805637 00000 n +0000128415 00000 n +0000805903 00000 n 0000003730 00000 n 0000003758 00000 n -0000131230 00000 n -0000805519 00000 n +0000131194 00000 n +0000805785 00000 n 0000003812 00000 n 0000003881 00000 n -0000131359 00000 n -0000805440 00000 n +0000131323 00000 n +0000805706 00000 n 0000003940 00000 n 0000003988 00000 n -0000131488 00000 n -0000805361 00000 n +0000131451 00000 n +0000805627 00000 n 0000004047 00000 n 0000004092 00000 n -0000131617 00000 n -0000805268 00000 n +0000131580 00000 n +0000805534 00000 n 0000004146 00000 n 0000004214 00000 n -0000131746 00000 n -0000805175 00000 n +0000131709 00000 n +0000805441 00000 n 0000004268 00000 n 0000004338 00000 n -0000131875 00000 n -0000805082 00000 n +0000135374 00000 n +0000805348 00000 n 0000004392 00000 n 0000004455 00000 n -0000135608 00000 n -0000804989 00000 n +0000135503 00000 n +0000805255 00000 n 0000004509 00000 n 0000004564 00000 n -0000135737 00000 n -0000804910 00000 n +0000135631 00000 n +0000805176 00000 n 0000004618 00000 n 0000004650 00000 n -0000135866 00000 n -0000804817 00000 n +0000135759 00000 n +0000805083 00000 n 0000004699 00000 n 0000004727 00000 n -0000139470 00000 n -0000804724 00000 n +0000139526 00000 n +0000804990 00000 n 0000004776 00000 n 0000004808 00000 n -0000139599 00000 n -0000804592 00000 n +0000139655 00000 n +0000804858 00000 n 0000004857 00000 n 0000004887 00000 n -0000139728 00000 n -0000804513 00000 n +0000139784 00000 n +0000804779 00000 n 0000004941 00000 n 0000004982 00000 n -0000143458 00000 n -0000804420 00000 n +0000143537 00000 n +0000804686 00000 n 0000005036 00000 n 0000005078 00000 n -0000143587 00000 n -0000804341 00000 n +0000143666 00000 n +0000804607 00000 n 0000005132 00000 n 0000005177 00000 n -0000149542 00000 n -0000804223 00000 n +0000149659 00000 n +0000804489 00000 n 0000005226 00000 n 0000005272 00000 n -0000149671 00000 n -0000804144 00000 n +0000149788 00000 n +0000804410 00000 n 0000005326 00000 n 0000005386 00000 n -0000149800 00000 n -0000804065 00000 n +0000149917 00000 n +0000804331 00000 n 0000005440 00000 n 0000005509 00000 n -0000152984 00000 n -0000803932 00000 n +0000153167 00000 n +0000804198 00000 n 0000005556 00000 n 0000005609 00000 n -0000153113 00000 n -0000803853 00000 n +0000153296 00000 n +0000804119 00000 n 0000005658 00000 n 0000005714 00000 n -0000153242 00000 n -0000803774 00000 n +0000153425 00000 n +0000804040 00000 n 0000005763 00000 n 0000005812 00000 n -0000157511 00000 n -0000803641 00000 n +0000157694 00000 n +0000803907 00000 n 0000005859 00000 n 0000005911 00000 n -0000157640 00000 n -0000803523 00000 n +0000157823 00000 n +0000803789 00000 n 0000005960 00000 n 0000006011 00000 n -0000162330 00000 n -0000803405 00000 n +0000162513 00000 n +0000803671 00000 n 0000006065 00000 n 0000006110 00000 n -0000162458 00000 n -0000803326 00000 n +0000162641 00000 n +0000803592 00000 n 0000006169 00000 n 0000006203 00000 n -0000166048 00000 n -0000803247 00000 n +0000166231 00000 n +0000803513 00000 n 0000006262 00000 n 0000006310 00000 n -0000166177 00000 n -0000803129 00000 n +0000166360 00000 n +0000803395 00000 n 0000006364 00000 n 0000006404 00000 n -0000166306 00000 n -0000803050 00000 n +0000166489 00000 n +0000803316 00000 n 0000006463 00000 n 0000006497 00000 n -0000170082 00000 n -0000802971 00000 n +0000170265 00000 n +0000803237 00000 n 0000006556 00000 n 0000006604 00000 n -0000170211 00000 n -0000802838 00000 n +0000170394 00000 n +0000803104 00000 n 0000006653 00000 n 0000006703 00000 n -0000173279 00000 n -0000802759 00000 n +0000173462 00000 n +0000803025 00000 n 0000006757 00000 n 0000006804 00000 n -0000173407 00000 n -0000802666 00000 n +0000173590 00000 n +0000802932 00000 n 0000006858 00000 n 0000006918 00000 n -0000173666 00000 n -0000802573 00000 n +0000173849 00000 n +0000802839 00000 n 0000006972 00000 n 0000007024 00000 n -0000178846 00000 n -0000802480 00000 n +0000179029 00000 n +0000802746 00000 n 0000007078 00000 n 0000007143 00000 n -0000178975 00000 n -0000802387 00000 n +0000179158 00000 n +0000802653 00000 n 0000007197 00000 n 0000007248 00000 n -0000182449 00000 n -0000802294 00000 n +0000182632 00000 n +0000802560 00000 n 0000007302 00000 n 0000007366 00000 n -0000182578 00000 n -0000802201 00000 n +0000182761 00000 n +0000802467 00000 n 0000007420 00000 n 0000007467 00000 n -0000182707 00000 n -0000802108 00000 n +0000182890 00000 n +0000802374 00000 n 0000007521 00000 n 0000007581 00000 n -0000182836 00000 n -0000802015 00000 n +0000183019 00000 n +0000802281 00000 n 0000007635 00000 n 0000007686 00000 n -0000186852 00000 n -0000801883 00000 n +0000187035 00000 n +0000802149 00000 n 0000007741 00000 n 0000007806 00000 n -0000186981 00000 n -0000801804 00000 n +0000187164 00000 n +0000802070 00000 n 0000007866 00000 n 0000007913 00000 n -0000193797 00000 n -0000801711 00000 n +0000193980 00000 n +0000801977 00000 n 0000007973 00000 n 0000008021 00000 n -0000200198 00000 n -0000801632 00000 n +0000200381 00000 n +0000801898 00000 n 0000008081 00000 n 0000008135 00000 n -0000203284 00000 n -0000801539 00000 n +0000203467 00000 n +0000801805 00000 n 0000008190 00000 n 0000008240 00000 n -0000206134 00000 n -0000801446 00000 n +0000206317 00000 n +0000801712 00000 n 0000008295 00000 n 0000008358 00000 n -0000206263 00000 n -0000801353 00000 n +0000206446 00000 n +0000801619 00000 n 0000008413 00000 n 0000008465 00000 n -0000206391 00000 n -0000801260 00000 n +0000206574 00000 n +0000801526 00000 n 0000008520 00000 n 0000008585 00000 n -0000206519 00000 n -0000801167 00000 n +0000206702 00000 n +0000801433 00000 n 0000008640 00000 n 0000008692 00000 n -0000212092 00000 n -0000801034 00000 n +0000212359 00000 n +0000801300 00000 n 0000008747 00000 n 0000008812 00000 n -0000228344 00000 n -0000800955 00000 n +0000228666 00000 n +0000801221 00000 n 0000008872 00000 n 0000008916 00000 n -0000249840 00000 n -0000800862 00000 n +0000250257 00000 n +0000801128 00000 n 0000008976 00000 n 0000009015 00000 n -0000249969 00000 n -0000800769 00000 n +0000250386 00000 n +0000801035 00000 n 0000009075 00000 n 0000009122 00000 n -0000250097 00000 n -0000800676 00000 n +0000250515 00000 n +0000800942 00000 n 0000009182 00000 n 0000009225 00000 n -0000257289 00000 n -0000800583 00000 n +0000257595 00000 n +0000800849 00000 n 0000009285 00000 n 0000009324 00000 n -0000261042 00000 n -0000800490 00000 n +0000261314 00000 n +0000800756 00000 n 0000009384 00000 n 0000009426 00000 n -0000264019 00000 n -0000800397 00000 n +0000264291 00000 n +0000800663 00000 n 0000009486 00000 n 0000009529 00000 n -0000271609 00000 n -0000800304 00000 n +0000271881 00000 n +0000800570 00000 n 0000009589 00000 n 0000009632 00000 n -0000275993 00000 n -0000800211 00000 n +0000276265 00000 n +0000800477 00000 n 0000009692 00000 n 0000009753 00000 n -0000276122 00000 n -0000800118 00000 n +0000276394 00000 n +0000800384 00000 n 0000009814 00000 n 0000009866 00000 n -0000279923 00000 n -0000800025 00000 n +0000280195 00000 n +0000800291 00000 n 0000009927 00000 n 0000009980 00000 n -0000280051 00000 n -0000799932 00000 n +0000280323 00000 n +0000800198 00000 n 0000010041 00000 n 0000010079 00000 n -0000284136 00000 n -0000799839 00000 n +0000284408 00000 n +0000800105 00000 n 0000010140 00000 n 0000010192 00000 n -0000287127 00000 n -0000799746 00000 n +0000287399 00000 n +0000800012 00000 n 0000010253 00000 n 0000010297 00000 n -0000290947 00000 n -0000799653 00000 n +0000291219 00000 n +0000799919 00000 n 0000010358 00000 n 0000010394 00000 n -0000299584 00000 n -0000799560 00000 n +0000299856 00000 n +0000799826 00000 n 0000010455 00000 n 0000010518 00000 n -0000299713 00000 n -0000799467 00000 n +0000299985 00000 n +0000799733 00000 n 0000010579 00000 n 0000010629 00000 n -0000302914 00000 n -0000799374 00000 n +0000303186 00000 n +0000799640 00000 n 0000010690 00000 n 0000010746 00000 n -0000307356 00000 n -0000799295 00000 n +0000307628 00000 n +0000799561 00000 n 0000010807 00000 n 0000010854 00000 n -0000310690 00000 n -0000799202 00000 n +0000310962 00000 n +0000799468 00000 n 0000010909 00000 n 0000010960 00000 n -0000315319 00000 n -0000799109 00000 n +0000315596 00000 n +0000799375 00000 n 0000011015 00000 n 0000011079 00000 n -0000319284 00000 n -0000799016 00000 n +0000319561 00000 n +0000799282 00000 n 0000011134 00000 n 0000011198 00000 n -0000319413 00000 n -0000798923 00000 n +0000319690 00000 n +0000799189 00000 n 0000011253 00000 n 0000011330 00000 n -0000319542 00000 n -0000798830 00000 n +0000319819 00000 n +0000799096 00000 n 0000011385 00000 n 0000011442 00000 n -0000319671 00000 n -0000798737 00000 n +0000319948 00000 n +0000799003 00000 n 0000011497 00000 n 0000011567 00000 n -0000323695 00000 n -0000798644 00000 n +0000323972 00000 n +0000798910 00000 n 0000011622 00000 n 0000011679 00000 n -0000323824 00000 n -0000798551 00000 n +0000324101 00000 n +0000798817 00000 n 0000011734 00000 n 0000011804 00000 n -0000328095 00000 n -0000798458 00000 n +0000328372 00000 n +0000798724 00000 n 0000011859 00000 n 0000011908 00000 n -0000328223 00000 n -0000798365 00000 n +0000328500 00000 n +0000798631 00000 n 0000011963 00000 n 0000012025 00000 n -0000330105 00000 n -0000798272 00000 n +0000330382 00000 n +0000798538 00000 n 0000012080 00000 n 0000012129 00000 n -0000335499 00000 n -0000798154 00000 n +0000335776 00000 n +0000798420 00000 n 0000012184 00000 n 0000012246 00000 n -0000335628 00000 n -0000798075 00000 n +0000335905 00000 n +0000798341 00000 n 0000012306 00000 n 0000012345 00000 n -0000339954 00000 n -0000797982 00000 n +0000340231 00000 n +0000798248 00000 n 0000012405 00000 n 0000012439 00000 n -0000345857 00000 n -0000797889 00000 n +0000346134 00000 n +0000798155 00000 n 0000012499 00000 n 0000012540 00000 n -0000361728 00000 n -0000797810 00000 n +0000362005 00000 n +0000798076 00000 n 0000012600 00000 n 0000012652 00000 n -0000369044 00000 n -0000797678 00000 n +0000369321 00000 n +0000797944 00000 n 0000012701 00000 n 0000012734 00000 n -0000369173 00000 n -0000797560 00000 n +0000369450 00000 n +0000797826 00000 n 0000012788 00000 n 0000012860 00000 n -0000369301 00000 n -0000797481 00000 n +0000369578 00000 n +0000797747 00000 n 0000012919 00000 n 0000012963 00000 n -0000376715 00000 n -0000797402 00000 n +0000376992 00000 n +0000797668 00000 n 0000013022 00000 n 0000013075 00000 n -0000380480 00000 n -0000797309 00000 n +0000380757 00000 n +0000797575 00000 n 0000013129 00000 n 0000013179 00000 n -0000380738 00000 n -0000797216 00000 n +0000381015 00000 n +0000797482 00000 n 0000013233 00000 n 0000013271 00000 n -0000384189 00000 n -0000797123 00000 n +0000384466 00000 n +0000797389 00000 n 0000013325 00000 n 0000013374 00000 n -0000384447 00000 n -0000796991 00000 n +0000384724 00000 n +0000797257 00000 n 0000013428 00000 n 0000013480 00000 n -0000384575 00000 n -0000796912 00000 n +0000384852 00000 n +0000797178 00000 n 0000013539 00000 n 0000013584 00000 n -0000384704 00000 n -0000796819 00000 n +0000384981 00000 n +0000797085 00000 n 0000013643 00000 n 0000013695 00000 n -0000387323 00000 n -0000796726 00000 n +0000387600 00000 n +0000796992 00000 n 0000013754 00000 n 0000013807 00000 n -0000387452 00000 n -0000796647 00000 n +0000387729 00000 n +0000796913 00000 n 0000013866 00000 n 0000013915 00000 n -0000387581 00000 n -0000796554 00000 n +0000387858 00000 n +0000796820 00000 n 0000013969 00000 n 0000014049 00000 n -0000394680 00000 n -0000796475 00000 n +0000394957 00000 n +0000796741 00000 n 0000014103 00000 n 0000014152 00000 n -0000394809 00000 n -0000796357 00000 n +0000395086 00000 n +0000796623 00000 n 0000014201 00000 n 0000014241 00000 n -0000398249 00000 n -0000796278 00000 n +0000398526 00000 n +0000796544 00000 n 0000014300 00000 n 0000014347 00000 n -0000398378 00000 n -0000796160 00000 n +0000398655 00000 n +0000796426 00000 n 0000014401 00000 n 0000014446 00000 n -0000398507 00000 n -0000796081 00000 n +0000398784 00000 n +0000796347 00000 n 0000014505 00000 n 0000014564 00000 n -0000402263 00000 n -0000795988 00000 n +0000402540 00000 n +0000796254 00000 n 0000014623 00000 n 0000014687 00000 n -0000405983 00000 n -0000795895 00000 n +0000406260 00000 n +0000796161 00000 n 0000014746 00000 n 0000014802 00000 n -0000409000 00000 n -0000795802 00000 n +0000409277 00000 n +0000796068 00000 n 0000014861 00000 n 0000014919 00000 n -0000409258 00000 n -0000795723 00000 n +0000409535 00000 n +0000795989 00000 n 0000014978 00000 n 0000015040 00000 n -0000411037 00000 n -0000795590 00000 n +0000411314 00000 n +0000795856 00000 n 0000015087 00000 n 0000015139 00000 n -0000411166 00000 n -0000795511 00000 n +0000411443 00000 n +0000795777 00000 n 0000015188 00000 n 0000015232 00000 n -0000415200 00000 n -0000795379 00000 n +0000415477 00000 n +0000795645 00000 n 0000015281 00000 n 0000015322 00000 n -0000415329 00000 n -0000795300 00000 n +0000415606 00000 n +0000795566 00000 n 0000015376 00000 n 0000015424 00000 n -0000415457 00000 n -0000795221 00000 n +0000415734 00000 n +0000795487 00000 n 0000015478 00000 n 0000015529 00000 n -0000415586 00000 n -0000795142 00000 n +0000415863 00000 n +0000795408 00000 n 0000015578 00000 n 0000015625 00000 n -0000420180 00000 n -0000795009 00000 n +0000420457 00000 n +0000795275 00000 n 0000015672 00000 n 0000015709 00000 n -0000420309 00000 n -0000794891 00000 n +0000420586 00000 n +0000795157 00000 n 0000015758 00000 n 0000015797 00000 n -0000420438 00000 n -0000794826 00000 n +0000420715 00000 n +0000795092 00000 n 0000015851 00000 n 0000015929 00000 n -0000420567 00000 n -0000794733 00000 n +0000420844 00000 n +0000794999 00000 n 0000015978 00000 n 0000016045 00000 n -0000420696 00000 n -0000794654 00000 n +0000420973 00000 n +0000794920 00000 n 0000016094 00000 n 0000016139 00000 n -0000424136 00000 n -0000794521 00000 n +0000424413 00000 n +0000794787 00000 n 0000016187 00000 n 0000016219 00000 n -0000424265 00000 n -0000794403 00000 n +0000424542 00000 n +0000794669 00000 n 0000016268 00000 n 0000016307 00000 n -0000424394 00000 n -0000794338 00000 n +0000424671 00000 n +0000794604 00000 n 0000016361 00000 n 0000016422 00000 n -0000428075 00000 n -0000794206 00000 n +0000428352 00000 n +0000794472 00000 n 0000016471 00000 n 0000016528 00000 n -0000428204 00000 n -0000794141 00000 n +0000428481 00000 n +0000794407 00000 n 0000016582 00000 n 0000016631 00000 n -0000428333 00000 n -0000794023 00000 n +0000428610 00000 n +0000794289 00000 n 0000016680 00000 n 0000016742 00000 n -0000428462 00000 n -0000793944 00000 n +0000428739 00000 n +0000794210 00000 n 0000016796 00000 n 0000016851 00000 n -0000452485 00000 n -0000793851 00000 n +0000452762 00000 n +0000794117 00000 n 0000016905 00000 n 0000016946 00000 n -0000452614 00000 n -0000793772 00000 n +0000452891 00000 n +0000794038 00000 n 0000017000 00000 n 0000017052 00000 n -0000455345 00000 n -0000793652 00000 n +0000455622 00000 n +0000793918 00000 n 0000017100 00000 n 0000017134 00000 n -0000455474 00000 n -0000793573 00000 n +0000455751 00000 n +0000793839 00000 n 0000017183 00000 n 0000017210 00000 n -0000473296 00000 n -0000793480 00000 n +0000473573 00000 n +0000793746 00000 n 0000017259 00000 n 0000017287 00000 n -0000480830 00000 n -0000793387 00000 n +0000481107 00000 n +0000793653 00000 n 0000017336 00000 n 0000017376 00000 n -0000487076 00000 n -0000793294 00000 n +0000487353 00000 n +0000793560 00000 n 0000017425 00000 n 0000017468 00000 n -0000493566 00000 n -0000793201 00000 n +0000493843 00000 n +0000793467 00000 n 0000017517 00000 n 0000017554 00000 n -0000506229 00000 n -0000793108 00000 n +0000506506 00000 n +0000793374 00000 n 0000017603 00000 n 0000017640 00000 n -0000509732 00000 n -0000793015 00000 n +0000510009 00000 n +0000793281 00000 n 0000017689 00000 n 0000017727 00000 n -0000512985 00000 n -0000792922 00000 n +0000513262 00000 n +0000793188 00000 n 0000017776 00000 n 0000017815 00000 n -0000526466 00000 n -0000792829 00000 n +0000526743 00000 n +0000793095 00000 n 0000017864 00000 n 0000017903 00000 n -0000529189 00000 n -0000792736 00000 n +0000529447 00000 n +0000793002 00000 n 0000017953 00000 n 0000017993 00000 n -0000538881 00000 n -0000792643 00000 n +0000539146 00000 n +0000792909 00000 n 0000018043 00000 n 0000018073 00000 n -0000548616 00000 n -0000792550 00000 n +0000548881 00000 n +0000792816 00000 n 0000018123 00000 n 0000018156 00000 n -0000563020 00000 n -0000792457 00000 n +0000563285 00000 n +0000792723 00000 n 0000018206 00000 n 0000018235 00000 n -0000566247 00000 n -0000792364 00000 n +0000566512 00000 n +0000792630 00000 n 0000018285 00000 n 0000018319 00000 n -0000572155 00000 n -0000792271 00000 n +0000572420 00000 n +0000792537 00000 n 0000018369 00000 n 0000018406 00000 n -0000578906 00000 n -0000792192 00000 n +0000579171 00000 n +0000792458 00000 n 0000018456 00000 n 0000018493 00000 n 0000018862 00000 n @@ -13821,10 +13821,10 @@ xref 0000018546 00000 n 0000026687 00000 n 0000026750 00000 n -0000787203 00000 n -0000761260 00000 n -0000787029 00000 n -0000788228 00000 n +0000787469 00000 n +0000761526 00000 n +0000787295 00000 n +0000788494 00000 n 0000021847 00000 n 0000022064 00000 n 0000022133 00000 n @@ -13845,1549 +13845,1549 @@ xref 0000027992 00000 n 0000026913 00000 n 0000028114 00000 n -0000760039 00000 n -0000733518 00000 n -0000759865 00000 n -0000732833 00000 n -0000730689 00000 n -0000732669 00000 n -0000039881 00000 n -0000031232 00000 n +0000760305 00000 n +0000733784 00000 n +0000760131 00000 n +0000733099 00000 n +0000730954 00000 n +0000732935 00000 n +0000039882 00000 n +0000031234 00000 n 0000028262 00000 n -0000039755 00000 n -0000039818 00000 n -0000031766 00000 n -0000031920 00000 n -0000032077 00000 n -0000032234 00000 n -0000032390 00000 n -0000032547 00000 n -0000032709 00000 n -0000032870 00000 n -0000033031 00000 n -0000033193 00000 n -0000033360 00000 n -0000033527 00000 n -0000033692 00000 n -0000033854 00000 n -0000034020 00000 n -0000034181 00000 n -0000034336 00000 n -0000034493 00000 n -0000034649 00000 n -0000034806 00000 n -0000034963 00000 n -0000035120 00000 n -0000035274 00000 n -0000035430 00000 n -0000035592 00000 n -0000035754 00000 n -0000035910 00000 n -0000036065 00000 n -0000036227 00000 n -0000036394 00000 n -0000036560 00000 n -0000036721 00000 n -0000036876 00000 n -0000037033 00000 n -0000037190 00000 n -0000037352 00000 n -0000037509 00000 n -0000037666 00000 n -0000037828 00000 n -0000037985 00000 n -0000038147 00000 n -0000038314 00000 n -0000038480 00000 n -0000038642 00000 n -0000038804 00000 n -0000038966 00000 n -0000039128 00000 n -0000039290 00000 n -0000039445 00000 n -0000039600 00000 n -0000053268 00000 n -0000043217 00000 n -0000039966 00000 n -0000053205 00000 n -0000730138 00000 n -0000713057 00000 n -0000729954 00000 n -0000043807 00000 n -0000043970 00000 n -0000044133 00000 n -0000044296 00000 n -0000044454 00000 n -0000044617 00000 n -0000044780 00000 n -0000044935 00000 n -0000045093 00000 n -0000045251 00000 n -0000045407 00000 n -0000045565 00000 n -0000045728 00000 n -0000045896 00000 n -0000046064 00000 n -0000046227 00000 n -0000046395 00000 n -0000046563 00000 n -0000046720 00000 n -0000046883 00000 n -0000047046 00000 n -0000047208 00000 n -0000047370 00000 n -0000047533 00000 n -0000047695 00000 n -0000047857 00000 n -0000048020 00000 n -0000048183 00000 n -0000048346 00000 n -0000048514 00000 n -0000048683 00000 n -0000048852 00000 n -0000049015 00000 n -0000049179 00000 n -0000049343 00000 n -0000049506 00000 n -0000049670 00000 n -0000049834 00000 n -0000050003 00000 n -0000050172 00000 n -0000050341 00000 n -0000050510 00000 n -0000050679 00000 n -0000050848 00000 n -0000051017 00000 n -0000051186 00000 n -0000051355 00000 n -0000051525 00000 n -0000051695 00000 n -0000051864 00000 n -0000052034 00000 n -0000052204 00000 n -0000052372 00000 n -0000052542 00000 n -0000052710 00000 n -0000052877 00000 n -0000053044 00000 n -0000066633 00000 n -0000056922 00000 n -0000053366 00000 n -0000066570 00000 n -0000057504 00000 n -0000057667 00000 n -0000057830 00000 n -0000057993 00000 n -0000058156 00000 n -0000058318 00000 n -0000058480 00000 n -0000058642 00000 n -0000058804 00000 n -0000058966 00000 n -0000059128 00000 n -0000059290 00000 n -0000059457 00000 n -0000059624 00000 n -0000059792 00000 n -0000059959 00000 n -0000060116 00000 n -0000060278 00000 n -0000060445 00000 n -0000060612 00000 n -0000060774 00000 n -0000060936 00000 n -0000061098 00000 n -0000061260 00000 n -0000061427 00000 n -0000061594 00000 n -0000061761 00000 n -0000061928 00000 n -0000062090 00000 n -0000062252 00000 n -0000062409 00000 n -0000062576 00000 n -0000062738 00000 n -0000062905 00000 n -0000063072 00000 n -0000063238 00000 n -0000712168 00000 n -0000690837 00000 n -0000711994 00000 n -0000063404 00000 n -0000063570 00000 n -0000063725 00000 n -0000063881 00000 n -0000064038 00000 n -0000064200 00000 n -0000064362 00000 n -0000064519 00000 n -0000064674 00000 n -0000064831 00000 n -0000064993 00000 n -0000065150 00000 n -0000065307 00000 n -0000065462 00000 n -0000065618 00000 n -0000065779 00000 n -0000065935 00000 n -0000066096 00000 n -0000066251 00000 n -0000066411 00000 n -0000071163 00000 n -0000067987 00000 n -0000066744 00000 n -0000071100 00000 n -0000068265 00000 n -0000068427 00000 n -0000068582 00000 n -0000068739 00000 n -0000068896 00000 n -0000069053 00000 n -0000069210 00000 n -0000069367 00000 n -0000069524 00000 n -0000069681 00000 n -0000069838 00000 n -0000069995 00000 n -0000070153 00000 n -0000070310 00000 n -0000070468 00000 n -0000689871 00000 n -0000669904 00000 n -0000689698 00000 n -0000070626 00000 n -0000070784 00000 n -0000070942 00000 n -0000074339 00000 n -0000073529 00000 n -0000071274 00000 n -0000073651 00000 n -0000073775 00000 n -0000073900 00000 n -0000074025 00000 n -0000074150 00000 n -0000074213 00000 n -0000074276 00000 n -0000669110 00000 n -0000650793 00000 n -0000668937 00000 n -0000788346 00000 n -0000078910 00000 n -0000077730 00000 n -0000074463 00000 n -0000078224 00000 n -0000078287 00000 n -0000078350 00000 n -0000078474 00000 n -0000078599 00000 n -0000078724 00000 n -0000077880 00000 n -0000078073 00000 n -0000078847 00000 n -0000369237 00000 n -0000428526 00000 n -0000083587 00000 n -0000082530 00000 n -0000079034 00000 n -0000083010 00000 n -0000083138 00000 n -0000082685 00000 n -0000082848 00000 n -0000083266 00000 n -0000083394 00000 n -0000083522 00000 n -0000099373 00000 n -0000086825 00000 n -0000086251 00000 n -0000083712 00000 n -0000086376 00000 n -0000086504 00000 n -0000086632 00000 n -0000086760 00000 n -0000090278 00000 n -0000089113 00000 n -0000086937 00000 n -0000089574 00000 n -0000089702 00000 n -0000089830 00000 n -0000089958 00000 n -0000090086 00000 n -0000089268 00000 n -0000089421 00000 n -0000090213 00000 n -0000302977 00000 n -0000091355 00000 n -0000091037 00000 n -0000090364 00000 n -0000091162 00000 n -0000091290 00000 n -0000093398 00000 n -0000092695 00000 n -0000091454 00000 n -0000092821 00000 n -0000092949 00000 n -0000093076 00000 n -0000093204 00000 n -0000093333 00000 n -0000788468 00000 n -0000095974 00000 n -0000095344 00000 n -0000093497 00000 n -0000095650 00000 n -0000095779 00000 n -0000095844 00000 n -0000095909 00000 n -0000095491 00000 n -0000287190 00000 n -0000099567 00000 n -0000098862 00000 n -0000096086 00000 n -0000098988 00000 n -0000099117 00000 n -0000099244 00000 n -0000650110 00000 n -0000638048 00000 n -0000649931 00000 n -0000099502 00000 n -0000103686 00000 n -0000102960 00000 n -0000099693 00000 n -0000103621 00000 n -0000637475 00000 n -0000626492 00000 n -0000637296 00000 n -0000103125 00000 n -0000103279 00000 n -0000103450 00000 n -0000212156 00000 n -0000361792 00000 n -0000107856 00000 n -0000107457 00000 n -0000103852 00000 n -0000107791 00000 n -0000107604 00000 n -0000178910 00000 n -0000111573 00000 n -0000111123 00000 n -0000107995 00000 n -0000111249 00000 n -0000111378 00000 n -0000111443 00000 n -0000111508 00000 n -0000114421 00000 n -0000117139 00000 n -0000114256 00000 n -0000111698 00000 n -0000116559 00000 n -0000116688 00000 n -0000116817 00000 n -0000116064 00000 n -0000116226 00000 n -0000625594 00000 n -0000615798 00000 n -0000625420 00000 n -0000615234 00000 n -0000606148 00000 n -0000615059 00000 n -0000116946 00000 n -0000116388 00000 n -0000117075 00000 n -0000788593 00000 n -0000115893 00000 n -0000115951 00000 n -0000116041 00000 n -0000228408 00000 n -0000264083 00000 n -0000121771 00000 n -0000120837 00000 n -0000117308 00000 n -0000121321 00000 n -0000121450 00000 n -0000120993 00000 n -0000121159 00000 n -0000121579 00000 n -0000121707 00000 n -0000432554 00000 n -0000125430 00000 n -0000125050 00000 n -0000121923 00000 n -0000125365 00000 n -0000125197 00000 n -0000126603 00000 n -0000126412 00000 n -0000125555 00000 n -0000126538 00000 n -0000128590 00000 n -0000128270 00000 n -0000126702 00000 n -0000128396 00000 n -0000128525 00000 n -0000132003 00000 n -0000131039 00000 n -0000128702 00000 n -0000131165 00000 n -0000131294 00000 n -0000131423 00000 n -0000131552 00000 n -0000131681 00000 n -0000131810 00000 n -0000131939 00000 n -0000135994 00000 n -0000135225 00000 n -0000132141 00000 n -0000135543 00000 n -0000135672 00000 n -0000135372 00000 n -0000135801 00000 n -0000135930 00000 n -0000788718 00000 n -0000139857 00000 n -0000139279 00000 n -0000136132 00000 n -0000139405 00000 n -0000139534 00000 n -0000139663 00000 n -0000139792 00000 n -0000143716 00000 n -0000143267 00000 n -0000139995 00000 n -0000143393 00000 n -0000143522 00000 n -0000143651 00000 n -0000146110 00000 n -0000145919 00000 n -0000143841 00000 n -0000146045 00000 n -0000149929 00000 n -0000149169 00000 n -0000146252 00000 n -0000149477 00000 n -0000605873 00000 n -0000602514 00000 n -0000605694 00000 n -0000149606 00000 n -0000149316 00000 n -0000149735 00000 n -0000149864 00000 n -0000428268 00000 n -0000150700 00000 n -0000150509 00000 n -0000150111 00000 n -0000150635 00000 n -0000153371 00000 n -0000152793 00000 n -0000150799 00000 n -0000152919 00000 n -0000153048 00000 n -0000153177 00000 n -0000153306 00000 n -0000788843 00000 n -0000153811 00000 n -0000153620 00000 n -0000153470 00000 n -0000153746 00000 n -0000157898 00000 n -0000157132 00000 n -0000153853 00000 n -0000157446 00000 n -0000157575 00000 n -0000157703 00000 n -0000157768 00000 n -0000157833 00000 n -0000157279 00000 n -0000162394 00000 n -0000162586 00000 n -0000162139 00000 n -0000157997 00000 n -0000162265 00000 n -0000162521 00000 n -0000166435 00000 n -0000165857 00000 n -0000162711 00000 n -0000165983 00000 n -0000166112 00000 n -0000166241 00000 n -0000166370 00000 n -0000169091 00000 n -0000170469 00000 n -0000168965 00000 n -0000166573 00000 n -0000170017 00000 n -0000170146 00000 n -0000170275 00000 n -0000170340 00000 n -0000170404 00000 n -0000173792 00000 n -0000173088 00000 n -0000170624 00000 n -0000173214 00000 n -0000173343 00000 n -0000173471 00000 n -0000173536 00000 n -0000173601 00000 n -0000173727 00000 n -0000788968 00000 n -0000179103 00000 n -0000178315 00000 n -0000173904 00000 n -0000178781 00000 n -0000178471 00000 n -0000178622 00000 n -0000179039 00000 n -0000581140 00000 n -0000182965 00000 n -0000181694 00000 n -0000179241 00000 n -0000182384 00000 n -0000182513 00000 n -0000182642 00000 n -0000182771 00000 n -0000181859 00000 n -0000182011 00000 n -0000182197 00000 n -0000182900 00000 n -0000187110 00000 n -0000186661 00000 n -0000183091 00000 n -0000186787 00000 n -0000186916 00000 n -0000187045 00000 n -0000191013 00000 n -0000190634 00000 n -0000187235 00000 n -0000190948 00000 n -0000190781 00000 n -0000193861 00000 n -0000194056 00000 n -0000193606 00000 n -0000191125 00000 n -0000193732 00000 n -0000193926 00000 n -0000193991 00000 n -0000196858 00000 n -0000196667 00000 n -0000194168 00000 n -0000196793 00000 n -0000789093 00000 n -0000200456 00000 n -0000200007 00000 n -0000196970 00000 n -0000200133 00000 n -0000200262 00000 n -0000200327 00000 n -0000200391 00000 n -0000203412 00000 n -0000203093 00000 n -0000200568 00000 n -0000203219 00000 n -0000203347 00000 n -0000206648 00000 n -0000205608 00000 n -0000203524 00000 n -0000206069 00000 n -0000206198 00000 n -0000205764 00000 n -0000205918 00000 n -0000206326 00000 n -0000206454 00000 n -0000206583 00000 n -0000208189 00000 n -0000207998 00000 n -0000206760 00000 n -0000208124 00000 n -0000209711 00000 n -0000209520 00000 n -0000208288 00000 n -0000209646 00000 n -0000212221 00000 n -0000211901 00000 n -0000209810 00000 n -0000212027 00000 n -0000789218 00000 n -0000216037 00000 n -0000215846 00000 n -0000212347 00000 n -0000215972 00000 n -0000220376 00000 n -0000219828 00000 n -0000216175 00000 n -0000220311 00000 n -0000219984 00000 n -0000220141 00000 n -0000398313 00000 n -0000224420 00000 n -0000224055 00000 n -0000220501 00000 n -0000224355 00000 n -0000602159 00000 n -0000600161 00000 n -0000601994 00000 n -0000224202 00000 n -0000228603 00000 n -0000228153 00000 n -0000224559 00000 n -0000228279 00000 n -0000228473 00000 n -0000228538 00000 n -0000232815 00000 n -0000232449 00000 n -0000228715 00000 n -0000232750 00000 n -0000232596 00000 n -0000238081 00000 n -0000236948 00000 n -0000232940 00000 n -0000238016 00000 n -0000237131 00000 n -0000237288 00000 n -0000237473 00000 n -0000237647 00000 n -0000237832 00000 n -0000789343 00000 n -0000315383 00000 n -0000241969 00000 n -0000241778 00000 n -0000238275 00000 n -0000241904 00000 n -0000245874 00000 n -0000245683 00000 n -0000242081 00000 n -0000245809 00000 n -0000250225 00000 n -0000249284 00000 n -0000245999 00000 n -0000249775 00000 n -0000249904 00000 n -0000249440 00000 n -0000250033 00000 n -0000250161 00000 n -0000249610 00000 n -0000330169 00000 n -0000253476 00000 n -0000253096 00000 n -0000250337 00000 n -0000253411 00000 n -0000253243 00000 n -0000415650 00000 n -0000257417 00000 n -0000256906 00000 n -0000253632 00000 n -0000257224 00000 n -0000257053 00000 n -0000257352 00000 n -0000261171 00000 n -0000260851 00000 n -0000257542 00000 n -0000260977 00000 n -0000261106 00000 n -0000789468 00000 n -0000264148 00000 n -0000263828 00000 n -0000261283 00000 n -0000263954 00000 n -0000268201 00000 n -0000268010 00000 n -0000264304 00000 n -0000268136 00000 n -0000271738 00000 n -0000271237 00000 n -0000268356 00000 n -0000271544 00000 n -0000271673 00000 n -0000271384 00000 n -0000276249 00000 n -0000275442 00000 n -0000271907 00000 n -0000275928 00000 n -0000276057 00000 n -0000275598 00000 n -0000276185 00000 n -0000275773 00000 n -0000280180 00000 n -0000279732 00000 n -0000276361 00000 n -0000279858 00000 n -0000279987 00000 n -0000280115 00000 n -0000284265 00000 n -0000283597 00000 n -0000280335 00000 n -0000284071 00000 n -0000284200 00000 n -0000283753 00000 n -0000283915 00000 n -0000789593 00000 n -0000287384 00000 n -0000286745 00000 n -0000284434 00000 n -0000287062 00000 n -0000286892 00000 n -0000287255 00000 n -0000287319 00000 n -0000291075 00000 n -0000290573 00000 n -0000287510 00000 n -0000290882 00000 n -0000291011 00000 n -0000290720 00000 n -0000295558 00000 n -0000295183 00000 n -0000291257 00000 n -0000295493 00000 n -0000295330 00000 n -0000394744 00000 n -0000299842 00000 n -0000299203 00000 n -0000295684 00000 n -0000299519 00000 n -0000299648 00000 n -0000299350 00000 n -0000299777 00000 n -0000328159 00000 n -0000303042 00000 n -0000302723 00000 n -0000299967 00000 n -0000302849 00000 n -0000307485 00000 n -0000307165 00000 n -0000303210 00000 n -0000307291 00000 n -0000307420 00000 n -0000789718 00000 n -0000310819 00000 n -0000310327 00000 n -0000307597 00000 n -0000310625 00000 n -0000310474 00000 n -0000310754 00000 n -0000315448 00000 n -0000314956 00000 n -0000310945 00000 n -0000315254 00000 n -0000315103 00000 n -0000319799 00000 n -0000318751 00000 n -0000315560 00000 n -0000319219 00000 n -0000318907 00000 n -0000319348 00000 n -0000319477 00000 n -0000319606 00000 n -0000319735 00000 n -0000319067 00000 n -0000323953 00000 n -0000323504 00000 n -0000319911 00000 n -0000323630 00000 n -0000323759 00000 n -0000323888 00000 n -0000328352 00000 n -0000327904 00000 n -0000324078 00000 n -0000328030 00000 n -0000328287 00000 n -0000330234 00000 n -0000329914 00000 n -0000328490 00000 n -0000330040 00000 n -0000789843 00000 n -0000331762 00000 n -0000331571 00000 n -0000330346 00000 n -0000331697 00000 n -0000333222 00000 n -0000333031 00000 n -0000331861 00000 n -0000333157 00000 n -0000335887 00000 n -0000335308 00000 n -0000333321 00000 n -0000335434 00000 n -0000335563 00000 n -0000335692 00000 n -0000335757 00000 n -0000335822 00000 n -0000340083 00000 n -0000339574 00000 n -0000335999 00000 n -0000339889 00000 n -0000339721 00000 n -0000340018 00000 n -0000581107 00000 n -0000345986 00000 n -0000343078 00000 n -0000340195 00000 n -0000345792 00000 n -0000345921 00000 n -0000343351 00000 n -0000343513 00000 n -0000343675 00000 n -0000343837 00000 n -0000343999 00000 n -0000344161 00000 n -0000344332 00000 n -0000344494 00000 n -0000344657 00000 n -0000344819 00000 n -0000344982 00000 n -0000345145 00000 n -0000345308 00000 n -0000345471 00000 n -0000345634 00000 n -0000351091 00000 n -0000349173 00000 n -0000346098 00000 n -0000351026 00000 n -0000349401 00000 n -0000349564 00000 n -0000349731 00000 n -0000349901 00000 n -0000350062 00000 n -0000350224 00000 n -0000350386 00000 n -0000350548 00000 n -0000350711 00000 n -0000350865 00000 n -0000789968 00000 n -0000357481 00000 n -0000354419 00000 n -0000351216 00000 n -0000357416 00000 n -0000354710 00000 n -0000354863 00000 n -0000355017 00000 n -0000355168 00000 n -0000355322 00000 n -0000355484 00000 n -0000355646 00000 n -0000355808 00000 n -0000355969 00000 n -0000356130 00000 n -0000356291 00000 n -0000356452 00000 n -0000356606 00000 n -0000356769 00000 n -0000356924 00000 n -0000357089 00000 n -0000357255 00000 n -0000493630 00000 n -0000509796 00000 n -0000361985 00000 n -0000361190 00000 n -0000357593 00000 n -0000361663 00000 n -0000361346 00000 n -0000361500 00000 n -0000361857 00000 n -0000361921 00000 n -0000365206 00000 n -0000365015 00000 n -0000362124 00000 n -0000365141 00000 n -0000369690 00000 n -0000368491 00000 n -0000365375 00000 n -0000368979 00000 n -0000369108 00000 n -0000369365 00000 n -0000368647 00000 n -0000368817 00000 n -0000369430 00000 n -0000369495 00000 n -0000369560 00000 n -0000369625 00000 n -0000372889 00000 n -0000372698 00000 n -0000369802 00000 n -0000372824 00000 n -0000376973 00000 n -0000376394 00000 n +0000039756 00000 n +0000039819 00000 n +0000031768 00000 n +0000031922 00000 n +0000032079 00000 n +0000032236 00000 n +0000032392 00000 n +0000032549 00000 n +0000032711 00000 n +0000032872 00000 n +0000033033 00000 n +0000033195 00000 n +0000033362 00000 n +0000033529 00000 n +0000033694 00000 n +0000033856 00000 n +0000034022 00000 n +0000034183 00000 n +0000034338 00000 n +0000034495 00000 n +0000034651 00000 n +0000034808 00000 n +0000034965 00000 n +0000035122 00000 n +0000035276 00000 n +0000035432 00000 n +0000035594 00000 n +0000035756 00000 n +0000035912 00000 n +0000036067 00000 n +0000036229 00000 n +0000036396 00000 n +0000036562 00000 n +0000036723 00000 n +0000036878 00000 n +0000037035 00000 n +0000037192 00000 n +0000037354 00000 n +0000037511 00000 n +0000037668 00000 n +0000037829 00000 n +0000037986 00000 n +0000038148 00000 n +0000038315 00000 n +0000038481 00000 n +0000038643 00000 n +0000038805 00000 n +0000038967 00000 n +0000039129 00000 n +0000039291 00000 n +0000039446 00000 n +0000039601 00000 n +0000053269 00000 n +0000043218 00000 n +0000039967 00000 n +0000053206 00000 n +0000730403 00000 n +0000713322 00000 n +0000730219 00000 n +0000043808 00000 n +0000043971 00000 n +0000044134 00000 n +0000044297 00000 n +0000044455 00000 n +0000044618 00000 n +0000044781 00000 n +0000044936 00000 n +0000045094 00000 n +0000045252 00000 n +0000045408 00000 n +0000045566 00000 n +0000045729 00000 n +0000045897 00000 n +0000046065 00000 n +0000046228 00000 n +0000046396 00000 n +0000046564 00000 n +0000046721 00000 n +0000046884 00000 n +0000047047 00000 n +0000047209 00000 n +0000047371 00000 n +0000047534 00000 n +0000047696 00000 n +0000047858 00000 n +0000048021 00000 n +0000048184 00000 n +0000048347 00000 n +0000048515 00000 n +0000048684 00000 n +0000048853 00000 n +0000049016 00000 n +0000049180 00000 n +0000049344 00000 n +0000049507 00000 n +0000049671 00000 n +0000049835 00000 n +0000050004 00000 n +0000050173 00000 n +0000050342 00000 n +0000050511 00000 n +0000050680 00000 n +0000050849 00000 n +0000051018 00000 n +0000051187 00000 n +0000051356 00000 n +0000051526 00000 n +0000051696 00000 n +0000051865 00000 n +0000052035 00000 n +0000052205 00000 n +0000052373 00000 n +0000052543 00000 n +0000052711 00000 n +0000052878 00000 n +0000053045 00000 n +0000066634 00000 n +0000056923 00000 n +0000053367 00000 n +0000066571 00000 n +0000057505 00000 n +0000057668 00000 n +0000057831 00000 n +0000057994 00000 n +0000058157 00000 n +0000058319 00000 n +0000058481 00000 n +0000058643 00000 n +0000058805 00000 n +0000058967 00000 n +0000059129 00000 n +0000059291 00000 n +0000059458 00000 n +0000059625 00000 n +0000059793 00000 n +0000059960 00000 n +0000060117 00000 n +0000060279 00000 n +0000060446 00000 n +0000060613 00000 n +0000060775 00000 n +0000060937 00000 n +0000061099 00000 n +0000061261 00000 n +0000061428 00000 n +0000061595 00000 n +0000061762 00000 n +0000061929 00000 n +0000062091 00000 n +0000062253 00000 n +0000062410 00000 n +0000062577 00000 n +0000062739 00000 n +0000062906 00000 n +0000063073 00000 n +0000063239 00000 n +0000712433 00000 n +0000691102 00000 n +0000712259 00000 n +0000063405 00000 n +0000063571 00000 n +0000063726 00000 n +0000063882 00000 n +0000064039 00000 n +0000064201 00000 n +0000064363 00000 n +0000064520 00000 n +0000064675 00000 n +0000064832 00000 n +0000064994 00000 n +0000065151 00000 n +0000065308 00000 n +0000065463 00000 n +0000065619 00000 n +0000065780 00000 n +0000065936 00000 n +0000066097 00000 n +0000066252 00000 n +0000066412 00000 n +0000071164 00000 n +0000067988 00000 n +0000066745 00000 n +0000071101 00000 n +0000068266 00000 n +0000068428 00000 n +0000068583 00000 n +0000068740 00000 n +0000068897 00000 n +0000069054 00000 n +0000069211 00000 n +0000069368 00000 n +0000069525 00000 n +0000069682 00000 n +0000069839 00000 n +0000069996 00000 n +0000070154 00000 n +0000070311 00000 n +0000070469 00000 n +0000690136 00000 n +0000670169 00000 n +0000689963 00000 n +0000070627 00000 n +0000070785 00000 n +0000070943 00000 n +0000074340 00000 n +0000073530 00000 n +0000071275 00000 n +0000073652 00000 n +0000073776 00000 n +0000073901 00000 n +0000074026 00000 n +0000074151 00000 n +0000074214 00000 n +0000074277 00000 n +0000669375 00000 n +0000651058 00000 n +0000669202 00000 n +0000788612 00000 n +0000078911 00000 n +0000077731 00000 n +0000074464 00000 n +0000078225 00000 n +0000078288 00000 n +0000078351 00000 n +0000078475 00000 n +0000078600 00000 n +0000078725 00000 n +0000077881 00000 n +0000078074 00000 n +0000078848 00000 n +0000369514 00000 n +0000428803 00000 n +0000083588 00000 n +0000082531 00000 n +0000079035 00000 n +0000083011 00000 n +0000083139 00000 n +0000082686 00000 n +0000082849 00000 n +0000083267 00000 n +0000083395 00000 n +0000083523 00000 n +0000099374 00000 n +0000086826 00000 n +0000086252 00000 n +0000083713 00000 n +0000086377 00000 n +0000086505 00000 n +0000086633 00000 n +0000086761 00000 n +0000090279 00000 n +0000089114 00000 n +0000086938 00000 n +0000089575 00000 n +0000089703 00000 n +0000089831 00000 n +0000089959 00000 n +0000090087 00000 n +0000089269 00000 n +0000089422 00000 n +0000090214 00000 n +0000303249 00000 n +0000091356 00000 n +0000091038 00000 n +0000090365 00000 n +0000091163 00000 n +0000091291 00000 n +0000093399 00000 n +0000092696 00000 n +0000091455 00000 n +0000092822 00000 n +0000092950 00000 n +0000093077 00000 n +0000093205 00000 n +0000093334 00000 n +0000788734 00000 n +0000095975 00000 n +0000095345 00000 n +0000093498 00000 n +0000095651 00000 n +0000095780 00000 n +0000095845 00000 n +0000095910 00000 n +0000095492 00000 n +0000287462 00000 n +0000099568 00000 n +0000098863 00000 n +0000096087 00000 n +0000098989 00000 n +0000099118 00000 n +0000099245 00000 n +0000650375 00000 n +0000638313 00000 n +0000650196 00000 n +0000099503 00000 n +0000103687 00000 n +0000102961 00000 n +0000099694 00000 n +0000103622 00000 n +0000637740 00000 n +0000626757 00000 n +0000637561 00000 n +0000103126 00000 n +0000103280 00000 n +0000103451 00000 n +0000212423 00000 n +0000362069 00000 n +0000107857 00000 n +0000107458 00000 n +0000103853 00000 n +0000107792 00000 n +0000107605 00000 n +0000179093 00000 n +0000111574 00000 n +0000111124 00000 n +0000107996 00000 n +0000111250 00000 n +0000111379 00000 n +0000111444 00000 n +0000111509 00000 n +0000114422 00000 n +0000117140 00000 n +0000114257 00000 n +0000111699 00000 n +0000116560 00000 n +0000116689 00000 n +0000116818 00000 n +0000116065 00000 n +0000116227 00000 n +0000625859 00000 n +0000616063 00000 n +0000625685 00000 n +0000615499 00000 n +0000606413 00000 n +0000615324 00000 n +0000116947 00000 n +0000116389 00000 n +0000117076 00000 n +0000788859 00000 n +0000115894 00000 n +0000115952 00000 n +0000116042 00000 n +0000228730 00000 n +0000264355 00000 n +0000121620 00000 n +0000120814 00000 n +0000117309 00000 n +0000121298 00000 n +0000121426 00000 n +0000120970 00000 n +0000121136 00000 n +0000121555 00000 n +0000432831 00000 n +0000125534 00000 n +0000125025 00000 n +0000121772 00000 n +0000125340 00000 n +0000125469 00000 n +0000125172 00000 n +0000126680 00000 n +0000126489 00000 n +0000125672 00000 n +0000126615 00000 n +0000128544 00000 n +0000128224 00000 n +0000126779 00000 n +0000128350 00000 n +0000128479 00000 n +0000131838 00000 n +0000131003 00000 n +0000128656 00000 n +0000131129 00000 n +0000131258 00000 n +0000131387 00000 n +0000131515 00000 n +0000131644 00000 n +0000131773 00000 n +0000135888 00000 n +0000134992 00000 n +0000131976 00000 n +0000135309 00000 n +0000135438 00000 n +0000135566 00000 n +0000135139 00000 n +0000135694 00000 n +0000135823 00000 n +0000788984 00000 n +0000139913 00000 n +0000139335 00000 n +0000136026 00000 n +0000139461 00000 n +0000139590 00000 n +0000139719 00000 n +0000139848 00000 n +0000143795 00000 n +0000143346 00000 n +0000140051 00000 n +0000143472 00000 n +0000143601 00000 n +0000143730 00000 n +0000146227 00000 n +0000146036 00000 n +0000143920 00000 n +0000146162 00000 n +0000150046 00000 n +0000149286 00000 n +0000146369 00000 n +0000149594 00000 n +0000606138 00000 n +0000602780 00000 n +0000605959 00000 n +0000149723 00000 n +0000149433 00000 n +0000149852 00000 n +0000149981 00000 n +0000428545 00000 n +0000150883 00000 n +0000150692 00000 n +0000150228 00000 n +0000150818 00000 n +0000153554 00000 n +0000152976 00000 n +0000150982 00000 n +0000153102 00000 n +0000153231 00000 n +0000153360 00000 n +0000153489 00000 n +0000789109 00000 n +0000153994 00000 n +0000153803 00000 n +0000153653 00000 n +0000153929 00000 n +0000158081 00000 n +0000157315 00000 n +0000154036 00000 n +0000157629 00000 n +0000157758 00000 n +0000157886 00000 n +0000157951 00000 n +0000158016 00000 n +0000157462 00000 n +0000162577 00000 n +0000162769 00000 n +0000162322 00000 n +0000158180 00000 n +0000162448 00000 n +0000162704 00000 n +0000166618 00000 n +0000166040 00000 n +0000162894 00000 n +0000166166 00000 n +0000166295 00000 n +0000166424 00000 n +0000166553 00000 n +0000169274 00000 n +0000170652 00000 n +0000169148 00000 n +0000166756 00000 n +0000170200 00000 n +0000170329 00000 n +0000170458 00000 n +0000170523 00000 n +0000170587 00000 n +0000173975 00000 n +0000173271 00000 n +0000170807 00000 n +0000173397 00000 n +0000173526 00000 n +0000173654 00000 n +0000173719 00000 n +0000173784 00000 n +0000173910 00000 n +0000789234 00000 n +0000179286 00000 n +0000178498 00000 n +0000174087 00000 n +0000178964 00000 n +0000178654 00000 n +0000178805 00000 n +0000179222 00000 n +0000581405 00000 n +0000183148 00000 n +0000181877 00000 n +0000179424 00000 n +0000182567 00000 n +0000182696 00000 n +0000182825 00000 n +0000182954 00000 n +0000182042 00000 n +0000182194 00000 n +0000182380 00000 n +0000183083 00000 n +0000187293 00000 n +0000186844 00000 n +0000183274 00000 n +0000186970 00000 n +0000187099 00000 n +0000187228 00000 n +0000191196 00000 n +0000190817 00000 n +0000187418 00000 n +0000191131 00000 n +0000190964 00000 n +0000194044 00000 n +0000194239 00000 n +0000193789 00000 n +0000191308 00000 n +0000193915 00000 n +0000194109 00000 n +0000194174 00000 n +0000197041 00000 n +0000196850 00000 n +0000194351 00000 n +0000196976 00000 n +0000789359 00000 n +0000200639 00000 n +0000200190 00000 n +0000197153 00000 n +0000200316 00000 n +0000200445 00000 n +0000200510 00000 n +0000200574 00000 n +0000203595 00000 n +0000203276 00000 n +0000200751 00000 n +0000203402 00000 n +0000203530 00000 n +0000206831 00000 n +0000205791 00000 n +0000203707 00000 n +0000206252 00000 n +0000206381 00000 n +0000205947 00000 n +0000206101 00000 n +0000206509 00000 n +0000206637 00000 n +0000206766 00000 n +0000208372 00000 n +0000208181 00000 n +0000206943 00000 n +0000208307 00000 n +0000209900 00000 n +0000209709 00000 n +0000208471 00000 n +0000209835 00000 n +0000212488 00000 n +0000212168 00000 n +0000209999 00000 n +0000212294 00000 n +0000789484 00000 n +0000216226 00000 n +0000216035 00000 n +0000212614 00000 n +0000216161 00000 n +0000220647 00000 n +0000220100 00000 n +0000216364 00000 n +0000220582 00000 n +0000220256 00000 n +0000220413 00000 n +0000398590 00000 n +0000224833 00000 n +0000224468 00000 n +0000220772 00000 n +0000224768 00000 n +0000602425 00000 n +0000600426 00000 n +0000602260 00000 n +0000224615 00000 n +0000228923 00000 n +0000228475 00000 n +0000224972 00000 n +0000228601 00000 n +0000228793 00000 n +0000228858 00000 n +0000233017 00000 n +0000232651 00000 n +0000229035 00000 n +0000232952 00000 n +0000232798 00000 n +0000238283 00000 n +0000237150 00000 n +0000233142 00000 n +0000238218 00000 n +0000237333 00000 n +0000237490 00000 n +0000237675 00000 n +0000237849 00000 n +0000238034 00000 n +0000789609 00000 n +0000315660 00000 n +0000242165 00000 n +0000241974 00000 n +0000238477 00000 n +0000242100 00000 n +0000246174 00000 n +0000245983 00000 n +0000242277 00000 n +0000246109 00000 n +0000250644 00000 n +0000249699 00000 n +0000246299 00000 n +0000250192 00000 n +0000250321 00000 n +0000249855 00000 n +0000250450 00000 n +0000250579 00000 n +0000250025 00000 n +0000330446 00000 n +0000253980 00000 n +0000253598 00000 n +0000250756 00000 n +0000253915 00000 n +0000253745 00000 n +0000415927 00000 n +0000257724 00000 n +0000257212 00000 n +0000254149 00000 n +0000257530 00000 n +0000257359 00000 n +0000257659 00000 n +0000261443 00000 n +0000261123 00000 n +0000257849 00000 n +0000261249 00000 n +0000261378 00000 n +0000789734 00000 n +0000264420 00000 n +0000264100 00000 n +0000261555 00000 n +0000264226 00000 n +0000268473 00000 n +0000268282 00000 n +0000264576 00000 n +0000268408 00000 n +0000272010 00000 n +0000271509 00000 n +0000268628 00000 n +0000271816 00000 n +0000271945 00000 n +0000271656 00000 n +0000276521 00000 n +0000275714 00000 n +0000272179 00000 n +0000276200 00000 n +0000276329 00000 n +0000275870 00000 n +0000276457 00000 n +0000276045 00000 n +0000280452 00000 n +0000280004 00000 n +0000276633 00000 n +0000280130 00000 n +0000280259 00000 n +0000280387 00000 n +0000284537 00000 n +0000283869 00000 n +0000280607 00000 n +0000284343 00000 n +0000284472 00000 n +0000284025 00000 n +0000284187 00000 n +0000789859 00000 n +0000287656 00000 n +0000287017 00000 n +0000284706 00000 n +0000287334 00000 n +0000287164 00000 n +0000287527 00000 n +0000287591 00000 n +0000291347 00000 n +0000290845 00000 n +0000287782 00000 n +0000291154 00000 n +0000291283 00000 n +0000290992 00000 n +0000295830 00000 n +0000295455 00000 n +0000291529 00000 n +0000295765 00000 n +0000295602 00000 n +0000395021 00000 n +0000300114 00000 n +0000299475 00000 n +0000295956 00000 n +0000299791 00000 n +0000299920 00000 n +0000299622 00000 n +0000300049 00000 n +0000328436 00000 n +0000303314 00000 n +0000302995 00000 n +0000300239 00000 n +0000303121 00000 n +0000307757 00000 n +0000307437 00000 n +0000303482 00000 n +0000307563 00000 n +0000307692 00000 n +0000789984 00000 n +0000311091 00000 n +0000310599 00000 n +0000307869 00000 n +0000310897 00000 n +0000310746 00000 n +0000311026 00000 n +0000315725 00000 n +0000315233 00000 n +0000311217 00000 n +0000315531 00000 n +0000315380 00000 n +0000320076 00000 n +0000319028 00000 n +0000315837 00000 n +0000319496 00000 n +0000319184 00000 n +0000319625 00000 n +0000319754 00000 n +0000319883 00000 n +0000320012 00000 n +0000319344 00000 n +0000324230 00000 n +0000323781 00000 n +0000320188 00000 n +0000323907 00000 n +0000324036 00000 n +0000324165 00000 n +0000328629 00000 n +0000328181 00000 n +0000324355 00000 n +0000328307 00000 n +0000328564 00000 n +0000330511 00000 n +0000330191 00000 n +0000328767 00000 n +0000330317 00000 n +0000790109 00000 n +0000332039 00000 n +0000331848 00000 n +0000330623 00000 n +0000331974 00000 n +0000333499 00000 n +0000333308 00000 n +0000332138 00000 n +0000333434 00000 n +0000336164 00000 n +0000335585 00000 n +0000333598 00000 n +0000335711 00000 n +0000335840 00000 n +0000335969 00000 n +0000336034 00000 n +0000336099 00000 n +0000340360 00000 n +0000339851 00000 n +0000336276 00000 n +0000340166 00000 n +0000339998 00000 n +0000340295 00000 n +0000581372 00000 n +0000346263 00000 n +0000343355 00000 n +0000340472 00000 n +0000346069 00000 n +0000346198 00000 n +0000343628 00000 n +0000343790 00000 n +0000343952 00000 n +0000344114 00000 n +0000344276 00000 n +0000344438 00000 n +0000344609 00000 n +0000344771 00000 n +0000344934 00000 n +0000345096 00000 n +0000345259 00000 n +0000345422 00000 n +0000345585 00000 n +0000345748 00000 n +0000345911 00000 n +0000351368 00000 n +0000349450 00000 n +0000346375 00000 n +0000351303 00000 n +0000349678 00000 n +0000349841 00000 n +0000350008 00000 n +0000350178 00000 n +0000350339 00000 n +0000350501 00000 n +0000350663 00000 n +0000350825 00000 n +0000350988 00000 n +0000351142 00000 n +0000790234 00000 n +0000357758 00000 n +0000354696 00000 n +0000351493 00000 n +0000357693 00000 n +0000354987 00000 n +0000355140 00000 n +0000355294 00000 n +0000355445 00000 n +0000355599 00000 n +0000355761 00000 n +0000355923 00000 n +0000356085 00000 n +0000356246 00000 n +0000356407 00000 n +0000356568 00000 n +0000356729 00000 n +0000356883 00000 n +0000357046 00000 n +0000357201 00000 n +0000357366 00000 n +0000357532 00000 n +0000493907 00000 n +0000510073 00000 n +0000362262 00000 n +0000361467 00000 n +0000357870 00000 n +0000361940 00000 n +0000361623 00000 n +0000361777 00000 n +0000362134 00000 n +0000362198 00000 n +0000365483 00000 n +0000365292 00000 n +0000362401 00000 n +0000365418 00000 n +0000369967 00000 n +0000368768 00000 n +0000365652 00000 n +0000369256 00000 n +0000369385 00000 n +0000369642 00000 n +0000368924 00000 n +0000369094 00000 n +0000369707 00000 n +0000369772 00000 n +0000369837 00000 n +0000369902 00000 n +0000373166 00000 n 0000372975 00000 n -0000376520 00000 n -0000376585 00000 n -0000376650 00000 n -0000376779 00000 n -0000376843 00000 n -0000376908 00000 n -0000790093 00000 n -0000380997 00000 n -0000380159 00000 n -0000377098 00000 n -0000380285 00000 n -0000380350 00000 n -0000380415 00000 n -0000380544 00000 n -0000380609 00000 n -0000380674 00000 n -0000380802 00000 n -0000380867 00000 n -0000380932 00000 n -0000384833 00000 n -0000383998 00000 n -0000381122 00000 n -0000384124 00000 n -0000384253 00000 n -0000384317 00000 n -0000384382 00000 n -0000384510 00000 n -0000384639 00000 n -0000384768 00000 n -0000387710 00000 n -0000387132 00000 n -0000385043 00000 n -0000387258 00000 n -0000387387 00000 n -0000387516 00000 n -0000387645 00000 n -0000391108 00000 n -0000390787 00000 n -0000387893 00000 n -0000390913 00000 n -0000390978 00000 n -0000391043 00000 n -0000395068 00000 n -0000394489 00000 n -0000391233 00000 n -0000394615 00000 n -0000394873 00000 n -0000394938 00000 n -0000395003 00000 n -0000398766 00000 n -0000397877 00000 n -0000395193 00000 n -0000398184 00000 n -0000398024 00000 n -0000398442 00000 n -0000398571 00000 n -0000398636 00000 n -0000398701 00000 n -0000790218 00000 n -0000402518 00000 n -0000401886 00000 n -0000398878 00000 n -0000402198 00000 n -0000402033 00000 n -0000402327 00000 n -0000402390 00000 n -0000402453 00000 n -0000581074 00000 n -0000406241 00000 n -0000405792 00000 n -0000402630 00000 n -0000405918 00000 n -0000406046 00000 n -0000406111 00000 n -0000406176 00000 n -0000409387 00000 n -0000408809 00000 n -0000406353 00000 n -0000408935 00000 n -0000409064 00000 n -0000409129 00000 n -0000409193 00000 n -0000599880 00000 n -0000592596 00000 n -0000599700 00000 n -0000409322 00000 n -0000411295 00000 n -0000410846 00000 n -0000409527 00000 n -0000410972 00000 n -0000411101 00000 n -0000411230 00000 n -0000415715 00000 n -0000414772 00000 n -0000411407 00000 n -0000415135 00000 n -0000592275 00000 n -0000583062 00000 n -0000592089 00000 n -0000414919 00000 n -0000415264 00000 n -0000415392 00000 n -0000415521 00000 n -0000417071 00000 n -0000416880 00000 n -0000415952 00000 n -0000417006 00000 n -0000790343 00000 n -0000417511 00000 n -0000417320 00000 n -0000417170 00000 n -0000417446 00000 n -0000420824 00000 n -0000419598 00000 n -0000417553 00000 n -0000420115 00000 n -0000420244 00000 n -0000420373 00000 n -0000420502 00000 n -0000420631 00000 n -0000420760 00000 n -0000419754 00000 n -0000419926 00000 n -0000421278 00000 n -0000421087 00000 n -0000420937 00000 n -0000421213 00000 n -0000424523 00000 n -0000423945 00000 n -0000421320 00000 n -0000424071 00000 n -0000424200 00000 n -0000424329 00000 n -0000424458 00000 n -0000428719 00000 n -0000427500 00000 n -0000424609 00000 n -0000428010 00000 n -0000428139 00000 n -0000428397 00000 n -0000427656 00000 n -0000427835 00000 n -0000428591 00000 n -0000428655 00000 n -0000435606 00000 n -0000431778 00000 n -0000428872 00000 n -0000431904 00000 n -0000431969 00000 n -0000432034 00000 n -0000432099 00000 n -0000432164 00000 n -0000432229 00000 n -0000432294 00000 n -0000432359 00000 n -0000432424 00000 n -0000432489 00000 n -0000432619 00000 n -0000432684 00000 n -0000432749 00000 n -0000432814 00000 n -0000432879 00000 n -0000432944 00000 n -0000433009 00000 n -0000433074 00000 n -0000433139 00000 n -0000433204 00000 n -0000433269 00000 n -0000433334 00000 n -0000433399 00000 n -0000433464 00000 n -0000433529 00000 n -0000433594 00000 n -0000433659 00000 n -0000433724 00000 n -0000433789 00000 n -0000433854 00000 n -0000433919 00000 n -0000433984 00000 n -0000434049 00000 n -0000434114 00000 n -0000434178 00000 n -0000434243 00000 n -0000434308 00000 n -0000434373 00000 n -0000434438 00000 n -0000434503 00000 n -0000434568 00000 n -0000434633 00000 n -0000434698 00000 n -0000434763 00000 n -0000434828 00000 n -0000434893 00000 n -0000434958 00000 n -0000435023 00000 n -0000435088 00000 n -0000435153 00000 n -0000435218 00000 n -0000435283 00000 n -0000435348 00000 n -0000435413 00000 n -0000435478 00000 n -0000435542 00000 n -0000790468 00000 n -0000442252 00000 n -0000438688 00000 n -0000435718 00000 n -0000438814 00000 n -0000438879 00000 n -0000438944 00000 n -0000439009 00000 n -0000439074 00000 n -0000439139 00000 n -0000439204 00000 n -0000439269 00000 n -0000439334 00000 n -0000439399 00000 n -0000439464 00000 n -0000439529 00000 n -0000439593 00000 n -0000439658 00000 n -0000439723 00000 n -0000439788 00000 n -0000439853 00000 n -0000439918 00000 n -0000439983 00000 n -0000440048 00000 n -0000440113 00000 n -0000440178 00000 n -0000440243 00000 n -0000440308 00000 n -0000440372 00000 n -0000440437 00000 n -0000440502 00000 n -0000440567 00000 n -0000440632 00000 n -0000440697 00000 n -0000440762 00000 n -0000440827 00000 n -0000440892 00000 n -0000440957 00000 n -0000441022 00000 n -0000441087 00000 n -0000441152 00000 n -0000441217 00000 n -0000441282 00000 n -0000441347 00000 n -0000441411 00000 n -0000441475 00000 n -0000441539 00000 n -0000441604 00000 n -0000441669 00000 n -0000441734 00000 n -0000441799 00000 n -0000441864 00000 n -0000441929 00000 n -0000441994 00000 n -0000442059 00000 n -0000442124 00000 n -0000442188 00000 n -0000448425 00000 n -0000444987 00000 n -0000442364 00000 n -0000445113 00000 n -0000445178 00000 n -0000445243 00000 n -0000445308 00000 n -0000445373 00000 n -0000445438 00000 n -0000445503 00000 n -0000445568 00000 n -0000445633 00000 n -0000445698 00000 n -0000445763 00000 n -0000445828 00000 n -0000445893 00000 n -0000445958 00000 n -0000446023 00000 n -0000446088 00000 n -0000446153 00000 n -0000446218 00000 n -0000446283 00000 n -0000446348 00000 n -0000446413 00000 n -0000446478 00000 n -0000446543 00000 n -0000446608 00000 n -0000446673 00000 n -0000446738 00000 n -0000446803 00000 n -0000446868 00000 n -0000446933 00000 n -0000446998 00000 n -0000447063 00000 n -0000447128 00000 n -0000447193 00000 n -0000447258 00000 n -0000447322 00000 n -0000447387 00000 n -0000447452 00000 n -0000447517 00000 n -0000447582 00000 n -0000447647 00000 n -0000447712 00000 n -0000447777 00000 n -0000447842 00000 n -0000447907 00000 n -0000447972 00000 n -0000448037 00000 n -0000448102 00000 n -0000448167 00000 n -0000448232 00000 n -0000448297 00000 n -0000448361 00000 n -0000453003 00000 n -0000450739 00000 n -0000448537 00000 n -0000450865 00000 n -0000450930 00000 n -0000450995 00000 n -0000451060 00000 n -0000451125 00000 n -0000451190 00000 n -0000451255 00000 n -0000451320 00000 n -0000451385 00000 n -0000451450 00000 n -0000451515 00000 n -0000451580 00000 n -0000451645 00000 n -0000451710 00000 n -0000451772 00000 n -0000451836 00000 n -0000451901 00000 n -0000451965 00000 n -0000452030 00000 n -0000452095 00000 n -0000452160 00000 n -0000452225 00000 n -0000452290 00000 n -0000452355 00000 n -0000452420 00000 n -0000452549 00000 n -0000452678 00000 n -0000452743 00000 n -0000452808 00000 n -0000452873 00000 n -0000452938 00000 n -0000455798 00000 n -0000455154 00000 n -0000453128 00000 n -0000455280 00000 n -0000455409 00000 n -0000455538 00000 n -0000455603 00000 n -0000455668 00000 n -0000455733 00000 n -0000460136 00000 n -0000459816 00000 n -0000455911 00000 n -0000459942 00000 n -0000460007 00000 n -0000460072 00000 n -0000463736 00000 n -0000463481 00000 n -0000460289 00000 n -0000463607 00000 n -0000463672 00000 n -0000790593 00000 n -0000466984 00000 n -0000466793 00000 n -0000463875 00000 n -0000466919 00000 n -0000470712 00000 n -0000470456 00000 n -0000467110 00000 n -0000470582 00000 n -0000470647 00000 n -0000473553 00000 n -0000472845 00000 n -0000470851 00000 n -0000472971 00000 n -0000473036 00000 n -0000473101 00000 n -0000473166 00000 n -0000473231 00000 n -0000473360 00000 n -0000473425 00000 n -0000473489 00000 n -0000478221 00000 n -0000477965 00000 n -0000473692 00000 n -0000478091 00000 n -0000478156 00000 n -0000481217 00000 n -0000480444 00000 n -0000478347 00000 n -0000480570 00000 n -0000480635 00000 n -0000480700 00000 n -0000480765 00000 n -0000480894 00000 n -0000480959 00000 n -0000481022 00000 n -0000481087 00000 n -0000481152 00000 n -0000484126 00000 n -0000483611 00000 n -0000481370 00000 n -0000483737 00000 n -0000483802 00000 n -0000483867 00000 n -0000483932 00000 n -0000483997 00000 n -0000484062 00000 n -0000790718 00000 n -0000487465 00000 n -0000486885 00000 n -0000484278 00000 n -0000487011 00000 n -0000487140 00000 n -0000487205 00000 n -0000487270 00000 n -0000487335 00000 n -0000487400 00000 n -0000490915 00000 n -0000490659 00000 n -0000487605 00000 n -0000490785 00000 n -0000490850 00000 n -0000493890 00000 n -0000493181 00000 n -0000491041 00000 n -0000493307 00000 n -0000493372 00000 n -0000493437 00000 n -0000493502 00000 n -0000493695 00000 n -0000493760 00000 n -0000493825 00000 n -0000497563 00000 n -0000497307 00000 n -0000494042 00000 n -0000497433 00000 n -0000497498 00000 n -0000501062 00000 n -0000500806 00000 n -0000497689 00000 n -0000500932 00000 n -0000500997 00000 n -0000504235 00000 n -0000503850 00000 n -0000501188 00000 n -0000503976 00000 n -0000504041 00000 n -0000504106 00000 n -0000504171 00000 n -0000790843 00000 n -0000506747 00000 n -0000505973 00000 n -0000504400 00000 n -0000506099 00000 n -0000506164 00000 n -0000506293 00000 n -0000506358 00000 n -0000506423 00000 n -0000506488 00000 n -0000506553 00000 n -0000506618 00000 n -0000506683 00000 n -0000510186 00000 n -0000509541 00000 n -0000506900 00000 n -0000509667 00000 n -0000509861 00000 n -0000509926 00000 n -0000509991 00000 n -0000510056 00000 n -0000510121 00000 n -0000513243 00000 n -0000512601 00000 n -0000510326 00000 n -0000512727 00000 n -0000512792 00000 n -0000512855 00000 n -0000512920 00000 n -0000513048 00000 n -0000513113 00000 n -0000513178 00000 n -0000516766 00000 n -0000516445 00000 n -0000513396 00000 n -0000516571 00000 n -0000516636 00000 n -0000516701 00000 n -0000520352 00000 n -0000520161 00000 n -0000516906 00000 n -0000520287 00000 n -0000523830 00000 n -0000523639 00000 n -0000520478 00000 n -0000523765 00000 n -0000790968 00000 n -0000526724 00000 n -0000526080 00000 n -0000523970 00000 n -0000526206 00000 n -0000526271 00000 n -0000526336 00000 n -0000526401 00000 n -0000526530 00000 n -0000526595 00000 n -0000526660 00000 n -0000529448 00000 n -0000528674 00000 n -0000526876 00000 n -0000528800 00000 n -0000528865 00000 n -0000528930 00000 n -0000528995 00000 n -0000529059 00000 n -0000529124 00000 n -0000529253 00000 n -0000529318 00000 n -0000529383 00000 n -0000532719 00000 n -0000532398 00000 n -0000529601 00000 n -0000532524 00000 n -0000532589 00000 n -0000532654 00000 n -0000535959 00000 n -0000535639 00000 n -0000532859 00000 n -0000535765 00000 n -0000535830 00000 n -0000535895 00000 n -0000539270 00000 n -0000538625 00000 n -0000536098 00000 n -0000538751 00000 n -0000538816 00000 n -0000538945 00000 n -0000539010 00000 n -0000539075 00000 n -0000539140 00000 n -0000539205 00000 n -0000542148 00000 n -0000541957 00000 n -0000539410 00000 n -0000542083 00000 n -0000791093 00000 n -0000545214 00000 n -0000544829 00000 n -0000542359 00000 n -0000544955 00000 n -0000545020 00000 n -0000545085 00000 n -0000545150 00000 n -0000548940 00000 n -0000548296 00000 n -0000545451 00000 n -0000548422 00000 n -0000548487 00000 n -0000548552 00000 n -0000548680 00000 n -0000548745 00000 n -0000548810 00000 n -0000548875 00000 n -0000553379 00000 n -0000553124 00000 n -0000549079 00000 n -0000553250 00000 n -0000553315 00000 n -0000556832 00000 n -0000556641 00000 n -0000553505 00000 n -0000556767 00000 n -0000559564 00000 n -0000559114 00000 n -0000556958 00000 n -0000559240 00000 n -0000559305 00000 n -0000559370 00000 n -0000559435 00000 n -0000559500 00000 n -0000563409 00000 n -0000562829 00000 n -0000559715 00000 n -0000562955 00000 n -0000563084 00000 n -0000563149 00000 n -0000563214 00000 n -0000563279 00000 n -0000563344 00000 n -0000791218 00000 n -0000566571 00000 n -0000565861 00000 n -0000563549 00000 n -0000565987 00000 n -0000566052 00000 n -0000566117 00000 n -0000566182 00000 n -0000566311 00000 n -0000566376 00000 n -0000566441 00000 n -0000566506 00000 n -0000569288 00000 n -0000569032 00000 n -0000566723 00000 n -0000569158 00000 n -0000569223 00000 n -0000572542 00000 n -0000571769 00000 n -0000569414 00000 n -0000571895 00000 n -0000571960 00000 n -0000572025 00000 n -0000572090 00000 n -0000572219 00000 n -0000572284 00000 n -0000572349 00000 n -0000572413 00000 n -0000572478 00000 n -0000575828 00000 n -0000575509 00000 n -0000572694 00000 n -0000575635 00000 n -0000575700 00000 n -0000575765 00000 n -0000579293 00000 n -0000578650 00000 n -0000575980 00000 n -0000578776 00000 n -0000578841 00000 n -0000578970 00000 n -0000579034 00000 n -0000579099 00000 n -0000579164 00000 n -0000579228 00000 n -0000580921 00000 n -0000580600 00000 n -0000579433 00000 n -0000580726 00000 n -0000580791 00000 n -0000580856 00000 n -0000791343 00000 n -0000581173 00000 n -0000592517 00000 n -0000600106 00000 n -0000602406 00000 n -0000602375 00000 n -0000606093 00000 n -0000615533 00000 n -0000626040 00000 n -0000637781 00000 n -0000650498 00000 n -0000669565 00000 n -0000690452 00000 n -0000712595 00000 n -0000730490 00000 n -0000733320 00000 n -0000733090 00000 n -0000760627 00000 n -0000787738 00000 n -0000791423 00000 n -0000791547 00000 n -0000791673 00000 n -0000791799 00000 n -0000791925 00000 n -0000792014 00000 n -0000792115 00000 n -0000809288 00000 n -0000829690 00000 n -0000829731 00000 n -0000829771 00000 n -0000829905 00000 n +0000370079 00000 n +0000373101 00000 n +0000377250 00000 n +0000376671 00000 n +0000373252 00000 n +0000376797 00000 n +0000376862 00000 n +0000376927 00000 n +0000377056 00000 n +0000377120 00000 n +0000377185 00000 n +0000790359 00000 n +0000381274 00000 n +0000380436 00000 n +0000377375 00000 n +0000380562 00000 n +0000380627 00000 n +0000380692 00000 n +0000380821 00000 n +0000380886 00000 n +0000380951 00000 n +0000381079 00000 n +0000381144 00000 n +0000381209 00000 n +0000385110 00000 n +0000384275 00000 n +0000381399 00000 n +0000384401 00000 n +0000384530 00000 n +0000384594 00000 n +0000384659 00000 n +0000384787 00000 n +0000384916 00000 n +0000385045 00000 n +0000387987 00000 n +0000387409 00000 n +0000385320 00000 n +0000387535 00000 n +0000387664 00000 n +0000387793 00000 n +0000387922 00000 n +0000391385 00000 n +0000391064 00000 n +0000388170 00000 n +0000391190 00000 n +0000391255 00000 n +0000391320 00000 n +0000395345 00000 n +0000394766 00000 n +0000391510 00000 n +0000394892 00000 n +0000395150 00000 n +0000395215 00000 n +0000395280 00000 n +0000399043 00000 n +0000398154 00000 n +0000395470 00000 n +0000398461 00000 n +0000398301 00000 n +0000398719 00000 n +0000398848 00000 n +0000398913 00000 n +0000398978 00000 n +0000790484 00000 n +0000402795 00000 n +0000402163 00000 n +0000399155 00000 n +0000402475 00000 n +0000402310 00000 n +0000402604 00000 n +0000402667 00000 n +0000402730 00000 n +0000581339 00000 n +0000406518 00000 n +0000406069 00000 n +0000402907 00000 n +0000406195 00000 n +0000406323 00000 n +0000406388 00000 n +0000406453 00000 n +0000409664 00000 n +0000409086 00000 n +0000406630 00000 n +0000409212 00000 n +0000409341 00000 n +0000409406 00000 n +0000409470 00000 n +0000600145 00000 n +0000592861 00000 n +0000599965 00000 n +0000409599 00000 n +0000411572 00000 n +0000411123 00000 n +0000409804 00000 n +0000411249 00000 n +0000411378 00000 n +0000411507 00000 n +0000415992 00000 n +0000415049 00000 n +0000411684 00000 n +0000415412 00000 n +0000592540 00000 n +0000583327 00000 n +0000592354 00000 n +0000415196 00000 n +0000415541 00000 n +0000415669 00000 n +0000415798 00000 n +0000417348 00000 n +0000417157 00000 n +0000416229 00000 n +0000417283 00000 n +0000790609 00000 n +0000417788 00000 n +0000417597 00000 n +0000417447 00000 n +0000417723 00000 n +0000421101 00000 n +0000419875 00000 n +0000417830 00000 n +0000420392 00000 n +0000420521 00000 n +0000420650 00000 n +0000420779 00000 n +0000420908 00000 n +0000421037 00000 n +0000420031 00000 n +0000420203 00000 n +0000421555 00000 n +0000421364 00000 n +0000421214 00000 n +0000421490 00000 n +0000424800 00000 n +0000424222 00000 n +0000421597 00000 n +0000424348 00000 n +0000424477 00000 n +0000424606 00000 n +0000424735 00000 n +0000428996 00000 n +0000427777 00000 n +0000424886 00000 n +0000428287 00000 n +0000428416 00000 n +0000428674 00000 n +0000427933 00000 n +0000428112 00000 n +0000428868 00000 n +0000428932 00000 n +0000435883 00000 n +0000432055 00000 n +0000429149 00000 n +0000432181 00000 n +0000432246 00000 n +0000432311 00000 n +0000432376 00000 n +0000432441 00000 n +0000432506 00000 n +0000432571 00000 n +0000432636 00000 n +0000432701 00000 n +0000432766 00000 n +0000432896 00000 n +0000432961 00000 n +0000433026 00000 n +0000433091 00000 n +0000433156 00000 n +0000433221 00000 n +0000433286 00000 n +0000433351 00000 n +0000433416 00000 n +0000433481 00000 n +0000433546 00000 n +0000433611 00000 n +0000433676 00000 n +0000433741 00000 n +0000433806 00000 n +0000433871 00000 n +0000433936 00000 n +0000434001 00000 n +0000434066 00000 n +0000434131 00000 n +0000434196 00000 n +0000434261 00000 n +0000434326 00000 n +0000434391 00000 n +0000434455 00000 n +0000434520 00000 n +0000434585 00000 n +0000434650 00000 n +0000434715 00000 n +0000434780 00000 n +0000434845 00000 n +0000434910 00000 n +0000434975 00000 n +0000435040 00000 n +0000435105 00000 n +0000435170 00000 n +0000435235 00000 n +0000435300 00000 n +0000435365 00000 n +0000435430 00000 n +0000435495 00000 n +0000435560 00000 n +0000435625 00000 n +0000435690 00000 n +0000435755 00000 n +0000435819 00000 n +0000790734 00000 n +0000442529 00000 n +0000438965 00000 n +0000435995 00000 n +0000439091 00000 n +0000439156 00000 n +0000439221 00000 n +0000439286 00000 n +0000439351 00000 n +0000439416 00000 n +0000439481 00000 n +0000439546 00000 n +0000439611 00000 n +0000439676 00000 n +0000439741 00000 n +0000439806 00000 n +0000439870 00000 n +0000439935 00000 n +0000440000 00000 n +0000440065 00000 n +0000440130 00000 n +0000440195 00000 n +0000440260 00000 n +0000440325 00000 n +0000440390 00000 n +0000440455 00000 n +0000440520 00000 n +0000440585 00000 n +0000440649 00000 n +0000440714 00000 n +0000440779 00000 n +0000440844 00000 n +0000440909 00000 n +0000440974 00000 n +0000441039 00000 n +0000441104 00000 n +0000441169 00000 n +0000441234 00000 n +0000441299 00000 n +0000441364 00000 n +0000441429 00000 n +0000441494 00000 n +0000441559 00000 n +0000441624 00000 n +0000441688 00000 n +0000441752 00000 n +0000441816 00000 n +0000441881 00000 n +0000441946 00000 n +0000442011 00000 n +0000442076 00000 n +0000442141 00000 n +0000442206 00000 n +0000442271 00000 n +0000442336 00000 n +0000442401 00000 n +0000442465 00000 n +0000448702 00000 n +0000445264 00000 n +0000442641 00000 n +0000445390 00000 n +0000445455 00000 n +0000445520 00000 n +0000445585 00000 n +0000445650 00000 n +0000445715 00000 n +0000445780 00000 n +0000445845 00000 n +0000445910 00000 n +0000445975 00000 n +0000446040 00000 n +0000446105 00000 n +0000446170 00000 n +0000446235 00000 n +0000446300 00000 n +0000446365 00000 n +0000446430 00000 n +0000446495 00000 n +0000446560 00000 n +0000446625 00000 n +0000446690 00000 n +0000446755 00000 n +0000446820 00000 n +0000446885 00000 n +0000446950 00000 n +0000447015 00000 n +0000447080 00000 n +0000447145 00000 n +0000447210 00000 n +0000447275 00000 n +0000447340 00000 n +0000447405 00000 n +0000447470 00000 n +0000447535 00000 n +0000447599 00000 n +0000447664 00000 n +0000447729 00000 n +0000447794 00000 n +0000447859 00000 n +0000447924 00000 n +0000447989 00000 n +0000448054 00000 n +0000448119 00000 n +0000448184 00000 n +0000448249 00000 n +0000448314 00000 n +0000448379 00000 n +0000448444 00000 n +0000448509 00000 n +0000448574 00000 n +0000448638 00000 n +0000453280 00000 n +0000451016 00000 n +0000448814 00000 n +0000451142 00000 n +0000451207 00000 n +0000451272 00000 n +0000451337 00000 n +0000451402 00000 n +0000451467 00000 n +0000451532 00000 n +0000451597 00000 n +0000451662 00000 n +0000451727 00000 n +0000451792 00000 n +0000451857 00000 n +0000451922 00000 n +0000451987 00000 n +0000452049 00000 n +0000452113 00000 n +0000452178 00000 n +0000452242 00000 n +0000452307 00000 n +0000452372 00000 n +0000452437 00000 n +0000452502 00000 n +0000452567 00000 n +0000452632 00000 n +0000452697 00000 n +0000452826 00000 n +0000452955 00000 n +0000453020 00000 n +0000453085 00000 n +0000453150 00000 n +0000453215 00000 n +0000456075 00000 n +0000455431 00000 n +0000453405 00000 n +0000455557 00000 n +0000455686 00000 n +0000455815 00000 n +0000455880 00000 n +0000455945 00000 n +0000456010 00000 n +0000460413 00000 n +0000460093 00000 n +0000456188 00000 n +0000460219 00000 n +0000460284 00000 n +0000460349 00000 n +0000464013 00000 n +0000463758 00000 n +0000460566 00000 n +0000463884 00000 n +0000463949 00000 n +0000790859 00000 n +0000467261 00000 n +0000467070 00000 n +0000464152 00000 n +0000467196 00000 n +0000470989 00000 n +0000470733 00000 n +0000467387 00000 n +0000470859 00000 n +0000470924 00000 n +0000473830 00000 n +0000473122 00000 n +0000471128 00000 n +0000473248 00000 n +0000473313 00000 n +0000473378 00000 n +0000473443 00000 n +0000473508 00000 n +0000473637 00000 n +0000473702 00000 n +0000473766 00000 n +0000478498 00000 n +0000478242 00000 n +0000473969 00000 n +0000478368 00000 n +0000478433 00000 n +0000481494 00000 n +0000480721 00000 n +0000478624 00000 n +0000480847 00000 n +0000480912 00000 n +0000480977 00000 n +0000481042 00000 n +0000481171 00000 n +0000481236 00000 n +0000481299 00000 n +0000481364 00000 n +0000481429 00000 n +0000484403 00000 n +0000483888 00000 n +0000481647 00000 n +0000484014 00000 n +0000484079 00000 n +0000484144 00000 n +0000484209 00000 n +0000484274 00000 n +0000484339 00000 n +0000790984 00000 n +0000487742 00000 n +0000487162 00000 n +0000484555 00000 n +0000487288 00000 n +0000487417 00000 n +0000487482 00000 n +0000487547 00000 n +0000487612 00000 n +0000487677 00000 n +0000491192 00000 n +0000490936 00000 n +0000487882 00000 n +0000491062 00000 n +0000491127 00000 n +0000494167 00000 n +0000493458 00000 n +0000491318 00000 n +0000493584 00000 n +0000493649 00000 n +0000493714 00000 n +0000493779 00000 n +0000493972 00000 n +0000494037 00000 n +0000494102 00000 n +0000497840 00000 n +0000497584 00000 n +0000494319 00000 n +0000497710 00000 n +0000497775 00000 n +0000501339 00000 n +0000501083 00000 n +0000497966 00000 n +0000501209 00000 n +0000501274 00000 n +0000504512 00000 n +0000504127 00000 n +0000501465 00000 n +0000504253 00000 n +0000504318 00000 n +0000504383 00000 n +0000504448 00000 n +0000791109 00000 n +0000507024 00000 n +0000506250 00000 n +0000504677 00000 n +0000506376 00000 n +0000506441 00000 n +0000506570 00000 n +0000506635 00000 n +0000506700 00000 n +0000506765 00000 n +0000506830 00000 n +0000506895 00000 n +0000506960 00000 n +0000510463 00000 n +0000509818 00000 n +0000507177 00000 n +0000509944 00000 n +0000510138 00000 n +0000510203 00000 n +0000510268 00000 n +0000510333 00000 n +0000510398 00000 n +0000513520 00000 n +0000512878 00000 n +0000510603 00000 n +0000513004 00000 n +0000513069 00000 n +0000513132 00000 n +0000513197 00000 n +0000513325 00000 n +0000513390 00000 n +0000513455 00000 n +0000517043 00000 n +0000516722 00000 n +0000513673 00000 n +0000516848 00000 n +0000516913 00000 n +0000516978 00000 n +0000520629 00000 n +0000520438 00000 n +0000517183 00000 n +0000520564 00000 n +0000524107 00000 n +0000523916 00000 n +0000520755 00000 n +0000524042 00000 n +0000791234 00000 n +0000527001 00000 n +0000526357 00000 n +0000524247 00000 n +0000526483 00000 n +0000526548 00000 n +0000526613 00000 n +0000526678 00000 n +0000526807 00000 n +0000526872 00000 n +0000526937 00000 n +0000529705 00000 n +0000528931 00000 n +0000527153 00000 n +0000529057 00000 n +0000529122 00000 n +0000529187 00000 n +0000529252 00000 n +0000529317 00000 n +0000529382 00000 n +0000529511 00000 n +0000529576 00000 n +0000529641 00000 n +0000532984 00000 n +0000532663 00000 n +0000529858 00000 n +0000532789 00000 n +0000532854 00000 n +0000532919 00000 n +0000536224 00000 n +0000535904 00000 n +0000533124 00000 n +0000536030 00000 n +0000536095 00000 n +0000536160 00000 n +0000539535 00000 n +0000538890 00000 n +0000536363 00000 n +0000539016 00000 n +0000539081 00000 n +0000539210 00000 n +0000539275 00000 n +0000539340 00000 n +0000539405 00000 n +0000539470 00000 n +0000542413 00000 n +0000542222 00000 n +0000539675 00000 n +0000542348 00000 n +0000791359 00000 n +0000545479 00000 n +0000545094 00000 n +0000542624 00000 n +0000545220 00000 n +0000545285 00000 n +0000545350 00000 n +0000545415 00000 n +0000549205 00000 n +0000548561 00000 n +0000545716 00000 n +0000548687 00000 n +0000548752 00000 n +0000548817 00000 n +0000548945 00000 n +0000549010 00000 n +0000549075 00000 n +0000549140 00000 n +0000553644 00000 n +0000553389 00000 n +0000549344 00000 n +0000553515 00000 n +0000553580 00000 n +0000557097 00000 n +0000556906 00000 n +0000553770 00000 n +0000557032 00000 n +0000559829 00000 n +0000559379 00000 n +0000557223 00000 n +0000559505 00000 n +0000559570 00000 n +0000559635 00000 n +0000559700 00000 n +0000559765 00000 n +0000563674 00000 n +0000563094 00000 n +0000559980 00000 n +0000563220 00000 n +0000563349 00000 n +0000563414 00000 n +0000563479 00000 n +0000563544 00000 n +0000563609 00000 n +0000791484 00000 n +0000566836 00000 n +0000566126 00000 n +0000563814 00000 n +0000566252 00000 n +0000566317 00000 n +0000566382 00000 n +0000566447 00000 n +0000566576 00000 n +0000566641 00000 n +0000566706 00000 n +0000566771 00000 n +0000569553 00000 n +0000569297 00000 n +0000566988 00000 n +0000569423 00000 n +0000569488 00000 n +0000572807 00000 n +0000572034 00000 n +0000569679 00000 n +0000572160 00000 n +0000572225 00000 n +0000572290 00000 n +0000572355 00000 n +0000572484 00000 n +0000572549 00000 n +0000572614 00000 n +0000572678 00000 n +0000572743 00000 n +0000576093 00000 n +0000575774 00000 n +0000572959 00000 n +0000575900 00000 n +0000575965 00000 n +0000576030 00000 n +0000579558 00000 n +0000578915 00000 n +0000576245 00000 n +0000579041 00000 n +0000579106 00000 n +0000579235 00000 n +0000579299 00000 n +0000579364 00000 n +0000579429 00000 n +0000579493 00000 n +0000581186 00000 n +0000580865 00000 n +0000579698 00000 n +0000580991 00000 n +0000581056 00000 n +0000581121 00000 n +0000791609 00000 n +0000581438 00000 n +0000592782 00000 n +0000600371 00000 n +0000602672 00000 n +0000602641 00000 n +0000606358 00000 n +0000615798 00000 n +0000626305 00000 n +0000638046 00000 n +0000650763 00000 n +0000669830 00000 n +0000690717 00000 n +0000712860 00000 n +0000730755 00000 n +0000733586 00000 n +0000733356 00000 n +0000760893 00000 n +0000788004 00000 n +0000791689 00000 n +0000791813 00000 n +0000791939 00000 n +0000792065 00000 n +0000792191 00000 n +0000792280 00000 n +0000792381 00000 n +0000809554 00000 n +0000829956 00000 n +0000829997 00000 n +0000830037 00000 n +0000830171 00000 n trailer << /Size 2296 /Root 2294 0 R /Info 2295 0 R -/ID [ ] +/ID [ ] >> startxref -830163 +830429 %%EOF From 66d5a4ad869f506ead8438a50432dc95ae51ad23 Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Wed, 18 Nov 2009 01:16:58 +0000 Subject: [PATCH 04/18] update --- doc/private/SRCID | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/private/SRCID b/doc/private/SRCID index 24117f2f72..5c975a9da6 100644 --- a/doc/private/SRCID +++ b/doc/private/SRCID @@ -1,6 +1,6 @@ -# $Id: SRCID,v 1.13 2009/11/18 00:19:05 tbox Exp $ +# $Id: SRCID,v 1.14 2009/11/18 01:16:58 tbox Exp $ # # This file must follow /bin/sh rules. It is imported directly via # configure. # -SRCID="( $Date: 2009/11/18 00:19:05 $ )" +SRCID="( $Date: 2009/11/18 01:16:58 $ )" From 2ad776a5c49d86c5ea43b95ff1600e9088cfab52 Mon Sep 17 00:00:00 2001 From: Evan Hunt Date: Wed, 18 Nov 2009 16:46:10 +0000 Subject: [PATCH 05/18] changed age to 0 --- lib/dns/api | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dns/api b/lib/dns/api index 737fa9b946..ddd8d2fd28 100644 --- a/lib/dns/api +++ b/lib/dns/api @@ -1,3 +1,3 @@ LIBINTERFACE = 62 LIBREVISION = 0 -LIBAGE = 1 +LIBAGE = 0 From e83a7cabc30e71127adb6f0334c3004d0e8f1b29 Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Wed, 18 Nov 2009 16:52:52 +0000 Subject: [PATCH 06/18] update --- doc/private/SRCID | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/private/SRCID b/doc/private/SRCID index 5c975a9da6..2612a46685 100644 --- a/doc/private/SRCID +++ b/doc/private/SRCID @@ -1,6 +1,6 @@ -# $Id: SRCID,v 1.14 2009/11/18 01:16:58 tbox Exp $ +# $Id: SRCID,v 1.15 2009/11/18 16:52:52 tbox Exp $ # # This file must follow /bin/sh rules. It is imported directly via # configure. # -SRCID="( $Date: 2009/11/18 01:16:58 $ )" +SRCID="( $Date: 2009/11/18 16:52:52 $ )" From b08325a7f3092cca1131e1a04a43a4ecef713e29 Mon Sep 17 00:00:00 2001 From: Evan Hunt Date: Wed, 18 Nov 2009 21:22:31 +0000 Subject: [PATCH 07/18] 2773. [bug] In autosigned zones, the SOA could be signed with the KSK. [RT #20628] --- CHANGES | 3 +++ bin/named/update.c | 4 ++-- lib/dns/zone.c | 4 ++-- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/CHANGES b/CHANGES index 0e2440074d..7bc19c2924 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +2773. [bug] In autosigned zones, the SOA could be signed + with the KSK. [RT #20628] + --- 9.7.0b3 released --- 2772. [security] When validating, track whether pending data was from diff --git a/bin/named/update.c b/bin/named/update.c index d7a054beb2..a31606a4a9 100644 --- a/bin/named/update.c +++ b/bin/named/update.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: update.c,v 1.168 2009/11/09 01:28:32 each Exp $ */ +/* $Id: update.c,v 1.169 2009/11/18 21:22:31 each Exp $ */ #include @@ -1926,7 +1926,7 @@ add_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db, if (type == dns_rdatatype_dnskey) { if (!KSK(keys[i]) && keyset_kskonly) continue; - } else if (!KSK(keys[i])) + } else if (KSK(keys[i])) continue; } else if (REVOKE(keys[i]) && type != dns_rdatatype_dnskey) continue; diff --git a/lib/dns/zone.c b/lib/dns/zone.c index ea26c1e5ff..1473360003 100644 --- a/lib/dns/zone.c +++ b/lib/dns/zone.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: zone.c,v 1.529 2009/11/12 23:47:59 tbox Exp $ */ +/* $Id: zone.c,v 1.530 2009/11/18 21:22:31 each Exp $ */ /*! \file */ @@ -4586,7 +4586,7 @@ add_sigs(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name, if (type == dns_rdatatype_dnskey) { if (!KSK(keys[i]) && keyset_kskonly) continue; - } else if (!KSK(keys[i])) + } else if (KSK(keys[i])) continue; } else if (REVOKE(keys[i]) && type != dns_rdatatype_dnskey) continue; From 3e084fed8d7017a0873e9c538a2c736fd96a4ada Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Wed, 18 Nov 2009 22:16:59 +0000 Subject: [PATCH 08/18] update --- doc/private/SRCID | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/private/SRCID b/doc/private/SRCID index 2612a46685..712f3c328b 100644 --- a/doc/private/SRCID +++ b/doc/private/SRCID @@ -1,6 +1,6 @@ -# $Id: SRCID,v 1.15 2009/11/18 16:52:52 tbox Exp $ +# $Id: SRCID,v 1.16 2009/11/18 22:16:59 tbox Exp $ # # This file must follow /bin/sh rules. It is imported directly via # configure. # -SRCID="( $Date: 2009/11/18 16:52:52 $ )" +SRCID="( $Date: 2009/11/18 22:16:59 $ )" From ae5b67a0c07b0c4ee351d6d5d7d52d252ccec446 Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Wed, 18 Nov 2009 23:19:11 +0000 Subject: [PATCH 09/18] auto update --- doc/private/branches | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/private/branches b/doc/private/branches index 9bf8e7f89b..a3927119d4 100644 --- a/doc/private/branches +++ b/doc/private/branches @@ -281,6 +281,7 @@ rt20474 new each // 2009-10-27 05:30 +0000 rt20526 new each // 2009-11-06 22:50 +0000 rt20541 new marka // 2009-10-30 02:28 +0000 rt20603 new sar // 2009-11-12 01:38 +0000 +rt20609 new marka // 2009-11-18 08:46 +0000 rt20619 new sar // 2009-11-16 19:51 +0000 shane_dbbackend open skan open explorer From c95f536d78842fbc8ebcef653d88e1f2270054f8 Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Wed, 18 Nov 2009 23:30:33 +0000 Subject: [PATCH 10/18] newcopyrights --- util/copyrights | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/util/copyrights b/util/copyrights index 2d08a6d40f..19d6d6488d 100644 --- a/util/copyrights +++ b/util/copyrights @@ -763,6 +763,20 @@ ./bin/tests/system/nsupdate/setup.sh SH 2000,2001,2004,2007,2009 ./bin/tests/system/nsupdate/tests.sh SH 2000,2001,2004,2007,2009 ./bin/tests/system/nsupdate/update_test.pl PERL 2000,2001,2004,2007 +./bin/tests/system/pending/clean.sh SH 2009 +./bin/tests/system/pending/ns1/named.conf CONF-C 2009 +./bin/tests/system/pending/ns1/root.db.in ZONE 2009 +./bin/tests/system/pending/ns1/sign.sh SH 2009 +./bin/tests/system/pending/ns2/example.db.in ZONE 2009 +./bin/tests/system/pending/ns2/named.conf CONF-C 2009 +./bin/tests/system/pending/ns2/sign.sh SH 2009 +./bin/tests/system/pending/ns3/hostile.db ZONE 2009 +./bin/tests/system/pending/ns3/mail.example.db ZONE 2009 +./bin/tests/system/pending/ns3/named.conf CONF-C 2009 +./bin/tests/system/pending/ns4/named.conf CONF-C 2009 +./bin/tests/system/pending/prereq.sh SH 2009 +./bin/tests/system/pending/setup.sh SH 2009 +./bin/tests/system/pending/tests.sh SH 2009 ./bin/tests/system/relay/README TXT.BRIEF 2000,2001,2004 ./bin/tests/system/relay/clean.sh SH 2000,2001,2004,2007 ./bin/tests/system/relay/ns1/.cvsignore X 2000,2001 From fe2b9bf5702a2cbc9127b8f9e92c2e6102dcfb9a Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Wed, 18 Nov 2009 23:48:07 +0000 Subject: [PATCH 11/18] update copyright notice --- bin/tests/system/pending/ns1/root.db.in | 4 ++-- bin/tests/system/pending/ns2/named.conf | 5 ++--- bin/tests/system/pending/ns2/sign.sh | 5 ++--- bin/tests/system/pending/ns3/named.conf | 5 ++--- bin/tests/system/pending/prereq.sh | 5 ++--- bin/tests/system/pending/tests.sh | 5 ++--- lib/dns/resolver.c | 16 ++++++++-------- 7 files changed, 20 insertions(+), 25 deletions(-) diff --git a/bin/tests/system/pending/ns1/root.db.in b/bin/tests/system/pending/ns1/root.db.in index d32be8a76c..a53b09ac7f 100644 --- a/bin/tests/system/pending/ns1/root.db.in +++ b/bin/tests/system/pending/ns1/root.db.in @@ -1,4 +1,4 @@ -; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") +; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") ; ; Permission to use, copy, modify, and/or distribute this software for any ; purpose with or without fee is hereby granted, provided that the above @@ -12,7 +12,7 @@ ; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR ; PERFORMANCE OF THIS SOFTWARE. -; $Id: root.db.in,v 1.2 2009/11/17 23:55:18 marka Exp $ +; $Id: root.db.in,v 1.3 2009/11/18 23:48:06 tbox Exp $ $TTL 30 . IN SOA marka.isc.org. a.root.servers.nil. ( diff --git a/bin/tests/system/pending/ns2/named.conf b/bin/tests/system/pending/ns2/named.conf index 5ed012459f..cb63caa6e0 100644 --- a/bin/tests/system/pending/ns2/named.conf +++ b/bin/tests/system/pending/ns2/named.conf @@ -1,6 +1,5 @@ /* - * Copyright (C) 2004, 2006-2008 Internet Systems Consortium, Inc. ("ISC") - * Copyright (C) 2000-2002 Internet Software Consortium. + * Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") * * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above @@ -15,7 +14,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */ +/* $Id: named.conf,v 1.3 2009/11/18 23:48:06 tbox Exp $ */ // NS2 diff --git a/bin/tests/system/pending/ns2/sign.sh b/bin/tests/system/pending/ns2/sign.sh index ea8af0a8a5..3bd1102f85 100644 --- a/bin/tests/system/pending/ns2/sign.sh +++ b/bin/tests/system/pending/ns2/sign.sh @@ -1,7 +1,6 @@ #!/bin/sh -e # -# Copyright (C) 2004, 2006-2009 Internet Systems Consortium, Inc. ("ISC") -# Copyright (C) 2000-2003 Internet Software Consortium. +# Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") # # Permission to use, copy, modify, and/or distribute this software for any # purpose with or without fee is hereby granted, provided that the above @@ -15,7 +14,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: sign.sh,v 1.2 2009/11/17 23:55:18 marka Exp $ +# $Id: sign.sh,v 1.3 2009/11/18 23:48:07 tbox Exp $ SYSTEMTESTTOP=../.. . $SYSTEMTESTTOP/conf.sh diff --git a/bin/tests/system/pending/ns3/named.conf b/bin/tests/system/pending/ns3/named.conf index 6d39ae9b87..659746a4b7 100644 --- a/bin/tests/system/pending/ns3/named.conf +++ b/bin/tests/system/pending/ns3/named.conf @@ -1,6 +1,5 @@ /* - * Copyright (C) 2004, 2006-2008 Internet Systems Consortium, Inc. ("ISC") - * Copyright (C) 2000-2002 Internet Software Consortium. + * Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") * * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above @@ -15,7 +14,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */ +/* $Id: named.conf,v 1.3 2009/11/18 23:48:07 tbox Exp $ */ // NS2 diff --git a/bin/tests/system/pending/prereq.sh b/bin/tests/system/pending/prereq.sh index 1e1b22ad5e..b05b622ed7 100644 --- a/bin/tests/system/pending/prereq.sh +++ b/bin/tests/system/pending/prereq.sh @@ -1,7 +1,6 @@ #!/bin/sh # -# Copyright (C) 2004, 2006, 2007, 2009 Internet Systems Consortium, Inc. ("ISC") -# Copyright (C) 2000-2002 Internet Software Consortium. +# Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") # # Permission to use, copy, modify, and/or distribute this software for any # purpose with or without fee is hereby granted, provided that the above @@ -15,7 +14,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: prereq.sh,v 1.2 2009/11/17 23:55:18 marka Exp $ +# $Id: prereq.sh,v 1.3 2009/11/18 23:48:06 tbox Exp $ ../../../tools/genrandom 400 random.data diff --git a/bin/tests/system/pending/tests.sh b/bin/tests/system/pending/tests.sh index 58019a9d48..e56b4079dc 100644 --- a/bin/tests/system/pending/tests.sh +++ b/bin/tests/system/pending/tests.sh @@ -1,7 +1,6 @@ #!/bin/sh # -# Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC") -# Copyright (C) 2000-2002 Internet Software Consortium. +# Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") # # Permission to use, copy, modify, and/or distribute this software for any # purpose with or without fee is hereby granted, provided that the above @@ -15,7 +14,7 @@ # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR # PERFORMANCE OF THIS SOFTWARE. -# $Id: tests.sh,v 1.2 2009/11/17 23:55:18 marka Exp $ +# $Id: tests.sh,v 1.3 2009/11/18 23:48:06 tbox Exp $ SYSTEMTESTTOP=.. . $SYSTEMTESTTOP/conf.sh diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c index eac42b8b5b..4381d03913 100644 --- a/lib/dns/resolver.c +++ b/lib/dns/resolver.c @@ -15,7 +15,7 @@ * PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: resolver.c,v 1.412 2009/11/17 23:55:18 marka Exp $ */ +/* $Id: resolver.c,v 1.413 2009/11/18 23:48:07 tbox Exp $ */ /*! \file */ @@ -4408,14 +4408,14 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo, if (rdataset->trust == dns_trust_additional && sigrdataset == NULL && EXTERNAL(rdataset)) continue; - + /* - * XXXMPA: If we store as "answer" after validating - * then we need to do bailiwick processing and - * also need to track whether RRsets are in or - * out of bailiwick. This will require a another - * pending trust level. - * + * XXXMPA: If we store as "answer" after validating + * then we need to do bailiwick processing and + * also need to track whether RRsets are in or + * out of bailiwick. This will require a another + * pending trust level. + * * Cache this rdataset/sigrdataset pair as * pending data. Track whether it was additional * or not. From f95bdcf65d90ce83cee440e2342a886baca6e16b Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Thu, 19 Nov 2009 00:19:08 +0000 Subject: [PATCH 12/18] update --- doc/private/SRCID | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/private/SRCID b/doc/private/SRCID index 712f3c328b..78f9b4b99d 100644 --- a/doc/private/SRCID +++ b/doc/private/SRCID @@ -1,6 +1,6 @@ -# $Id: SRCID,v 1.16 2009/11/18 22:16:59 tbox Exp $ +# $Id: SRCID,v 1.17 2009/11/19 00:19:08 tbox Exp $ # # This file must follow /bin/sh rules. It is imported directly via # configure. # -SRCID="( $Date: 2009/11/18 22:16:59 $ )" +SRCID="( $Date: 2009/11/19 00:19:08 $ )" From f7e3edb15a73e285f34147b0092c63546c5dfbea Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 19 Nov 2009 05:03:52 +0000 Subject: [PATCH 13/18] cleanup --- doc/draft/draft-baba-dnsext-acl-reqts-01.txt | 336 --- doc/draft/draft-daigle-napstr-04.txt | 1232 ----------- doc/draft/draft-danisch-dns-rr-smtp-03.txt | 1960 ----------------- doc/draft/draft-dnsext-opcode-discover-02.txt | 241 -- .../draft-dolmatov-dnsext-dnssec-gost-00.txt | 370 ---- .../draft-durand-dnsop-dynreverse-00.txt | 240 -- doc/draft/draft-ietf-dnsext-2929bis-01.txt | 928 -------- ...f-dnsext-dnssec-2535typecode-change-06.txt | 442 ---- ...t-ietf-dnsext-dnssec-online-signing-02.txt | 616 ------ .../draft-ietf-dnsext-dnssec-trans-02.txt | 839 ------- doc/draft/draft-ietf-dnsext-ds-sha256-05.txt | 504 ----- ...raft-ietf-dnsext-forgery-resilience-02.txt | 17 - ...-ietf-dnsext-keyrr-key-signing-flag-12.txt | 560 ----- doc/rfc/index | 8 + doc/rfc/rfc3755.txt | 507 +++++ .../rfc4471.txt} | 876 ++++---- .../rfc4955.txt} | 671 +----- .../rfc4956.txt} | 845 +++---- .../rfc5001.txt} | 647 ++---- doc/rfc/rfc5452.txt | 1011 +++++++++ .../rfc5625.txt} | 583 +++-- 21 files changed, 2954 insertions(+), 10479 deletions(-) delete mode 100644 doc/draft/draft-baba-dnsext-acl-reqts-01.txt delete mode 100644 doc/draft/draft-daigle-napstr-04.txt delete mode 100644 doc/draft/draft-danisch-dns-rr-smtp-03.txt delete mode 100644 doc/draft/draft-dnsext-opcode-discover-02.txt delete mode 100644 doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt delete mode 100644 doc/draft/draft-durand-dnsop-dynreverse-00.txt delete mode 100644 doc/draft/draft-ietf-dnsext-2929bis-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt delete mode 100644 doc/draft/draft-ietf-dnsext-ds-sha256-05.txt delete mode 100644 doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt delete mode 100644 doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt create mode 100644 doc/rfc/rfc3755.txt rename doc/{draft/draft-ietf-dnsext-dns-name-p-s-00.txt => rfc/rfc4471.txt} (60%) rename doc/{draft/draft-ietf-dnsext-dnssec-experiments-03.txt => rfc/rfc4955.txt} (54%) rename doc/{draft/draft-ietf-dnsext-dnssec-opt-in-07.txt => rfc/rfc4956.txt} (59%) rename doc/{draft/draft-ietf-dnsext-nsid-01.txt => rfc/rfc5001.txt} (68%) create mode 100644 doc/rfc/rfc5452.txt rename doc/{draft/draft-ietf-dnsext-dnsproxy-05.txt => rfc/rfc5625.txt} (55%) diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt deleted file mode 100644 index 1030e5782e..0000000000 --- a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt +++ /dev/null @@ -1,336 +0,0 @@ - - - - -Internet-Draft T. Baba -Expires: March 11, 2004 NTT Data - September 11, 2003 - - - Requirements for Access Control in Domain Name Systems - draft-baba-dnsext-acl-reqts-01.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - Distribution of this memo is unlimited. - - This Internet-Draft will expire on March 11, 2004. - -Abstract - - This document describes the requirements for access control - mechanisms in the Domain Name System (DNS), which authenticate - clients and then allow or deny access to resource records in the - zone according to the access control list (ACL). - -1. Introduction - - The Domain Name System (DNS) is a hierarchical, distributed, highly - available database used for bi-directional mapping between domain - names and IP addresses, for email routing, and for other information - [RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined - to authenticate the data in DNS and provide key distribution services - using SIG, KEY, and NXT resource records (RRs) [RFC2535]. - - - -Baba Expires March 11, 2004 [Page 1] - -Internet-Draft DNS Access Control Requirements September 2003 - - - At the 28th IETF Meeting in Houston in 1993, DNS security design team - started a discussion about DNSSEC and agreed to accept the assumption - that "DNS data is public". Accordingly, confidentiality for queries - or responses is not provided by DNSSEC, nor are any sort of access - control lists or other means to differentiate inquirers. However, - about ten years has passed, access control in DNS has been more - important than before. Currently, new RRs are proposed to add new - functionality to DNS such as ENUM [RFC2916]. Such new RRs may - contain private information. Thus, DNS access control will be - needed. - - Furthermore, with DNS access control mechanism, access from - unauthorized clients can be blocked when they perform DNS name - resolution. Thus, for example, Denial of Service (DoS) attacks - against a server used by a closed user group can be prevented using - this mechanism if IP address of the server is not revealed by other - sources. - - This document describes the requirements for access control - mechanisms in DNS. - -2. Terminology - - AC-aware client - This is the client that understands the DNS access control - extensions. This client may be an end host which has a stub - resolver, or a cashing/recursive name server which has a - full-service resolver. - - AC-aware server - This is the authoritative name server that understands the DNS - access control extensions. - - ACE - An Access Control Entry. This is the smallest unit of access - control policy. It grants or denies a given set of access - rights to a set of principals. An ACE is a component of an ACL, - which is associated with a resource. - - ACL - An Access Control List. This contains all of the access control - policies which are directly associated with a particular - resource. These policies are expressed as ACEs. - - Client - A program or host which issues DNS requests and accepts its - responses. A client may be an end host or a cashing/recursive name - server. - - - -Baba Expires March 11, 2004 [Page 2] - -Internet-Draft DNS Access Control Requirements September 2003 - - - RRset - All resource records (RRs) having the same NAME, CLASS and TYPE - are called a Resource Record Set (RRset). - -3. Requirements - - This section describes the requirements for access control in DNS. - -3.1 Authentication - -3.1.1 Client Authentication Mechanism - - The AC-aware server must identify AC-aware clients based on IP - address and/or domain name (user ID or host name), and must - authenticate them using strong authentication mechanism such as - digital signature or message authentication code (MAC). - - SIG(0) RR [RFC2931] contains a domain name associated with sender's - public key in its signer's name field, and TSIG RR [RFC2845] also - contains a domain name associated with shared secret key in its key - name field. Each of these domain names can be a host name or a user - name, and can be used as a sender's identifier for access control. - Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for - message authentication. These mechanisms can be used to authenticate - AC-aware clients. - - Server authentication may be also provided. - -3.1.2 End-to-End Authentication - - In current DNS model, caching/recursive name servers are deployed - between end hosts and authoritative name servers. Although - authoritative servers can authenticate caching/recursive name servers - using SIG(0) or TSIG, they cannot authenticate end hosts behind them. - For end-to-end authentication, the mechanism for an end host to - discover the target authoritative name server and directly access to - it bypassing caching/recursive name servers is needed. For example, - an end host can get the IP addresses of the authoritative name - servers by retrieving NS RRs for the zone via local caching/recursive - name server. - - In many enterprise networks, however, there are firewalls that block - all DNS packets other than those going to/from the particular - caching/recursive servers. To deal with this problem, one can - implement packet forwarding function on the caching/recursive servers - and enable end-to-end authentication via the caching/recursive - servers. - - - - -Baba Expires March 11, 2004 [Page 3] - -Internet-Draft DNS Access Control Requirements September 2003 - - -3.1.3 Authentication Key Retrieval - - Keys which are used to authenticate clients should be able to be - automatically retrieved. The KEY RR is used to store a public key - for a zone or a host that is associated with a domain name. SIG(0) - RR uses a public key in KEY RR for verifying the signature. If - DNSSEC is available, the KEY RR would be protected by the SIG RR. - KEY RR or newly defined RR can be used to automatic key retrieval. - -3.2 Confidentiality - -3.2.1 Data Encryption - - To avoid disclosure to eavesdroppers, the response containing the - RRsets which are restricted to access from particular users should be - encrypted. Currently, no encryption mechanism is specified in DNS. - Therefore, new RRs should be defined for DNS message encryption. - Instead, IPsec [RFC2401] can be used to provide confidentiality if - name server and resolver can set up security associations dynamically - using IPsec API [IPSECAPI] when encryption is required. - - In case encryption is applied, entire DNS message including DNS - header should be encrypted to hide information including error code. - - Query encryption may be also provided for hiding query information. - -3.2.2 Key Exchange - - If DNS message encryption is provided, automatic key exchange - mechanism should be also provided. [RFC2930] specifies a TKEY RR - that can be used to establish and delete shared secret keys used by - TSIG between a client and a server. With minor extensions, TKEY can - be used to establish shared secret keys used for message encryption. - -3.2.3 Caching - - The RRset that is restricted to access from particular users must not - be cached. To avoid caching, the TTL of the RR that is restricted to - access should be set to zero during transit. - -3.3 Access Control - -3.3.1 Granularity of Access Control - - Control of access on a per-user/per-host granularity must be - supported. Control of access to individual RRset (not just the - entire zone) must be also supported. However, SOA, NS, SIG, NXT, - KEY, and DS RRs must be publicly accessible to avoid unexpected - results. - - -Baba Expires March 11, 2004 [Page 4] - -Internet-Draft DNS Access Control Requirements September 2003 - - -3.3.2 ACL Representation - - Access Control List (ACL) format must be standardized so that both - the primary and secondary AC-aware servers can recognize the same - ACL. Although ACL may appear in or out of zone data, it must be - transferred to the secondary AC-aware server with associated zone - data. It is a good idea to contain ACL in zone data, because ACL can - be transferred with zone data using existing zone transfer mechanisms - automatically. However, ACL must not be published except for - authorized secondary master servers. - - In zone data master files, ACL should be specified using TXT RRs or - newly defined RRs. In each access control entry (ACE), authorized - entities (host or user) must be described using domain name (host - name, user name, or IP address in in-addr.arpa/ip6.arpa format). - There may be other access control attributes such as access time. - - It must be possible to create publicly readable entries, which may be - read even by unauthenticated clients. - -3.3.3 Zone/ACL Transfer - - As mentioned above, ACL should be transferred from a primary AC-aware - server to a secondary AC-aware server with associated zone data. - When an AC-aware server receives a zone/ACL transfer request, the - server must authenticate the client, and should encrypt the zone - data and associated ACL during transfer. - -3.4 Backward/co-existence Compatibility - - Any new protocols to be defined for access control in DNS must be - backward compatible with existing DNS protocol. AC-aware servers - must be able to process normal DNS query without authentication, and - must respond if retrieving RRset is publicly accessible. - - Modifications to root/gTLD/ccTLD name servers are not allowed. - -4. Security Considerations - - This document discusses the requirements for access control - mechanisms in DNS. - -5. Acknowledgements - - This work is funded by the Telecommunications Advancement - Organization of Japan (TAO). - - The author would like to thank the members of the NTT DATA network - security team for their important contribution to this work. - - -Baba Expires March 11, 2004 [Page 5] - -Internet-Draft DNS Access Control Requirements September 2003 - - -6. References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, - September 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", - RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s)", RFC 2931, September 2000. - - [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API", - draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in - Progress. - - -Author's Address - - Tatsuya Baba - NTT Data Corporation - Research and Development Headquarters - Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku, - Tokyo 104-0033, Japan - - Tel: +81 3 3523 8081 - Fax: +81 3 3523 8090 - Email: babatt@nttdata.co.jp - - - - - - - - -Baba Expires March 11, 2004 [Page 6] diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt deleted file mode 100644 index fffa8a5f20..0000000000 --- a/doc/draft/draft-daigle-napstr-04.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - -Network Working Group L. Daigle -Internet-Draft A. Newton -Expires: August 15, 2004 VeriSign, Inc. - February 15, 2004 - - - Domain-based Application Service Location Using SRV RRs and the - Dynamic Delegation Discovery Service (DDDS) - draft-daigle-napstr-04.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 15, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This memo defines a generalized mechanism for application service - naming that allows service location without relying on rigid domain - naming conventions (so-called name hacks). The proposal defines a - Dynamic Delegation Discovery System (DDDS) Application to map domain - name, application service name, and application protocol to target - server and port, dynamically. - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 1] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . 4 - 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . . 5 - 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . . . . 5 - 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . . . . 5 - 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . . . . 5 - 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . . . . 6 - 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . . . . 6 - 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1 Guidelines for Application Protocol Developers . . . . . . . 7 - 3.1.1 Registration of application service and protocol tags . . . 7 - 3.1.2 Definition of conditions for retry/failure . . . . . . . . . 8 - 3.1.3 Server identification and handshake . . . . . . . . . . . . 8 - 3.2 Guidelines for Domain Administrators . . . . . . . . . . . . 8 - 3.3 Guidelines for Client Software Writers . . . . . . . . . . . 9 - 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2 Service Discovery within a Domain . . . . . . . . . . . . . 10 - 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10 - 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 12 - 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . . 12 - 5. Motivation and Discussion . . . . . . . . . . . . . . . . . 14 - 5.1 So, why not just SRV records? . . . . . . . . . . . . . . . 15 - 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . . 15 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 16 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 - A. Application Service Location Application of DDDS . . . . . . 18 - A.1 Application Unique String . . . . . . . . . . . . . . . . . 18 - A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 18 - A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 18 - A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 19 - A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19 - A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 20 - A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 20 - A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 20 - B. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . 20 - B.1 Finding the first (best) target . . . . . . . . . . . . . . 20 - B.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 21 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 - - - - -Daigle & Newton Expires August 15, 2004 [Page 2] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -1. Introduction - - This memo defines a generalized mechanism for application service - naming that allows service location without relying on rigid domain - naming conventions (so-called name hacks). The proposal defines a - Dynamic Delegation Discovery System (DDDS -- see [6]) Application to - map domain name, application service name, and application protocol - to target server and port, dynamically. - - As discussed in Section 5, existing approaches to using DNS records - to dynamically determining the current host for a given application - service are limited in terms of the use cases supported. To address - some of the limitations, this document defines a DDDS Application to - map service+protocol+domain to specific server addresses using both - NAPTR [7] and SRV ([5]) DNS resource records. This can be viewed as - a more general version of the use of SRV and/or a very restricted - application of the use of NAPTR resource records. - - 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 ([2]). - -2. Straightforward-NAPTR (S-NAPTR) Specification - - The precise details of the specification of this DDDS application are - given in Appendix A. This section defines the usage of the DDDS - application. - -2.1 Key Terms - - An "application service" is a generic term for some type of - application, indpendent of the protocol that may be used to offer it. - Each application service will be associated with an IANA-registered - tag. For example, instant messaging is a type of application - service, which can be implemented by many different application-layer - protocols, and the tag "IM" (used as an illustration here) could be - registered for it. - - An "application protocol" is used to implement the application - service. These are also associated with IANA-registered tags. In - the case where multiple transports are available for the application, - separate tags should be defined for each transport. - - The intention is that the combination of application service and - protocol tags should be specific enough that finding a known pair - (e.g., "IM:ProtC") is sufficient for a client to identify a server - with which it can communicate. - - - - -Daigle & Newton Expires August 15, 2004 [Page 3] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - Some protocols support multiple application services. For example, - LDAP is an application protocol, and can be found supporting various - services (e.g., "whitepages", "directory enabled networking", etc). - -2.2 S-NAPTR DDDS Application Usage - - As outlined in Appendix A, NAPTR records are used to store - application service+protocol information for a given domain. - Following the DDDS standard, these records are looked up, and the - rewrite rules (contained in the NAPTR records) are used to determine - the successive DNS lookups, until a desirable target is found. - - For the rest of this section, refer to the set of NAPTR resource - records for example.com shown in the figure below. - - example.com. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "" "WP:whois++" "" bunyip.example. - IN NAPTR 100 20 "s" "WP:ldap" "" _ldap._tcp.myldap.example.com. - IN NAPTR 200 10 "" "IM:protA" "" someisp.example. - IN NAPTR 200 30 "a" "IM:protB" "" myprotB.example.com. - - -2.2.1 Ordering and Preference - - A client retrieves all of the NAPTR records associated with the - target domain name (example.com, above). These are to be sorted in - terms of increasing ORDER, and increasing PREF within each ORDER. - -2.2.2 Matching and non-Matching NAPTR Records - - Starting with the first sorted NAPTR record, the client examines the - SERVICE field to find a match. In the case of the S-NAPTR DDDS - application, that means a SERVICE field that includes the tags for - the desired application service and a supported application protocol. - - If more than one NAPTR record matches, they are processed in - increasing sort order. - -2.2.3 Terminal and Non-Terminal NAPTR Records - - A NAPTR record with an empty FLAG field is "non-terminal". That is, - more NAPTR RR lookups are to be performed. Thus, to process a NAPTR - record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is - used as the target of the next DNS lookup -- for NAPTR RRs. - - In S-NAPTR, the only terminal flags are "S" and "A". These are - called "terminal" NAPTR lookups because they denote the end of the - - - -Daigle & Newton Expires August 15, 2004 [Page 4] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - DDDS/NAPTR processing rules. In the case of an "S" flag, the - REPLACEMENT field is used as the target of a DNS query for SRV RRs, - and normal SRV processing is applied. In the case of an "A" flag, an - address record is sought for the REPLACEMENT field target (and the - default protocol port is assumed). - -2.2.4 S-NAPTR and Successive Resolution - - As shown in the example NAPTR RR set above, it is possible to have - multiple possible targets for a single application service+protocol - pair. These are to be pursued in order until a server is - successfully contacted or all possible matching NAPTR records have - been successively pursued to terminal lookups and servers contacted. - That is, a client must backtrack and attempt other resolution paths - in the case of failure. - - "Failure" is declared, and backtracking must be used when - - o the designated remote server (host and port) fail to provide - appropriate security credentials for the *originating* domain - - o connection to the designated remote server otherwise fails -- the - specifics terms of which are defined when an application protocol - is registered - - o the S-NAPTR-designated DNS lookup fails to yield expected results - -- e.g., no A RR for an "A" target, no SRV record for an "S" - target, or no NAPTR record with appropriate application service - and protocol for a NAPTR lookup. Except in the case of the very - first NAPTR lookup, this last is a configuration error: the fact - that example.com has a NAPTR record pointing to "bunyip.example" - for the "WP:Whois++" service and protocol means the administrator - of example.com believes that service exists. If bunyip.example - has no "WP:Whois++" NAPTR record, the application client MUST - backtrack and try the next available "WP:Whois++" option from - example.com. As there is none, the whole resolution fails. - - An application client first queries for the NAPTR RRs for the domain - of a named application service. The application client MUST select - one protocol to choose The PREF field of the NAPTR RRs may be used by - the domain administrator to The first DNS query is for the NAPTR RRs - in the original target domain (example.com, above). - -2.2.5 Clients Supporting Multiple Protocols - - In the case of an application client that supports more than one - protocol for a given application service, it MUST pursue S-NAPTR - resolution completely for one protocol before trying another.j It MAY - - - -Daigle & Newton Expires August 15, 2004 [Page 5] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - choose which protocol to try first based on its own preference, or - from the PREF ranking in the first set of NAPTR records (i.e., those - for the target named domain). However, the chosen protocol MUST be - listed in that first NAPTR RR set. - - That is, what the client MUST NOT do is start looking for one - protocol, observe that a successive NAPTR RR set supports another of - its preferred protocols, and continue the S-NAPTR resolution based on - that protocol. For example, even if someisp.example offers the "IM" - service with protocol "ProtB", there is no reason to believe it does - so on behalf of example.com (since there is no such pointer in - example.com's NAPTR RR set). - -3. Guidelines - -3.1 Guidelines for Application Protocol Developers - - The purpose of S-NAPTR is to provide application standards developers - with a more powerful framework (than SRV RRs alone) for naming - service targets, without requiring each application protocol (or - service) standard to define a separate DDDS application. - - Note that this approach is intended specifically for use when it - makes sense to associate services with particular domain names (e.g., - e-mail addresses, SIP addresses, etc). A non-goal is having all - manner of label mapped into domain names in order to use this. - - Specifically not addressed in this document is how to select the - domain for which the service+protocol is being sought. It is up to - other conventions to define how that might be used (e.g., instant - messaging standards can define what domain to use from IM URIs, how - to step down from foobar.example.com to example.com, and so on, if - that is applicable). - - Although this document proposes a DDDS application that does not use - all the features of NAPTR resource records, it does not mean to imply - that DNS resolvers should fail to implement all aspects of the NAPTR - RR standard. A DDDS application is a client use convention. - - The rest of this section outlines the specific elements that protocol - developers must determine and document in order to make use of S- - NAPTR. - -3.1.1 Registration of application service and protocol tags - - Application protocol developers that wish to make use of S-NAPTR must - make provision to register any relevant application service and - application protocol tags, as described in Section 6. - - - -Daigle & Newton Expires August 15, 2004 [Page 6] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -3.1.2 Definition of conditions for retry/failure - - One other important aspect that must be defined is the expected - behaviour for interacting with the servers that are reached via S- - NAPTR. Specifically, under what circumstances should the client - retry a target that was found via S-NAPTR? What should it consider a - failure that causes it to return to the S-NAPTR process to determine - the next serviceable target (a less preferred target)? - - For example, if the client gets a "connection refused" from a server, - should it retry for some (protocol-dependent) period of time? Or, - should it try the next-preferred target in the S-NAPTR chain of - resolution? Should it only try the next-preferred target if it - receives a protocol-specific permanent error message? - - The most important thing is to select one expected behaviour and - document it as part of the use of S-NAPTR. - - As noted earlier, failure to provide appropriate credentials to - identify the server as being authoritative for the original taret - domain is always considered a failure condition. - -3.1.3 Server identification and handshake - - As noted in Section 7, use of the DNS for server location increases - the importance of using protocol-specific handshakes to determine and - confirm the identity of the server that is eventually reached. - - Therefore, application protocol developers using S-NAPTR should - identify the mechanics of the expected identification handshake when - the client connects to a server found through S-NAPTR. - -3.2 Guidelines for Domain Administrators - - Although S-NAPTR aims to provide a "straightforward" application of - DDDS and use of NAPTR records, it is still possible to create very - complex chains and dependencies with the NAPTR and SRV records. - - Therefore, domain administrators are called upon to use S-NAPTR with - as much restraint as possible, while still achieving their service - design goals. - - The complete set of NAPTR, SRV and A RRs that are "reachable" through - the S-NAPTR process for a particular application service can be - thought of as a "tree". Each NAPTR RR retrieved points to more NAPTR - or SRV records; each SRV record points to several A record lookups. - Even though a particular client can "prune" the tree to use only - those records referring to application protocols supported by the - - - -Daigle & Newton Expires August 15, 2004 [Page 7] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - client, the tree could be quite deep, and retracing the tree to retry - other targets can become expensive if the tree has many branches. - - Therefore, - - o Fewer branches is better: for both NAPTR and SRV records, provide - different targets with varying preferences where appropriate - (e.g., to provide backup services, etc), but don't look for - reasons to provide more. - - o Shallower is better: avoid using NAPTR records to "rename" - services within a zone. Use NAPTR records to identify services - hosted elsewhere (i.e., where you cannot reasonably provide the - SRV records in your own zone). - - -3.3 Guidelines for Client Software Writers - - To properly understand DDDS/NAPTR, an implementor must read [6]. - However, the most important aspect to keep in mind is that, if one - target fails to work for the application, it is expected that the - application will continue through the S-NAPTR tree to try the (less - preferred) alternatives. - -4. Illustrations - -4.1 Use Cases - - The basic intended use cases for which S-NAPTR has been developed - are: - - o Service discovery within a domain. For example, this can be used - to find the "authoritative" server for some type of service within - a domain (see the specific example in Section 4.2). - - o Multiple protocols. This is increasingly common as new - application services are defined. This includes the case of - instant messaging (a service) which can be offered with multiple - protocols (see Section 4.3). - - o Remote hosting. Each of the above use cases applies within the - administration of a single domain. However, one domain operator - may elect to engage another organization to provide an application - service. See Section 4.4 for an example that cannot be served by - SRV records alone. - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 8] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -4.2 Service Discovery within a Domain - - There are occasions when it is useful to be able to determine the - "authoritative" server for a given application service within a - domain. This is "discovery", because there is no a priori knowledge - as to whether or where the service is offered; it is therefore - important to determine the location and characteristics of the - offered service. - - For example, there is growing discussion of having a generic - mechanism for locating the keys or certificates associated with - particular application (servers) operated in (or for) a particular - domain. Here's a hypothetical case for storing application key or - certificate data for a given domain. The premise is that some - credentials registry (CredReg) service has been defined to be a leaf - node service holding the keys/certs for the servers operated by (or - for) the domain. Furthermore, it is assumed that more than one - protocol is available to provide the service for a particular domain. - This DDDS-based approach is used to find the CredReg server that - holds the information. - - Thus, the set of NAPTR records for thinkingcat.example might look - like this: - - thinkingcat.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" theserver.thinkingcat.example. - - Note that another domain, offering the same application service, - might offer it using a different set of application protocols: - - anotherdomain.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" foo.anotherdomain.example. - - -4.3 Multiple Protocols - - As it stands, there are several different protocols proposed for - offering "instant message" services. Assuming that "IM" was - registered as an application service, this DDDS application could be - used to determine the available services for delivering to a target. - - Two particular features of instant messaging should be noted: - - 1. gatewaying is expected to bridge communications across protocols - - 2. instant messaging servers are likely to be operated out of a - - - -Daigle & Newton Expires August 15, 2004 [Page 9] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - different domain than the instant messaging address, and servers - of different protocols may be offered by independent - organizations - - For example, "thinkingcat.example" may support its own servers for - the "ProtA" instant messaging protocol, but rely on outsourcing from - "example.com" for "ProtC" and "ProtB" servers. - - Using this DDDS-based approach, thinkingcat.example can indicate a - preference ranking for the different types of servers for the instant - messaging service, and yet the out-sourcer can independently rank the - preference and ordering of servers. This independence is not - achievable through the use of SRV records alone. - - Thus, to find the IM services for thinkingcat.example, the NAPTR - records for thinkingcat.example are retrieved: - - thinkingcat.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. - IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. - IN NAPTR 100 30 "s" "IM:ProtC" "" _ProtC._tcp.example.com. - - and then the administrators at example.com can manage the preference - rankings of the servers they use to support the ProtB service: - - _ProtB._tcp.example.com. - ;; Pref Weight Port Target - IN SRV 10 0 10001 bigiron.example.com - IN SRV 20 0 10001 backup.im.example.com - IN SRV 30 0 10001 nuclearfallout.australia-isp.example - - -4.4 Remote Hosting - - In the Instant Message hosting example in Section 4.3, the service - owner (thinkingcat.example) had to host pointers to the hosting - service's SRV records in the thinkingcat.example domain. - - A better way to approach this is to have one NAPTR RR in the - thinkingcat.example domain pointing to all the hosted services, and - the hosting domain has NAPTR records for each service to map them to - whatever local hosts it chooses (and may change from time to time). - - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 10] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - thinkingcat.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. - IN NAPTR 100 20 "" "IM:ProtB:ProtC" "" thinkingcat.example.com. - - - and then the administrators at example.com can break out the - individual application protocols and manage the preference rankings - of the servers they use to support the ProtB service (as before): - - thinkingcat.example.com. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "s" "IM:ProtC" "" _ProtC._tcp.example.com. - IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. - - - - _ProtC._tcp.example.com. - ;; Pref Weight Port Target - IN SRV 10 0 10001 bigiron.example.com - IN SRV 20 0 10001 backup.im.example.com - IN SRV 30 0 10001 nuclearfallout.australia-isp.example - - -4.5 Sets of NAPTR RRs - - Note that the above sections assumed that there was one service - available (via S-NAPTR) per domain. Often, that will not be the - case. Assuming thinkingcat.example had the CredReg service set up as - described in Section 4.2 and the instant messaging service set up as - described in Section 4.4, then a client querying for the NAPTR RR set - from thinkingcat.com would get the following answer: - - thinkingcat.example. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. - IN NAPTR 100 20 "" "IM:ProtB:ProtC:" "" thinkingcat.example.com. - IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example. - - Sorting them by increasing "ORDER", the client would look through the - SERVICE strings to determine if there was a NAPTR RR that matched the - application service it was looking for, with an application protocol - it could use. The first (lowest PREF) record that so matched is the - one the client would use to continue. - -4.6 Sample sequence diagram - - Consider the example in Section 4.3. Visually, the sequence of steps - - - -Daigle & Newton Expires August 15, 2004 [Page 11] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - required for the client to reach the final server for a "ProtB" - service for IM for the thinkingcat.example domain is as follows: - - - Client NS for NS for - thinkingcat.example example.com backup.im.example.com - | | | - 1 -------->| | | - 2 <--------| | | - 3 ------------------------------>| | - 4 <------------------------------| | - 5 ------------------------------>| | - 6 <------------------------------| | - 7 ------------------------------>| | - 8 <------------------------------| | - 9 ------------------------------------------------->| - 10 <-------------------------------------------------| - 11 ------------------------------------------------->| - 12 <-------------------------------------------------| - (...) - - - - 1. the name server (NS) for thinkingcat.example is reached with a - request for all NAPTR records - - 2. the server responds with the NAPTR records shown in Section 4.3. - - 3. the second NAPTR record matches the desired criteria; that has an - "s" flag and a replacement fields of "_ProtB._tcp.example.com". - So, the client looks up SRV records for that target, ultimately - making the request of the NS for example.com. - - 4. the response includes the SRV records listed in Section 4.3. - - 5. the client attempts to reach the server with the lowest PREF in - the SRV list -- looking up the A record for the SRV record's - target (bigiron.example.com). - - 6. the example.com NS responds with an error message -- no such - machine! - - 7. the client attempts to reach the second server in the SRV list, - and looks up the A record for backup.im.example.com - - 8. the client gets the A record with the IP address for - backup.im.example.com from example.com's NS. - - - - -Daigle & Newton Expires August 15, 2004 [Page 12] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - 9. the client connects to that IP address, on port 10001 (from the - SRV record), using ProtB over tcp. - - 10. the server responds with an "OK" message. - - 11. the client uses ProtB to challenge that this server has - credentials to operate the service for the original domain - (thinkingcat.example) - - 12. the server responds, and the rest is IM. - - -5. Motivation and Discussion - - Increasingly, application protocol standards are using domain names - to identify server targets, and stipulating that clients should look - up SRV resource records to determine the host and port providing the - server. This enables a distinction between naming an application - service target and actually hosting the server. It also increases - flexibility in hosting the target service: - - o the server may be operated by a completely different organization - without having to list the details of that organization's DNS - setup (SRVs) - - o multiple instances can be set up (e.g., for load balancing or - secondaries) - - o it can be moved from time to time without disrupting clients' - access, etc. - - This is quite useful, but Section 5.1 outlines some of the - limitations inherent in the approach. - - That is, while SRV records can be used to map from a specific service - name and protocol for a specific domain to a specific server, SRV - records are limited to one layer of indirection, and are focused on - server administration rather than on application naming. And, while - the DDDS specification and use of NAPTR allows multiple levels of - redirection before locating the target server machine with an SRV - record, this proposal requires only a subset of NAPTR strictly bound - to domain names, without making use of the REGEXP field of NAPTR. - These restrictions make the client's resolution process much more - predictable and efficient than with some potential uses of NAPTR - records. This is dubbed "S-NAPTR" -- a "S"traightforward use of - NAPTR records. - - - - - -Daigle & Newton Expires August 15, 2004 [Page 13] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -5.1 So, why not just SRV records? - - An expected question at this point is: this is so similar in - structure to SRV records, why are we doing this with DDDS/NAPTR? - - Limitations of SRV include: - - o SRV provides a single layer of indirection -- the outcome of an - SRV lookup is a new domain name for which the A RR is to be found. - - o the purpose of SRV is focused on individual server administration, - not application naming: as stated in [5] "The SRV RR allows - administrators to use several servers for a single domain, to move - services from host to host with little fuss, and to designate some - hosts as primary servers for a service and others as backups." - - o target servers by "service" (e.g., "ldap") and "protocol" (e.g., - "tcp") in a given domain. The definition of these terms implies - specific things (e.g., that protocol should be one of UDP or TCP) - without being precise. Restriction to UDP and TCP is insufficient - for the uses described here. - - The basic answer is that SRV records provide mappings from protocol - names to host and port. The use cases described herein require an - additional layer -- from some service label to servers that may in - fact be hosted within different administrative domains. We could - tweak SRV to say that the next lookup could be something other than - an address record, but that is more complex than is necessary for - most applications of SRV. - -5.2 So, why not just NAPTR records? - - That's a trick question. NAPTR records cannot appear in the wild -- - see [6]. They must be part of a DDDS application. - - The purpose here is to define a single, common mechanism (the DDDS - application) to use NAPTR when all that is desired is simple DNS- - based location of services. This should be easy for applications to - use -- some simple IANA registrations and it's done. - - Also, NAPTR has very powerful tools for expressing "rewrite" rules. - That power (==complexity) makes some protocol designers and service - administrators nervous. The concern is that it can translate into - unintelligible, noodle-like rule sets that are difficult to test and - administer. - - This proposed DDDS application specifically uses a subset of NAPTR's - abilities. Only "replacement" expressions are allowed, not "regular - - - -Daigle & Newton Expires August 15, 2004 [Page 14] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - expressions". - -6. IANA Considerations - - This document calls for 2 IANA registries: one for application - service tags, and one for application protocol tags. - - Application service and protocol tags should be defined in an RFC - (unless the "x-" experimental form is used, in which case they are - unregistered). There are no restrictions placed on the tags other - than that they must conform with the syntax defined below (Appendix - A.5). The IANA registries should list the tags and the RFC that - defines their use. - -7. Security Considerations - - The security of this approach to application service location is only - as good as the security of the DNS servers along the way. If any of - them is compromised, bogus NAPTR and SRV records could be inserted to - redirect clients to unintended destinations. This problem is hardly - unique to S-NAPTR (or NAPTR in general). - - To protect against DNS-vectored attacks, applications should define - some form of end-to-end authentication to ensure that the correct - destination has been reached. Many application protocols such as - HTTPS, BEEP, IMAP, etc... define the necessary handshake mechansims - to accomplish this task. - - The basic mechanism works in the following way: - - 1. During some portion of the protocol handshake, the client sends - to the server the original name of the desired destination (i.e. - no transformations that may have resulted from NAPTR - replacements, SRV targets, or CNAME changes). In certain cases - where the application protocol does not have such a feature but - TLS may be used, it is possible to use the "server_name" TLS - extension. - - 2. The server sends back to the client a credential with the - appropriate name. For X.509 certificates, the name would either - be in the subjectDN or subjectAltName fields. For Kerberos, the - name would be a service principle name. - - 3. Using the matching semantics defined by the application protocol, - the client compares the name in the credential with the name sent - to the server. - - 4. If the names match, there is reasonable assurance that the - - - -Daigle & Newton Expires August 15, 2004 [Page 15] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - correct end point has been reached. - - It is important to note that this document does not define either the - handshake mechanism, the specific credenential naming fields, nor the - name matching semantics. Definitions of S-NAPTR for particular - application protocols MUST define these. - -8. Acknowledgements - - Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for - discussion and input that has (hopefully!) provoked clarifying - revisions of this document. - -References - - [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource - Identifiers (URI): Generic Syntax", RFC 2396, August 1998. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part - One: The Comprehensive DDDS", RFC 3401, October 2002. - - [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part - Three: The Domain Name System (DNS) Database", RFC 3403, October - 2002. - - [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part - Four: The Uniform Resource Identifiers (URI)", RFC 3404, October - 2002. - - - - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 16] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -Authors' Addresses - - Leslie Daigle - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - EMail: leslie@verisignlabs.com; leslie@thinkingcat.com - - - Andrew Newton - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - EMail: anewton@verisignlabs.com - -Appendix A. Application Service Location Application of DDDS - - This section defines the DDDS application, as described in [6]. - -A.1 Application Unique String - - The Application Unique String is domain label for which an - authoritative server for a particular service is sought. - -A.2 First Well Known Rule - - The "First Well Known Rule" is identity -- that is, the output of the - rule is the Application Unique String, the domain label for which the - authoritative server for a particular service is sought. - -A.3 Expected Output - - The expected output of this Application is the information necessary - to connect to authoritative server(s) (host, port, protocol) for an - application service within a given a given domain. - -A.4 Flags - - This DDDS Application uses only 2 of the Flags defined for the - URI/URN Resolution Application ([8]): "S" and "A". No other Flags - are valid. - - Both are for terminal lookups. This means that the Rule is the last - one and that the flag determines what the next stage should be. The - - - -Daigle & Newton Expires August 15, 2004 [Page 17] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - "S" flag means that the output of this Rule is a domain label for - which one or more SRV [5] records exist. "A" means that the output - of the Rule is a domain name and should be used to lookup address - records for that domain. - - Consistent with the DDDS algorithm, if the Flag string is empty the - next lookup is for another NAPTR record (for the replacement target). - -A.5 Service Parameters - - Service Parameters for this Application take the form of a string of - characters that follow this ABNF ([3]): - - service-parms = [ [app-service] *(":" app-protocol)] - app-service = experimental-service / iana-registered-service - app-protocol = experimental-protocol / iana-registered-protocol - experimental-service = "x-" 1*30ALPHANUMSYM - experimental-protocol = "x-" 1*30ALPHANUMSYM - iana-registered-service = ALPHA *31ALPHANUMSYM - iana-registered-protocol = ALPHA *31ALPHANUM - ALPHA = %x41-5A / %x61-7A ; A-Z / a-z - DIGIT = %x30-39 ; 0-9 - SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." - ALPHANUMSYM = ALPHA / DIGIT / SYM - ; The app-service and app-protocol tags are limited to 32 - ; characters and must start with an alphabetic character. - ; The service-parms are considered case-insensitive. - - Thus, the Service Parameters may consist of an empty string, just an - app-service, or an app-service with one or more app-protocol - specifications separated by the ":" symbol. - - Note that this is similar to, but not the same as the syntax used in - the URI DDDS application ([8]). The DDDS DNS database requires each - DDDS application to define the syntax of allowable service strings. - The syntax here is expanded to allow the characters that are valid in - any URI scheme name (see [1]). Since "+" (the separator used in the - RFC3404 service parameter string) is an allowed character for URI - scheme names, ":" is chosen as the separator here. - -A.5.1 Application Services - - The "app-service" must be a registered service [this will be an IANA - registry; this is not the IANA port registry, because we want to - define services for which there is no single protocol, and we don't - want to use up port space for nothing]. - - - - - -Daigle & Newton Expires August 15, 2004 [Page 18] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -A.5.2 Application Protocols - - The protocol identifiers that are valid for the "app-protocol" - production are any standard, registered protocols [IANA registry - again -- is this the list of well known/registered ports?]. - -A.6 Valid Rules - - Only substitution Rules are permitted for this application. That is, - no regular expressions are allowed. - -A.7 Valid Databases - - At present only one DDDS Database is specified for this Application. - [7] specifies a DDDS Database that uses the NAPTR DNS resource record - to contain the rewrite rules. The Keys for this database are encoded - as domain-names. - - The First Well Known Rule produces a domain name, and this is the Key - that is used for the first lookup -- the NAPTR records for that - domain are requested. - - DNS servers MAY interpret Flag values and use that information to - include appropriate NAPTR, SRV or A records in the Additional - Information portion of the DNS packet. Clients are encouraged to - check for additional information but are not required to do so. See - the Additional Information Processing section of [7] for more - information on NAPTR records and the Additional Information section - of a DNS response packet. - -Appendix B. Pseudo pseudocode for S-NAPTR - -B.1 Finding the first (best) target - - Assuming the client supports 1 protocol for a particular application - service, the following pseudocode outlines the expected process to - find the first (best) target for the client, using S-NAPTR. - - - target = [initial domain] - naptr-done = false - - while (not naptr-done) - { - NAPTR-RRset = [DNSlookup of NAPTR RRs for target] - [sort NAPTR-RRset by ORDER, and PREF within each ORDER] - rr-done = false - cur-rr = [first NAPTR RR] - - - -Daigle & Newton Expires August 15, 2004 [Page 19] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - while (not rr-done) - if ([SERVICE field of cur-rr contains desired application - service and application protocol]) - rr-done = true - target= [REPLACEMENT target of NAPTR RR] - else - cur-rr = [next rr in list] - - if (not empty [FLAG in cur-rr]) - naptr-done = true - } - - port = -1 - - if ([FLAG in cur-rr is "S"]) - { - SRV-RRset = [DNSlookup of SRV RRs for target] - [sort SRV-RRset based on PREF] - target = [target of first RR of SRV-RRset] - port = [port in first RR of SRV-RRset] - } - - ; now, whether it was an "S" or an "A" in the NAPTR, we - ; have the target for an A record lookup - - host = [DNSlookup of target] - - return (host, port) - - - -B.2 Finding subsequent targets - - The pseudocode in Appendix B is crafted to find the first, most - preferred, host-port pair for a particular application service an - protocol. If, for any reason, that host-port pair did not work - (connection refused, application-level error), the client is expected - to try the next host-port in the S-NAPTR tree. - - The pseudocode above does not permit retries -- once complete, it - sheds all context of where in the S-NAPTR tree it finished. - Therefore, client software writers could - - o entwine the application-specific protocol with the DNS lookup and - RRset processing described in the pseudocode and continue the S- - NAPTR processing if the application code fails to connect to a - located host-port pair; - - - - -Daigle & Newton Expires August 15, 2004 [Page 20] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - - o use callbacks for the S-NAPTR processing; - - o use an S-NAPTR resolution routine that finds *all* valid servers - for the required application service and protocol from the - originating domain, and provides them in sorted order for the - application to try in order. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 21] - -Internet-Draft draft-daigle-napstr-04 February 2004 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Daigle & Newton Expires August 15, 2004 [Page 22] - diff --git a/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/doc/draft/draft-danisch-dns-rr-smtp-03.txt deleted file mode 100644 index 4a01d91b9a..0000000000 --- a/doc/draft/draft-danisch-dns-rr-smtp-03.txt +++ /dev/null @@ -1,1960 +0,0 @@ - - - -INTERNET-DRAFT Hadmut Danisch -Category: Experimental Oct 2003 -Expires: Apr 1, 2004 - - The RMX DNS RR and method for lightweight SMTP sender authorization - draft-danisch-dns-rr-smtp-03.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - -Abstract - - This memo introduces a new authorization scheme for SMTP e-mail - transport. It is designed to be a simple and robust protection - against e-mail fraud, spam and worms. It is based solely on - organisational security mechanisms and does not require but still - allow use of cryptography. This memo also focuses on security and - privacy problems and requirements in context of spam defense. In - contrast to prior versions of the draft a new RR type is not - required anymore. - - - - - - - - - - - - -Hadmut Danisch Experimental [Page 1] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Table of Contents - - -1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 -2. Problem and threat description . . . . . . . . . . . . . . . . . 4 - 2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4 - 2.1.1 Definition of sender forgery . . . . . . . . . . . 4 - 2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5 - 2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5 - 2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6 - 2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6 - 2.4. Shortcomings of cryptographical approaches . . . . . . . . 7 -3. A DNS based sender address verification . . . . . . . . . . . . 7 - 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Envelope vs. header sender address . . . . . . . . . . . . 9 - 3.3. Domain part vs. full sender address . . . . . . . . . . . 9 -4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10 - 4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10 - 4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11 -5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11 - 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11 - 5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12 - 5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13 - 5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14 - 5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14 - 5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15 - 5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15 - 5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16 -6. Optional and experimental entry types . . . . . . . . . . . . . 16 - 6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16 - 6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16 - 6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17 - 6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17 -7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. Alternative encoding as TXT records . . . . . . . . . . . 17 - 7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18 - 7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18 - 7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18 - 7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18 - 7.2.5 Encoding of unused and full query . . . . . . . . . 19 - 7.2.6 Additional Records . . . . . . . . . . . . . . . . 19 -8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19 - - - -Hadmut Danisch Experimental [Page 2] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20 -10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20 - 10.1. Problem description . . . . . . . . . . . . . . . . . . . 20 - 10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21 - 10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21 -11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 - 11.1. Draft specific considerations . . . . . . . . . . . . . . 22 - 11.1.1 Authentication strength . . . . . . . . . . . . . 22 - 11.1.2 Where Authentication and Authorization end . . . . 22 - 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23 - 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25 - 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25 - 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25 - 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26 - 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26 - 11.2. General Considerations about spam defense . . . . . . . . 27 - 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27 - 11.2.2 Content based Denial of Service attacks . . . . . 27 -12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28 - 12.1. Draft specific considerations . . . . . . . . . . . . . . 28 - 12.1.1 No content leaking . . . . . . . . . . . . . . . . 28 - 12.1.2 Message reception and sender domain . . . . . . . 28 - 12.1.3 Network structure . . . . . . . . . . . . . . . . 29 - 12.1.4 Owner information distribution . . . . . . . . . . 29 - 12.2. General Considerations about spam defense . . . . . . . . 29 - 12.2.1 Content leaking of content filters . . . . . . . . 29 - 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30 -13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30 - 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30 - 13.1.1 Compatibility with old mail receivers . . . . . . 30 - 13.1.2 Compatibility with old mail senders . . . . . . . 30 - 13.1.3 Compatibility with old DNS clients . . . . . . . . 30 - 13.1.4 Compatibility with old DNS servers . . . . . . . . 30 - 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31 -14. General considerations about fighting spam . . . . . . . . . . 31 - 14.1. The economical problem . . . . . . . . . . . . . . . . . 31 - 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32 - 14.3. The network structure problem . . . . . . . . . . . . . . 33 - 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33 - 14.5. The identity problem . . . . . . . . . . . . . . . . . . 33 - 14.6. The multi-legislation problem . . . . . . . . . . . . . . 34 -Implementation and further Information . . . . . . . . . . . . . . . 34 -References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 -Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 -Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - - - - - - -Hadmut Danisch Experimental [Page 3] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -1. General Issues - - 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 RFC 2119 [1]. - -2. Problem and threat description - -2.1. Mail sender forgery - - The amount of e-mails with forged sender addresses has dramatically - increased. As a consequence, damages and annoyances caused by such - e-mails increased as well. In the majority of examined e-mails the - domain name of the envelope sender address was forged, and the e- - mail was sent from an IP address which does not belong to a network - used by the actual owner of the domain. - -2.1.1. Definition of sender forgery - - As discussions, comments to prior versions of this draft, and - different approaches to stop forgery showed, different perceptions - of "mail forgery" exist. For example, there are mechanisms to - verify e-mail addresses for mailing lists, web servers, or to stop - spam, which do send a message with a random number to the given - address and expect the user to send a reply. Here, someone is - considered to be allowed to use a particular e-mail address, if and - only if he is able to receive informations sent to this address, - and is able to reply to such a message. While this definition - appears to be quite plausible and natural, it can't be used for a - simple technical solution. Sending back a challenge and expecting a - reply is simply too much overhead and time delay, and not every - authorized sender is able or willing to reply (e.g. because he went - offline or is not a human). - - Within the scope of this memo, sender forgery means that the - initiator of an e-mail transfer (which is the original sender in - contrast to relays) uses a sender address which he was not - authorized to use. Being authorized to use an address means that - the owner (administrator) of the internet domain has given - permission, i.e. agrees with the use of the address by that - particular sender. This memo will cover both the permission of the - full e-mail address and the domain part only for simplicity. - - Within context of Internet and SMTP, the sender address usually - occurs twice, once as the envelope sender address in SMTP, and once - as the address given in the RFC822 mail header. While the following - considerations apply to both addresses in principle, it is - important to stress that both addresses have distinct semantics and - - - -Hadmut Danisch Experimental [Page 4] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - are not neccessarily the same. The envelope address identifies the - initiator of the transport, while the header identifies the author - of the message content. Since this memo deals with the message - transport only and completely ignores the message content, the - method should naturally be applied to the envelope sender address. - -2.1.2. Spam - - A common and well known problem is the dramatic increase of - unsolicited e-mail, commonly called "spam". Again, the majority of - examined e-mails had forged sender addresses. The abused domains - were mainly those of common webmailers as hotmail or yahoo, or - well-known companies. - - Unfortunately, there is no accurate definition of spam availabe - yet, and neither are the concise technical criterions to filter or - block spam with technical mechanisms. There are efforts to design - content based filters, but these filters are expensive in - calculation time (and sometimes money), and they do not reliably - provide predictable results. Usually they give false positives - and/or require user interaction. Content filters in general suffer - from a design problem described later in this memo. Therefore, - this proposal does not use the content based approach to block - spam. - - As analysis of spam messages showed, most of spam messages were - sent with forged envelope sender addresses. This has mainly three - reasons. The first reason is, that spam senders usually do not - want to be contacted by e-mail. The second reason is, that they do - not want to be blacklisted easily. The third reason is, that spam - is or is going to be unlawful in many countries, and the sender - does not want to reveal his identity. Therefore, spam is considered - to be a special case of sender forgery. - -2.1.3. E-Mail Worms - - Another example of sender forgery is the reproduction of e-mail - worms. Most worms do choose random sender addresses, e.g. using - the addresses found in mailboxes on the infected system. In most - cases analyzed by the author, the e-mails sent by the reproduction - process can also be categorized as forged, since the infected - system would under normal circumstances not be authorized to send - e-mails with such e-mail addresses. So forgery does not require a - malicious human to be directly involved. This memo covers any kind - of e-mail sender address forgery, included those generated by - malicious software. - -2.1.4. E-Mail spoofing and fraud - - - -Hadmut Danisch Experimental [Page 5] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Forging e-mail sender addresses for fraud or other kinds of - deception ("human engineering") has also dramatically increased. - There are many known cases where single or mass e-mails were sent - with wrong sender addresses, pretending to come from service - provider, software manufacturers etc., and asking the receiver to - install any software or patches, or to reply with any confidential - information. The Internet is becoming more and more a scene of - crime, and so are it's services, including e-mail. It is obvious - that crime based on e-mail is eased by the fact that SMTP allows - arbitrary sender address spoofing. - -2.2. Indirect damage caused by forgery - - As observed by the author, mass mails and worms with forged sender - addresses can cause a severe damage for the real owner of the - abused sender addresses. If a sender A is sending an e-mail to the - receiver B, pretending to be C by using a sender address of C's - domain, then C has currently no chance to prevent this, since C's - machines and software are not involved in any way in the delivery - process between A and B. B will nevertheless send any error - messages (virus/spam alert, "no such user", etc.) to C, erroneously - assuming that the message was sent by C. The author found several - cases where this flood of error messages caused a severe denial of - service or a dramatic increase of costs, e.g. when C was - downloading the e-mail through expensive or low bandwidth - connections (e.g. modem or mobile phones), or where disk space was - limited. The author examined mass mailings, where several tens or - hundreds of thousands of messages were sent to several addresses - around the world, where these messages caused only annoyance. But - since several thousands of these addresses were invalid or didn't - accept the message, the owner of the DNS domain which was abused by - the spammer to forge sender addresses was flooded for several - months with thousands of error messages, jamming the e-mail system - and causing severe costs and damages. - - As a consequence, when A sends a message to B, pretending to be C, - there must be any mechanism to allow C to inform B about the fact, - that A is not authorized to use C as a sender address. This is what - this memo is about. - -2.3. Technical problem analysis - - Why does e-mail forgery actually exist? Because of the lack of the - Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender - authentication, authorisation, or verification. This protocol was - designed at a time where security was not an issue. Efforts have - been made to block forged e-mails by requiring the sender address - domain part to be resolvable. This method provides protection from - - - -Hadmut Danisch Experimental [Page 6] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - e-mails with non-existing sender domains, and indeed, for some time - it blocked most spam e-mails. However, since attackers and spam - senders began to abuse existing domain names, this method was - rendered ineffective. - -2.4. Shortcomings of cryptographical approaches - - At a first glance, the problem of sender address forgery might - appear to be solvable with cryptographic methods such as challenge - response authentications or digital signatures. A deeper analysis - shows that only a small, closed user group could be covered with - cryptographical methods. Any method used to stop spam forgery must - be suitable to detect forgery not only for a small number of - particular addresses, but for all addresses on the world. An - attacker does not need to know the secrets belonging to a - particular address. It is sufficient to be able to forge any - address and thus to know any secret key. Since there are several - hundreds of millions of users, there will always be a large amount - of compromised keys, thus spoiling any common cryptographic method. - Furthermore, cryptography has proven to be far too complicated and - error prone to be commonly administered and reliably implemented. - Many e-mail and DNS administrators do not have the knowledge - required to deal with cryptographic mechanisms. Many legislations - do not allow the general deployment of cryptography and a directory - service with public keys. For these reasons, cryptography is - applicable only to a small and closed group of users, but not to - all participants of the e-mail service. - -3. A DNS based sender address verification - -3.1. Overview - - To gain improvement in e-mail authenticity while keeping as much - SMTP compatibility as possible, a method is suggested which doesn't - change SMTP at all. - - The idea is to store informations about how to verify who is - authorized to transmit e-mails through SMTP with a particular - sender address (either full address or - for simplicity - only the - domain part of the address) in a directory service, which is - currently the DNS. To be precise, the verification consists of two - steps, the classical pair of authentication and authorization: - - The first step is the authentication. While several methods are - possible to perform authentication (see below), the most important - and robust method is the verification of the sender's IP address. - This is done implicitely by TCP/IP and the TCP sequence number. The - authenticated identity is the IP address. It has to be stressed - - - -Hadmut Danisch Experimental [Page 7] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - that this TCP/IP "authentication" is a weak authentication and - vulnerable to several attacks. It is nevertheless sufficient for - this purpose, especially for blocking spam. It doesn't take any - implementation and it doesn't cost: It is already there, it is a - functionality of TCP/IP. An incoming SMTP connection based on - TCP/IP already carries the sender's IP address without any - modification of SMTP. See below (section Entry types) for more - details about authentication methods. - - The second step is the authorization. It is based on the identity - given by the previous authentication step, e.g. the IP address of - the originator of the incoming SMTP connection, and on the - envelope sender address. The mechanism proposed in this memo - answers the question "Is that particular sender (IP address,...) - allowed to send with that sender address" by querying and - processing informations stored in a directory service, which is - DNS. - - When the sender has issued the "MAIL FROM:" SMTP command, the - receiving mail transfer agent (MTA) can - and modern MTAs do - - perform some authorization checks, e.g. run a local rule database - or check whether the sender domain is resolvable. - - The suggested method is to let the DNS server for the sender domain - provide informations about who - this means for example which IP - address - is authorized to use an address or a domain as a part of - it. After receiving the "MAIL FROM:" SMTP command, the receiving - MTA can verify, whether e. g. the IP address of the sending MTA is - authorized to send mails with this domain name. Therefore, a list - of entries with authorized IP addresses or other informations is - provided by the authoritative DNS server of that domain. The entry - types are described in the subsequent chapters. Some of these - methods are - - - An IPv4 or IPv6 network address and mask - - A fully qualified domain name referring to an A record - - A fully qualified domain name referring to an APL record - - RMX records of these types would look like this: - - somedomain.de. IN RMX ipv4:10.0.0.0/8 - rmxtest.de. IN RMX host:relay.provider.com - danisch.de. IN RMX apl:relays.rackland.de - relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24 - - where the machine with the example address 213.133.101.23 and the - machines in the example subnet 1.2.3.0/24 are the only machines - allowed to send e-mails with an envelope sender address of domain - - - -Hadmut Danisch Experimental [Page 8] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - danisch.de. Since the APL records do not necessarily belong to the - same domain or zone table as the RMX records, this easily allows to - refer to APL records defined by someone else, e.g. the internet - access or server hosting provider, thus reducing administrative - overhead to a minimum. In the example given above, the domain - danisch.de and several other domains are hosted by the service - provider Rackland. So if the relay structure of Rackland is - modified, only the zone of rackland.de needs to be modified. The - domain owners don't need to care about such details. - -3.2. Envelope vs. header sender address - - Questions were raised why the proposed mechanism is based on the - envelope sender address, and not on the sender address given in the - message header. Technically, both can be used. Actually, it makes - sense to use the envelope address. - - In common, the header sender address identifies the author of the - content, while the envelope sender tells who caused the - transmission. The approach proposed in this memo is transmission - based, not content based. We can not authorize the author of a - message if we don't have contact with him, if the message does not - already contain a signature. In contrast, the sending MTA is linked - to an IP address which can be used for authentication. This - mechanism might not be very strong, but it is available and - sufficient to solve today's e-mail security problems. - - Some people argued that it is the header address and not the sender - address, which is displayed in common mail readers (MUAs), and - where the receiver believes the mail comes from. That's true, but - it doesn't help. There are many cases where the header sender - differs from the envelope sender for good reasons (see below in the - consequences chapter for the discussion about relaying). Relaying, - mailing lists etc. require to replace the sender address used for - RMX. If this were the header address, the message header would have - to be modified. This is undesirable. - -3.3. Domain part vs. full sender address - - Former versions of this draft were limited to the domain part of - the sender address. The first reason is that it is common and MX- - like, to lookup only the domain part of an e-mail address in DNS. - The second reason is, that it was left to the private business of - the domain administration to handle details of user verification. - The idea was that the domain administration takes care to verify - the left part of an e-mail address with an arbitrary method of - their individual taste. RMX was originally designed to ignore the - left part of the address and to expect the domain administration to - - - -Hadmut Danisch Experimental [Page 9] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - take over responsibility for enforcing their policy. If, e.g., a - spam message arrived and passed the RMX mechanism, it is known to - be authorized by the domain administration and they can be blamed, - no matter what is on the left side of the sender address - it's - their private problem what happens on the left side of the @. By - far the most of the comments to prior versions of this draft agreed - with that. A few comments asked for a finer granularity. - - And indeed, there is no technical reason against a finer - granularity. All it takes is a mapping from a given envelope - sender address to a DNS name, and the RMX lookup for that - particular e-mail address could be done instead of a lookup for the - domain part only. However, to my knowledge, most domain - administrators would not like to provide an RMX entry for every - single e-mail address. In many cases, this would also overload DNS - servers. - - It is to be discussed how to cover both views. One method could be - to query the full address, and if no RMX records were found to - query the domain part only. A different approach would be to query - the domain part only, and if it's RMX record contain a special - entry, then a new query for the full address is triggered. A third - way would be to always query the full address and to leave the - problem to the wildcard mechanism of DNS. This still has to be - discussed and will be described in future versions of this draft. - - - - - - - - - - - -4. Mapping of E-Mail addresses to DNS names - - To perform the RMX query, a mapping is needed from E-Mail addresses - to DNS fully qualified domain names. - - This chapter is under development and just a first approach. - -4.1. Domain part only - - Mapping of the domain part is trivial, since the domain part of an - e-mail address itself is a valid DNS name and does not need - translation. It might be nevertheless desirable to distinguish the - - - -Hadmut Danisch Experimental [Page 10] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - RMX entries from other entries, depending of the encoding of the - records. If the RMX entries are encoded in TXT record types, they - might collide with other uses of TXT records. It might be - necessary to prepend the domain part with a special prefix, e.g. - _rmx. So the e-mail address some.user@example.com could be mapped - to example.com or _rmx.example.com. - -4.2. Full address - - Mapping a full address is slightly more difficult. The @ sign must - be unambiguously translated, and therefore can not be simply - translated into a dot. The e-mail addresses some.user@example.com - and some@user.example.com must have different mappings. Therefore, - the @ sign could be translated into _rmx, implicitely assuming that - this is not an allowed domain name component of normal domain - names. Then the rightmost _rmx in the mapped DNS name always - corresponds to the @ sign. some.user@example.com would e translated - into some.user._rmx.example.com and can be covered by a wildcard - entry like *._rmx.example.com. - - Character encoding and character sets are still to be discussed. - -4.3. Empty address - - Unfortunately, SMTP allows empty envelope sender addresses to be - used for error messages. Empty sender addresses can therefore not - be prohibited. As observed, a significant amount of spam was sent - with such an empty sender address. To solve this problem, the host - name given in the HELO or EHLO command is taken to lookup the RMX - records instead. This makes sense, since such messages were - generated by the machine, not a human. - - - - -5. Mandatory entry types and their syntax - - The entry types described in this section MUST be supported by any - implementation of this draft. - -5.1. Overall structure - - Similar to APL, an RMX record is just a concatenation of zero or - more RMX entries. The entries within one record form an ordered - rule base as commonly usual in packet filtes and firewall rulesets, - i. e. they are processed one ofter another until the first entry - matches. This entry determines the result of the query. Once a - matching entry is found, the RMX processing is finished. - - - -Hadmut Danisch Experimental [Page 11] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - For any domain name there should not exist more than a single RMX - record. Due to the structure of DNS, it is nevertheless possible to - have more than a single RMX record. Multiple RMX records are - treated as a single record consisting of the concatenation of all - records. While the entries in a record are ordered, the records are - not ordered and may be processed in arbitrary order. If the order - of the entries matters, it is the zone maintainer's responsibility - to keep those entries in a single record. For example, there are - negative entries, which exclude IP addresses from authorization. - It is important that these entries are processed before positive - entries giving permission to a wider address range. Since order is - guaranteed only within a record, corresponding negative and - positive entries must be put in the same record. - - An RMX record may consist of one or more entries, where the entries - are separated by whitespace. An entry must not contain white space. - Each entry consists of an optional exclamation sign, a tag, a - colon, and the entry data: - - [!] TAG : ENTRY-SPECIFIC-DATA - - If the entry starts with an exclamation sign, the entry is negated. - See the entry type description below for details. - - The TAG is the mnemonic type identifier or the decimal number of - the entry. The TAG is case-insensitive. It is immediately followed - by a colon. - - The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the - entry type. See description below. - - Example: - - danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5 - ipv4:1.2.3.0/24 - -5.2. Unused - - This is a primitive entry which just says that this sender address - will never be used as a sender address under any circumstances. - Example: - - testdomain.danisch.de IN RMX unused: - -5.3. IPv4 and IPv6 address ranges - - These entry types contain a bit sequence representing a CIDR - address part. If that bit sequence matches the given IP address, - - - -Hadmut Danisch Experimental [Page 12] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - authorization is granted or denied, depending on the negation flag. - - The entry is prepended with the tag "IPv4" or "IPv6". The colon is - followed with an IPv4 or IPv6 address in standard notation, - optionally followed by a slash and a mask length. If the negation - flag is set, then the given address range is excluded. Examples: - - danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0 - IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16 - IN RMX !ipv4:1.2.3.4 - - (Please note that it does not make much sense to use - RFC1918-Addresses in RMX records, this is just to give a syntax - example.) - - -5.4. DNS Hostname - - This entry type simply contains a regular DNS name, which is to be - resolved as a host name (fetch the A record or IPv6 equivalent). If - the given IP address matches the result, authorization is granted - or denied, depending on the negation flag. It is still to be - defined how to treat unresolvable entries. - - The entry is prepended with the tag "host", followed by a colon and - the hostname. Examples: - - danisch.de IN RMX host:relay.provider.de - IN RMX !host:badmachine.domain.de apl:relays.domain.de - -5.4.1. Road warriors and DynDNS entries - - Several people argued against RMX that it would break their - existing installation which delivers e-mail from dynamically - assigned IP addresses, because their IP providers didn't assign a - static address, or because they are a road warrior, plugging their - notebook in any hotel room on the world. - - RMX provides a simple solution. If such a machine has a dynamically - updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of - the hostname type pointing to this dynamic DNS entry. - - The cleaner solution would be to deliver mail the same way as it is - received: If downloaded by POP from a central relay with a static - address, where the MX points to, then it would be a good idea to - deliver e-mail the same way in reverse direction. Unfortunately, - plain POP does not support uploading yet. - - - - -Hadmut Danisch Experimental [Page 13] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -5.5. APL Reference - - This entry type simply contains a regular DNS name, which is to be - resolved as an APL record index (fetch the APL record). If the - given IP address positively matches the APL, authorization is - granted. Details of the semantic (espially when the negation bit is - set) are still to be defined. It is still to be defined how to - treat unresolvable entries. - - The entry is prepended with the tag "host", followed by a colon and - the hostname. Example: - - danisch.de IN RMX apl:relays.rackland.de - -5.6. Domain Member - - In many cases it is desirable to cover all hosts of a given domain - with an RMX record without the need to duplicate the list of these - hosts. This entry type does it (thanks to Eric A. Hall for pointing - out this entry type). It contains a regular DNS name. - - If this entry type is given, a reverse DNS query for the IP address - of the sending MTA is performed to find its official fully - qualified domain name. To prevent spoofing, this domain name is - accepted only if a subsequent address query to the given domain - name points to exactly the IP address of the sending MTA (the usual - procedure to verify PTR records). - - The entry matches if the fully qualified domain name of the sending - MTA ends in the given domain. The negation flag works as usual. - - The tag for this entry type is "domain". After the colon the domain - name is given, but might be empty, thus pointing to itself. - Example: - - somedomain.org IN RMX domain:somedomain.org domain:provider.com - - would authorize all machines which's hostname can be verified - through an PTR and A query, and which ends in "somedomain.org" or - "provider.com". - - With such an entry, large companies with different networks can - easily be covered with just a single and simple RMX entry. - Obviously, it requires proper PTR records. - - As a special shortcut, the DNS name may be empty. In this case the - domain name of the zone itself is taken. Thus, with a very simple - entry of the type - - - -Hadmut Danisch Experimental [Page 14] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - somecompany.com IN RMX domain: - - a company could authorize all machines which's IP addresses map to - DNS names end in somecompany.com, which applies in the majority of - companies. - - - - -5.7. Full Address Query - - As described above, RMX records will in most cases apply to the - domain part of the sender address. In special cases it might be - desirable to query the RMX record for a particular address. An RMX - entry of the Full Address Query type may occur in a domain RMX - record only. It signals that the RMX record for the full address is - to be fetched and processed. - - This entry type does not take arguments. The negation flag is not - supported. The tag is "full". - - If such a full address query is to be performed, the mail address - must be mapped to a valid and non-ambiguos DNS name. This mapping - is still to be defined. It is not sufficient to simply replace the - @ with a dot, because of case sensitivity, character sets, etc. The - e-mail addresses - - john.doe@example.org - John.Doe@example.org - john@doe.example.org - - must all be mapped to different DNS entries. This entry type might - vanish in future versions of the draft, depending on the discussion - about whether to query the domain name part only or the full - address. - -5.8. DNS mapped authorization - - As I learned from comments to prior versions of the draft and from - alternative proposals, many users wish to have a DNS mapped - authorization table, i. e. the client queries a DNS entry of the - form a.b.c.d.domain, where a.b.c.d is the sender's IP address. - Since people wish to have this, RMX will now include such a mapping - entry. The entry has a parameter giving the DNS domain name where - to look at. If the parameter is empty, then the same domain is - taken as for the RMX lookup. - - As this is currently under construction and discussion in an IETF - - - -Hadmut Danisch Experimental [Page 15] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - group, details will be published in future versions of this draft. - -5.9. RMX reference - - This entry type has no parameters. It means that all those machines - are authorized, which are pointed to by an MX record. - -6. Optional and experimental entry types - - The following subsections roughly describe further entry types - which might not be supported by all implementations and might not - be allowed in all legislations. These methods might vanish in - future versions of the draft and are just considerations about what - to include in RMX and what to not include. The main purpose of this - section is to start discussion about such entry types. - - The disadvantage of the following methods is that they violate the - basic idea of RMX, i. e. to be simple, robust, easy to implement - and easy to administer. I personally do not believe that it is a - good idea or even feasible to implement cryptography for a world - wide e-mail transfer network. Keep in mind that cryptographic keys - can be copied. If only <0.1% of cryptographic keys were revealed, - this completely compromises and spoils RMX. Cryptography is simply - the wrong tool for the problem RMX is intended to solve. I - nevertheless like to discuss these methods. - -6.1. TLS fingerprint - - The sender is considered to be authorized if the message was - transmitted through SMTP and TLS, and the sender used a certificate - matching the fingerprint given in the RMX record. - -6.2. TLS and LDAP - - This means that the receiver should perform an LDAP query for the - sender address (through the LDAP SRV record or given in the RMX - record), fetch the X.509 certificate for the sender. The sender is - considered to be authorized when the message was transmitted - through SMTP and TLS using this certificate. - -6.3. PGP or S/MIME signature - - It would be possible to accept a message only if it was signed with - PGP or S/MIME with a key which's fingerprint is given in the RMX - record or to be fetched from LDAP or any PGP database. This is - just for discussion, since it violates the idea of RMX to focus on - the transport, not on the content. It would also allow replay - attacks and not cover the envelope sender address or message - - - -Hadmut Danisch Experimental [Page 16] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - header. - -6.4. Transparent Challenge/Response - - It would also be possible to implement a challenge-response - mechanism without modifying the syntax of SMTP. For example, the - receiving MTA could issue a challenge with it's very first greeting - message, the sending MTA could hide the response in the HELO - parameter and when the receiving MTA later learns the sender - envelope address, it could verify the response based on - informations in the RMX record. - -6.5. SASL Challenge/Response - - Modern SMTP implementations already include a SASL mechanisms, - which easily allows to plugin new authentication mechanisms. While - common SASL mechanisms require to use a previously shared password, - a new mechanism could perform a challenge response authentication - as a SASL method. - - - - - - -7. Encoding - -7.1. Alternative encoding as TXT records - - The main objection against the prior versions of this draft was - that it requires a new RR entry type and upgrading all DNS servers. - - Therefore and alternative encoding is proposed. Instead of using a - new RR type, the TXT record type is used to contain the RMX record. - The records would simply look as described in the entry type - chapters above, e.g. - - _rmx.danisch.de. IN TXT "apl:relays.rackland.de" - - To allow smooth introduction of RMX without the need to immediately - upgrade all DNS servers, all clients (which have to be newly - installed anyway) MUST support both the TXT and the RMX records. A - client has to perform an ANY or a TXT and a RMX query. Servers/zone - tables may currently use TXT entries but SHOULD use RMX entries in - future. - -7.2. RMX Records - - - - -Hadmut Danisch Experimental [Page 17] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -7.2.1. Overall structure - - Each entry starts with an octet containting the entry type and the - negation flag: - - +---+---+---+---+---+---+---+---+------ - | N | Entry Type Code | Parameters... - +---+---+---+---+---+---+---+---+------ - - N If this bit (MSB) is set, an IP address - matching this entry is not authorized, - but explicitely rejected. See entry - type descriptions for details. - - Entry Type A 7bit number simply determining the entry - type. - - - Currently, entries do not have an explicit length field, the entry - length is determined implicitely by the entry type. Applications - are required to abort if an unknown entry type is found, instead of - skipping unknown entries. - -7.2.2. Record encoding - - A RMX record is simply a concatenation of RMX entries. - -7.2.3. Encoding of IPv4 and IPv6 address ranges - - After the entry type tag as described above, one octet follows - giving the length L of the bit sequence. Then a sequence of exactly - as many octets follows as needed to carry L bits of information (= - trunc((L+7)/8) ). - - +---+---+---+---+---+---+---+---+ - | N | Entry Type Code (1 or 2) | - +---+---+---+---+---+---+---+---+ - | Length Field L | - +---+---+---+---+---+---+---+---+ - | Bit Field | - / ((L+7)/8) Octets / - +---+---+---+---+---+---+---+---+ - - -7.2.4. Encoding of DNS - - After the entry type tag immediately follows a DNS encoded and - compressed [3] domain name. - - - -Hadmut Danisch Experimental [Page 18] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - +---+---+---+---+---+---+---+---+ - | N | Entry Type Code (3..5) | - +---+---+---+---+---+---+---+---+ - | Length Field L | - +---+---+---+---+---+---+---+---+ - | Encoded DNS | - / Name as described in RFC1035 / - +---+---+---+---+---+---+---+---+ - - In contrast to earlier versions of this draft, the DNS name cannot - be compressed, since this would cause decompression errors when a - DNS server is part of the query chain which does not know this - particular RR type. - -7.2.5. Encoding of unused and full query - - These entries do not contain parameters and does not allow the - negation flag. So the encoding is quite simple: - - +---+---+---+---+---+---+---+---+ - | 0 | Entry Type Code (6 or 7)| - +---+---+---+---+---+---+---+---+ - - - -7.2.6. Additional Records - - In order to avoid the need of a second query to resolve the given - host name, a DNS server should enclose the A record for that domain - name in the additional section of the additional section of the DNS - reply, if the server happens to be authoritative. - - In order to avoid the need of a second query to resolve the given - host name, a DNS server should enclose the APL record for that - domain name in the additional section of the additional section of - the DNS reply, if the server happens to be authoritative. - - - -8. Message Headers - - An RMX query must be followed by any kind of action depending on - the RMX result. One action might be to reject the message. Another - action might be to add a header line to the message body, thus - allowing MUAs and delivery programs to filter or sort messages. - - In future, the RMX result might be melted into the Received: header - line. - - - -Hadmut Danisch Experimental [Page 19] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - The details of such entries are to be discussed. As a proposal the - following form is suggested: - - X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM - - where - - RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX", - "TempFail", "BadData", "Trusted". - - ADDRESS is the IP address of the sending machine - - HOST is the name of the machine performing the RMX query. - - DATE is the date of the query. - - MECHANISM is the RMX method used to authorize the sender. - - - -9. SMTP error messages - - If a message is rejected because of RMX records, an error message - should be issued which explains the details. It is to be discussed - whether new SMTP error codes are to be defined. - - -10. Message relaying and forwarding - -10.1. Problem description - - Message forwarding and relaying means that an MTA which received an - e-mail by SMTP does not deliver it locally, but resends the message - - usually unchanged except for an additional Received header line - and maybe the recipient's address rewritten - to the next SMTP MTA. - Message forwarding is an essential functionality of e-mail - transport services, for example: - - - Message transport from outer MX relay to the intranet - - Message forwarding and Cc-ing by .forward or .procmail-alike - mechanisms - - Mailing list processing - - Message reception by mail relays with low MX priority, - usually provided by third parties as a stand-by service - in case of relay failure or maintenance - - "Forwarding" and "Bouncing" as a MUA functionality - - In all these cases a message is sent by SMTP from a host which is - - - -Hadmut Danisch Experimental [Page 20] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - not covered by the original sender domain's RMX records. While the - RMX records would forbid accepting this message, it still must be - accepted. The following subsections explain how to cope with - relaying. - -10.2. Trusted relaying/forwarding - - In some cases the receiving MTA trusts the sending MTA to not fake - messages and to already have checked the RMX records at message - reception. As a typical example, a company might have an outer mail - relay which receives messages from the Internet and checks the RMX - records. This relay then forwards the messages to the different - department's mail servers. It does not make sense for these - department mail servers to check the RMX record, since the RMX - records have already been checked and - since the message was - relayed by the outer relay - always would deny the message. In this - case there is a trust relationship between the department relays - and the outer relay. So RMX checking is turned off for trusted - relays. In this example, the department relays would not check - messages from the outer relay (but for intranet security, they - could still check RMX records of the other departments sub-domains - to avoid internal forgery between departments). - - Another common example are the low-priority MX relays, which - receive and cache e-mails when the high-priority relays are down. - In this case, the high-priority relay would trust the low-priority - relay to have verified the sender authorization and would not - perform another RMX verification (which would obviously fail). - - When a relay forwards a message to a trusting machine, the envelope - sender address should remain unchanged. - -10.3. Untrusted relaying/forwarding - - If the receiving MTA does not trust the forwarding MTA, then there - is no chance to leave the sender envelope address unchanged. At a - first glance this might appear impracticable, but this is - absolutely necessary. If an untrusted MTA could claim to have - forwarded a message from a foreign sender address, it could have - forged the message as well. Spammers and forgers would just have to - act as such a relay. - - Therefore, it is required that, when performing untrusted - forwarding, the envelope sender address has to be replaced by the - sender address of someone responsible for the relaying mechanism, - e.g. the owner of the mailing list or the mail address of the user - who's .forward caused the transmission. It is important to stress - that untrusted relaying/forwarding means taking over responsibility - - - -Hadmut Danisch Experimental [Page 21] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - for the message. It is the idea of RMX records to tie - responsibility to message transmission. Untrusted relaying without - replacing the sender address would mean to transmit without taking - responsibility. - - The disadvantage is that the original sender address is lost. - Therefore, whenever a sender address replacement happens, the - Received-Line must contain the old address. Many of today's MTAs - already insert the envelope recipient address, but not the sender - address into the Received header line. It seems reasonable to - require every Received line to include both the sender and - recipient address of the incoming SMTP connection. - - -11. Security Considerations - -11.1. Draft specific considerations - -11.1.1. Authentication strength - - It is important to stress, that the suggested method does not - provide high level security and does not completely prevent forged - e-mails or spam under any circumstances. It is a robust, but not - highly reliable and completely secure security mechanism. Keep in - mind that it is based on DNS, and DNS is not secure today. - Authorization is based on the IP address. The very same machine - with the very same IP address could be authorized to send e-mail - with a given sender address and sending spam at the same time. - Maybe because several users are logged in. Or because several - customers use the same relay of the same ISP, where one customer - could use the sender address of a different customer. It is up to - the ISP to prevent this or not. Machines can still be hijacked. - Spammers are also domain owners. They can simply use their own - domain and authorize themselves. You will always find people on the - world who do not care about security and open their relays and RMX - records for others to abuse them. RMX is to be considered as a - very cheap and simple light weight mechanism, which can - nevertheless provide a significant improvement in mail security - against a certain class of attacks, until a successor of SMTP has - been defined and commonly accepted. - -11.1.2. Where Authentication and Authorization end - - Previous versions of RMX records did not cover the local part of - the e-mail address, i.e. what's on the left side of the @ sign. - This is still to be discussed. Authentication and authorization are - limited to the sending MTA's IP address. The authentication is - limited to the TCP functionality, which is sufficient for light - - - -Hadmut Danisch Experimental [Page 22] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - weight authentication. The RMX records authorize the IP address of - the sending host only, not the particular sender of the message. So - if a machine is authorized to use sender addresses of more than a - single domain, the authentication scheme does not prevent that any - user on this machine can send with any of these domains. RMX is not - a substitute for the host security of the involved machines. - - The proposed authentication scheme can be seen as a "half way - authentication": It does not track back an e-mail to the effective - sender. It tracks only half of the way, i. e. it tracks back to the - domain and it's DNS administrators who authorized that particular - sender IP address to use it for sending e-mail. How the party - responsible for that domain performs user authentication, whom it - grants access to, how it helds people responsible for abuse, is - completely left as the private business of those who are in charge - of that domain. So this draft does not interfere with the domain's - individual security policy or any legislation about such policies. - On the other hand, the proposed authentication scheme does not give - any statement about the nature and quality of the domain's security - policy. This is an essential feature of the proposal: E-mail - authentication must be deployed world wide, otherwise it won't do - the job. Any security scheme interfering with the local - legislations or the domain's security policy will not be accepted - and can't effectively deployed. Therefore, the security policy must - remain the domain's private business, no matter how lousy the - policy might be. - - In order to achieve this and to make use of the only existing world - wide Internet directory scheme (DNS), the approach of this proposal - is to just ignore the local part of the sender address (i.e. what's - left of the @ part) and limit view to the domain part. After all, - that's what we do anyway when delivering to a given address with - SMTP. - -11.1.3. Vulnerability of DNS - - DNS is an essential part of the proposed authentication scheme, - since it requires any directory service, and DNS is currently the - only one available. Unfortunately, DNS is vulnerable and can be - spoofed and poisoned. This flaw is commonly known and weakens many - network services, but for reasons beyond that draft DNS has not - been significantly improved yet. After the first version of this - draft, I received several comments who asked me not to use DNS - because of its lack of security. I took this into consideration, - but came to the conclusion that this is unfeasible: Any - authentication scheme linked to some kind of symbolic identity (in - this case the domain name) needs some kind of infrastructure and - trusted assignment. There are basically two ways to do it: Do it - - - -Hadmut Danisch Experimental [Page 23] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - yourself and trust nobody else, or let someone else do it. There - are methods to do it the former way, e.g. to give someone some kind - of authentication information after a first successful e-mail - exchange, e.g. some kind of cookie or special e-mail address. This - is certainly interesting and powerful, but it does not solve the - problem on a world wide scale and is far to complicated and error - prone for the average user, i. e. 99% of the users. - - The latter method to let someone else do the symbolic name - assignment and create the authentication framework is well known. - It context of public key cryptography, this is called a Public Key - Infrastructure (PKI). On of the best known facts about PKIs is - that, until now, we don't have any covering a significant part of - the Internet. And we won't have any in near future. The complexity - is far too high, it is too expensive, and it involves cooperation - of every single user, which is simply unrealistic and extremely - error prone. So what do we have we can use? All we have is the DNS - and the Whois database. And we have countries who don't allow - cryptography. So the proposal was designed to use DNS without - cryptography. It does not avoid DNS because of its vulnerability, - it asks for a better DNS, but accepts the DNS as it is for the - moment. Currently there are two main threats caused by the DNS - weakness: - - - A spammer/forger could spoof DNS in order to gain false - authorization to send fake e-mails. - - - An attacker could spoof DNS in order to block delivery from - authorized machines, i. e. perform a Denial of Service attack. - - The first one is rather unrealistic, because it would require an - average spammer to poison a significant part of the DNS servers of - its victims. A spammer sending messages to one million receipients - would need to poison at least 1-10% which is 10,000 to 100,000 - receipient's DNS servers. This should be unfeasible in most cases. - - In contrast, the second threat is a severe one. If an attacker - wanted to block messages from one company to another, he just needs - to poison the recipients DNS server with a wrong RMX record in - order to make the recipient's SMTP machine reject all messages. And - this is feasible since the attacker needs to poison only a single - DNS server. But does this make SMTP more vulnerable? No. Because - the attacker can already do even more without RMX. By poisoning the - sender's DNS server with wrong MX records, the attacker can also - block message delivery or even redirect the messages to the - attacker's machine, thus preventing any delivery error messages and - furthermore getting access to the messages. - - - - -Hadmut Danisch Experimental [Page 24] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - As a consequence, e-mail delivery by SMTP requires a better DNS - anyway. The requirements are not significantly expanded by RMX. - -11.1.4. Sneaking RMX attack? - - While writing a test implementation, a certain kind of attack came - into my mind. I'm still not sure, whether this attack is possible - on any DNS server, but I believe it should be mentioned: - - Imagine an unauthorized sender is sending a forged mail (e.g. - spam). At connection time, before querying the RMX record, the - receiving MTA usually performs a PTR query for the IP address of - the sending MTA. If the sender has control over the authoritative - name server for that particular IP address, the sender could give a - normal PTR answer, but could append a wrong RMX, APL, or A record - in the additional section of the query. A subsequent RMX query - could receive wrong DNS data if the DNS server used by the - receiving MTA accepted those forged records. - -11.1.5. Open SMTP relays - - Open SMTP relays (i.e. machines who accept any e-mail message from - anyone and deliver to the world) abused by spammers are a one of - the main problems of spam defense and sender backtracking. In most - cases this problem just vanishes because foreign open relay - machines will not be covered by the RMX records of the forged - sender address. But there are two special cases: - - If the spammer knows about a domain which authorizes this - particular machine, that domain can be used for forgery. But in - this case, the IP address of the relay machine and the RMX records - of the domain track back to the persons responsible. Both can be - demanded to fix the relay or remove the RMX record for this - machine. An open relay is a security flaw like leaving the machine - open for everybody to login and send random mails from inside. Once - the administrative persons refuse to solve the problem, they can be - identified as spammers and held responsible. - - The second special case is when a domain authorizes all IP - addresses by having the network 0.0.0.0/0 in the RMX/APL record. In - this case, open relays don't make things worse. It's up to the - recipient's MTA to reject mails from domains with loose security - policies. - -11.1.6. Unforged Spam - - This proposal does not prevent spam (which is, by the way, not yet - exactly defined), it prevents forgery. Since spam is against law - - - -Hadmut Danisch Experimental [Page 25] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - and violates the recipients rights, spam depends on untracability - of the sender. In practice the sender forges the sender address - (other cases see below). This proposal is designed to detect such - forgeries. - - However, the RMX approach is rendered ineffective, if the sender - doesn't forge. If the sender uses just a normal address of it's own - domain, this is just a plain, normal e-mail, which needs to be let - through. Since it is up to the human's taste whether this is spam - or not, there's no technical way to reliably identify this as spam. - But since the sender domain is known, this domain can be - blacklisted or legal steps can be gone into. - -11.1.7. Reliability of Whois Entries - - Once the RMX infrastructure gets deployed, what's the security - gain? It allows to determine the domain which's DNS zone - authorized the sending machine. What's that good for? There are - some immediate uses of the domain name, e.g. in black- and - whitelisting. But in most cases this is just the starting point of - further investigations, either performed automatically before - message acceptance, or manually after spam has been received and - complainted about. - - The next step after determining the domain is determining the - people responsible for this domain. This can sometimes be achieved - by querying the Whois databases. Unfortunately, many whois entries - are useless because they are incomplete, wrong, obsolete, or in - uncommon languages. Furthermore, there are several formats of - address informations which make it difficult to automatically - extract the address. Sometimes the whois entry identifies the - provider and not the owner of the domain. Whois servers are not - built for high availability and sometimes unreachable. - - Therefore, a mandatory standard is required about the contents and - the format of whois entries, and the availability of the servers. - After receiving the MAIL FROM SMTP command with the sender envelope - address, the receiving MTA could check the RMX record and Whois - entry. If it doesn't point to a real human, the message could be - rejected and an error message like "Ask your provider to fix your - Whois entry" could be issued. Obviously, domain providers must be - held responsible for wrong entries. It might still be acceptable to - allow anonymous domains, i. e. domains which don't point to a - responsible human. But it is the receivers choice to accept e-mails - from such domains or not. - -11.1.8. Hazards for Freedom of Speech - - - - -Hadmut Danisch Experimental [Page 26] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Currently, some governments try to enforce limitations of internet - traffic in order to cut unwanted content providers from the - network. Some of these governments try to hide a whole country - behind firewalls, others try to force Internet providers to poison - DNS servers with wrong A records for web servers, e.g. one county - administration in Germany tries to do so. If message reception - depends on DNS entries, the same governments will try to block not - only HTTP, but SMTP also. - - However, since most MTAs already reject messages from unresolvable - domain names this is not a new threat. - -11.2. General Considerations about spam defense - - After discussing security requirements of the proposal, now the - security advantages of the RMX approach over content based filters - will be explained. Basically, there are three kinds of content - filters: - - - Those who upload the message or some digest to an external - third party and ask "Is this spam"? - - - Those who download a set of patterns and rules from a third - party and apply this set to incoming messages in order to - determine whether it is spam. - - - Those who are independent and don't contact any third party, - but try to learn themselves what is spam and what isn't. - - - The message filters provided by some e-mail service providers are - usually not a kind of their own, but a combination of the first two - kinds. - -11.2.1. Action vs. reaction - - Content filters suffer from a fundamental design problem: They are - late. They need to see some content of the same kind before in - order to learn and to block further distribution. - - This works for viruses and worms, which redistribute. This doesn't - work for spam, since spam is usually not redistributed after the - first delivery. When the filters have learned or downloaded new - pattern sets, it's too late. - - This proposal does not have this problem. - -11.2.2. Content based Denial of Service attacks - - - -Hadmut Danisch Experimental [Page 27] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - All three kinds of content filters, but especially the second and - the third kind are vulnerable to content based Denial of Service - attacks. - - If some kind of third party (e.g. non-democratic government, - intellectual property warriors, religious groups, military, secret - services, patriots, public relation agents, etc.) wants certain - contents not to be distributed, they could either poison the - pattern/rule databases or feed wrong sets to particular receivers. - - Such pattern/rule sets are the perfect tool for censoring e-mail - traffic and denial of service attacks by governments and other - parties, and a similar threat are virus filters. E. g. the content - industry could demand to teach all virus and spam filters to delete - all e-mails containing the URL of an MP3 web server outside the - legislations. Software manufacturers could try to block all e-mails - containing software license keys, thus trying to make unallowed - distribution more difficult. Governments could try to block - distribution of unwanted informations. - - This proposal does not have this problem. - - -12. Privacy Considerations - - (It was proposed on the 56th IETF meeting to have a privacy section - in drafts and RFCs.) - -12.1. Draft specific considerations - -12.1.1. No content leaking - - Since the RMX approach doesn't touch the contents of a message in - any way, there is obviously no way of leaking out any information - about the content of the message. RMX is based solely on the - envelope recipient address. However, methods to fix problems not - covered by RMX might allow content leaking, e.g. if the acceptance - of a message with an empty sender address requires the reference to - the message id of an e-mail recently sent, this allows an attacker - to verify whether a certain message was delivered from there. - -12.1.2. Message reception and sender domain - - Message delivery triggers RMX and APL requests by the recipient. - Thus, the admin of the DNS server or an eavesdropper could learn - that the given machine has just received a message with a sender - from this address, even if the SMTP traffic itself had been - encrypted. - - - -Hadmut Danisch Experimental [Page 28] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - However, most of today's MTAs do query the MX and A records of the - domain after the MAIL FROM command, so this is not a real new - threat. - -12.1.3. Network structure - - Since RMX and its associated APL records provide a complete list of - all IP addresses of hosts authorized to send messages from this - address, they do reveal informations about the network structure - and maybe the lifestyle of the domain owner, since a growing number - of domains are owned by single persons or families. E.g. the RMX - records could reveal where someone has his job or spends his time - at weekends. - - If such informations are to be kept secret, it is the user's job to - not sent e-mails from there and to relay them from non-compromising - IP addresses. - -12.1.4. Owner information distribution - - As described above, RMX depends partly on the reliability of the - whois database entries. It does not make anonymous domains - impossible, but it requires to keep the database entries "true", i. - e. if a whois entry does not contain informations about the - responsible person, this must be unambigously labeled as anonymous. - It must not contain fake names and addresses to pretend a non- - existing person. However, since most Internet users on the world - feel extremely annoyed by spam, they will urge their MTA admin to - reject messages from anonymous domains. The domain owner will have - the choice to either remain anonymous but be not able to send e- - mail to everyone in the world, or to be able but to reveal his - identity to everyone on the world. - - It would be possible to provide whois-like services only to - recipients of recent messages, but this would make things too - complicated to be commonly adopted. - -12.2. General Considerations about spam defense - -12.2.1. Content leaking of content filters - - As described above in the Security chapter, there are spam filters - which inherently allow leakage of the message body. Those filters - upload either the message body, or in most cases just some kind of - checksum to a third party, which replies whether this is to be seen - as spam or not. The idea is to keep a databases of all digests of - all messages. If a message is sent more often than some threshold, - it is to be considered as a mass mail and therefore tagged as spam. - - - -Hadmut Danisch Experimental [Page 29] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - While the digest itself does not reveal the content of the message, - it perfectly reveals where a particular message has been delivered - to. If a government finds just a single unwanted message, if a - software manufacturer finds a single message with a stolen product - license key, if someone finds a message with unpatriotic content, - it takes just a single database lookup to get a list of all people - who received this particular message. Content filters with digest - upload are the perfect "Big Brother". - -12.2.2. Black- and Whitelists - - Some proposals against spam are based on a central database of - white- or blacklisted IP addresses, Sender names, Message IDs or - whatever. Again, there is a central database which learns who has - received which e-mail or from which sender with every query. This - allows tracking relations between persons, which is also a breach - of privacy. - - - -13. Deployment Considerations - -13.1. Compatibility - -13.1.1. Compatibility with old mail receivers - - Since the suggested extension doesn't change the SMTP protocol at - all, it is fully compatible with old mail receivers. They simply - don't ask for the RMX records and don't perform the check. - -13.1.2. Compatibility with old mail senders - - Since the SMTP protocol is unchanged and the SMTP sender is not - involved in the check, the method is fully compatible with old mail - senders. - -13.1.3. Compatibility with old DNS clients - - Since the RMX is a new RR, the existing DNS protocol and zone - informations remain completely untouched. - - If RMX is provided as a TXT record instead, it must be ensured that - no other software is misinterpreting this entry. - -13.1.4. Compatibility with old DNS servers - - Full compatibility: If the server does not support RMX records, RMX - in TXT records can be used. - - - -Hadmut Danisch Experimental [Page 30] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -13.2. Enforcement policy - - Obviously, for reasons of backward compatibility and smooth - introduction of this scheme, RMX records can't be required - immediately. Domains without RMX records must temporarily be - treated the same way as they are treated right now, i.e. e-mail - must be accepted from anywhere. But once the scheme becomes - sufficiently widespread, mail relays can start to refuse e-mails - with sender addresses from domains without RMX records, thus - forcing the owner of the domain to include a statement of - authorization into the domain's zone table. Domain owners will - still be free to have an RMX record with a network and mask - 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere. - On the other hand, mail receivers will be free to refuse mails from - domains without RMX records or RMX records which are too loose. - Advanced MTAs might have a configuration option to set the maximum - number of IP addresses authorized to use a domain. E-mails from a - domain, which's RMX records exceed this limit, would be rejected. - For example, a relay could reject e-mails from domains which - authorize more than 8 IP addresses. That allows to accept e-mails - only from domains with a reasonable security policy. - - - -14. General considerations about fighting spam - - Is there a concise technical solution against spam? Yes. - - Will it be deployed? Certainly not. - - Why not? Because of the strong non-technical interests of several - parties against a solution to the problem, as described below. - Since these are non-technical reasons, they might be beyond the - scope of such a draft. But since they are the main problems that - prevent fighting spam, it is unavoidable to address them. This - chapter exists temporarily only and should support the discussion - of solutions. It is not supposed to be included in a later RFC. - -14.1. The economical problem - - As has been recently illustrated in the initial session of the - IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting, - sending spam is a business with significant revenues. - - But a much bigger business is selling Anti-Spam software. This is a - billion dollar market, and it is rapidly growing. Any simple and - effective solution against spam would defeat revenues and drive - several companies into bankrupt, would make consultants jobless. - - - -Hadmut Danisch Experimental [Page 31] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - Therefore, spam is essential for the Anti-Spam business. If there - is no spam, then no Anti-Spam software can be sold, similar to the - Anti-Virus business. There are extremely strong efforts to keep - this market growing. Viruses, Worms, and now spam are just perfect - to keep this market alive: It is not sufficient to just buy a - software. Databases need to be updated continuously, thus making - the cash flow continuously. Have a single, simple, and permanent - solution to the problem and - boom - this billion dollar market is - dead. - - That's one of the reasons why people are expected to live with - spam. They have to live with it to make them buy Anti-Spam - software. Content filters are perfect products to keep this market - alive. - -14.2. The POP problem - - Another problem is the history of mail delivery. Once upon a time, - there used to be very few SMTP relays which handled the e-mail - traffic of all the world, and everybody was happy with that. Then - odd things like Personal Computers, which are sometimes switched - off, portable computers, dynamicly assigned IP addresses, IP access - from hotel rooms, etc. was invented, and people became unhappy, - because SMTP does not support delivery to such machines. To make - them happy again, the Post Office Protocol[4] was invented, which - turned the last part of message delivery from SMTP's push style - into a pull style, thus making virtually every computer on the - world with any random IP address a potential receiver of mails for - random domains. Unfortunately, only receiving e-mail was covered, - but sending e-mail was left to SMTP. - - The result is that today we have only very few SMTP relays pointed - to by MX records, but an extreme number of hosts sending e-mail - with SMTP from any IP address with sender addresses from any - domain. Mail delivery has become very asymmetric. Insecurity, - especially forgeability, has become an essential part of mail - transport. - - That problem could easily be fixed: Use protocols which allow - uploading of messages to be delivered. If a host doesn't receive - messages by SMTP, it shouldn't deliver by SMTP. Mail delivery - should go the same way back that incoming mail went in. This is - not a limitation to those people on the road who plug their - portable computer in any hotel room's phone plug and use any - provider. If there is a POP server granting download access from - anywhere, then the same server should be ready to accept uploading - of outgoing messages. - - - - -Hadmut Danisch Experimental [Page 32] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - But as I saw from the comments on the first version of this draft, - people religiously insist on sending e-mail with their domain from - any computer with any IP address in the world, e.g. when visiting a - friend using her computer. It appears to be impossible to convince - people that stopping mail forgery requires every one of them to - give up forging. - -14.3. The network structure problem - - A subsequent problem is that many organisations failed to implement - a proper mail delivery structure and heavily based their network on - this asymmetry. I received harsh comments from Universities who - were unable to give their network a good structure. While they do - have a central mail relay for incoming mail to the universities - domain, they developed a structure where every member of the - University randomly sends e-mails with that University's domain as - a sender address from home or everywhere in the world with any - dynamically assigned IP address from any provider. So this domain - is to be used from every possible IP address on earth, and they are - unable to operate any authentication scheme. Furthermore, they were - unable to understand that such a policy heavily supports spam and - that they have to expect that people don't accept such e-mails - anymore once they become blacklisted. - - As long as organisations insist on having such policies, spammers - will have a perfect playground. - -14.4. The mentality problem - - Another problem is the mentality of many internet users of certain - countries. I received harsh comments from people who strongly - insisted on the freedom to send any e-mail with any sender address - from anywhere, and who heavily refused any kind of authentication - step or any limitation, because they claimed that this would - infringe their constitutional "Freedom of speech". They are - undeviatingly convinced that "Freedom of speech" guarantees their - right to talk to everybody with any sender address, and that is has - to be kept the recipient's own problem to sort out what he doesn't - want to read - on the recipient's expense. - - It requires a clear statement that the constitutional "Freedom of - Speech" does not cover molesting people with unsolicited e-mail - with forged sender address. - -14.5. The identity problem - - How does one fight against mail forgery? With authentication. What - is authentication? In simple words: Making sure that the sender's - - - -Hadmut Danisch Experimental [Page 33] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - - real identity meets the recipients idea of who is the sender, based - on the sender address which came with the message. - - What is identity? It is the main problem. Several countries have - different ideas of "identity", which turn out to be somehow - incompatible. In some countries people have identity cards and - never change their name and birthday. Identities are created by - human birth, not by identity changes. Other countries do not have - such a tight idea about identity. People's temporary identity is - based on nothing more than a driving license and a social security - number. With this background, it is virtually impossible to create - a trustworthy PKI covering all Internet users. I learned that it is - extremely difficult to convince some people to give up random e- - mail sending. - -14.6. The multi-legislation problem - - Many proposals about fighting spam are feasible under certain - legislations only, and are inacceptable under some of the - legislations. But a world wide applicable method is required. - That's why the approach to ask everone on the world to sign - messages with cryptographic keys is not feasible. - - -Implementation and further Information - - Further informations and a test implementation are available at - - http://www.danisch.de/work/security/antispam.html - http://www.danisch.de/software/rmx/ - - - Additional informations and a technology overview are also - available at - - http://www.mikerubel.org/computers/rmx_records/ - - -References - - - -1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- - els," RFC 2119 (March 1997). - -2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001). - - - - - -Hadmut Danisch Experimental [Page 34] - -INTERNET-DRAFT DNS RMX RR Oct 2003 - - -3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," - RFC 1035 (November 1987). - -4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939 - (May 1996). - - -Draft History - - 00 Dec 2002 - 01 Apr 2003 - 02 Jun 2003 - 03 Oct 2003 - -Author's Address - - Hadmut Danisch - - Tennesseeallee 58 - 76149 Karlsruhe - Germany - - Phone: ++49-721-843004 or ++49-351-4850477 - E-Mail: rfc@danisch.de - -Comments - - Please send comments to rfc@danisch.de. - -Expiry - - This drafts expires on Apr 1, 2004. - - - - - - - - - - - - - - - - - - - -Hadmut Danisch Experimental [Page 35] - diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt deleted file mode 100644 index 7b5e8cc445..0000000000 --- a/doc/draft/draft-dnsext-opcode-discover-02.txt +++ /dev/null @@ -1,241 +0,0 @@ - -IETF DNSEXT WG Bill Manning -draft-dnsext-opcode-discover-02.txt ep.net - Paul Vixie - ISC - 13 Oct 2003 - - - The DISCOVER opcode - -This document is an Internet-Draft and is subject to all provisions of -Section 10 of RFC2026. - -Comments may be submitted to the group mailing list at "mdns@zocalo.net" -or the authors. - -Distribution of this memo is unlimited. - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other groups -may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months and -may be updated, replaced, or obsoleted by other documents at any time. It -is inappropriate to use Internet-Drafts as reference material or to cite -them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in RFC 2119 - -0. Abstract: - - The QUERY opcode in the DNS is designed for unicast. With the - development of multicast capabilities in the DNS, it is desireable - to have a more robust opcode for server interactions since a single - request may generate replies from multiple responders. So DISCOVER - is defined to deal with replies from multiple responders. - - As such, this document extends the core DNS specifications to allow - clients to have a method for coping with replies from multiple - responders. Use of this new opcode may facilitate DNS operations in - modern networking topologies. A prototype of the DISCOVER opcode - was developed during the TBDS project (1999-2000), funded under DARPA - grant F30602-99-1-0523. - -1. Introduction: - - This document describes an experimental extension to the DNS to receive - multiple responses which is the likely result when using DNS that has - enabled multicast queries. This approach was developed as part of the - TBDS research project, funded under DARPA grant F30602-99-1-0523. The - full processing rules used by TBDS are documented here for possible - incorporation in a future revision of the DNS specification." - -2. Method: - - DISCOVER works like QUERY except: - - 1. it can be sent to a broadcast or multicast destination. QUERY - isn't defined for non-unicast, and arguably shouldn't be. - - 2. the Question section, if present, has - tuples. TBDS tried to augment this structure as follows: - . While this worked for our purposes in - TBDS, it is cleaner to place the SRV question in a separate pass. - - 3. if QDCOUNT equals 0 then only servers willing to do recursion should - answer. Other servers must silently discard the DISCOVER request. - - 4. if QDCOUNT is not equal to 0 then only servers who are authoritative - for the zones named by some QNAME should answer. - - 5. responses may echo the request's Question section or leave it blank, - just like QUERY. - - 6. responses have standard Answer, Authority, and Additional sections. - e.g. the response is the same as that to a QUERY. It is desireable - that zero content answers not be sent to avoid badly formed or - unfulfilled requests. Responses should be sent to the unicast - address of the requester and the source address should reflect - the unicast address of the responder. - - Example usage for gethostby{name,addr}-style requestors: - - Compute the zone name of the enclosing in-addr.arpa, ip6.int, or - ip6.arpa domain. - - DISCOVER whether anyone in-scope is authoritative for this zone. - - If so, query these authoritative servers for local - in-addr/ip6 names. - - If not, DISCOVER whether there are recursive servers available. - - If so, query these recursive servers for local - in-addr/ip6 names. - - So, a node will issue a multicast request with the DISCOVER opcode at - some particular multicast scope. Then determine, from the replies, - whether there are any DNS servers which are authoritative (or support - recursion) for the zone. Replies to DISCOVER requests MUST set the - Recursion Available (RA) flag in the DNS message header. - - It is important to recognize that a requester must be prepared to - receive multiple replies from multiple responders. We expect that - there will be a single response per responder. - - Once one learns a host's FQDN by the above means, repeat the process - for discovering the closest enclosing authoritative server of such - local name. - - Cache all NS and A data learned in this process, respecting TTL's. - - TBDS usage for SRV requestors: - - Do the gethostbyaddr() and gethostbyname() on one's own link-local - address, using the above process. - - Assume that the closest enclosing zone for which an authority server - answers an in-scope DISCOVER packet is "this host's parent domain". - - Compute the SRV name as _service._transport.*.parentdomain. - - This is a change to the definition as defined in RFC 1034. - A wildcard label ("*") in the QNAME used in a DNS message with - opcode DISCOVER SHOULD be evaluated with special rules. The - wildcard matches any label for which the DNS server data is - authoritative. For example 'x.*.example.com.' would match - 'x.y.example.com.' and 'x.yy.example.com.' provided that the - server was authoritative for 'example.com.' In this particular - case, we suggest the follwing considerations be made: - - getservbyname() can be satisfied by issuing a request with - this computed SRV name. This structure can be - populated by values returned from a request as follows: - - s_name The name of the service, "_service" without the - preceding underscore. - s_aliases The names returned in the SRV RRs in replies - to the query. - s_port The port number in the SRV RRs replies to the - query. If these port numbers disagree - one - of the port numbers is chosen, and only those - names which correspond are returned. - s_proto The transport protocol from named by the - "_transport" label, without the preceding - underscore. - - Send SRV query for this name to discovered local authoritative servers. - - Usage for disconnected networks with no authoritative servers: - - Hosts should run a "stub server" which acts as though its FQDN is a - zone name. Computed SOA gives the host's FQDN as MNAME, "." as the - ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE - and the other timers. Compute NS as the host's FQDN. Compute the - glue as the host's link-local address. Or Hosts may run a - "DNS stub server" which acts as though its FQDN is a zone name. The - rules governing the behavior of this stub server are given elsewhere - [1] [2]. - - Such stub servers should answer DISCOVER packets for its zone, and - will be found by the iterative "discover closest enclosing authority - server" by DISCOVER clients, either in the gethostbyname() or SRV - cases described above. Note that stub servers only answer with - zone names which exactly match QNAME's, not with zone names which - are owned by QNAME's. - - The main deviation from the DNS[3][4] model is that a host (like, say, a - printer offering LPD services) has a DNS server which answers authoritatively - for something which hasn't been delegated to it. However, the only way that - such DNS servers can be discovered is with a new opcode, DISCOVER, which - is explicitly defined to discover undelegated zones for tightly scoped - purposes. Therefore this isn't officially a violation of DNS's coherency - principles. In some cases a responder to DISCOVER may not be traditional - DNS software, it could be special purpose software. - -3. IANA Considerations - - As a new opcode, the IANA will need to assign a numeric value - for the memnonic. The last OPCODE assigned was "5", for UPDATE. - Test implementations have used OPCODE "6". - -4. Security Considerations - - No new security considerations are known to be introduced with any new - opcode, however using multicast for service discovery has the potential - for denial of service, primarly from flooding attacks. It may also be - possible to enable deliberate misconfiguration of clients simply by - running a malicious DNS resolver that claims to be authoritative for - things that it is not. One possible way to mitigate this effect is by - use of credentials, such as CERT resource records within an RR set. - The TBDS project took this approach. - -5. Attribution: - - This material was generated in discussions on the mdns mailing list -hosted by Zocalo in March 2000. Updated by discussion in September/October -2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, -Erik Guttman, Bill Manning and Paul Vixie were active contributors. - -6. Author's Address - - Bill Manning - PO 12317 - Marina del Rey, CA. 90295 - +1.310.322.8102 - bmanning@karoshi.com - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 7001 - - -7. References - -Informational References: - -[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS", - draft-ietf-dnsext-mdns-00.txt, November 2000. Expired - -[2] Woodcock, B., Manning, B., "Multicast Domain Name Service", - draft-manning-dnsext-mdns-00.txt, August 2000. Expired. - -Normative References: -[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", - RFC 1034, November 1987. -[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", - RFC 1035, November 1987 - - ----------------------------EOL----------------------- - diff --git a/doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt b/doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt deleted file mode 100644 index 3e08247f69..0000000000 --- a/doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt +++ /dev/null @@ -1,370 +0,0 @@ -DNS Extensions working group V.Dolmatov, Ed. -Internet-Draft Cryptocom Ltd. -Intended status: Standards Track April 8, 2009 -Expires: December 31, 2009 - - - Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records - for DNSSEC - draft-dolmatov-dnsext-dnssec-gost-00 - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on 31 December 2009. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - This document describes how to produce GOST signature and hash algorithms - DNSKEY and RRSIG resource records for use in the Domain Name System - Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . - 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . - 2.1. Using a public key with existing cryptographic libraries. . - 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . - 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . - 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . - 5. NSEC3 Resource Records . . . . . . . . . . . . . . . . . . . . - 6. Deployment Considerations . . . . . . . . . . . . . . . . . . . - 6.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . - 6.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . - 6.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . - 7. Implementation Considerations . . . . . . . . . . . . . . . . . - 7.1. Support for GOST signatures . . . . . . . . . . . . . . . . - 7.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . - 7.2.1. NSEC3 in Authoritative servers . . . . . . . . . . . . - 7.2.2. NSEC3 in Validators . . . . . . . . . . . . . . . . . . - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . - 10.1. Normative References . . . . . . . . . . . . . . . . . . . - 10.2. Informative References . . . . . . . . . . . . . . . . . . - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical distributed - database for Internet Naming. The DNS has been extended to use - cryptographic keys and digital signatures for the verification of the - authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034 - [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security - Extensions, called DNSSEC. - - RFC 4034 describes how to store DNSKEY and RRSIG resource records, - and specifies a list of cryptographic algorithms to use. This - document extends that list with the signature and hash algorithms - GOST [GOST3410, GOST3411], - and specifies how to store DNSKEY data and how to produce - RRSIG resource records with these hash algorithms. - - Familiarity with DNSSEC and GOST signature and hash - algorithms is assumed in this document. - - The term "GOST" is not officially defined, but is usually used to - refer to the collection of the Russian cryptographic algorithms - GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. Since GOST 28147-89 - is not used in DNSSEC, GOST will only refer to GOST R 34.10-2001 - (signatire algorithm) and GOST R 34.11-94 (hash algorithm) 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]. - - -2. DNSKEY Resource Records - - The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. - - GOST R 34.10-2001 public keys are stored with the algorithm number {TBA1}. - - The public key parameters are those identified by - id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357]. - The digest parameters for signature are those identified by - id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357]. - - The wire format of the public key is compatible with RFC 4491 [RFC4491]: - - According to [GOSTR341001], a public key is a point on the elliptic - curve Q = (x,y). - - The wire representation of a public key MUST contain 64 octets, where the - first 32 octets contain the little-endian representation of x and the - second 32 octets contain the little-endian representation of y. This - corresponds to the binary representation of (256||256) from - [GOSTR341001], ch. 5.3. - -2.1. Using a public key with existing cryptographic libraries - - Existing GOST-aware cryptographic libraries at time of this document - writing are capable to read GOST public keys via generic X509 API if the - key is encoded according to RFC 4491 [RFC4491], section 2.3.2. - - To make this encoding from the wire format of a GOST public key, prepend - a key data with the following 37-byte sequence: - - 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 0x12 - 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a 0x85 0x03 - 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40 - -2.2. GOST DNSKEY RR Example - - The following DNSKEY RR stores a DNS zone key for example.com - - example.com. 86400 IN DNSKEY 256 3 {TBA1} ( RamuUwTG1r4RUqsgXu/xF6B+Y - tJLzZEykiZ4C2Fa1gV1pI/8GA - el2Wm69Cz5h1T9eYAQKFAGwzW - m4Lke0E26aw== ) - -3. RRSIG Resource Records - - The value of the signature field in the RRSIG RR follows the RFC 4490 - [RFC4490] and is calculated as follows. The values for the RDATA fields - that precede the signature data are specified in RFC 4034 [RFC4034]. - - hash = GOSTR3411(data) - - where "data" is the wire format data of the resource record set that is - signed, as specified in RFC 4034 [RFC4034]. Hash MUST be calculated with - GOST R 34.11-94 parameters identified by - id-GostR3411-94-CryptoProParamSet [RFC4357]. - - Signature is calculated from the hash according to the GOST R 34.10-2001 - standard and its wire format is compatible with RFC 4490 [RFC4490]. - Quoting RFC 4490: - - "The signature algorithm GOST R 34.10-2001 generates a digital - signature in the form of two 256-bit numbers, r and s. Its octet - string representation consists of 64 octets, where the first 32 - octets contain the big-endian representation of s and the second 32 - octets contain the big-endian representation of r." - -4. DS Resource Records - - GOST R 34.11-94 digest algorithm is denoted in DS RR by the digest type - {TBA2}. The wire format of a digest value is compatible with RFC 4490 - [RFC4490]. Quoting RFC 4490: - - "A 32-byte digest in little-endian representation." - - The digest MUST always be calculated with GOST R 34.11-94 parameters - identified by id-GostR3411-94-CryptoProParamSet [RFC4357]. - -5. NSEC3 Resource Records - - GOST R 34.11-94 digest algorithm is denoted in NSEC3 RR by the digest type - {TBA2}. The wire format of a digest value is compatible with RFC 4490 - [RFC4490]. Quoting RFC 4490: - - "A 32-byte digest in little-endian representation." - - The digest MUST always be calculated with GOST R 34.11-94 parameters - identified by id-GostR3411-94-CryptoProParamSet [RFC4357]. - -6. Deployment Considerations - -6.1. Key Sizes - - According to RFC4357 [RFC4357] key size of GOST public keys MUST - be 512 bits. - -6.2. Signature Sizes - - According to GOST signature algorithm [GOST3410] size of GOST signature - is 512 bit. - -6.3. Digest Sizes - - According to GOST R 34.11-94 [GOST3411] size of GOST digest is 256 bit. - -7. Implementation Considerations - -7.1. Support for GOST signatures - - DNSSEC aware implementations SHOULD be able to support RRSIG and - DNSKEY resource records created with the GOST algorithms as - defined in this document. - -7.2. Support for NSEC3 Denial of Existence - - RFC5155 [RFC5155] defines new algorithm identifiers for existing - signing algorithms, to indicate that zones signed with these - algorithm identifiers use NSEC3 instead of NSEC records to provide - denial of existence. That mechanism was chosen to protect - implementations predating RFC5155 from encountering resource records - they could not know about. This document does not define such - algorithm aliases, and support for NSEC3 denial of existence is - implicitly signaled with support for one of the algorithms defined in - this document. - -7.2.1. NSEC3 in Authoritative servers - - An authoritative server that does not implement NSEC3 MAY still serve - zones that use GOST with NSEC denial of existence. - -7.2.2. NSEC3 in Validators - - A DNSSEC validator that implements GOST MUST be able to handle - both NSEC and NSEC3 [RFC5155] negative answers. If this is not the - case, the validator MUST treat a zone signed with GOST - as signed with an unknown algorithm, and thus as insecure. - - -8. IANA Considerations - - This document updates the IANA registry "DNS SECURITY ALGORITHM - NUMBERS -- per [RFC4035] " - (http://www.iana.org/assignments/dns-sec-alg-numbers). The following - entries are added to the registry: - Zone Trans. - Value Algorithm Mnemonic Signing Sec. References Status - {TBA1} GOST R 34.10-2001 GOST Y * (this memo) OPTIONAL - - This document updates the RFC 4034 [RFC4034] Digest Types assignment - (RFC 4034, section A.2): - - Value Algorithm Status - {TBA2} GOST R 34.11-94 OPTIONAL - -9. Acknowledgments - - This document is a minor extension to RFC 4034 [RFC4034]. Also, we - try to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509] - and RFC 4357 [RFC4357] for consistency. The authors of and - contributors to these documents are gratefully acknowledged for - their hard work. - - The following people provided additional feedback and text: Dmitry - Burkov, Jaap Akkerhuis, Jelte Jansen and Wouter Wijngaards. - - -10. References - -10.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, March 1997. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [GOST3410] "Information technology. Cryptographic data security. - Signature and verification processes of [electronic] - digital signature.", GOST R 34.10-2001, Gosudarstvennyi - Standard of Russian Federation, Government Committee of - the Russia for Standards, 2001. (In Russian) - - [GOST3411] "Information technology. Cryptographic Data Security. - Hashing function.", GOST R 34.11-94, Gosudarstvennyi - Standard of Russian Federation, Government Committee of - the Russia for Standards, 1994. (In Russian) - - [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional - Cryptographic Algorithms for Use with GOST 28147-89, - GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 - Algorithms", RFC 4357, January 2006. - - [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, - GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 - Algorithms with Cryptographic Message Syntax (CMS)", - RFC 4490, May 2006. - - [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST - R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 - Algorithms with the Internet X.509 Public Key - Infrastructure Certificate and CRL Profile", RFC 4491, - May 2006. - - - -10.2. Informative References - - [NIST800-57] - Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, - "Recommendations for Key Management", NIST SP 800-57, - March 2007. - - [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography - Standards (PKCS) #1: RSA Cryptography Specifications - Version 2.1", RFC 3447, February 2003. - - [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - -Authors' Addresses - - -Vasily Dolmatov, Ed. -Cryptocom Ltd. -Bolotnikovskaya, 23 -Moscow, 117303, Russian Federation - -EMail: dol@cryptocom.ru - -Artem Chuprina -Cryptocom Ltd. -Bolotnikovskaya, 23 -Moscow, 117303, Russian Federation - -EMail: ran@cryptocom.ru - -Igor Ustinov -Cryptocom Ltd. -Bolotnikovskaya, 23 -Moscow, 117303, Russian Federation - -EMail: igus@cryptocom.ru - - Expires December 31, 2009 [Page ] - - diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt deleted file mode 100644 index 224e7ad169..0000000000 --- a/doc/draft/draft-durand-dnsop-dynreverse-00.txt +++ /dev/null @@ -1,240 +0,0 @@ -Internet Engineering Task Force Alain Durand -INTERNET-DRAFT SUN Microsystems -Feb 21, 2003 -Expires Aug 2, 2003 - - - - Dynamic reverse DNS for IPv6 - - - - -Status of this memo - - - This memo provides information to the Internet community. It does - not specify an Internet standard of any kind. This memo is in full - conformance with all provisions of Section 10 of RFC2026 [RFC2026]. - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -Abstract - - This document describes a method to dynamically generate PTR records - and corresponding A or AAAA records when the reverse path DNS tree is - not populated. - - A special domain dynrev.arpa. is reserved for that purpose. - - -1. Introduction - - In IPv4, the reverse path tree of the DNS under in-addr.arpa. - although not perfectly maintained, is still mostly usable and its - existence is important for a number of applications that relies on - its existence and decent status. Some applications performs some - (very) weak security checks based on it. Mail relays relies on it for - some anti-spams checks an some FTP server will not let you in unless - your IP address resolve properly with a PTR record. - - IPv6 addresses being much longer (and cumbersome) than IPv4 - addresses, it is to fear that the reverse path tree under ip6.arpa. - would not be as well maintained. Also, tools like 6to4, Isatap and - others have made creative use of the 128 bits of an IPv6 address to - automatically embed an IPv4 address to enable seamless connection to - the IPv6 Internet. However, no provision has been made to make sure - the reverse path tree gets automatically updated as well for those - new IPv6 addresses. One step furter, RFC3041 describes a mechanism - to basically use random bits in the bottom part of an IPv6 address to - preserver anonymity. If those addresses are to resolve in the reverse - path tree, it obviously has to be with anonymous data as well. - Another point to note is that home customer ISPs in IPv4 have a - current practice to pre-populate the reverse path tree with names - automatically derived from the IP addresses. This practice is no - longer possible in IPv6, where IP address allocation is not dense as - it is the case in IPv4. The mere size of typical customer allocation - (2^48 according to the recommendation of RFC3177) makes it - impossible. - - Applications that check the existence of PTR records usually follow - this by checking if the name pointed by the PTR resolve in a A (or - AAAA for IPv6) that match the original IP address. Thus the forward - path tree must also include the corresponding data. - - One simple approach of this problem is to simply declare the usage of - the reverse path DNS as described above obsolete. The author believe - this is too strong an approach for now. - - Similarly, a completely different approach would be to deprecate the - usage of DNS for the reverse tree altogether and replace it by - something inspired from ICMP name-info messages. The author believes - that this approached is an important departure from the current - practise and thus not very realistic. Also, there are some concerns - about the the security implications of this method as any node could - easily impersonate any name. This approach would fundamentally change - the underlying assumption of "I trust what has been put in the DNS by - the local administrators" to "I trust what has been configured on - each machine I query directly". - - - -2. Dynamic record generation - - If static pre-population of the tree is not possible anymore and data - still need to be returned to applications using getnameinfo(), the - alternative is dynamic record generation. This can be done is two - places: in the DNS servers responsible for the allocated space (/64 - or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the - sub resolver library or the recursive DNS server). - - 2.1. On the resolver side. - - The resolver, either in the recursive DNS server or in the stub - library could theoretically generate this data. - - In case DNSsec is in place, the recursive DNS server would have to - pretend these records are authentic. - - If the synthesis is done in the stub-resolver library, no record - needs to be actually generated, only the right information needs to - be passed to getnameinfo() and getaddrinfo(). If the synthesis is - done in the recursive DNS server, no modification is required to - existing stub resolvers. - - -2.2. On the server side. - - PTR records could be generated automatically by the server - responsible for the reverse path tree of an IPv6 prefix (a /64 or /48 - prefixes or basically anything in between) when static data is not - available. - - There could be impact on DNSsec as the zone or some parts of the zone - may need to be resigned each time a DNS query is made for an - unpopulated address. This can be seen as a DOS attack on a DNSsec - zone, so server side synthesis is not recommended if DNSsec is - deployed. - - - -3. Synthesis - - The algorithm is simple: Do the normal queries. If the query returns - No such domain, replace this answer by the synthetized one if - possible. - -3.1. PTR synthesis - - The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa. - where [X] is any valid DNS name. - - The fact that the synthetized PTR points to the dynrev.arpa. domain - is an indication to the applications that this record has been - dynamically generated. - - -3.2. A synthesis - - If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A - record for the string [X].dynrev.arpa. which value is d.c.b.a. with - a,b,c & d being integer [0..255] - - -3.3. AAAA synthesis - - If [X] is in the form - a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in- - addr.arpa, one can synthetized a AAAA record for the string - [X].dynrev.arpa. which value is - FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with - a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits. - - -3.4. Server side synthesis - - If synthesis is done on the server side, PTR could be set not to use - the dynrev.arpa domain but the local domain name instead. It culd be - for instance dynrev.mydomain.com. - - Note also that server side synthesis is not incompatible with - resolver side synthesis. - - - -4. IANA considerations - - The dynrev.arpa. domain is reserved for the purpose of this document. - - - -5. Security considerations - - Section 2. discusses the the interactions with DNSsec. - - - -6. Authors addresses - - Alain Durand - SUN Microsystems, Inc - 17, Network Circle - UMPK17-202 - Menlo Park, CA 94025 - USA - Mail: Alain.Durand@sun.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt deleted file mode 100644 index fa41e7635e..0000000000 --- a/doc/draft/draft-ietf-dnsext-2929bis-01.txt +++ /dev/null @@ -1,928 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories -Expires: February 2006 August 2005 - - - - Domain Name System (DNS) IANA Considerations - ------ ---- ------ ----- ---- -------------- - - - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Distribution of this draft is unlimited. It is intended to become - the new BCP 42 obsoleting RFC 2929. Comments should be sent to the - DNS Working Group mailing list . - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than a "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - - -Abstract - - 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. - - - - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. DNS Query/Response Headers..............................3 - 2.1 One Spare Bit?.........................................4 - 2.2 Opcode Assignment......................................4 - 2.3 RCODE Assignment.......................................5 - 3. DNS Resource Records....................................6 - 3.1 RR TYPE IANA Considerations............................7 - 3.1.1 DNS TYPE Allocation Policy...........................8 - 3.1.2 Special Note on the OPT RR...........................9 - 3.1.3 The AFSDB RR Subtype Field...........................9 - 3.2 RR CLASS IANA Considerations...........................9 - 3.3 RR NAME Considerations................................11 - 4. Security Considerations................................11 - - Appendix: Changes from RFC 2929...........................12 - - Copyright and Disclaimer..................................13 - Normative References......................................13 - Informative References....................................14 - - Authors Addresses.........................................16 - Expiration and File Name..................................16 - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -1. Introduction - - The Domain Name System (DNS) provides replicated distributed secure - hierarchical databases which hierarchically store "resource records" - (RRs) under domain names. DNS data is structured into CLASSes and - zones which can be independently maintained. See [RFC 1034, 1035, - 2136, 2181, 4033] familiarity with which is assumed. - - This document provides, either directly or by reference, general IANA - parameter assignment considerations applying across DNS query and - response headers and all RRs. There may be additional IANA - considerations that apply to only a particular RR type or - query/response opcode. See the specific RFC defining that RR type or - query/response opcode for such considerations if they have been - defined, except for AFSDB RR considerations [RFC 1183] which are - included herein. This RFC obsoletes [RFC 2929]. - - IANA currently maintains a web page of DNS parameters. See - . - - "IETF Standards Action", "IETF Consensus", "Specification Required", - and "Private Use" are as defined in [RFC 2434]. - - - -2. DNS Query/Response Headers - - The header for DNS queries and responses contains field/bits in the - following diagram taken from [RFC 2136, 2929]: - - 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/ZOCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT/PRCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT/UPCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The ID field identifies the query and is echoed in the response so - they can be matched. - - The QR bit indicates whether the header is for a query or a response. - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful - only in queries or only in responses, depending on the bit. However, - many DNS implementations copy the query header as the initial value - of the response header without clearing bits. Thus any attempt to - use a "query" bit with a different meaning in a response or to define - a query meaning for a "response" bit is dangerous given existing - implementation. Such meanings may only be assigned by an IETF - Standards Action. - - The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), - authority count (NSCOUNT), and additional information count (ARCOUNT) - express the number of records in each section for all opcodes except - Update. These fields have the same structure and data type for - Update but are instead the counts for the zone (ZOCOUNT), - prerequisite (PRCOUNT), update (UPCOUNT), and additional information - (ARCOUNT) sections. - - - -2.1 One Spare Bit? - - There have been ancient DNS implementations for which the Z bit being - on in a query meant that only a response from the primary server for - a zone is acceptable. It is believed that current DNS - implementations ignore this bit. - - Assigning a meaning to the Z bit requires an IETF Standards Action. - - - -2.2 Opcode Assignment - - Currently DNS OpCodes are assigned as follows: - - OpCode Name Reference - - 0 Query [RFC 1035] - 1 IQuery (Inverse Query, Obsolete) [RFC 3425] - 2 Status [RFC 1035] - 3 available for assignment - 4 Notify [RFC 1996] - 5 Update [RFC 2136] - 6-15 available for assignment - - New OpCode assignments require an IETF Standards Action as modified - by [RFC 4020]. - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -2.3 RCODE Assignment - - It would appear from the DNS header above that only four bits of - RCODE, or response/error code are available. However, RCODEs can - appear not only at the top level of a DNS response but also inside - OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. - The OPT RR provides an eight bit extension resulting in a 12 bit - RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field. - - Error codes appearing in the DNS header and in these three RR types - all refer to the same error code space with the single exception of - error code 16 which has a different meaning in the OPT RR from its - meaning in other contexts. See table below. - - RCODE Name Description Reference - Decimal - Hexadecimal - 0 NoError No Error [RFC 1035] - 1 FormErr Format Error [RFC 1035] - 2 ServFail Server Failure [RFC 1035] - 3 NXDomain Non-Existent Domain [RFC 1035] - 4 NotImp Not Implemented [RFC 1035] - 5 Refused Query Refused [RFC 1035] - 6 YXDomain Name Exists when it should not [RFC 2136] - 7 YXRRSet RR Set Exists when it should not [RFC 2136] - 8 NXRRSet RR Set that should exist does not [RFC 2136] - 9 NotAuth Server Not Authoritative for zone [RFC 2136] - 10 NotZone Name not contained in zone [RFC 2136] - 11 - 15 Available for assignment - 16 BADVERS Bad OPT Version [RFC 2671] - 16 BADSIG TSIG Signature Failure [RFC 2845] - 17 BADKEY Key not recognized [RFC 2845] - 18 BADTIME Signature out of time window [RFC 2845] - 19 BADMODE Bad TKEY Mode [RPC 2930] - 20 BADNAME Duplicate key name [RPF 2930] - 21 BADALG Algorithm not supported [RPF 2930] - - 22 - 3,840 - 0x0016 - 0x0F00 Available for assignment - - 3,841 - 4,095 - 0x0F01 - 0x0FFF Private Use - - 4,096 - 65,534 - 0x1000 - 0xFFFE Available for assignment - - 65,535 - 0xFFFF Reserved, can only be allocated by an IETF - Standards Action. - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - Since it is important that RCODEs be understood for interoperability, - assignment of new RCODE listed above as "available for assignment" - requires an IETF Consensus. - - - -3. DNS Resource Records - - All RRs have the same top level format shown in the figure below - taken from [RFC 1035]: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | | - / / - / NAME / - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TYPE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | CLASS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TTL | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | RDLENGTH | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| - / RDATA / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - NAME is an owner name, i.e., the name of the node to which this - resource record pertains. NAMEs are specific to a CLASS as described - in section 3.2. NAMEs consist of an ordered sequence of one or more - labels each of which has a label type [RFC 1035, 2671]. - - TYPE is a two octet unsigned integer containing one of the RR TYPE - codes. See section 3.1. - - CLASS is a two octet unsigned integer containing one of the RR CLASS - codes. See section 3.2. - - TTL is a four octet (32 bit) bit unsigned integer that specifies the - number of seconds that the resource record may be cached before the - source of the information should again be consulted. Zero is - interpreted to mean that the RR can only be used for the transaction - in progress. - - RDLENGTH is an unsigned 16 bit integer that specifies the length in - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - octets of the RDATA field. - - RDATA is a variable length string of octets that constitutes the - resource. The format of this information varies according to the TYPE - and in some cases the CLASS of the resource record. - - - -3.1 RR TYPE IANA Considerations - - There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, - and MetaTYPEs. - - Data TYPEs are the primary means of storing data. QTYPES can only be - used in queries. Meta-TYPEs designate transient data associated with - an particular DNS message and in some cases can also be used in - queries. Thus far, data TYPEs have been assigned from 1 upwards plus - the block from 100 through 103 while Q and Meta Types have been - assigned from 255 downwards except for the OPT Meta-RR which is - assigned TYPE 41. There have been DNS implementations which made - caching decisions based on the top bit of the bottom byte of the RR - TYPE. - - There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG - [RFC 2845], and TKEY [RFC 2930]. - - There are currently five QTYPEs assigned: * (all), MAILA, MAILB, - AXFR, and IXFR. - - Considerations for the allocation of new RR TYPEs are as follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC - 2535] and in other circumstances and must never be allocated - for ordinary use. - - 1 - 127 - 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data - TYPEs by the DNS TYPE Allocation Policy as specified in - section 3.1.1. - - 128 - 255 - 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and - Meta TYPEs by the DNS TYPE Allocation Policy as specified in - section 3.1.1. - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - 256 - 32,767 - 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS - TYPE Allocation Policy as specified in section 3.1.1. - - 32,768 - 65,279 - 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. - - 65,280 - 65534 - 0xFF00 - 0xFFFE - Private Use. - - 65,535 - 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. - - - -3.1.1 DNS TYPE Allocation Policy - - Parameter values specified above as assigned based on DNS TYPE - Allocation Policy. That is, Expert Review with the additional - requirement that the review be based on a complete template as - specified below which has been posted for three weeks to the - namedroppers@ops.ietf.org mailing list. - - Partial or draft templates may be posted with the intend of - soliciting feedback. - - - DNS RR TYPE PARAMETER ALLOCATION TEMPLATE - - Date: - - Name and email of originator: - - Pointer to internet-draft or other document giving a detailed - description of the protocol use of the new RR Type: - - What need is the new RR TYPE intended to fix? - - What existing RR TYPE(s) come closest to filling that need and why are - they unsatisfactory? - - Does the proposed RR TYPR require special handling within the DNS - different from an Unknown RR TYPE? - - Comments: - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -3.1.2 Special Note on the OPT RR - - The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its - primary purpose is to extend the effective field size of various DNS - fields including RCODE, label type, OpCode, flag bits, and RDATA - size. In particular, for resolvers and servers that recognize it, it - extends the RCODE field from 4 to 12 bits. - - - -3.1.3 The AFSDB RR Subtype Field - - The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same - RDATA field structure as the MX RR but the 16 bit unsigned integer - field at the beginning of the RDATA is interpreted as a subtype as - follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - Allocation requires IETF Standards Action. - - 1 - 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183]. - - 2 - 0x0002 - DCE/NCA root cell directory node [RFC 1183]. - - 3 - 65,279 - 0x0003 - 0xFEFF - Allocation by IETF Consensus. - - 65,280 - 65,534 - 0xFF00 - 0xFFFE - Private Use. - - 65,535 - 0xFFFF - Reserved, allocation requires IETF Standards Action. - - - -3.2 RR CLASS IANA Considerations - - DNS CLASSes have been little used but constitute another dimension of - the DNS distributed database. In particular, there is no necessary - relationship between the name space or root servers for one CLASS and - those for another CLASS. The same name can have completely different - meanings in different CLASSes; however, the label types are the same - and the null label is usable only as root in every CLASS. However, - as global networking and DNS have evolved, the IN, or Internet, CLASS - has dominated DNS use. - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - There are two subcategories of DNS CLASSes: normal data containing - classes and QCLASSes that are only meaningful in queries or updates. - - The current CLASS assignments and considerations for future - assignments are as follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - Reserved, assignment requires an IETF Standards Action. - - 1 - 0x0001 - Internet (IN). - - 2 - 0x0002 - Available for assignment by IETF Consensus as a data CLASS. - - 3 - 0x0003 - Chaos (CH) [Moon 1981]. - - 4 - 0x0004 - Hesiod (HS) [Dyer 1987]. - - 5 - 127 - 0x0005 - 0x007F - available for assignment by IETF Consensus for data - CLASSes only. - - 128 - 253 - 0x0080 - 0x00FD - available for assignment by IETF Consensus for - QCLASSes only. - - 254 - 0x00FE - QCLASS None [RFC 2136]. - - 255 - 0x00FF - QCLASS Any [RFC 1035]. - - 256 - 32,767 - 0x0100 - 0x7FFF - Assigned by IETF Consensus. - - 32,768 - 65,279 - 0x8000 - 0xFEFF - Assigned based on Specification Required as defined - in [RFC 2434]. - - 65,280 - 65,534 - 0xFF00 - 0xFFFE - Private Use. - - 65,535 - 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -3.3 RR NAME Considerations - - DNS NAMEs are sequences of labels [RFC 1035]. The last label in each - NAME is "ROOT" which is the zero length label. By definition, the - null or ROOT label can not be used for any other NAME purpose. - - At the present time, there are two categories of label types, data - labels and compression labels. Compression labels are pointers to - data labels elsewhere within an RR or DNS message and are intended to - shorten the wire encoding of NAMEs. The two existing data label - types are sometimes referred to as Text and Binary. Text labels can, - in fact, include any octet value including zero value octets but most - current uses involve only [US-ASCII]. For retrieval, Text labels are - defined to treat ASCII upper and lower case letter codes as matching - [insensitive]. Binary labels are bit sequences [RFC 2673]. The - Binary label type is Experimental [RFC 3363]. - - IANA considerations for label types are given in [RFC 2671]. - - NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon - 1981] CLASSes are essentially for local use. The IN or Internet - CLASS is thus the only DNS CLASS in global use on the Internet at - this time. - - A somewhat out-of-date description of name allocation in the IN Class - is given in [RFC 1591]. Some information on reserved top level - domain names is in BCP 32 [RFC 2606]. - - - -4. Security Considerations - - This document addresses IANA considerations in the allocation of - general DNS parameters, not security. See [RFC 4033, 4034, 4035] for - secure DNS considerations. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 11] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -Appendix: Changes from RFC 2929 - - RFC Editor: This Appendix should be deleted for publication. - - Changes from RFC 2929 to this draft: - - 1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE - Allocation Policy" and add the specification of that policy. Change - some remaining "IETF Standards Action" allocation requirements to say - "as modified by [RFC 4020]". - - 2. Updated various RFC references. - - 3. Mentioned that the Binary label type is now Experimental and - IQuery is Obsolete. - - 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be - IETF Standards Action required. - - 5. Add an IANA allocation policy for the AFSDB RR Subtype field. - - 6. Addition of reference to case insensitive draft. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 12] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -Copyright and Disclaimer - - Copyright (C) The Internet Society (2005). This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Normative References - - [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. - Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. - - [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", RFC 1996, August 1996. - - [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System", - RFC 2673, August 1999. - - [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - -D. Eastlake 3rd [Page 13] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", September 2000. - - [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. - Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in - the Domain Name System (DNS)", RFC 3363, August 2002. - - [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November - 2002. - - [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of - Standards Track Code Points", BCP 100, RFC 4020, February 2005. - - [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC 4033, March - 2005. - - [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security Extensions", RFC - 4035, March 2005. - - [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", - X3.4, American National Standards Institute: New York, 1968. - - - -Informative References - - [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena - Technical Plan - Name Service, April 1987, - - [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts - Institute of Technology Artificial Intelligence Laboratory, June - 1981. - - [RFC 1591] - Postel, J., "Domain Name System Structure and - Delegation", RFC 1591, March 1994. - - [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, - "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, - September 2000. - - [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS - Names", RFC 2606, June 1999. - - [insensitive] - Eastlake, D., "Domain Name System (DNS) Case - - -D. Eastlake 3rd [Page 14] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - - Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt, - work in progress. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 15] - - -INTERNET-DRAFT DNS IANA Considerations August 2005 - - -Authors Addresses - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 (w) - email: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires February 2006. - - Its file name is draft-ietf-dnsext-2929bis-01.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 16] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt deleted file mode 100644 index bcc2b4ec51..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt +++ /dev/null @@ -1,442 +0,0 @@ - - -INTERNET-DRAFT Samuel Weiler -Expires: June 2004 December 15, 2003 -Updates: RFC 2535, [DS] - - Legacy Resolver Compatibility for Delegation Signer - draft-ietf-dnsext-dnssec-2535typecode-change-06.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - Comments should be sent to the author or to the DNSEXT WG mailing - list: namedroppers@ops.ietf.org - -Abstract - - As the DNS Security (DNSSEC) specifications have evolved, the - syntax and semantics of the DNSSEC resource records (RRs) have - changed. Many deployed nameservers understand variants of these - semantics. Dangerous interactions can occur when a resolver that - understands an earlier version of these semantics queries an - authoritative server that understands the new delegation signer - semantics, including at least one failure scenario that will cause - an unsecured zone to be unresolvable. This document changes the - type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to - avoid those interactions. - -Changes between 05 and 06: - - Signifigantly reworked the IANA section -- went back to one - algorithm registry. - - Removed Diffie-Hellman from the list of zone-signing algorithms - (leaving only DSA, RSA/SHA-1, and private algorithms). - - Added a DNSKEY flags field registry. - -Changes between 04 and 05: - - IESG approved publication. - - Cleaned up an internal reference in the acknowledgements section. - - Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference. - - Changed the names of both new registries. Added algorithm - mnemonics to the new zone signing algorithm registry. Minor - rewording in the IANA section for clarity. - - Cleaned up formatting of references. Replaced unknown-rr draft - references with RFC3597. Bumped DS version number. - -Changes between 03 and 04: - - Clarified that RRSIG(0) may be defined by standards action. - - Created a new algorithm registry and renamed the old algorithm - registry for SIG(0) only. Added references to the appropriate - crypto algorithm and format specifications. - - Several minor rephrasings. - -Changes between 02 and 03: - - KEY (as well as SIG) retained for SIG(0) use only. - -Changes between 01 and 02: - - SIG(0) still uses SIG, not RRSIG. Added 2931 reference. - - Domain names embedded in NSECs and RRSIGs are not compressible and - are not downcased. Added unknown-rrs reference (as informative). - - Simplified the last paragraph of section 3 (NSEC doesn't always - signal a negative answer). - - Changed the suggested type code assignments. - - Added 2119 reference. - - Added definitions of "unsecure delegation" and "unsecure referral", - since they're not clearly defined elsewhere. - - Moved 2065 to informative references, not normative. - -1. Introduction - - The DNSSEC protocol has been through many iterations whose syntax - and semantics are not completely compatible. This has occurred as - part of the ordinary process of proposing a protocol, implementing - it, testing it in the increasingly complex and diverse environment - of the Internet, and refining the definitions of the initial - Proposed Standard. In the case of DNSSEC, the process has been - complicated by DNS's criticality and wide deployment and the need - to add security while minimizing daily operational complexity. - - A weak area for previous DNS specifications has been lack of detail - in specifying resolver behavior, leaving implementors largely on - their own to determine many details of resolver function. This, - combined with the number of iterations the DNSSEC spec has been - through, has resulted in fielded code with a wide variety of - behaviors. This variety makes it difficult to predict how a - protocol change will be handled by all deployed resolvers. The - risk that a change will cause unacceptable or even catastrophic - failures makes it difficult to design and deploy a protocol change. - One strategy for managing that risk is to structure protocol - changes so that existing resolvers can completely ignore input that - might confuse them or trigger undesirable failure modes. - - This document addresses a specific problem caused by Delegation - Signer's [DS] introduction of new semantics for the NXT RR that are - incompatible with the semantics in RFC 2535 [RFC2535]. Answers - provided by DS-aware servers can trigger an unacceptable failure - mode in some resolvers that implement RFC 2535, which provides a - great disincentive to sign zones with DS. The changes defined in - this document allow for the incremental deployment of DS. - -1.1 Terminology - - In this document, the term "unsecure delegation" means any - delegation for which no DS record appears at the parent. An - "unsecure referral" is an answer from the parent containing an NS - RRset and a proof that no DS record exists for that name. - - 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]. - -1.2 The Problem - - Delegation Signer introduces new semantics for the NXT RR that are - incompatible with the semantics in RFC 2535. In RFC 2535, NXT - records were only required to be returned as part of a - non-existence proof. With DS, an unsecure referral returns, in - addition to the NS, a proof of non-existence of a DS RR in the form - of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was - to interpret a response with both an NS and an NXT in the authority - section, RCODE=0, and AA=0. Some widely deployed 2535-aware - resolvers interpret any answer with an NXT as a proof of - non-existence of the requested record. This results in unsecure - delegations being invisible to 2535-aware resolvers and violates - the basic architectural principle that DNSSEC must do no harm -- - the signing of zones must not prevent the resolution of unsecured - delegations. - -2. Possible Solutions - - This section presents several solutions that were considered. - Section 3 describes the one selected. - -2.1. Change SIG, KEY, and NXT type codes - - To avoid the problem described above, legacy (RFC2535-aware) - resolvers need to be kept from seeing unsecure referrals that - include NXT records in the authority section. The simplest way to - do that is to change the type codes for SIG, KEY, and NXT. - - The obvious drawback to this is that new resolvers will not be able - to validate zones signed with the old RRs. This problem already - exists, however, because of the changes made by DS, and resolvers - that understand the old RRs (and have compatibility issues with DS) - are far more prevalent than 2535-signed zones. - -2.2. Change a subset of type codes - - The observed problem with unsecure referrals could be addressed by - changing only the NXT type code or another subset of the type codes - that includes NXT. This has the virtue of apparent simplicity, but - it risks introducing new problems or not going far enough. It's - quite possible that more incompatibilities exist between DS and - earlier semantics. Legacy resolvers may also be confused by seeing - records they recognize (SIG and KEY) while being unable to find - NXTs. Although it may seem unnecessary to fix that which is not - obviously broken, it's far cleaner to change all of the type codes - at once. This will leave legacy resolvers and tools completely - blinded to DNSSEC -- they will see only unknown RRs. - -2.3. Replace the DO bit - - Another way to keep legacy resolvers from ever seeing DNSSEC - records with DS semantics is to have authoritative servers only - send that data to DS-aware resolvers. It's been proposed that - assigning a new EDNS0 flag bit to signal DS-awareness (tentatively - called "DA"), and having authoritative servers send DNSSEC data - only in response to queries with the DA bit set, would accomplish - this. This bit would presumably supplant the DO bit described in - RFC 3225. - - This solution is sufficient only if all 2535-aware resolvers zero - out EDNS0 flags that they don't understand. If one passed through - the DA bit unchanged, it would still see the new semantics, and it - would probably fail to see unsecure delegations. Since it's - impractical to know how every DNS implementation handles unknown - EDNS0 flags, this is not a universal solution. It could, though, - be considered in addition to changing the RR type codes. - -2.4. Increment the EDNS version - - Another possible solution is to increment the EDNS version number - as defined in RFC 2671 [RFC2671], on the assumption that all - existing implementations will reject higher versions than they - support, and retain the DO bit as the signal for DNSSEC awareness. - This approach has not been tested. - -2.5. Do nothing - - There is a large deployed base of DNS resolvers that understand - DNSSEC as defined by the standards track RFC 2535 and RFC 2065 - and, due to under specification in those documents, interpret any - answer with an NXT as a non-existence proof. So long as that is - the case, zone owners will have a strong incentive to not sign any - zones that contain unsecure delegations, lest those delegations be - invisible to such a large installed base. This will dramatically - slow DNSSEC adoption. - - Unfortunately, without signed zones there's no clear incentive for - operators of resolvers to upgrade their software to support the new - version of DNSSEC, as defined in [DS]. Historical data suggests - that resolvers are rarely upgraded, and that old nameserver code - never dies. - - Rather than wait years for resolvers to be upgraded through natural - processes before signing zones with unsecure delegations, - addressing this problem with a protocol change will immediately - remove the disincentive for signing zones and allow widespread - deployment of DNSSEC. - -3. Protocol changes - - This document changes the type codes of SIG, KEY, and NXT. This - approach is the cleanest and safest of those discussed above, - largely because the behavior of resolvers that receive unknown type - codes is well understood. This approach has also received the most - testing. - - To avoid operational confusion, it's also necessary to change the - mnemonics for these RRs. DNSKEY will be the replacement for KEY, - with the mnemonic indicating that these keys are not for - application use, per [RFC3445]. RRSIG (Resource Record SIGnature) - will replace SIG, and NSEC (Next SECure) will replace NXT. These - new types completely replace the old types, except that SIG(0) - [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY. - - The new types will have exactly the same syntax and semantics as - specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for - the following: - - 1) Consistent with [RFC3597], domain names embedded in - RRSIG and NSEC RRs MUST NOT be compressed, - - 2) Embedded domain names in RRSIG and NSEC RRs are not downcased - for purposes of DNSSEC canonical form and ordering nor for - equality comparison, and - - 3) An RRSIG with a type-covered field of zero has undefined - semantics. The meaning of such a resource record may only be - defined by IETF Standards Action. - - If a resolver receives the old types, it SHOULD treat them as - unknown RRs and SHOULD NOT assign any special meaning to them or - give them any special treatment. It MUST NOT use them for DNSSEC - validations or other DNS operational decision making. For example, - a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to - validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, - they MUST NOT receive special treatment. As an example, if a SIG - is included in a signed zone, there MUST be an RRSIG for it. - Authoritative servers may wish to give error messages when loading - zones containing SIG or NXT records (KEY records may be included - for SIG(0) or TKEY). - - As a clarification to previous documents, some positive responses, - particularly wildcard proofs and unsecure referrals, will contain - NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as - negative answers merely because they contain an NSEC. - -4. IANA Considerations - -4.1 DNS Resource Record Types - - This document updates the IANA registry for DNS Resource Record - Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and - DNSKEY RRs, respectively. - - Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and - TKEY [RFC2930] use only. - - Type 30 (NXT) should be marked as Obsolete. - -4.2 DNS Security Algorithm Numbers - - To allow zone signing (DNSSEC) and transaction security mechanisms - (SIG(0) and TKEY) to use different sets of algorithms, the existing - "DNS Security Algorithm Numbers" registry is modified to include - the applicability of each algorithm. Specifically, two new columns - are added to the registry, showing whether each algorithm may be - used for zone signing, transaction security mechanisms, or both. - Only algorithms usable for zone signing may be used in DNSKEY, - RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG - may be used in SIG and KEY RRs. - - All currently defined algorithms remain usable for transaction - security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private - algorithms (types 253 and 254) may be used for zone signing. Note - that the registry does not contain the requirement level of each - algorithm, only whether or not an algorithm may be used for the - given purposes. For example, RSA/MD5, while allowed for - transaction security mechanisms, is NOT RECOMMENDED, per RFC3110. - - Additionally, the presentation format algorithm mnemonics from - RFC2535 Section 7 are added to the registry. This document assigns - RSA/SHA-1 the mnemonic RSASHA1. - - As before, assignment of new algorithms in this registry requires - IETF Standards Action. Additionally, modification of algorithm - mnemonics or applicability requires IETF Standards Action. - Documents defining a new algorithm must address the applicability - of the algorithm and should assign a presentation mnemonic to the - algorithm. - -4.3 DNSKEY Flags - - Like the KEY resource record, DNSKEY contains a 16-bit flags field. - This document creates a new registry for the DNSKEY flags field. - - Initially, this registry only contains an assignment for bit 7 (the - ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF - Standards Action. - -4.4 DNSKEY Protocol Octet - - Like the KEY resource record, DNSKEY contains an eight bit protocol - field. The only defined value for this field is 3 (DNSSEC). No - other values are allowed, hence no IANA registry is needed for this - field. - -5. Security Considerations - - The changes introduced here do not materially affect security. - The implications of trying to use both new and legacy types - together are not well understood, and attempts to do so would - probably lead to unintended and dangerous results. - - Changing type codes will leave code paths in legacy resolvers that - are never exercised. Unexercised code paths are a frequent source - of security holes, largely because those code paths do not get - frequent scrutiny. - - Doing nothing, as described in section 2.5, will slow DNSSEC - deployment. While this does not decrease security, it also fails - to increase it. - -6. Normative references - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [DS] Gudmundsson, O., "Delegation Signer Resource Record", - draft-ietf-dnsext-delegation-signer-15.txt, work in - progress, June 2003. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s)", RFC 2931, September 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name - System (DNS)", RFC 2436, March 1999. - - [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the - Domain Name System (DNS)", RFC 2539, March 1999. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the - Domain Name System (DNS)", RFC 3110, May 2001. - -7. Informative References - - [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning, - "Domain Name System (DNS) IANA Considerations", BCP 42, - RFC 2929, September 2000. - - [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource - Record (RR) Types", RFC 3597, September 2003. - -8. Acknowledgments - - The changes introduced here and the analysis of alternatives had - many contributors. With apologies to anyone overlooked, those - include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed - Lewis, Bill Manning, and Suzanne Woolf. - - Thanks to Jakob Schlyter and Mark Andrews for identifying the - incompatibility described in section 1.2. - - In addition to the above, the author would like to thank Scott - Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive - comments. - -9. Author's Address - - Samuel Weiler - SPARTA, Inc. - 7075 Samuel Morse Drive - Columbia, MD 21046 - USA - weiler@tislabs.com - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt deleted file mode 100644 index 7503c66ab3..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt +++ /dev/null @@ -1,616 +0,0 @@ - - - -Network Working Group S. Weiler -Internet-Draft SPARTA, Inc -Updates: 4034, 4035 (if approved) J. Ihren -Expires: July 24, 2006 Autonomica AB - January 20, 2006 - - - Minimally Covering NSEC Records and DNSSEC On-line Signing - draft-ietf-dnsext-dnssec-online-signing-02 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 24, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes how to construct DNSSEC NSEC resource records - that cover a smaller range of names than called for by RFC4034. By - generating and signing these records on demand, authoritative name - servers can effectively stop the disclosure of zone contents - otherwise made possible by walking the chain of NSEC records in a - signed zone. - - - - -Weiler & Ihren Expires July 24, 2006 [Page 1] - -Internet-Draft NSEC Epsilon January 2006 - - -Changes from ietf-01 to ietf-02 - - Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG - and NSEC bits set, to be consistent with DNSSECbis -- previous text - said SHOULD. - - Made the applicability statement a little less oppressive. - -Changes from ietf-00 to ietf-01 - - Added an applicability statement, making reference to ongoing work on - NSEC3. - - Added the phrase "epsilon functions", which has been commonly used to - describe the technique and already appeared in the header of each - page, in place of "increment and decrement functions". Also added an - explanatory sentence. - - Corrected references from 4034 section 6.2 to section 6.1. - - Fixed an out-of-date reference to [-bis] and other typos. - - Replaced IANA Considerations text. - - Escaped close parentheses in examples. - - Added some more acknowledgements. - -Changes from weiler-01 to ietf-00 - - Inserted RFC numbers for 4033, 4034, and 4035. - - Specified contents of bitmap field in synthesized NSEC RR's, pointing - out that this relaxes a constraint in 4035. Added 4035 to the - Updates header. - -Changes from weiler-00 to weiler-01 - - Clarified that this updates RFC4034 by relaxing requirements on the - next name field. - - Added examples covering wildcard names. - - In the 'better functions' section, reiterated that perfect functions - aren't needed. - - Added a reference to RFC 2119. - - - - -Weiler & Ihren Expires July 24, 2006 [Page 2] - -Internet-Draft NSEC Epsilon January 2006 - - -Table of Contents - - 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 - 2. Applicability of This Technique . . . . . . . . . . . . . . . 4 - 3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5 - 4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 - Intellectual Property and Copyright Statements . . . . . . . . . . 11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 3] - -Internet-Draft NSEC Epsilon January 2006 - - -1. Introduction and Terminology - - With DNSSEC [1], an NSEC record lists the next instantiated name in - its zone, proving that no names exist in the "span" between the - NSEC's owner name and the name in the "next name" field. In this - document, an NSEC record is said to "cover" the names between its - owner name and next name. - - Through repeated queries that return NSEC records, it is possible to - retrieve all of the names in the zone, a process commonly called - "walking" the zone. Some zone owners have policies forbidding zone - transfers by arbitrary clients; this side-effect of the NSEC - architecture subverts those policies. - - This document presents a way to prevent zone walking by constructing - NSEC records that cover fewer names. These records can make zone - walking take approximately as many queries as simply asking for all - possible names in a zone, making zone walking impractical. Some of - these records must be created and signed on demand, which requires - on-line private keys. Anyone contemplating use of this technique is - strongly encouraged to review the discussion of the risks of on-line - signing in Section 6. - - 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 RFC 2119 [4]. - - -2. Applicability of This Technique - - The technique presented here may be useful to a zone owner that wants - to use DNSSEC, is concerned about exposure of its zone contents via - zone walking, and is willing to bear the costs of on-line signing. - - As discussed in Section 6, on-line signing has several security - risks, including an increased likelihood of private keys being - disclosed and an increased risk of denial of service attack. Anyone - contemplating use of this technique is strongly encouraged to review - the discussion of the risks of on-line signing in Section 6. - - Furthermore, at the time this document was published, the DNSEXT - working group was actively working on a mechanism to prevent zone - walking that does not require on-line signing (tentatively called - NSEC3). The new mechanism is likely to expose slightly more - information about the zone than this technique (e.g. the number of - instantiated names), but it may be preferable to this technique. - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 4] - -Internet-Draft NSEC Epsilon January 2006 - - -3. Minimally Covering NSEC Records - - This mechanism involves changes to NSEC records for instantiated - names, which can still be generated and signed in advance, as well as - the on-demand generation and signing of new NSEC records whenever a - name must be proven not to exist. - - In the 'next name' field of instantiated names' NSEC records, rather - than list the next instantiated name in the zone, list any name that - falls lexically after the NSEC's owner name and before the next - instantiated name in the zone, according to the ordering function in - RFC4034 [2] section 6.1. This relaxes the requirement in section - 4.1.1 of RFC4034 that the 'next name' field contains the next owner - name in the zone. This change is expected to be fully compatible - with all existing DNSSEC validators. These NSEC records are returned - whenever proving something specifically about the owner name (e.g. - that no resource records of a given type appear at that name). - - Whenever an NSEC record is needed to prove the non-existence of a - name, a new NSEC record is dynamically produced and signed. The new - NSEC record has an owner name lexically before the QNAME but - lexically following any existing name and a 'next name' lexically - following the QNAME but before any existing name. - - The generated NSEC record's type bitmap MUST have the RRSIG and NSEC - bits set and SHOULD NOT have any other bits set. This relaxes the - requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at - names that did not exist before the zone was signed. - - The functions to generate the lexically following and proceeding - names need not be perfect nor consistent, but the generated NSEC - records must not cover any existing names. Furthermore, this - technique works best when the generated NSEC records cover as few - names as possible. In this document, the functions that generate the - nearby names are called 'epsilon' functions, a reference to the - mathematical convention of using the greek letter epsilon to - represent small deviations. - - An NSEC record denying the existence of a wildcard may be generated - in the same way. Since the NSEC record covering a non-existent - wildcard is likely to be used in response to many queries, - authoritative name servers using the techniques described here may - want to pregenerate or cache that record and its corresponding RRSIG. - - For example, a query for an A record at the non-instantiated name - example.com might produce the following two NSEC records, the first - denying the existence of the name example.com and the second denying - the existence of a wildcard: - - - -Weiler & Ihren Expires July 24, 2006 [Page 5] - -Internet-Draft NSEC Epsilon January 2006 - - - exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) - - \).com 3600 IN NSEC +.com ( RRSIG NSEC ) - - Before answering a query with these records, an authoritative server - must test for the existence of names between these endpoints. If the - generated NSEC would cover existing names (e.g. exampldd.com or - *bizarre.example.com), a better epsilon function may be used or the - covered name closest to the QNAME could be used as the NSEC owner - name or next name, as appropriate. If an existing name is used as - the NSEC owner name, that name's real NSEC record MUST be returned. - Using the same example, assuming an exampldd.com delegation exists, - this record might be returned from the parent: - - exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) - - Like every authoritative record in the zone, each generated NSEC - record MUST have corresponding RRSIGs generated using each algorithm - (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as - described in RFC4035 [3] section 2.2. To minimize the number of - signatures that must be generated, a zone may wish to limit the - number of algorithms in its DNSKEY RRset. - - -4. Better Epsilon Functions - - Section 6.1 of RFC4034 defines a strict ordering of DNS names. - Working backwards from that definition, it should be possible to - define epsilon functions that generate the immediately following and - preceding names, respectively. This document does not define such - functions. Instead, this section presents functions that come - reasonably close to the perfect ones. As described above, an - authoritative server should still ensure than no generated NSEC - covers any existing name. - - To increment a name, add a leading label with a single null (zero- - value) octet. - - To decrement a name, decrement the last character of the leftmost - label, then fill that label to a length of 63 octets with octets of - value 255. To decrement a null (zero-value) octet, remove the octet - -- if an empty label is left, remove the label. Defining this - function numerically: fill the left-most label to its maximum length - with zeros (numeric, not ASCII zeros) and subtract one. - - In response to a query for the non-existent name foo.example.com, - these functions produce NSEC records of: - - - - -Weiler & Ihren Expires July 24, 2006 [Page 6] - -Internet-Draft NSEC Epsilon January 2006 - - - fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) - - \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) - - The first of these NSEC RRs proves that no exact match for - foo.example.com exists, and the second proves that there is no - wildcard in example.com. - - Both of these functions are imperfect: they don't take into account - constraints on number of labels in a name nor total length of a name. - As noted in the previous section, though, this technique does not - depend on the use of perfect epsilon functions: it is sufficient to - test whether any instantiated names fall into the span covered by the - generated NSEC and, if so, substitute those instantiated owner names - for the NSEC owner name or next name, as appropriate. - - -5. IANA Considerations - - This document specifies no IANA Actions. - - -6. Security Considerations - - This approach requires on-demand generation of RRSIG records. This - creates several new vulnerabilities. - - First, on-demand signing requires that a zone's authoritative servers - have access to its private keys. Storing private keys on well-known - internet-accessible servers may make them more vulnerable to - unintended disclosure. - - Second, since generation of digital signatures tends to be - computationally demanding, the requirement for on-demand signing - makes authoritative servers vulnerable to a denial of service attack. - - Lastly, if the epsilon functions are predictable, on-demand signing - may enable a chosen-plaintext attack on a zone's private keys. Zones - using this approach should attempt to use cryptographic algorithms - that are resistant to chosen-plaintext attacks. It's worth noting - - - -Weiler & Ihren Expires July 24, 2006 [Page 7] - -Internet-Draft NSEC Epsilon January 2006 - - - that while DNSSEC has a "mandatory to implement" algorithm, that is a - requirement on resolvers and validators -- there is no requirement - that a zone be signed with any given algorithm. - - The success of using minimally covering NSEC record to prevent zone - walking depends greatly on the quality of the epsilon functions - chosen. An increment function that chooses a name obviously derived - from the next instantiated name may be easily reverse engineered, - destroying the value of this technique. An increment function that - always returns a name close to the next instantiated name is likewise - a poor choice. Good choices of epsilon functions are the ones that - produce the immediately following and preceding names, respectively, - though zone administrators may wish to use less perfect functions - that return more human-friendly names than the functions described in - Section 4 above. - - Another obvious but misguided concern is the danger from synthesized - NSEC records being replayed. It's possible for an attacker to replay - an old but still validly signed NSEC record after a new name has been - added in the span covered by that NSEC, incorrectly proving that - there is no record at that name. This danger exists with DNSSEC as - defined in [3]. The techniques described here actually decrease the - danger, since the span covered by any NSEC record is smaller than - before. Choosing better epsilon functions will further reduce this - danger. - -7. Normative References - - [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - - [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - -Appendix A. Acknowledgments - - Many individuals contributed to this design. They include, in - addition to the authors of this document, Olaf Kolkman, Ed Lewis, - - - -Weiler & Ihren Expires July 24, 2006 [Page 8] - -Internet-Draft NSEC Epsilon January 2006 - - - Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, - Jakob Schlyter, Bill Manning, and Joao Damas. - - In addition, the editors would like to thank Ed Lewis, Scott Rose, - and David Blacka for their careful review of the document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 9] - -Internet-Draft NSEC Epsilon January 2006 - - -Authors' Addresses - - Samuel Weiler - SPARTA, Inc - 7075 Samuel Morse Drive - Columbia, Maryland 21046 - US - - Email: weiler@tislabs.com - - - Johan Ihren - Autonomica AB - Bellmansgatan 30 - Stockholm SE-118 47 - Sweden - - Email: johani@autonomica.se - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 10] - -Internet-Draft NSEC Epsilon January 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Weiler & Ihren Expires July 24, 2006 [Page 11] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt deleted file mode 100644 index dd8cbf0682..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt +++ /dev/null @@ -1,839 +0,0 @@ - -DNS Extensions Working Group R. Arends -Internet-Draft Telematica Instituut -Expires: August 25, 2005 P. Koch - DENIC eG - J. Schlyter - NIC-SE - February 21, 2005 - - - Evaluating DNSSEC Transition Mechanisms - draft-ietf-dnsext-dnssec-trans-02.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 25, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document collects and summarizes different proposals for - alternative and additional strategies for authenticated denial in DNS - responses, evaluates these proposals and gives a recommendation for a - - - -Arends, et al. Expires August 25, 2005 [Page 1] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - way forward. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 - 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 - 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 - 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5 - 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 - 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6 - 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 - 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 - 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 - 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9 - 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 - 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10 - 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11 - 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11 - 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 - 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 25, 2005 [Page 2] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -1. Introduction - - This report shall document the process of dealing with the NSEC - walking problem late in the Last Call for - [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol, - I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion - that took place in the DNSEXT WG during the first half of June 2004 - as well as some additional ideas that came up subsequently. - - This is an edited excerpt of the chairs' mail to the WG: - The working group consents on not including NSEC-alt in the - DNSSEC-bis documents. The working group considers to take up - "prevention of zone enumeration" as a work item. - There may be multiple mechanisms to allow for co-existence with - DNSSEC-bis. The chairs allow the working group a little over a - week (up to June 12, 2004) to come to consensus on a possible - modification to the document to enable gentle rollover. If that - consensus cannot be reached the DNSSEC-bis documents will go out - as-is. - - To ease the process of getting consensus, a summary of the proposed - solutions and analysis of the pros and cons were written during the - weekend. - - This summary includes: - - An inventory of the proposed mechanisms to make a transition to - future work on authenticated denial of existence. - List the known Pros and Cons, possibly provide new arguments, and - possible security considerations of these mechanisms. - Provide a recommendation on a way forward that is least disruptive - to the DNSSEC-bis specifications as they stand and keep an open - path to other methods for authenticated denial of existence. - - The descriptions of the proposals in this document are coarse and do - not cover every detail necessary for implementation. In any case, - documentation and further study is needed before implementaion and/or - deployment, including those which seem to be solely operational in - nature. - -2. Transition Mechanisms - - In the light of recent discussions and past proposals, we have found - several ways to allow for transition to future expansion of - authenticated denial. We tried to illuminate the paths and pitfalls - in these ways forward. Some proposals lead to a versioning of - DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other - proposals are 'clean' but may cause delay, while again others may be - - - -Arends, et al. Expires August 25, 2005 [Page 3] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - plain hacks. - - Some paths do not introduce versioning, and might require the current - DNSSEC-bis documents to be fully updated to allow for extensions to - authenticated denial mechanisms. Other paths introduce versioning - and do not (or minimally) require DNSSEC-bis documents to be updated, - allowing DNSSEC-bis to be deployed, while future versions can be - drafted independent from or partially depending on DNSSEC-bis. - -2.1 Mechanisms With Need of Updating DNSSEC-bis - - Mechanisms in this category demand updates to the DNSSEC-bis document - set. - -2.1.1 Dynamic NSEC Synthesis - - This proposal assumes that NSEC RRs and the authenticating RRSIG will - be generated dynamically to just cover the (non existent) query name. - The owner name is (the) one preceding the name queried for, the Next - Owner Name Field has the value of the Query Name Field + 1 (first - successor in canonical ordering). A separate key (the normal ZSK or - a separate ZSK per authoritative server) would be used for RRSIGs on - NSEC RRs. This is a defense against enumeration, though it has the - presumption of online signing. - -2.1.1.1 Coexistence and Migration - - There is no change in interpretation other then that the next owner - name might or might not exist. - -2.1.1.2 Limitations - - This introduces an unbalanced cost between query and response - generation due to dynamic generation of signatures. - -2.1.1.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents might need to be updated to indicate - that the next owner name might not be an existing name in the zone. - This is not a real change to the spec since implementers have been - warned not to synthesize with previously cached NSEC records. A - specific bit to identify the dynamic signature generating key might - be useful as well, to prevent it from being used to fake positive - data. - -2.1.1.4 Cons - - Unbalanced cost is a ground for DDoS. Though this protects against - - - -Arends, et al. Expires August 25, 2005 [Page 4] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - enumeration, it is not really a path for versioning. - -2.1.1.5 Pros - - Hardly any amendments to DNSSEC-bis. - -2.1.2 Add Versioning/Subtyping to Current NSEC - - This proposal introduces versioning for the NSEC RR type (a.k.a. - subtyping) by adding a (one octet) version field to the NSEC RDATA. - Version number 0 is assigned to the current (DNSSEC-bis) meaning, - making this an 'Must Be Zero' (MBZ) for the to be published docset. - -2.1.2.1 Coexistence and Migration - - Since the versioning is done inside the NSEC RR, different versions - may coexist. However, depending on future methods, that may or may - not be useful inside a single zone. Resolvers cannot ask for - specific NSEC versions but may be able to indicate version support by - means of a to be defined EDNS option bit. - -2.1.2.2 Limitations - - There are no technical limitations, though it will cause delay to - allow testing of the (currently unknown) new NSEC interpretation. - - Since the versioning and signaling is done inside the NSEC RR, future - methods will likely be restricted to a single RR type authenticated - denial (as opposed to e.g. NSEC-alt, which currently proposes three - RR types). - -2.1.2.3 Amendments to DNSSEC-bis - - Full Update of the current DNSSEC-bis documents to provide for new - fields in NSEC, while specifying behavior in case of unknown field - values. - -2.1.2.4 Cons - - Though this is a clean and clear path without versioning DNSSEC, it - takes some time to design, gain consensus, update the current - dnssec-bis document, test and implement a new authenticated denial - record. - -2.1.2.5 Pros - - Does not introduce an iteration to DNSSEC while providing a clear and - clean migration strategy. - - - -Arends, et al. Expires August 25, 2005 [Page 5] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.1.3 Type Bit Map NSEC Indicator - - Bits in the type-bit-map are reused or allocated to signify the - interpretation of NSEC. - - This proposal assumes that future extensions make use of the existing - NSEC RDATA syntax, while it may need to change the interpretation of - the RDATA or introduce an alternative denial mechanism, invoked by - the specific type-bit-map-bits. - -2.1.3.1 Coexistence and migration - - Old and new NSEC meaning could coexist, depending how the signaling - would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR - types are available as well as those covering meta/query types or - types to be specifically allocated. - -2.1.3.2 Limitations - - This mechanism uses an NSEC field that was not designed for that - purpose. Similar methods were discussed during the Opt-In discussion - and the Silly-State discussion. - -2.1.3.3 Amendments to DNSSEC-bis - - The specific type-bit-map-bits must be allocated and they need to be - specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) - interpretation. Also, behaviour of the resolver and validator must - be documented in case unknown values are encountered for the MBZ - field. Currently the protocol document specifies that the validator - MUST ignore the setting of the NSEC and the RRSIG bits, while other - bits are only used for the specific purpose of the type-bit-map field - -2.1.3.4 Cons - - The type-bit-map was not designed for this purpose. It is a - straightforward hack. Text in protocol section 5.4 was put in - specially to defend against this usage. - -2.1.3.5 Pros - - No change needed to the on-the-wire protocol as specified in the - current docset. - -2.1.4 New Apex Type - - This introduces a new Apex type (parallel to the zone's SOA) - indicating the DNSSEC version (or authenticated denial) used in or - - - -Arends, et al. Expires August 25, 2005 [Page 6] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - for this zone. - -2.1.4.1 Coexistence and Migration - - Depending on the design of this new RR type multiple denial - mechanisms may coexist in a zone. Old validators will not understand - and thus ignore the new type, so interpretation of the new NSEC - scheme may fail, negative responses may appear 'bogus'. - -2.1.4.2 Limitations - - A record of this kind is likely to carry additional - feature/versioning indications unrelated to the current question of - authenticated denial. - -2.1.4.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents need to be updated to indicate that - the absence of this type indicates dnssec-bis, and that the (mere) - presence of this type indicated unknown versions. - -2.1.4.4 Cons - - The only other 'zone' or 'apex' record is the SOA record. Though - this proposal is not new, it is yet unknown how it might fulfill - authenticated denial extensions. This new RR type would only provide - for a generalized signaling mechanism, not the new authenticated - denial scheme. Since it is likely to be general in nature, due to - this generality consensus is not to be reached soon. - -2.1.4.5 Pros - - This approach would allow for a lot of other per zone information to - be transported or signaled to both (slave) servers and resolvers. - -2.1.5 NSEC White Lies - - This proposal disables one part of NSEC (the pointer part) by means - of a special target (root, apex, owner, ...), leaving intact only the - ability to authenticate denial of existence of RR sets, not denial of - existence of domain names (NXDOMAIN). It may be necessary to have - one working NSEC to prove the absence of a wildcard. - -2.1.5.1 Coexistence and Migration - - The NSEC target can be specified per RR, so standard NSEC and 'white - lie' NSEC can coexist in a zone. There is no need for migration - because no versioning is introduced or intended. - - - -Arends, et al. Expires August 25, 2005 [Page 7] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.1.5.2 Limitations - - This proposal breaks the protocol and is applicable to certain types - of zones only (no wildcard, no deep names, delegation only). Most of - the burden is put on the resolver side and operational consequences - are yet to be studied. - -2.1.5.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents need to be updated to indicate that - the NXDOMAIN responses may be insecure. - -2.1.5.4 Cons - - Strictly speaking this breaks the protocol and doesn't fully fulfill - the requirements for authenticated denial of existence. Security - implications need to be carefully documented: search path problems - (forged denial of existence may lead to wrong expansion of non-FQDNs - [RFC1535]) and replay attacks to deny existence of records. - -2.1.5.5 Pros - - Hardly any amendments to DNSSEC-bis. Operational "trick" that is - available anyway. - -2.1.6 NSEC Optional via DNSSKEY Flag - - A new DNSKEY may be defined to declare NSEC optional per zone. - -2.1.6.1 Coexistence and Migration - - Current resolvers/validators will not understand the Flag bit and - will have to treat negative responses as bogus. Otherwise, no - migration path is needed since NSEC is simply turned off. - -2.1.6.2 Limitations - - NSEC can only be made completely optional at the cost of being unable - to prove unsecure delegations (absence of a DS RR [RFC3658]). A next - to this approach would just disable authenticated denial for - non-existence of nodes. - -2.1.6.3 Amendments to DNSSEC-bis - - New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to - be specified in the light of absence of authenticated denial. - - - - - -Arends, et al. Expires August 25, 2005 [Page 8] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.1.6.4 Cons - - Doesn't fully meet requirements. Operational consequences to be - studied. - -2.1.6.5 Pros - - Official version of the "trick" presented in (8). Operational - problems can be addressed during future work on validators. - -2.1.7 New Answer Pseudo RR Type - - A new pseudo RR type may be defined that will be dynamically created - (and signed) by the responding authoritative server. The RR in the - response will cover the QNAME, QCLASS and QTYPE and will authenticate - both denial of existence of name (NXDOMAIN) or RRset. - -2.1.7.1 Coexistence and Migration - - Current resolvers/validators will not understand the pseudo RR and - will thus not be able to process negative responses so testified. A - signaling or solicitation method would have to be specified. - -2.1.7.2 Limitations - - This method can only be used with online keys and online signing - capacity. - -2.1.7.3 Amendments to DNSSEC-bis - - Signaling method needs to be defined. - -2.1.7.4 Cons - - Keys have to be held and processed online with all security - implications. An additional flag for those keys identifying them as - online or negative answer only keys should be considered. - -2.1.7.5 Pros - - Expands DNSSEC authentication to the RCODE. - -2.1.8 SIG(0) Based Authenticated Denial - - -2.1.8.1 Coexistence and Migration - - - - - -Arends, et al. Expires August 25, 2005 [Page 9] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.1.8.2 Limitations - - -2.1.8.3 Amendments to DNSSEC-bis - - -2.1.8.4 Cons - - -2.1.8.5 Pros - - -2.2 Mechanisms Without Need of Updating DNSSEC-bis - -2.2.1 Partial Type-code and Signal Rollover - - Carefully crafted type code/signal rollover to define a new - authenticated denial space that extends/replaces DNSSEC-bis - authenticated denial space. This particular path is illuminated by - Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> - posted to 2004-06-02. - -2.2.1.1 Coexistence and Migration - - To protect the current resolver for future versions, a new DNSSEC-OK - bit must be allocated to make clear it does or does not understand - the future version. Also, a new DS type needs to be allocated to - allow differentiation between a current signed delegation and a - 'future' signed delegation. Also, current NSEC needs to be rolled - into a new authenticated denial type. - -2.2.1.2 Limitations - - None. - -2.2.1.3 Amendments to DNSSEC-bis - - None. - -2.2.1.4 Cons - - It is cumbersome to carefully craft an TCR that 'just fits'. The - DNSSEC-bis protocol has many 'borderline' cases that needs special - consideration. It might be easier to do a full TCR, since a few of - the types and signals need upgrading anyway. - - - - - - -Arends, et al. Expires August 25, 2005 [Page 10] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -2.2.1.5 Pros - - Graceful adoption of future versions of NSEC, while there are no - amendments to DNSSEC-bis. - -2.2.2 A Complete Type-code and Signal Rollover - - A new DNSSEC space is defined which can exist independent of current - DNSSEC-bis space. - - This proposal assumes that all current DNSSEC type-codes - (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any - future versions of DNSSEC. Any future version of DNSSEC has its own - types to allow for keys, signatures, authenticated denial, etcetera. - -2.2.2.1 Coexistence and Migration - - Both spaces can co-exist. They can be made completely orthogonal. - -2.2.2.2 Limitations - - None. - -2.2.2.3 Amendments to DNSSEC-bis - - None. - -2.2.2.4 Cons - - With this path we abandon the current DNSSEC-bis. Though it is easy - to role specific well-known and well-tested parts into the re-write, - once deployment has started this path is very expensive for - implementers, registries, registrars and registrants as well as - resolvers/users. A TCR is not to be expected to occur frequently, so - while a next generation authenticated denial may be enabled by a TCR, - it is likely that that TCR will only be agreed upon if it serves a - whole basket of changes or additions. A quick introduction of - NSEC-ng should not be expected from this path. - -2.2.2.5 Pros - - No amendments/changes to current DNSSEC-bis docset needed. It is - always there as last resort. - -2.2.3 Unknown Algorithm in RRSIG - - This proposal assumes that future extensions make use of the existing - NSEC RDATA syntax, while it may need to change the interpretation of - - - -Arends, et al. Expires August 25, 2005 [Page 11] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - the RDATA or introduce an alternative denial mechanism, invoked by - the specific unknown signing algorithm. The different interpretation - would be signaled by use of different signature algorithms in the - RRSIG records covering the NSEC RRs. - - When an entire zone is signed with a single unknown algorithm, it - will cause implementations that follow current dnssec-bis documents - to treat individual RRsets as unsigned. - -2.2.3.1 Coexistence and migration - - Old and new NSEC RDATA interpretation or known and unknown Signatures - can NOT coexist in a zone since signatures cover complete (NSEC) - RRSets. - -2.2.3.2 Limitations - - Validating resolvers agnostic of new interpretation will treat the - NSEC RRset as "not signed". This affects wildcard and non-existence - proof, as well as proof for (un)secured delegations. Also, all - positive signatures (RRSIGs on RRSets other than DS, NSEC) appear - insecure/bogus to an old validator. - - The algorithm version space is split for each future version of - DNSSEC. Violation of the 'modular components' concept. We use the - 'validator' to protect the 'resolver' from unknown interpretations. - -2.2.3.3 Amendments to DNSSEC-bis - - None. - -2.2.3.4 Cons - - The algorithm field was not designed for this purpose. This is a - straightforward hack. - -2.2.3.5 Pros - - No amendments/changes to current DNSSEC-bis docset needed. - -3. Recommendation - - The authors recommend that the working group commits to and starts - work on a partial TCR, allowing graceful transition towards a future - version of NSEC. Meanwhile, to accomodate the need for an - immediately, temporary, solution against zone-traversal, we recommend - On-Demand NSEC synthesis. - - - - -Arends, et al. Expires August 25, 2005 [Page 12] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - This approach does not require any mandatory changes to DNSSEC-bis, - does not violate the protocol and fulfills the requirements. As a - side effect, it moves the cost of implementation and deployment to - the users (zone owners) of this mechanism. - -4. Acknowledgements - - The authors would like to thank Sam Weiler and Mark Andrews for their - input and constructive comments. - -5. References - -5.1 Normative References - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Massey, D., Larson, M. and S. - Rose, "DNS Security Introduction and Requirements", - Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October - 2004. - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., "Protocol Modifications for the DNS Security - Extensions", - Internet-Draft draft-ietf-dnsext-dnssec-protocol-09, - October 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., "Resource Records for the DNS Security - Extensions", - Internet-Draft draft-ietf-dnsext-dnssec-records-11, - October 2004. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - -5.2 Informative References - - [RFC1535] Gavron, E., "A Security Problem and Proposed Correction - With Widely Deployed DNS Software", RFC 1535, October - 1993. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - - - -Arends, et al. Expires August 25, 2005 [Page 13] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - - RFC 2535, March 1999. - - [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, - June 1999. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Brouwerijstraat 1 - Enschede 7523 XC - The Netherlands - - Phone: +31 53 4850485 - Email: roy.arends@telin.nl - - - Peter Koch - DENIC eG - Wiesenh"uttenplatz 26 - Frankfurt 60329 - Germany - - Phone: +49 69 27235 0 - Email: pk@DENIC.DE - - - Jakob Schlyter - NIC-SE - Box 5774 - Stockholm SE-114 87 - Sweden - - Email: jakob@nic.se - URI: http://www.nic.se/ - - - - - - - - - - - - -Arends, et al. Expires August 25, 2005 [Page 14] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Arends, et al. Expires August 25, 2005 [Page 15] - - diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt deleted file mode 100644 index 2460cb619b..0000000000 --- a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt +++ /dev/null @@ -1,504 +0,0 @@ - - - -Network Working Group W. Hardaker -Internet-Draft Sparta -Expires: August 25, 2006 February 21, 2006 - - - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) - draft-ietf-dnsext-ds-sha256-05.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 25, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document specifies how to use the SHA-256 digest type in DNS - Delegation Signer (DS) Resource Records (RRs). DS records, when - stored in a parent zone, point to key signing DNSKEY key(s) in a - child zone. - - - - - - - - -Hardaker Expires August 25, 2006 [Page 1] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Implementing the SHA-256 algorithm for DS record support . . . 3 - 2.1. DS record field values . . . . . . . . . . . . . . . . . . 3 - 2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3 - 2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4 - 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4 - 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 - 6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5 - 6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 - Intellectual Property and Copyright Statements . . . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 25, 2006 [Page 2] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -1. Introduction - - The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent - zones to distribute a cryptographic digest of a child's Key Signing - Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the - parent zone's private zone data signing keys for each algorithm in - use by the parent. Each signature is published in an RRSIG resource - record, owned by the same domain as the DS RRset and with a type - covered of DS. - - 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]. - - -2. Implementing the SHA-256 algorithm for DS record support - - This document specifies that the digest type code [XXX: To be - assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] - [SHA256CODE] for use within DS records. The results of the digest - algorithm MUST NOT be truncated and the entire 32 byte digest result - is to be published in the DS record. - -2.1. DS record field values - - Using the SHA-256 digest algorithm within a DS record will make use - of the following DS-record fields: - - Digest type: [XXX: To be assigned by IANA; likely 2] - - Digest: A SHA-256 bit digest value calculated by using the following - formula ("|" denotes concatenation). The resulting value is not - truncated and the entire 32 byte result is to used in the - resulting DS record and related calculations. - - digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) - - where DNSKEY RDATA is defined by [RFC4034] as: - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key - - The Key Tag field and Algorithm fields remain unchanged by this - document and are specified in the [RFC4034] specification. - -2.2. DS Record with SHA-256 Wire Format - - The resulting on-the-wire format for the resulting DS record will be - [XXX: IANA assignment should replace the 2 below]: - - - -Hardaker Expires August 25, 2006 [Page 3] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | DigestType=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest (length for SHA-256 is 32 bytes) / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - -2.3. Example DS Record Using SHA-256 - - The following is an example DNSKEY and matching DS record. This - DNSKEY record comes from the example DNSKEY/DS records found in - section 5.4 of [RFC4034]. - - The DNSKEY record: - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - The resulting DS record covering the above DNSKEY record using a SHA- - 256 digest: [RFC Editor: please replace XXX with the assigned digest - type (likely 2):] - - dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C - CEB1E3E0614B93C4F9E99B83 - 83F6A1E4469DA50A ) - - -3. Implementation Requirements - - Implementations MUST support the use of the SHA-256 algorithm in DS - RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 - digests if DS RRs with SHA-256 digests are present in the DS RRset. - - -4. Deployment Considerations - - If a validator does not support the SHA-256 digest type and no other - DS RR exists in a zone's DS RRset with a supported digest type, then - - - -Hardaker Expires August 25, 2006 [Page 4] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - - the validator has no supported authentication path leading from the - parent to the child. The resolver should treat this case as it would - the case of an authenticated NSEC RRset proving that no DS RRset - exists, as described in [RFC4035], section 5.2. - - Because zone administrators can not control the deployment speed of - support for SHA-256 in validators that may be referencing any of - their zones, zone operators should consider deploying both SHA-1 and - SHA-256 based DS records. This should be done for every DNSKEY for - which DS records are being generated. Whether to make use of both - digest types and for how long is a policy decision that extends - beyond the scope of this document. - - -5. IANA Considerations - - Only one IANA action is required by this document: - - The Digest Type to be used for supporting SHA-256 within DS records - needs to be assigned by IANA. This document requests that the Digest - Type value of 2 be assigned to the SHA-256 digest algorithm. - - At the time of this writing, the current digest types assigned for - use in DS records are as follows: - - VALUE Digest Type Status - 0 Reserved - - 1 SHA-1 MANDATORY - 2 SHA-256 MANDATORY - 3-255 Unassigned - - - -6. Security Considerations - -6.1. Potential Digest Type Downgrade Attacks - - A downgrade attack from a stronger digest type to a weaker one is - possible if all of the following are true: - - o A zone includes multiple DS records for a given child's DNSKEY, - each of which use a different digest type. - - o A validator accepts a weaker digest even if a stronger one is - present but invalid. - - For example, if the following conditions are all true: - - - - - -Hardaker Expires August 25, 2006 [Page 5] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - - o Both SHA-1 and SHA-256 based digests are published in DS records - within a parent zone for a given child zone's DNSKEY. - - o The DS record with the SHA-1 digest matches the digest computed - using the child zone's DNSKEY. - - o The DS record with the SHA-256 digest fails to match the digest - computed using the child zone's DNSKEY. - - Then if the validator accepts the above situation as secure then this - can be used as a downgrade attack since the stronger SHA-256 digest - is ignored. - -6.2. SHA-1 vs SHA-256 Considerations for DS Records - - Users of DNSSEC are encouraged to deploy SHA-256 as soon as software - implementations allow for it. SHA-256 is widely believed to be more - resilient to attack than SHA-1, and confidence in SHA-1's strength is - being eroded by recently-announced attacks. Regardless of whether or - not the attacks on SHA-1 will affect DNSSEC, it is believed (at the - time of this writing) that SHA-256 is the better choice for use in DS - records. - - At the time of this publication, the SHA-256 digest algorithm is - considered sufficiently strong for the immediate future. It is also - considered sufficient for use in DNSSEC DS RRs for the immediate - future. However, future published attacks may weaken the usability - of this algorithm within the DS RRs. It is beyond the scope of this - document to speculate extensively on the cryptographic strength of - the SHA-256 digest algorithm. - - Likewise, it is also beyond the scope of this document to specify - whether or for how long SHA-1 based DS records should be - simultaneously published alongside SHA-256 based DS records. - - -7. Acknowledgments - - This document is a minor extension to the existing DNSSEC documents - and those authors are gratefully appreciated for the hard work that - went into the base documents. - - The following people contributed to portions of this document in some - fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, - Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam - Weiler. - - - - - -Hardaker Expires August 25, 2006 [Page 6] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [SHA256] National Institute of Standards and Technology, "Secure - Hash Algorithm. NIST FIPS 180-2", August 2002. - -8.2. Informative References - - [SHA256CODE] - Eastlake, D., "US Secure Hash Algorithms (SHA)", - June 2005. - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 25, 2006 [Page 7] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -Author's Address - - Wes Hardaker - Sparta - P.O. Box 382 - Davis, CA 95617 - US - - Email: hardaker@tislabs.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 25, 2006 [Page 8] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Hardaker Expires August 25, 2006 [Page 9] - diff --git a/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt b/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt deleted file mode 100644 index 87bce00b5c..0000000000 --- a/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt +++ /dev/null @@ -1,17 +0,0 @@ - -This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted -from the Internet-Drafts directory. An Internet-Draft expires 185 days from -the date that it is posted unless it is replaced by an updated version, or the -Secretariat has been notified that the document is under official review by the -IESG or has been passed to the RFC Editor for review and/or publication as an -RFC. This Internet-Draft was not published as an RFC. - -Internet-Drafts are not archival documents, and copies of Internet-Drafts that have -been deleted from the directory are not available. The Secretariat does not have -any information regarding the future plans of the author(s) or working group, if -applicable, with respect to this deleted Internet-Draft. For more information, or -to request a copy of the document, please contact the author(s) directly. - -Draft Author(s): -Remco van Mook , -Bert Hubert diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt deleted file mode 100644 index 6bffb70423..0000000000 --- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt +++ /dev/null @@ -1,560 +0,0 @@ - -DNS Extensions O. Kolkman -Internet-Draft RIPE NCC -Expires: June 17, 2004 J. Schlyter - - E. Lewis - ARIN - December 18, 2003 - - - DNSKEY RR Secure Entry Point Flag - draft-ietf-dnsext-keyrr-key-signing-flag-12 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on June 17, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - With the Delegation Signer (DS) resource record the concept of a - public key acting as a secure entry point has been introduced. During - exchanges of public keys with the parent there is a need to - differentiate secure entry point keys from other public keys in the - DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is - defined to indicate that DNSKEY is to be used as a secure entry - point. The flag bit is intended to assist in operational procedures - to correctly generate DS resource records, or to indicate what - DNSKEYs are intended for static configuration. The flag bit is not to - - - -Kolkman, et al. Expires June 17, 2004 [Page 1] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - be used in the DNS verification protocol. This document updates RFC - 2535 and RFC 3445. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4 - 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 - 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - 7. Internationalization Considerations . . . . . . . . . . . . . . 6 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 - Normative References . . . . . . . . . . . . . . . . . . . . . . 7 - Informative References . . . . . . . . . . . . . . . . . . . . . 7 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 - Intellectual Property and Copyright Statements . . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman, et al. Expires June 17, 2004 [Page 2] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - -1. Introduction - - "All keys are equal but some keys are more equal than others" [6] - - With the definition of the Delegation Signer Resource Record (DS RR) - [5] it has become important to differentiate between the keys in the - DNSKEY RR set that are (to be) pointed to by parental DS RRs and the - other keys in the DNSKEY RR set. We refer to these public keys as - Secure Entry Point (SEP) keys. A SEP key either used to generate a - DS RR or is distributed to resolvers that use the key as the root of - a trusted subtree[3]. - - In early deployment tests, the use of two (kinds of) key pairs for - each zone has been prevalent. For one kind of key pair the private - key is used to sign just the zone's DNSKEY resource record (RR) set. - Its public key is intended to be referenced by a DS RR at the parent - or configured statically in a resolver. The private key of the other - kind of key pair is used to sign the rest of the zone's data sets. - The former key pair is called a key-signing key (KSK) and the latter - is called a zone-signing key (ZSK). In practice there have been - usually one of each kind of key pair, but there will be multiples of - each at times. - - It should be noted that division of keys pairs into KSK's and ZSK's - is not mandatory in any definition of DNSSEC, not even with the - introduction of the DS RR. But, in testing, this distinction has - been helpful when designing key roll over (key super-cession) - schemes. Given that the distinction has proven helpful, the labels - KSK and ZSK have begun to stick. - - There is a need to differentiate the public keys for the key pairs - that are used for key signing from keys that are not used key signing - (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to - be sent for generating DS RRs, which DNSKEYs are to be distributed to - resolvers, and which keys are fed to the signer application at the - appropriate time. - - In other words, the SEP bit provides an in-band method to communicate - a DNSKEY RR's intended use to third parties. As an example we present - 3 use cases in which the bit is useful: - - The parent is a registry, the parent and the child use secured DNS - queries and responses, with a preexisting trust-relation, or plain - DNS over a secured channel to exchange the child's DNSKEY RR - sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset - the SEP bit can be used to isolate the DNSKEYs for which a DS RR - needs to be created. - - - - -Kolkman, et al. Expires June 17, 2004 [Page 3] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - An administrator has configured a DNSKEY as root for a trusted - subtree into security aware resolver. Using a special purpose tool - that queries for the KEY RRs from that domain's apex, the - administrator will be able to notice the roll over of the trusted - anchor by a change of the subset of KEY RRs with the DS flag set. - - A signer might use the SEP bit on the public key to determine - which private key to use to exclusively sign the DNSKEY RRset and - which private key to use to sign the other RRsets in the zone. - - As demonstrated in the above examples it is important to be able to - differentiate the SEP keys from the other keys in a DNSKEY RR set in - the flow between signer and (parental) key-collector and in the flow - between the signer and the resolver configuration. The SEP flag is to - be of no interest to the flow between the verifier and the - authoritative data store. - - The reason for the term "SEP" is a result of the observation that the - distinction between KSK and ZSK key pairs is made by the signer, a - key pair could be used as both a KSK and a ZSK at the same time. To - be clear, the term SEP was coined to lessen the confusion caused by - the overlap. ( Once this label was applied, it had the side effect of - removing the temptation to have both a KSK flag bit and a ZSK flag - bit.) - - The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", - "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be - interpreted as described in RFC2119 [1]. - -2. The Secure Entry Point (SEP) Flag - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | flags |S| protocol | algorithm | - | |E| | | - | |P| | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - DNSKEY RR Format - - - - - - -Kolkman, et al. Expires June 17, 2004 [Page 4] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - This document assigns the 15'th bit in the flags field as the secure - entry point (SEP) bit. If the the bit is set to 1 the key is - intended to be used as secure entry point key. One SHOULD NOT assign - special meaning to the key if the bit is set to 0. Operators can - recognize the secure entry point key by the even or odd-ness of the - decimal representation of the flag field. - -3. DNSSEC Protocol Changes - - The bit MUST NOT be used during the resolving and verification - process. The SEP flag is only used to provide a hint about the - different administrative properties of the key and therefore the use - of the SEP flag does not change the DNS resolution protocol or the - resolution process. - -4. Operational Guidelines - - The SEP bit is set by the key-pair-generator and MAY be used by the - zone signer to decide whether the public part of the key pair is to - be prepared for input to a DS RR generation function. The SEP bit is - recommended to be set (to 1) whenever the public key of the key pair - will be distributed to the parent zone to build the authentication - chain or if the public key is to be distributed for static - configuration in verifiers. - - When a key pair is created, the operator needs to indicate whether - the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within - the data that is used to compute the 'key tag field' in the SIG RR, - changing the SEP bit will change the identity of the key within DNS. - In other words, once a key is used to generate signatures, the - setting of the SEP bit is to remain constant. If not, a verifier will - not be able to find the relevant KEY RR. - - When signing a zone, it is intended that the key(s) with the SEP bit - set (if such keys exist) are used to sign the KEY RR set of the zone. - The same key can be used to sign the rest of the zone data too. It - is conceivable that not all keys with a SEP bit set will sign the - DNSKEY RR set, such keys might be pending retirement or not yet in - use. - - When verifying a RR set, the SEP bit is not intended to play a role. - How the key is used by the verifier is not intended to be a - consideration at key creation time. - - Although the SEP flag provides a hint on which public key is to be - used as trusted root, administrators can choose to ignore the fact - that a DNSKEY has its SEP bit set or not when configuring a trusted - root for their resolvers. - - - -Kolkman, et al. Expires June 17, 2004 [Page 5] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - Using the SEP flag a key roll over can be automated. The parent can - use an existing trust relation to verify DNSKEY RR sets in which a - new DNSKEY RR with the SEP flag appears. - -5. Security Considerations - - As stated in Section 3 the flag is not to be used in the resolution - protocol or to determine the security status of a key. The flag is to - be used for administrative purposes only. - - No trust in a key should be inferred from this flag - trust MUST be - inferred from an existing chain of trust or an out-of-band exchange. - - Since this flag might be used for automating public key exchanges, we - think the following consideration is in place. - - Automated mechanisms for roll over of the DS RR might be vulnerable - to a class of replay attacks. This might happen after a public key - exchange where a DNSKEY RR set, containing two DNSKEY RRs with the - SEP flag set, is sent to the parent. The parent verifies the DNSKEY - RR set with the existing trust relation and creates the new DS RR - from the DNSKEY RR that the current DS RR is not pointing to. This - key exchange might be replayed. Parents are encouraged to implement a - replay defense. A simple defense can be based on a registry of keys - that have been used to generate DS RRs during the most recent roll - over. These same considerations apply to entities that configure keys - in resolvers. - -6. IANA Considerations - - The flag bits in the DNSKEY RR are assigned by IETF consensus and - registered in the DNSKEY Flags registry (created by [4]). This - document assigns the 15th bit in the DNSKEY RR as the Secure Entry - Point (SEP) bit. - -7. Internationalization Considerations - - Although SEP is a popular acronym in many different languages, there - are no internationalization considerations. - -8. Acknowledgments - - The ideas documented in this document are inspired by communications - we had with numerous people and ideas published by other folk. Among - others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, - Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler - have contributed ideas and provided feedback. - - - - -Kolkman, et al. Expires June 17, 2004 [Page 6] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - This document saw the light during a workshop on DNSSEC operations - hosted by USC/ISI in August 2002. - -Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [3] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [4] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work - in progress), October 2003. - -Informative References - - [5] Gudmundsson, O., "Delegation Signer Resource Record", - draft-ietf-dnsext-delegation-signer-15 (work in progress), June - 2003. - - [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy - Story", ISBN 0151002177 (50th anniversary edition), April 1996. - - -Authors' Addresses - - Olaf M. Kolkman - RIPE NCC - Singel 256 - Amsterdam 1016 AB - NL - - Phone: +31 20 535 4444 - EMail: olaf@ripe.net - URI: http://www.ripe.net/ - - - Jakob Schlyter - Karl Gustavsgatan 15 - Goteborg SE-411 25 - Sweden - - EMail: jakob@schlyter.se - - - - -Kolkman, et al. Expires June 17, 2004 [Page 7] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - Edward P. Lewis - ARIN - 3635 Concorde Parkway Suite 200 - Chantilly, VA 20151 - US - - Phone: +1 703 227 9854 - EMail: edlewis@arin.net - URI: http://www.arin.net/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman, et al. Expires June 17, 2004 [Page 8] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Kolkman, et al. Expires June 17, 2004 [Page 9] - -Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman, et al. Expires June 17, 2004 [Page 10] - - diff --git a/doc/rfc/index b/doc/rfc/index index 83ae404410..2858658729 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -92,6 +92,7 @@ Secret Key Transaction Authentication for DNS (GSS-TSIG) 3655: Redefinition of DNS Authenticated Data (AD) bit 3658: Delegation Signer (DS) Resource Record (RR) +3755: Legacy Resolver Compatibility for Delegation Signer (DS) 3757: Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag 3833: Threat Analysis of the Domain Name System (DNS) @@ -112,6 +113,7 @@ 4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 4470: Minimally Covering NSEC Records and DNSSEC On-line Signing +4471: Derivation of DNS Name Predecessor and Successor 4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) 4634: US Secure Hash Algorithms (SHA and HMAC-SHA) 4635: HMAC SHA TSIG Algorithm Identifiers @@ -120,9 +122,15 @@ 4701: A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) 4892: Requirements for a Mechanism Identifying a Name Server Instance +4955: DNS Security (DNSSEC) Experiments +4956: DNS Security (DNSSEC) Opt-In +5001: DNS Name Server Identifier (NSID) Option 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence 5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extension +5395: Domain Name System (DNS) IANA Considerations +5452: Measures for Making DNS More Resilient against Forged Answers 5507: Design Choices When Expanding the DNS +5625: DNS Proxy Implementation Guidelines 5702: Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC diff --git a/doc/rfc/rfc3755.txt b/doc/rfc/rfc3755.txt new file mode 100644 index 0000000000..a9a7cf2692 --- /dev/null +++ b/doc/rfc/rfc3755.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group S. Weiler +Request for Comments: 3755 SPARTA, Inc. +Updates: 3658, 2535 May 2004 +Category: Standards Track + + + Legacy Resolver Compatibility for Delegation Signer (DS) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + As the DNS Security (DNSSEC) specifications have evolved, the syntax + and semantics of the DNSSEC resource records (RRs) have changed. + Many deployed nameservers understand variants of these semantics. + Dangerous interactions can occur when a resolver that understands an + earlier version of these semantics queries an authoritative server + that understands the new delegation signer semantics, including at + least one failure scenario that will cause an unsecured zone to be + unresolvable. This document changes the type codes and mnemonics of + the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. + +1. Introduction + + The DNSSEC protocol has been through many iterations whose syntax and + semantics are not completely compatible. This has occurred as part + of the ordinary process of proposing a protocol, implementing it, + testing it in the increasingly complex and diverse environment of the + Internet, and refining the definitions of the initial Proposed + Standard. In the case of DNSSEC, the process has been complicated by + DNS's criticality and wide deployment and the need to add security + while minimizing daily operational complexity. + + A weak area for previous DNS specifications has been lack of detail + in specifying resolver behavior, leaving implementors largely on + their own to determine many details of resolver function. This, + combined with the number of iterations the DNSSEC specifications have + been through, has resulted in fielded code with a wide variety of + + + +Weiler Standards Track [Page 1] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + + behaviors. This variety makes it difficult to predict how a protocol + change will be handled by all deployed resolvers. The risk that a + change will cause unacceptable or even catastrophic failures makes it + difficult to design and deploy a protocol change. One strategy for + managing that risk is to structure protocol changes so that existing + resolvers can completely ignore input that might confuse them or + trigger undesirable failure modes. + + This document addresses a specific problem caused by Delegation + Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR + that are incompatible with the semantics in [RFC2535]. Answers + provided by DS-aware servers can trigger an unacceptable failure mode + in some resolvers that implement RFC 2535, which provides a great + disincentive to sign zones with DS. The changes defined in this + document allow for the incremental deployment of DS. + +1.1. Terminology + + In this document, the term "unsecure delegation" means any delegation + for which no DS record appears at the parent. An "unsecure referral" + is an answer from the parent containing an NS RRset and a proof that + no DS record exists for that name. + + 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]. + +1.2. The Problem + + Delegation Signer (DS) introduces new semantics for the NXT RR that + are incompatible with the semantics in RFC 2535. In RFC 2535, NXT + records were only required to be returned as part of a non-existence + proof. With DS, an unsecure referral returns, in addition to the NS, + a proof of non-existence of a DS RR in the form of an NXT and + SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a + response with RCODE=0, AA=0, and both an NS and an NXT in the + authority section. Some widely deployed 2535-aware resolvers + interpret any answer with an NXT as a proof of non-existence of the + requested record. This results in unsecure delegations being + invisible to 2535-aware resolvers and violates the basic + architectural principle that DNSSEC must do no harm -- the signing of + zones must not prevent the resolution of unsecured delegations. + +2. Possible Solutions + + This section presents several solutions that were considered. + Section 3 describes the one selected. + + + + +Weiler Standards Track [Page 2] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +2.1. Change SIG, KEY, and NXT type codes + + To avoid the problem described above, legacy (RFC2535-aware) + resolvers need to be kept from seeing unsecure referrals that include + NXT records in the authority section. The simplest way to do that is + to change the type codes for SIG, KEY, and NXT. + + The obvious drawback to this is that new resolvers will not be able + to validate zones signed with the old RRs. This problem already + exists, however, because of the changes made by DS, and resolvers + that understand the old RRs (and have compatibility issues with DS) + are far more prevalent than 2535-signed zones. + +2.2. Change a subset of type codes + + The observed problem with unsecure referrals could be addressed by + changing only the NXT type code or another subset of the type codes + that includes NXT. This has the virtue of apparent simplicity, but + it risks introducing new problems or not going far enough. It's + quite possible that more incompatibilities exist between DS and + earlier semantics. Legacy resolvers may also be confused by seeing + records they recognize (SIG and KEY) while being unable to find NXTs. + Although it may seem unnecessary to fix that which is not obviously + broken, it's far cleaner to change all of the type codes at once. + This will leave legacy resolvers and tools completely blinded to + DNSSEC -- they will see only unknown RRs. + +2.3. Replace the DO bit + + Another way to keep legacy resolvers from ever seeing DNSSEC records + with DS semantics is to have authoritative servers only send that + data to DS-aware resolvers. It's been proposed that assigning a new + EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and + having authoritative servers send DNSSEC data only in response to + queries with the DA bit set, would accomplish this. This bit would + presumably supplant the DO bit described in [RFC3225]. + + This solution is sufficient only if all 2535-aware resolvers zero out + EDNS0 flags that they don't understand. If one passed through the DA + bit unchanged, it would still see the new semantics, and it would + probably fail to see unsecure delegations. Since it's impractical to + know how every DNS implementation handles unknown EDNS0 flags, this + is not a universal solution. It could, though, be considered in + addition to changing the RR type codes. + + + + + + + +Weiler Standards Track [Page 3] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +2.4. Increment the EDNS version + + Another possible solution is to increment the EDNS version number as + defined in [RFC2671], on the assumption that all existing + implementations will reject higher versions than they support, and + retain the DO bit as the signal for DNSSEC awareness. This approach + has not been tested. + +2.5. Do nothing + + There is a large deployed base of DNS resolvers that understand + DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and, + due to under specification in those documents, interpret any answer + with an NXT as a non-existence proof. So long as that is the case, + zone owners will have a strong incentive to not sign any zones that + contain unsecure delegations, lest those delegations be invisible to + such a large installed base. This will dramatically slow DNSSEC + adoption. + + Unfortunately, without signed zones there's no clear incentive for + operators of resolvers to upgrade their software to support the new + version of DNSSEC, as defined in RFC 3658. Historical data suggests + that resolvers are rarely upgraded, and that old nameserver code + never dies. + + Rather than wait years for resolvers to be upgraded through natural + processes before signing zones with unsecure delegations, addressing + this problem with a protocol change will immediately remove the + disincentive for signing zones and allow widespread deployment of + DNSSEC. + +3. Protocol changes + + This document changes the type codes of SIG, KEY, and NXT. This + approach is the cleanest and safest of those discussed above, largely + because the behavior of resolvers that receive unknown type codes is + well understood. This approach has also received the most testing. + + To avoid operational confusion, it's also necessary to change the + mnemonics for these RRs. DNSKEY will be the replacement for KEY, + with the mnemonic indicating that these keys are not for application + use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace + SIG, and NSEC (Next SECure) will replace NXT. These new types + completely replace the old types, except that SIG(0) [RFC2931] and + TKEY [RFC2930] will continue to use SIG and KEY. + + + + + + +Weiler Standards Track [Page 4] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + + The new types will have exactly the same syntax and semantics as + specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for + the following: + + 1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC + RRs MUST NOT be compressed, + + 2) Embedded domain names in RRSIG and NSEC RRs are not downcased for + purposes of DNSSEC canonical form and ordering nor for equality + comparison, and + + 3) An RRSIG with a type-covered field of zero has undefined + semantics. The meaning of such a resource record may only be + defined by IETF Standards Action. + + If a resolver receives the old types, it SHOULD treat them as unknown + RRs and SHOULD NOT assign any special meaning to them or give them + any special treatment. It MUST NOT use them for DNSSEC validations + or other DNS operational decision making. For example, a resolver + MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs. + If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive + special treatment. As an example, if a SIG is included in a signed + zone, there MUST be an RRSIG for it. Authoritative servers may wish + to give error messages when loading zones containing SIG or NXT + records (KEY records may be included for SIG(0) or TKEY). + + As a clarification to previous documents, some positive responses, + particularly wildcard proofs and unsecure referrals, will contain + NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as negative + answers merely because they contain an NSEC. + +4. IANA Considerations + +4.1. DNS Resource Record Types + + This document updates the IANA registry for DNS Resource Record Types + by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, + respectively. + + Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and + TKEY [RFC2930] use only. + + Type 30 (NXT) should be marked as Obsolete. + + + + + + + + +Weiler Standards Track [Page 5] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +4.2. DNS Security Algorithm Numbers + + To allow zone signing (DNSSEC) and transaction security mechanisms + (SIG(0) and TKEY) to use different sets of algorithms, the existing + "DNS Security Algorithm Numbers" registry is modified to include the + applicability of each algorithm. Specifically, two new columns are + added to the registry, showing whether each algorithm may be used for + zone signing, transaction security mechanisms, or both. Only + algorithms usable for zone signing may be used in DNSKEY, RRSIG, and + DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in + SIG and KEY RRs. + + All currently defined algorithms except for Indirect (algorithm 252) + remain usable for transaction security mechanisms. Only RSA/SHA-1 + [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and + 254) may be used for zone signing. Note that the registry does not + contain the requirement level of each algorithm, only whether or not + an algorithm may be used for the given purposes. For example, + RSA/MD5, while allowed for transaction security mechanisms, is NOT + RECOMMENDED, per [RFC3110]. + + Additionally, the presentation format algorithm mnemonics from + [RFC2535] Section 7 are added to the registry. This document assigns + RSA/SHA-1 the mnemonic RSASHA1. + + As before, assignment of new algorithms in this registry requires + IETF Standards Action. Additionally, modification of algorithm + mnemonics or applicability requires IETF Standards Action. Documents + defining a new algorithm must address the applicability of the + algorithm and should assign a presentation mnemonic to the algorithm. + +4.3. DNSKEY Flags + + Like the KEY resource record, DNSKEY contains a 16-bit flags field. + This document creates a new registry for the DNSKEY flags field. + + Initially, this registry only contains an assignment for bit 7 (the + ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF + Standards Action. + +4.4. DNSKEY Protocol Octet + + Like the KEY resource record, DNSKEY contains an eight bit protocol + field. The only defined value for this field is 3 (DNSSEC). No + other values are allowed, hence no IANA registry is needed for this + field. + + + + + +Weiler Standards Track [Page 6] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +5. Security Considerations + + The changes introduced here do not materially affect security. The + implications of trying to use both new and legacy types together are + not well understood, and attempts to do so would probably lead to + unintended and dangerous results. + + Changing type codes will leave code paths in legacy resolvers that + are never exercised. Unexercised code paths are a frequent source of + security holes, largely because those code paths do not get frequent + scrutiny. + + Doing nothing, as described in section 2.5, will slow DNSSEC + deployment. While this does not decrease security, it also fails to + increase it. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", + RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + + + + + + + + + + +Weiler Standards Track [Page 7] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +6.2. Informative References + + [RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System + Security Extensions", RFC 2065, January 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + +7. Acknowledgments + + The changes introduced here and the analysis of alternatives had many + contributors. With apologies to anyone overlooked, those include: + Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, + Bill Manning, Paul Vixie, and Suzanne Woolf. + + Thanks to Jakob Schlyter and Mark Andrews for identifying the + incompatibility described in section 1.2. + + In addition to the above, the author would like to thank Scott Rose, + Olafur Gudmundsson, and Sandra Murphy for their substantive comments. + +8. Author's Address + + Samuel Weiler + SPARTA, Inc. + 7075 Samuel Morse Drive + Columbia, MD 21046 + USA + + EMail: weiler@tislabs.com + + + + + + + + + + + + +Weiler Standards Track [Page 8] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Weiler Standards Track [Page 9] + diff --git a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/doc/rfc/rfc4471.txt similarity index 60% rename from doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt rename to doc/rfc/rfc4471.txt index 438e8008a4..eb338e6b5e 100644 --- a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt +++ b/doc/rfc/rfc4471.txt @@ -1,40 +1,28 @@ -DNS Extensions Working Group G. Sisson -Internet-Draft B. Laurie -Expires: January 11, 2006 Nominet - July 10, 2005 + + + + + + +Network Working Group G. Sisson +Request for Comments: 4471 B. Laurie +Category: Experimental Nominet + September 2006 Derivation of DNS Name Predecessor and Successor - draft-ietf-dnsext-dns-name-p-s-00 -Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. +Status of This Memo - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 11, 2006. + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract @@ -42,105 +30,90 @@ Abstract 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 + existence without disclosing other owner names in a DNSSEC secured zone. - - - - -Sisson & Laurie Expires January 11, 2006 [Page 1] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 - 3. Absolute Method . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 4 - 3.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 4 - 4. Modified Method . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 6 - 4.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 6 - 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5.1. Case Considerations . . . . . . . . . . . . . . . . . . . 7 - 5.2. Choice of Range . . . . . . . . . . . . . . . . . . . . . 7 - 5.3. Wild Card Considerations . . . . . . . . . . . . . . . . . 8 - 5.4. Possible Modifications . . . . . . . . . . . . . . . . . . 8 - 5.4.1. Restriction of Effective Maximum DNS Name Length . . . 8 - 5.4.2. Use of Modified Method With Zones Containing - SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 9 - 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.1. Examples of Immediate Predecessors Using Absolute - Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.2. Examples of Immediate Successors Using Absolute Method . . 13 - 6.3. Examples of Predecessors Using Modified Method . . . . . . 19 - 6.4. Examples of Successors Using Modified Method . . . . . . . 20 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 - Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22 - A.1. Changes from sisson-02 to ietf-00 . . . . . . . . . . . . 22 - A.2. Changes from sisson-01 to sisson-02 . . . . . . . . . . . 23 - A.3. Changes from sisson-00 to sisson-01 . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 - Intellectual Property and Copyright Statements . . . . . . . . . . 25 + 1. Introduction ....................................................2 + 2. Notational Conventions ..........................................3 + 3. Derivations .....................................................3 + 3.1. Absolute Method ............................................3 + 3.1.1. Derivation of DNS Name Predecessor ..................3 + 3.1.2. Derivation of DNS Name Successor ....................4 + 3.2. Modified Method ............................................4 + 3.2.1. Derivation of DNS Name Predecessor ..................5 + 3.2.2. Derivation of DNS Name Successor ....................6 + 4. Notes ...........................................................6 + 4.1. Test for Existence .........................................6 + 4.2. Case Considerations ........................................7 + 4.3. Choice of Range ............................................7 + 4.4. Wild Card Considerations ...................................8 + 4.5. Possible Modifications .....................................8 + 4.5.1. Restriction of Effective Maximum DNS Name Length ....8 + 4.5.2. Use of Modified Method with Zones Containing - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 2] +Sisson & Laurie Experimental [Page 1] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 + SRV RRs .............................................8 + 5. Examples ........................................................9 + 5.1. Examples of Immediate Predecessors Using Absolute Method ..10 + 5.2. Examples of Immediate Successors Using Absolute Method ....14 + 5.3. Examples of Predecessors Using Modified Method ............19 + 5.4. Examples of Successors Using Modified Method ..............20 + 6. Security Considerations ........................................21 + 7. Acknowledgements ...............................................21 + 8. References .....................................................21 + 8.1. Normative References ......................................21 + 8.2. Informative References ....................................22 + 1. Introduction One of the proposals for avoiding the exposure of zone information during the deployment DNSSEC is dynamic NSEC resource record (RR) - synthesis. This technique is described in [I-D.ietf-dnsext-dnssec- - trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the - generation of NSEC RRs that just span the query name for non-existent - owner names. In order to do this, the DNS names which would occur - just prior to and just following a given query name must be - calculated in real time, as maintaining a list of all possible owner - names that might occur in a zone would be impracticable. + synthesis. This technique is described in [DNSSEC-TRANS] and + [RFC4470], and involves the generation of NSEC RRs that just span the + query name for non-existent owner names. In order to do this, the + DNS names that would occur just prior to and just following a given + query name must be calculated in real time, as maintaining a list of + all possible owner names that might occur in a zone would be + impracticable. Section 6.1 of [RFC4034] defines canonical DNS name order. This document does not amend or modify this definition. However, the - derivation of immediate predecessor and successor, while trivial, is - non-obvious. Accordingly, several methods are described here as an - aid to implementors and a reference to other interested parties. + derivation of immediate predecessor and successor, although trivial, + is non-obvious. Accordingly, several methods are described here as + an aid to implementors and a reference to other interested parties. This document describes two methods: - 1. An ``absolute method'', which returns the immediate predecessor - or successor of a domain name such that no valid DNS name could + 1. An "absolute method", which returns the immediate predecessor or + successor of a domain name such that no valid DNS name could exist between that DNS name and the predecessor or successor. - 2. A ``modified method'', which returns a predecessor and successor - which are more economical in size and computation. This method - is restricted to use with zones consisting only of single-label - owner names where a maximum-length owner name would not result in - a DNS name exceeding the maximum DNS name length. This is, - however, the type of zone for which the technique of online- - signing is most likely to be used. + 2. A "modified method", which returns a predecessor and successor + that are more economical in size and computation. This method is + restricted to use with zones consisting exclusively of owner + names that contain no more than one label more than the owner + name of the apex, where the longest possible owner name (i.e., + one with a maximum length left-most label) would not exceed the + maximum DNS name length. This is, however, the type of zone for + which the technique of online signing is most likely to be used. + + + + + + + +Sisson & Laurie Experimental [Page 2] + +RFC 4471 DNS Name Predecessor and Successor September 2006 2. Notational Conventions @@ -156,104 +129,106 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 P'(N): Predecessor to N (modified method). - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 3] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - S'(N): Successor to N (modified method). - -3. Absolute Method +3. Derivations These derivations assume that all uppercase US-ASCII letters in N have already been replaced by their corresponding lowercase equivalents. Unless otherwise specified, processing stops after the first step in which a condition is met. -3.1. Derivation of DNS Name Predecessor + The derivations make reference to maximum label length and maximum + DNS name length; these are defined in Section 3.1 of [RFC1034] to be + 63 and 255 octets, respectively. + +3.1. Absolute Method + +3.1.1. Derivation of DNS Name Predecessor To derive P(N): 1. If N is the same as the owner name of the zone apex, prepend N repeatedly with labels of the maximum length possible consisting - of octets of the maximum sort value (e.g. 0xff) until N is the - maximum length possible; otherwise continue to the next step. + of octets of the maximum sort value (e.g., 0xff) until N is the + maximum length possible; otherwise proceed to the next step. 2. If the least significant (left-most) label of N consists of a - single octet of the minimum sort value (e.g. 0x00), remove that - label; otherwise continue to the next step. + single octet of the minimum sort value (e.g., 0x00), remove that + label; otherwise proceed to the next step. 3. If the least significant (right-most) octet in the least significant (left-most) label of N is the minimum sort value, - remove the least significant octet and continue with step 5. + remove the least significant octet and proceed to step 5. - 4. Decrement the value of the least significant (right-most) octet, - skipping any values that correspond to uppercase US-ASCII - letters, and then append the label with as many octets as - possible of the maximum sort value. Continue to the next step. + 4. Decrement the value of the least significant (right-most) octet + of the least significant (left-most) label, skipping any values + that correspond to uppercase US-ASCII letters, and then append + + + +Sisson & Laurie Experimental [Page 3] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + the least significant (left-most) label with as many octets as + possible of the maximum sort value. Proceed to the next step. 5. Prepend N repeatedly with labels of as long a length as possible consisting of octets of the maximum sort value until N is the maximum length possible. -3.2. Derivation of DNS Name Successor +3.1.2. Derivation of DNS Name Successor To derive S(N): 1. If N is two or more octets shorter than the maximum DNS name length, prepend N with a label containing a single octet of the - minimum sort value (e.g. 0x00); otherwise continue to the next + minimum sort value (e.g., 0x00); otherwise proceed to the next step. - 2. If N is one or more octets shorter than the maximum DNS name - length and the least significant (left-most) label is one or more - octets shorter than the maximum label length, append an octet of - - - -Sisson & Laurie Expires January 11, 2006 [Page 4] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - the minimum sort value to the least significant label; otherwise - continue to the next step. + 2. If N is one octet shorter than the maximum DNS name length and + the least significant (left-most) label is one or more octets + shorter than the maximum label length, append an octet of the + minimum sort value to the least significant label; otherwise + proceed to the next step. 3. Increment the value of the least significant (right-most) octet in the least significant (left-most) label that is less than the - maximum sort value (e.g. 0xff), skipping any values that + maximum sort value (e.g., 0xff), skipping any values that correspond to uppercase US-ASCII letters, and then remove any octets to the right of that one. If all octets in the label are - the maximum sort value, then continue to the next step. + the maximum sort value, then proceed to the next step. - 4. Remove the least significant (left-most) label. If N is now the - same as the owner name of the zone apex, do nothing. (This will - occur only if N is the maximum possible name in canonical DNS - name order, and thus has wrapped to the owner name of zone apex.) - Otherwise repeat starting at step 2. + 4. Remove the least significant (left-most) label. Unless N is now + the same as the owner name of the zone apex (this will occur only + if N was the maximum possible name in canonical DNS name order, + and thus has wrapped to the owner name of zone apex), repeat + starting at step 2. - -4. Modified Method +3.2. Modified Method This method is for use with zones consisting only of single-label owner names where an owner name consisting of label of maximum length - would not result in a DNS name which exceeded the maximum DNS name + would not result in a DNS name that exceeded the maximum DNS name length. This method is computationally simpler and returns values - which are more economical in size than the absolute method. It + that are more economical in size than the absolute method. It differs from the absolute method detailed above in the following ways: 1. Step 1 of the derivation P(N) has been omitted as the existence of the owner name of the zone apex never requires denial. - 2. A new step 1 has been introduced which removes unnecessary - labels. + + + +Sisson & Laurie Experimental [Page 4] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + 2. A new step 1 has been introduced that removes unnecessary labels. 3. Step 4 of the derivation P(N) has been omitted as it is only necessary for zones containing owner names consisting of more @@ -271,87 +246,110 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 assumption of this method that no DNS name in the zone can exceed the maximum DNS name length. - - -Sisson & Laurie Expires January 11, 2006 [Page 5] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - - These derivations assume that all uppercase US-ASCII letters in N - have already been replaced by their corresponding lowercase - equivalents. Unless otherwise specified, processing stops after the - first step in which a condition is met. - -4.1. Derivation of DNS Name Predecessor +3.2.1. Derivation of DNS Name Predecessor To derive P'(N): - 1. If N has more labels than the number of labels in the owner name - of the apex + 1, repeatedly remove the least significant (left- - most) label until N has no more labels than the number of labels - in the owner name of the apex + 1; otherwise continue to next - step. + 1. If N is two or more labels longer than the owner name of the + apex, repeatedly remove the least significant (left-most) label + until N is only one label longer than the owner name of the apex; + otherwise proceed to the next step. 2. If the least significant (left-most) label of N consists of a - single octet of the minimum sort value (e.g. 0x00), remove that - label; otherwise continue to the next step. + single octet of the minimum sort value (e.g., 0x00), remove that + label; otherwise proceed to the next step. (If this condition is + met, P'(N) is the owner name of the apex.) 3. If the least significant (right-most) octet in the least significant (left-most) label of N is the minimum sort value, remove the least significant octet. 4. Decrement the value of the least significant (right-most) octet, - skipping any values which correspond to uppercase US-ASCII + skipping any values that correspond to uppercase US-ASCII letters, and then append the label with as many octets as possible of the maximum sort value. -4.2. Derivation of DNS Name Successor + + + + + + + + + + +Sisson & Laurie Experimental [Page 5] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + +3.2.2. Derivation of DNS Name Successor To derive S'(N): - 1. If N has more labels than the number of labels in the owner name - of the apex + 1, repeatedly remove the least significant (left- - most) label until N has no more labels than the number of labels - in the owner name of the apex + 1. Continue to next step. + 1. If N is two or more labels longer than the owner name of the + apex, repeatedly remove the least significant (left-most) label + until N is only one label longer than the owner name of the apex. + Proceed to the next step. 2. If the least significant (left-most) label of N is one or more octets shorter than the maximum label length, append an octet of the minimum sort value to the least significant label; otherwise - continue to the next step. + proceed to the next step. 3. Increment the value of the least significant (right-most) octet in the least significant (left-most) label that is less than the - maximum sort value (e.g. 0xff), skipping any values which + maximum sort value (e.g., 0xff), skipping any values that correspond to uppercase US-ASCII letters, and then remove any octets to the right of that one. If all octets in the label are - the maximum sort value, then continue to the next step. - - - -Sisson & Laurie Expires January 11, 2006 [Page 6] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - + the maximum sort value, then proceed to the next step. 4. Remove the least significant (left-most) label. (This will occur only if the least significant label is the maximum label length and consists entirely of octets of the maximum sort value, and thus has wrapped to the owner name of the zone apex.) +4. Notes -5. Notes +4.1. Test for Existence -5.1. Case Considerations + Before using the result of P(N) or P'(N) as the owner name of an NSEC + RR in a DNS response, a name server should test to see whether the + name exists. If it does, either a standard non-synthesised NSEC RR + should be used, or the synthesised NSEC RR should reflect the RRset + types that exist at the NSEC RR's owner name in the Type Bit Map + field as specified by Section 4.1.2 of [RFC4034]. Implementors will + likely find it simpler to use a non-synthesised NSEC RR. For further + details, see Section 2 of [RFC4470]. + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 6] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + +4.2. Case Considerations Section 3.5 of [RFC1034] specifies that "while upper and lower case - letters are allowed in [DNS] names, no significance is attached to - the case". Additionally, Section 6.1 of [RFC4034] states that when + letters are allowed in names, no significance is attached to the + case". Additionally, Section 6.1 of [RFC4034] states that when determining canonical DNS name order, "uppercase US-ASCII letters are treated as if they were lowercase US-ASCII letters". Consequently, values corresponding to US-ASCII uppercase letters must be skipped when decrementing and incrementing octets in the derivations - described in Section 3.1 and Section 3.2. + described in Section 3. The following pseudo-code is illustrative: @@ -369,98 +367,100 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 else octet++; -5.2. Choice of Range +4.3. Choice of Range [RFC2181] makes the clarification that "any binary string whatever - can be used as the label of any resource record". Consequently the + can be used as the label of any resource record". Consequently, the minimum sort value may be set as 0x00 and the maximum sort value as - 0xff, and the range of possible values will be any DNS name which + 0xff, and the range of possible values will be any DNS name that contains octets of any value other than those corresponding to uppercase US-ASCII letters. However, if all owner names in a zone are in the letter-digit-hyphen, or LDH, format specified in [RFC1034], it may be desirable to restrict the range of possible values to DNS names containing only - LDH values. This has the effect of: - - - -Sisson & Laurie Expires January 11, 2006 [Page 7] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - + LDH values. This has the effect of 1. making the output of tools such as `dig' and `nslookup' less - subject to confusion; + subject to confusion, 2. minimising the impact that NSEC RRs containing DNS names with non-LDH values (or non-printable values) might have on faulty DNS - resolver implementations; and + resolver implementations, and - 3. preventing the possibility of results which are wildcard DNS - names (see Section 5.3). + + + +Sisson & Laurie Experimental [Page 7] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + 3. preventing the possibility of results that are wildcard DNS names + (see Section 4.4). This may be accomplished by using a minimum sort value of 0x1f (US- ASCII character `-') and a maximum sort value of 0x7a (US-ASCII character lowercase `z'), and then skipping non-LDH, non-lowercase values when incrementing or decrementing octets. -5.3. Wild Card Considerations +4.4. Wild Card Considerations Neither derivation avoids the possibility that the result may be a - DNS name containing a wildcard label, i.e. a label containing a + DNS name containing a wildcard label, i.e., a label containing a single octet with the value 0x2a (US-ASCII character `*'). With additional tests, wildcard DNS names may be explicitly avoided; alternatively, if the range of octet values can be restricted to those corresponding to letter-digit-hyphen, or LDH, characters (see - Section 5.2), such DNS names will not occur. + Section 4.3), such DNS names will not occur. - Note that it is improbable that a result which is a wildcard DNS name + Note that it is improbable that a result that is a wildcard DNS name will occur unintentionally; even if one does occur either as the owner name of, or in the RDATA of an NSEC RR, it is treated as a literal DNS name with no special meaning. -5.4. Possible Modifications +4.5. Possible Modifications -5.4.1. Restriction of Effective Maximum DNS Name Length +4.5.1. Restriction of Effective Maximum DNS Name Length [RFC1034] specifies that "the total number of octets that represent a - [DNS] name (i.e., the sum of all label octets and label lengths) is - limited to 255", including the null (zero-length) label which - represents the root. For the purpose of deriving predecessors and - successors during NSEC RR synthesis, the maximum DNS name length may - be effectively restricted to the length of the longest DNS name in - the zone. This will minimise the size of responses containing - synthesised NSEC RRs but, especially in the case of the modified - method, may result in some additional computational complexity. + name (i.e., the sum of all label octets and label lengths) is limited + to 255", including the null (zero-length) label that represents the + root. For the purpose of deriving predecessors and successors during + NSEC RR synthesis, the maximum DNS name length may be effectively + restricted to the length of the longest DNS name in the zone. This + will minimise the size of responses containing synthesised NSEC RRs + but, especially in the case of the modified method, may result in + some additional computational complexity. Note that this modification will have the effect of revealing information about the longest name in the zone. Moreover, when the - contents of the zone changes, e.g. during dynamic updates and zone + contents of the zone changes, e.g., during dynamic updates and zone transfers, care must be taken to ensure that the effective maximum - - - -Sisson & Laurie Expires January 11, 2006 [Page 8] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - DNS name length agrees with the new contents. -5.4.2. Use of Modified Method With Zones Containing SRV RRs +4.5.2. Use of Modified Method with Zones Containing SRV RRs - Normally the modified method cannot be used in zones that contain - SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple - labels. However the use of SRV RRs can be accommodated by various - techniques. There are at least four possible ways to do this: + Normally, the modified method cannot be used in zones that contain + Service Record (SRV) RRs [RFC2782], as SRV RRs have owner names that + contain multiple labels. However, the use of SRV RRs can be + + + +Sisson & Laurie Experimental [Page 8] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + accommodated by various techniques. There are at least four possible + ways to do this: 1. Use conventional NSEC RRs for the region of the zone that contains first-level labels beginning with the underscore (`_') character. For the purposes of generating these NSEC RRs, the existence of (possibly fictional) ownernames `9{63}' and `a' could be assumed, providing a lower and upper bound for this - region. Then all queries where the QNAME doesn't exist but + region. Then all queries where the QNAME does not exist but contains a first-level label beginning with an underscore could be handled using the normal DNSSEC protocol. @@ -473,7 +473,7 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 2. The absolute method could be used for synthesising NSEC RRs for all queries where the QNAME contains a leading underscore. - However this re-introduces the susceptibility of the absolute + However, this re-introduces the susceptibility of the absolute method to denial of service activity, as an attacker could send queries for an effectively inexhaustible supply of domain names beginning with a leading underscore. @@ -482,42 +482,42 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 NSEC RRs for all queries where the QNAME contains a leading underscore. This variant would assume that all predecessors and successors to queries where the QNAME contains a leading - underscore may consist of two lablels rather than only one. This + underscore may consist of two labels rather than only one. This introduces a little additional complexity without incurring the full increase in response size and computational complexity as the absolute method. - 4. Finally, a variant the modified method which assumes that all + 4. Finally, a variant of the modified method that assumes that all owner names in the zone consist of one or two labels could be - used. However this negates much of the reduction in response + used. However, this negates much of the reduction in response size of the modified method and may be nearly as computationally complex as the absolute method. +5. Examples + + In the following examples, + + the owner name of the zone apex is "example.com.", -Sisson & Laurie Expires January 11, 2006 [Page 9] + +Sisson & Laurie Experimental [Page 9] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 -6. Examples - - In the following examples: - - the owner name of the zone apex is "example.com."; - the range of octet values is 0x00 - 0xff excluding values - corresponding to uppercase US-ASCII letters; and + corresponding to uppercase US-ASCII letters, and non-printable octet values are expressed as three-digit decimal numbers preceded by a backslash (as specified in Section 5.1 of [RFC1035]). -6.1. Examples of Immediate Predecessors Using Absolute Method +5.1. Examples of Immediate Predecessors Using Absolute Method - Example of typical case: + Example of a typical case: P(foo.example.com.) = @@ -548,21 +548,22 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 where {n} represents the number of repetitions of an octet. - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 10] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - Example where least significant (left-most) label of DNS name consists of a single octet of the minimum sort value: P(\000.foo.example.com.) = foo.example.com. + + + + + + +Sisson & Laurie Experimental [Page 10] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + Example where least significant (right-most) octet of least significant (left-most) label has the minimum sort value: @@ -609,12 +610,17 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 -Sisson & Laurie Expires January 11, 2006 [Page 11] + + + + + +Sisson & Laurie Experimental [Page 11] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 - Example where DNS name contains an octet which must be decremented by + Example where DNS name contains an octet that must be decremented by skipping values corresponding to US-ASCII uppercase letters: P(fo\[.example.com.) = @@ -665,9 +671,9 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 -Sisson & Laurie Expires January 11, 2006 [Page 12] +Sisson & Laurie Experimental [Page 12] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 Example where DNS name is the owner name of the zone apex, and @@ -702,30 +708,36 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 \255{49}.\255{63}.\255{63}.\255{63}.example.com. -6.2. Examples of Immediate Successors Using Absolute Method + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 13] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + +5.2. Examples of Immediate Successors Using Absolute Method Example of typical case: S(foo.example.com.) = \000.foo.example.com. - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 13] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - Example where DNS name is one octet short of the maximum DNS name length: @@ -771,15 +783,9 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 14] +Sisson & Laurie Experimental [Page 14] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 Example where DNS name is the maximum DNS name length: @@ -833,9 +839,9 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 -Sisson & Laurie Expires January 11, 2006 [Page 15] +Sisson & Laurie Experimental [Page 15] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 Example where DNS name is the maximum DNS name length and the least @@ -889,14 +895,14 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 -Sisson & Laurie Expires January 11, 2006 [Page 16] +Sisson & Laurie Experimental [Page 16] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 Example where DNS name is the maximum DNS name length and the eight - least significant (right-most) octets of the least significant (left- - most) label have the maximum sort value: + least significant (right-most) octets of the least significant + (left-most) label have the maximum sort value: N = foooooooooooooooooooooooooooooooooooooooo\255 \255\255\255\255\255\255\255.ooooooooooooooooooo @@ -945,13 +951,13 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 -Sisson & Laurie Expires January 11, 2006 [Page 17] +Sisson & Laurie Experimental [Page 17] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 Example where DNS name is the maximum DNS name length and contains an - octet which must be incremented by skipping values corresponding to + octet that must be incremented by skipping values corresponding to US-ASCII uppercase letters: N = fooooooooooooooooooooooooooooooooooooooooooooooo @@ -1001,9 +1007,9 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 -Sisson & Laurie Expires January 11, 2006 [Page 18] +Sisson & Laurie Experimental [Page 18] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 Example where DNS name has the maximum possible sort order in the @@ -1037,9 +1043,9 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 S(N) = example.com. -6.3. Examples of Predecessors Using Modified Method +5.3. Examples of Predecessors Using Modified Method - Example of typical case: + Example of a typical case: P'(foo.example.com.) = @@ -1057,9 +1063,9 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 -Sisson & Laurie Expires January 11, 2006 [Page 19] +Sisson & Laurie Experimental [Page 19] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 Example where DNS name contains more labels than DNS names in the @@ -1094,9 +1100,9 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 \255{63}.example.com. -6.4. Examples of Successors Using Modified Method +5.4. Examples of Successors Using Modified Method - Example of typical case: + Example of a typical case: S'(foo.example.com.) = foo\000.example.com. @@ -1106,22 +1112,18 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 S'(bar.foo.example.com.) = foo\000.example.com. - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 20] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - Example where least significant (left-most) label has the maximum sort value, and consequently wraps to the owner name of the zone apex: + + + +Sisson & Laurie Experimental [Page 20] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + N = \255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255 @@ -1135,156 +1137,58 @@ Internet-Draft DNS Name Predecessor and Successor July 2005 S'(N) = example.com. - -7. Security Considerations +6. Security Considerations The derivation of some predecessors/successors requires the testing - of more conditions than others. Consequently the effectiveness of a + of more conditions than others. Consequently, the effectiveness of a denial-of-service attack may be enhanced by sending queries that require more conditions to be tested. The modified method involves the testing of fewer conditions than the absolute method and consequently is somewhat less susceptible to this exposure. +7. Acknowledgements -8. IANA Considerations + The authors would like to thank Sam Weiler, Olaf Kolkman, Olafur + Gudmundsson, and Niall O'Reilly for their review and input. - This document has no IANA actions. +8. References - Note to RFC Editor: This section is included to make it clear during - pre-publication review that this document has no IANA actions. It - may therefore be removed should it be published as an RFC. +8.1. Normative References + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. -9. Acknowledgments + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. - The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and - Niall O'Reilly for their review and input. + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR + for specifying the location of services (DNS SRV)", + RFC 2782, February 2000. -10. References + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. - - - -Sisson & Laurie Expires January 11, 2006 [Page 21] +Sisson & Laurie Experimental [Page 21] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 -10.1 Normative References +8.2. Informative References - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - -10.2 Informative References - - [I-D.ietf-dnsext-dnssec-online-signing] - Ihren, J. and S. Weiler, "Minimally Covering NSEC Records - and DNSSEC On-line Signing", - draft-ietf-dnsext-dnssec-online-signing-00 (work in - progress), May 2005. - - [I-D.ietf-dnsext-dnssec-trans] - Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC - Transition Mechanisms", - draft-ietf-dnsext-dnssec-trans-02 (work in progress), - February 2005. - - -Appendix A. Change History - -A.1. Changes from sisson-02 to ietf-00 - - o Added notes on use of SRV RRs with modified method. - - o Changed reference from weiler-dnssec-online-signing to ietf- - dnsext-dnssec-online-signing. - - o Changed reference from ietf-dnsext-dnssec-records to RFC 4034. - - o Miscellaneous minor changes to text. - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 22] - -Internet-Draft DNS Name Predecessor and Successor July 2005 - - -A.2. Changes from sisson-01 to sisson-02 - - o Added modified version of derivation (with supporting examples). - - o Introduced notational conventions N, P(N), S(N), P'(N) and S'(N). - - o Added clarification to derivations about when processing stops. - - o Miscellaneous minor changes to text. - -A.3. Changes from sisson-00 to sisson-01 - - o Split step 3 of derivation of DNS name predecessor into two - distinct steps for clarity. - - o Added clarifying text and examples related to the requirement to - avoid uppercase characters when decrementing or incrementing - octets. - - o Added optimisation using restriction of effective maximum DNS name - length. - - o Changed examples to use decimal rather than octal notation as per - [RFC1035]. - - o Corrected DNS name length of some examples. - - o Added reference to weiler-dnssec-online-signing. - - o Miscellaneous minor changes to text. - - - - - - - - - - - - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 23] - -Internet-Draft DNS Name Predecessor and Successor July 2005 + [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC + Records and DNSSEC On-line Signing", RFC 4470, April + 2006. + [DNSSEC-TRANS] Arends, R., Koch, P., and J. Schlyter, "Evaluating + DNSSEC Transition Mechanisms", Work in Progress, + February 2005. Authors' Addresses @@ -1296,8 +1200,8 @@ Authors' Addresses OX4 6LB GB - Phone: +44 1865 332339 - Email: geoff@nominet.org.uk + Phone: +44 1865 332211 + EMail: geoff@nominet.org.uk Ben Laurie @@ -1308,7 +1212,7 @@ Authors' Addresses GB Phone: +44 20 8735 0686 - Email: ben@algroup.co.uk + EMail: ben@algroup.co.uk @@ -1327,22 +1231,28 @@ Authors' Addresses - - - - - - - - - - -Sisson & Laurie Expires January 11, 2006 [Page 24] +Sisson & Laurie Experimental [Page 22] -Internet-Draft DNS Name Predecessor and Successor July 2005 +RFC 4471 DNS Name Predecessor and Successor September 2006 -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -1366,32 +1276,16 @@ Intellectual Property Statement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. +Acknowledgement -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). -Sisson & Laurie Expires January 11, 2006 [Page 25] + + + +Sisson & Laurie Experimental [Page 23] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt b/doc/rfc/rfc4955.txt similarity index 54% rename from doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt rename to doc/rfc/rfc4955.txt index c8db70916f..2d2eb84e0f 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt +++ b/doc/rfc/rfc4955.txt @@ -1,85 +1,48 @@ -DNSEXT D. Blacka -Internet-Draft VeriSign, Inc. -Intended status: Standards Track April 7, 2006 -Expires: October 9, 2006 - DNSSEC Experiments - draft-ietf-dnsext-dnssec-experiments-03 -Status of this Memo +Network Working Group D. Blacka +Request for Comments: 4955 VeriSign, Inc. +Category: Standards Track July 2007 - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + DNS Security (DNSSEC) Experiments - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." +Status of This Memo - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on October 9, 2006. + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2006). - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 1] - -Internet-Draft DNSSEC Experiments April 2006 - + Copyright (C) The IETF Trust (2007). Abstract This document describes a methodology for deploying alternate, non- - backwards-compatible, DNSSEC methodologies in an experimental fashion - without disrupting the deployment of standard DNSSEC. - + backwards-compatible, DNS Security (DNSSEC) methodologies in an + experimental fashion without disrupting the deployment of standard + DNSSEC. Table of Contents - 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8 - 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 10.2. Informative References . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 + 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Definitions and Terminology . . . . . . . . . . . . . . . . . . 2 + 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 4 + 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 5 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 @@ -92,84 +55,12 @@ Table of Contents - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 2] +Blacka Standards Track [Page 1] -Internet-Draft DNSSEC Experiments April 2006 +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 -1. Definitions and Terminology - - Throughout this document, familiarity with the DNS system (RFC 1035 - [5]) and the DNS security extensions ([2], [3], and [4] is assumed. - - 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 RFC 2119 [1]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 3] - -Internet-Draft DNSSEC Experiments April 2006 - - -2. Overview +1. Overview Historically, experimentation with DNSSEC alternatives has been a problematic endeavor. There has typically been a desire to both @@ -180,50 +71,20 @@ Internet-Draft DNSSEC Experiments April 2006 aware resolvers. This document describes a standard methodology for setting up DNSSEC - experiments. This methodology addresses the issue of co-existence + experiments. This methodology addresses the issue of coexistence with standard DNSSEC and DNS by using unknown algorithm identifiers to hide the experimental DNSSEC protocol modifications from standard security-aware resolvers. +2. Definitions and Terminology + Throughout this document, familiarity with the DNS system (RFC 1035 + [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and + RFC 4035 [4]) is assumed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 4] - -Internet-Draft DNSSEC Experiments April 2006 - + 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 RFC 2119 [1]. 3. Experiments @@ -250,35 +111,9 @@ Internet-Draft DNSSEC Experiments April 2006 - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 5] +Blacka Standards Track [Page 2] -Internet-Draft DNSSEC Experiments April 2006 +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 4. Method @@ -290,7 +125,7 @@ Internet-Draft DNSSEC Experiments April 2006 This technique works because of the way DNSSEC-compliant validators are expected to work in the presence of a DS set with only unknown - algorithm identifiers. From [4], Section 5.2: + algorithm identifiers. From RFC 4035 [4], Section 5.2: If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported @@ -306,21 +141,36 @@ Internet-Draft DNSSEC Experiments April 2006 verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned. - While this behavior isn't strictly mandatory (as marked by MUST), it - is likely that a validator would implement this behavior, or, more to - the point, it would handle this situation in a safe way (see below - (Section 6).) + Although this behavior isn't strictly mandatory (as marked by MUST), + it is unlikely for a validator to implement a substantially different + behavior. Essentially, if the validator does not have a usable chain + of trust to a child zone, then it can only do one of two things: + treat responses from the zone as insecure (the recommended behavior), + or treat the responses as bogus. If the validator chooses the + latter, this will both violate the expectation of the zone owner and + defeat the purpose of the above rule. However, with local policy, it + is within the right of a validator to refuse to trust certain zones + based on any criteria, including the use of unknown signing + algorithms. Because we are talking about experiments, it is RECOMMENDED that - private algorithm numbers be used (see [3], appendix A.1.1. Note - that secure handling of private algorithms requires special handing - by the validator logic. See [6] for further details.) Normally, - instead of actually inventing new signing algorithms, the recommended - path is to create alternate algorithm identifiers that are aliases - for the existing, known algorithms. While, strictly speaking, it is - only necessary to create an alternate identifier for the mandatory - algorithms, it is suggested that all optional defined algorithms be - aliased as well. + private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1. + Note that secure handling of private algorithms requires special + handing by the validator logic. See "Clarifications and + Implementation Notes for DNSSECbis" [6] for further details.) + Normally, instead of actually inventing new signing algorithms, the + recommended path is to create alternate algorithm identifiers that + are aliases for the existing, known algorithms. While, strictly + speaking, it is only necessary to create an alternate identifier for + the mandatory algorithms, it is suggested that all optional defined + algorithms be aliased as well. + + + +Blacka Standards Track [Page 3] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + It is RECOMMENDED that for a particular DNSSEC experiment, a particular domain name base is chosen for all new algorithms, then @@ -329,14 +179,6 @@ Internet-Draft DNSSEC Experiments April 2006 chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-experiment-a.example.com". However, any unique identifier - - - -Blacka Expires October 9, 2006 [Page 6] - -Internet-Draft DNSSEC Experiments April 2006 - - will suffice. Using this method, resolvers (or, more specifically, DNSSEC @@ -352,51 +194,13 @@ Internet-Draft DNSSEC Experiments April 2006 This method also precludes any zone from being both in an experiment and in a classic DNSSEC island of security. That is, a zone is - either in an experiment and only experimentally validatable, or it is - not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 7] - -Internet-Draft DNSSEC Experiments April 2006 - + either in an experiment and only possible to validate experimentally, + or it is not. 5. Defining an Experiment The DNSSEC experiment MUST define the particular set of (previously - unknown) algorithm identifiers that identify the experiment, and + unknown) algorithm identifiers that identify the experiment and define what each unknown algorithm identifier means. Typically, unless the experiment is actually experimenting with a new DNSSEC algorithm, this will be a mapping of private algorithm identifiers to @@ -407,9 +211,9 @@ Internet-Draft DNSSEC Experiments April 2006 authors of the experiment. Then the experiment will define a mapping between known mandatory and optional algorithms into this private algorithm identifier space. Alternately, the experiment MAY use the - OID private algorithm space instead (using algorithm number 254), or - MAY choose non-private algorithm numbers, although this would require - an IANA allocation. + Object Identifier (OID) private algorithm space instead (using + algorithm number 254), or MAY choose non-private algorithm numbers, + although this would require an IANA allocation. For example, an experiment might specify in its description the DNS name "dnssec-experiment-a.example.com" as the base name, and declare @@ -417,6 +221,13 @@ Internet-Draft DNSSEC Experiments April 2006 algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an alias of DNSSEC algorithm 5 (RSASHA1). + + +Blacka Standards Track [Page 4] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + Resolvers MUST only recognize the experiment's semantics when present in a zone signed by one or more of these algorithm identifiers. This is necessary to isolate the semantics of one experiment from any @@ -426,85 +237,21 @@ Internet-Draft DNSSEC Experiments April 2006 understand both standard DNSSEC and the defined experimental DNSSEC protocol, although this isn't required. - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 8] - -Internet-Draft DNSSEC Experiments April 2006 - - 6. Considerations There are a number of considerations with using this methodology. - 1. Under some circumstances, it may be that the experiment will not - be sufficiently masked by this technique and may cause resolution - problem for resolvers not aware of the experiment. For instance, - the resolver may look at a non-validatable response and conclude - that the response is bogus, either due to local policy or - implementation details. This is not expected to be a common - case, however. + 1. If an unaware validator does not correctly follow the rules laid + out in RFC 4035 (e.g., the validator interprets a DNSSEC record + prior to validating it), or if the experiment is broader in scope + that just modifying the DNSSEC semantics, the experiment may not + be sufficiently masked by this technique. This may cause + unintended resolution failures. 2. It will not be possible for security-aware resolvers unaware of the experiment to build a chain of trust through an experimental zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 9] - -Internet-Draft DNSSEC Experiments April 2006 - - 7. Use in Non-Experiments This general methodology MAY be used for non-backwards compatible @@ -519,48 +266,6 @@ Internet-Draft DNSSEC Experiments April 2006 o Resolvers MAY recognize the protocol change in zones not signed (or not solely signed) using the new algorithm identifiers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 10] - -Internet-Draft DNSSEC Experiments April 2006 - - 8. Security Considerations Zones using this methodology will be considered insecure by all @@ -568,114 +273,24 @@ Internet-Draft DNSSEC Experiments April 2006 possible to create a secure delegation from an experimental zone that will be followed by resolvers unaware of the experiment. + Implementers should take into account any security issues that may + result from environments being configured to trust both experimental + and non-experimental zones. If the experimental zone is more - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 11] +Blacka Standards Track [Page 5] -Internet-Draft DNSSEC Experiments April 2006 +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 -9. IANA Considerations + vulnerable to attacks, it could, for example, be used to promote + trust in zones not part of the experiment, possibly under the control + of an attacker. - This document has no IANA actions. +9. References - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 12] - -Internet-Draft DNSSEC Experiments April 2006 - - -10. References - -10.1. Normative References +9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -692,42 +307,13 @@ Internet-Draft DNSSEC Experiments April 2006 "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. -10.2. Informative References +9.2. Informative References [5] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. - [6] Austein, R. and S. Weiler, "Clarifications and Implementation - Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02 - (work in progress), January 2006. - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 13] - -Internet-Draft DNSSEC Experiments April 2006 - + [6] Weiler, S. and R. Austein, "Clarifications and Implementation + Notes for DNSSECbis", Work in Progress, March 2007. Author's Address @@ -738,7 +324,7 @@ Author's Address US Phone: +1 703 948 3200 - Email: davidb@verisign.com + EMail: davidb@verisign.com URI: http://www.verisignlabs.com @@ -749,45 +335,14 @@ Author's Address - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires October 9, 2006 [Page 14] +Blacka Standards Track [Page 6] -Internet-Draft DNSSEC Experiments April 2006 +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 Full Copyright Statement - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors @@ -795,13 +350,12 @@ Full Copyright Statement This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - Intellectual Property The IETF takes no position regarding the validity or scope of any @@ -826,15 +380,16 @@ Intellectual Property this standard. Please address the information to the IETF at ietf-ipr@ietf.org. +Acknowledgement -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). + Funding for the RFC Editor function is currently provided by the + Internet Society. -Blacka Expires October 9, 2006 [Page 15] + + +Blacka Standards Track [Page 7] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/doc/rfc/rfc4956.txt similarity index 59% rename from doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt rename to doc/rfc/rfc4956.txt index 17e28e8286..536c680cba 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt +++ b/doc/rfc/rfc4956.txt @@ -1,90 +1,89 @@ -DNSEXT R. Arends -Internet-Draft Telematica Instituut -Expires: January 19, 2006 M. Kosters + + + +Network Working Group R. Arends +Request for Comments: 4956 Nominet +Category: Experimental M. Kosters D. Blacka - Verisign, Inc. - July 18, 2005 + VeriSign, Inc. + July 2007 - DNSSEC Opt-In - draft-ietf-dnsext-dnssec-opt-in-07 + DNS Security (DNSSEC) Opt-In -Status of this Memo +Status of This Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 19, 2006. + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The IETF Trust (2007). Abstract - 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. + In the DNS security (DNSSEC) extensions, delegations to unsigned + subzones are cryptographically secured. Maintaining this + cryptography is not always 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. -Arends, et al. Expires January 19, 2006 [Page 1] + + + + + + + + + + + + + + + + + + + +Arends, et al. Experimental [Page 1] -Internet-Draft DNSSEC Opt-In July 2005 +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 Table of Contents - 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4 - 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4 - 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 5 - 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 5 - 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 6 - 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 6 - 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 7 - 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 7 - 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7 - 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 7 - 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 8 - 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 8 + 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Server Considerations . . . . . . . . . . . . . . . . . . 6 + 4.1.1. Delegations Only . . . . . . . . . . . . . . . . . . . 6 + 4.1.2. Insecure Delegation Responses . . . . . . . . . . . . 6 + 4.1.3. Dynamic Update . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Client Considerations . . . . . . . . . . . . . . . . . . 7 + 4.2.1. Delegations Only . . . . . . . . . . . . . . . . . . . 7 + 4.2.2. Validation Process Changes . . . . . . . . . . . . . . 7 + 4.2.3. NSEC Record Caching . . . . . . . . . . . . . . . . . 8 + 4.2.4. Use of the AD bit . . . . . . . . . . . . . . . . . . 8 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . 13 - 11.2 Informative References . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 - A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . 16 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. Implementing Opt-In Using "Views" . . . . . . . . . . 15 @@ -108,100 +107,131 @@ Table of Contents -Arends, et al. Expires January 19, 2006 [Page 2] + + + + +Arends, et al. Experimental [Page 2] -Internet-Draft DNSSEC Opt-In July 2005 +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 -1. Definitions and Terminology - - Throughout this document, familiarity with the DNS system (RFC 1035 - [1]), DNS security extensions ([3], [4], and [5], referred to in this - document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090 - [10]) is assumed. - - The following abbreviations and terms are used in this document: - - RR: is used to refer to a DNS resource record. - RRset: refers to a Resource Record Set, as defined by [8]. In this - document, the RRset is also defined to include the covering RRSIG - records, if any exist. - signed name: refers to a DNS name that has, at minimum, a (signed) - NSEC record. - unsigned name: refers to a DNS name that does not (at least) have a - NSEC record. - covering NSEC record/RRset: is the NSEC record used to prove - (non)existence of a particular name or RRset. This means that for - a RRset or name 'N', the covering NSEC record has the name 'N', or - has an owner name less than 'N' and "next" name greater than 'N'. - delegation: refers to a NS RRset with a name different from the - current zone apex (non-zone-apex), signifying a delegation to a - subzone. - secure delegation: refers to a signed name containing a delegation - (NS RRset), and a signed DS RRset, signifying a delegation to a - signed subzone. - insecure delegation: refers to a signed name containing a delegation - (NS RRset), but lacking a DS RRset, signifying a delegation to an - unsigned subzone. - Opt-In insecure delegation: refers to an unsigned name containing - only a delegation NS RRset. The covering NSEC record uses the - Opt-In methodology described 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 RFC 2119 [7]. - -2. Overview +1. Overview The cost to cryptographically secure delegations to unsigned zones is high for large delegation-centric zones and zones where insecure delegations will be updated rapidly. For these zones, the costs of - maintaining the NSEC record chain may be extremely high relative to - the gain of cryptographically authenticating existence of unsecured - zones. + maintaining the NextSECure (NSEC) record chain may be extremely high + relative to the gain of cryptographically authenticating existence of + unsecured zones. This document describes an experimental method of eliminating the - - - -Arends, et al. Expires January 19, 2006 [Page 3] - -Internet-Draft DNSSEC Opt-In July 2005 - - superfluous cryptography present in secure delegations to unsigned zones. Using "Opt-In", a zone administrator can choose to remove insecure delegations from the NSEC chain. This is accomplished by extending the semantics of the NSEC record by using a redundant bit in the type map. +2. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [1]), DNS security extensions ([4], [5], and [6], referred to in this + document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090 + [10]) is assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + + RRset: refers to a Resource Record Set, as defined by [8]. In this + document, the RRset is also defined to include the covering RRSIG + records, if any exist. + + signed name: refers to a DNS name that has, at minimum, a (signed) + NSEC record. + + unsigned name: refers to a DNS name that does not (at least) have an + NSEC record. + + covering NSEC record/RRset: is the NSEC record used to prove + (non)existence of a particular name or RRset. This means that for + a RRset or name 'N', the covering NSEC record has the name 'N', or + has an owner name less than 'N' and "next" name greater than 'N'. + + delegation: refers to an NS RRset with a name different from the + current zone apex (non-zone-apex), signifying a delegation to a + subzone. + + + + + + +Arends, et al. Experimental [Page 3] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + secure delegation: refers to a signed name containing a delegation + (NS RRset), and a signed DS RRset, signifying a delegation to a + signed subzone. + + insecure delegation: refers to a signed name containing a delegation + (NS RRset), but lacking a DS RRset, signifying a delegation to an + unsigned subzone. + + Opt-In insecure delegation: refers to an unsigned name containing + only a delegation NS RRset. The covering NSEC record uses the + Opt-In methodology described 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 RFC 2119 [2]. + 3. Experimental Status This document describes an EXPERIMENTAL extension to DNSSEC. It interoperates with non-experimental DNSSEC using the technique - described in [6]. This experiment is identified with the following + described in [7]. This experiment is identified with the following private algorithms (using algorithm 253): - "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, + "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, and - "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, + + "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, RSASHA1. Servers wishing to sign and serve zones that utilize Opt-In MUST sign - the zone with only one or more of these private algorithms. This - requires the signing tools and servers to support private algorithms, - as well as Opt-In. + the zone with only one or more of these private algorithms and MUST + NOT use any other algorithms. - Resolvers wishing to validate Opt-In zones MUST only do so when the - zone is only signed using one or more of these private algorithms. + Resolvers MUST NOT apply the Opt-In validation rules described in + this document unless a zone is signed using one or more of these + private algorithms. + + This experimental protocol relaxes the restriction that validators + MUST ignore the setting of the NSEC bit in the type map as specified + in RFC 4035 [6] Section 5.4. The remainder of this document assumes that the servers and resolvers involved are aware of and are involved in this experiment. + + + + + + + +Arends, et al. Experimental [Page 4] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + 4. Protocol Additions In DNSSEC, delegation NS RRsets are not signed, but are instead - accompanied by a NSEC RRset of the same name and (possibly) a DS + accompanied by an NSEC RRset of the same name and (possibly) a DS record. The security status of the subzone is determined by the presence or absence of the DS RRset, cryptographically proven by the NSEC record. Opt-In expands this definition by allowing insecure @@ -217,14 +247,6 @@ Internet-Draft DNSSEC Opt-In July 2005 delegation nodes. This tag is indicated by the absence of the NSEC bit in the type map. Since the NSEC bit in the type map merely indicates the existence of the record itself, this bit is redundant - - - -Arends, et al. Expires January 19, 2006 [Page 4] - -Internet-Draft DNSSEC Opt-In July 2005 - - and safe for use as a tag. An Opt-In tagged NSEC record does not assert the (non)existence of @@ -236,11 +258,11 @@ Internet-Draft DNSSEC Opt-In July 2005 An Opt-In NSEC record MAY have the same name as an insecure delegation. In this case, the delegation is proven insecure by the - lack of a DS bit in type map and the signed NSEC record does assert - the existence of the delegation. + lack of a DS bit in the type map, and the signed NSEC record does + assert the existence of the delegation. Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC - records and standard DNSSEC NSEC records. If a NSEC record is not + records and standard DNSSEC NSEC records. If an NSEC record is not Opt-In, there MUST NOT be any insecure delegations (or any other records) between it and the RRsets indicated by the 'next domain name' in the NSEC RDATA. If it is Opt-In, there MUST only be @@ -251,39 +273,43 @@ Internet-Draft DNSSEC Opt-In July 2005 o An Opt-In NSEC type is identified by a zero-valued (or not- specified) NSEC bit in the type bit map of the NSEC record. - o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in - the type bit map of the NSEC record. - and, + + + + + +Arends, et al. Experimental [Page 5] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + o A standard DNSSEC NSEC type is identified by a one-valued NSEC bit + in the type bit map of the NSEC record. + + and o An Opt-In NSEC record does not assert the non-existence of a name between its owner name and "next" name, although it does assert that any name in this span MUST be an insecure delegation. + o An Opt-In NSEC record does assert the (non)existence of RRsets with the same owner name. -4.1 Server Considerations +4.1. Server Considerations Opt-In imposes some new requirements on authoritative DNS servers. -4.1.1 Delegations Only +4.1.1. Delegations Only This specification dictates that only insecure delegations may exist between the owner and "next" names of an Opt-In tagged NSEC record. - Signing tools SHOULD NOT generate signed zones that violate this - restriction. Servers SHOULD refuse to load and/or serve zones that - violate this restriction. Servers also SHOULD reject AXFR or IXFR - - - -Arends, et al. Expires January 19, 2006 [Page 5] - -Internet-Draft DNSSEC Opt-In July 2005 - - + Signing tools MUST NOT generate signed zones that violate this + restriction. Servers MUST refuse to load and/or serve zones that + violate this restriction. Servers also MUST reject AXFR or IXFR responses that violate this restriction. -4.1.2 Insecure Delegation Responses +4.1.2. Insecure Delegation Responses When returning an Opt-In insecure delegation, the server MUST return the covering NSEC RRset in the Authority section. @@ -294,54 +320,7 @@ Internet-Draft DNSSEC Opt-In July 2005 different owner name from the delegation RRset. This may require implementations to search for the covering NSEC RRset. -4.1.3 Wildcards and Opt-In - - Standard DNSSEC describes the practice of returning NSEC records to - prove the non-existence of an applicable wildcard in non-existent - name responses. This NSEC record can be described as a "negative - wildcard proof". The use of Opt-In NSEC records changes the - necessity for this practice. For non-existent name responses when - the query name (qname) is covered by an Opt-In tagged NSEC record, - servers MAY choose to omit the wildcard proof record, and clients - MUST NOT treat the absence of this NSEC record as a validation error. - - The intent of the standard DNSSEC negative wildcard proof requirement - is to prevent malicious users from undetectably removing valid - wildcard responses. In order for this cryptographic proof to work, - the resolver must be able to prove: - - 1. The exact qname does not exist. This is done by the "normal" - NSEC record. - 2. No applicable wildcard exists. This is done by returning a NSEC - record proving that the wildcard does not exist (this is the - negative wildcard proof). - - However, if the NSEC record covering the exact qname is an Opt-In - NSEC record, the resolver will not be able to prove the first part of - this equation, as the qname might exist as an insecure delegation. - Thus, since the total proof cannot be completed, the negative - wildcard proof NSEC record is not useful. - - The negative wildcard proof is also not useful when returned as part - of an Opt-In insecure delegation response for a similar reason: the - resolver cannot prove that the qname does or does not exist, and - therefore cannot prove that a wildcard expansion is valid. - - The presence of an Opt-In tagged NSEC record does not change the - practice of returning a NSEC along with a wildcard expansion. Even - - - -Arends, et al. Expires January 19, 2006 [Page 6] - -Internet-Draft DNSSEC Opt-In July 2005 - - - though the Opt-In NSEC will not be able to prove that the wildcard - expansion is valid, it will prove that the wildcard expansion is not - masking any signed records. - -4.1.4 Dynamic Update +4.1.3. Dynamic Update Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In particular, it introduces the need for rules that describe when to @@ -351,23 +330,36 @@ Internet-Draft DNSSEC Opt-In July 2005 zones that use Opt-In NSEC records. Servers SHOULD return responses to update requests with RCODE=REFUSED. -4.2 Client Considerations + + + + + +Arends, et al. Experimental [Page 6] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + +4.2. Client Considerations Opt-In imposes some new requirements on security-aware resolvers (caching or otherwise). -4.2.1 Delegations Only +4.2.1. Delegations Only - As stated in the "Server Considerations" section above, this - specification restricts the namespace covered by Opt-In tagged NSEC - records to insecure delegations only. Thus, resolvers MUST reject as - invalid any records that fall within an Opt-In NSEC record's span - that are not NS records or corresponding glue records. + As stated in Section 4.1 above, this specification restricts the + namespace covered by Opt-In tagged NSEC records to insecure + delegations only. Clients are not expected to take any special + measures to enforce this restriction; instead, it forms an underlying + assumption that clients may rely on. -4.2.2 Validation Process Changes +4.2.2. Validation Process Changes This specification does not change the resolver's resolution algorithm. However, it does change the DNSSEC validation process. + +4.2.2.1. Referrals + Resolvers MUST be able to use Opt-In tagged NSEC records to cryptographically prove the validity and security status (as insecure) of a referral. Resolvers determine the security status of @@ -379,31 +371,39 @@ Internet-Draft DNSSEC Opt-In July 2005 signed. The absence of the DS RRset is proven using a verified NSEC record of the same name that does not have the DS bit set in the type map. This NSEC record MAY also be tagged as Opt-In. + o Using Opt-In, the security status is proven by the existence of a DS record (for signed) or the presence of a verified Opt-In tagged NSEC record that covers the delegation name. That is, the NSEC record does not have the NSEC bit set in the type map, and the delegation name falls between the NSEC's owner and "next" name. - - - -Arends, et al. Expires January 19, 2006 [Page 7] - -Internet-Draft DNSSEC Opt-In July 2005 - - Using Opt-In does not substantially change the nature of following referrals within DNSSEC. At every delegation point, the resolver will have cryptographic proof that the referred-to subzone is signed or unsigned. - When receiving either an Opt-In insecure delegation response or a - non-existent name response where that name is covered by an Opt-In - tagged NSEC record, the resolver MUST NOT require proof (in the form - of a NSEC record) that a wildcard did not exist. +4.2.2.2. Queries for DS Resource Records -4.2.3 NSEC Record Caching + Since queries for DS records are directed to the parent side of a + zone cut (see [5], Section 5), negative responses to these queries + may be covered by an Opt-In flagged NSEC record. + + + +Arends, et al. Experimental [Page 7] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + Resolvers MUST be able to use Opt-In tagged NSEC records to + cryptographically prove the validity and security status of negative + responses to queries for DS records. In particular, a NOERROR/NODATA + (i.e., RCODE=3, but the answer section is empty) response to a DS + query may be proven by an Opt-In flagged covering NSEC record, rather + than an NSEC record matching the query name. + +4.2.3. NSEC Record Caching Caching resolvers MUST be able to retrieve the appropriate covering Opt-In NSEC record when returning referrals that need them. This @@ -412,16 +412,21 @@ Internet-Draft DNSSEC Opt-In July 2005 implementations may have to use new methods for finding these NSEC records. -4.2.4 Use of the AD bit +4.2.4. Use of the AD bit - The AD bit, as defined by [2] and [5], MUST NOT be set when: + The AD bit, as defined by [3] and [6], MUST NOT be set when: o sending a Name Error (RCODE=3) response where the covering NSEC is tagged as Opt-In. + o sending an Opt-In insecure delegation response, unless the covering (Opt-In) NSEC record's owner name equals the delegation name. + o sending a NOERROR/NODATA response when query type is DS and the + covering NSEC is tagged as Opt-In, unless NSEC record's owner name + matches the query name. + This rule is based on what the Opt-In NSEC record actually proves: for names that exist between the Opt-In NSEC record's owner and "next" names, the Opt-In NSEC record cannot prove the non-existence @@ -439,21 +444,22 @@ Internet-Draft DNSSEC Opt-In July 2005 delegations to unsigned subzones, can lead to substantial space savings (both in memory and on disk). Additionally, Opt-In allows for the addition or removal of insecure delegations without modifying - the NSEC record chain. Zones that are frequently updating insecure - delegations (e.g., TLDs) can avoid the substantial overhead of -Arends, et al. Expires January 19, 2006 [Page 8] +Arends, et al. Experimental [Page 8] -Internet-Draft DNSSEC Opt-In July 2005 +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 - modifying and resigning the affected NSEC records. + the NSEC record chain. Zones that are frequently updating insecure + delegations (e.g., Top-Level Domains (TLDs)) can avoid the + substantial overhead of modifying and resigning the affected NSEC + records. 6. Example - Consider the zone EXAMPLE, shown below. This is a zone where all of + Consider the zone EXAMPLE shown below. This is a zone where all of the NSEC records are tagged as Opt-In. Example A: Fully Opt-In Zone. @@ -490,22 +496,27 @@ Internet-Draft DNSSEC Opt-In July 2005 NS.UNSIGNED.EXAMPLE. A ... + Example A. + + + + + + +Arends, et al. Experimental [Page 9] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + In this example, a query for a signed RRset (e.g., "FIRST- - SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- - SECURE.EXAMPLE A") will result in a standard DNSSEC response. + SECURE.EXAMPLE A") or a secure delegation ("WWW.SECOND-SECURE.EXAMPLE + A") will result in a standard DNSSEC response. A query for a nonexistent RRset will result in a response that - differs from standard DNSSEC by: the NSEC record will be tagged as - Opt-In, there may be no NSEC record proving the non-existence of a - - - -Arends, et al. Expires January 19, 2006 [Page 9] - -Internet-Draft DNSSEC Opt-In July 2005 - - - matching wildcard record, and the AD bit will not be set. + differs from standard DNSSEC by the following: the NSEC record will + be tagged as Opt-In, there may be no NSEC record proving the non- + existence of a matching wildcard record, and the AD bit will not be + set. A query for an insecure delegation RRset (or a referral) will return both the answer (in the Authority section) and the corresponding @@ -526,6 +537,8 @@ Internet-Draft DNSSEC Opt-In July 2005 Additional Section: NS.UNSIGNED.EXAMPLE. A ... + Example A.1 + In the Example A.1 zone, the EXAMPLE. node MAY use either style of NSEC record, because there are no insecure delegations that occur between it and the next node, FIRST-SECURE.EXAMPLE. In other words, @@ -543,6 +556,14 @@ Internet-Draft DNSSEC Opt-In July 2005 NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is part of the NSEC chain and also covered by an Opt-In tagged NSEC record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be + + + +Arends, et al. Experimental [Page 10] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + removed from the zone without modifying and resigning the prior NSEC record. Delegations with names that fall between NOT-SECURE- 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without @@ -551,16 +572,8 @@ Internet-Draft DNSSEC Opt-In July 2005 7. Transition Issues Opt-In is not backwards compatible with standard DNSSEC and is - considered experimental. Standard DNSSEC compliant implementations + considered experimental. Standard DNSSEC-compliant implementations would not recognize Opt-In tagged NSEC records as different from - - - -Arends, et al. Expires January 19, 2006 [Page 10] - -Internet-Draft DNSSEC Opt-In July 2005 - - standard NSEC records. Because of this, standard DNSSEC implementations, if they were to validate Opt-In style responses, would reject all Opt-In insecure delegations within a zone as @@ -579,15 +592,16 @@ Internet-Draft DNSSEC Opt-In July 2005 Opt-In allows for unsigned names, in the form of delegations to unsigned subzones, to exist within an otherwise signed zone. All unsigned names are, by definition, insecure, and their validity or - existence cannot by cryptographically proven. + existence cannot be cryptographically proven. In general: - o Records with unsigned names (whether existing or not) suffer from + o Records with unsigned names (whether or not existing) suffer from the same vulnerabilities as records in an unsigned zone. These vulnerabilities are described in more detail in [12] (note in - particular sections 2.3, "Name Games" and 2.6, "Authenticated + particular Sections 2.3, "Name Games" and 2.6, "Authenticated Denial"). + o Records with signed names have the same security whether or not Opt-In is used. @@ -597,26 +611,25 @@ Internet-Draft DNSSEC Opt-In July 2005 the ability to prove the existence or nonexistence of an insecure delegation within the span of an Opt-In NSEC record. + + + + +Arends, et al. Experimental [Page 11] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + In particular, this means that a malicious entity may be able to insert or delete records with unsigned names. These records are normally NS records, but this also includes signed wildcard expansions (while the wildcard record itself is signed, its expanded - name is an unsigned name). + name is an unsigned name), which can be undetectably removed or used + to replace an existing unsigned delegation. For example, if a resolver received the following response from the example zone above: - - - - - - -Arends, et al. Expires January 19, 2006 [Page 11] - -Internet-Draft DNSSEC Opt-In July 2005 - - Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A RCODE=NOERROR @@ -632,6 +645,8 @@ Internet-Draft DNSSEC Opt-In July 2005 Additional Section: + Attacker has forged a name + The resolver would have no choice but to believe that the referral to NS.FORGED. is valid. If a wildcard existed that would have been expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could @@ -640,77 +655,83 @@ Internet-Draft DNSSEC Opt-In July 2005 Note that being able to add a delegation is functionally equivalent to being able to add any record type: an attacker merely has to forge - a delegation to nameserver under his/her control and place whatever - records needed at the subzone apex. + a delegation to the nameserver under his/her control and place + whatever records are needed at the subzone apex. While in particular cases, this issue may not present a significant security problem, in general it should not be lightly dismissed. Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. In particular, zone signing tools SHOULD NOT default to Opt-In, and - MAY choose to not support Opt-In at all. - -9. IANA Considerations - - None. - -10. Acknowledgments - - The contributions, suggestions and remarks of the following persons - (in alphabetic order) to this draft are acknowledged: - - Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf - Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning, - Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian - Wellington. - -11. References + MAY choose not to support Opt-In at all. -Arends, et al. Expires January 19, 2006 [Page 12] + + + + +Arends, et al. Experimental [Page 12] -Internet-Draft DNSSEC Opt-In July 2005 +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 -11.1 Normative References +9. Acknowledgments - [1] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. + The contributions, suggestions, and remarks of the following persons + (in alphabetic order) to this document are acknowledged: - [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. + Mats Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill + Manning, Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, + Brian Wellington. - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. +10. References - [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. +10.1. Normative References - [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. - [6] Blacka, D., "DNSSEC Experiments", - draft-ietf-dnsext-dnssec-experiments-01 (work in progress), - July 2005. - -11.2 Informative References - - [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + [3] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [7] Blacka, D., "DNSSEC Experiments", RFC 4955, July 2007. + +10.2. Informative References + [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. - [9] Eastlake, D., "Secure Domain Name System Dynamic Update", - RFC 2137, April 1997. + [9] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. [10] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001. + + + + +Arends, et al. Experimental [Page 13] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. @@ -724,44 +745,50 @@ Internet-Draft DNSSEC Opt-In July 2005 -Arends, et al. Expires January 19, 2006 [Page 13] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Experimental [Page 14] -Internet-Draft DNSSEC Opt-In July 2005 +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - Email: roy.arends@telin.nl - - - Mark Kosters - Verisign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - Email: markk@verisign.com - URI: http://www.verisignlabs.com - - - David Blacka - Verisign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - Email: davidb@verisign.com - URI: http://www.verisignlabs.com - -Appendix A. Implementing Opt-In using "Views" +Appendix A. Implementing Opt-In Using "Views" In many cases, it may be convenient to implement an Opt-In zone by combining two separately maintained "views" of a zone at request @@ -777,41 +804,87 @@ Appendix A. Implementing Opt-In using "Views" In addition, the only RRsets that may solely exist in the insecure view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and - - - -Arends, et al. Expires January 19, 2006 [Page 14] - -Internet-Draft DNSSEC Opt-In July 2005 - - the zone apex NS RRset) MUST be signed and in the secure view. These two views may be combined at request time to provide a virtual, single Opt-In zone. The following algorithm is used when responding to each query: + V_A is the secure view as described above. + V_B is the insecure view as described above. - R_A is a response generated from V_A, following RFC 2535bis. + + R_A is a response generated from V_A, following standard DNSSEC. + R_B is a response generated from V_B, following DNS resolution as per RFC 1035 [1]. + R_C is the response generated by combining R_A with R_B, as described below. - A query is DNSSEC-aware if it either has the DO bit [11] turned - on, or is for a DNSSEC-specific record type. - + A query is DNSSEC-aware if it either has the DO bit [11] turned on + or is for a DNSSEC-specific record type. 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, generate and return R_B, otherwise + 2. Generate R_A. + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + + + + + + + + +Arends, et al. Experimental [Page 15] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + 4. Generate R_B and combine it with R_A to form R_C: + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the records from R_A into R_B, EXCEPT the AUTHORITY section SOA record, if R_B's RCODE = NOERROR. + 5. Return R_C. +Authors' Addresses + + Roy Arends + Nominet + Sandford Gate + Sandy Lane West + Oxford OX4 6LB + UNITED KINGDOM + + Phone: +44 1865 332211 + EMail: roy@nominet.org.uk + + + Mark Kosters + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: mkosters@verisign.com + URI: http://www.verisignlabs.com + + + David Blacka + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com @@ -822,26 +895,28 @@ Internet-Draft DNSSEC Opt-In July 2005 - - - - - - - - - - - - - - -Arends, et al. Expires January 19, 2006 [Page 15] +Arends, et al. Experimental [Page 16] -Internet-Draft DNSSEC Opt-In July 2005 +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -865,26 +940,7 @@ Intellectual Property Statement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment +Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. @@ -892,5 +948,8 @@ Acknowledgment -Arends, et al. Expires January 19, 2006 [Page 16] + + + +Arends, et al. Experimental [Page 17] diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/rfc/rfc5001.txt similarity index 68% rename from doc/draft/draft-ietf-dnsext-nsid-01.txt rename to doc/rfc/rfc5001.txt index 90d1a0609d..fe15339369 100644 --- a/doc/draft/draft-ietf-dnsext-nsid-01.txt +++ b/doc/rfc/rfc5001.txt @@ -1,42 +1,27 @@ + + + Network Working Group R. Austein -Internet-Draft ISC -Expires: July 15, 2006 January 11, 2006 +Request for Comments: 5001 ISC +Category: Standards Track August 2007 - DNS Name Server Identifier Option (NSID) - draft-ietf-dnsext-nsid-01 + DNS Name Server Identifier (NSID) Option -Status of this Memo +Status of This Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 15, 2006. + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract @@ -44,74 +29,57 @@ Abstract mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc - mechanism allow an operator to send follow-up queries when it is + mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable - way to obtain the identity of the name server which responded is to + way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. -Austein Expires July 15, 2006 [Page 1] + + + + + + + + + + + + + + + + + + +Austein Standards Track [Page 1] -Internet-Draft DNS NSID January 2006 +RFC 5001 DNS NSID August 2007 Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4 + 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 3 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 - 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5 - 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8 - 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8 - 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 2] - -Internet-Draft DNS NSID January 2006 - + 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 4 + 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 7 + 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 7 + 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 1. Introduction @@ -131,10 +99,22 @@ Internet-Draft DNS NSID January 2006 Given that a DNS query is an idempotent operation with no retained state, it would appear that the only completely reliable way to - obtain the identity of the name server which responded to a - particular query is to have that name server include identifying - information in the response itself. This note defines a protocol - enhancement to achieve this. + obtain the identity of the name server that responded to a particular + query is to have that name server include identifying information in + the response itself. This note defines a protocol enhancement to + achieve this. + + + + + + + + +Austein Standards Track [Page 2] + +RFC 5001 DNS NSID August 2007 + 1.1. Reserved Words @@ -142,33 +122,6 @@ Internet-Draft DNS NSID January 2006 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 3] - -Internet-Draft DNS NSID January 2006 - - 2. Protocol This note uses an EDNS [RFC2671] option to signal the resolver's @@ -195,10 +148,10 @@ Internet-Draft DNS NSID January 2006 2.2. Name Server Behavior - A name server which understands the NSID option and chooses to honor - a particular NSID request responds by including identifying - information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR - in the response message. + A name server that understands the NSID option and chooses to honor a + particular NSID request responds by including identifying information + in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the + response message. The name server MUST ignore any NSID payload data that might be present in the query message. @@ -210,29 +163,31 @@ Internet-Draft DNS NSID January 2006 absence of the NSID option in the recursive name server's response to the original client. + + + + +Austein Standards Track [Page 3] + +RFC 5001 DNS NSID August 2007 + + As stated in Section 2.1, this mechanism is not restricted to authoritative name servers; the semantics are intended to be equally applicable to recursive name servers. 2.3. The NSID Option - The OPTION-CODE for the NSID option is [TBD]. + The OPTION-CODE for the NSID option is 3. - - -Austein Expires July 15, 2006 [Page 4] - -Internet-Draft DNS NSID January 2006 - - - The OPTION-DATA for the NSID option is an opaque byte string the + The OPTION-DATA for the NSID option is an opaque byte string, the semantics of which are deliberately left outside the protocol. See Section 3.1 for discussion. 2.4. Presentation Format - User interfaces MUST read and write the content of the NSID option as - a sequence of hexadecimal digits, two digits per payload octet. + User interfaces MUST read and write the contents of the NSID option + as a sequence of hexadecimal digits, two digits per payload octet. The NSID payload is binary data. Any comparison between NSID payloads MUST be a comparison of the raw binary data. Copy @@ -243,44 +198,6 @@ Internet-Draft DNS NSID January 2006 See Section 3.3 for discussion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 5] - -Internet-Draft DNS NSID January 2006 - - 3. Discussion This section discusses certain aspects of the protocol and explains @@ -288,11 +205,28 @@ Internet-Draft DNS NSID January 2006 3.1. The NSID Payload - The syntax and semantics of the content of the NSID option is - deliberately left outside the scope of this specification. This - section describe some of the kinds of data that server administrators - might choose to provide as the content of the NSID option, and - explains the reasoning behind choosing a simple opaque byte string. + The syntax and semantics of the content of the NSID option are + deliberately left outside the scope of this specification. + + Choosing the NSID content is a prerogative of the server + administrator. The server administrator might choose to encode the + NSID content in such a way that the server operator (or clients + authorized by the server operator) can decode the NSID content to + obtain more information than other clients can. Alternatively, the + server operator might choose unencoded NSID content that is equally + meaningful to any client. + + This section describes some of the kinds of data that server + administrators might choose to provide as the content of the NSID + option, and explains the reasoning behind specifying a simple opaque + byte string in Section 2.3. + + + +Austein Standards Track [Page 4] + +RFC 5001 DNS NSID August 2007 + There are several possibilities for the payload of the NSID option: @@ -306,11 +240,11 @@ Internet-Draft DNS NSID January 2006 predictable fashion somehow using the server's IP address or name as a seed value. - o It could be some sort of probabilisticly unique identifier + o It could be some sort of probabilistically unique identifier initially derived from some sort of random number generator then preserved across reboots of the name server. - o It could be some sort of dynamicly generated identifier so that + o It could be some sort of dynamically generated identifier so that only the name server operator could tell whether or not any two queries had been answered by the same server. @@ -329,14 +263,6 @@ Internet-Draft DNS NSID January 2006 o Using the "real" name is simple, but the name server may not have a "real" name. - - - -Austein Expires July 15, 2006 [Page 6] - -Internet-Draft DNS NSID January 2006 - - o Using the "real" address is also simple, and the name server almost certainly does have at least one non-anycast IP address for maintenance operations, but the operator of the name server may @@ -350,6 +276,14 @@ Internet-Draft DNS NSID January 2006 o Using a hash or pseudo-random number can provide a fixed length value that the resolver can use to tell two name servers apart + + + +Austein Standards Track [Page 5] + +RFC 5001 DNS NSID August 2007 + + without necessarily being able to tell where either one of them "really" is, but makes debugging more difficult if one happens to be in a friendly open environment. Furthermore, hashing might not @@ -358,43 +292,59 @@ Internet-Draft DNS NSID January 2006 that operators might have to debug at 4am tend not to be very random. - o Probabilisticly unique identifiers have similar properties to + o Probabilistically unique identifiers have properties similar to hashed identifiers, but (given a sufficiently good random number generator) are immune to the search space issues. However, the strength of this approach is also its weakness: there is no algorithmic transformation by which even the server operator can associate name server instances with identifiers while debugging, which might be annoying. This approach also requires the name - server instance to preserve the probabilisticly unique identifier - across reboots, but this does not appear to be a serious - restriction, since authoritative nameservers almost always have - some form of nonvolatile storage in any case, and in the rare case - of a name server that does not have any way to store such an - identifier, nothing terrible will happen if the name server just + server instance to preserve the probabilistically unique + identifier across reboots, but this does not appear to be a + serious restriction, since authoritative nameservers almost always + have some form of non-volatile storage. In the rare case of a + name server that does not have any way to store such an + identifier, nothing terrible will happen if the name server generates a new identifier every time it reboots. o Using an arbitrary octet string gives name server operators yet - another thing to configure, or mis-configure, or forget to + another setting to configure, or mis-configure, or forget to configure. Having all the nodes in an anycast name server constellation identify themselves as "My Name Server" would not be particularly useful. + o A signed blob is not particularly useful as an NSID payload unless + the signed data is dynamic and includes some kind of replay + protection, such as a timestamp or some kind of data identifying + the requestor. Signed blobs that meet these criteria could + conceivably be useful in some situations but would require + detailed security analysis beyond the scope of this document. + + o A static encrypted blob would not be particularly useful, as it + would be subject to replay attacks and would, in effect, just be a + random number to any party that does not possess the decryption + key. Dynamic encrypted blobs could conceivably be useful in some + situations but, as with signed blobs, dynamic encrypted blobs + would require detailed security analysis beyond the scope of this + document. + Given all of the issues listed above, there does not appear to be a single solution that will meet all needs. Section 2.3 therefore defines the NSID payload to be an opaque byte string and leaves the - choice up to the implementor and name server operator. The following - guidelines may be useful to implementors and server operators: + choice of payload up to the implementor and name server operator. - -Austein Expires July 15, 2006 [Page 7] +Austein Standards Track [Page 6] -Internet-Draft DNS NSID January 2006 +RFC 5001 DNS NSID August 2007 + The following guidelines may be useful to implementors and server + operators: + o Operators for whom divulging the unicast address is an issue could - use the raw binary representation of a probabilisticly unique + use the raw binary representation of a probabilistically unique random number. This should probably be the default implementation behavior. @@ -438,17 +388,17 @@ Internet-Draft DNS NSID January 2006 Given the range of possible payload contents described in Section 3.1, it is not possible to define a single presentation format for the NSID payload that is efficient, convenient, + + + +Austein Standards Track [Page 7] + +RFC 5001 DNS NSID August 2007 + + unambiguous, and aesthetically pleasing. In particular, while it is tempting to use a presentation format that uses some form of textual strings, attempting to support this would significantly complicate - - - -Austein Expires July 15, 2006 [Page 8] - -Internet-Draft DNS NSID January 2006 - - what's intended to be a very simple debugging mechanism. In some cases the content of the NSID payload may be binary data @@ -468,7 +418,7 @@ Internet-Draft DNS NSID January 2006 It is much more important for the NSID payload data to be passed unambiguously from server administrator to user and back again than - it is for the payload data data to be pretty while in transit. In + it is for the payload data to be pretty while in transit. In particular, it's critical that it be straightforward for a user to cut and paste an exact copy of the NSID payload output by a debugging tool into other formats such as email messages or web forms without @@ -490,82 +440,23 @@ Internet-Draft DNS NSID January 2006 "sender's UDP payload size" field of the OPT pseudo-RR to signal a receive buffer size large enough to make truncation unlikely. - - - - - - - - - - -Austein Expires July 15, 2006 [Page 9] - -Internet-Draft DNS NSID January 2006 - - 4. IANA Considerations - This mechanism requires allocation of one ENDS option code for the - NSID option (Section 2.3). + IANA has allocated EDNS option code 3 for the NSID option + (Section 2.3). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 10] +Austein Standards Track [Page 8] -Internet-Draft DNS NSID January 2006 +RFC 5001 DNS NSID August 2007 5. Security Considerations - This document describes a channel signaling mechanism, intended + This document describes a channel signaling mechanism intended primarily for debugging. Channel signaling mechanisms are outside - the scope of DNSSEC per se. Applications that require integrity + the scope of DNSSEC, per se. Applications that require integrity protection for the data being signaled will need to use a channel security mechanism such as TSIG [RFC2845]. @@ -576,102 +467,26 @@ Internet-Draft DNS NSID January 2006 leaves the syntax and semantics of the NSID option content up to the implementation and the name server operator. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 11] - -Internet-Draft DNS NSID January 2006 - + Two of the possible kinds of payload data discussed in Section 3.1 + involve a digital signature and encryption, respectively. While this + specification discusses some of the pitfalls that might lurk for + careless users of these kinds of payload data, full analysis of the + issues that would be involved in these kinds of payload data would + require knowledge of the content to be signed or encrypted, + algorithms to be used, and so forth, which is beyond the scope of + this document. Implementors should seek competent advice before + attempting to use these kinds of NSID payloads. 6. Acknowledgements - Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve - Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg, - Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and - Suzanne Woolf. Apologies to anyone inadvertently omitted from the - above list. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 12] - -Internet-Draft DNS NSID January 2006 - + Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews, + Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad, + John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter + Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey + Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam + Weiler, and Suzanne Woolf, none of whom are responsible for what the + author did with their comments and suggestions. Apologies to anyone + inadvertently omitted from the above list. 7. References @@ -683,6 +498,16 @@ Internet-Draft DNS NSID January 2006 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. + + + + + +Austein Standards Track [Page 9] + +RFC 5001 DNS NSID August 2007 + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. @@ -692,43 +517,6 @@ Internet-Draft DNS NSID January 2006 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, BCP 18, January 1998. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 13] - -Internet-Draft DNS NSID January 2006 - - Author's Address Rob Austein @@ -737,7 +525,7 @@ Author's Address Redwood City, CA 94063 USA - Email: sra@isc.org + EMail: sra@isc.org @@ -771,21 +559,28 @@ Author's Address - - - - - - - - - -Austein Expires July 15, 2006 [Page 14] +Austein Standards Track [Page 10] -Internet-Draft DNS NSID January 2006 +RFC 5001 DNS NSID August 2007 -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -809,26 +604,7 @@ Intellectual Property Statement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment +Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. @@ -836,5 +612,8 @@ Acknowledgment -Austein Expires July 15, 2006 [Page 15] + + + +Austein Standards Track [Page 11] diff --git a/doc/rfc/rfc5452.txt b/doc/rfc/rfc5452.txt new file mode 100644 index 0000000000..6f59bf57ac --- /dev/null +++ b/doc/rfc/rfc5452.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group A. Hubert +Request for Comments: 5452 Netherlabs Computer Consulting BV. +Updates: 2181 R. van Mook +Category: Standards Track Equinix + January 2009 + + + Measures for Making DNS More Resilient against Forged Answers + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + The current Internet climate poses serious threats to the Domain Name + System. In the interim period before the DNS protocol can be secured + more fully, measures can already be taken to harden the DNS to make + 'spoofing' a recursing nameserver many orders of magnitude harder. + + Even a cryptographically secured DNS benefits from having the ability + to discard bogus responses quickly, as this potentially saves large + amounts of computation. + + By describing certain behavior that has previously not been + standardized, this document sets out how to make the DNS more + resilient against accepting incorrect responses. This document + updates RFC 2181. + + + + + + + + +Hubert & van Mook Standards Track [Page 1] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements and Definitions . . . . . . . . . . . . . . . . . 4 + 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Description of DNS Spoofing . . . . . . . . . . . . . . . . . 5 + 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 6 + 4.1. Forcing a Query . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Matching the Question Section . . . . . . . . . . . . . . 7 + 4.3. Matching the ID Field . . . . . . . . . . . . . . . . . . 7 + 4.4. Matching the Source Address of the Authentic Response . . 7 + 4.5. Matching the Destination Address and Port of the + Authentic Response . . . . . . . . . . . . . . . . . . . . 8 + 4.6. Have the Response Arrive before the Authentic Response . . 8 + 5. Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Accepting Only In-Domain Records . . . . . . . . . . . . . . . 9 + 7. Combined Difficulty . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Symbols Used in Calculation . . . . . . . . . . . . . . . 10 + 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Repetitive Spoofing Attempts for a Single Domain Name . . 13 + 9. Forgery Countermeasures . . . . . . . . . . . . . . . . . . . 13 + 9.1. Query Matching Rules . . . . . . . . . . . . . . . . . . . 13 + 9.2. Extending the Q-ID Space by Using Ports and Addresses . . 14 + 9.2.1. Justification and Discussion . . . . . . . . . . . . . 14 + 9.3. Spoof Detection and Countermeasure . . . . . . . . . . . . 15 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 + + + + + + + + + + + + + + + + + + + +Hubert & van Mook Standards Track [Page 2] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +1. Introduction + + This document describes several common problems in DNS + implementations, which, although previously recognized, remain + largely unsolved. Besides briefly recapping these problems, this + document contains rules that, if implemented, make complying + resolvers vastly more resistant to the attacks described. The goal + is to make the existing DNS as secure as possible within the current + protocol boundaries. + + The words below are aimed at authors of resolvers: it is up to + operators to decide which nameserver implementation to use, or which + options to enable. Operational constraints may override the security + concerns described below. However, implementations are expected to + allow an operator to enable functionality described in this document. + + Almost every transaction on the Internet involves the Domain Name + System, which is described in [RFC1034], [RFC1035], and beyond. + + Additionally, it has recently become possible to acquire Secure + Socket Layer/Transport Layer Security (SSL/TLS) certificates with no + other confirmation of identity than the ability to respond to a + verification email sent via SMTP ([RFC5321]) -- which generally uses + DNS for its routing. + + In other words, any party that (temporarily) controls the Domain Name + System is in a position to reroute most kinds of Internet + transactions, including the verification steps in acquiring an SSL/ + TLS certificate for a domain. This in turn means that even + transactions protected by SSL/TLS could be diverted. + + It is entirely conceivable that such rerouted traffic could be used + to the disadvantage of Internet users. + + These and other developments have made the security and + trustworthiness of DNS of renewed importance. Although the DNS + community is working hard on finalizing and implementing a + cryptographically enhanced DNS protocol, steps should be taken to + make sure that the existing use of DNS is as secure as possible + within the bounds of the relevant standards. + + It should be noted that the most commonly used resolvers currently do + not perform as well as possible in this respect, making this document + of urgent importance. + + A thorough analysis of risks facing DNS can be found in [RFC3833]. + + + + + +Hubert & van Mook Standards Track [Page 3] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + This document expands on some of the risks mentioned in RFC 3833, + especially those outlined in the sections on "ID Guessing and Query + Prediction" and "Name Chaining". Furthermore, it emphasizes a number + of existing rules and guidelines embodied in the relevant DNS + protocol specifications. The following also specifies new + requirements to make sure the Domain Name System can be relied upon + until a more secure protocol has been standardized and deployed. + + It should be noted that even when all measures suggested below are + implemented, protocol users are not protected against third parties + with the ability to observe, modify, or inject packets in the traffic + of a resolver. + + For protocol extensions that offer protection against these + scenarios, see [RFC4033] and beyond. + +2. Requirements and Definitions + +2.1. Definitions + + This document uses the following definitions: + + Client: typically a 'stub-resolver' on an end-user's computer. + + Resolver: a nameserver performing recursive service for clients, + also known as a caching server, or a full service resolver + ([RFC1123], Section 6.1.3.1). + + Stub resolver: a very limited resolver on a client computer, that + leaves the recursing work to a full resolver. + + Query: a question sent out by a resolver, typically in a UDP + packet + + Response: the answer sent back by an authoritative nameserver, + typically in a UDP packet. + + Third party: any entity other than the resolver or the intended + recipient of a question. The third party may have access to an + arbitrary authoritative nameserver, but has no access to packets + transmitted by the resolver or authoritative server. + + Attacker: malicious third party. + + Spoof: the activity of attempting to subvert the DNS process by + getting a chosen answer accepted. + + + + + +Hubert & van Mook Standards Track [Page 4] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + Authentic response: the correct answer that comes from the right + authoritative server. + + Target domain name: domain for which the attacker wishes to spoof + in an answer + + Fake data: response chosen by the attacker. + +2.2. Key Words + + 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]. + +3. Description of DNS Spoofing + + When certain steps are taken, it is feasible to "spoof" the current + deployed majority of resolvers with carefully crafted and timed DNS + packets. Once spoofed, a caching server will repeat the data it + wrongfully accepted, and make its clients contact the wrong, and + possibly malicious, servers. + + To understand how this process works it is important to know what + makes a resolver accept a response. + + The following sentence in Section 5.3.3 of [RFC1034] presaged the + present problem: + + The resolver should be highly paranoid in its parsing of responses. + It should also check that the response matches the query it sent + using the ID field in the response. + + DNS data is to be accepted by a resolver if and only if: + + 1. The question section of the reply packet is equivalent to that of + a question packet currently waiting for a response. + + 2. The ID field of the reply packet matches that of the question + packet. + + 3. The response comes from the same network address to which the + question was sent. + + 4. The response comes in on the same network address, including port + number, from which the question was sent. + + In general, the first response matching these four conditions is + accepted. + + + +Hubert & van Mook Standards Track [Page 5] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + If a third party succeeds in meeting the four conditions before the + response from the authentic nameserver does so, it is in a position + to feed a resolver fabricated data. When it does so, we dub it an + "attacker", attempting to spoof in fake data. + + All conditions mentioned above can theoretically be met by a third + party, with the difficulty being a function of the resolver + implementation and zone configuration. + +4. Detailed Description of Spoofing Scenarios + + The previous paragraph discussed a number of requirements an attacker + must match in order to spoof in manipulated (or fake) data. This + section discusses the relative difficulties and how implementation- + defined choices impact the amount of work an attacker has to perform + to meet said difficulties. + + Some more details can be found in Section 2.2 of [RFC3833]. + +4.1. Forcing a Query + + Formally, there is no need for a nameserver to perform service except + for its operator, its customers, or more generally its users. + Recently, open recursing nameservers have been used to amplify + denial-of-service attacks. + + Providing full service enables the third party to send the target + resolver a query for the domain name it intends to spoof. On + receiving this query, and not finding the answer in its cache, the + resolver will transmit queries to relevant authoritative nameservers. + This opens up a window of opportunity for getting fake answer data + accepted. + + Queries may however be forced indirectly, for example, by inducing a + mail server to perform DNS lookups. + + Some operators restrict access by not recursing for unauthorized IP + addresses, but only respond with data from the cache. This makes + spoofing harder for a third party as it cannot then force the exact + moment a question will be asked. It is still possible however to + determine a time range when this will happen, because nameservers + helpfully publish the decreasing time to live (TTL) of entries in the + cache, which indicate from which absolute time onwards a new query + could be sent to refresh the expired entry. + + The time to live of the target domain name's RRSets determines how + often a window of opportunity is available, which implies that a + short TTL makes spoofing far more viable. + + + +Hubert & van Mook Standards Track [Page 6] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + Note that the attacker might very well have authorized access to the + target resolver by virtue of being a customer or employee of its + operator. In addition, access may be enabled through the use of + reflectors as outlined in [RFC5358]. + +4.2. Matching the Question Section + + DNS packets, both queries and responses, contain a question section. + Incoming responses should be verified to have a question section that + is equivalent to that of the outgoing query. + +4.3. Matching the ID Field + + The DNS ID field is 16 bits wide, meaning that if full use is made of + all these bits, and if their contents are truly random, it will + require on average 32768 attempts to guess. Anecdotal evidence + suggests there are implementations utilizing only 14 bits, meaning on + average 8192 attempts will suffice. + + Additionally, if the target nameserver can be forced into having + multiple identical queries outstanding, the "Birthday Attack" + phenomenon means that any fake data sent by the attacker is matched + against multiple outstanding queries, significantly raising the + chance of success. Further details in Section 5. + +4.4. Matching the Source Address of the Authentic Response + + It should be noted that meeting this condition entails being able to + transmit packets on behalf of the address of the authoritative + nameserver. While two Best Current Practice documents ([RFC2827] and + [RFC3013] specifically) direct Internet access providers to prevent + their customers from assuming IP addresses that are not assigned to + them, these recommendations are not universally (nor even widely) + implemented. + + Many zones have two or three authoritative nameservers, which make + matching the source address of the authentic response very likely + with even a naive choice having a double digit success rate. + + Most recursing nameservers store relative performance indications of + authoritative nameservers, which may make it easier to predict which + nameserver would originally be queried -- the one most likely to + respond the quickest. + + Generally, this condition requires at most two or three attempts + before it is matched. + + + + + +Hubert & van Mook Standards Track [Page 7] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +4.5. Matching the Destination Address and Port of the Authentic + Response + + Note that the destination address of the authentic response is the + source address of the original query. + + The actual address of a recursing nameserver is generally known; the + port used for asking questions is harder to determine. Most current + resolvers pick an arbitrary port at startup (possibly at random) and + use this for all outgoing queries. In quite a number of cases, the + source port of outgoing questions is fixed at the traditional DNS + assigned server port number of 53. + + If the source port of the original query is random, but static, any + authoritative nameserver under observation by the attacker can be + used to determine this port. This means that matching this + conditions often requires no guess work. + + If multiple ports are used for sending queries, this enlarges the + effective ID space by a factor equal to the number of ports used. + + Less common resolving servers choose a random port per outgoing + query. If this strategy is followed, this port number can be + regarded as an additional ID field, again containing up to 16 bits. + + If the maximum ports range is utilized, on average, around 32256 + source ports would have to be tried before matching the source port + of the original query, as ports below 1024 may be unavailable for + use, leaving 64512 options. + + It is in general safe for DNS to use ports in the range 1024-49152 + even though some of these ports are allocated to other protocols. + DNS resolvers will not be able to use any ports that are already in + use. If a DNS resolver uses a port, it will release that port after + a short time and migrate to a different port. Only in the case of a + high-volume resolver is it possible that an application wanting a + particular UDP port suffers a long term block-out. + + It should be noted that a firewall will not prevent the matching of + this address, as it will accept answers that (appear to) come from + the correct address, offering no additional security. + +4.6. Have the Response Arrive before the Authentic Response + + Once any packet has matched the previous four conditions (plus + possible additional conditions), no further responses are generally + accepted. + + + + +Hubert & van Mook Standards Track [Page 8] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + This means that the third party has a limited time in which to inject + its spoofed response. For calculations, we will assume a window in + order of at most 100 ms (depending on the network distance to the + authentic authoritative nameserver). + + This time period can be far longer if the authentic authoritative + nameservers are (briefly) overloaded by queries, perhaps by the + attacker. + +5. Birthday Attacks + + The so-called "birthday paradox" implies that a group of 23 people + suffices to have a more than even chance of having two or more + members of the group share a birthday. + + An attacker can benefit from this exact phenomenon if it can force + the target resolver to have multiple equivalent (identical QNAME, + QTYPE, and QCLASS) outstanding queries at any one time to the same + authoritative server. + + Any packet the attacker sends then has a much higher chance of being + accepted because it only has to match any of the outstanding queries + for that single domain. Compared to the birthday analogy above, of + the group composed of queries and responses, the chance of having any + of these share an ID rises quickly. + + As long as small numbers of queries are sent out, the chance of + successfully spoofing a response rises linearly with the number of + outstanding queries for the exact domain and nameserver. + + For larger numbers, this effect is less pronounced. + + More details are available in US-CERT [vu-457875]. + +6. Accepting Only In-Domain Records + + Responses from authoritative nameservers often contain information + that is not part of the zone for which we deem it authoritative. As + an example, a query for the MX record of a domain might get as its + responses a mail exchanger in another domain, and additionally the IP + address of this mail exchanger. + + If accepted uncritically, the resolver stands the chance of accepting + data from an untrusted source. Care must be taken to only accept + data if it is known that the originator is authoritative for the + QNAME or a parent of the QNAME. + + + + + +Hubert & van Mook Standards Track [Page 9] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + One very simple way to achieve this is to only accept data if it is + part of the domain for which the query was intended. + +7. Combined Difficulty + + Given a known or static destination port, matching ID field, the + source and destination address requires on average in the order of 2 + * 2^15 = 65000 packets, assuming a zone has 2 authoritative + nameservers. + + If the window of opportunity available is around 100 ms, as assumed + above, an attacker would need to be able to briefly transmit 650000 + packets/s to have a 50% chance to get spoofed data accepted on the + first attempt. + + A realistic minimal DNS response consists of around 80 bytes, + including IP headers, making the packet rate above correspond to a + respectable burst of 416 Mbit/s. + + As of mid-2006, this kind of bandwidth was not common but not scarce + either, especially among those in a position to control many servers. + + These numbers change when a window of a full second is assumed, + possibly because the arrival of the authentic response can be + prevented by overloading the bona fide authoritative hosts with decoy + queries. This reduces the needed bandwidth to 42 Mbit/s. + + If, in addition, the attacker is granted more than a single chance + and allowed up to 60 minutes of work on a domain with a time to live + of 300 seconds, a meager 4 Mbit/s suffices for a 50% chance at + getting fake data accepted. Once equipped with a longer time, + matching condition 1 mentioned above is straightforward -- any + popular domain will have been queried a number of times within this + hour, and given the short TTL, this would lead to queries to + authoritative nameservers, opening windows of opportunity. + +7.1. Symbols Used in Calculation + + Assume the following symbols are used: + + I: Number distinct IDs available (maximum 65536) + + P: Number of ports used (maximum around 64000 as ports under 1024 are + not always available, but often 1) + + N: Number of authoritative nameservers for a domain (averages around + 2.5) + + + + +Hubert & van Mook Standards Track [Page 10] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + F: Number of "fake" packets sent by the attacker + + R: Number of packets sent per second by the attacker + + W: Window of opportunity, in seconds. Bounded by the response time + of the authoritative servers (often 0.1s) + + D: Average number of identical outstanding queries of a resolver + (typically 1, see Section 5) + + A: Number of attempts, one for each window of opportunity + +7.2. Calculation + + The probability of spoofing a resolver is equal to the amount of fake + packets that arrive within the window of opportunity, divided by the + size of the problem space. + + When the resolver has 'D' multiple identical outstanding queries, + each fake packet has a proportionally higher chance of matching any + of these queries. This assumption only holds for small values of + 'D'. + + In symbols, if the probability of being spoofed is denoted as P_s: + + D * F + P_s = --------- + N * P * I + + It is more useful to reason not in terms of aggregate packets but to + convert to packet rate, which can easily be converted to bandwidth if + needed. + + If the window of opportunity length is 'W' and the attacker can send + 'R' packets per second, the number of fake packets 'F' that are + candidates to be accepted is: + + D * R * W + F = R * W -> P_s = --------- + N * P * I + + Finally, to calculate the combined chance 'P_cs' of spoofing over a + chosen time period 'T', it should be realized that the attacker has a + new window of opportunity each time the TTL 'TTL' of the target + domain expires. This means that the number of attempts 'A' is equal + to 'T / TTL'. + + + + + +Hubert & van Mook Standards Track [Page 11] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + To calculate the combined chance of at least one success, the + following formula holds: + + (T / TTL) + A ( D * R * W ) + P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- ) + ( N * P * I ) + + When common numbers (as listed above) for D, W, N, P, and I are + inserted, this formula reduces to: + + (T / TTL) + ( R ) + P_cs = 1 - ( 1 - ------- ) + ( 1638400 ) + + From this formula, it can be seen that, if the nameserver + implementation is unchanged, only raising the TTL offers protection. + Raising N, the number of authoritative nameservers, is not feasible + beyond a small number. + + For the degenerate case of a zero-second TTL, a window of opportunity + opens for each query sent, making the effective TTL equal to 'W' + above, the response time of the authoritative server. + + This last case also holds for spoofing techniques that do not rely on + TTL expiry, but use repeated and changing queries. + +8. Discussion + + The calculations above indicate the relative ease with which DNS data + can be spoofed. For example, using the formula derived earlier on an + RRSet with a 3600 second TTL, an attacker sending 7000 fake response + packets/s (a rate of 4.5 Mbit/s), stands a 10% chance of spoofing a + record in the first 24 hours, which rises to 50% after a week. + + For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24 + minutes, 50% after less than 3 hours, 90% after around 9 hours. + + For some classes of attacks, the effective TTL is near zero, as noted + above. + + Note that the attacks mentioned above can be detected by watchful + server operators - an unexpected incoming stream of 4.5 Mbit/s of + packets might be noticed. + + An important assumption however in these calculations is a known or + static destination port of the authentic response. + + + +Hubert & van Mook Standards Track [Page 12] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + If that port number is unknown and needs to be guessed as well, the + problem space expands by a factor of 64000, leading the attacker to + need in excess of 285Gb/s to achieve similar success rates. + + Such bandwidth is not generally available, nor is it expected to be + so in the foreseeable future. + + Note that some firewalls may need reconfiguring if they are currently + set up to only allow outgoing queries from a single DNS source port. + +8.1. Repetitive Spoofing Attempts for a Single Domain Name + + Techniques are available to use an effectively infinite number of + queries to achieve a desired spoofing goal. In the math above, this + reduces the effective TTL to 0. + + If such techniques are employed, using the same 7000 packets/s rate + mentioned above, and using 1 source port, the spoofing chance rises + to 50% within 7 seconds. + + If 64000 ports are used, as recommended in this document, using the + same query rate, the 50% level is reached after around 116 hours. + +9. Forgery Countermeasures + +9.1. Query Matching Rules + + A resolver implementation MUST match responses to all of the + following attributes of the query: + + o Source address against query destination address + + o Destination address against query source address + + o Destination port against query source port + + o Query ID + + o Query name + + o Query class and type + + before applying DNS trustworthiness rules (see Section 5.4.1 of + [RFC2181]). + + A mismatch and the response MUST be considered invalid. + + + + + +Hubert & van Mook Standards Track [Page 13] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +9.2. Extending the Q-ID Space by Using Ports and Addresses + + Resolver implementations MUST: + + o Use an unpredictable source port for outgoing queries from the + range of available ports (53, or 1024 and above) that is as large + as possible and practicable; + + o Use multiple different source ports simultaneously in case of + multiple outstanding queries; + + o Use an unpredictable query ID for outgoing queries, utilizing the + full range available (0-65535). + + Resolvers that have multiple IP addresses SHOULD use them in an + unpredictable manner for outgoing queries. + + Resolver implementations SHOULD provide means to avoid usage of + certain ports. + + Resolvers SHOULD favor authoritative nameservers with which a trust + relation has been established; stub-resolvers SHOULD be able to use + Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when + communicating with their recursive resolver. + + In case a cryptographic verification of response validity is + available (TSIG, SIG(0)), resolver implementations MAY waive above + rules, and rely on this guarantee instead. + + Proper unpredictability can be achieved by employing a high quality + (pseudo-)random generator, as described in [RFC4086]. + +9.2.1. Justification and Discussion + + Since an attacker can force a full DNS resolver to send queries to + the attacker's own nameservers, any constant or sequential state held + by such a resolver can be measured, and it must not be trivially easy + to reverse engineer the resolver's internal state in a way that + allows low-cost, high-accuracy prediction of future state. + + A full DNS resolver with only one or a small number of upstream- + facing endpoints is effectively using constants for IP source address + and UDP port number, and these are very predictable by potential + attackers, and must therefore be avoided. + + A full DNS resolver that uses a simple increment to get its next DNS + query ID is likewise very predictable and so very spoofable. + + + + +Hubert & van Mook Standards Track [Page 14] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + Finally, weak random number generators have been shown to expose + their internal state, such that an attacker who witnesses several + sequential "random" values can easily predict the next ones. A + crypto-strength random number generator is one whose output cannot be + predicted no matter how many successive values are witnessed. + +9.3. Spoof Detection and Countermeasure + + If a resolver detects that an attempt is being made to spoof it, + perhaps by discovering that many packets fail the criteria as + outlined above, it MAY abandon the UDP query and re-issue it over + TCP. TCP, by the nature of its use of sequence numbers, is far more + resilient against forgery by third parties. + +10. Security Considerations + + This document provides clarification of the DNS specification to + decrease the probability that DNS responses can be successfully + forged. Recommendations found above should be considered + complementary to possible cryptographical enhancements of the domain + name system, which protect against a larger class of attacks. + + This document recommends the use of UDP source port number + randomization to extend the effective DNS transaction ID beyond the + available 16 bits. + + A resolver that does not implement the recommendations outlined above + can easily be forced to accept spoofed responses, which in turn are + passed on to client computers -- misdirecting (user) traffic to + possibly malicious entities. + + This document directly impacts the security of the Domain Name + System, implementers are urged to follow its recommendations. + + Most security considerations can be found in Sections 4 and 5, while + proposed countermeasures are described in Section 9. + + For brevity's sake, in lieu of repeating the security considerations + references, the reader is referred to these sections. + + Nothing in this document specifies specific algorithms for operators + to use; it does specify algorithms implementations SHOULD or MUST + support. + + It should be noted that the effects of source port randomization may + be dramatically reduced by NAT devices that either serialize or limit + in volume the UDP source ports used by the querying resolver. + + + + +Hubert & van Mook Standards Track [Page 15] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + DNS recursive servers sitting behind at NAT or a statefull firewall + may consume all available NAT translation entries/ports when + operating under high query load. Port randomization will cause + translation entries to be consumed faster than with fixed query port. + + To avoid this, NAT boxes and statefull firewalls can/should purge + outgoing DNS query translation entries 10-17 seconds after the last + outgoing query on that mapping was sent. [RFC4787]-compliant devices + need to treat UDP messages with port 53 differently than most other + UDP protocols. + + To minimize the potential that port/state exhaustion attacks can be + staged from the outside, it is recommended that services that + generate a number of DNS queries for each connection should be rate + limited. This applies in particular to email servers. + +11. Acknowledgments + + Source port randomization in DNS was first implemented and possibly + invented by Dan J. Bernstein. + + Although any mistakes remain our own, the authors gratefully + acknowledge the help and contributions of: + Stephane Bortzmeyer + Alfred Hoenes + Peter Koch + Sean Leach + Norbert Sendetzky + Paul Vixie + Florian Weimer + Wouter Wijngaards + Dan Wing + +12. References + +12.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + + +Hubert & van Mook Standards Track [Page 16] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP + Source Address Spoofing", BCP 38, RFC 2827, May 2000. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. + Wellington, "Secret Key Transaction Authentication for + DNS (TSIG)", RFC 2845, May 2000. + + [RFC3013] Killalea, T., "Recommended Internet Service Provider + Security Services and Procedures", BCP 46, RFC 3013, + November 2000. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, + June 2005. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + +12.2. Informative References + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October 1989. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the + Domain Name System (DNS)", RFC 3833, August 2004. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + + [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive + Nameservers in Reflector Attacks", BCP 140, RFC 5358, + October 2008. + + [vu-457875] United States CERT, "Various DNS service implementations + generate multiple simultaneous queries for the same + resource record", VU 457875, November 2002. + + + + + + +Hubert & van Mook Standards Track [Page 17] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +Authors' Addresses + + Bert Hubert + Netherlabs Computer Consulting BV. + Braillelaan 10 + Rijswijk (ZH) 2289 CM + The Netherlands + + EMail: bert.hubert@netherlabs.nl + + + Remco van Mook + Equinix + Auke Vleerstraat 1 + Enschede 7521 PE + The Netherlands + + EMail: remco@eu.equinix.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hubert & van Mook Standards Track [Page 18] + diff --git a/doc/draft/draft-ietf-dnsext-dnsproxy-05.txt b/doc/rfc/rfc5625.txt similarity index 55% rename from doc/draft/draft-ietf-dnsext-dnsproxy-05.txt rename to doc/rfc/rfc5625.txt index c5858c00ad..102d7e8770 100644 --- a/doc/draft/draft-ietf-dnsext-dnsproxy-05.txt +++ b/doc/rfc/rfc5625.txt @@ -1,37 +1,28 @@ -DNSEXT R. Bellis -Internet-Draft Nominet UK -Intended status: BCP April 23, 2009 -Expires: October 25, 2009 + + + +Network Working Group R. Bellis +Request for Comments: 5625 Nominet UK +BCP: 152 August 2009 +Category: Best Current Practice DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-05 -Status of this Memo +Abstract - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. + This document provides guidelines for the implementation of DNS + proxies, as found in broadband gateways and other similar network + devices. - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. +Status of This Memo - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on October 25, 2009. + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. Copyright Notice @@ -44,89 +35,72 @@ Copyright Notice Please review these documents carefully, as they describe your rights and restrictions with respect to this document. -Abstract - - This document provides guidelines for the implementation of DNS - proxies, as found in broadband gateways and other similar network - devices. -Bellis Expires October 25, 2009 [Page 1] + + + + + + + + + + + + + + + + + +Bellis Best Current Practice [Page 1] -Internet-Draft DNS Proxy Implementation Guidelines April 2009 +RFC 5625 DNS Proxy Implementation Guidelines August 2009 Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3 - - 4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4 - 4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4 - 4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4 - 4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5 - 4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5 - 4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 6 - 4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6 - 4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6 - 4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7 - - 5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7 - 5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 8 - 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8 - 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8 - - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9 - 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10 - 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10 - - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - - 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 - - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 - - - - - - - - - - - - -Bellis Expires October 25, 2009 [Page 2] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. The Transparency Principle ......................................3 + 4. Protocol Conformance ............................................4 + 4.1. Unexpected Flags and Data ..................................4 + 4.2. Label Compression ..........................................4 + 4.3. Unknown Resource Record Types ..............................4 + 4.4. Packet Size Limits .........................................4 + 4.4.1. TCP Transport .......................................5 + 4.4.2. Extension Mechanisms for DNS (EDNS0) ................6 + 4.4.3. IP Fragmentation ....................................6 + 4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7 + 5. DHCP's Interaction with DNS .....................................7 + 5.1. Domain Name Server (DHCP Option 6) .........................7 + 5.2. Domain Name (DHCP Option 15) ...............................8 + 5.3. DHCP Leases ................................................8 + 6. Security Considerations .........................................9 + 6.1. Forgery Resilience .........................................9 + 6.2. Interface Binding .........................................10 + 6.3. Packet Filtering ..........................................10 + 7. Acknowledgements ...............................................10 + 8. References .....................................................11 + 8.1. Normative References ......................................11 + 8.2. Informative References ....................................12 1. Introduction - Research has found ([SAC035], [DOTSE]) that many commonly-used - broadband gateways (and similar devices) contain DNS proxies which - are incompatible in various ways with current DNS standards. + Research has found ([SAC035], [DOTSE]) that many commonly used + broadband gateways (and similar devices) contain DNS proxies that are + incompatible in various ways with current DNS standards. These proxies are usually simple DNS forwarders, but typically do not have any caching capabilities. The proxy serves as a convenient default DNS resolver for clients on the LAN, but relies on an - upstream resolver (e.g. at an ISP) to perform recursive DNS lookups. + upstream resolver (e.g., at an ISP) to perform recursive DNS lookups. Note that to ensure full DNS protocol interoperability it is preferred that client stub resolvers should communicate directly with - full-feature upstream recursive resolvers wherever possible. + full-feature, upstream recursive resolvers wherever possible. That notwithstanding, this document describes the incompatibilities that have been discovered and offers guidelines to implementors on @@ -134,13 +108,20 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 client must use the broadband gateway's DNS proxy. + + + +Bellis Best Current Practice [Page 2] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + 2. Terminology 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]. - 3. The Transparency Principle It is not considered practical for a simple DNS proxy to implement @@ -148,30 +129,26 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 There are several reasons why this is the case: - o broadband gateways usually have limited hardware resources - o firmware upgrade cycles are long, and many users do not routinely - apply upgrades when they become available - o no-one knows what those future DNS features will be, nor how they - might be implemented - o it would substantially complicate the configuration UI of the - device + o Broadband gateways usually have limited hardware resources. - Furthermore some modern DNS protocol extensions (see e.g. EDNS0, + o Firmware upgrade cycles are long, and many users do not routinely + apply upgrades when they become available. + + o No one knows what those future DNS features will be or how they + might be implemented. + + o Doing so would substantially complicate the configuration user + interface (UI) of the device. + + Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0 below) are intended to be used as "hop-by-hop" mechanisms. If the DNS proxy is considered to be such a "hop" in the resolution chain, then for it to function correctly, it would need to be fully compliant with all such mechanisms. - - -Bellis Expires October 25, 2009 [Page 3] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - [SAC035] shows that the more actively a proxy participates in the DNS - protocol then the more likely it is that it will somehow interfere - with the flow of messages between the DNS client and the upstream + protocol, the more likely it is that it will somehow interfere with + the flow of messages between the DNS client and the upstream recursive resolvers. The role of the proxy should therefore be no more and no less than to @@ -187,11 +164,18 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 Except when required to enforce an active security or network policy (such as maintaining a pre-authentication "walled garden"), end-users SHOULD be able to send their DNS queries to specified upstream + + + +Bellis Best Current Practice [Page 3] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + resolvers, thereby bypassing the proxy altogether. In this case, the gateway SHOULD NOT modify the DNS request or response packets in any way. - 4. Protocol Conformance 4.1. Unexpected Flags and Data @@ -205,26 +189,18 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 containing either the "Authentic Data" (AD) or "Checking Disabled" (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] originally specified that these unused "Z" flag bits "MUST" be zero. - However these flag bits were always intended to be reserved for + However, these flag bits were always intended to be reserved for future use, so refusing to proxy any packet containing these flags (now that uses for those flags have indeed been defined) is not appropriate. - Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown - DNS flags and proxy those packets as usual. + Therefore, proxies MUST ignore any unknown DNS flags and proxy those + packets as usual. 4.2. Label Compression Compression of labels as per Section 4.1.4 of [RFC1035] is optional. - - - -Bellis Expires October 25, 2009 [Page 4] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - Proxies MUST forward packets regardless of the presence or absence of compressed labels therein. @@ -236,28 +212,36 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 All requests and responses MUST be proxied regardless of the values of the QTYPE and QCLASS fields. - Similarly all responses MUST be proxied regardless of the values of + Similarly, all responses MUST be proxied regardless of the values of the TYPE and CLASS fields of any Resource Record therein. 4.4. Packet Size Limits [RFC1035] specifies that the maximum size of the DNS payload in a UDP packet is 512 octets. Where the required portions of a response - would not fit inside that limit the DNS server MUST set the + would not fit inside that limit, the DNS server MUST set the + + + +Bellis Best Current Practice [Page 4] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + "TrunCation" (TC) bit in the DNS response header to indicate that truncation has occurred. There are however two standard mechanisms - (described in Section 4.4.1 and Section 4.4.2) for transporting - responses larger than 512 octets. + (described in Sections 4.4.1 and 4.4.2) for transporting responses + larger than 512 octets. Many proxies have been observed to truncate all responses at 512 octets, and others at a packet size related to the WAN MTU, in either case doing so without correctly setting the TC bit. Other proxies have been observed to remove the TC bit in server - responses which correctly had the TC bit set by the server. + responses that correctly had the TC bit set by the server. - If a DNS response is truncated but the TC bit is not set then client - failures may result. In particular a naive DNS client library might + If a DNS response is truncated but the TC bit is not set, then client + failures may result. In particular, a naive DNS client library might suffer crashes due to reading beyond the end of the data actually received. @@ -266,29 +250,22 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 size. See Section 4.4.3 for recommendations for packet sizes exceeding the WAN MTU. - If a proxy must unilaterally truncate a response then the proxy MUST + If a proxy must unilaterally truncate a response, then the proxy MUST set the TC bit. Similarly, proxies MUST NOT remove the TC bit from responses. - - - - - - -Bellis Expires October 25, 2009 [Page 5] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - 4.4.1. TCP Transport Should a UDP query fail because of truncation, the standard fail-over - mechanism is to retry the query using TCP, as described in section + mechanism is to retry the query using TCP, as described in Section 6.1.3.2 of [RFC1123]. - DNS proxies SHOULD therefore be prepared to receive and forward - queries over TCP. + Whilst TCP transport is not strictly mandatory, it is supported by + the vast majority of stub resolvers and recursive servers. Lack of + support in the proxy prevents this fail-over mechanism from working. + + DNS proxies MUST therefore be prepared to receive and forward queries + over TCP. Note that it is unlikely that a client would send a request over TCP unless it had already received a truncated UDP response. Some @@ -298,14 +275,23 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 behaviour increases network traffic and causes delay in DNS resolution since the initial UDP request is doomed to fail. - Therefore whenever a proxy receives a request over TCP, the proxy + + + + +Bellis Best Current Practice [Page 5] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + + Therefore, whenever a proxy receives a request over TCP, the proxy SHOULD forward the query over TCP and SHOULD NOT attempt the same query over UDP first. 4.4.2. Extension Mechanisms for DNS (EDNS0) - The Extension Mechanism for DNS [RFC2671] was introduced to allow the - transport of larger DNS packets over UDP and also to allow for + The "Extension Mechanism for DNS" [RFC2671] was introduced to allow + the transport of larger DNS packets over UDP and also to allow for additional request and response flags. A client may send an OPT Resource Record (OPT RR) in the Additional @@ -314,9 +300,9 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 by DNSSEC to indicate that DNSSEC-related RRs should be returned to the client. - However some proxies have been observed to either reject (with a + However, some proxies have been observed to either reject (with a FORMERR response code) or black-hole any packet containing an OPT RR. - As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets. + As per Section 4.1, proxies MUST NOT refuse to proxy such packets. 4.4.3. IP Fragmentation @@ -324,18 +310,12 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 gateway's algorithm for handling fragmented IP packets. Several methods are possible: - 1. fragments are dropped - 2. fragments are forwarded individually as they're received - 3. complete packets are reassembled on the gateway, and then re- - fragmented (if necessary) as they're forwarded to the client + 1. Fragments are dropped. + 2. Fragments are forwarded individually as they're received. - - -Bellis Expires October 25, 2009 [Page 6] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - + 3. Complete packets are reassembled on the gateway and then re- + fragmented (if necessary) as they're forwarded to the client. Method 1 above will cause compatibility problems with EDNS0 unless the DNS client is configured to advertise an EDNS0 buffer size @@ -347,11 +327,20 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 to 65535 octets, most common DNS server implementations do not support a buffer size above 4096 octets. - Therefore (irrespective of which of the methods above is in use) + Therefore (irrespective of which of the above methods is in use), proxies SHOULD be capable of forwarding UDP packets up to a payload size of at least 4096 octets. - NB: in theory IP fragmentation may also occur if the LAN MTU is + + + + +Bellis Best Current Practice [Page 6] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + + NB: in theory, IP fragmentation may also occur if the LAN MTU is smaller than the WAN MTU, although the author has not observed such a configuration in use on any residential broadband service. @@ -372,55 +361,58 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 containing TKEY [RFC2930] Resource Records. NB: any DNS proxy (such as those commonly found in WiFi hotspot - "walled gardens") which transparently intercepts all DNS queries, and - which returns unsigned responses to signed queries, will also cause + "walled gardens") that transparently intercepts all DNS queries and + that returns unsigned responses to signed queries, will also cause TSIG authentication failures. - 5. DHCP's Interaction with DNS Whilst this document is primarily about DNS proxies, most consumers rely on DHCP [RFC2131] to obtain network configuration settings. - Such settings include the client machine's IP address, subnet mask - and default gateway, but also include DNS related settings. + Such settings include the client machine's IP address, subnet mask, + and default gateway, but also include DNS-related settings. It is therefore appropriate to examine how DHCP affects client DNS - - - -Bellis Expires October 25, 2009 [Page 7] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - configuration. 5.1. Domain Name Server (DHCP Option 6) Most gateways default to supplying their own IP address in the DHCP "Domain Name Server" option [RFC2132]. The net result is that - without explicit re-configuration many DNS clients will by default + without explicit re-configuration many DNS clients will, by default, send queries to the gateway's DNS proxy. This is understandable behaviour given that the correct upstream settings are not usually known at boot time. + + + + + + + +Bellis Best Current Practice [Page 7] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + Most gateways learn their own DNS settings via values supplied by an - ISP via DHCP or PPP over the WAN interface. However whilst many + ISP via DHCP or PPP over the WAN interface. However, whilst many gateways do allow the device administrator to override those values, some gateways only use those supplied values to affect the proxy's own forwarding function, and do not offer these values via DHCP. - When using such a device the only way to avoid using the DNS proxy is - to hard-code the required values in the client operating system. + When using such a device, the only way to avoid using the DNS proxy + is to hard-code the required values in the client operating system. This may be acceptable for a desktop system but it is inappropriate - for mobile devices which are regularly used on many different + for mobile devices that are regularly used on many different networks. As per Section 3, end-users SHOULD be able to send their DNS queries directly to specified upstream resolvers, ideally without hard-coding those settings in their stub resolver. - It is therefore RECOMMENDED that gateways SHOULD support device + It is therefore RECOMMENDED that gateways SHOULD support device- administrator configuration of values for the "Domain Name Server" DHCP option. @@ -431,80 +423,72 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 attributed to particular equipment vendors whose firmware defaults this DHCP option to specific values. - Since no standard exists for a "local" scoped domain name suffix it + Since no standard exists for a "local" scoped domain name suffix, it is RECOMMENDED that the default value for this option SHOULD be empty, and that this option MUST NOT be sent to clients when no value is configured. 5.3. DHCP Leases - It is noted that some DHCP servers in broadband gateways by default - offer their own IP address for the "Domain Name Server" option (as + It is noted that some DHCP servers in broadband gateways offer, by + default, their own IP address for the "Domain Name Server" option (as described above) but then automatically start offering the upstream - - - -Bellis Expires October 25, 2009 [Page 8] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - servers' addresses once they've been learnt over the WAN interface. - In general this behaviour is highly desirable, but the effect for the - end-user is that the settings used depend on whether the DHCP lease - was obtained before or after the WAN link was established. + In general, this behaviour is highly desirable, but the effect for + the end-user is that the settings used depend on whether the DHCP + lease was obtained before or after the WAN link was established. - If the DHCP lease is obtained whilst the WAN link is down then the + If the DHCP lease is obtained whilst the WAN link is down, then the DHCP client (and hence the DNS client) will not receive the correct values until the DHCP lease is renewed. + + + + +Bellis Best Current Practice [Page 8] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + Whilst no specific recommendations are given here, vendors may wish - to give consideration to the length of DHCP leases, and whether some - mechanism for forcing a DHCP lease renewal might be appropriate. + to give consideration to the length of DHCP leases and to whether + some mechanism for forcing a DHCP lease renewal might be appropriate. Another possibility is that the learnt upstream values might be persisted in non-volatile memory such that on reboot the same values - can be automatically offered via DHCP. However this does run the + can be automatically offered via DHCP. However, this does run the risk that incorrect values are initially offered if the device is moved or connected to another ISP. - Alternatively, the DHCP server might only issue very short (i.e. 60 + Alternatively, the DHCP server might only issue very short (i.e., 60 second) leases while the WAN link is down, only reverting to more typical lease lengths once the WAN link is up and the upstream DNS - servers are known. Indeed with such a configuration it may be + servers are known. Indeed, with such a configuration it may be possible to avoid the need to implement a DNS proxy function in the broadband gateway at all. - 6. Security Considerations - This document introduces no new protocols. However there are some - security related recommendations for vendors that are listed here. + This document introduces no new protocols. However, there are some + security-related recommendations for vendors that are listed here. 6.1. Forgery Resilience - Whilst DNS proxies are not usually full-feature resolvers they + Whilst DNS proxies are not usually full-feature resolvers, they nevertheless share some characteristics with them. - Notwithstanding the recommendations above about transparency many DNS - proxies are observed to pick a new Query ID for outbound requests to - ensure that responses are directed to the correct client. + Notwithstanding the recommendations above about transparency, many + DNS proxies are observed to pick a new Query ID for outbound requests + to ensure that responses are directed to the correct client. - NB: Changing the Query ID is acceptable and compatible with proxying + NB: changing the Query ID is acceptable and compatible with proxying TSIG-signed packets since the TSIG signature calculation is based on - the original message ID which is carried in the TSIG RR. + the original message ID, which is carried in the TSIG RR. It has been standard guidance for many years that each DNS query - should use a randomly generated Query ID. However many proxies have - - - -Bellis Expires October 25, 2009 [Page 9] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - + should use a randomly generated Query ID. However, many proxies have been observed picking sequential Query IDs for successive requests. It is strongly RECOMMENDED that DNS proxies follow the relevant @@ -513,126 +497,76 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 applies to source port selection within any NAT function. If a DNS proxy is running on a broadband gateway with NAT that is - compliant with [RFC4787] then it SHOULD also follow the + compliant with [RFC4787], then it SHOULD also follow the recommendations in Section 10 of [RFC5452] concerning how long DNS state is kept. + + +Bellis Best Current Practice [Page 9] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + 6.2. Interface Binding Some gateways have been observed to have their DNS proxy listening on both internal (LAN) and external (WAN) interfaces. In this - configuration it is possible for the proxy to be used to mount + configuration, it is possible for the proxy to be used to mount reflector attacks as described in [RFC5358]. - The DNS proxy in a gateway SHOULD NOT by default be accessible from + The DNS proxy in a gateway SHOULD NOT, by default, be accessible from the WAN interfaces of the device. 6.3. Packet Filtering The Transparency and Robustness Principles are not entirely - compatible with the deep packet inspection features of security - appliances such as firewalls which are intended to protect systems on - the inside of a network from rogue traffic. + compatible with the deep packet-inspection features of security + appliances such as firewalls, which are intended to protect systems + on the inside of a network from rogue traffic. - However a clear distinction may be made between traffic that is + However, a clear distinction may be made between traffic that is intrinsically malformed and that which merely contains unexpected data. - Examples of malformed packets which MAY be dropped include: + Examples of malformed packets that MAY be dropped include: - o invalid compression pointers (i.e. those that point outside of the - current packet, or which might cause a parsing loop). - o incorrect counts for the Question, Answer, Authority and + o invalid compression pointers (i.e., those that point outside of + the current packet or that might cause a parsing loop) + + o incorrect counts for the Question, Answer, Authority, and Additional Sections (although care should be taken where - truncation is a possibility). + truncation is a possibility) - Since dropped packets will cause the client to repeatedly retransmit - the original request, it is RECOMMENDED that proxies SHOULD instead - return a suitable DNS error response to the client (i.e. SERVFAIL) - instead of dropping the packet completely. + Dropped packets will cause the client to repeatedly retransmit the + original request, with the client only detecting the error after + several retransmit intervals. + In these circumstances, proxies SHOULD synthesise a suitable DNS + error response to the client (i.e., SERVFAIL) instead of dropping the + packet completely. This will allow the client to detect the error + immediately. - - - - -Bellis Expires October 25, 2009 [Page 10] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - -7. IANA Considerations - - This document requests no IANA actions. - - -8. Change Log - - NB: to be removed by the RFC Editor before publication. - - draft-ietf-dnsproxy-05 - Removed specific reference to 28 byte IP headers (from Mark - Andrews) - - draft-ietf-dnsproxy-04 - post WGLC - Introduction expanded - Section 5.2 - changed SHOULD to MUST - Section 4.5 - changed SHOULD to MUST (Alex Bligh) - Editorial nits (from Andrew Sullivan, Alfred Hones) - Clarificaton on end-user vs device administrator (Alan Barrett, - Paul Selkirk) - - draft-ietf-dnsproxy-03 - Editorial nits and mention of LAN MTU (from Alex Bligh) - - draft-ietf-dnsproxy-02 - Changed "router" to "gateway" throughout (David Oran) - Updated forgery resilience reference - Elaboration on bypassability (from Nicholas W.) - Elaboration on NAT source port randomisation (from Nicholas W.) - Mention of using short DHCP leases while the WAN link is down - (from Ralph Droms) - Further clarification on permissibility of altering QID when using - TSIG - - draft-ietf-dnsproxy-01 - Strengthened recommendations about truncation (from Shane Kerr) - New TSIG text (with help from Olafur) - Additional forgery resilience text (from Olafur) - Compression support (from Olafur) - Correction of text re: QID changes and compatibility with TSIG - - draft-ietf-dnsproxy-00 - Changed recommended DPI error to SERVFAIL (from Jelte) - Changed example for invalid compression pointers (from Wouter). - Note about TSIG implications of changing Query ID (from Wouter). - Clarified TC-bit text (from Wouter) - - - - - -Bellis Expires October 25, 2009 [Page 11] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - - Extra text about proxy bypass (Nicholas W.) - - draft-bellis-dnsproxy-00 - Initial draft - - -9. Acknowledgements +7. Acknowledgements The author would particularly like to acknowledge the assistance of - Lisa Phifer of Core Competence. In addition the author is grateful + Lisa Phifer of Core Competence. In addition, the author is grateful for the feedback from the members of the DNSEXT Working Group. -10. References -10.1. Normative References + + + + +Bellis Best Current Practice [Page 10] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + +8. References + +8.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. @@ -665,14 +599,6 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. - - - -Bellis Expires October 25, 2009 [Page 12] - -Internet-Draft DNS Proxy Implementation Guidelines April 2009 - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. @@ -685,10 +611,19 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008. + + + + +Bellis Best Current Practice [Page 11] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009. -10.2. Informative References +8.2. Informative References [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband Routers", February 2008, @@ -698,7 +633,6 @@ Internet-Draft DNS Proxy Implementation Guidelines April 2009 Broadband Routers and Firewalls", September 2008, . - Author's Address Ray Bellis @@ -708,7 +642,7 @@ Author's Address United Kingdom Phone: +44 1865 332211 - Email: ray.bellis@nominet.org.uk + EMail: ray.bellis@nominet.org.uk URI: http://www.nominet.org.uk/ @@ -724,5 +658,18 @@ Author's Address -Bellis Expires October 25, 2009 [Page 13] + + + + + + + + + + + + + +Bellis Best Current Practice [Page 12] From 9dad3e27102700ea9e0be1dfbeb24a8da8f15638 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 19 Nov 2009 05:11:47 +0000 Subject: [PATCH 14/18] new draft --- .../draft-ietf-dnsext-rfc2671bis-edns0-01.txt | 480 -------------- .../draft-ietf-dnsext-rfc2671bis-edns0-02.txt | 616 ++++++++++++++++++ 2 files changed, 616 insertions(+), 480 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt deleted file mode 100644 index 8f84fd4db2..0000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt +++ /dev/null @@ -1,480 +0,0 @@ - - - - - - -DNSEXT Working Group Paul Vixie, ISC -INTERNET-DRAFT - March 17, 2008 - -Intended Status: Standards Track -Obsoletes: 2671 (if approved) - - - Revised extension mechanisms for DNS (EDNS0) - - -Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - Abstract - - The Domain Name System's wire protocol includes a number of fixed - fields whose range has been or soon will be exhausted and does not - allow clients to advertise their capabilities to servers. This - document describes backward compatible mechanisms for allowing the - protocol to grow. - - - -Expires September 2008 [Page 1] - -INTERNET-DRAFT EDNS0 March 2008 - - -1 - Introduction - -1.1. DNS (see [RFC1035]) specifies a Message Format and within such -messages there are standard formats for encoding options, errors, and -name compression. The maximum allowable size of a DNS Message is fixed. -Many of DNS's protocol limits are too small for uses which are or which -are desired to become common. There is no way for implementations to -advertise their capabilities. - -1.2. Unextended agents will not know how to interpret the protocol -extensions detailed here. In practice, these clients will be upgraded -when they have need of a new feature, and only new features will make -use of the extensions. Extended agents must be prepared for behaviour -of unextended clients in the face of new protocol elements, and fall -back gracefully to unextended DNS. RFC 2671 originally has proposed -extensions to the basic DNS protocol to overcome these deficiencies. -This memo refines that specification and obsoletes RFC 2671. - -1.3. 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 RFC 2119 [RFC2119]. - -2 - Affected Protocol Elements - -2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit -word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of -1-bit flags. The original reserved Z bits have been allocated to -various purposes, and most of the RCODE values are now in use. More -flags and more possible RCODEs are needed. The OPT pseudo-RR specified -in Section 4 contains subfields that carry a bit field extension of the -RCODE field and additional flag bits, respectively; for details see -Section 4.6 below. - -2.2. The first two bits of a wire format domain label are used to denote -the type of the label. [RFC1035 4.1.4] allocates two of the four -possible types and reserves the other two. Proposals for use of the -remaining types far outnumber those available. More label types were -needed, and an extension mechanism was proposed in RFC 2671 [RFC2671 -Section 3]. Section 3 of this document reserves DNS labels with a first -octet in the range of 64-127 decimal (label type 01) for future -standardization of Extended DNS Labels. - - - - - - - -Expires September 2008 [Page 2] - -INTERNET-DRAFT EDNS0 March 2008 - - -2.3. DNS Messages are limited to 512 octets in size when sent over UDP. -While the minimum maximum reassembly buffer size still allows a limit of -512 octets of UDP payload, most of the hosts now connected to the -Internet are able to reassemble larger datagrams. Some mechanism must -be created to allow requestors to advertise larger buffer sizes to -responders. To this end, the OPT pseudo-RR specified in Section 4 -contains a maximum payload size field; for details see Section 4.5 -below. - -3 - Extended Label Types - -The first octet in the on-the-wire representation of a DNS label -specifies the label type; the basic DNS specification [RFC1035] -dedicates the two most significant bits of that octet for this purpose. - -This document reserves DNS label type 0b01 for use as an indication for -Extended Label Types. A specific extended label type is selected by the -6 least significant bits of the first octet. Thus, Extended Label Types -are indicated by the values 64-127 (0b01xxxxxx) in the first octet of -the label. - -Allocations from this range are to be made for IETF documents fully -describing the syntax and semantics as well as the applicability of the -particular Extended Label Type. - -This document does not describe any specific Extended Label Type. - -4 - OPT pseudo-RR - -4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data -section of a request, and to responses to such requests. An OPT is -called a pseudo-RR because it pertains to a particular transport level -message and not to any actual DNS data. OPT RRs MUST NOT be cached, -forwarded, or stored in or loaded from master files. The quantity of -OPT pseudo-RRs per message MUST be either zero or one, but not greater. - -4.2. An OPT RR has a fixed part and a variable set of options expressed -as {attribute, value} pairs. The fixed part holds some DNS meta data -and also a small collection of new protocol elements which we expect to -be so popular that it would be a waste of wire space to encode them as -{attribute, value} pairs. - - - - - - - -Expires September 2008 [Page 3] - -INTERNET-DRAFT EDNS0 March 2008 - - -4.3. The fixed part of an OPT RR is structured as follows: - -Field Name Field Type Description ------------------------------------------------------- -NAME domain name empty (root domain) -TYPE u_int16_t OPT (41) -CLASS u_int16_t sender's UDP payload size -TTL u_int32_t extended RCODE and flags -RDLEN u_int16_t describes RDATA -RDATA octet stream {attribute,value} pairs - - -4.4. The variable part of an OPT RR is encoded in its RDATA and is -structured as zero or more of the following: - - : +0 (MSB) : +1 (LSB) : - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | OPTION-CODE | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | OPTION-LENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 4: | | - / OPTION-DATA / - / / - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - -OPTION-CODE (Assigned by IANA.) - -OPTION-LENGTH Size (in octets) of OPTION-DATA. - -OPTION-DATA Varies per OPTION-CODE. - -4.4.1. Order of appearance of option tuples is never relevant. Any -option whose meaning is affected by other options is so affected no -matter which one comes first in the OPT RDATA. - -4.4.2. Any OPTION-CODE values not understood by a responder or requestor -MUST be ignored. So, specifications of such options might wish to -include some kind of signalled acknowledgement. For example, an option -specification might say that if a responder sees option XYZ, it SHOULD -include option XYZ in its response. - - - - - - -Expires September 2008 [Page 4] - -INTERNET-DRAFT EDNS0 March 2008 - - -4.5. The sender's UDP payload size (which OPT stores in the RR CLASS -field) is the number of octets of the largest UDP payload that can be -reassembled and delivered in the sender's network stack. Note that path -MTU, with or without fragmentation, may be smaller than this. Values -lower than 512 are undefined, and may be treated as format errors, or -may be treated as equal to 512, at the implementor's discretion. - -4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP -reassembly buffer. Choosing 1280 on an Ethernet connected requestor -would be reasonable. The consequence of choosing too large a value may -be an ICMP message from an intermediate gateway, or even a silent drop -of the response message. - -4.5.2. Both requestors and responders are advised to take account of the -path's discovered MTU (if already known) when considering message sizes. - -4.5.3. The requestor's maximum payload size can change over time, and -therefore MUST NOT be cached for use beyond the transaction in which it -is advertised. - -4.5.4. The responder's maximum payload size can change over time, but -can be reasonably expected to remain constant between two sequential -transactions; for example, a meaningless QUERY to discover a responder's -maximum UDP payload size, followed immediately by an UPDATE which takes -advantage of this size. (This is considered preferrable to the outright -use of TCP for oversized requests, if there is any reason to suspect -that the responder implements EDNS, and if a request will not fit in the -default 512 payload size limit.) - -4.5.5. Due to transaction overhead, it is unwise to advertise an -architectural limit as a maximum UDP payload size. Just because your -stack can reassemble 64KB datagrams, don't assume that you want to spend -more than about 4KB of state memory per ongoing transaction. - -4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) -are structured as follows: - - : +0 (MSB) : +1 (LSB) : - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | DO| Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - - - -Expires September 2008 [Page 5] - -INTERNET-DRAFT EDNS0 March 2008 - - -EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that - EXTENDED-RCODE value zero (0) indicates that an - unextended RCODE is in use (values zero (0) through - fifteen (15)). - -VERSION Indicates the implementation level of whoever sets it. - Full conformance with this specification is indicated by - version zero (0). Requestors are encouraged to set this - to the lowest implemented level capable of expressing a - transaction, to minimize the responder and network load - of discovering the greatest common implementation level - between requestor and responder. A requestor's version - numbering strategy should ideally be a run time - configuration option. - - If a responder does not implement the VERSION level of - the request, then it answers with RCODE=BADVERS. All - responses MUST be limited in format to the VERSION level - of the request, but the VERSION of each response MUST be - the highest implementation level of the responder. In - this way a requestor will learn the implementation level - of a responder as a side effect of every response, - including error responses, including RCODE=BADVERS. - -DO DNSSEC OK bit [RFC3225]. - -Z Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification [IANAFLAGS]. - -5 - Transport Considerations - -5.1. The presence of an OPT pseudo-RR in a request is an indication that -the requestor fully implements the given version of EDNS, and can -correctly understand any response that conforms to that feature's -specification. - -5.2. Lack of use of these features in a request is an indication that -the requestor does not implement any part of this specification and that -the responder SHOULD NOT use any protocol extension described here in -its response. - -5.3. Responders who do not understand these protocol extensions are -expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or -to appear to "time out" due to inappropriate action by a "middle box" -such as a NAT, or to ignore extensions and respond only to unextended - - - -Expires September 2008 [Page 6] - -INTERNET-DRAFT EDNS0 March 2008 - - -protocol elements. Therefore use of extensions SHOULD be "probed" such -that a responder who isn't known to support them be allowed a retry with -no extensions if it responds with such an RCODE, or does not respond. -If a responder's capability level is cached by a requestor, a new probe -SHOULD be sent periodically to test for changes to responder capability. - -5.4. If EDNS is used in a request, and the response arrives with TC set -and with no EDNS OPT RR, a requestor should assume that truncation -prevented the OPT RR from being appended by the responder, and further, -that EDNS is not used in the response. Correspondingly, an EDNS -responder who cannot fit all necessary elements (including an OPT RR) -into a response, should respond with a normal (unextended) DNS response, -possibly setting TC if the response will not fit in the unextended -response message's 512-octet size. - -6 - Security Considerations - -Requestor-side specification of the maximum buffer size may open a new -DNS denial of service attack if responders can be made to send messages -which are too large for intermediate gateways to forward, thus leading -to potential ICMP storms between gateways and responders. - -7 - IANA Considerations - -IANA has allocated RR type code 41 for OPT. - -This document controls the following IANA sub-registries in registry -"DOMAIN NAME SYSTEM PARAMETERS": - - "EDNS Extended Label Type" - "EDNS Option Codes" - "EDNS Version Numbers" - "Domain System Response Code" - -IANA is advised to re-parent these subregistries to this document. - -This document assigns label type 0b01xxxxxx as "EDNS Extended Label -Type." We request that IANA record this assignment. - -This document assigns option code 65535 to "Reserved for future -expansion." - -This document assigns EDNS Extended RCODE "16" to "BADVERS". - - - - - -Expires September 2008 [Page 7] - -INTERNET-DRAFT EDNS0 March 2008 - - -IESG approval is required to create new entries in the EDNS Extended -Label Type or EDNS Version Number registries, while any published RFC -(including Informational, Experimental, or BCP) is grounds for -allocation of an EDNS Option Code. - -8 - Acknowledgements - -Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, -Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten, -Alfred Hoenes and Markku Savela were each instrumental in creating and -refining this specification. - -9 - References - -[RFC1035] P. Mockapetris, "Domain Names - Implementation and - Specification," RFC 1035, USC/Information Sciences - Institute, November 1987. - -[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119, Harvard University, March - 1997. - -[RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671, - Internet Software Consortium, August 1999. - -[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC - 3225, Nominum Inc., December 2001. - -[IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site - http://www.iana.org/assignments/dns-header-flags, as of - June 2005 or later. - -10 - Author's Address - -Paul Vixie - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 423 1301 - EMail: vixie@isc.org - - - - - - - - -Expires September 2008 [Page 8] - -INTERNET-DRAFT EDNS0 March 2008 - - -Full Copyright Statement - -Copyright (C) IETF Trust (2007). - -This document is subject to the rights, licenses and restrictions -contained in BCP 78, and except as set forth therein, the authors retain -all their rights. - -This document and the information contained herein are provided on an -"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR -IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE -INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE -INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED -WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - -The IETF takes no position regarding the validity or scope of any -Intellectual Property Rights or other rights that might be claimed to -pertain to the implementation or use of the technology described in this -document or the extent to which any license under such rights might or -might not be available; nor does it represent that it has made any -independent effort to identify any such rights. Information on the -procedures with respect to rights in RFC documents can be found in BCP -78 and BCP 79. - -Copies of IPR disclosures made to the IETF Secretariat and any -assurances of licenses to be made available, or the result of an attempt -made to obtain a general license or permission for the use of such -proprietary rights by implementers or users of this specification can be -obtained from the IETF on-line IPR repository at -http://www.ietf.org/ipr. - -The IETF invites any interested party to bring to its attention any -copyrights, patents or patent applications, or other proprietary rights -that may cover technology that may be required to implement this -standard. Please address the information to the IETF at -ietf-ipr@ietf.org. - -Acknowledgement - -Funding for the RFC Editor function is provided by the IETF -Administrative Support Activity (IASA). - - - - -Expires September 2008 [Page 9] - \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt new file mode 100644 index 0000000000..ba1b4147f4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt @@ -0,0 +1,616 @@ + + + +DNSEXT Working Group M. Graff +Internet-Draft P. Vixie +Obsoletes: 2671 (if approved) Internet Systems Consortium +Intended status: Standards Track July 28, 2009 +Expires: January 29, 2010 + + + Extension Mechanisms for DNS (EDNS0) + draft-ietf-dnsext-rfc2671bis-edns0-02 + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 29, 2010. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + The Domain Name System's wire protocol includes a number of fixed + fields whose range has been or soon will be exhausted and does not + + + +Graff & Vixie Expires January 29, 2010 [Page 1] + +Internet-Draft EDNS0 Extensions July 2009 + + + allow requestors to advertise their capabilities to responders. This + document describes backward compatible mechanisms for allowing the + protocol to grow. + + This document updates the EDNS0 specification based on 10 years of + operational experience. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 + 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 + 4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 3 + 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3 + 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 + 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 + 6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 4 + 6.1. OPT Record Behavior . . . . . . . . . . . . . . . . . . . 4 + 6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5 + 6.3. Requestor's Payload Size . . . . . . . . . . . . . . . . . 6 + 6.4. Responder's Payload Size . . . . . . . . . . . . . . . . . 6 + 6.5. Payload Size Selection . . . . . . . . . . . . . . . . . . 7 + 6.6. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 7 + 6.7. Extended RCODE . . . . . . . . . . . . . . . . . . . . . . 7 + 6.8. OPT Options Type Allocation Procedure . . . . . . . . . . 8 + 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 + + + + + + + + + + + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 2] + +Internet-Draft EDNS0 Extensions July 2009 + + +1. Introduction + + DNS [RFC1035] specifies a Message Format and within such messages + there are standard formats for encoding options, errors, and name + compression. The maximum allowable size of a DNS Message is fixed. + Many of DNS's protocol limits are too small for uses which are or + which are desired to become common. There is no way for + implementations to advertise their capabilities. + + Unextended agents will not know how to interpret the protocol + extensions detailed here. In practice, these clients will be + upgraded when they have need of a new feature, and only new features + will make use of the extensions. Extended agents must be prepared + for behaviour of unextended clients in the face of new protocol + elements, and fall back gracefully to unextended DNS. [RFC2671] + originally proposed extensions to the basic DNS protocol to overcome + these deficiencies. This memo refines that specification and + obsoletes [RFC2671]. + + +2. Requirements Language + + 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 RFC 2119 [RFC2119]. + + +3. EDNS Support Requirement + + EDNS support is manditory in a modern world. DNSSEC requires EDNS + support, and many other featres are made possible only by EDNS + support to request or advertise them. + + +4. Affected Protocol Elements + +4.1. Message Header + + The DNS Message Header's (see , section 4.1.1 [RFC1035]) second full + 16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a + number of 1-bit flags. The original reserved Z bits have been + allocated to various purposes, and most of the RCODE values are now + in use. More flags and more possible RCODEs are needed. The OPT + pseudo-RR specified below contains subfields that carry a bit field + extension of the RCODE field and additional flag bits, respectively. + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 3] + +Internet-Draft EDNS0 Extensions July 2009 + + +4.2. Label Types + + The first two bits of a wire format domain label are used to denote + the type of the label. ,section 4.1.4 [RFC1035] allocates two of the + four possible types and reserves the other two. More label types + were proposed in [RFC2671] section 3. + +4.3. UDP Message Size + + DNS Messages are limited to 512 octets in size when sent over UDP. + While the minimum maximum reassembly buffer size still allows a limit + of 512 octets of UDP payload, most of the hosts now connected to the + Internet are able to reassemble larger datagrams. Some mechanism + must be created to allow requestors to advertise larger buffer sizes + to responders. To this end, the OPT pseudo-RR specified below + contains a maximum payload size field. + + +5. Extended Label Types + + The first octet in the on-the-wire representation of a DNS label + specifies the label type; the basic DNS specification [RFC1035] + dedicates the two most significant bits of that octet for this + purpose. + + This document reserves DNS label type 0b01 for use as an indication + for Extended Label Types. A specific extended label type is selected + by the 6 least significant bits of the first octet. Thus, Extended + Label Types are indicated by the values 64-127 (0b01xxxxxx) in the + first octet of the label. + + This document does not describe any specific Extended Label Type. + + In practice, Extended Label Types are difficult to use due to support + in clients and intermediate gateways. Therefore, the registry of + Extended Label Types is requested to be closed. They cause + interoperability problems and at present no defined label types are + in use. + + +6. OPT pseudo-RR + +6.1. OPT Record Behavior + + One OPT pseudo-RR (RR type 41) MAY be added to the additional data + section of a request. If present in requests, compliant responders + which implement EDNS MUST include an OPT record in non-truncated + responses, and SHOULD attempt to include them in all responses. An + + + +Graff & Vixie Expires January 29, 2010 [Page 4] + +Internet-Draft EDNS0 Extensions July 2009 + + + OPT is called a pseudo-RR because it pertains to a particular + transport level message and not to any actual DNS data. OPT RRs MUST + NOT be cached, forwarded, or stored in or loaded from master files. + The quantity of OPT pseudo-RRs per message MUST be either zero or + one, but not greater. + +6.2. OPT Record Format + + An OPT RR has a fixed part and a variable set of options expressed as + {attribute, value} pairs. The fixed part holds some DNS meta data + and also a small collection of basic extension elements which we + expect to be so popular that it would be a waste of wire space to + encode them as {attribute, value} pairs. + + The fixed part of an OPT RR is structured as follows: + + +------------+--------------+------------------------------+ + | Field Name | Field Type | Description | + +------------+--------------+------------------------------+ + | NAME | domain name | empty (root domain) | + | TYPE | u_int16_t | OPT | + | CLASS | u_int16_t | requestor's UDP payload size | + | TTL | u_int32_t | extended RCODE and flags | + | RDLEN | u_int16_t | describes RDATA | + | RDATA | octet stream | {attribute,value} pairs | + +------------+--------------+------------------------------+ + + OPT RR Format + + The variable part of an OPT RR is encoded in its RDATA and is + structured as zero or more of the following: + + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | OPTION-CODE | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | OPTION-LENGTH | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 4: | | + / OPTION-DATA / + / / + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 5] + +Internet-Draft EDNS0 Extensions July 2009 + + + OPTION-CODE + Assigned by Expert Review. + + OPTION-LENGTH + Size (in octets) of OPTION-DATA. + + OPTION-DATA + Varies per OPTION-CODE. + + Order of appearance of option tuples is never relevant. Any option + whose meaning is affected by other options is so affected no matter + which one comes first in the OPT RDATA. + + Any OPTION-CODE values not understood by a responder or requestor + MUST be ignored. Specifications of such options might wish to + include some kind of signalled acknowledgement. For example, an + option specification might say that if a responder sees option XYZ, + it SHOULD include option XYZ in its response. + +6.3. Requestor's Payload Size + + The requestor's UDP payload size (which OPT stores in the RR CLASS + field) is the number of octets of the largest UDP payload that can be + reassembled and delivered in the requestor's network stack. Note + that path MTU, with or without fragmentation, may be smaller than + this. Values lower than 512 MUST be treated as equal to 512. + + Note that a 512-octet UDP payload requires a 576-octet IP reassembly + buffer. Choosing 1280 for IPv4 over Ethernet would be reasonable. + The consequence of choosing too large a value may be an ICMP message + from an intermediate gateway, or even a silent drop of the response + message. + + The requestor's maximum payload size can change over time, and MUST + therefore not be cached for use beyond the transaction in which it is + advertised. + +6.4. Responder's Payload Size + + The responder's maximum payload size can change over time, but can be + reasonably expected to remain constant between two sequential + transactions; for example, a meaningless QUERY to discover a + responder's maximum UDP payload size, followed immediately by an + UPDATE which takes advantage of this size. (This is considered + preferrable to the outright use of TCP for oversized requests, if + there is any reason to suspect that the responder implements EDNS, + and if a request will not fit in the default 512 payload size limit.) + + + + +Graff & Vixie Expires January 29, 2010 [Page 6] + +Internet-Draft EDNS0 Extensions July 2009 + + +6.5. Payload Size Selection + + Due to transaction overhead, it is unwise to advertise an + architectural limit as a maximum UDP payload size. Just because your + stack can reassemble 64KB datagrams, don't assume that you want to + spend more than about 4KB of state memory per ongoing transaction. + + A requestor MAY choose to implement a fallback to smaller advertised + sizes to work around firewall or other network limitations. A + requestor SHOULD choose to use a fallback mechanism which begins with + a large size, such as 4096. If that fails, a fallback around the + 1220 byte range SHOULD be tried, as it has a reasonable chance to fit + within a single Ethernet frame. Failing that, a requestor MAY choose + a 512 byte packet, which with large answers may cause a TCP retry. + +6.6. Middleware Boxes + + Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes. + + Middleware boxes which simply forward requests to a recursive + resolver MUST NOT modify the OPT record contents in either direction. + +6.7. Extended RCODE + + The extended RCODE and flags (which OPT stores in the RR TTL field) + are structured as follows: + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | EXTENDED-RCODE | VERSION | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | DO| Z | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + EXTENDED-RCODE + Forms upper 8 bits of extended 12-bit RCODE. Note that + EXTENDED-RCODE value "0" indicates that an unextended RCODE is + in use (values "0" through "15"). + + VERSION + Indicates the implementation level of whoever sets it. Full + conformance with this specification is indicated by version + ``0.'' Requestors are encouraged to set this to the lowest + implemented level capable of expressing a transaction, to + minimize the responder and network load of discovering the + greatest common implementation level between requestor and + responder. A requestor's version numbering strategy MAY + ideally be a run time configuration option. + + + +Graff & Vixie Expires January 29, 2010 [Page 7] + +Internet-Draft EDNS0 Extensions July 2009 + + + If a responder does not implement the VERSION level of the + request, then it answers with RCODE=BADVERS. All responses + MUST be limited in format to the VERSION level of the request, + but the VERSION of each response SHOULD be the highest + implementation level of the responder. In this way a requestor + will learn the implementation level of a responder as a side + effect of every response, including error responses and + including RCODE=BADVERS. + + DO + DNSSEC OK bit as defined by [RFC3225]. + + Z + Set to zero by senders and ignored by receivers, unless + modified in a subsequent specification. + +6.8. OPT Options Type Allocation Procedure + + Allocations assigned by expert review. TBD + + +7. Transport Considerations + + The presence of an OPT pseudo-RR in a request should be taken as an + indication that the requestor fully implements the given version of + EDNS, and can correctly understand any response that conforms to that + feature's specification. + + Lack of presence of an OPT record in a request MUST be taken as an + indication that the requestor does not implement any part of this + specification and that the responder MUST NOT use any protocol + extension described here in its response. + + Responders who do not implement these protocol extensions MUST + respond with FORMERR messages without any OPT record. + + If there is a problem with processing the OPT record itself, such as + an option value that is badly formatted or includes out of range + values, a FORMERR MAY be retured. If this occurs the response MUST + include an OPT record. This MAY be used to distinguish between + servers whcih do not implement EDNS and format errors within EDNS. + + If EDNS is used in a request, and the response arrives with TC set + and with no EDNS OPT RR, a requestor SHOULD assume that truncation + prevented the OPT RR from being appended by the responder, and + further, that EDNS is not used in the response. Correspondingly, an + EDNS responder who cannot fit all necessary elements (including an + OPT RR) into a response, SHOULD respond with a normal (unextended) + + + +Graff & Vixie Expires January 29, 2010 [Page 8] + +Internet-Draft EDNS0 Extensions July 2009 + + + DNS response, possibly setting TC if the response will not fit in the + unextended response message's 512-octet size. + + +8. Security Considerations + + Requestor-side specification of the maximum buffer size may open a + new DNS denial of service attack if responders can be made to send + messages which are too large for intermediate gateways to forward, + thus leading to potential ICMP storms between gateways and + responders. + + Announcing very large UDP buffer sizes may result in dropping by + firewalls. This could cause retransmissions with no hope of success. + Some devices reject fragmented UDP packets. + + Announcing too small UDP buffer sizes may result in fallback to TCP. + This is especially important with DNSSEC, where answers are much + larger. + + +9. IANA Considerations + + The IANA has assigned RR type code 41 for OPT. + + [RFC2671] specified a number of IANA sub-registries within "DOMAIN + NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option + Codes", "EDNS Version Numbers", and "Domain System Response Code." + IANA is advised to re-parent these subregistries to this document. + + RFC 2671 created an extended label type registry. We request that + this registry be closed. + + This document assigns extended label type 0bxx111111 as "Reserved for + future extended label types." We request that IANA record this + assignment. + + This document assigns option code 65535 to "Reserved for future + expansion." + + This document expands the RCODE space from 4 bits to 12 bits. This + will allow IANA to assign more than the 16 distinct RCODE values + allowed in RFC 1035 [RFC1035]. + + This document assigns EDNS Extended RCODE "16" to "BADVERS". + + IESG approval should be required to create new entries in the EDNS + Extended Label Type or EDNS Version Number registries, while any + + + +Graff & Vixie Expires January 29, 2010 [Page 9] + +Internet-Draft EDNS0 Extensions July 2009 + + + published RFC (including Informational, Experimental, or BCP) should + be grounds for allocation of an EDNS Option Code. + + +10. Acknowledgements + + Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, + Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas + Narten were each instrumental in creating and refining this + specification. + + +11. References + +11.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", + RFC 3225, December 2001. + +11.2. Informative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +Authors' Addresses + + Michael Graff + Internet Systems Consortium + 950 Charter Street + Redwood City, California 94063 + US + + Phone: +1 650.423.1304 + Email: mgraff@isc.org + + + + + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 10] + +Internet-Draft EDNS0 Extensions July 2009 + + + Paul Vixie + Internet Systems Consortium + 950 Charter Street + Redwood City, California 94063 + US + + Phone: +1 650.423.1301 + Email: vixie@isc.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Graff & Vixie Expires January 29, 2010 [Page 11] + From f6566e9ec2d32748e779f2350fab88782eef953f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 19 Nov 2009 05:15:35 +0000 Subject: [PATCH 15/18] cleanup --- doc/draft/draft-ietf-dnsext-mdns-46.txt | 1801 ----------------- .../draft-ietf-dnsext-rfc2536bis-dsa-07.txt | 464 ----- .../draft-ietf-dnsext-rfc2539bis-dhk-07.txt | 580 ------ ...xt-signed-nonexistence-requirements-01.txt | 755 ------- ...draft-ietf-dnsext-tkey-renewal-mode-05.txt | 1292 ------------ 5 files changed, 4892 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-mdns-46.txt delete mode 100644 doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt delete mode 100644 doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt delete mode 100644 doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt diff --git a/doc/draft/draft-ietf-dnsext-mdns-46.txt b/doc/draft/draft-ietf-dnsext-mdns-46.txt deleted file mode 100644 index 63d0b23af6..0000000000 --- a/doc/draft/draft-ietf-dnsext-mdns-46.txt +++ /dev/null @@ -1,1801 +0,0 @@ - - - - - - -DNSEXT Working Group Bernard Aboba -INTERNET-DRAFT Dave Thaler -Category: Standards Track Levon Esibov - Microsoft Corporation -16 April 2006 - - Linklocal Multicast Name Resolution (LLMNR) - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on October 15, 2006. - -Copyright Notice - - Copyright (C) The Internet Society 2006. - -Abstract - - 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. - - - - - -Aboba, Thaler & Esibov Standards Track [Page 1] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -Table of Contents - -1. Introduction .......................................... 3 - 1.1 Requirements .................................... 4 - 1.2 Terminology ..................................... 4 -2. Name Resolution Using LLMNR ........................... 4 - 2.1 LLMNR Packet Format ............................. 5 - 2.2 Sender Behavior ................................. 8 - 2.3 Responder Behavior .............................. 8 - 2.4 Unicast Queries and Responses ................... 11 - 2.5 Off-link Detection .............................. 11 - 2.6 Responder Responsibilities ...................... 12 - 2.7 Retransmission and Jitter ....................... 13 - 2.8 DNS TTL ......................................... 14 - 2.9 Use of the Authority and Additional Sections .... 14 -3. Usage model ........................................... 15 - 3.1 LLMNR Configuration ............................. 16 -4. Conflict Resolution ................................... 18 - 4.1 Uniqueness Verification ......................... 18 - 4.2 Conflict Detection and Defense .................. 19 - 4.3 Considerations for Multiple Interfaces .......... 20 - 4.4 API issues ...................................... 22 -5. Security Considerations ............................... 22 - 5.1 Denial of Service ............................... 22 - 5.2 Spoofing ...............,........................ 23 - 5.3 Authentication .................................. 24 - 5.4 Cache and Port Separation ....................... 24 -6. IANA considerations ................................... 25 -7. Constants ............................................. 25 -8. References ............................................ 26 - 8.1 Normative References ............................ 26 - 8.2 Informative References .......................... 26 -Acknowledgments .............................................. 28 -Authors' Addresses ........................................... 28 -Intellectual Property Statement .............................. 29 -Disclaimer of Validity ....................................... 29 -Copyright Statement .......................................... 29 - - - - - - - - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 2] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -1. Introduction - - 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. - - Since LLMNR only operates on the local link, it cannot be considered - a substitute for DNS. Link-scope multicast addresses are used to - prevent propagation of LLMNR traffic across routers, potentially - flooding the network. LLMNR queries can also be sent to a unicast - address, as described in Section 2.4. - - Propagation of LLMNR packets on the local link is considered - sufficient to enable name resolution in small networks. In such - networks, if a network has a gateway, then typically the network is - able to provide DNS server configuration. Configuration issues are - discussed in Section 3.1. - - In the future, it may be desirable to consider use of multicast name - resolution with multicast scopes beyond the link-scope. This could - occur if LLMNR deployment is successful, the need arises for - multicast name resolution beyond the link-scope, or multicast routing - becomes ubiquitous. For example, expanded support for multicast name - resolution might be required for mobile ad-hoc networks. - - Once we have experience in LLMNR deployment in terms of - administrative issues, usability and impact on the network, it will - be possible to reevaluate which multicast scopes are appropriate for - use with multicast name resolution. IPv4 administratively scoped - multicast usage is specified in "Administratively Scoped IP - Multicast" [RFC2365]. - - Service discovery in general, as well as discovery of DNS servers - using LLMNR in particular, is outside of the scope of this document, - as is name resolution over non-multicast capable media. - -1.1. Requirements - - In this document, several words are used to signify the requirements - of the specification. 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]. - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 3] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -1.2. Terminology - - This document assumes familiarity with DNS terminology defined in - [RFC1035]. Other terminology used in this document includes: - -Routable Address - An address other than a Link-Local address. This includes globally - routable addresses, as well as private addresses. - -Reachable - An LLMNR responder considers one of its addresses reachable over a - link if it will respond to an ARP or Neighbor Discovery query for - that address received on that link. - -Responder - A host that listens to LLMNR queries, and responds to those for - which it is authoritative. - -Sender - A host that sends an LLMNR query. - -UNIQUE - There are some scenarios when multiple responders may respond to - the same query. There are other scenarios when only one responder - may respond to a query. Names for which only a single responder is - anticipated are referred to as UNIQUE. Name uniqueness is - configured on the responder, and therefore uniqueness verification - is the responder's responsibility. - -2. Name Resolution Using LLMNR - - LLMNR queries are sent to and received on port 5355. The IPv4 link- - scope multicast address a given responder listens to, and to which a - sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast - address a given responder listens to, and to which a sender sends all - queries, is FF02:0:0:0:0:0:1:3. - - Typically a host is configured as both an LLMNR sender and a - responder. A host MAY be configured as a sender, but not a - responder. 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. This document does not specify how names are chosen or - configured. This may occur via any mechanism, including DHCPv4 - [RFC2131] or DHCPv6 [RFC3315]. - - A typical sequence of events for LLMNR usage is as follows: - - [a] An LLMNR sender sends an LLMNR query to the link-scope - - - -Aboba, Thaler & Esibov Standards Track [Page 4] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - multicast address(es), unless a unicast query is indicated, - as specified in Section 2.4. - - [b] A responder responds to this query only if it is authoritative - for the name in the query. A responder responds to a - multicast query by sending a unicast UDP response to the sender. - Unicast queries are responded to as indicated in Section 2.4. - - [c] Upon reception of the response, the sender processes it. - - The sections that follow provide further details on sender and - responder behavior. - -2.1. LLMNR Packet Format - - LLMNR is based on the DNS packet format defined in [RFC1035] Section - 4 for both queries and responses. LLMNR implementations SHOULD send - UDP queries and responses only as large as are known to be - permissible without causing fragmentation. When in doubt a maximum - packet size of 512 octets SHOULD be used. 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). - -2.1.1. LLMNR Header Format - - LLMNR queries and responses utilize the DNS header format defined in - [RFC1035] with exceptions noted below: - - 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 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - where: - - - - - -Aboba, Thaler & Esibov Standards Track [Page 5] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -ID A 16 bit identifier assigned by the program that generates any kind - of query. This identifier is copied from the query to the response - and can be used by the sender to match responses to outstanding - queries. The ID field in a query SHOULD be set to a pseudo-random - value. For advice on generation of pseudo-random values, please - consult [RFC1750]. - -QR Query/Response. A one bit field, which if set indicates that the - message is an LLMNR response; if clear then the message is an LLMNR - query. - -OPCODE - A four bit field that specifies the kind of query in this message. - This value is set by the originator of a query and copied into the - response. This specification defines the behavior of standard - queries and responses (opcode value of zero). Future - specifications may define the use of other opcodes with LLMNR. - LLMNR senders and responders MUST support standard queries (opcode - value of zero). LLMNR queries with unsupported OPCODE values MUST - be silently discarded by responders. - -C Conflict. When set within a request, the 'C'onflict bit indicates - that a sender has received multiple LLMNR responses to this query. - In an LLMNR response, if the name is considered UNIQUE, then the - 'C' bit is clear, otherwise it is set. LLMNR senders do not - retransmit queries with the 'C' bit set. Responders MUST NOT - respond to LLMNR queries with the 'C' bit set, but may start the - uniqueness verification process, as described in Section 4.2. - -TC TrunCation - specifies that this message was truncated due to - length greater than that permitted on the transmission channel. - The TC bit MUST NOT be set in an LLMNR query and if set is ignored - by an LLMNR responder. If the TC bit is set in an LLMNR response, - then the sender SHOULD resend the LLMNR query over TCP using the - unicast address of the responder as the destination address. If - the sender receives a response to the TCP query, then it SHOULD - discard the UDP response with the TC bit set. See [RFC2181] and - Section 2.4 of this specification for further discussion of the TC - bit. - -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 the name. A responder MUST ignore the 'T' bit in - a query, if set. A response with the 'T' bit set is silently - discarded by the sender, except if it is a uniqueness query, in - which case a conflict has been detected and a responder MUST - resolve the conflict as described in Section 4.1. - - - - -Aboba, Thaler & Esibov Standards Track [Page 6] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -Z Reserved for future use. Implementations of this specification - MUST set these bits to zero in both queries and responses. If - these bits are set in a LLMNR query or response, implementations of - this specification MUST ignore them. Since reserved bits could - conceivably be used for different purposes than in DNS, - implementors are advised not to enable processing of these bits in - an LLMNR implementation starting from a DNS code base. - -RCODE - Response code -- this 4 bit field is set as part of LLMNR - responses. In an LLMNR query, the sender MUST set RCODE to zero; - the responder ignores the RCODE and assumes it to be zero. The - response to a multicast LLMNR query MUST have RCODE set to zero. A - sender MUST silently discard an LLMNR response with a non-zero - RCODE sent in response to a multicast query. - - 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. This - may be required, for example, when an LLMNR query includes a TSIG - RR in the additional section, and the responder encounters a - problem that requires returning a non-zero RCODE. TSIG error - conditions defined in [RFC2845] include a TSIG RR in an - unacceptable position (RCODE=1) or a TSIG RR which does not - validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)). - - Since LLMNR responders only respond to LLMNR queries for names for - which they are authoritative, LLMNR responders MUST NOT respond - with an RCODE of 3; instead, they should not respond at all. - - LLMNR implementations MUST support EDNS0 [RFC2671] and extended - RCODE values. - -QDCOUNT - An unsigned 16 bit integer specifying the number of entries in the - question section. A sender MUST place only one question into the - question section of an LLMNR query. LLMNR responders MUST silently - discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders - MUST silently discard LLMNR responses with QDCOUNT not equal to - one. - -ANCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the answer section. LLMNR responders MUST silently - - - -Aboba, Thaler & Esibov Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - discard LLMNR queries with ANCOUNT not equal to zero. - -NSCOUNT - An unsigned 16 bit integer specifying the number of name server - resource records in the authority records section. Authority - record section processing is described in Section 2.9. LLMNR - responders MUST silently discard LLMNR queries with NSCOUNT not - equal to zero. - -ARCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the additional records section. Additional record - section processing is described in Section 2.9. - -2.2. Sender Behavior - - A sender MAY send an LLMNR query for any legal resource record type - (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. - As described in Section 2.4, a sender MAY also send a unicast query. - - The sender MUST anticipate receiving no replies to some LLMNR - queries, in the event that no responders are available within the - link-scope. If no response is received, a resolver treats it as a - response that the name does not exist (RCODE=3 is returned). A - sender can handle duplicate responses by discarding responses with a - source IP address and ID field that duplicate a response already - received. - - When multiple valid LLMNR responses are received with the 'C' bit - set, they SHOULD be concatenated and treated in the same manner that - multiple RRs received from the same DNS server would be. However, - responses with the 'C' bit set SHOULD NOT be concatenated with - responses with the 'C' bit clear; instead, only the responses with - the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are - received along with error response(s), then the error responses are - silently discarded. - - Since the responder may order the RRs in the response so as to - indicate preference, the sender SHOULD preserve ordering in the - response to the querying application. - -2.3. Responder Behavior - - An LLMNR response MUST be sent to the sender via unicast. - - 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 - - - -Aboba, Thaler & Esibov Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - responder has another RR in addition to the SOA RR; the SOA RR MUST - NOT be the only RR that a responder has. However, in general whether - RRs are manually or automatically created is an implementation - decision. - - 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 - - host1.example.com. IN A 192.0.2.1 - IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - 1.2.0.192.in-addr.arpa. IN PTR host1. - IN PTR host1.example.com. - - 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. - ip6.arpa IN PTR host1. (line split for formatting reasons) - IN PTR host1.example.com. - - An LLMNR responder might be further manually configured with the name - of a local mail server with an MX RR included in the "host1." and - "host1.example.com." records. - - In responding to queries: - -[a] Responders MUST listen on UDP port 5355 on the link-scope multicast - address(es) defined in Section 2, and on TCP port 5355 on the - unicast address(es) that could be set as the source address(es) - when the responder responds to the LLMNR query. - -[b] Responders MUST direct responses to the port from which the query - was sent. When queries are received via TCP this is an inherent - part of the transport protocol. For queries received by UDP the - responder MUST take note of the source port and use that as the - destination port in the response. Responses MUST always be sent - from the port to which they were directed. - -[c] Responders MUST respond to LLMNR queries for names and addresses - they are authoritative for. This applies to both forward and - reverse lookups, with the exception of queries with the 'C' bit - set, which do not elicit a response. - -[d] Responders MUST NOT respond to LLMNR queries for names they are not - authoritative for. - - - -Aboba, Thaler & Esibov Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -[e] Responders MUST NOT respond using data from the LLMNR or DNS - resolver cache. - -[f] If a DNS server is running on a host that supports LLMNR, the DNS - server MUST respond to LLMNR queries only for the RRSets relating - to the host on which the server is running, but MUST NOT respond - for other records for which the server is authoritative. DNS - servers also MUST NOT send LLMNR queries in order to resolve DNS - queries. - -[g] If a responder is authoritative for a name, it MUST respond with - RCODE=0 and an empty answer section, if the type of query does not - match a RR that the responder has. - - As an example, a host configured to respond to LLMNR queries for the - name "foo.example.com." is authoritative for the name - "foo.example.com.". On receiving an LLMNR query for an A RR with the - name "foo.example.com." the host authoritatively responds with A - RR(s) that contain IP address(es) in the RDATA of the resource - record. If the responder has a AAAA RR, but no A RR, and an A RR - query is received, the responder would respond with RCODE=0 and an - empty answer section. - - In conventional DNS terminology a DNS server authoritative for a zone - is authoritative for all the domain names under the zone apex except - for the branches delegated into separate zones. Contrary to - conventional DNS terminology, an LLMNR responder is authoritative - only for the zone apex. - - For example the host "foo.example.com." is not authoritative for the - name "child.foo.example.com." unless the host is configured with - multiple names, including "foo.example.com." and - "child.foo.example.com.". As a result, "foo.example.com." cannot - reply to an LLMNR query for "child.foo.example.com." with RCODE=3 - (authoritative name error). The purpose of limiting the name - authority scope of a responder is to prevent complications that could - be caused by coexistence of two or more hosts with the names - representing child and parent (or grandparent) nodes in the DNS tree, - for example, "foo.example.com." and "child.foo.example.com.". - - Without the restriction on authority an LLMNR query for an A resource - record for the name "child.foo.example.com." would result in two - authoritative responses: RCODE=3 (authoritative name error) received - from "foo.example.com.", and a requested A record - from - "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled - hosts could perform a dynamic update of the parent (or grandparent) - zone with a delegation to a child zone; for example a host - "child.foo.example.com." could send a dynamic update for the NS and - - - -Aboba, Thaler & Esibov Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - glue A record to "foo.example.com.". However, this approach - significantly complicates implementation of LLMNR and would not be - acceptable for lightweight hosts. - -2.4. Unicast Queries and Responses - - Unicast queries SHOULD be sent when: - - [a] A sender repeats a query after it received a response - with the TC bit set to the previous LLMNR multicast query, or - - [b] The sender queries for a PTR RR of a fully formed IP address - within the "in-addr.arpa" or "ip6.arpa" zones. - - 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. - - A unicast PTR RR query for an off-link address will not elicit a - response, but instead an ICMP TTL or Hop Limit exceeded message will - be received. An implementation receiving an ICMP message in response - to a TCP connection setup attempt can return immediately, treating - this as a response that no such name exists (RCODE=3 is returned). - An implementation that cannot process ICMP messages MAY send - multicast UDP queries for PTR RRs. Since TCP implementations will - not retransmit prior to RTOmin, a considerable period will elapse - before TCP retransmits multiple times, resulting in a long timeout - for TCP PTR RR queries sent to an off-link destination. - -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. - - On receiving an LLMNR query, the responder MUST check whether it was - sent to a LLMNR multicast addresses defined in Section 2. If it was - sent to another multicast address, then the query MUST be silently - discarded. - - - -Aboba, Thaler & Esibov Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - 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. - - 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 early implementations of [RFC3927]. - - Implementation note: - - In the sockets API for IPv4 [POSIX], the IP_TTL and - IP_MULTICAST_TTL socket options are used to set the TTL of - outgoing unicast and multicast packets. The IP_RECVTTL socket - option is available on some platforms to retrieve the IPv4 TTL of - received packets with recvmsg(). [RFC2292] specifies similar - options for setting and retrieving the IPv6 Hop Limit. - -2.6. Responder Responsibilities - - It is the responsibility of the responder to ensure that RRs returned - in LLMNR responses MUST only include values that are valid on the - local interface, such as IPv4 or IPv6 addresses valid on the local - link or names defended using the mechanism described in Section 4. - IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local - addresses are defined in [RFC2373]. In particular: - - [a] If a link-scope IPv6 address is returned in a AAAA RR, - that address MUST be valid on the local link over which - LLMNR is used. - - [b] If an IPv4 address is returned, it MUST be reachable - through the link over which LLMNR is used. - - [c] If a name is returned (for example in a CNAME, MX - or SRV RR), the name MUST be resolvable on the local - link over which LLMNR is used. - - Where multiple addresses represent valid responses to a query, the - order in which the addresses are returned is as follows: - - [d] If the source address of the query is a link-scope address, - then the responder SHOULD include a link-scope address first - - - -Aboba, Thaler & Esibov Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - in the response, if available. - - [e] If the source address of the query is a routable address, - then the responder MUST include a routable address first - in the response, if available. - -2.7. Retransmission and Jitter - - An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine - when to retransmit an LLMNR query. An LLMNR sender SHOULD either - estimate the LLMNR_TIMEOUT for each interface, or set a reasonably - high initial timeout. Suggested constants are described in Section - 7. - - 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. - An LLMNR query SHOULD NOT be sent more than three times. - - Where LLMNR queries are sent using TCP, retransmission is handled by - the transport layer. Queries with the 'C' bit set MUST be sent using - multicast UDP and MUST NOT be retransmitted. - - 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 + JITTER_INTERVAL 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. - - 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, 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 - - - -Aboba, Thaler & Esibov Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - responders responding with names which they have previously - determined to be UNIQUE (see Section 4 for details). - -2.8. DNS TTL - - The responder should insert a pre-configured TTL value in the records - returned in an LLMNR response. A default value of 30 seconds is - RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc - networks), the TTL value may need to be reduced. - - Due to the TTL minimalization necessary when caching an RRset, all - TTLs in an RRset MUST be set to the same value. - -2.9. Use of the Authority and Additional Sections - - Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a - concept of delegation. In LLMNR, the NS resource record type may be - stored and queried for like any other type, but it has no special - delegation semantics as it does in the DNS. Responders MAY have NS - records associated with the names for which they are authoritative, - but they SHOULD NOT include these NS records in the authority - sections of responses. - - Responders SHOULD insert an SOA record into the authority section of - a negative response, to facilitate negative caching as specified in - [RFC2308]. The TTL of this record is set from the minimum of the - MINIMUM field of the SOA record and the TTL of the SOA itself, and - indicates how long a resolver may cache the negative answer. The - owner name of the SOA record (MNAME) MUST be set to the query name. - The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored - by senders. Negative responses without SOA records SHOULD NOT be - cached. - - In LLMNR, the additional section is primarily intended for use by - EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, - senders MAY only include pseudo RR-types in the additional section of - a query; unless the 'C' bit is set, responders MUST ignore the - additional section of queries containing other RR types. - - In queries where the 'C' bit is set, the sender SHOULD include the - conflicting RRs in the additional section. Since conflict - notifications are advisory, responders SHOULD log information from - the additional section, but otherwise MUST ignore the additional - section. - - Senders MUST NOT cache RRs from the authority or additional section - of a response as answers, though they may be used for other purposes - such as negative caching. - - - -Aboba, Thaler & Esibov Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -3. Usage Model - - LLMNR is a peer-to-peer name resolution protocol that is not intended - as a replacement for DNS; rather, it enables name resolution in - scenarios in which conventional DNS name resolution is not possible. - This includes 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. - - By default, an LLMNR sender SHOULD send LLMNR queries only for - single-label names. In order to reduce unnecessary DNS queries, stub - resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS - queries for single-label names. An LLMNR sender SHOULD NOT be - enabled to send a query for any name, except where security - mechanisms (described in Section 5.3) can be utilized. - - Regardless of whether security mechanisms can be utilized, LLMNR - queries SHOULD NOT be sent unless 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, a - host SHOULD attempt to reach DNS servers over all protocols - on which DNS server address(es) are configured, prior to sending - LLMNR queries. 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 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. Where a - single resolver call generates DNS queries for A and AAAA RRs, - an implementation MAY choose not to send LLMNR queries if any - of the DNS queries is successful. An LLMNR query SHOULD only - be sent for the originally requested name; a searchlist - is not used to form additional LLMNR queries. - - Since LLMNR is a secondary name resolution mechanism, its usage is in - part determined by the behavior of DNS implementations. In general, - robust DNS resolver implementations are more likely to avoid - unnecessary LLMNR queries. - - As noted in [DNSPerf], even when DNS servers are configured, a - - - -Aboba, Thaler & Esibov Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - significant fraction of DNS queries do not receive a response, or - result in negative responses due to missing inverse mappings or NS - records that point to nonexistent or inappropriate hosts. This has - the potential to result in a large number of unnecessary LLMNR - queries. - - [RFC1536] describes common DNS implementation errors and fixes. If - the proposed fixes are implemented, unnecessary LLMNR queries will be - reduced substantially, and so implementation of [RFC1536] is - recommended. - - For example, [RFC1536] Section 1 describes issues with retransmission - and recommends implementation of a retransmission policy based on - round trip estimates, with exponential back-off. [RFC1536] Section 4 - describes issues with failover, and recommends that resolvers try - another server when they don't receive a response to a query. These - policies are likely to avoid unnecessary LLMNR queries. - - [RFC1536] Section 3 describes zero answer bugs, which if addressed - will also reduce unnecessary LLMNR queries. - - [RFC1536] Section 6 describes name error bugs and recommended - searchlist processing that will reduce unnecessary RCODE=3 - (authoritative name) errors, thereby also reducing unnecessary LLMNR - queries. - - If error responses are received from both DNS and LLMNR, then the - lowest RCODE value should be returned. For example, if either DNS or - LLMNR receives a response with RCODE=0, then this should returned to - the caller. - -3.1. LLMNR Configuration - - LLMNR usage MAY be configured manually or automatically on a per - interface basis. By default, LLMNR responders SHOULD be enabled on - all interfaces, at all times. Enabling LLMNR for use in situations - where a DNS server has been configured will result in a change in - default behavior without a simultaneous update to configuration - information. Where this is considered undesirable, LLMNR SHOULD NOT - be enabled by default, so that hosts will neither listen on the link- - scope multicast address, nor will they send queries to that address. - - Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is - possible for a dual stack host to be configured with the address of a - DNS server over IPv4, while remaining unconfigured with a DNS server - suitable for use over IPv6. - - In these situations, a dual stack host will send AAAA queries to the - - - -Aboba, Thaler & Esibov Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - configured DNS server over IPv4. However, an IPv6-only host - unconfigured with a DNS server suitable for use over IPv6 will be - unable to resolve names using DNS. Automatic IPv6 DNS configuration - mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely - deployed, and not all DNS servers support IPv6. Therefore lack of - IPv6 DNS configuration may be a common problem in the short term, and - LLMNR may prove useful in enabling link-local name resolution over - IPv6. - - Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], - IPv6-only hosts may not be configured with a DNS server. Where there - is no DNS server authoritative for the name of a host or the - authoritative DNS server does not support dynamic client update over - IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not - be able to do DNS dynamic update, and other hosts will not be able to - resolve its name. - - For example, if the configured DNS server responds to a AAAA RR query - sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or - RCODE=0 and an empty answer section, then a AAAA RR query sent using - LLMNR over IPv6 may be successful in resolving the name of an - IPv6-only host on the local link. - - Similarly, if a DHCPv4 server is available providing DNS server - configuration, and DNS server(s) exist which are authoritative for - the A RRs of local hosts and support either dynamic client update - over IPv4 or DHCPv4-based dynamic update, then the names of local - IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no - DNS server is authoritative for the names of local hosts, or the - authoritative DNS server(s) do not support dynamic update, then LLMNR - enables linklocal name resolution over IPv4. - - Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to - configure LLMNR on an interface. The LLMNR Enable Option, described - in [LLMNREnable], can be used to explicitly enable or disable use of - LLMNR on an interface. The LLMNR Enable Option does not determine - whether or in which order DNS itself is used for name resolution. - The order in which various name resolution mechanisms should be used - can be specified using the Name Service Search Option (NSSO) for DHCP - [RFC2937], using the LLMNR Enable Option code carried in the NSSO - data. - - It is possible that DNS configuration mechanisms will go in and out - of service. In these circumstances, it is possible for hosts within - an administrative domain to be inconsistent in their DNS - configuration. - - For example, where DHCP is used for configuring DNS servers, one or - - - -Aboba, Thaler & Esibov Standards Track [Page 17] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - more DHCP servers can fail. As a result, hosts configured prior to - the outage will be configured with a DNS server, while hosts - configured after the outage will not. Alternatively, it is possible - for the DNS configuration mechanism to continue functioning while - configured DNS servers fail. - - An outage in the DNS configuration mechanism may result in hosts - continuing to use LLMNR even once the outage is repaired. Since - LLMNR only enables linklocal name resolution, this represents a - degradation in capabilities. As a result, hosts without a configured - DNS server may wish to periodically attempt to obtain DNS - configuration if permitted by the configuration mechanism in use. In - the absence of other guidance, a default retry interval of one (1) - minute is RECOMMENDED. - -4. Conflict Resolution - - 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). - - To detect duplicate use of a name, an administrator can use a name - resolution utility which employs LLMNR and lists both responses and - responders. This would allow an administrator to diagnose behavior - and potentially to intervene and reconfigure LLMNR responders who - should not be configured to respond to the same name. - -4.1. Uniqueness Verification - - 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. - - Uniqueness verification is carried out when the host: - - - starts up or is rebooted - - wakes from sleep (if the network interface was inactive - during sleep) - - is configured to respond to LLMNR queries on an interface - - - -Aboba, Thaler & Esibov Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - enabled for transmission and reception of IP traffic - - is configured to respond to LLMNR queries using additional - UNIQUE resource records - - verifies the acquisition of a new IP address and configuration - on an interface - - To verify uniqueness, a responder MUST send an LLMNR query with the - 'C' bit clear, over all protocols on which it responds to LLMNR - queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify - uniqueness of a name by sending a query for the name with type='ANY'. - - 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. To avoid triggering conflict - detection, a responder that detects that it is connected to the same - link on multiple interfaces SHOULD set the 'C' bit in responses. - - 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. If so, the responder MUST NOT use the name - in response to LLMNR queries received over any protocol (IPv4 or - IPv6). For the purpose of uniqueness verification, the contents of - the answer section in a response is irrelevant. - - Periodically carrying out uniqueness verification in an attempt to - detect name conflicts is not necessary, wastes network bandwidth, and - may actually be detrimental. For example, if network links are - joined only briefly, and are separated again before any new - communication is initiated, temporary conflicts are benign and no - forced reconfiguration is required. LLMNR responders SHOULD NOT - periodically attempt uniqueness verification. - -4.2. Conflict Detection and Defense - - Hosts on disjoint network links may configure the same name for use - with LLMNR. If these separate network links are later joined or - bridged together, then there may be multiple hosts which are now on - the same link, trying to use the same name. - - 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 - - - -Aboba, Thaler & Esibov Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - time with the 'C' bit set, with the potentially conflicting resource - records included in the additional section. - - Queries with the 'C' bit set are considered advisory and responders - MUST verify the existence of a conflict before acting on it. A - responder receiving a query with the 'C' bit set MUST NOT respond. - - 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, 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. To avoid triggering conflict detection, a responder that - detects that it is connected to the same link on multiple interfaces - SHOULD set the 'C' bit in responses. - - An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD - log them. Upon detecting a conflict, an LLMNR responder MUST - immediately stop using the conflicting name in response to LLMNR - queries received over any supported protocol, if the source IP - address in the response, interpreted as an unsigned integer, is less - than the source IP address in the uniqueness verification query. - - 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. - -4.3. Considerations for Multiple Interfaces - - A multi-homed host may elect to configure LLMNR on only one of its - active interfaces. In many situations this will be adequate. - However, should a host need to configure LLMNR on more than one of - its active interfaces, there are some additional precautions it MUST - take. Implementers who are not planning to support LLMNR on multiple - interfaces simultaneously may skip this section. - - Where a host is configured to issue LLMNR queries on more than one - interface, each interface maintains its own independent LLMNR - resolver cache, containing the responses to LLMNR queries. - - A multi-homed host checks the uniqueness of UNIQUE records as - described in Section 4. The situation is illustrated in figure 1. - - - - - -Aboba, Thaler & Esibov Standards Track [Page 20] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - ---------- ---------- - | | | | - [A] [myhost] [myhost] - - Figure 1. Link-scope name conflict - - In this situation, the multi-homed myhost will probe for, and defend, - its host name on both interfaces. A conflict will be detected on one - interface, but not the other. The multi-homed myhost will not be - able to respond with a host RR for "myhost" on the interface on the - right (see Figure 1). The multi-homed host may, however, be - configured to use the "myhost" name on the interface on the left. - - Since names are only unique per-link, hosts on different links could - be using the same name. If an LLMNR client sends requests over - multiple interfaces, and receives replies from more than one, the - result returned to the client is defined by the implementation. The - situation is illustrated in figure 2. - - ---------- ---------- - | | | | - [A] [myhost] [A] - - - Figure 2. Off-segment name conflict - - If host myhost is configured to use LLMNR on both interfaces, it will - send LLMNR queries on both interfaces. When host myhost sends a - query for the host RR for name "A" it will receive a response from - hosts on both interfaces. - - Host myhost cannot distinguish between the situation shown in Figure - 2, and that shown in Figure 3 where no conflict exists. - - [A] - | | - ----- ----- - | | - [myhost] - - Figure 3. Multiple paths to same host - - This illustrates that the proposed name conflict resolution mechanism - does not support detection or resolution of conflicts between hosts - on different links. This problem can also occur with DNS when a - multi-homed host is connected to two different networks with - separated name spaces. It is not the intent of this document to - address the issue of uniqueness of names within DNS. - - - -Aboba, Thaler & Esibov Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -4.4. API Issues - - [RFC2553] provides an API which can partially solve the name - ambiguity problem for applications written to use this API, since the - sockaddr_in6 structure exposes the scope within which each scoped - address exists, and this structure can be used for both IPv4 (using - v4-mapped IPv6 addresses) and IPv6 addresses. - - Following the example in Figure 2, an application on 'myhost' issues - the request getaddrinfo("A", ...) with ai_family=AF_INET6 and - ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both - interfaces and the resolver library will return a list containing - multiple addrinfo structures, each with an associated sockaddr_in6 - structure. This list will thus contain the IPv4 and IPv6 addresses - of both hosts responding to the name 'A'. Link-local addresses will - have a sin6_scope_id value that disambiguates which interface is used - to reach the address. Of course, to the application, Figures 2 and 3 - are still indistinguishable, but this API allows the application to - communicate successfully with any address in the list. - -5. Security Considerations - - LLMNR is a peer-to-peer name resolution protocol designed for use on - the local link. While LLMNR limits the vulnerability of responders - to off-link senders, it is possible for an off-link responder to - reach a sender. - - 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 network, while wireless attackers may mount - attacks from a distance. Link-layer security such as [IEEE-802.11i] - 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. Denial of Service - - Attackers may take advantage of LLMNR conflict detection by - allocating the same name, denying service to other LLMNR responders - and possibly allowing an attacker to receive packets destined for - other hosts. By logging conflicts, LLMNR responders can provide - forensic evidence of these attacks. - - An attacker may spoof LLMNR queries from a victim's address in order - to mount a denial of service attack. Responders setting the IPv6 Hop - Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP - - - -Aboba, Thaler & Esibov Standards Track [Page 22] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - response may be able to reach the victim across the Internet. - - While LLMNR responders only respond to queries for which they are - authoritative and LLMNR does not provide wildcard query support, an - LLMNR response may be larger than the query, and an attacker can - generate multiple responses to a query for a name used by multiple - responders. A sender may protect itself against unsolicited - responses by silently discarding them as rapidly as possible. - -5.2. Spoofing - - 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. 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. To prevent successful setup of TCP - connections by an off-link sender, responders receiving a TCP SYN - reply with a TCP SYN-ACK with TTL set to one (1). - - While it is difficult for an off-link attacker to send an LLMNR query - to a responder, it is possible for an off-link 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. Since the - forged response will only be accepted if it contains a matching ID - field, choosing a pseudo-random ID field within queries provides some - protection against off-link responders. - - Since 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. As noted in "Threat Analysis of the Domain - Name System (DNS)" [RFC3833] these threats also exist with DNS, since - DNS response spoofing tools are available that can allow an attacker - to respond to a query more quickly than a distant DNS server. - However, while switched networks or link layer security may make it - difficult for an on-link attacker to snoop unicast DNS queries, - multicast LLMNR queries are propagated to all hosts on the link, - making it possible for an on-link attacker to spoof LLMNR responses - without having to guess the value of the ID field in the query. - - 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. - - - -Aboba, Thaler & Esibov Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - This vulnerability can be reduced by limiting use of LLMNR to - resolution of single-label names as described in Section 3, or by - implementation of authentication (see Section 5.3). - -5.3. 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. Where a pre-arranged security configuration is possible, - the following security mechanisms may be used: - -[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) - [RFC2931] 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, based on group keys. While group - keys can be used to demonstrate membership in a group, they do not - protect against forgery by an attacker that is a member of the - group. - -[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. As with TSIG, this does not - protect against forgery by an attacker with access to the group - pre-shared key. - -[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to - support DNSSEC, LLMNR implementations MAY be configured with trust - anchors, or they MAY make use of keys obtained from DNS queries. - Since LLMNR does not support "delegated trust" (CD or AD bits), - LLMNR implementations cannot make use of DNSSEC unless they are - DNSSEC-aware and support validation. Unlike approaches [a] or [b], - DNSSEC permits a responder to demonstrate ownership of a name, not - just membership within a trusted group. As a result, it enables - protection against forgery. - -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. - - - -Aboba, Thaler & Esibov Standards Track [Page 24] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - - If LLMNR is given higher priority than DNS among the enabled name - resolution mechanisms, 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 SHOULD NOT be used as a primary name resolution - mechanism. - -6. IANA Considerations - - LLMNR requires allocation of port 5355 for both TCP and UDP. - - LLMNR requires allocation of link-scope multicast IPv4 address - 224.0.0.252, as well as link-scope multicast IPv6 address - FF02:0:0:0:0:0:1:3. - - This specification creates two new name spaces: the LLMNR namespace - and the reserved bits in the LLMNR header. The reserved bits in the - LLMNR header are allocated by IETF Consensus, in accordance with BCP - 26 [RFC2434]. - - In order to to avoid creating any new administrative procedures, - administration of the LLMNR namespace will piggyback on the - administration of the DNS namespace. - - The rights to use a fully qualified domain name (FQDN) within LLMNR - are obtained coincident with acquiring the rights to use that name - within DNS. Those wishing to use a FQDN within LLMNR should first - acquire the rights to use the corresponding FQDN within DNS. Using a - FQDN within LLMNR without ownership of the corresponding name in DNS - creates the possibility of conflict and therefore is discouraged. - - LLMNR responders may self-allocate a name within the single-label - name space, first defined in [RFC1001]. Since single-label names are - not unique, no registration process is required. - -7. Constants - - The following timing constants are used in this protocol; they are - not intended to be user configurable. - - JITTER_INTERVAL 100 ms - LLMNR_TIMEOUT 1 second (if set statically on all interfaces) - 100 ms (IEEE 802 media, including IEEE 802.11) - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -8. References - -8.1. Normative References - -[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS - Service on a TCP/UDP Transport: Concepts and Methods", RFC - 1001, March 1987. - -[RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, November 1987. - -[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - -[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - -[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - -[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. - -[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - -[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - -[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s)", RFC 2931, September 2000. - -8.2. Informative References - -[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of - Caching", IEEE/ACM Transactions on Networking, Volume 10, - Number 5, pp. 589, October 2002. - -[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local - unicast addresses to communicate with recursive DNS servers", - Internet draft (work in progress), draft-ietf-ipv6-dns- - discovery-07.txt, October 2002. - - - - -Aboba, Thaler & Esibov Standards Track [Page 26] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -[IEEE-802.11i] - Institute of Electrical and Electronics Engineers, "Supplement - to Standard for Telecommunications and Information Exchange - Between Systems - LAN/MAN Specific Requirements - Part 11: - Wireless LAN Medium Access Control (MAC) and Physical Layer - (PHY) Specifications: Specification for Enhanced Security", - IEEE 802.11i, July 2004. - -[LLMNREnable] - Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work - in progress), draft-guttman-mdns-enable-02.txt, April 2002. - -[LLMNRSec] - Jeong, J., Park, J. and H. Kim, "DNS Name Service based on - Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT - 2004, Phoenix Park, Korea, February 9-11, 2004. - -[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- - Portable Operating System Interface (POSIX). Open Group - Technical Standard: Base Specifications, Issue 6, December - 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin - -[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested - Fixes", RFC 1536, October 1993. - -[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - -[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - -[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - -[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC - 2365, July 1998. - -[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic - Socket Interface Extensions for IPv6", RFC 2553, March 1999. - -[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC - 2937, September 2000. - -[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - -[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name - System (DNS)", RFC 3833, August 2004. - - - -Aboba, Thaler & Esibov Standards Track [Page 27] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of Link-Local IPv4 Addresses", RFC 3927, October 2004. - -[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "DNS Security Introduction and Requirement", RFC 4033, March - 2005. - -Acknowledgments - - This work builds upon original work done on multicast DNS by Bill - Manning and Bill Woodcock. Bill Manning's work was funded under - DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge - their contribution to the current specification. Constructive input - has also been received from Mark Andrews, Rob Austein, Randy Bush, - Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur - Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, - Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, - Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike - St. Johns, Sander Van-Valkenburg, and Brian Zill. - -Authors' Addresses - - Bernard Aboba - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 706 6605 - EMail: bernarda@microsoft.com - - Dave Thaler - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 703 8835 - EMail: dthaler@microsoft.com - - Levon Esibov - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - EMail: levone@microsoft.com - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 28] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 29] - - - - - -INTERNET-DRAFT LLMNR 16 April 2006 - - -Open Issues - - Open issues with this specification are tracked on the following web - site: - - http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 30] - - - diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt deleted file mode 100644 index e169da8681..0000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt +++ /dev/null @@ -1,464 +0,0 @@ - -INTERNET-DRAFT DSA Information in the DNS -OBSOLETES: RFC 2536 Donald E. Eastlake 3rd - Motorola Laboratories -Expires: September 2006 March 2006 - - - DSA Keying and Signature Information in the DNS - --- ------ --- --------- ----------- -- --- --- - - Donald E. Eastlake 3rd - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Distribution of this document is unlimited. Comments should be sent - to the DNS extensions working group mailing list - . - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - - -Abstract - - The standard method of encoding US Government Digital Signature - Algorithm keying and signature information for use in the Domain Name - System is specified. - - - - - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DSA Information in the DNS - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. DSA Keying Information..................................3 - 3. DSA Signature Information...............................4 - 4. Performance Considerations..............................4 - 5. Security Considerations.................................5 - 6. IANA Considerations.....................................5 - Copyright, Disclaimer, and Additional IPR Provisions.......5 - - Normative References.......................................7 - Informative References.....................................7 - - Author's Address...........................................8 - Expiration and File Name...................................8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT DSA Information in the DNS - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information [RFC 1034, 1035]. The DNS has been extended to - include digital signatures and cryptographic keys as described in - [RFC 4033, 4034, 4035] and additional work is underway which would - require the storage of keying and signature information in the DNS. - - This document describes how to encode US Government Digital Signature - Algorithm (DSA) keys and signatures in the DNS. Familiarity with the - US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier]. - - - -2. DSA Keying Information - - When DSA public keys are stored in the DNS, the structure of the - relevant part of the RDATA part of the RR being used is the fields - listed below in the order given. - - The period of key validity is not included in this data but is - indicated separately, for example by an RR such as RRSIG which signs - and authenticates the RR containing the keying information. - - Field Size - ----- ---- - T 1 octet - Q 20 octets - P 64 + T*8 octets - G 64 + T*8 octets - Y 64 + T*8 octets - - As described in [FIPS 186-2] and [Schneier], T is a key size - parameter chosen such that 0 <= T <= 8. (The meaning if the T octet - is greater than 8 is reserved and the remainder of the data may have - a different format in that case.) Q is a prime number selected at - key generation time such that 2**159 < Q < 2**160. Thus Q is always - 20 octets long and, as with all other fields, is stored in "big- - endian" network order. P, G, and Y are calculated as directed by the - [FIPS 186-2] key generation algorithm [Schneier]. P is in the range - 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G - and Y are quantities modulo P and so can be up to the same length as - P and are allocated fixed size fields with the same number of octets - as P. - - During the key generation process, a random number X must be - generated such that 1 <= X <= Q-1. X is the private key and is used - in the final step of public key generation where Y is computed as - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DSA Information in the DNS - - - Y = G**X mod P - - - -3. DSA Signature Information - - The portion of the RDATA area used for US Digital Signature Algorithm - signature information is shown below with fields in the order they - are listed and the contents of each multi-octet field in "big-endian" - network order. - - Field Size - ----- ---- - T 1 octet - R 20 octets - S 20 octets - - First, the data signed must be determined. Then the following steps - are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as - specified in the public key [Schneier]: - - hash = SHA-1 ( data ) - - Generate a random K such that 0 < K < Q. - - R = ( G**K mod P ) mod Q - - S = ( K**(-1) * (hash + X*R) ) mod Q - - For information on the SHA-1 hash function see [FIPS 180-2] and [RFC - 3174]. - - Since Q is 160 bits long, R and S can not be larger than 20 octets, - which is the space allocated. - - T is copied from the public key. It is not logically necessary in - the SIG but is present so that values of T > 8 can more conveniently - be used as an escape for extended versions of DSA or other algorithms - as later standardized. - - - -4. Performance Considerations - - General signature generation speeds are roughly the same for RSA [RFC - 3110] and DSA. With sufficient pre-computation, signature generation - with DSA is faster than RSA. Key generation is also faster for DSA. - However, signature verification is an order of magnitude slower than - RSA when the RSA public exponent is chosen to be small, as is - recommended for some applications. - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DSA Information in the DNS - - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including DNS overhead. Larger - transfers will perform correctly and extensions have been - standardized [RFC 2671] to make larger transfers more efficient, it - is still advisable at this time to make reasonable efforts to - minimize the size of RR sets containing keying and/or signature - inforamtion consistent with adequate security. - - - -5. Security Considerations - - Keys retrieved from the DNS should not be trusted unless (1) they - have been securely obtained from a secure resolver or independently - verified by the user and (2) this secure resolver and secure - obtainment or independent verification conform to security policies - acceptable to the user. As with all cryptographic algorithms, - evaluating the necessary strength of the key is essential and - dependent on local policy. - - The key size limitation of a maximum of 1024 bits ( T = 8 ) in the - current DSA standard may limit the security of DSA. For particular - applications, implementors are encouraged to consider the range of - available algorithms and key sizes. - - DSA assumes the ability to frequently generate high quality random - numbers. See [random] for guidance. DSA is designed so that if - biased rather than random numbers are used, high bandwidth covert - channels are possible. See [Schneier] and more recent research. The - leakage of an entire DSA private key in only two DSA signatures has - been demonstrated. DSA provides security only if trusted - implementations, including trusted random number generation, are - used. - - - -6. IANA Considerations - - Allocation of meaning to values of the T parameter that are not - defined herein (i.e., > 8 ) requires an IETF standards actions. It - is intended that values unallocated herein be used to cover future - extensions of the DSS standard. - - - -Copyright, Disclaimer, and Additional IPR Provisions - - Copyright (C) The Internet Society (2006). This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DSA Information in the DNS - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DSA Information in the DNS - - -Normative References - - [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital - Signature Standard, 27 January 2000. - - [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - - -Informative References - - [RFC 1034] - "Domain names - concepts and facilities", P. - Mockapetris, 11/01/1987. - - [RFC 1035] - "Domain names - implementation and specification", P. - Mockapetris, 11/01/1987. - - [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August - 1999. - - [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System - (DNS)", D. Eastlake 3rd. May 2001. - - [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P. - Jones, September 2001. - - [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC 4033, March - 2005. - - [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security Extensions", RFC - 4035, March 2005. - - [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. - - [Schneier] - "Applied Cryptography Second Edition: protocols, - algorithms, and source code in C" (second edition), Bruce Schneier, - 1996, John Wiley and Sons, ISBN 0-471-11709-9. - - - - - - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DSA Information in the DNS - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Labortories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554(w) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in September 2006. - - Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt deleted file mode 100644 index f6e8588e8c..0000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt +++ /dev/null @@ -1,580 +0,0 @@ - -INTERNET-DRAFT Diffie-Hellman Information in the DNS -OBSOLETES: RFC 2539 Donald E. Eastlake 3rd - Motorola Laboratories -Expires: September 2006 March 2006 - - - - - Storage of Diffie-Hellman Keying Information in the DNS - ------- -- -------------- ------ ----------- -- --- --- - - - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Distribution of this document is unlimited. Comments should be sent - to the DNS extensions working group mailing list - . - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Abstract - - The standard method for encoding Diffie-Hellman keys in the Domain - Name System is specified. - - - - - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Acknowledgements - - Part of the format for Diffie-Hellman keys and the description - thereof was taken from a work in progress by Ashar Aziz, Tom Markson, - and Hemma Prafullchandra. In addition, the following persons - provided useful comments that were incorporated into the predecessor - of this document: Ran Atkinson, Thomas Narten. - - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Acknowledgements...........................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 1.1 About This Document....................................3 - 1.2 About Diffie-Hellman...................................3 - 2. Encoding Diffie-Hellman Keying Information..............4 - 3. Performance Considerations..............................5 - 4. IANA Considerations.....................................5 - 5. Security Considerations.................................5 - Copyright, Disclaimer, and Additional IPR Provisions.......5 - - Normative References.......................................7 - Informative Refences.......................................7 - - Author's Address...........................................8 - Expiration and File Name...................................8 - - Appendix A: Well known prime/generator pairs...............9 - A.1. Well-Known Group 1: A 768 bit prime..................9 - A.2. Well-Known Group 2: A 1024 bit prime.................9 - A.3. Well-Known Group 3: A 1536 bit prime................10 - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - similar information [RFC 1034, 1035]. The DNS has been extended to - include digital signatures and cryptographic keys as described in - [RFC 4033, 4034, 4035] and additonal work is underway which would use - the storage of keying information in the DNS. - - - -1.1 About This Document - - This document describes how to store Diffie-Hellman keys in the DNS. - Familiarity with the Diffie-Hellman key exchange algorithm is assumed - [Schneier, RFC 2631]. - - 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 RFC 2119. - - - -1.2 About Diffie-Hellman - - Diffie-Hellman requires two parties to interact to derive keying - information which can then be used for authentication. Thus Diffie- - Hellman is inherently a key agreement algorithm. As a result, no - format is defined for Diffie-Hellman "signature information". For - example, assume that two parties have local secrets "i" and "j". - Assume they each respectively calculate X and Y as follows: - - X = g**i ( mod p ) - - Y = g**j ( mod p ) - - They exchange these quantities and then each calculates a Z as - follows: - - Zi = Y**i ( mod p ) - - Zj = X**j ( mod p ) - - Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared - secret between the two parties that an adversary who does not know i - or j will not be able to learn from the exchanged messages (unless - the adversary can derive i or j by performing a discrete logarithm - mod p which is hard for strong p and g). - - The private key for each party is their secret i (or j). The public - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - - key is the pair p and g, which is the same for both parties, and - their individual X (or Y). - - For further information about Diffie-Hellman and precautions to take - in deciding on a p and g, see [RFC 2631]. - - - -2. Encoding Diffie-Hellman Keying Information - - When Diffie-Hellman keys appear within the RDATA portion of a RR, - they are encoded as shown below. - - The period of key validity is not included in this data but is - indicated separately, for example by an RR such as RRSIG which signs - and authenticates the RR containing the keying information. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | KEY flags | protocol | algorithm=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | prime length (or flag) | prime (p) (or special) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / prime (p) (variable length) | generator length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | generator (g) (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | public value length | public value (variable length)/ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / public value (g^i mod p) (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Prime length is the length of the Diffie-Hellman prime (p) in bytes - if it is 16 or greater. Prime contains the binary representation of - the Diffie-Hellman prime with most significant byte first (i.e., in - network order). If "prime length" field is 1 or 2, then the "prime" - field is actually an unsigned index into a table of 65,536 - prime/generator pairs and the generator length SHOULD be zero. See - Appedix A for defined table entries and Section 4 for information on - allocating additional table entries. The meaning of a zero or 3 - through 15 value for "prime length" is reserved. - - Generator length is the length of the generator (g) in bytes. - Generator is the binary representation of generator with most - significant byte first. PublicValueLen is the Length of the Public - Value (g**i (mod p)) in bytes. PublicValue is the binary - representation of the DH public value with most significant byte - first. - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -3. Performance Considerations - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including DNS overhead. Larger - transfers will perform correctly and extensions have been - standardized [RFC 2671] to make larger transfers more efficient. But - it is still advisable at this time to make reasonable efforts to - minimize the size of RR sets containing keying information consistent - with adequate security. - - - -4. IANA Considerations - - Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires - an IETF consensus as defined in [RFC 2434]. - - Well known prime/generator pairs number 0x0000 through 0x07FF can - only be assigned by an IETF standards action. [RFC 2539], the - Proposed Standard predecessor of this document, assigned 0x0001 - through 0x0002. This document additionally assigns 0x0003. Pairs - number 0s0800 through 0xBFFF can be assigned based on RFC - documentation. Pairs number 0xC000 through 0xFFFF are available for - private use and are not centrally coordinated. Use of such private - pairs outside of a closed environment may result in conflicts and/or - security failures. - - - -5. Security Considerations - - Keying information retrieved from the DNS should not be trusted - unless (1) it has been securely obtained from a secure resolver or - independently verified by the user and (2) this secure resolver and - secure obtainment or independent verification conform to security - policies acceptable to the user. As with all cryptographic - algorithms, evaluating the necessary strength of the key is important - and dependent on security policy. - - In addition, the usual Diffie-Hellman key strength considerations - apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p - SHOULD be "large", etc. See [RFC 2631, Schneier]. - - - -Copyright, Disclaimer, and Additional IPR Provisions - - Copyright (C) The Internet Society (2006). This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Normative References - - [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2434] - "Guidelines for Writing an IANA Considerations Section - in RFCs", T. Narten, H. Alvestrand, October 1998. - - [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June - 1999. - - [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - - -Informative Refences - - [RFC 1034] - "Domain names - concepts and facilities", P. - Mockapetris, November 1987. - - [RFC 1035] - "Domain names - implementation and specification", P. - Mockapetris, November 1987. - - [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name - System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC. - - [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August - 1999. - - [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC 4033, March - 2005. - - [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security Extensions", RFC - 4035, March 2005. - - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley - and Sons. - - - - - - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in September 2006. - - Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Appendix A: Well known prime/generator pairs - - These numbers are copied from the IPSEC effort where the derivation - of these values is more fully explained and additional information is - available. Richard Schroeppel performed all the mathematical and - computational work for this appendix. - - - -A.1. Well-Known Group 1: A 768 bit prime - - The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its - decimal value is - 155251809230070893513091813125848175563133404943451431320235 - 119490296623994910210725866945387659164244291000768028886422 - 915080371891804634263272761303128298374438082089019628850917 - 0691316593175367469551763119843371637221007210577919 - - Prime modulus: Length (32 bit words): 24, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - -A.2. Well-Known Group 2: A 1024 bit prime - - The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. - Its decimal value is - 179769313486231590770839156793787453197860296048756011706444 - 423684197180216158519368947833795864925541502180565485980503 - 646440548199239100050792877003355816639229553136239076508735 - 759914822574862575007425302077447712589550957937778424442426 - 617334727629299387668709205606050270810842907692932019128194 - 467627007 - - Prime modulus: Length (32 bit words): 32, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 - FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -A.3. Well-Known Group 3: A 1536 bit prime - - The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. - Its decimal value is - 241031242692103258855207602219756607485695054850245994265411 - 694195810883168261222889009385826134161467322714147790401219 - 650364895705058263194273070680500922306273474534107340669624 - 601458936165977404102716924945320037872943417032584377865919 - 814376319377685986952408894019557734611984354530154704374720 - 774996976375008430892633929555996888245787241299381012913029 - 459299994792636526405928464720973038494721168143446471443848 - 8520940127459844288859336526896320919633919 - - Prime modulus Length (32 bit words): 48, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 10] - diff --git a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt deleted file mode 100644 index 0af13c616f..0000000000 --- a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt +++ /dev/null @@ -1,755 +0,0 @@ - - -Network Working Group B. Laurie -Internet-Draft Nominet -Expires: March 2, 2005 R. Loomis - SAIC - September 2004 - - - - Requirements related to DNSSEC Signed Proof of Non-Existence - draft-ietf-dnsext-signed-nonexistence-requirements-01 - - -Status of this Memo - - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - This Internet-Draft will expire on March 2, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). - - -Abstract - - - DNSSEC-bis uses the NSEC record to provide authenticated denial of - existence of RRsets. NSEC also has the side-effect of permitting - zone enumeration, even if zone transfers have been forbidden. - Because some see this as a problem, this document has been assembled - to detail the possible requirements for denial of existence A/K/A - signed proof of non-existence. - - - - -Laurie & Loomis Expires March 2, 2005 [Page 1] -Internet-Draft signed-nonexistence-requirements September 2004 - - - -Table of Contents - - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3 - 4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4 - 5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4 - 6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4 - 7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5 - 9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5 - 10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6 - 11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6 - 12. Non-overlap of denial records with possible zone records . . 7 - 13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7 - 14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8 - 15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8 - 16. Minimisation of Client Complexity . . . . . . . . . . . . . 8 - 17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8 - 18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8 - 19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8 - 20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8 - 21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9 - 22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9 - 23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9 - 24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9 - 25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9 - 26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - 28. Requirements notation . . . . . . . . . . . . . . . . . . . 9 - 29. Security Considerations . . . . . . . . . . . . . . . . . . 10 - 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 30.1 Normative References . . . . . . . . . . . . . . . . . . . 10 - 30.2 Informative References . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 - Intellectual Property and Copyright Statements . . . . . . . 11 - - - - - - - - - - - - - - - - -Laurie & Loomis Expires March 2, 2005 [Page 2] -Internet-Draft signed-nonexistence-requirements September 2004 - - - -1. Introduction - - - NSEC records allow trivial enumeration of zones - a situation that - has existed for several years but which has recently been raised as a - significant concern for DNSSECbis deployment in several zones. - Alternate proposals have been made that make zone enumeration more - difficult, and some previous proposals to modify DNSSEC had related - requirements/desirements that are relevant to the discussion. In - addition the original designs for NSEC/NXT records were based on - working group discussions and the choices made were not always - documented with context and requirements-- so some of those choices - may need to be restated as requirements. Overall, the working group - needs to better understand the requirements for denial of existence - (and certain other requirements related to DNSSECbis deployment) in - order to evaluate the proposals that may replace NSEC. - - - In the remainder of this document, "NSEC++" is used as shorthand for - "a denial of existence proof that will replace NSEC". "NSECbis" has - also been used as shorthand for this, but we avoid that usage since - NSECbis will not be part of DNSSECbis and therefore there might be - some confusion. - - -2. Non-purposes - - - This document does not currently document the reasons why zone - enumeration might be "bad" from a privacy, security, business, or - other perspective--except insofar as those reasons result in - requirements. Once the list of requirements is complete and vaguely - coherent, the trade-offs (reducing zone enumeration will have X cost, - while providing Y benefit) may be revisited. The editors of this - compendium received inputs on the potential reasons why zone - enumeration is bad (and there was significant discussion on the - DNSEXT WG mailing list) but that information fell outside the scope - of this document. - - - Note also that this document does not assume that NSEC *must* be - replaced with NSEC++, if the requirements can be met through other - methods (e.g., "white lies" with the current NSEC). As is stated - above, this document is focused on requirements collection and - (ideally) prioritization rather than on the actual implementation. - - -3. Zone Enumeration - - - Authenticated denial should not permit trivial zone enumeration. - - - Additional discussion: NSEC (and NXT before it) provide a linked - list that could be "walked" to trivially enumerate all the signed - records in a zone. This requirement is primarily (though not - - - - -Laurie & Loomis Expires March 2, 2005 [Page 3] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - exclusively) important for zones that either are delegation-only/ - -mostly or do not have reverse lookup (PTR) records configured, since - enterprises that have PTR records for all A records have already - provided a similar capability to enumerate the contents of DNS zones. - - - Contributor: various - - -4. Zone Enumeration II - - - Zone enumeration should be at least as difficult as it would be to - effect a dictionary attack using simple DNS queries to do the same in - an unsecured zone. - - - (Editor comment: it is not clear how to measure difficulty in this - case. Some examples could be monetary cost, bandwidth, processing - power or some combination of these. It has also been suggested that - the requirement is that the graph of difficulty of enumeration vs. - the fraction of the zone enumerated should be approximately the same - shape in the two cases) - - - Contributor: Nominet - - -5. Zone Enumeration III - - - Enumeration of a zone with random contents should computationally - infeasible. - - - Editor comment: this is proposed as a way of evaluating the - effectiveness of a proposal rather than as a requirement anyone would - actually have in practice. - - - Contributor: Alex Bligh - - -6. Exposure of Contents - - - NSEC++ should not expose any of the contents of the zone (apart from - the NSEC++ records themselves, of course). - - - Editor comment: this is a weaker requirement than prevention of - enumeration, but certainly any zone that satisfied this requirement - would also satisfy the trivial prevention of enumeration requirement. - - - Contributor: Ed Lewis - - -7. Zone Size - - - Requirement: NSEC++ should make it possible to take precautions - against trivial zone size estimates. Since not all zone owners care - - - - -Laurie & Loomis Expires March 2, 2005 [Page 4] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - about others estimation of the size of a zone, it is not always - necessary to prohibit trivial estimation of the size of the zone but - NSEC++ should allow such measures. - - - Additional Discussion: Even with proposals based on obfuscating names - with hashes it is trivial to give very good estimates of the number - of domains in a certain zone. Just send 10 random queries and look - at the range between the two hash values returned in each NSEC++. As - hash output can be assumed to follow a rectangular random - distribution, using the mean difference between the two values, you - can estimate the total number of records. It is probably sufficient - to look at even one NSEC++, since the two hash values should follow a - (I believe) Poisson distribution. - - - The concern is motivated by some wording remembered from NSEC, which - stated that NSEC MUST only be present for existing owner names in the - zone, and MUST NOT be present for non-existing owner names. If - similar wording were carried over to NSEC++, introducing bogus owner - names in the hash chain (an otherwise simple solution to guard - against trivial estimates of zone size) wouldn't be allowed. - - - One simple attempt at solving this is to describe in the - specifications how zone signer tools can add a number of random - "junk" records. - - - Editor's comment: it is interesting that obfuscating names might - actually make it easier to estimate zone size. - - - Contributor: Simon Josefsson. - - -8. Single Method - - - Requirement: A single NSEC++ method must be able to carry both - old-style denial (i.e. plain labels) and whatever the new style - looks like. Having two separate denial methods could result in - cornercases where one method can deny the other and vice versa. - - - Additional discussion: This requirement can help -bis folks to a - smooth upgrade to -ter. First they'd change the method while the - content is the same, then they can change content of the method. - - - Contributor: Roy Arends. - - -9. Empty Non-terminals - - - Requirement: Empty-non-terminals (ENT) should remain empty. In - other words, adding NSEC++ records to an existing DNS structure - should not cause the creation of NSEC++ records (or related records) - - - - -Laurie & Loomis Expires March 2, 2005 [Page 5] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - at points that are otherwise ENT. - - - Additional discussion: Currently NSEC complies with ENT requirement: - b.example.com NSEC a.c.example.com implies the existence of an ENT - with ownername c.example.com. NSEC2 breaks that requirement, since - the ownername is entirely hashed causing the structure to disappear. - This is why EXIST was introduced. But EXIST causes ENT to be - non-empty-terminals. Next to the dissappearance of ENT, it causes - (some) overhead since an EXIST record needs a SIG, NSEC2 and - SIG(NSEC2). DNSNR honours this requirement by hashing individual - labels instead of ownernames. However this causes very long labels. - Truncation is a measure against very long ownernames, but that is - controversial. There is a fair discussion of the validity of - truncation in the DNSNR draft, but that hasn't got proper review yet. - - - Contributor: Roy Arends. - - - (Editor comment: it is not clear to us that an EXIST record needs an - NSEC2 record, since it is a special purpose record only used for - denial of existence) - - -10. Prevention of Precomputed Dictionary Attacks - - - Requirement: NSEC++ needs to provide a method to reduce the - effectiveness of precomputed dictionary attacks. - - - Additional Discussion: Salt is a measure against dictionary attacks. - There are other possible measures (such as iterating hashes in - NSEC2). The salt needs to be communicated in every response, since - it is needed in every verification. Some have suggested to move the - salt to a special record instead of the denial record. I think this - is not wise. Response size has more priority over zone size. An - extra record causes a larger response than a larger existing record. - - - Contributor: Roy Arends. - - - (Editor comment: the current version of NSEC2 also has the salt in - every NSEC2 record) - - -11. DNSSEC-Adoption and Zone-Growth Relationship - - - Background: Currently with NSEC, when a delegation centric zone - deploys DNSSEC, the zone-size multiplies by a non-trivial factor even - when the DNSSEC-adoption rate of the subzones remains low--because - each delegation point creates at least one NSEC record and - corresponding signature in the parent even if the child is not - signed. - - - - - -Laurie & Loomis Expires March 2, 2005 [Page 6] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - Requirements: A delegation-only (or delegation-mostly) zone that is - signed but which has no signed child zones should initially need only - to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some - minimal set of NSEC++ records to cover zone contents. Further, - during the transition of a delegation-only zone from 0% signed - children to 100% signed children, the growth in the delegation-only - zone should be roughly proportional to the percentage of signed child - zones. - - - Additional Discussion: This is why DNSNR has the Authoritative Only - bit. This is similar to opt-in for delegations only. This (bit) is - currently the only method to help delegation-centric zone cope with - zone-growth due to DNSSEC adoption. As an example, A delegation only - zone which deploys DNSSEC with the help of this bit, needs to add - SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No - more than that. - - - Contributor: Roy Arends. - - -12. Non-overlap of denial records with possible zone records - - - Requirement: NSEC++ records should in some way be differentiated - from regular zone records, so that there is no possibility that a - record in the zone could be duplicated by a non-existence proof - (NSEC++) record. - - - Additional discussion: This requirement is derived from a discussion - on the DNSEXT mailing list related to copyrights and domain names. - As was outlined there, one solution is to put NSEC++ records in a - separate namespace, e.g.: $ORIGIN co.uk. - 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your - delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345... - ; for amazon.co.uk. - - - Contributor: various - - - (Editor comment: One of us still does not see why a conflict - matters. Even if there is an apparent conflict or overlap, the - "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the - other name _never_ appears in NSEC2 records.) - - -13. Exposure of Private Keys - - - Private keys associated with the public keys in the DNS should be - exposed as little as possible. It is highly undesirable for private - keys to be distributed to nameservers, or to otherwise be available - in the run-time environment of nameservers. - - - - - -Laurie & Loomis Expires March 2, 2005 [Page 7] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - Contributors: Nominet, Olaf Kolkman, Ed Lewis - - -14. Minimisation of Zone Signing Cost - - - The additional cost of creating an NSEC++ signed zone should not - significantly exceed the cost of creating an ordinary signed zone. - - - Contributor: Nominet - - -15. Minimisation of Asymmetry - - - Nameservers should have to do as little additional work as necessary. - More precisely, it is desirable for any increase in cost incurred by - the nameservers to be offset by a proportionate increase in cost to - DNS `clients', e.g. stub and/or `full-service' resolvers. - - - Contributor: Nominet - - -16. Minimisation of Client Complexity - - - Caching, wildcards, CNAMEs, DNAMEs should continue to work without - adding too much complexity at the client side. - - - Contributor: Olaf Kolkman - - -17. Completeness - - - A proof of nonexistence should be possible for all nonexistent data - in the zone. - - - Contributor: Olaf Kolkman - - -18. Purity of Namespace - - - The name space should not be muddied with fake names or data sets. - - - Contributor: Ed Lewis - - -19. Replay Attacks - - - NSEC++ should not allow a replay to be used to deny existence of an - RR that actually exists. - - - Contributor: Ed Lewis - - -20. Compatibility with NSEC - - - NSEC++ should not introduce changes incompatible with NSEC. - - - - -Laurie & Loomis Expires March 2, 2005 [Page 8] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - Contributor: Ed Lewis - - -21. Compatibility with NSEC II - - - NSEC++ should differ from NSEC in a way that is transparent to the - resolver or validator. - - - Contributor: Ed Lewis - - -22. Compatibility with NSEC III - - - NSEC++ should differ from NSEC as little as possible whilst achieving - other requirements. - - - Contributor: Alex Bligh - - -23. Coexistence with NSEC - - - NSEC++ should be optional, allowing NSEC to be used instead. - - - Contributor: Ed Lewis, Alex Bligh - - -24. Coexistence with NSEC II - - - NSEC++ should not impose extra work on those content with NSEC. - - - Contributor: Ed Lewis - - -25. Protocol Design - - - A good security protocol would allow signing the nonexistence of some - selected names without revealing anything about other names. - - - Contributor: Dan Bernstein - - -26. Process - - - Clearly not all of these requirements can be met. Therefore the next - phase of this document will be to either prioritise them or narrow - them down to a non-contradictory set, which should then allow us to - judge proposals on the basis of their fit. - - -27. Acknowledgements - - -28. Requirements notation - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - - - - -Laurie & Loomis Expires March 2, 2005 [Page 9] -Internet-Draft signed-nonexistence-requirements September 2004 - - - - document are to be interpreted as described in [RFC2119]. - - -29. Security Considerations - - - There are currently no security considerations called out in this - draft. There will be security considerations in the choice of which - requirements will be implemented, but there are no specific security - requirements during the requirements collection process. - - -30. References - - -30.1 Normative References - - - [dnssecbis-protocol] - "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some - Month 2004. - - -30.2 Informative References - - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - [RFC2418] Bradner, S., "IETF Working Group Guidelines and - Procedures", BCP 25, RFC 2418, September 1998. - - - -Authors' Addresses - - - Ben Laurie - Nominet - 17 Perryn Road - London W3 7LR - England - - - Phone: +44 (20) 8735 0686 - EMail: ben@algroup.co.uk - - - - Rip Loomis - Science Applications International Corporation - 7125 Columbia Gateway Drive, Suite 300 - Columbia, MD 21046 - US - - - EMail: gilbert.r.loomis@saic.com - - - - -Laurie & Loomis Expires March 2, 2005 [Page 10] -Internet-Draft signed-nonexistence-requirements September 2004 - - - -Intellectual Property Statement - - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - -Disclaimer of Validity - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Copyright Statement - - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - -Acknowledgment - - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - -Laurie & Loomis Expires March 2, 2005 [Page 11] \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt deleted file mode 100644 index 9c73c68bef..0000000000 --- a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt +++ /dev/null @@ -1,1292 +0,0 @@ - - - - - -DNS Extensions Yuji Kamite -Internet-Draft NTT Communications -Expires: April 15, 2005 Masaya Nakayama - The University of Tokyo - October 14, 2004 - - - - TKEY Secret Key Renewal Mode - draft-ietf-dnsext-tkey-renewal-mode-05 - - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 15, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - This document defines a new mode in TKEY and proposes an atomic - method for changing secret keys used for TSIG periodically. - Originally, TKEY provides methods of setting up shared secrets other - - - -Kamite, et. al. Expires April 15, 2005 [Page 1] - -INTERNET-DRAFT October 2004 - - - than manual exchange, but it cannot control timing of key renewal - very well though it can add or delete shared keys separately. This - proposal is a systematical key renewal procedure intended for - preventing signing DNS messages with old and non-safe keys - permanently. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4 - 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4 - 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5 - 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5 - 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6 - 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7 - 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7 - 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7 - 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8 - 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8 - 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10 - 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10 - 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10 - 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11 - 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11 - 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12 - 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13 - 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14 - 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15 - 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15 - 4.2 Authentication Methods Considerations . . . . . . . . . . 15 - 5. Special Considerations for Two Servers' Case . . . . . . . . 16 - 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16 - 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17 - 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 - 11.2 Informative References . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 - Intellectual Property and Copyright Statements . . . . . . . . 23 - - - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 2] - -INTERNET-DRAFT October 2004 - - -1. Introduction - - TSIG [RFC2845] provides DNS message integrity and the - request/transaction authentication by means of message authentication - codes (MAC). TSIG is a practical solution in view of calculation - speed and availability. However, TSIG does not have exchanging - mechanism of shared secret keys between server and resolver, and - administrators might have to exchange secret keys manually. TKEY - [RFC2930] is introduced to solve such problem and it can exchange - secrets for TSIG via networks. - - In various modes of TKEY, a server and a resolver can add or delete a - secret key be means of TKEY message exchange. However, the existing - TKEY does not care fully about the management of keys which became - too old, or dangerous after long time usage. - - It is ideal that the number of secret which a pair of hosts share - should be limited only one, because having too many keys for the same - purpose might not only be a burden to resolvers for managing and - distinguishing according to servers to query, but also does not seem - to be safe in terms of storage and protection against attackers. - Moreover, perhaps holding old keys long time might give attackers - chances to compromise by scrupulous calculation. - - Therefore, when a new shared secret is established by TKEY, the - previous old secret should be revoked immediately. To accomplish - this, DNS servers must support a protocol for key renewal. This - document specifies procedure to refresh secret keys between two hosts - which is defined within the framework of TKEY, and it is called "TKEY - Secret Key Renewal Mode". - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and - "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - - -1.1. Defined Words - - * Inception Time: Beginning of the shared secret key lifetime. This - value is determined when the key is generated. - - * Expiry Limit: Time limit of the key's validity. This value is - determined when a new key is generated. After Expiry Limit, server - and client (resolver) must not authenticate TSIG signed with the key. - Therefore, Renewal to the next key should be carried out before - Expiry Limit. - - * Partial Revocation Time: Time when server judges the key is too old - - - -Kamite, et. al. Expires April 15, 2005 [Page 3] - -INTERNET-DRAFT October 2004 - - - and must be updated. It must be between Inception Time and Expiry - Limit. This value is determined by server freely following its - security policy. e.g., If the time from Inception to Partial - Revocation is short, renewal will be carried out more often, which - might be safer. - - * Revocation Time: Time when the key becomes invalid and can be - removed. This value is not determined in advance because it is the - actual time when revocation is completed. - - * Adoption Time: Time when the new key is adopted as the next key - formally. After Adoption, the key is valid and server and client can - generate or verify TSIG making use of it. Adoption Time also means - the time when it becomes possible to remove the previous key, so - Revocation and Adoption are usually done at the same time. - - - Partial - Inception Revocation Revocation Expiry Limit - | | | | - |----------------|- - - - - - >>|- (revoked) -| - | | | | - previous key | | | - |- - - -|-------------------->> time - | | new key - Inception Adoption - - -1.2. New Format and Assigned Numbers - - TSIG - ERROR = (PartialRevoke), TBD - - TKEY - Mode = (server assignment for key renewal), TBD - Mode = (Diffie-Hellman exchange for key renewal), TBD - Mode = (resolver assignment for key renewal), TBD - Mode = (key adoption), TBD - - -1.3. Overview of Secret Key Renewal Mode - - When a server receives a query from a client signed with a TSIG key, - It always checks if the present time is within the range of usage - duration it considers safe. If it is judged that the key is too old, - i.e., after Partial Revocation Time, the server comes to be in - Partial Revocation state about the key, and this key is called - partially revoked. - - - -Kamite, et. al. Expires April 15, 2005 [Page 4] - -INTERNET-DRAFT October 2004 - - - In this state, if a client sends a normal query (e.g., question about - A RR) other than TKEY Renewal request with TSIG signed with the old - key, the server returns an error message to notify that the time to - renew has come. This is called "PartialRevoke" error message. It is - server's choice whether it returns PartialRevoke or not. If and only - if the server is ready for changing its own key, it decides to return - PartialRevoke. - - The client which got this error is able to notice that it is - necessary to refresh the secret. To make a new shared secret, it - sends a TKEY Renewal request, in which several keying methods are - available. It can make use of TSIG authentication signed with the - partially revoked key mentioned above. - - After new secret establishment, the client sends a TKEY Adoption - request for renewal confirmation. This can also be authenticated with - the partially revoked key. If this is admitted by the server, the new - key is formally adopted, and at the same time the corresponding old - secret is invalidated. Then the client can send the first query again - signed with the new key. - - Key renewal procedure is executed based on two-phase commit - mechanism. The first phase is the TKEY Renewal request and its - response, which means preparatory confirmation for key update. The - second phase is Adoption request and its response. If the server gets - request and client receives the response successfully, they can - finish renewal process. If any error happens and renewal process - fails during these phases, client should roll back to the beginning - of the first phase, and send TKEY Renewal request again. This - rollback can be done until the Expiry Limit of the key. - - -2. Shared Secret Key Renewal - - Suppose a server and a client agree to change their TSIG keys - periodically. Key renewal procedure is defined between two hosts. - -2.1. Key Usage Time Check - - Whenever a server receives a query with TSIG and can find a key that - is used for signing it, the server checks its Inception Time, Partial - Revocation Time and Expiry Limit (this information is usually - memorized by the server). - - When the present time is before Inception Time, the server MUST NOT - verify TSIG with the key, and server acts the same way as when the - key used by the client is not recognized. It follows [RFC2845] 4.5.1. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 5] - -INTERNET-DRAFT October 2004 - - - When the present time is equal to Inception Time, or between - Inception Time and Partial Revocation Time, the behavior of the - server is the same as when a valid key is found. It follows [RFC2845] - 4.5.2 and 4.5.3. - - When the present time is the same as the Partial Revocation Time, or - between the Partial Revocation Time and Expiry Limit, the server - comes to be in Partial Revocation state about the TSIG key and - behaves according to the next section. - - When the present time is the same as the Expiry Time or after it, the - server MUST NOT verify TSIG with the key, and returns error messages - in the same way as when the key used by the client is not recognized. - It follows [RFC2845] 4.5.1. - - -2.2. Partial Revocation - - In Partial Revocation state, we say the server has partially revoked - the key and the key has become a "partially revoked key". - - If server has received a query signed with the partially revoked key - for TKEY Renewal request (See section 2.3.) or Key Adoption request - (See section 2.4.), then server does proper process following each - specification. If it is for TKEY key deletion request ([RFC2930] - 4.2), server MAY process usual deletion operation defined therein. - - If server receives other types of query signed with the partially - revoked key, and both the corresponding MAC and signed TIME are - verified, then server begins returning answer whose TSIG error code - is "PartialRevoke" (See section 9.). Server MUST randomly but with - increasing frequency return PartialRevoke when in the Partial - Revocation state. - - Server can decide when it actually sends PartialRevoke, checking if - it is appropriate time for renewal. Server MUST NOT return - PartialRevoke if this is apart long lived TSIG transaction (such as - AXFR) that started before the Partial Revocation Time. - - If the client receives PartialRevoke and understands it, then it MUST - retry the query with the old key unless a new key has been adopted. - Client SHOULD start the process to renew the TSIG key. For key - renewal procedure, see details in Section 2.3 and 2.4. - - PartialRevoke period (i.e., time while server returns PartialRevoke - randomely) SHOULD be small, say 2-5% of key lifetime. This is - server's choice. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 6] - -INTERNET-DRAFT October 2004 - - - Server MUST keep track of clients ignoring PartialRevoke, thus - indicating ignorance of this TKEY mode. - - PartialRevoke error messages have the role to inform clients of the - keys' partial revocation and urge them to send TKEY Renewal requests. - These error responses MUST be signed with those partial revoked keys - if the queries are signed with them. They are sent only when the - signing keys are found to be partially revoked. If the MAC of TSIG - cannot be verified with the partially revoked keys, servers MUST NOT - return PartialRevoke error with MAC, but MUST return another error - such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other - words, a server informs its key's partial revocation only when the - MAC in the received query is valid. - - -2.3. Key Renewal Message Exchange - -2.3.1. Query for Key Renewal - - If a client has received a PartialRevoke error and authenticated the - response based on TSIG MAC, it sends a TKEY query for Key Renewal (in - this document, we call it Renewal request, too.) to the server. The - request MUST be signed with TSIG or SIG(0) [RFC2931] for - authentication. If TSIG is selected, the client can sign it with the - partial revoked key. - - Key Renewal can use one of several keying methods which is indicated - in "Mode" field of TKEY RR, and its message structure is dependent on - that method. - - -2.3.2. Response for Key Renewal - - The server which has received Key Renewal request first tries to - verify TSIG or SIG(0) accompanying it. If the TSIG is signed and - verified with the partially revoked key, the request MUST be - authenticated. - - After authentication, server must check existing old key's validity. - If the partially revoked key indicated in the request TKEY's OldName - and OldAlgorithm field (See section 2.3.4.) does not exist at the - server, "BADKEY" [RFC2845] is given in Error field for response. If - any other error happens, server returns appropriate error messages - following the specification described in section 2.5. If there are no - errors, server returns a Key Renewal answer. This answer MUST be - signed with TSIG or SIG(0) for authentication. - - When this answer is successfully returned and no error is detected by - - - -Kamite, et. al. Expires April 15, 2005 [Page 7] - -INTERNET-DRAFT October 2004 - - - client, a new shared secret can be established. The details of - concrete keying procedure are given in the section 2.5. - - Note: - Sometimes Adoption message and new Renewal request will cross on - the wire. In this case the newly generated key Adoption message is - resent. - - -2.3.3. Attributes of Generated Key - - As a result of this message exchange, client comes to know the newly - generated key's attributes such as key's name, Inception Time and - Expiry Limit. They are decided by the server and told to the client; - in particular, however, once the server has decided Expiry Limit and - returned a response, it should obey the decision as far as it can. In - other words, they SHOULD NOT change time values for checking Expiry - Limit in the future without any special reason, such as security - issue like "Emergency Compulsory Revocation" described in section 8. - - On the other hand, Partial Revocation Time of this generated key is - not decided based on the request, and not informed to the client. The - server can determine any value as long as it is between Inception - Time and Expiry Limit. However, the period from Inception to Partial - Revocation SHOULD be fixed as the server side's configuration or be - set the same as the corresponding old key's one. - - Note: - Even if client sends Key Renewal request though the key described - in OldName has not been partially revoked yet, server does renewal - processes. At the moment when the server accepts such requests - with valid authentication, it MUST forcibly consider the key is - already partially revoked, that is, the key's Partial Revocation - Time must be changed into the present time (i.e., the time when - the server receives the request). - - -2.3.4. TKEY RR structure - - TKEY RR for Key Renewal message has the structure given below. In - principle, format and definition for each field follows [RFC2930]. - Note that each keying scheme sometimes needs different interpretation - of RDATA field; for detail, see section 2.5. - - Field Type Comment - ------- ------ ------- - NAME domain used for a new key, see below - TYPE u_int16_t (defined in [RFC2930]) - - - -Kamite, et. al. Expires April 15, 2005 [Page 8] - -INTERNET-DRAFT October 2004 - - - CLASS u_int16_t (defined in [RFC2930]) - TTL u_int32_t (defined in [RFC2930]) - RDLEN u_int16_t (defined in [RFC2930]) - RDATA: - Algorithm: domain algorithm for a new key - Inception: u_int32_t about the keying material - Expiration: u_int32_t about the keying material - Mode: u_int16_t scheme for key agreement - see section 9. - Error: u_int16_t see description below - Key Size: u_int16_t see description below - Key Data: octet-stream - Other Size: u_int16_t (defined in [RFC2930]) - size of other data - Other Data: newly defined: see description below - - - For "NAME" field, both non-root and root name are allowed. It may - be used for a new key's name in the same manner as [RFC2930] 2.1. - - "Algorithm" specifies which algorithm is used for agreed keying - material, which is used for identification of the next key. - - "Inception" and "Expiration" are used for the valid period of - keying material. The meanings differ somewhat according to whether - the message is request or answer, and its keying scheme. - - "Key Data" has different meanings according to keying schemes. - - "Mode" field stores the value in accordance with the keying method, - and see section 2.5. Servers and clients supporting TKEY Renewal - method MUST implement "Diffie-Hellman exchange for key renewal" - scheme. All other modes are OPTIONAL. - - "Error" is an extended RCODE which includes "PartialRevoke" value - too. See section 9. - - "Other Data" field has the structure given below. They describe - attributes of the key to be renewed. - - in Other Data filed: - - Field Type Comment - ------- ------ ------- - OldNAME domain name of the old key - OldAlgorithm domain algorithm of the old key - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 9] - -INTERNET-DRAFT October 2004 - - - "OldName" indicates the name of the previous key (usually, - this is partially revoked key's name that client noticed by - PartialRevoke answer from server), and "OldAlogirthm" - indicates its algorithm. - - -2.4. Key Adoption - -2.4.1. Query for Key Adoption - - After receiving a TKEY Renewal answer, the client gets the same - secret as the server. Then, it sends a TKEY Adoption request. The - request's question section's QNAME field is the same as the NAME - filed of TKEY written below. In additional section, there is one TKEY - RR that has the structure and values described below. - - "NAME" field is the new key's name to be adopted which was already - generated by Renewal message exchange. "Algorithm" is its - algorithm. "Inception" means the key's Inception Time, and - "Expiration" means Expiry Limit. - - "Mode" field is the value of "key adoption". See section 9. - - "Other Data" field in Adoption has the same structure as that of - Renewal request message. "OldName" means the previous old key, and - "OldAlogirthm" means its algorithm. - - Key Adoption request MUST be signed with TSIG or SIG(0) for - authentication. The client can sign TSIG with the previous key. Note - that until Adoption is finished, the new key is treated as invalid, - thus it cannot be used for authentication immediately. - - -2.4.2. Response for Key Adoption - - The server which has received Adoption request, it verifies TSIG or - SIG(0) accompanying it. If the TSIG is signed with the partially - revoked key and can be verified, the message MUST be authenticated. - - If the next new key indicated by the request TKEY's "NAME" is not - present at the server, BADNAME [RFC2845] is given in Error field and - the error message is returned. - - If the next key exists but it has not been adopted formally yet, the - server confirms the previous key's existence indicated by the - "OldName" and "OldAlgorithm" field. If it succeeds, the server - executes Adoption of the next key and Revocation of the previous key. - Response message duplicates the request's TKEY RR with NOERROR, - - - -Kamite, et. al. Expires April 15, 2005 [Page 10] - -INTERNET-DRAFT October 2004 - - - including "OldName" and "OldAlgorithm" that indicate the revoked key. - - If the next key exists but it is already adopted, the server returns - a response message regardless of the substance of the request TKEY's - "OldName". In this response, Response TKEY RR has the same data as - the request's one except as to its "Other Data" that is changed into - null (i.e., "Other Size" is zero), which is intended for telling the - client that the previous key name was ignored, and the new key is - already available. - - Client sometimes has to retry Adoption request. Suppose the client - sent request signed with the partially revoked key, but its response - did not return successfully (e.g., due to the drop of UDP packet). - Client will probably retry Adoption request; however, the request - will be refused in the form of TSIG "BADKEY" error because the - previous key was already revoked. In this case, client will - retransmit Adoption request signed with the next key, and expect a - response which has null "Other Data" for confirming the completion of - renewal. - - -2.5. Keying Schemes - - In Renewal message exchanges, there are no limitations as to which - keying method is actually used. The specification of keying - algorithms is independent of the general procedure of Renewal that is - described in section 2.3. - - Now this document specifies three algorithms in this section, but - other future documents can make extensions defining other methods. - - -2.5.1. DH Exchange for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.1. This - specification only describes the difference from it and special - notice; assume that all other points, such as keying material - computation, are the exactly same as the specification of [RFC2930] - 4.1. - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. KEY RR is - the client's Diffie-Hellman public key [RFC2539]. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 11] - -INTERNET-DRAFT October 2004 - - - TKEY "Mode" field stores the value of "DH exchange for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is used as a random, following [RFC2930] 4.1. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. If - any incompatible DH key is found in the request, "BADKEY" - [RFC2845] is given in Error field for response. "FORMERR" is given - if the query included no DH KEY. - - If there are no errors, the server processes a response according - to Diffie-Hellman algorithm and returns the answer. In this - answer, there is one TKEY RR in answer section and KEY RR(s) in - additional section. - - As long as no error has occurred, all values of TKEY are equal to - that of the request message except TKEY NAME, TKEY RDLEN, RDATA's - Inception, Expiration, Key Size and Key Data. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - TKEY "Key Data" is used as an additional nonce, following - [RFC2930] 4.1. - - The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in - the additional section and a server Diffie-Hellman KEY RR will - also be present in the answer section, following [RFC2930] 4.1. - - -2.5.2. Server Assigned Keying for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.4. This - specification only describes the difference from it and special - notice; assume that all other points, such as secret encrypting - method, are the exactly same as the specification of [RFC2930] 4.4. - - - -Kamite, et. al. Expires April 15, 2005 [Page 12] - -INTERNET-DRAFT October 2004 - - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. KEY RR is - used in encrypting the response. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - TKEY "Mode" field stores the value of "server assignment for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is provided following the specification of - [RFC2930] 4.4. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. - "FORMERR" is given if the query specified no encryption key. - - If there are no errors, the server response contains one TKEY RR - in the answer section, and echoes the KEY RR provided in the query - in the additional information section. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - TKEY "Key Data" is the assigned keying data encrypted under the - public key in the resolver provided KEY RR, which is the same as - [RFC2930] 4.4. - - -2.5.3. Resolver Assigned Keying for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.5. This - specification only describes the difference from it and special - notice; assume that all other points, such as secret encrypting - method, are the exactly same as the specification of [RFC2930] 4.5. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 13] - -INTERNET-DRAFT October 2004 - - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. TKEY RR - has the encrypted keying material and KEY RR is the server public - key used to encrypt the data. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - TKEY "Mode" field stores the value of "resolver assignment for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is the encrypted keying material. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. - "FORMERR" is given if the server does not have the corresponding - private key for the KEY RR that was shown sin the request. - - If there are no errors, the server returns a response. The - response contains a TKEY RR in the answer section to tell the - shared key's name and its usage time values. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - -2.6. Considerations about Non-compliant Hosts - - Key Renewal requests and responses must be exchanged between hosts - which can understand them and do proper processes. PartialRevoke - error messages will be only ignored if they should be returned to - non-compliant hosts. - - Note that server does not inform actively the necessity of renewal to - clients, but inform it as responses invoked by client's query. - Server needs not care whether the PartialRevoke errors has reached - - - -Kamite, et. al. Expires April 15, 2005 [Page 14] - -INTERNET-DRAFT October 2004 - - - client or not. If client has not received yet because of any reasons - such as packet drops, it will resend the queries, and finally will be - able to get PartialRevoke information. - - -3. Secret Storage - - Every server keeps all secrets and attached information, e.g., - Inception Time, Expiry Limit, etc. safely to be able to recover from - unexpected stop. To accomplish this, formally adopted keys SHOULD be - memorized not only on memory, but also be stored in the form of some - files. It will become more secure if they are stored in ecrypted - form. - - -4. Compulsory Key Revocation - -4.1. Compulsory Key Revocation by Server - - There is a rare but possible case that although servers have already - partially revoked keys, clients do not try to send any Renewal - requests. If this state continues, in the future it will become the - time of Expiry Limit. After Expiry Limit, the keys will be expired - and completely removed, so this is called Compulsory Key Revocation - by server. - - If Expiry Limit is too distant from the Partial Revocation Time, then - even though very long time passes, clients will be able to refresh - secrets only if they add TSIG signed with those old partially revoked - keys into requests, which is not safe. - - On the other hand, if Expiry Limit is too close to Partial Revocation - Time, perhaps clients might not be able to notice their keys' Partial - Revocation by getting "PartialRevoke" errors. - - Therefore, servers should set proper Expiry Limit to their keys, - considering both their keys' safety, and enough time for clients to - send requests and process renewal. - - -4.2. Authentication Methods Considerations - - It might be ideal to provide both SIG(0) and TSIG as authentication - methods. For example: - - A client and a server start SIG(0) authentication at first, to - establish TSIG shared keys by means of "Query for Diffie-Hellman - Exchanged Keying" as described in [RFC2930] 4.1. Once they get - - - -Kamite, et. al. Expires April 15, 2005 [Page 15] - -INTERNET-DRAFT October 2004 - - - shared secret, they keep using TSIG for queries and responses. - After a while the server returns a "ParitalRevoke" error and they - begin a key renewal process. Both TSIG signed with partially - revoked keys and SIG(0) are okay for authentication, but TSIG would - be easier to use considering calculation efficiency. - - Suppose now client is halted for long time with some reason. - Because server does not execute any renewal process, it will - finally do Compulsory Revocation. Even if client restarts and sends - a key Renewal request, it will fail because old key is already - deleted at server. - - At this moment, however, if client also uses SIG(0) as another - authentication method, it can make a new shared key again and - recover successfully by sending "Query for Diffie-Hellman Exchanged - Keying" with SIG(0). - - -5. Special Considerations for Two servers' Case - - This section refers to the case where both hosts are DNS servers - which can act as full resolvers as well and using one shared key - only. If one server (called Server A) wants to refresh a shared key - (called "Key A-B"), it will await a TKEY Renewal request from the - other server (called Server B). However, perhaps Server A wants to - refresh the key right now. - - In this case, Server A is allowed to send a Renewal request to Server - B, if Server A knows the Key A-B is too old and wants to renew it - immediately. - - Note that the initiative in key renewal belongs to Server A because - it can notice the Partial Revocation Time and decide key renewal. If - Server B has information about Partial Revocation Time as well, it - can also decide for itself to send Renewal request to Server A. - However, it is not essential for both two servers have information - about key renewal timing. - -5.1. To Cope with Collisions of Renewal Requests - - At least one of two hosts which use Key Renewal must know their key - renewal information such as Partial Revocation Time. It is okay that - both hosts have it. - - Provided that both two servers know key renewal timing information, - there is possibility for them to begin partial revocation and sending - Renewal requests to each other at the same time. Such collisions will - not happen so often because Renewal requests are usually invoked when - - - -Kamite, et. al. Expires April 15, 2005 [Page 16] - -INTERNET-DRAFT October 2004 - - - hosts want to send queries, but it is possible. - - When one of two servers tries to send Renewal requests, it MUST - protect old secrets that it has partially revoked and prevent it from - being refreshed by any requests from the other server (i.e., it must - lock the old secret during the process of renewal). While the server - is sending Renewal requests and waiting responses, it ignores the - other server's Renewal requests. - - Therefore, servers might fail to change secrets by means of their own - requests to others. After failure they will try to resend, but they - should wait for random delays by the next retries. If they get any - Renewal requests from others while they are waiting, their shared - keys may be refreshed, then they do not need to send any Renewal - requests now for themselves. - - -6. Key Name Considerations - - Since both servers and clients have only to distinguish new secrets - and old ones, keys' names do not need to be specified strictly. - However, it is recommended that some serial number or key generation - time be added to the name and that the names of keys between the same - pair of hosts should have some common labels among their keys. For - example, suppose A.example.com. and B.example.com. share the key - ".A.example.com.B.example.com." such as - "10010.A.example.com.B.example.com.". After key renewal, they change - their secret and name into "10011.A.example.com.B.example.com." - - Servers and clients must be able to use keys properly for each query. - Because TSIG secret keys themselves do not have any particular IDs to - be distinguished and would be identified by their names and - algorithm, it must be understood correctly what keys are refreshed. - - -7. Example Usage of Secret Key Renewal Mode - - This is an example of Renewal mode usage where a Server, - server.example.com, and a Client, client.exmple.com have an initial - shared secret key named "00.client.example.com.server.example.com". - - (1) The time values for key - "00.client.example.com.server.example.com" was set as follows: - Inception Time is at 1:00, Expiry Limit is at 21:00. - - (2) At Server, renewal time has been set: Partial Revocation Time - is at 20:00. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 17] - -INTERNET-DRAFT October 2004 - - - (3) Suppose the present time is 19:55. If Client sends a query - signed with key "00.client.example.com.server.example.com" to ask - the IP address of "www.example.com", finally it will get a proper - answer from Server with valid TSIG (NOERROR). - - (4) At 20:05. Client sends a query to ask the IP address of - "www2.example.com". It is signed with key - "00.client.example.com.server.example.com". Server returns an - answer for the IP address. However, server has begun retuning - PartialRevoke Error randomely. This answer includes valid TSIG MAC - signed with "00.client.example.com.server.example.com", and its - Error Code indicates PartialRevoke. Client understands that the - current key is partially revoked. - - (5) At 20:06. Client sends a Renewal request to Server. This - request is signed with key - "00.client.example.com.server.example.com". It includes data such - as: - - Question Section: - QNAME = 01.client.example.com. (Client can set this freely) - TYPE = TKEY - - Additional Section: - 01.client.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (DH exchange for key renewal) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - Additional Section also contains a KEY RR for DH and a TSIG RR. - - (6) As soon as Server receives this request, it verifies TSIG. It - is signed with the partially revoked key - "00.client.example.com.server.example.com". and Server accepts the - request. It creates a new key by Diffie-Hellman calculation and - returns an answer which includes data such as: - - Answer Section: - 01.client.example.com.server.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (DH exchange for key renewal) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - - -Kamite, et. al. Expires April 15, 2005 [Page 18] - -INTERNET-DRAFT October 2004 - - - Answer Section also contains KEY RRs for DH. - - Additional Section also contains a TSIG RR. - This response is signed with key - "00.client.example.com.server.example.com" without error. - - At the same time, Server decides to set the Partial Revocation Time - of this new key "01.client.example.com.server.example.com." as next - day's 15:00. - - (7) Client gets the response and checks TSIG MAC, and calculates - Diffie-Hellman. It will get a new key, and it has been named - "01.client.example.com.server.example.com" by Server. - - (8) At 20:07. Client sends an Adoption request to Server. This - request is signed with the previous key - "00.client.example.com.server.example.com". It includes: - - Question Section: - QNAME = 01.client.example.com.server.example.com. - TYPE = TKEY - - Additional Section: - 01.client.example.com.server.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (key adoption) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - Additional Section also contains a TSIG RR. - - (9) Server verifies the query's TSIG. It is signed with the - previous key and authenticated. It returns a response whose TKEY RR - is the same as the request's one. The response is signed with key - "00.client.example.com.server.example.com.". As soon as the - response is sent, Server revokes and removes the previous key. At - the same time, key "01.client.example.com.server.example.com." is - validated. - - (10) Client acknowledges the success of Adoption by receiving the - response. Then, it retries to send an original question about - "www2.example.com". It is signed with the adopted key - "01.client.example.com.server.example.com", so Server authenticates - it and returns an answer. - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 19] - -INTERNET-DRAFT October 2004 - - - (11) This key is used until next day's 15:00. After that, it will - be partially revoked again. - - -8. Security Considerations - - This document considers about how to refresh shared secret. Secret - changed by this method is used at servers in support of TSIG - [RFC2845]. - - [RFC2104] says that current attacks to HMAC do not indicate a - specific recommended frequency for key changes but periodic key - refreshment is a fundamental security practice that helps against - potential weaknesses of the function and keys, and limits the damage - of an exposed key. TKEY Secret Key Renewal provides the method of - periodical key refreshment. - - In TKEY Secret Key Renewal, clients need to send two requests - (Renewal and Adoption) and spend time to finish their key renewal - processes. Thus the usage period of secrets should be considered - carefully based on both TKEY processing performance and security. - - This document specifies the procedure of periodical key renewal, but - actually there is possibility for servers to have no choice other - than revoking their secret keys immediately especially when the keys - are found to be compromised by attackers. This is called "Emergency - Compulsory Revocation". For example, suppose the original Expiry - Limit was set at 21:00, Partial Revocation Time at 20:00 and - Inception Time at 1:00. if at 11:00 the key is found to be - compromised, the server sets Expiry Limit forcibly to be 11:00 or - before it. - - Consequently, once Compulsory Revocation (See section 4.) is carried - out, normal renewal process described in this document cannot be done - any more as far as the key is concerned. However, after such - accidents happened, the two hosts are able to establish secret keys - and begin renewal procedure only if they have other (non-compromised) - shared TSIG keys or safe SIG(0) keys for the authentication of - initial secret establishment such as Diffie-Hellman Exchanged Keying. - - -9. IANA Considerations - - IANA needs to allocate a value for "DH exchange for key renewal", - "server assignment for key renewal", "resolver assignment for key - renewal" and "key adoption" in the mode filed of TKEY. It also needs - to allocate a value for "PartialRevoke" from the extended RCODE - space. - - - -Kamite, et. al. Expires April 15, 2005 [Page 20] - -INTERNET-DRAFT October 2004 - - -10. Acknowledgements - - The authors would like to thank Olafur Gudmundsson, whose helpful - input and comments contributed greatly to this document. - - -11. References - -11.1. Normative References - -[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - -[RFC2539] - D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name - System (DNS)", RFC 2539, March 1999. - -[RFC2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, - May 2000. - -[RFC2930] - D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', - RFC 2930, September 2000. - -[RFC2931] - D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s - )", RFC 2931, September 2000. - -11.2. Informative References - -[RFC2104] - H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message - Authentication", RFC2104, February 1997. - - - - - - - - - - - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 21] - -INTERNET-DRAFT October 2004 - - -Authors' Addresses - - Yuji Kamite - NTT Communications Corporation - Tokyo Opera City Tower - 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo - 163-1421, Japan - EMail: y.kamite@ntt.com - - - Masaya Nakayama - Information Technology Center, The University of Tokyo - 2-11-16 Yayoi, Bunkyo-ku, Tokyo - 113-8658, Japan - EMail: nakayama@nc.u-tokyo.ac.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kamite, et. al. Expires April 15, 2005 [Page 22] - -INTERNET-DRAFT October 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Kamite, et. al. Expires April 15, 2005 [Page 23] - - - From 6b5b1d74a411bd2e3c2ff25291e1bf9412adaa3d Mon Sep 17 00:00:00 2001 From: Automatic Updater Date: Thu, 19 Nov 2009 05:17:19 +0000 Subject: [PATCH 16/18] update --- doc/private/SRCID | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/private/SRCID b/doc/private/SRCID index 78f9b4b99d..c2799e427f 100644 --- a/doc/private/SRCID +++ b/doc/private/SRCID @@ -1,6 +1,6 @@ -# $Id: SRCID,v 1.17 2009/11/19 00:19:08 tbox Exp $ +# $Id: SRCID,v 1.18 2009/11/19 05:17:19 tbox Exp $ # # This file must follow /bin/sh rules. It is imported directly via # configure. # -SRCID="( $Date: 2009/11/19 00:19:08 $ )" +SRCID="( $Date: 2009/11/19 05:17:19 $ )" From fad04ffe23de26d42bae77b69a983bd964a01883 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 19 Nov 2009 05:34:56 +0000 Subject: [PATCH 17/18] cleanup --- ...t-ietf-dnsext-trustupdate-threshold-00.txt | 1501 ------------- ...raft-ietf-dnsext-trustupdate-timers-05.txt | 729 ------- .../draft-ietf-dnsext-wcard-clarify-10.txt | 1063 ---------- ...t-ietf-dnsop-ipv6-dns-configuration-06.txt | 1848 ----------------- ...etf-dnsop-ipv6-transport-guidelines-01.txt | 300 --- ...etf-dnsop-key-rollover-requirements-02.txt | 389 ---- doc/draft/draft-ietf-dnsop-serverid-06.txt | 618 ------ doc/draft/draft-ietf-enum-e164-gstn-np-05.txt | 1588 -------------- .../draft-ietf-ipv6-node-requirements-08.txt | 1200 ----------- doc/draft/draft-ietf-secsh-dns-05.txt | 614 ------ ...t-ihren-dnsext-threshold-validation-00.txt | 519 ----- .../draft-park-ipv6-extensions-dns-pnp-00.txt | 1830 ---------------- doc/rfc/index | 4 + doc/rfc/rfc4294.txt | 1123 ++++++++++ doc/rfc/rfc4339.txt | 1459 +++++++++++++ .../rfc4472.txt} | 1483 +++++++------ doc/rfc/rfc4697.txt | 1011 +++++++++ 17 files changed, 4311 insertions(+), 12968 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt delete mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt delete mode 100644 doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt delete mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt delete mode 100644 doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt delete mode 100644 doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt delete mode 100644 doc/draft/draft-ietf-dnsop-serverid-06.txt delete mode 100644 doc/draft/draft-ietf-enum-e164-gstn-np-05.txt delete mode 100644 doc/draft/draft-ietf-ipv6-node-requirements-08.txt delete mode 100644 doc/draft/draft-ietf-secsh-dns-05.txt delete mode 100644 doc/draft/draft-ihren-dnsext-threshold-validation-00.txt delete mode 100644 doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt create mode 100644 doc/rfc/rfc4294.txt create mode 100644 doc/rfc/rfc4339.txt rename doc/{draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt => rfc/rfc4472.txt} (54%) create mode 100644 doc/rfc/rfc4697.txt diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt deleted file mode 100644 index eaf68656cc..0000000000 --- a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt +++ /dev/null @@ -1,1501 +0,0 @@ -Network Working Group J. Ihren -Internet-Draft Autonomica AB -Expires: April 18, 2005 O. Kolkman - RIPE NCC - B. Manning - EP.net - October 18, 2004 - - - - An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for - DNSSEC Trust Anchors. - draft-ietf-dnsext-trustupdate-threshold-00 - - -Status of this Memo - - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - This Internet-Draft will expire on April 18, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - -Abstract - - - The DNS Security Extensions (DNSSEC) works by validating so called - chains of authority. The start of these chains of authority are - usually public keys that are anchored in the DNS clients. These keys - are known as the so called trust anchors. - - - - - -Ihren, et al. Expires April 18, 2005 [Page 1] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - This memo describes a method how these client trust anchors can be - replaced using the DNS validation and querying mechanisms (in-band) - when the key pairs used for signing by zone owner are rolled. - - - This memo also describes a method to establish the validity of trust - anchors for initial configuration, or priming, using out of band - mechanisms. - - -Table of Contents - - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry - Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction and Background . . . . . . . . . . . . . . . . . 5 - 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5 - 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7 - 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8 - 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9 - 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10 - 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11 - 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12 - 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12 - 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12 - 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12 - 3.6 Removal of trust anchors for a trust point . . . . . . . . 12 - 3.7 No need for resolver-side overlap of old and new keys . . 13 - 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14 - 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.1.1 Bootstrapping trust anchors using a priming key . . . 14 - 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15 - 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 6.1 Threshold-based Trust Update Security Considerations . . . 17 - 6.2 Priming Key Security Considerations . . . . . . . . . . . 17 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 - 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 - A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 - B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23 - B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23 - B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . . 24 - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 2] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -1. Terminology - - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in - RFC2119 [1]. - - - The term "zone" refers to the unit of administrative control in the - Domain Name System. In this document "name server" denotes a DNS - name server that is authoritative (i.e. knows all there is to know) - for a DNS zone. A "zone owner" is the entity responsible for signing - and publishing a zone on a name server. The terms "authentication - chain", "bogus", "trust anchors" and "Island of Security" are defined - in [4]. Throughout this document we use the term "resolver" to mean - "Validating Stub Resolvers" as defined in [4]. - - - We use the term "security apex" as the zone for which a trust anchor - has been configured (by validating clients) and which is therefore, - by definition, at the root of an island of security. The - configuration of trust anchors is a client side issue. Therefore a - zone owner may not always know if their zone has become a security - apex. - - - A "stale anchor" is a trust anchor (a public key) that relates to a - key that is not used for signing. Since trust anchors indicate that - a zone is supposed to be secure a validator will mark the all data in - an island of security as bogus when all trust anchors become stale. - - - It is assumed that the reader is familiar with public key - cryptography concepts [REF: Schneier Applied Cryptography] and is - able to distinguish between the private and public parts of a key - based on the context in which we use the term "key". If there is a - possible ambiguity we will explicitly mention if a private or a - public part of a key is used. - - - The term "administrator" is used loosely throughout the text. In - some cases an administrator is meant to be a person, in other cases - the administrator may be a process that has been delegated certain - responsibilities. - - -1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points - - - Although the DNSSEC protocol does not make a distinction between - different keys the operational practice is that a distinction is made - between zone signing keys and key signing keys. A key signing key is - used to exclusively sign the DNSKEY Resource Record (RR) set at the - apex of a zone and the zone signing keys sign all the data in the - zone (including the DNSKEY RRset at the apex). - - - - - -Ihren, et al. Expires April 18, 2005 [Page 3] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - Keys that are intended to be used as the start of the authentication - chain for a particular zone, either because they are pointed to by a - parental DS RR or because they are configured as a trust anchor, are - called Secure Entry Point (SEP) keys. In practice these SEP keys - will be key signing keys. - - - In order for the mechanism described herein to work the keys that are - intended to be used as secure entry points MUST have the SEP [2] flag - set. In the examples it is assumed that keys with the SEP flag set - are used as key signing keys and thus exclusively sign the DNSKEY - RRset published at the apex of the zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 4] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -2. Introduction and Background - - - When DNSSEC signatures are validated the resolver constructs a chain - of authority from a pre-configured trust anchor to the DNSKEY - Resource Record (RR), which contains the public key that validates - the signature stored in an RRSIG RR. DNSSEC is designed so that the - administrator of a resolver can validate data in multiple islands of - security by configuring multiple trust anchors. - - - It is expected that resolvers will have more than one trust anchor - configured. Although there is no deployment experience it is not - unreasonable to expect resolvers to be configured with a number of - trust anchors that varies between order 1 and order 1000. Because - zone owners are expected to roll their keys, trust anchors will have - to be maintained (in the resolver end) in order not to become stale. - - - Since there is no global key maintenance policy for zone owners and - there are no mechanisms in the DNS to signal the key maintenance - policy it may be very hard for resolvers administrators to keep their - set of trust anchors up to date. For instance, if there is only one - trust anchor configured and the key maintenance policy is clearly - published, through some out of band trusted channel, then a resolver - administrator can probably keep track of key rollovers and update the - trust anchor manually. However, with an increasing number of trust - anchors all rolled according to individual policies that are all - published through different channels this soon becomes an - unmanageable problem. - - -2.1 Dangers of Stale Trust Anchors - - - Whenever a SEP key at a security apex is rolled there exists a danger - that "stale anchors" are created. A stale anchor is a trust anchor - (i.e. a public key configured in a validating resolver) that relates - to a private key that is no longer used for signing. - - - The problem with a stale anchors is that they will (from the - validating resolvers point of view) prove data to be false even - though it is actually correct. This is because the data is either - signed by a new key or is no longer signed and the resolver expects - data to be signed by the old (now stale) key. - - - This situation is arguably worse than not having a trusted key - configured for the secure entry point, since with a stale key no - lookup is typically possible (presuming that the default - configuration of a validating recursive nameserver is to not give out - data that is signed but failed to verify. - - - The danger of making configured trust anchors become stale anchors - - - - -Ihren, et al. Expires April 18, 2005 [Page 5] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - may be a reason for zone owners not to roll their keys. If a - resolver is configured with many trust anchors that need manual - maintenance it may be easy to not notice a key rollover at a security - apex, resulting in a stale anchor. - - - In Section 3 this memo sets out a lightweight, in-DNS, mechanism to - track key rollovers and modify the configured trust anchors - accordingly. The mechanism is stateless and does not need protocol - extensions. The proposed design is that this mechanism is - implemented as a "trust updating machine" that is run entirely - separate from the validating resolver except that the trust updater - will have influence over the trust anchors used by the latter. - - - In Section 4 we describe a method [Editors note: for now only the - frame work and a set of requirements] to install trust anchors. This - method can be used at first configuration or when the trust anchors - became stale (typically due to a failure to track several rollover - events). - - - The choice for which domains trust anchors are to be configured is a - local policy issue. So is the choice which trust anchors has - prevalence if there are multiple chains of trust to a given piece of - DNS data (e.g. when a parent zone and its child both have trust - anchors configured). Both issues are out of the scope of this - document. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 6] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -3. Threshold-based Trust Anchor Rollover - - -3.1 The Rollover - - - When a key pair is replaced all signatures (in DNSSEC these are the - RRSIG records) created with the old key will be replaced by new - signatures created by the new key. Access to the new public key is - needed to verify these signatures. - - - Since zone signing keys are in "the middle" of a chain of authority - they can be verified using the signature made by a key signing key. - Rollover of zone signing keys is therefore transparent to validators - and requires no action in the validator end. - - - But if a key signing key is rolled a resolver can determine its - authenticity by either following the authorization chain from the - parents DS record, an out-of-DNS authentication mechanism or by - relying on other trust anchors known for the zone in which the key is - rolled. - - - The threshold trust anchor rollover mechanism (or trust update), - described below, is based on using existing trust anchors to verify a - subset of the available signatures. This is then used as the basis - for a decision to accept the new keys as valid trust anchors. - - - Our example pseudo zone below contains a number of key signing keys - numbered 1 through Y and two zone signing keys A and B. During a key - rollover key 2 is replaced by key Y+1. The zone content changes - from: - - - example.com. DNSKEY key1 - example.com. DNSKEY key2 - example.com. DNSKEY key3 - ... - example.com. DNSKEY keyY - - - example.com. DNSKEY keyA - example.com. DNSKEY keyB - - - example.com. RRSIG DNSKEY ... (key1) - example.com. RRSIG DNSKEY ... (key2) - example.com. RRSIG DNSKEY ... (key3) - ... - example.com. RRSIG DNSKEY ... (keyY) - example.com. RRSIG DNSKEY ... (keyA) - example.com. RRSIG DNSKEY ... (keyB) - - - to: - - - - -Ihren, et al. Expires April 18, 2005 [Page 7] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - example.com. DNSKEY key1 - example.com. DNSKEY key3 - ... - example.com. DNSKEY keyY - example.com. DNSKEY keyY+1 - - - example.com. RRSIG DNSKEY ... (key1) - example.com. RRSIG DNSKEY ... (key3) - ... - example.com. RRSIG DNSKEY ... (keyY) - example.com. RRSIG DNSKEY ... (keyY+1) - example.com. RRSIG DNSKEY ... (keyA) - example.com. RRSIG DNSKEY ... (keyB) - - - When the rollover becomes visible to the verifying stub resolver it - will be able to verify the RRSIGs associated with key1, key3 ... - keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will - not be used for validation, since that key is previously unknown and - therefore not trusted. - - - Note that this example is simplified. Because of operational - considerations described in [5] having a period during which the two - key signing keys are both available is necessary. - - -3.2 Threshold-based Trust Update - - - The threshold-based trust update algorithm applies as follows. If - for a particular secure entry point - o if the DNSKEY RRset in the zone has been replaced by a more recent - one (as determined by comparing the RRSIG inception dates) - and - o if at least M configured trust anchors directly verify the related - RRSIGs over the new DNSKEY RRset - and - o the number of configured trust anchors that verify the related - RRSIGs over the new DNSKEY RRset exceed a locally defined minimum - number that should be greater than one - then all the trust anchors for the particular secure entry point are - replaced by the set of keys from the zones DNSKEY RRset that have the - SEP flag set. - - - The choices for the rollover acceptance policy parameter M is left to - the administrator of the resolver. To be certain that a rollover is - accepted up by resolvers using this mechanism zone owners should roll - as few SEP keys at a time as possible (preferably just one). That - way they comply to the most strict rollover acceptance policy of - M=N-1. - - - - - -Ihren, et al. Expires April 18, 2005 [Page 8] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - The value of M has an upper bound, limited by the number of of SEP - keys a zone owner publishes (i.e. N). But there is also a lower - bound, since it will not be safe to base the trust in too few - signatures. The corner case is M=1 when any validating RRSIG will be - sufficient for a complete replacement of the trust anchors for that - secure entry point. This is not a recommended configuration, since - that will allow an attacker to initiate rollover of the trust anchors - himself given access to just one compromised key. Hence M should in - be strictly larger than 1 as shown by the third requirement above. - - - If the rollover acceptance policy is M=1 then the result for the - rollover in our example above should be that the local database of - trust anchors is updated by removing key "key2" from and adding key - "keyY+1" to the key store. - - -3.3 Possible Trust Update States - - - We define five states for trust anchor configuration at the client - side. - PRIMING: There are no trust anchors configured. There may be priming - keys available for initial priming of trust anchors. - IN-SYNC: The set of trust anchors configured exactly matches the set - of SEP keys used by the zone owner to sign the zone. - OUT-OF-SYNC: The set of trust anchors is not exactly the same as the - set of SEP keys used by the zone owner to sign the zone but there - are enough SEP key in use by the zone owner that is also in the - trust anchor configuration. - UNSYNCABLE: There is not enough overlap between the configured trust - anchors and the set of SEP keys used to sign the zone for the new - set to be accepted by the validator (i.e. the number of - signatures that verify is not sufficient). - STALE: There is no overlap between the configured trust anchors and - the set of SEP keys used to sign the zone. Here validation of - data is no longer possible and hence we are in a situation where - the trust anchors are stale. - - - Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of - the automatic trust update mechanism. The PRIMING state is where a - validator is located before acquiring an up-to-date set of trust - anchors. The transition from PRIMING to IN-SYNC is manual (see - Section 4 below). - - - Example: assume a secure entry point with four SEP keys and a - validator with the policy that it will accept any update to the set - of trust anchors as long as no more than two signatures fail to - validate (i.e. M >= N-2) and at least two signature does validate - (i.e. M >= 2). In this case the rollover of a single key will move - the validator from IN-SYNC to OUT-OF-SYNC. When the trust update - - - - -Ihren, et al. Expires April 18, 2005 [Page 9] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - state machine updates the trust anchors it returns to state IN-SYNC. - - - If if for some reason it fails to update the trust anchors then the - next rollover (of a different key) will move the validator from - OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys - that are configured as trust anchors and that is sufficient to accpt - an automatic update of the trust anchors. - - - The UNSYNCABLE state is where a validator is located if it for some - reason fails to incorporate enough updates to the trust anchors to be - able to accept new updates according to its local policy. In this - example (i.e. with the policy specified above) this will either be - because M < N-2 or M < 2, which does not suffice to authenticate a - successful update of trust anchors. - - - Continuing with the previous example where two of the four SEP keys - have already rolled, but the validator has failed to update the set - of trust anchors. When the third key rolls over there will only be - one trust anchor left that can do successful validation. This is not - sufficient to enable automatic update of the trust anchors, hence the - new state is UNSYNCABLE. Note, however, that the remaining - up-to-date trust anchor is still enough to do successful validation - so the validator is still "working" from a DNSSEC point of view. - - - The STALE state, finally, is where a validator ends up when it has - zero remaining current trust anchors. This is a dangerous state, - since the stale trust anchors will cause all validation to fail. The - escape is to remove the stale trust anchors and thereby revert to the - PRIMING state. - - -3.4 Implementation notes - - - The DNSSEC protocol specification ordains that a DNSKEY to which a DS - record points should be self-signed. Since the keys that serve as - trust anchors and the keys that are pointed to by DS records serve - the same purpose, they are both secure entry points, we RECOMMEND - that zone owners who want to facilitate the automated rollover scheme - documented herein self-sign DNSKEYs with the SEP bit set and that - implementation check that DNSKEYs with the SEP bit set are - self-signed. - - - In order to maintain a uniform way of determining that a keyset in - the zone has been replaced by a more recent set the automatic trust - update machine SHOULD only accept new DNSKEY RRsets if the - accompanying RRSIGs show a more recent inception date than the - present set of trust anchors. This is also needed as a safe guard - against possible replay attacks where old updates are replayed - "backwards" (i.e. one change at a time, but going in the wrong - - - - -Ihren, et al. Expires April 18, 2005 [Page 10] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - direction, thereby luring the validator into the UNSYNCABLE and - finally STALE states). - - - In order to be resilient against failures the implementation should - collect the DNSKEY RRsets from (other) authoritative servers if - verification of the self signatures fails. - - - The threshold-based trust update mechanism SHOULD only be applied to - algorithms, as represented in the algorithm field in the DNSKEY/RRSIG - [3], that the resolver is aware of. In other words the SEP keys of - unknown algorithms should not be used when counting the number of - available signatures (the N constant) and the SEP keys of unknown - algorithm should not be entered as trust anchors. - - - When in state UNSYNCABLE or STALE manual intervention will be needed - to return to the IN-SYNC state. These states should be flagged. The - most appropriate action is human audit possibly followed by - re-priming (Section 4) the keyset (i.e. manual transfer to the - PRIMING state through removal of the configured trust anchors). - - - An implementation should regularly probe the the authoritative - nameservers for new keys. Since there is no mechanism to publish - rollover frequencies this document RECOMMENDS zone owners not to roll - their key signing keys more often than once per month and resolver - administrators to probe for key rollsovers (and apply the threshold - criterion for acceptance of trust update) not less often than once - per month. If the rollover frequency is higher than the probing - frequency then trust anchors may become stale. The exact relation - between the frequencies depends on the number of SEP keys rolled by - the zone owner and the value M configured by the resolver - administrator. - - - In all the cases below a transaction where the threshold criterion is - not satisfied should be considered bad (i.e. possibly spoofed or - otherwise corrupted data). The most appropriate action is human - audit. - - - There is one case where a "bad" state may be escaped from in an - automated fashion. This is when entering the STALE state where all - DNSSEC validation starts to fail. If this happens it is concievable - that it is better to completely discard the stale trust anchors - (thereby reverting to the PRIMING state where validation is not - possible). A local policy that automates removal of stale trust - anchors is therefore suggested. - - -3.5 Possible transactions - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 11] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -3.5.1 Single DNSKEY replaced - - - This is probably the most typical transaction on the zone owners - part. The result should be that if the threshold criterion is - satisfied then the key store is updated by removal of the old trust - anchor and addition of the new key as a new trust anchor. Note that - if the DNSKEY RRset contains exactly M keys replacement of keys is - not possible, i.e. for automatic rollover to work M must be stricly - less than N. - - -3.5.2 Addition of a new DNSKEY (no removal) - - - If the threshold criterion is satisfied then the new key is added as - a configured trust anchor. Not more than N-M keys can be added at - once, since otherwise the algorithm will fail. - - -3.5.3 Removal of old DNSKEY (no addition) - - - If the threshold criterion is satisfied then the old key is removed - from being a configured trust anchor. Note that it is not possible - to reduce the size of the DNSKEY RRset to a size smaller than the - minimum required value for M. - - -3.5.4 Multiple DNSKEYs replaced - - - Arguably it is not a good idea for the zone administrator to replace - several keys at the same time, but from the resolver point of view - this is exactly what will happen if the validating resolver for some - reason failed to notice a previous rollover event. - - - Not more than N-M keys can be replaced at one time or the threshold - criterion will not be satisfied. Or, expressed another way: as long - as the number of changed keys is less than or equal to N-M the - validator is in state OUT-OF-SYNC. When the number of changed keys - becomes greater than N-M the state changes to UNSYNCABLE and manual - action is needed. - - -3.6 Removal of trust anchors for a trust point - - - If the parent of a secure entry point gets signed and it's trusted - keys get configured in the key store of the validating resolver then - the configured trust anchors for the child should be removed entirely - unless explicitly configured (in the utility configuration) to be an - exception. - - - The reason for such a configuration would be that the resolver has a - local policy that requires maintenance of trusted keys further down - the tree hierarchy than strictly needed from the point of view. - - - - -Ihren, et al. Expires April 18, 2005 [Page 12] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - The default action when the parent zone changes from unsigned to - signed should be to remove the configured trust anchors for the - child. This form of "garbage collect" will ensure that the automatic - rollover machinery scales as DNSSEC deployment progresses. - - -3.7 No need for resolver-side overlap of old and new keys - - - It is worth pointing out that there is no need for the resolver to - keep state about old keys versus new keys, beyond the requirement of - tracking signature inception time for the covering RRSIGs as - described in Section 3.4. - - - From the resolver point of view there are only trusted and not - trusted keys. The reason is that the zone owner needs to do proper - maintenance of RRSIGs regardless of the resolver rollover mechanism - and hence must ensure that no key rolled out out the DNSKEY set until - there cannot be any RRSIGs created by this key still legally cached. - - - Hence the rollover mechanism is entirely stateless with regard to the - keys involved: as soon as the resolver (or in this case the rollover - tracking utility) detects a change in the DNSKEY RRset (i.e. it is - now in the state OUT-OF-SYNC) with a sufficient number of matching - RRSIGs the configured trust anchors are immediately updated (and - thereby the machine return to state IN-SYNC). I.e. the rollover - machine changes states (mostly oscillating between IN-SYNC and - OUT-OF-SYNC), but the status of the DNSSEC keys is stateless. - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 13] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -4. Bootstrapping automatic rollovers - - - It is expected that with the ability to automatically roll trust - anchors at trust points will follow a diminished unwillingness to - roll these keys, since the risks associated with stale keys are - minimized. - - - The problem of "priming" the trust anchors, or bringing them into - sync (which could happen if a resolver is off line for a long period - in which a set of SEP keys in a zone 'evolve' away from its trust - anchor configuration) remains. - - - For (re)priming we can rely on out of band technology and we propose - the following framework. - - -4.1 Priming Keys - - - If all the trust anchors roll somewhat frequently (on the order of - months or at most about a year) then it will not be possible to - design a device, or a software distribution that includes trust - anchors, that after being manufactured is put on a shelf for several - key rollover periods before being brought into use (since no trust - anchors that were known at the time of manufacture remain active). - - - To alleviate this we propose the concept of "priming keys". Priming - keys are ordinary DNSSEC Key Signing Keys with the characteristic - that - o The private part of a priming key signs the DNSKEY RRset at the - security apex, i.e. at least one RRSIG DNSKEY is created by a - priming key rather than by an "ordinary" trust anchor - o the public parts of priming keys are not included in the DNSKEY - RRset. Instead the public parts of priming keys are only - available out-of-band. - o The public parts of the priming keys have a validity period. - Within this period they can be used to obtain trust anchors. - o The priming key pairs are long lived (relative to the key rollover - period.) - - -4.1.1 Bootstrapping trust anchors using a priming key - - - To install the trust anchors for a particular security apex an - administrator of a validating resolver will need to: - o query for the DNSKEY RRset of the zone at the security apex; - o verify the self signatures of all DNSKEYs in the RRset; - o verify the signature of the RRSIG made with a priming key -- - verification using one of the public priming keys that is valid at - that moment is sufficient; - - - - - -Ihren, et al. Expires April 18, 2005 [Page 14] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - o create the trust anchors by extracting the DNSKEY RRs with the SEP - flag set. - The SEP keys with algorithms unknown to the validating resolver - SHOULD be ignored during the creation of the trust anchors. - - -4.1.2 Distribution of priming keys - - - The public parts of the priming keys SHOULD be distributed - exclusively through out-of-DNS mechanisms. The requirements for a - distribution mechanism are: - o it can carry the "validity" period for the priming keys; - o it can carry the self-signature of the priming keys; - o and it allows for verification using trust relations outside the - DNS. - A distribution mechanism would benefit from: - o the availability of revocation lists; - o the ability of carrying zone owners policy information such as - recommended values for "M" and "N" and a rollover frequency; - o and the technology on which is based is readily available. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 15] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -5. The Threshold Rollover Mechanism vs Priming - - - There is overlap between the threshold-based trust updater and the - Priming method. One could exclusively use the Priming method for - maintaining the trust anchors. However the priming method probably - relies on "non-DNS' technology and may therefore not be available for - all devices that have a resolver. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 16] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -6. Security Considerations - - -6.1 Threshold-based Trust Update Security Considerations - - - A clear issue for resolvers will be how to ensure that they track all - rollover events for the zones they have configure trust anchors for. - Because of temporary outages validating resolvers may have missed a - rollover of a KSK. The parameters that determine the robustness - against failures are: the length of the period between rollovers - during which the KSK set is stable and validating resolvers can - actually notice the change; the number of available KSKs (i.e. N) - and the number of signatures that may fail to validate (i.e. N-M). - - - With a large N (i.e. many KSKs) and a small value of M this - operation becomes more robust since losing one key, for whatever - reason, will not be crucial. Unfortunately the choice for the number - of KSKs is a local policy issue for the zone owner while the choice - for the parameter M is a local policy issue for the resolver - administrator. - - - Higher values of M increase the resilience against attacks somewhat; - more signatures need to verify for a rollover to be approved. On the - other hand the number of rollover events that may pass unnoticed - before the resolver reaches the UNSYNCABLE state goes down. - - - The threshold-based trust update intentionally does not provide a - revocation mechanism. In the case that a sufficient number of - private keys of a zone owner are simultaneously compromised the the - attacker may use these private keys to roll the trust anchors of (a - subset of) the resolvers. This is obviously a bad situation but it - is not different from most other public keys systems. - - - However, it is important to point out that since any reasonable trust - anchor rollover policy (in validating resolvers) will require more - than one RRSIG to validate this proposal does provide security - concious zone administrators with the option of not storing the - individual private keys in the same location and thereby decreasing - the likelihood of simultaneous compromise. - - -6.2 Priming Key Security Considerations - - - Since priming keys are not included in the DNSKEY RR set they are - less sensitive to packet size constraints and can be chosen - relatively large. The private parts are only needed to sign the - DNSKEY RR set during the validity period of the particular priming - key pair. Note that the private part of the priming key is used each - time when a DNSKEY RRset has to be resigned. In practice there is - therefore little difference between the usage pattern of the private - - - - -Ihren, et al. Expires April 18, 2005 [Page 17] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - part of key signing keys and priming keys. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 18] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -7. IANA Considerations - - - NONE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 19] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -8. References - - -8.1 Normative References - - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - - [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - - [3] Arends, R., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-10 (work in progress), - September 2004. - - -8.2 Informative References - - - [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-12 (work in progress), September - 2004. - - - [5] Kolkman, O., "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practices-01 (work in - progress), May 2004. - - - [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 - Public Key Infrastructure Certificate and CRL Profile", RFC - 2459, January 1999. - - - -Authors' Addresses - - - Johan Ihren - Autonomica AB - Bellmansgatan 30 - Stockholm SE-118 47 - Sweden - - - EMail: johani@autonomica.se - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 20] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - - Olaf M. Kolkman - RIPE NCC - Singel 256 - Amsterdam 1016 AB - NL - - - Phone: +31 20 535 4444 - EMail: olaf@ripe.net - URI: http://www.ripe.net/ - - - - Bill Manning - EP.net - Marina del Rey, CA 90295 - USA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 21] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -Appendix A. Acknowledgments - - - The present design for in-band automatic rollovers of DNSSEC trust - anchors is the result of many conversations and it is no longer - possible to remember exactly who contributed what. - - - In addition we've also had appreciated help from (in no particular - order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt - Larson and Mark Kosters. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 22] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -Appendix B. Document History - - - This appendix will be removed if and when the document is submitted - to the RFC editor. - - - The version you are reading is tagged as $Revision: 1.1 $. - - - Text between square brackets, other than references, are editorial - comments and will be removed. - - -B.1 prior to version 00 - - - This draft was initially published as a personal submission under the - name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt. - - - Kolkman documented the ideas provided by Ihren and Manning. In the - process of documenting (and prototyping) Kolkman changed some of the - details of the M-N algorithms working. Ihren did not have a chance - to review the draft before Kolkman posted; - - - Kolkman takes responsibilities for omissions, fuzzy definitions and - mistakes. - - -B.2 version 00 - o The name of the draft was changed as a result of the draft being - adopted as a working group document. - o A small section on the concept of stale trust anchors was added. - o The different possible states are more clearly defined, including - examples of transitions between states. - o The terminology is changed throughout the document. The old term - "M-N" is replaced by "threshold" (more or less). Also the - interpretation of the constants M and N is significantly - simplified to bring the usage more in line with "standard" - threshold terminlogy. - - - - - - - - - - - - - - - - - - -Ihren, et al. Expires April 18, 2005 [Page 23] -Internet-Draft DNSSEC Threshold-based Trust Update October 2004 - - - -Intellectual Property Statement - - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - -Disclaimer of Validity - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Copyright Statement - - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - -Acknowledgment - - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Ihren, et al. Expires April 18, 2005 [Page 24] \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt deleted file mode 100644 index 02852591ec..0000000000 --- a/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt +++ /dev/null @@ -1,729 +0,0 @@ - - - -Network Working Group M. StJohns -Internet-Draft Nominum, Inc. -Intended status: Informational November 29, 2006 -Expires: June 2, 2007 - - - Automated Updates of DNSSEC Trust Anchors - draft-ietf-dnsext-trustupdate-timers-05 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on June 2, 2007. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes a means for automated, authenticated and - authorized updating of DNSSEC "trust anchors". The method provides - protection against N-1 key compromises of N keys in the trust point - key set. Based on the trust established by the presence of a current - anchor, other anchors may be added at the same place in the - hierarchy, and, ultimately, supplant the existing anchor(s). - - This mechanism will require changes to resolver management behavior - - - -StJohns Expires June 2, 2007 [Page 1] - -Internet-Draft trustanchor-update November 2006 - - - (but not resolver resolution behavior), and the addition of a single - flag bit to the DNSKEY record. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 - 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5 - 2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 - 2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 - 2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 - 2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 - 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 - 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8 - 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9 - 6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9 - 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 - 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 - 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10 - 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 - 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11 - 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11 - 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 - 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 - Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . . . 13 - - - - - - - - - - - - - - -StJohns Expires June 2, 2007 [Page 2] - -Internet-Draft trustanchor-update November 2006 - - -1. Introduction - - As part of the reality of fielding DNSSEC (Domain Name System - Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has - come to the realization that there will not be one signed name space, - but rather islands of signed name space each originating from - specific points (i.e. 'trust points') in the DNS tree. Each of those - islands will be identified by the trust point name, and validated by - at least one associated public key. For the purpose of this document - we'll call the association of that name and a particular key a 'trust - anchor'. A particular trust point can have more than one key - designated as a trust anchor. - - For a DNSSEC-aware resolver to validate information in a DNSSEC - protected branch of the hierarchy, it must have knowledge of a trust - anchor applicable to that branch. It may also have more than one - trust anchor for any given trust point. Under current rules, a chain - of trust for DNSSEC-protected data that chains its way back to ANY - known trust anchor is considered 'secure'. - - Because of the probable balkanization of the DNSSEC tree due to - signing voids at key locations, a resolver may need to know literally - thousands of trust anchors to perform its duties. (e.g. Consider an - unsigned ".COM".) Requiring the owner of the resolver to manually - manage this many relationships is problematic. It's even more - problematic when considering the eventual requirement for key - replacement/update for a given trust anchor. The mechanism described - herein won't help with the initial configuration of the trust anchors - in the resolvers, but should make trust point key replacement/ - rollover more viable. - - As mentioned above, this document describes a mechanism whereby a - resolver can update the trust anchors for a given trust point, mainly - without human intervention at the resolver. There are some corner - cases discussed (e.g. multiple key compromise) that may require - manual intervention, but they should be few and far between. This - document DOES NOT discuss the general problem of the initial - configuration of trust anchors for the resolver. - -1.1. Compliance Nomenclature - - 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 BCP 14, [RFC2119]. - - - - - - - -StJohns Expires June 2, 2007 [Page 3] - -Internet-Draft trustanchor-update November 2006 - - -2. Theory of Operation - - The general concept of this mechanism is that existing trust anchors - can be used to authenticate new trust anchors at the same point in - the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a - DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section - 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is - validated by an existing trust anchor, then the resolver can add the - new key to its valid set of trust anchors for that trust point. - - There are some issues with this approach which need to be mitigated. - For example, a compromise of one of the existing keys could allow an - attacker to add their own 'valid' data. This implies a need for a - method to revoke an existing key regardless of whether or not that - key is compromised. As another example, assuming a single key - compromise, we need to prevent an attacker from adding a new key and - revoking all the other old keys. - -2.1. Revocation - - Assume two trust anchor keys A and B. Assume that B has been - compromised. Without a specific revocation bit, B could invalidate A - simply by sending out a signed trust point key set which didn't - contain A. To fix this, we add a mechanism which requires knowledge - of the private key of a DNSKEY to revoke that DNSKEY. - - A key is considered revoked when the resolver sees the key in a self- - signed RRSet and the key has the REVOKE bit (see Section 7 below) set - to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this - key as a trust anchor or for any other purposes except validating the - RRSIG it signed over the DNSKEY RRSet specifically for the purpose of - validating the revocation. Unlike the 'Add' operation below, - revocation is immediate and permanent upon receipt of a valid - revocation at the resolver. - - A self-signed RRSet is a DNSKEY RRSet which contains the specific - DNSKEY and for which there is a corresponding validated RRSIG record. - It's not a special DNSKEY RRSet, just a way of describing the - validation requirements for that RRSet. - - N.B. A DNSKEY with the REVOKE bit set has a different fingerprint - than one without the bit set. This affects the matching of a DNSKEY - to DS records in the parent, or the fingerprint stored at a resolver - used to configure a trust point. - - In the given example, the attacker could revoke B because it has - knowledge of B's private key, but could not revoke A. - - - - -StJohns Expires June 2, 2007 [Page 4] - -Internet-Draft trustanchor-update November 2006 - - -2.2. Add Hold-Down - - Assume two trust point keys A and B. Assume that B has been - compromised. An attacker could generate and add a new trust anchor - key - C (by adding C to the DNSKEY RRSet and signing it with B), and - then invalidate the compromised key. This would result in both the - attacker and owner being able to sign data in the zone and have it - accepted as valid by resolvers. - - To mitigate but not completely solve this problem, we add a hold-down - time to the addition of the trust anchor. When the resolver sees a - new SEP key in a validated trust point DNSKEY RRSet, the resolver - starts an acceptance timer, and remembers all the keys that validated - the RRSet. If the resolver ever sees the DNSKEY RRSet without the - new key but validly signed, it stops the acceptance process for that - key and resets the acceptance timer. If all of the keys which were - originally used to validate this key are revoked prior to the timer - expiring, the resolver stops the acceptance process and resets the - timer. - - Once the timer expires, the new key will be added as a trust anchor - the next time the validated RRSet with the new key is seen at the - resolver. The resolver MUST NOT treat the new key as a trust anchor - until the hold down time expires AND it has retrieved and validated a - DNSKEY RRSet after the hold down time which contains the new key. - - N.B.: Once the resolver has accepted a key as a trust anchor, the key - MUST be considered a valid trust anchor by that resolver until - explictly revoked as described above. - - In the given example, the zone owner can recover from a compromise by - revoking B and adding a new key D and signing the DNSKEY RRSet with - both A and B. - - The reason this does not completely solve the problem has to do with - the distributed nature of DNS. The resolver only knows what it sees. - A determined attacker who holds one compromised key could keep a - single resolver from realizing that key had been compromised by - intercepting 'real' data from the originating zone and substituting - their own (e.g. using the example, signed only by B). This is no - worse than the current situation assuming a compromised key. - -2.3. Active Refresh - - A resolver which has been configured for automatic update of keys - from a particular trust point MUST query that trust point (e.g. do a - lookup for the DNSKEY RRSet and related RRSIG records) no less often - than the lesser of 15 days or half the original TTL for the DNSKEY - - - -StJohns Expires June 2, 2007 [Page 5] - -Internet-Draft trustanchor-update November 2006 - - - RRSet or half the RRSIG expiration interval and no more often than - once per hour. The expiration interval is the amount of time from - when the RRSIG was last retrieved until the expiration time in the - RRSIG. - - If the query fails, the resolver MUST repeat the query until - satisfied no more often than once an hour and no less often than the - lesser of 1 day or 10% of the original TTL or 10% of the original - expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 * - origTTL, .1 * expireInterval)). - -2.4. Resolver Parameters - -2.4.1. Add Hold-Down Time - - The add hold-down time is 30 days or the expiration time of the - original TTL of the first trust point DNSKEY RRSet which contained - the new key, whichever is greater. This ensures that at least two - validated DNSKEY RRSets which contain the new key MUST be seen by the - resolver prior to the key's acceptance. - -2.4.2. Remove Hold-Down Time - - The remove hold-down time is 30 days. This parameter is solely a key - management database bookeeping parameter. Failure to remove - information about the state of defunct keys from the database will - not adversely impact the security of this protocol, but may end up - with a database cluttered with obsolete key information. - -2.4.3. Minimum Trust Anchors per Trust Point - - A compliant resolver MUST be able to manage at least five SEP keys - per trust point. - - -3. Changes to DNSKEY RDATA Wire Format - - Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE' - flag. If this bit is set to '1', AND the resolver sees an - RRSIG(DNSKEY) signed by the associated key, then the resolver MUST - consider this key permanently invalid for all purposes except for - validating the revocation. - - -4. State Table - - The most important thing to understand is the resolver's view of any - key at a trust point. The following state table describes that view - - - -StJohns Expires June 2, 2007 [Page 6] - -Internet-Draft trustanchor-update November 2006 - - - at various points in the key's lifetime. The table is a normative - part of this specification. The initial state of the key is 'Start'. - The resolver's view of the state of the key changes as various events - occur. - - This is the state of a trust point key as seen from the resolver. - The column on the left indicates the current state. The header at - the top shows the next state. The intersection of the two shows the - event that will cause the state to transition from the current state - to the next. - - - NEXT STATE - -------------------------------------------------- - FROM |Start |AddPend |Valid |Missing|Revoked|Removed| - ---------------------------------------------------------- - Start | |NewKey | | | | | - ---------------------------------------------------------- - AddPend |KeyRem | |AddTime| | | - ---------------------------------------------------------- - Valid | | | |KeyRem |Revbit | | - ---------------------------------------------------------- - Missing | | |KeyPres| |Revbit | | - ---------------------------------------------------------- - Revoked | | | | | |RemTime| - ---------------------------------------------------------- - Removed | | | | | | | - ---------------------------------------------------------- - - - State Table - -4.1. Events - NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. - That key will become a new trust anchor for the named trust point - after it's been present in the RRSet for at least 'add time'. - KeyPres The key has returned to the valid DNSKEY RRSet. - KeyRem The resolver sees a valid DNSKEY RRSet that does not contain - this key. - AddTime The key has been in every valid DNSKEY RRSet seen for at - least the 'add time'. - RemTime A revoked key has been missing from the trust point DNSKEY - RRSet for sufficient time to be removed from the trust set. - RevBit The key has appeared in the trust anchor DNSKEY RRSet with - its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet - signed by this key. - - - - - -StJohns Expires June 2, 2007 [Page 7] - -Internet-Draft trustanchor-update November 2006 - - -4.2. States - Start The key doesn't yet exist as a trust anchor at the resolver. - It may or may not exist at the zone server, but either hasn't yet - been seen at the resolver or was seen but was absent from the last - DNSKEY RRSet (e.g. KeyRem event). - AddPend The key has been seen at the resolver, has its 'SEP' bit - set, and has been included in a validated DNSKEY RRSet. There is - a hold-down time for the key before it can be used as a trust - anchor. - Valid The key has been seen at the resolver and has been included in - all validated DNSKEY RRSets from the time it was first seen up - through the hold-down time. It is now valid for verifying RRSets - that arrive after the hold down time. Clarification: The DNSKEY - RRSet does not need to be continuously present at the resolver - (e.g. its TTL might expire). If the RRSet is seen, and is - validated (i.e. verifies against an existing trust anchor), this - key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. - Missing This is an abnormal state. The key remains as a valid trust - point key, but was not seen at the resolver in the last validated - DNSKEY RRSet. This is an abnormal state because the zone operator - should be using the REVOKE bit prior to removal. - Revoked This is the state a key moves to once the resolver sees an - RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains - this key with its REVOKE bit set to '1'. Once in this state, this - key MUST permanently be considered invalid as a trust anchor. - Removed After a fairly long hold-down time, information about this - key may be purged from the resolver. A key in the removed state - MUST NOT be considered a valid trust anchor. (Note: this state is - more or less equivalent to the "Start" state, except that it's bad - practice to re-introduce previously used keys - think of this as - the holding state for all the old keys for which the resolver no - longer needs to track state.) - - -5. Trust Point Deletion - - A trust point which has all of its trust anchors revoked is - considered deleted and is treated as if the trust point was never - configured. If there are no superior configured trust points, data - at and below the deleted trust point are considered insecure by the - resolver. If there ARE superior configured trust points, data at and - below the deleted trust point are evaluated with respect to the - superior trust point(s). - - Alternately, a trust point which is subordinate to another configured - trust point MAY be deleted by a resolver after 180 days where such - subordinate trust point validly chains to a superior trust point. - The decision to delete the subordinate trust anchor is a local - - - -StJohns Expires June 2, 2007 [Page 8] - -Internet-Draft trustanchor-update November 2006 - - - configuration decision. Once the subordinate trust point is deleted, - validation of the subordinate zone is dependent on validating the - chain of trust to the superior trust point. - - -6. Scenarios - Informative - - The suggested model for operation is to have one active key and one - stand-by key at each trust point. The active key will be used to - sign the DNSKEY RRSet. The stand-by key will not normally sign this - RRSet, but the resolver will accept it as a trust anchor if/when it - sees the signature on the trust point DNSKEY RRSet. - - Since the stand-by key is not in active signing use, the associated - private key may (and should) be provided with additional protections - not normally available to a key that must be used frequently. E.g. - locked in a safe, split among many parties, etc. Notionally, the - stand-by key should be less subject to compromise than an active key, - but that will be dependent on operational concerns not addressed - here. - -6.1. Adding a Trust Anchor - - Assume an existing trust anchor key 'A'. - 1. Generate a new key pair. - 2. Create a DNSKEY record from the key pair and set the SEP and Zone - Key bits. - 3. Add the DNSKEY to the RRSet. - 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - - 'A'. - 5. Wait a while (i.e. for various resolvers timers to go off and for - them to retrieve the new DNSKEY RRSet and signatures). - 6. The new trust anchor will be populated at the resolvers on the - schedule described by the state table and update algorithm - see - Section 2 above - -6.2. Deleting a Trust Anchor - - Assume existing trust anchors 'A' and 'B' and that you want to revoke - and delete 'A'. - 1. Set the revocation bit on key 'A'. - 2. Sign the DNSKEY RRSet with both 'A' and 'B'. - 'A' is now revoked. The operator should include the revoked 'A' in - the RRSet for at least the remove hold-down time, but then may remove - it from the DNSKEY RRSet. - - - - - - -StJohns Expires June 2, 2007 [Page 9] - -Internet-Draft trustanchor-update November 2006 - - -6.3. Key Roll-Over - - Assume existing keys A and B. 'A' is actively in use (i.e. has been - signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been - in the DNSKEY RRSet and is a valid trust anchor, but wasn't being - used to sign the RRSet.) - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'A'. - 4. Sign the RRSet with 'A' and 'B'. - 'A' is now revoked, 'B' is now the active key, and 'C' will be the - stand-by key once the hold-down expires. The operator should include - the revoked 'A' in the RRSet for at least the remove hold-down time, - but may then remove it from the DNSKEY RRSet. - -6.4. Active Key Compromised - - This is the same as the mechanism for Key Roll-Over (Section 6.3) - above assuming 'A' is the active key. - -6.5. Stand-by Key Compromised - - Using the same assumptions and naming conventions as Key Roll-Over - (Section 6.3) above: - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'B'. - 4. Sign the RRSet with 'A' and 'B'. - 'B' is now revoked, 'A' remains the active key, and 'C' will be the - stand-by key once the hold-down expires. 'B' should continue to be - included in the RRSet for the remove hold-down time. - -6.6. Trust Point Deletion - - To delete a trust point which is subordinate to another configured - trust point (e.g. example.com to .com) requires some juggling of the - data. The specific process is: - 1. Generate a new DNSKEY and DS record and provide the DS record to - the parent along with DS records for the old keys - 2. Once the parent has published the DSs, add the new DNSKEY to the - RRSet and revoke ALL of the old keys at the same time while - signing the DNSKEY RRSet with all of the old and new keys. - 3. After 30 days stop publishing the old, revoked keys and remove - any corresponding DS records in the parent. - Revoking the old trust point keys at the same time as adding new keys - that chain to a superior trust prevents the resolver from adding the - new keys as trust anchors. Adding DS records for the old keys avoids - a race condition where either the subordinate zone becomes unsecure - - - -StJohns Expires June 2, 2007 [Page 10] - -Internet-Draft trustanchor-update November 2006 - - - (because the trust point was deleted) or becomes bogus (because it - didn't chain to the superior zone). - - -7. IANA Considerations - - The IANA will need to assign a bit in the DNSKEY flags field (see - section 4.3 of [RFC3755]) for the REVOKE bit. There are no other - IANA actions required. - - -8. Security Considerations - - In addition to the following sections, see also Theory of Operation - above and especially Section 2.2 for related discussions. - -8.1. Key Ownership vs Acceptance Policy - - The reader should note that, while the zone owner is responsible for - creating and distributing keys, it's wholly the decision of the - resolver owner as to whether to accept such keys for the - authentication of the zone information. This implies the decision to - update trust anchor keys based on trust for a current trust anchor - key is also the resolver owner's decision. - - The resolver owner (and resolver implementers) MAY choose to permit - or prevent key status updates based on this mechanism for specific - trust points. If they choose to prevent the automated updates, they - will need to establish a mechanism for manual or other out-of-band - updates outside the scope of this document. - -8.2. Multiple Key Compromise - - This scheme permits recovery as long as at least one valid trust - anchor key remains uncompromised. E.g. if there are three keys, you - can recover if two of them are compromised. The zone owner should - determine their own level of comfort with respect to the number of - active valid trust anchors in a zone and should be prepared to - implement recovery procedures once they detect a compromise. A - manual or other out-of-band update of all resolvers will be required - if all trust anchor keys at a trust point are compromised. - -8.3. Dynamic Updates - - Allowing a resolver to update its trust anchor set based on in-band - key information is potentially less secure than a manual process. - However, given the nature of the DNS, the number of resolvers that - would require update if a trust anchor key were compromised, and the - - - -StJohns Expires June 2, 2007 [Page 11] - -Internet-Draft trustanchor-update November 2006 - - - lack of a standard management framework for DNS, this approach is no - worse than the existing situation. - - -9. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -Editorial Comments - - [msj2] msj: To be assigned. - - -Author's Address - - Michael StJohns - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - USA - - Phone: +1-301-528-4729 - Email: Mike.StJohns@nominum.com - URI: www.nominum.com - - - - - - - - - - - -StJohns Expires June 2, 2007 [Page 12] - -Internet-Draft trustanchor-update November 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -StJohns Expires June 2, 2007 [Page 13] - - diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt deleted file mode 100644 index 9cf88a5831..0000000000 --- a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt +++ /dev/null @@ -1,1063 +0,0 @@ -Internet-Draft dnsext-wcard January 9, 2006 - -DNSEXT Working Group E. Lewis -INTERNET DRAFT NeuStar -Expiration Date: July 9, 2006 January 9, 2006 -Updates RFC 1034, RFC 2672 - - The Role of Wildcards - in the Domain Name System - draft-ietf-dnsext-wcard-clarify-10.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that - any applicable patent or other IPR claims of which he or she is - aware have been or will be disclosed, and any of which he or she - becomes aware will be disclosed, in accordance with Section 6 of - BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This Internet-Draft will expire on July 9, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - 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. - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 1] - -Internet-Draft dnsext-wcard January 9, 2006 - -Table of Contents - -1. Introduction . . . . . . . . . . . . . . . . 3 -1 1 Motivation 3 -1 2 The Original Definition 3 -1 3 Roadmap to This Document 4 -1 3 1 New Terms 4 -1.3.2 Changed Text 5 -1.3.3 Considerations with Special Types 5 -1.4 Standards Terminology 5 -2. Wildcard Syntax . . . . . . . . . . . . . . . 6 -2.1 Identifying a Wildcard 6 -2.1.1 Wild Card Domain Name and Asterisk Label 6 -2.1.2 Asterisks and Other Characters 6 -2.1.3 Non-terminal Wild Card Domain Names 6 -2.2 Existence Rules 7 -2.2.1 An Example 7 -2.2.2 Empty Non-terminals 9 -2.2.3 Yet Another Definition of Existence 10 -2.3 When is a Wild Card Domain Name Not Special 10 -3. Impact of a Wild Card Domain Name On a Response . . . . . 10 -3.1 Step 2 10 -3.2 Step 3 11 -3.3 Part 'c' 11 -3.3.1 Closest Encloser and the Source of Synthesis 12 -3.3.2 Closest Encloser and Source of Synthesis Examples 12 -3.3.3 Type Matching 13 -4. Considerations with Special Types . . . . . . . . . 13 -4.1 SOA RRSet at a Wild Card Domain Name 13 -4.2 NS RRSet at a Wild Card Domain Name 14 -4.2.1 Discarded Notions 14 -4.3 CNAME RRSet at a Wild Card Domain Name 15 -4.4 DNAME RRSet at a Wild Card Domain Name 15 -4.5 SRV RRSet at a Wild Card Domain Name 16 -4.6 DS RRSet at a Wild Card Domain Name 16 -4.7 NSEC RRSet at a Wild Card Domain Name 17 -4.8 RRSIG at a Wild Card Domain Name 17 -4.9 Empty Non-terminal Wild Card Domain Name 17 -5. Security Considerations . . . . . . . . . . . . . 17 -6. IANA Considerations . . . . . . . . . . . . . 17 -7. References . . . . . . . . . . . . . 17 -8. Editor . . . . . . . . . . . . . 18 -9. Others Contributing to the Document . . . . . . . . 18 -10. Trailing Boilerplate . . . . . . . . . . . . . 19 - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 2] - -Internet-Draft dnsext-wcard January 9, 2006 - -1. Introduction - - In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the - synthesis of answers from special resource records called - wildcards. The definition in RFC 1034 is incomplete and has - proven to be confusing. This document describes the wildcard - synthesis by adding to the discussion and making limited - modifications. Modifications are made to close inconsistencies - that have led to interoperability issues. This description - does not expand the service intended by the original definition. - - Staying within the spirit and style of the original documents, - this document avoids specifying rules for DNS implementations - regarding wildcards. The intention is to only describe what is - needed for interoperability, not restrict implementation choices. - In addition, consideration is given to minimize any backwards - compatibility issues with implementations that comply with RFC - 1034's definition. - - This document is focused on the concept of wildcards as defined - in RFC 1034. Nothing is implied regarding alternative means of - synthesizing resource record sets, nor are alternatives discussed. - -1.1 Motivation - - Many DNS implementations diverge, in different ways, from the - original definition of wildcards. Although there is clearly a - need to clarify the original documents in light of this alone, - the impetus for this document lay in the engineering of the DNS - security extensions [RFC4033]. With an unclear definition of - wildcards the design of authenticated denial became entangled. - - This document is intended to limit its changes, documenting only - those based on implementation experience, and to remain as close - to the original document as possible. To reinforce that this - document is meant to clarify and adjust and not redefine wildcards, - relevant sections of RFC 1034 are repeated verbatim to facilitate - comparison of the old and new text. - -1.2 The Original Definition - - The definition of the wildcard concept is comprised by the - documentation of the algorithm by which a name server prepares - a response (in RFC 1034's section 4.3.2) and the way in which - a resource record (set) is identified as being a source of - synthetic data (section 4.3.3). - - This is the definition of the term "wildcard" as it appears in - RFC 1034, section 4.3.3. - - - -DNSEXT Working Group Expires July 9, 2006 [Page 3] - -Internet-Draft dnsext-wcard January 9, 2006 - -# In the previous algorithm, special treatment was given to RRs with -# owner names starting with the label "*". Such RRs are called -# wildcards. Wildcard RRs can be thought of as instructions for -# synthesizing RRs. When the appropriate conditions are met, the name -# server creates RRs with an owner name equal to the query name and -# contents taken from the wildcard RRs. - - This passage follows the algorithm in which the term wildcard - is first used. In this definition, wildcard refers to resource - records. In other usage, wildcard has referred to domain names, - and it has been used to describe the operational practice of - relying on wildcards to generate answers. It is clear from this - that there is a need to define clear and unambiguous terminology - in the process of discussing wildcards. - - The mention of the use of wildcards in the preparation of a - response is contained in step 3c of RFC 1034's section 4.3.2 - entitled "Algorithm." Note that "wildcard" does not appear in - the algorithm, instead references are made to the "*" label. - The portion of the algorithm relating to wildcards is - deconstructed in detail in section 3 of this document, this is - the beginning of the relevant portion of the "Algorithm." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - The scope of this document is the RFC 1034 definition of - wildcards and the implications of updates to those documents, - such as DNSSEC. Alternate schemes for synthesizing answers are - not considered. (Note that there is no reference listed. No - document is known to describe any alternate schemes, although - there has been some mention of them in mailing lists.) - -1.3 Roadmap to This Document - - This document accomplishes these three items. - o Defines new terms - o Makes minor changes to avoid conflicting concepts - o Describes the actions of certain resource records as wildcards - -1.3.1 New Terms - - To help in discussing what resource records are wildcards, two - terms will be defined - "asterisk label" and "wild card domain - name". These are defined in section 2.1.1. - - To assist in clarifying the role of wildcards in the name server - algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest - encloser" are defined. These definitions are in section 3.3.2. - "Label match" is defined in section 3.2. - -DNSEXT Working Group Expires July 9, 2006 [Page 4] - -Internet-Draft dnsext-wcard January 9, 2006 - - The new terms are used to make discussions of wildcards clearer. - Terminology doesn't directly have an impact on implementations. - -1.3.2 Changed Text - - The definition of "existence" is changed superficially. This - change will not be apparent to implementations; it is needed to - make descriptions more precise. The change appears in section - 2.2.3. - - RFC 1034, section 4.3.3., seems to prohibit having two asterisk - labels in a wildcard owner name. With this document the - restriction is removed entirely. This change and its implications - are in section 2.1.3. - - The actions when a source of synthesis owns a CNAME RR are - changed to mirror the actions if an exact match name owns a - CNAME RR. This is an addition to the words in RFC 1034, - section 4.3.2, step 3, part c. The discussion of this is in - section 3.3.3. - - Only the latter change represents an impact to implementations. - The definition of existence is not a protocol impact. The change - to the restriction on names is unlikely to have an impact, as - RFC 1034 contained no specification on when and how to enforce the - restriction. - -1.3.3 Considerations with Special Types - - This document describes semantics of wildcard RRSets for - "interesting" types as well as empty non-terminal wildcards. - Understanding these situations in the context of wildcards has - been clouded because these types incur special processing if - they are the result of an exact match. This discussion is in - section 4. - - These discussions do not have an implementation impact, they cover - existing knowledge of the types, but to a greater level of detail. - -1.4 Standards Terminology - - This document does not use terms as defined in "Key words for use - in RFCs to Indicate Requirement Levels." [RFC2119] - - Quotations of RFC 1034 are denoted by a '#' in the leftmost - column. References to section "4.3.2" are assumed to refer - to RFC 1034's section 4.3.2, simply titled "Algorithm." - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 5] - -Internet-Draft dnsext-wcard January 9, 2006 - -2. Wildcard Syntax - - The syntax of a wildcard is the same as any other DNS resource - record, across all classes and types. The only significant - feature is the owner name. - - Because wildcards are encoded as resource records with special - names, they are included in zone transfers and incremental zone - transfers[RFC1995] just as non-wildcard resource records are. - This feature has been under appreciated until discussions on - alternative approaches to wildcards appeared on mailing lists. - -2.1 Identifying a Wildcard - - To provide a more accurate description of wildcards, the - definition has to start with a discussion of the domain names - that appear as owners. Two new terms are needed, "Asterisk - Label" and "Wild Card Domain Name." - -2.1.1 Wild Card Domain Name and Asterisk Label - - A "wild card domain name" is defined by having its initial - (i.e., left-most or least significant) label be, in binary format: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC20] - for the '*' character. - - A descriptive name of a label equaling that value is an "asterisk - label." - - RFC 1034's definition of wildcard would be "a resource record - owned by a wild card domain name." - -2.1.2 Asterisks and Other Characters - - No label values other than that in section 2.1.1 are asterisk - labels, hence names beginning with other labels are never wild - card domain names. Labels such as 'the*' and '**' are not - asterisk labels so these labels do not start wild card domain - names. - -2.1.3 Non-terminal Wild Card Domain Names - - In section 4.3.3, the following is stated: - -# .......................... The owner name of the wildcard RRs is of -# the form "*.", where is any domain name. -# should not contain other * labels...................... - -DNSEXT Working Group Expires July 9, 2006 [Page 6] - -Internet-Draft dnsext-wcard January 9, 2006 - - The restriction is now removed. The original documentation of it - is incomplete and the restriction does not serve any purpose - given years of operational experience. - - There are three possible reasons for putting the restriction in - place, but none of the three has held up over time. One is - that the restriction meant that there would never be subdomains - of wild card domain names, but the restriciton as stated still - permits "example.*.example." for instance. Another is that - wild card domain names are not intended to be empty non-terminals, - but this situation does not disrupt the algorithm in 4.3.2. - Finally, "nested" wild card domain names are not ambiguous once - the concept of the closest encloser had been documented. - - A wild card domain name can have subdomains. There is no need - to inspect the subdomains to see if there is another asterisk - label in any subdomain. - - A wild card domain name can be an empty non-terminal. (See the - upcoming sections on empty non-terminals.) In this case, any - lookup encountering it will terminate as would any empty - non-terminal match. - -2.2 Existence Rules - - The notion that a domain name 'exists' is mentioned in the - definition of wildcards. In section 4.3.3 of RFC 1034: - -# Wildcard RRs do not apply: -# -... -# - When the query name or a name between the wildcard domain and -# the query name is know[n] to exist. For example, if a wildcard - - "Existence" is therefore an important concept in the understanding - of wildcards. Unfortunately, the definition of what exists, in RFC - 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is - taken at the definition of existence. - -2.2.1 An Example - - To illustrate what is meant by existence consider this complete - zone: - - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 7] - -Internet-Draft dnsext-wcard January 9, 2006 - - $ORIGIN example. - example. 3600 IN SOA - example. 3600 NS ns.example.com. - example. 3600 NS ns.example.net. - *.example. 3600 TXT "this is a wild card" - *.example. 3600 MX 10 host1.example. - sub.*.example. 3600 TXT "this is not a wild card" - host1.example. 3600 A 192.0.4.1 - _ssh._tcp.host1.example. 3600 SRV - _ssh._tcp.host2.example. 3600 SRV - subdel.example. 3600 NS ns.example.com. - subdel.example. 3600 NS ns.example.net. - - A look at the domain names in a tree structure is helpful: - - | - -------------example------------ - / / \ \ - / / \ \ - / / \ \ - * host1 host2 subdel - | | | - | | | - sub _tcp _tcp - | | - | | - _ssh _ssh - - The following responses would be synthesized from one of the - wildcards in the zone: - - QNAME=host3.example. QTYPE=MX, QCLASS=IN - the answer will be a "host3.example. IN MX ..." - - QNAME=host3.example. QTYPE=A, QCLASS=IN - the answer will reflect "no error, but no data" - because there is no A RR set at '*.example.' - - QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN - the answer will be "foo.bar.example. IN TXT ..." - because bar.example. does not exist, but the wildcard - does. - - The following responses would not be synthesized from any of the - wildcards in the zone: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - - QNAME=sub.*.example., QTYPE=MX, QCLASS=IN - because sub.*.example. exists - -DNSEXT Working Group Expires July 9, 2006 [Page 8] - -Internet-Draft dnsext-wcard January 9, 2006 - - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists (and is a zone cut) - - QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN - because *.example. exists - - The final example highlights one common misconception about - wildcards. A wildcard "blocks itself" in the sense that a - wildcard does not match its own subdomains. I.e. "*.example." - does not match all names in the "example." zone, it fails to - match the names below "*.example." To cover names under - "*.example.", another wild card domain name is needed - - "*.*.example." - which covers all but it's own subdomains. - -2.2.2 Empty Non-terminals - - Empty non-terminals [RFC2136, Section 7.16] are domain names - that own no resource records but have subdomains that do. In - section 2.2.1, "_tcp.host1.example." is an example of a empty - non-terminal name. Empty non-terminals are introduced by this - text in section 3.1 of RFC 1034: - -# The domain name space is a tree structure. Each node and leaf on -# the tree corresponds to a resource set (which may be empty). The -# domain system makes no distinctions between the uses of the -# interior nodes and leaves, and this memo uses the term "node" to -# refer to both. - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized, and that empty non-terminals - "exist." - - Pedantically reading the above paragraph can lead to an - interpretation that all possible domains exist - up to the - suggested limit of 255 octets for a domain name [RFC1035]. - For example, www.example. may have an A RR, and as far as is - practically concerned, is a leaf of the domain tree. But the - definition can be taken to mean that sub.www.example. also - exists, albeit with no data. By extension, all possible domains - exist, from the root on down. - - As RFC 1034 also defines "an authoritative name error indicating - that the name does not exist" in section 4.3.1, so this apparently - is not the intent of the original definition, justifying the - need for an updated definition in the next section. - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 9] - -Internet-Draft dnsext-wcard January 9, 2006 - -2.2.3 Yet Another Definition of Existence - - RFC1034's wording is fixed by the following paragraph: - - The domain name space is a tree structure. Nodes in the tree - either own at least one RRSet and/or have descendants that - collectively own at least one RRSet. A node may exist with no - RRSets only if it has descendents that do, this node is an empty - non-terminal. - - A node with no descendants is a leaf node. Empty leaf nodes do - not exist. - - Note that at a zone boundary, the domain name owns data, - including the NS RR set. In the delegating zone, the NS RR - set is not authoritative, but that is of no consequence here. - The domain name owns data, therefore, it exists. - -2.3 When is a Wild Card Domain Name Not Special - - When a wild card domain name appears in a message's query section, - no special processing occurs. An asterisk label in a query name - only matches a single, corresponding asterisk label in the - existing zone tree when the 4.3.2 algorithm is being followed. - - When a wild card domain name appears in the resource data of a - record, no special processing occurs. An asterisk label in that - context literally means just an asterisk. - -3. Impact of a Wild Card Domain Name On a Response - - RFC 1034's description of how wildcards impact response - generation is in its section 4.3.2. That passage contains the - algorithm followed by a server in constructing a response. - Within that algorithm, step 3, part 'c' defines the behavior of - the wildcard. - - The algorithm in section 4.3.2. is not intended to be pseudo-code, - i.e., its steps are not intended to be followed in strict order. - The "algorithm" is a suggested means of implementing the - requirements. As such, in step 3, parts a, b, and c, do not have - to be implemented in that order, provided that the result of the - implemented code is compliant with the protocol's specification. - -3.1 Step 2 - - Step 2 of section 4.3.2 reads: - -# 2. Search the available zones for the zone which is the nearest -# ancestor to QNAME. If such a zone is found, go to step 3, -# otherwise step 4. - -DNSEXT Working Group Expires July 9, 2006 [Page 10] - -Internet-Draft dnsext-wcard January 9, 2006 - - In this step, the most appropriate zone for the response is - chosen. The significance of this step is that it means all of - step 3 is being performed within one zone. This has significance - when considering whether or not an SOA RR can be ever be used for - synthesis. - -3.2 Step 3 - - Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. - But the beginning of the step is important and needs explanation. - -# 3. Start matching down, label by label, in the zone. The -# matching process can terminate several ways: - - The word 'matching' refers to label matching. The concept - is based in the view of the zone as the tree of existing names. - The query name is considered to be an ordered sequence of - labels - as if the name were a path from the root to the owner - of the desired data. (Which it is - 3rd paragraph of RFC 1034, - section 3.1.) - - The process of label matching a query name ends in exactly one of - three choices, the parts 'a', 'b', and 'c'. Either the name is - found, the name is below a cut point, or the name is not found. - - Once one of the parts is chosen, the other parts are not - considered. (E.g., do not execute part 'c' and then change - the execution path to finish in part 'b'.) The process of label - matching is also done independent of the query type (QTYPE). - - Parts 'a' and 'b' are not an issue for this clarification as they - do not relate to record synthesis. Part 'a' is an exact match - that results in an answer, part 'b' is a referral. - -3.3 Part 'c' - - The context of part 'c' is that the process of label matching the - labels of the query name has resulted in a situation in which - there is no corresponding label in the tree. It is as if the - lookup has "fallen off the tree." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - To help describe the process of looking 'to see if [...] the "*" - label exists' a term has been coined to describe the last domain - (node) matched. The term is "closest encloser." - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 11] - -Internet-Draft dnsext-wcard January 9, 2006 - -3.3.1 Closest Encloser and the Source of Synthesis - - The closest encloser is the node in the zone's tree of existing - domain names that has the most labels matching the query name - (consecutively, counting from the root label downward). Each match - is a "label match" and the order of the labels is the same. - - The closest encloser is, by definition, an existing name in the - zone. The closest encloser might be an empty non-terminal or even - be a wild card domain name itself. In no circumstances is the - closest encloser to be used to synthesize records for the current - query. - - The source of synthesis is defined in the context of a query - process as that wild card domain name immediately descending - from the closest encloser, provided that this wild card domain - name exists. "Immediately descending" means that the source - of synthesis has a name of the form: - .. - A source of synthesis does not guarantee having a RRSet to use - for synthesis. The source of synthesis could be an empty - non-terminal. - - If the source of synthesis does not exist (not on the domain - tree), there will be no wildcard synthesis. There is no search - for an alternate. - - The important concept is that for any given lookup process, there - is at most one place at which wildcard synthetic records can be - obtained. If the source of synthesis does not exist, the lookup - terminates, the lookup does not look for other wildcard records. - -3.3.2 Closest Encloser and Source of Synthesis Examples - - To illustrate, using the example zone in section 2.2.1 of this - document, the following chart shows QNAMEs and the closest - enclosers. - - QNAME Closest Encloser Source of Synthesis - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no source - _telnet._tcp.host2.example. host2.example. no source - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - foobar.*.example. *.example. no source - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 12] - -Internet-Draft dnsext-wcard January 9, 2006 - -3.3.3 Type Matching - - RFC 1034 concludes part 'c' with this: - -# If the "*" label does not exist, check whether the name -# we are looking for is the original QNAME in the query -# or a name we have followed due to a CNAME. If the name -# is original, set an authoritative name error in the -# response and exit. Otherwise just exit. -# -# If the "*" label does exist, match RRs at that node -# against QTYPE. If any match, copy them into the answer -# section, but set the owner of the RR to be QNAME, and -# not the node with the "*" label. Go to step 6. - - The final paragraph covers the role of the QTYPE in the lookup - process. - - Based on implementation feedback and similarities between step - 'a' and step 'c' a change to this passage has been made. - - The change is to add the following text to step 'c' prior to the - instructions to "go to step 6": - - If the data at the source of synthesis is a CNAME, and - QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response changing the owner name - to the QNAME, change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - This is essentially the same text in step a covering the - processing of CNAME RRSets. - -4. Considerations with Special Types - - Sections 2 and 3 of this document discuss wildcard synthesis - with respect to names in the domain tree and ignore the impact - of types. In this section, the implication of wildcards of - specific types are discussed. The types covered are those - that have proven to be the most difficult to understand. The - types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and - "none," i.e., empty non-terminal wild card domain names. - -4.1 SOA RRSet at a Wild Card Domain Name - - A wild card domain name owning an SOA RRSet means that the - domain is at the root of the zone (apex). The domain can not - be a source of synthesis because that is, by definition, a - descendent node (of the closest encloser) and a zone apex is - at the top of the zone. - - -DNSEXT Working Group Expires July 9, 2006 [Page 13] - -Internet-Draft dnsext-wcard January 9, 2006 - - Although a wild card domain name owning an SOA RRSet can never - be a source of synthesis, there is no reason to forbid the - ownership of an SOA RRSet. - - E.g., given this zone: - $ORIGIN *.example. - @ 3600 IN SOA - 3600 NS ns1.example.com. - 3600 NS ns1.example.net. - www 3600 TXT "the www txt record" - - A query for www.*.example.'s TXT record would still find the - "the www txt record" answer. The asterisk label only becomes - significant when section 4.3.2, step 3 part 'c' is in effect. - - Of course, there would need to be a delegation in the parent - zone, "example." for this to work too. This is covered in the - next section. - -4.2 NS RRSet at a Wild Card Domain Name - - With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now - in place, the semantics of a wild card domain name owning an - NS RRSet has come to be poorly defined. The dilemma relates to - a conflict between the rules for synthesis in part 'c' and the - fact that the resulting synthesis generates a record for which - the zone is not authoritative. In a DNSSEC signed zone, the - mechanics of signature management (generation and inclusion - in a message) have become unclear. - - Salient points of the working group discussion on this topic is - summarized in section 4.2.1. - - As a result of these discussion, there is no definition given for - wild card domain names owning an NS RRSet. The semantics are - left undefined until there is a clear need to have a set defined, - and until there is a clear direction to proceed. Operationally, - inclusion of wild card NS RRSets in a zone is discouraged, but - not barred. - -4.2.1 Discarded Notions - - Prior to DNSSEC, a wild card domain name owning a NS RRSet - appeared to be workable, and there are some instances in which - it is found in deployments using implementations that support - this. Continuing to allow this in the specification is not - tenable with DNSSEC. The reason is that the synthesis of the - NS RRSet is being done in a zone that has delegated away the - responsibility for the name. This "unauthorized" synthesis is - not a problem for the base DNS protocol, but DNSSEC, in affirming - the authorization model for DNS exposes the problem. - -DNSEXT Working Group Expires July 9, 2006 [Page 14] - -Internet-Draft dnsext-wcard January 9, 2006 - - Outright banning of wildcards of type NS is also untenable as - the DNS protocol does not define how to handle "illegal" data. - Implementations may choose not to load a zone, but there is no - protocol definition. The lack of the definition is complicated - by having to cover dynamic update [RFC 2136], zone transfers, - as well as loading at the master server. The case of a client - (resolver, caching server) getting a wildcard of type NS in - a reply would also have to be considered. - - Given the daunting challenge of a complete definition of how to - ban such records, dealing with existing implementations that - permit the records today is a further complication. There are - uses of wild card domain name owning NS RRSets. - - One compromise proposed would have redefined wildcards of type - NS to not be used in synthesis, this compromise fell apart - because it would have required significant edits to the DNSSEC - signing and validation work. (Again, DNSSEC catches - unauthorized data.) - - With no clear consensus forming on the solution to this dilemma, - and the realization that wildcards of type NS are a rarity in - operations, the best course of action is to leave this open-ended - until "it matters." - -4.3 CNAME RRSet at a Wild Card Domain Name - - The issue of a CNAME RRSet owned by a wild card domain name has - prompted a suggested change to the last paragraph of step 3c of - the algorithm in 4.3.2. The changed text appears in section - 3.3.3 of this document. - -4.4 DNAME RRSet at a Wild Card Domain Name - - Ownership of a DNAME [RFC2672] RRSet by a wild card domain name - represents a threat to the coherency of the DNS and is to be - avoided or outright rejected. Such a DNAME RRSet represents - non-deterministic synthesis of rules fed to different caches. - As caches are fed the different rules (in an unpredictable - manner) the caches will cease to be coherent. ("As caches - are fed" refers to the storage in a cache of records obtained - in responses by recursive or iterative servers.) - - For example, assume one cache, responding to a recursive - request, obtains the record: - "a.b.example. DNAME foo.bar.example.net." - and another cache obtains: - "b.example. DNAME foo.bar.example.net." - both generated from the record: - "*.example. DNAME foo.bar.example.net." - by an authoritative server. - -DNSEXT Working Group Expires July 9, 2006 [Page 15] - -Internet-Draft dnsext-wcard January 9, 2006 - - The DNAME specification is not clear on whether DNAME records - in a cache are used to rewrite queries. In some interpretations, - the rewrite occurs, in some, it is not. Allowing for the - occurrence of rewriting, queries for "sub.a.b.example. A" may - be rewritten as "sub.foo.bar.tld. A" by the former caching - server and may be rewritten as "sub.a.foo.bar.tld. A" by the - latter. Coherency is lost, an operational nightmare ensues. - - Another justification for banning or avoiding wildcard DNAME - records is the observation that such a record could synthesize - a DNAME owned by "sub.foo.bar.example." and "foo.bar.example." - There is a restriction in the DNAME definition that no domain - exist below a DNAME-owning domain, hence, the wildcard DNAME - is not to be permitted. - -4.5 SRV RRSet at a Wild Card Domain Name - - The definition of the SRV RRset is RFC 2782 [RFC2782]. In the - definition of the record, there is some confusion over the term - "Name." The definition reads as follows: - -# The format of the SRV RR -... -# _Service._Proto.Name TTL Class SRV Priority Weight Port Target -... -# Name -# The domain this RR refers to. The SRV RR is unique in that the -# name one searches for is not this name; the example near the end -# shows this clearly. - - Do not confuse the definition "Name" with the owner name. I.e., - once removing the _Service and _Proto labels from the owner name - of the SRV RRSet, what remains could be a wild card domain name - but this is immaterial to the SRV RRSet. - - E.g., If an SRV record is: - _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. - - *.example is a wild card domain name and although it is the Name - of the SRV RR, it is not the owner (domain name). The owner - domain name is "_foo._udp.*.example." which is not a wild card - domain name. - - The confusion is likely based on the mixture of the specification - of the SRV RR and the description of a "use case." - -4.6 DS RRSet at a Wild Card Domain Name - - A DS RRSet owned by a wild card domain name is meaningless and - harmless. This statement is made in the context that an NS RRSet - at a wild card domain name is undefined. At a non-delegation - -DNSEXT Working Group Expires July 9, 2006 [Page 16] - -Internet-Draft dnsext-wcard January 9, 2006 - - point, a DS RRSet has no value (no corresponding DNSKEY RRSet - will be used in DNSSEC validation). If there is a synthesized - DS RRSet, it alone will not be very useful as it exists in the - context of a delegation point. - -4.7 NSEC RRSet at a Wild Card Domain Name - - Wild card domain names in DNSSEC signed zones will have an NSEC - RRSet. Synthesis of these records will only occur when the - query exactly matches the record. Synthesized NSEC RR's will not - be harmful as they will never be used in negative caching or to - generate a negative response. [RFC2308] - -4.8 RRSIG at a Wild Card Domain Name - - RRSIG records will be present at a wild card domain name in a - signed zone, and will be synthesized along with data sought in a - query. The fact that the owner name is synthesized is not a - problem as the label count in the RRSIG will instruct the - verifying code to ignore it. - -4.9 Empty Non-terminal Wild Card Domain Name - - If a source of synthesis is an empty non-terminal, then the - response will be one of no error in the return code and no RRSet - in the answer section. - -5. Security Considerations - - This document is refining the specifications to make it more - likely that security can be added to DNS. No functional - additions are being made, just refining what is considered - proper to allow the DNS, security of the DNS, and extending - the DNS to be more predictable. - -6. IANA Considerations - - None. - -7. References - - Normative References - - [RFC20] ASCII Format for Network Interchange, V.G. Cerf, - Oct-16-1969 - - [RFC1034] Domain Names - Concepts and Facilities, - P.V. Mockapetris, Nov-01-1987 - - [RFC1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - -DNSEXT Working Group Expires July 9, 2006 [Page 17] - -Internet-Draft dnsext-wcard January 9, 2006 - - [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 - - [RFC2119] Key Words for Use in RFCs to Indicate Requirement - Levels, S Bradner, March 1997 - - [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), - M. Andrews, March 1998 - - [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, - August 1999. - - [RFC2782] A DNS RR for specifying the location of services (DNS - SRV), A. Gulbrandsen, et.al., February 2000 - - [RFC4033] DNS Security Introduction and Requirements, R. Arends, - et.al., March 2005 - - [RFC4034] Resource Records for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - [RFC4035] Protocol Modifications for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - Informative References - - [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - April 1997 - -8. Editor - - Name: Edward Lewis - Affiliation: NeuStar - Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US - Phone: +1-571-434-5468 - Email: ed.lewis@neustar.biz - - Comments on this document can be sent to the editor or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - -9. Others Contributing to the Document - - This document represents the work of a large working group. The - editor merely recorded the collective wisdom of the working group. - - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 17] - -Internet-Draft dnsext-wcard January 9, 2006 - -10. Trailing Boilerplate - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided - on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION - HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET - SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL - WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO - ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT - INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of - any Intellectual Property Rights or other rights that might - be claimed to pertain to the implementation or use of the - technology described in this document or the extent to which - any license under such rights might or might not be available; - nor does it represent that it has made any independent effort - to identify any such rights. Information on the procedures - with respect to rights in RFC documents can be found in BCP 78 - and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the - use of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR - repository at http://www.ietf.org/ipr. The IETF invites any - interested party to bring to its attention any copyrights, - patents or patent applications, or other proprietary rights - that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - -Expiration - - This document expires on or about July 9, 2006. - - - -DNSEXT Working Group Expires July 9, 2006 [Page 19] diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt deleted file mode 100644 index bf2afcdfb3..0000000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt +++ /dev/null @@ -1,1848 +0,0 @@ - - - -DNS Operations WG J. Jeong, Ed. -Internet-Draft ETRI/University of Minnesota -Expires: November 6, 2005 May 5, 2005 - - - IPv6 Host Configuration of DNS Server Information Approaches - draft-ietf-dnsop-ipv6-dns-configuration-06.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 6, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes three approaches for IPv6 recursive DNS - server address configuration. It details the operational attributes - of three solutions: RA option, DHCPv6 option, and Well-known anycast - addresses for recursive DNS servers. Additionally, it suggests the - deployment scenarios in four kinds of networks, such as ISP, - Enterprise, 3GPP, and Unmanaged networks, considering multi-solution - resolution. Therefore, this document will give the audience a - - - -Jeong Expires November 6, 2005 [Page 1] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - guideline for IPv6 host DNS configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 2] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. IPv6 DNS Configuration Approaches . . . . . . . . . . . . . . 7 - 3.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 8 - 3.1.3 Observations . . . . . . . . . . . . . . . . . . . . . 9 - 3.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 11 - 3.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 12 - 3.2.3 Observations . . . . . . . . . . . . . . . . . . . . . 12 - 3.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 12 - 3.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 13 - 3.3.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 14 - 3.3.3 Observations . . . . . . . . . . . . . . . . . . . . . 14 - 4. Interworking among IPv6 DNS Configuration Approaches . . . . . 15 - 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16 - 5.1 ISP Network . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.1.1 RA Option Approach . . . . . . . . . . . . . . . . . . 16 - 5.1.2 DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17 - 5.1.3 Well-known Anycast Addresses Approach . . . . . . . . 17 - 5.2 Enterprise Network . . . . . . . . . . . . . . . . . . . . 17 - 5.3 3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.3.1 Currently Available Mechanisms and Recommendations . . 19 - 5.3.2 RA Extension . . . . . . . . . . . . . . . . . . . . . 19 - 5.3.3 Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20 - 5.3.4 Well-known Addresses . . . . . . . . . . . . . . . . . 21 - 5.3.5 Recommendations . . . . . . . . . . . . . . . . . . . 21 - 5.4 Unmanaged Network . . . . . . . . . . . . . . . . . . . . 22 - 5.4.1 Case A: Gateway does not provide IPv6 at all . . . . . 22 - 5.4.2 Case B: A dual-stack gateway connected to a - dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22 - 5.4.3 Case C: A dual-stack gateway connected to an - IPv4-only ISP . . . . . . . . . . . . . . . . . . . . 22 - 5.4.4 Case D: A gateway connected to an IPv6-only ISP . . . 23 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 6.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 25 - 6.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 25 - 6.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 25 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29 - 9.2 Informative References . . . . . . . . . . . . . . . . . . 29 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 - A. Link-layer Multicast Acknowledgements for RA Option . . . . . 32 - - - -Jeong Expires November 6, 2005 [Page 3] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - Intellectual Property and Copyright Statements . . . . . . . . 33 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 4] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -1. Introduction - - Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address - Autoconfiguration provide the ways to configure either fixed or - mobile nodes with one or more IPv6 addresses, default routes and some - other parameters [3][4]. To support the access to additional - services in the Internet that are identified by a DNS name, such as a - web server, the configuration of at least one recursive DNS server is - also needed for DNS name resolution. - - This document describes three approaches of recursive DNS server - address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 - option [5]-[7], and (c) Well-known anycast addresses for recursive - DNS servers [9]. Also, it suggests the applicable scenarios for four - kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP - network, and (d) Unmanaged network. - - This document is just an analysis of each possible approach, and does - not make any recommendation on a particular one or on a combination - of particular ones. Some approaches may even not be adopted at all - as a result of further discussion. - - Therefore, the objective of this document is to help the audience - select the approaches suitable for IPv6 host configuration of - recursive DNS servers. - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 5] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -2. Terminology - - This document uses the terminology described in [3]-[9]. In - addition, a new term is defined below: - - o Recursive DNS Server (RDNSS): A Recursive DNS Server is a name - server that offers the recursive service of DNS name resolution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 6] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -3. IPv6 DNS Configuration Approaches - - In this section, the operational attributes of the three solutions - are described in detail. - -3.1 RA Option - - The RA approach is to define a new ND option called the RDNSS option - that contains a recursive DNS server address. Existing ND transport - mechanisms (i.e., advertisements and solicitations) are used. This - works in the same way that nodes learn about routers and prefixes. - An IPv6 host can configure the IPv6 addresses of one or more RDNSSes - via RA message periodically sent by a router or solicited by a Router - Solicitation (RS) [8]. - - This approach needs RDNSS information to be configured in the routers - doing the advertisements. The configuration of RDNSS addresses can - be performed manually by an operator or other ways, such as automatic - configuration through a DHCPv6 client running on the router. When - advertising more than one RDNSS option, an RA message includes as - many RDNSS options as RDNSSes. - - Through the ND protocol and RDNSS option along with a prefix - information option, an IPv6 host can perform its network - configuration of its IPv6 address and RDNSS simultaneously [3][4]. - The RA option for RDNSS can be used on any network that supports the - use of ND. - - However, it is worth noting that some link layers, such as Wireless - LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast, - which means that they cannot guarantee the timely delivery of RA - messages [25]-[28]. This is discussed in Appendix A. - - The RA approach is useful in some mobile environments where the - addresses of the RDNSSes are changing because the RA option includes - a lifetime field that allows client to use RDNSSes nearer to the - client. This can be configured to a value that will require the - client to time out the entry and switch over to another RDNSS address - [8]. However, from the viewpoint of implementation, the lifetime - field would seem to make matters a bit more complex. Instead of just - writing to a DNS configuration file, such as resolv.conf for the list - of RDNSS addresses, we have to have a daemon around (or a program - that is called at the defined intervals) that keeps monitoring the - lifetime of RDNSSes all the time. - - The preference value of RDNSS, included in the RDNSS option, allows - IPv6 hosts to select primary RDNSS among several RDNSSes; this can be - used for the load balancing of RDNSSes [8]. - - - -Jeong Expires November 6, 2005 [Page 7] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -3.1.1 Advantages - - The RA option for RDNSS has a number of advantages. These include: - - 1. The RA option is an extension of existing ND/Autoconfig - mechanisms [3][4], and does not require a change in the base ND - protocol. - - 2. This approach, like ND, works well on a variety of link types - including point-to-point links, point-to-multipoint, and - multipoint-to-multipoint (i.e., Ethernet LANs), etc. RFC 2461 - [3] states, however, that there may be some link types on which - ND is not feasible; on such links, some other mechanisms will be - needed for DNS configuration. - - 3. All of the information a host needs to run the basic Internet - applications such as the email, web, ftp, etc., can be obtained - with the addition of this option to ND and address - autoconfiguration. The use of a single mechanism is more - reliable and easier to provide than when the RDNSS information is - learned via another protocol mechanism. Debugging problems when - multiple protocol mechanisms are being used is harder and much - more complex. - - 4. This mechanism works over a broad range of scenarios and - leverages IPv6 ND. This works well on links that support - broadcast reliably (e.g., Ethernet LANs) but not necessarily on - other links (e.g., Wireless LANs): Refer to Appendix A. Also, - this works well on links that are high performance (e.g., - Ethernet LANs) and low performance (e.g., Cellular networks). In - the latter case, by combining the RDNSS information with the - other information in the RA, the host can learn all of the - information needed to use most Internet applications, such as the - web in a single packet. This not only saves bandwidth where this - is an issue, but also minimizes the delay needed to learn the - RDNSS information. - - 5. The RA approach could be used as a model for other similar types - of configuration information. New RA options for other server - addresses, such as NTP server address, that are common to all - clients on a subnet would be easy to define. - - -3.1.2 Disadvantages - - 1. ND is mostly implemented in the kernel of operating system. - Therefore, if ND supports the configuration of some additional - services, such as DNS servers, ND should be extended in the - - - -Jeong Expires November 6, 2005 [Page 8] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - kernel, and complemented by a user-land process. DHCPv6, - however, has more flexibility for the extension of service - discovery because it is an application layer protocol. - - 2. The current ND framework should be modified to facilitate the - synchronization between another ND cache for RDNSSes in the - kernel space and the DNS configuration file in the user space. - Because it is unacceptable to write and rewrite to the DNS - configuration file (e.g., resolv.conf) from the kernel, another - approach is needed. One simple approach to solve this is to have - a daemon listening to what the kernel conveys, and to have the - daemon do these steps, but such a daemon is not needed with the - current ND framework. - - 3. It is necessary to configure RDNSS addresses at least at one - router on every link where this information needs to be - configured via the RA option. - - -3.1.3 Observations - - The proposed RDNSS RA option along with the IPv6 ND and - Autoconfiguration allows a host to obtain all of the information it - needs to access the basic Internet services like the web, email, ftp, - etc. This is preferable in the environments where hosts use RAs to - autoconfigure their addresses and all the hosts on the subnet share - the same router and server addresses. If the configuration - information can be obtained from a single mechanism, it is preferable - because it does not add additional delay, and it uses a minimum of - bandwidth. The environments like this include the homes, public - cellular networks, and enterprise environments where no per host - configuration is needed, but exclude public WLAN hot spots. - - DHCPv6 is preferable where it is being used for address configuration - and if there is a need for host specific configuration [5]-[7]. The - environments like this are most likely to be the enterprise - environments where the local administration chooses to have per host - configuration control. - -Note - - The observation section is based on what the proponents of each - approach think makes a good overall solution. - -3.2 DHCPv6 Option - - DHCPv6 [5] includes the "DNS Recursive Name Server" option, through - which a host can obtain a list of IP addresses of recursive DNS - - - -Jeong Expires November 6, 2005 [Page 9] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - servers [7]. The DNS Recursive Name Server option carries a list of - IPv6 addresses of RDNSSes to which the host may send DNS queries. - The DNS servers are listed in the order of preference for use by the - DNS resolver on the host. - - The DNS Recursive Name Server option can be carried in any DHCPv6 - Reply message, in response to either a Request or an Information - request message. Thus, the DNS Recursive Name Server option can be - used either when DHCPv6 is used for address assignment, or when - DHCPv6 is used only for other configuration information as stateless - DHCPv6 [6]. - - Stateless DHCPv6 can be deployed either using DHCPv6 servers running - on general-purpose computers, or on router hardware. Several router - vendors currently implement stateless DHCPv6 servers. Deploying - stateless DHCPv6 in routers has the advantage that no special - hardware is required, and should work well for networks where DHCPv6 - is needed for very straightforward configuration of network devices. - - However, routers can also act as DHCPv6 relay agents. In this case, - the DHCPv6 server need not be on the router - it can be on a general - purpose computer. This has the potential to give the operator of the - DHCPv6 server more flexibility in how the DHCPv6 server responds to - individual clients - clients can easily be given different - configuration information based on their identity, or for any other - reason. Nothing precludes adding this flexibility to a router, but - generally in current practice, DHCP servers running on general- - purpose hosts tend to have more configuration options than those that - are embedded in routers. - - DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 - clients that use a stateful configuration assignment. To do this, - the DHCPv6 server sends a Reconfigure message to the client. The - client validates the Reconfigure message, and then contacts the - DHCPv6 server to obtain updated configuration information. Using - this mechanism, it is currently possible to propagate new - configuration information to DHCPv6 clients as this information - changes. - - The DHC Working Group is currently studying an additional mechanism - through which configuration information, including the list of - RDNSSes, can be updated. The lifetime option for DHCPv6 [10] assigns - a lifetime to configuration information obtained through DHCPv6. At - the expiration of the lifetime, the host contacts the DHCPv6 server - to obtain updated configuration information, including the list of - RDNSSes. This lifetime gives the network administrator another - mechanism to configure hosts with new RDNSSes by controlling the time - at which the host refreshes the list. - - - -Jeong Expires November 6, 2005 [Page 10] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - The DHC Working Group has also discussed the possibility of defining - an extension to DHCPv6 that would allow the use of multicast to - provide configuration information to multiple hosts with a single - DHCPv6 message. Because of the lack of deployment experience, the WG - has deferred consideration of multicast DHCPv6 configuration at this - time. Experience with DHCPv4 has not identified a requirement for - multicast message delivery, even in large service provider networks - with tens of thousands of hosts that may initiate a DHCPv4 message - exchange simultaneously. - -3.2.1 Advantages - - The DHCPv6 option for RDNSS has a number of advantages. These - include: - - 1. DHCPv6 currently provides a general mechanism for conveying - network configuration information to clients. So configuring - DHCPv6 servers allows the network administrator to configure - RDNSSes along with the addresses of other network services, as - well as location-specific information like time zones. - - 2. As a consequence, when the network administrator goes to - configure DHCPv6, all the configuration information can be - managed through a single service, typically with a single user - interface and a single configuration database. - - 3. DHCPv6 allows for the configuration of a host with information - specific to that host, so that hosts on the same link can be - configured with different RDNSSes as well as with other - configuration information. This capability is important in some - network deployments such as service provider networks or WiFi hot - spots. - - 4. A mechanism exists for extending DHCPv6 to support the - transmission of additional configuration that has not yet been - anticipated. - - 5. Hosts that require other configuration information such as the - addresses of SIP servers and NTP servers are likely to need - DHCPv6 for other configuration information. - - 6. The specification for configuration of RDNSSes through DHCPv6 is - available as an RFC. No new protocol extensions such as new - options are necessary. - - 7. Interoperability among independent implementations has been - demonstrated. - - - - -Jeong Expires November 6, 2005 [Page 11] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -3.2.2 Disadvantages - - The DHCPv6 option for RDNSS has a few disadvantages. These include: - - 1. Update currently requires message from server (however, see - [10]). - - 2. Because DNS information is not contained in RA messages, the host - must receive two messages from the router, and must transmit at - least one message to the router. On networks where bandwidth is - at a premium, this is a disadvantage, although on most networks - it is not a practical concern. - - 3. Increased latency for initial configuration - in addition to - waiting for an RA message, the client must now exchange packets - with a DHCPv6 server; even if it is locally installed on a - router, this will slightly extend the time required to configure - the client. For clients that are moving rapidly from one network - to another, this will be a disadvantage. - - -3.2.3 Observations - - In the general case, on general-purpose networks, stateless DHCPv6 - provides significant advantages and no significant disadvantages. - Even in the case where bandwidth is at a premium and low latency is - desired, if hosts require other configuration information in addition - to a list of RDNSSes or if hosts must be configured selectively, - those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive - name server option will be advantageous. - - However, we are aware of some applications where it would be - preferable to put the RDNSS information into an RA packet; for - example, on a cell phone network, where bandwidth is at a premium and - extremely low latency is desired. The final DNS configuration draft - should be written so as to allow these special applications to be - handled using DNS information in the RA packet. - -3.3 Well-known Anycast Addresses - - Anycast uses the same routing system as unicast [11]. However, - administrative entities are local ones. The local entities may - accept unicast routes (including default routes) to anycast servers - from adjacent entities. The administrative entities should not - advertise their peers routes to their internal anycast servers, if - they want to prohibit external access from some peers to the servers. - If some advertisement is inevitable (such as the case with default - routes), the packets to the servers should be blocked at the boundary - - - -Jeong Expires November 6, 2005 [Page 12] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - of the entities. Thus, for this anycast, not only unicast routing - but also unicast ND protocols can be used as is. - - First of all, the well-known anycast addresses approach is much - different from that discussed at IPv6 Working Group in the past [9]. - It should be noted that "anycast" in this memo is simpler than that - of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be - prohibited to have multiple servers on a single link sharing an - anycast address. That is, on a link, an anycast address is assumed - to be unique. DNS clients today already have redundancy by having - multiple well-known anycast addresses configured as RDNSS addresses. - There is no point in having multiple RDNSSes sharing an anycast - address on a single link. - - The approach with well-known anycast addresses is to set multiple - well-known anycast addresses in clients' resolver configuration files - from the beginning, say, as factory default. Thus, there is no - transport mechanism and no packet format [9]. - - An anycast address is an address shared by multiple servers (in this - case, the servers are RDNSSes). A request from a client to the - anycast address is routed to a server selected by the routing system. - However, it is a bad idea to mandate "site" boundary on anycast - addresses, because most users just do not have their own servers and - want to access their ISPs' across their site boundaries. Larger - sites may also depend on their ISPs or may have their own RDNSSes - within "site" boundaries. - -3.3.1 Advantages - - The basic advantage of the well-known addresses approach is that it - uses no transport mechanism. Thus, - - 1. There is no delay to get the response and no further delay by - packet losses. - - 2. The approach can be combined with any other configuration - mechanisms, such as the RA-based approach and DHCP based - approach, as well as the factory default configuration. - - 3. The approach works over any environment where DNS works. - - Another advantage is that the approach needs to configure DNS servers - as a router, but nothing else. Considering that DNS servers do need - configuration, the amount of overall configuration effort is - proportional to the number of the DNS servers and scales linearly. - It should be noted that, in the simplest case where a subscriber to - an ISP does not have any DNS server, the subscriber naturally - - - -Jeong Expires November 6, 2005 [Page 13] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - accesses DNS servers of the ISP even though the subscriber and the - ISP do nothing and there is no protocol to exchange DNS server - information between the subscriber and the ISP. - -3.3.2 Disadvantages - - Well-known anycast addresses approach requires that DNS servers (or - routers near it as a proxy) act as routers to advertise their anycast - addresses to the routing system, which requires some configuration - (see the last paragraph of the previous section on the scalability of - the effort). - -3.3.3 Observations - - If other approaches are used in addition, the well-known anycast - addresses should also be set in RA or DHCP configuration files to - reduce the configuration effort of users. - - The redundancy by multiple RDNSSes is better provided by multiple - servers having different anycast addresses than multiple servers - sharing the same anycast address because the former approach allows - stale servers to still generate routes to their anycast addresses. - Thus, in a routing domain (or domains sharing DNS servers), there - will be only one server having an anycast address unless the domain - is so large that load distribution is necessary. - - Small ISPs will operate one RDNSS at each anycast address which is - shared by all the subscribers. Large ISPs may operate multiple - RDNSSes at each anycast address to distribute and reduce load, where - the boundary between RDNSSes may be fixed (redundancy is still - provided by multiple addresses) or change dynamically. DNS packets - with the well-known anycast addresses are not expected (though not - prohibited) to cross ISP boundaries, as ISPs are expected to be able - to take care of themselves. - - Because "anycast" in this memo is simpler than that of RFC 1546 [11] - and RFC 3513 [12] where it is assumed to be administratively - prohibited to have multiple servers on a single link sharing an - anycast address, anycast in this memo should be implemented as - UNICAST of RFC 2461 [3] and RFC 3513 [12]. As a result, ND-related - instability disappears. Thus, anycast in well-known anycast - addresses approach can and should use the anycast address as a source - unicast (according to RFC 3513 [12]) address of packets of UDP and - TCP responses. With TCP, if a route flips and packets to an anycast - address are routed to a new server, it is expected that the flip is - detected by ICMP or sequence number inconsistency and the TCP - connection is reset and retried. - - - - -Jeong Expires November 6, 2005 [Page 14] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -4. Interworking among IPv6 DNS Configuration Approaches - - Three approaches can work together for IPv6 host configuration of - RDNSS. This section shows a consideration on how these approaches - can interwork each other. - - For ordering between RA and DHCP approaches, the O (Other stateful - configuration) flag in RA message can be used [8][32]. If no RDNSS - option is included, an IPv6 host may perform DNS configuration - through DHCPv6 [5]-[7] regardless of whether the O flag is set or - not. - - The well-known anycast addresses approach fully interworks with the - other approaches. That is, the other approaches can remove the - configuration effort on servers by using the well-known addresses as - the default configuration. Moreover, the clients preconfigured with - the well-known anycast addresses can be further configured to use - other approaches to override the well-known addresses, if the - configuration information from other approaches is available. - Otherwise, all the clients need to have the well-known anycast - addresses preconfigured. In order to use the anycast approach along - with two other approaches, there are three choices as follows: - - 1. The first choice is that well-known addresses are used as last - resort, when an IPv6 host cannot get RDNSS information through RA - and DHCP. The well-known anycast addresses have to be - preconfigured in all of IPv6 hosts' resolver configuration files. - - 2. The second is that an IPv6 host can configure well-known - addresses as the most preferable in its configuration file even - though either an RA option or DHCP option is available. - - 3. The last is that the well-known anycast addresses can be set in - RA or DHCP configuration to reduce the configuration effort of - users. According to either the RA or DHCP mechanism, the well- - known addresses can be obtained by an IPv6 host. Because this - approach is the most convenient for users, the last option is - recommended. - - -Note - - This section does not necessarily mean this document suggests - adopting all these three approaches and making them interwork in the - way described here. In fact, some approaches may even not be adopted - at all as a result of further discussion. - - - - - -Jeong Expires November 6, 2005 [Page 15] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -5. Deployment Scenarios - - Regarding the DNS configuration on the IPv6 host, several mechanisms - are being considered at the DNSOP Working Group such as RA option, - DHCPv6 option and well-known preconfigured anycast addresses as of - today, and this document is a final result from the long thread. In - this section, we suggest four applicable scenarios of three - approaches for IPv6 DNS configuration. - -Note - - In the applicable scenarios, authors do not implicitly push any - specific approaches into the restricted environments. No enforcement - is in each scenario and all mentioned scenarios are probable. The - main objective of this work is to provide a useful guideline for IPv6 - DNS configuration. - -5.1 ISP Network - - A characteristic of ISP network is that multiple Customer Premises - Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) - routers and each PE connects multiple CPE devices to the backbone - network infrastructure [13]. The CPEs may be hosts or routers. - - In the case where the CPE is a router, there is a customer network - that is connected to the ISP backbone through the CPE. Typically, - each customer network gets a different IPv6 prefix from an IPv6 PE - router, but the same RDNSS configuration will be distributed. - - This section discusses how the different approaches to distributing - DNS information are compared in an ISP network. - -5.1.1 RA Option Approach - - When the CPE is a host, the RA option for RDNSS can be used to allow - the CPE to get RDNSS information as well as /64 prefix information - for stateless address autoconfiguration at the same time when the - host is attached to a new subnet [8]. Because an IPv6 host must - receive at least one RA message for stateless address - autoconfiguration and router configuration, the host could receive - RDNSS configuration information in that RA without the overhead of an - additional message exchange. - - When the CPE is a router, the CPE may accept the RDNSS information - from the RA on the interface connected to the ISP, and copy that - information into the RAs advertised in the customer network. - - This approach is more valuable in the mobile host scenario, in which - - - -Jeong Expires November 6, 2005 [Page 16] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - the host must receive at least an RA message for detecting a new - network, than in other scenarios generally although administrator - should configure RDNSS information on the routers. Secure ND [14] - can provide extended security when using RA messages. - -5.1.2 DHCPv6 Option Approach - - DHCPv6 can be used for RDNSS configuration through the use of the DNS - option, and can provide other configuration information in the same - message with RDNSS configuration [5]-[7]. The DHCPv6 DNS option is - already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or - stateless DHCP [6] is nowhere as complex as a full DHCPv6 - implementation. DHCP is a client-server model protocol, so ISPs can - handle user identification on its network intentionally, and also - authenticated DHCP [15] can be used for secure message exchange. - - The expected model for deployment of IPv6 service by ISPs is to - assign a prefix to each customer, which will be used by the customer - gateway to assign a /64 prefix to each network in the customer's - network. Prefix delegation with DHCP (DHCPv6 PD) has already been - adopted by ISPs for automating the assignment of the customer prefix - to the customer gateway [17]. DNS configuration can be carried in - the same DHCPv6 message exchange used for DHCPv6 to efficiently - provide that information, along with any other configuration - information needed by the customer gateway or customer network. This - service model can be useful to Home or SOHO subscribers. The Home or - SOHO gateway, which is a customer gateway for ISP, can then pass that - RDNSS configuration information to the hosts in the customer network - through DHCP. - -5.1.3 Well-known Anycast Addresses Approach - - The well-known anycast addresses approach is also a feasible and - simple mechanism for ISP [9]. The use of well-known anycast - addresses avoids some of the security risks in rogue messages sent - through an external protocol like RA or DHCPv6. The configuration of - hosts for the use of well-known anycast addresses requires no - protocol or manual configuration, but the configuration of routing - for the anycast addresses requires intervention on the part of the - network administrator. Also, the number of special addresses would - be equal to the number of RDNSSes that could be made available to - subscribers. - -5.2 Enterprise Network - - Enterprise network is defined as a network that has multiple internal - links, one or more router connections, to one or more Providers and - is actively managed by a network operations entity [16]. An - - - -Jeong Expires November 6, 2005 [Page 17] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - enterprise network can get network prefixes from an ISP by either - manual configuration or prefix delegation [17]. In most cases, - because an enterprise network manages its own DNS domains, it - operates its own DNS servers for the domains. These DNS servers - within enterprise network process recursive DNS name resolution - requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the - enterprise network can be performed like in Section 4, in which three - approaches can be used together as follows: - - 1. An IPv6 host can decide which approach is or may be used in its - subnet with the O flag in RA message [8][32]. As the first - choice in Section 4, well-known anycast addresses can be used as - a last resort when RDNSS information cannot be obtained through - either an RA option or DHCP option. This case needs IPv6 hosts - to preconfigure the well-known anycast addresses in their DNS - configuration files. - - 2. When the enterprise prefers the well-known anycast approach to - others, IPv6 hosts should preconfigure the well-known anycast - addresses like in the first choice. - - 3. The last choice, a more convenient and transparent way, does not - need IPv6 hosts to preconfigure the well-known anycast addresses - because the addresses are delivered to IPv6 hosts via either the - RA option or DHCPv6 option as if they were unicast addresses. - This way is most recommended for the sake of user's convenience. - - -5.3 3GPP Network - - The IPv6 DNS configuration is a missing part of IPv6 - autoconfiguration and an important part of the basic IPv6 - functionality in the 3GPP User Equipment (UE). The higher level - description of the 3GPP architecture can be found in [18], and - transition to IPv6 in 3GPP networks is analyzed in [19] and [20]. - - In the 3GPP architecture, there is a dedicated link between the UE - and the GGSN called the Packet Data Protocol (PDP) Context. This - link is created through the PDP Context activation procedure [21]. - There is a separate PDP context type for IPv4 and IPv6 traffic. If a - 3GPP UE user is communicating using IPv6 (having an active IPv6 PDP - context), it cannot be assumed that (s)he has simultaneously an - active IPv4 PDP context, and DNS queries could be done using IPv4. A - 3GPP UE can thus be an IPv6 node, and it needs to somehow discover - the address of the RDNSS. Before IP-based services (e.g., web - browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses - need to be discovered in the 3GPP UE. - - - - -Jeong Expires November 6, 2005 [Page 18] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - Section 5.3.1 briefly summarizes currently available mechanisms in - 3GPP networks and recommendations. 5.3.2 analyzes the Router - Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 - mechanism, and 5.3.4 analyzes the Well-known addresses approach. - Section 5.3.5 finally summarizes the recommendations. - -5.3.1 Currently Available Mechanisms and Recommendations - - 3GPP has defined a mechanism, in which RDNSS addresses can be - received in the PDP context activation (a control plane mechanism). - That is called the Protocol Configuration Options Information Element - (PCO-IE) mechanism [22]. The RDNSS addresses can also be received - over the air (using text messages), or typed in manually in the UE. - Note that the two last mechanisms are not very well scalable. The UE - user most probably does not want to type IPv6 RDNSS addresses - manually in his/her UE. The use of well-known addresses is briefly - discussed in section 5.3.4. - - It is seen that the mechanisms above most probably are not sufficient - for the 3GPP environment. IPv6 is intended to operate in a zero- - configuration manner, no matter what the underlying network - infrastructure is. Typically, the RDNSS address is needed to make an - IPv6 node operational - and the DNS configuration should be as simple - as the address autoconfiguration mechanism. It must also be noted - that there will be additional IP interfaces in some near future 3GPP - UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such - as PCO-IE [22]) do not work for those IP interfaces. In other words, - a good IPv6 DNS configuration mechanism should also work in a multi- - access network environment. - - From a 3GPP point of view, the best IPv6 DNS configuration solution - is feasible for a very large number of IPv6-capable UEs (can be even - hundreds of millions in one operator's network), is automatic and - thus requires no user action. It is suggested to standardize a - lightweight, stateless mechanism that works in all network - environments. The solution could then be used for 3GPP, 3GPP2, WLAN - and other access network technologies. A light, stateless IPv6 DNS - configuration mechanism is thus not only needed in 3GPP networks, but - also 3GPP networks and UEs would certainly benefit from the new - mechanism. - -5.3.2 RA Extension - - Router Advertisement extension [8] is a lightweight IPv6 DNS - configuration mechanism that requires minor changes in the 3GPP UE - IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in - the 3GPP architecture) IPv6 stack. This solution can be specified in - the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs - - - -Jeong Expires November 6, 2005 [Page 19] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - and GGSNs - - In this solution, an IPv6-capable UE configures DNS information via - RA message sent by its default router (GGSN), i.e., RDNSS option for - recursive DNS server is included in the RA message. This solution is - easily scalable for a very large number of UEs. The operator can - configure the RDNSS addresses in the GGSN as a part of normal GGSN - configuration. The IPv6 RDNSS address is received in the Router - Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS - addresses can be avoided. - - If thinking about the cons, this mechanism still requires - standardization effort in the IETF, and the end nodes and routers - need to support this mechanism. The equipment software update - should, however, be pretty straightforward, and new IPv6 equipment - could support RA extension already from the beginning. - -5.3.3 Stateless DHCPv6 - - DHCPv6-based solution needs the implementation of Stateless DHCP [6] - and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the - operator's network. A possible configuration is such that the GGSN - works as a DHCP relay. - - Pros for Stateless DHCPv6-based solution are - - 1. Stateless DHCPv6 is a standardized mechanism. - - 2. DHCPv6 can be used for receiving other configuration information - than RDNSS addresses, e.g., SIP server addresses. - - 3. DHCPv6 works in different network environments. - - 4. When DHCPv6 service is deployed through a single, centralized - server, the RDNSS configuration information can be updated by the - network administrator at a single source. - - Some issues with DHCPv6 in 3GPP networks are listed below: - - 1. DHCPv6 requires an additional server in the network unless the - (Stateless) DHCPv6 functionality is integrated into a router - already existing, and that means one box more to be maintained. - - 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing - (3GPP Stateless Address Autoconfiguration is typically used), and - not automatically implemented in 3GPP IPv6 UEs. - - - - - -Jeong Expires November 6, 2005 [Page 20] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - 3. Scalability and reliability of DHCPv6 in very large 3GPP networks - (with tens or hundreds of millions of UEs) may be an issue, at - least the redundancy needs to be taken care of. However, if the - DHCPv6 service is integrated into the network elements, such as a - router operating system, scalability and reliability is - comparable with other DNS configuration approaches. - - 4. It is sub-optimal to utilize the radio resources in 3GPP networks - for DHCPv6 messages if there is a simpler alternative available. - - * The use of Stateless DHCPv6 adds one round trip delay to the - case in which the UE can start transmitting data right after - the Router Advertisement. - - 5. If the DNS information (suddenly) changes, Stateless DHCPv6 can - not automatically update the UE, see [23]. - - -5.3.4 Well-known Addresses - - Using well-known addresses is also a feasible and a light mechanism - for 3GPP UEs. Those well-known addresses can be preconfigured in the - UE software and the operator makes the corresponding configuration on - the network side. So this is a very easy mechanism for the UE, but - requires some configuration work in the network. When using well- - known addresses, UE forwards queries to any of the preconfigured - addresses. In the current proposal [9], IPv6 anycast addresses are - suggested. - -Note - - The IPv6 DNS configuration proposal based on the use of well-known - site-local addresses developed at the IPv6 Working Group was seen as - a feasible mechanism for 3GPP UEs, but opposition by some people in - the IETF and finally deprecating IPv6 site-local addresses made it - impossible to standardize it. Note that this mechanism is - implemented in some existing operating systems today (also in some - 3GPP UEs) as a last resort of IPv6 DNS configuration. - -5.3.5 Recommendations - - It is suggested that a lightweight, stateless DNS configuration - mechanism is specified as soon as possible. From a 3GPP UE and - network point of view, the Router Advertisement based mechanism looks - most promising. The sooner a light, stateless mechanism is - specified, the sooner we can get rid of using well-known site-local - addresses for IPv6 DNS configuration. - - - - -Jeong Expires November 6, 2005 [Page 21] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -5.4 Unmanaged Network - - There are 4 deployment scenarios of interest in unmanaged networks - [24]: - - 1. A gateway which does not provide IPv6 at all; - - 2. A dual-stack gateway connected to a dual-stack ISP; - - 3. A dual-stack gateway connected to an IPv4-only ISP; and - - 4. A gateway connected to an IPv6-only ISP. - - -5.4.1 Case A: Gateway does not provide IPv6 at all - - In this case, the gateway does not provide IPv6; the ISP may or may - not provide IPv6. Automatic or Configured tunnels are the - recommended transition mechanisms for this scenario. - - The case where dual-stack hosts behind an NAT, that need access to an - IPv6 RDNSS, cannot be entirely ruled out. The DNS configuration - mechanism has to work over the tunnel, and the underlying tunneling - mechanism could be implementing NAT traversal. The tunnel server - assumes the role of a relay (both for DHCP and Well-known anycast - addresses approaches). - - RA-based mechanism is relatively straightforward in its operation, - assuming the tunnel server is also the IPv6 router emitting RAs. - Well-known anycast addresses approach seems also simple in operation - across the tunnel, but the deployment model using Well-known anycast - addresses in a tunneled environment is unclear or not well - understood. - -5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP - - This is similar to a typical IPv4 home user scenario, where DNS - configuration parameters are obtained using DHCP. Except that - Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the - DHCP server is stateful (maintains the state for clients). - -5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP - - This is similar to Case B. If a gateway provides IPv6 connectivity by - managing tunnels, then it is also supposed to provide access to an - RDNSS. Like this, the tunnel for IPv6 connectivity originates from - the dual-stack gateway instead of the host. - - - - -Jeong Expires November 6, 2005 [Page 22] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -5.4.4 Case D: A gateway connected to an IPv6-only ISP - - This is similar to Case B. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 23] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -6. Security Considerations - - As security requirements depend solely on applications and are - different application by application, there can be no generic - requirement defined at IP or application layer for DNS. - - However, it should be noted that cryptographic security requires - configured secret information that full autoconfiguration and - cryptographic security are mutually exclusive. People insisting on - secure full autoconfiguration will get false security, false - autoconfiguration or both. - - In some deployment scenarios [19], where cryptographic security is - required for applications, the secret information for the - cryptographic security is preconfigured through which application - specific configuration data, including those for DNS, can be securely - configured. It should be noted that if applications requiring - cryptographic security depend on DNS, the applications also require - cryptographic security to DNS. Therefore, the full autoconfiguration - of DNS is not acceptable. - - However, with full autoconfiguration, weaker but still reasonable - security is being widely accepted and will continue to be acceptable. - That is, with full autoconfiguration, which means there is no - cryptographic security for the autoconfiguration, it is already - assumed that the local environment is secure enough that the - information from the local autoconfiguration server has acceptable - security even without cryptographic security. Thus, the - communication between the local DNS client and local DNS server has - acceptable security. - - In autoconfiguring recursive servers, DNSSEC may be overkill, because - DNSSEC [29] needs the configuration and reconfiguration of clients at - root key roll-over [30][31]. Even if additional keys for secure key - roll-over are added at the initial configuration, they are as - vulnerable as the original keys to some forms of attacks, such as - social hacking. Another problem of using DNSSEC and - autoconfiguration together is that DNSSEC requires secure time, which - means secure communication with autoconfigured time servers, which - requires configured secret information. Therefore, in order that the - autoconfiguration may be secure, it requires configured secret - information. - - If DNSSEC [29] is used and the signatures are verified on the client - host, the misconfiguration of a DNS server may be simply denial of - service. Also, if local routing environment is not reliable, clients - may be directed to a false resolver with the same IP address as the - true one. - - - -Jeong Expires November 6, 2005 [Page 24] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -6.1 RA Option - - The security of RA option for RDNSS is the same as the ND protocol - security [3][8]. The RA option does not add any new vulnerability. - - It should be noted that the vulnerability of ND is not worse and is a - subset of the attacks that any node attached to a LAN can do - independently of ND. A malicious node on a LAN can promiscuously - receive packets for any router's MAC address and send packets with - the router's MAC address as the source MAC address in the L2 header. - As a result, the L2 switches send packets addressed to the router to - the malicious node. Also, this attack can send redirects that tell - the hosts to send their traffic somewhere else. The malicious node - can send unsolicited RA or NA replies, answer RS or NS requests, etc. - All of this can be done independently of implementing ND. Therefore, - the RA option for RDNSS does not add to the vulnerability. - - Security issues regarding the ND protocol were discussed at IETF SEND - (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND - security has been published [14]. - -6.2 DHCPv6 Option - - The DNS Recursive Name Server option may be used by an intruder DHCP - server to cause DHCP clients to send DNS queries to an intruder DNS - recursive name server [7]. The results of these misdirected DNS - queries may be used to spoof DNS names. - - To avoid attacks through the DNS Recursive Name Server option, the - DHCP client SHOULD require DHCP authentication (see section - "Authentication of DHCP messages" in RFC 3315 [5]) before installing - a list of DNS recursive name servers obtained through authenticated - DHCP. - -6.3 Well-known Anycast Addresses - - Well-known anycast addresses does not require configuration security - since there is no protocol [9]. - - The DNS server with the preconfigured addresses are still reasonably - reliable, if local environment is reasonably secure, that is, there - is no active attackers receiving queries to the anycast addresses of - the servers and reply to them. - - - - - - - - -Jeong Expires November 6, 2005 [Page 25] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -7. Contributors - - Ralph Droms - Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxboro, MA 01719 - US - - Phone: +1 978 936 1674 - Email: rdroms@cisco.com - - - Robert M. Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - US - - Phone: +1 650 625 2004 - Email: bob.hinden@nokia.com - - - Ted Lemon - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94043 - US - - Email: Ted.Lemon@nominum.com - - - Masataka Ohta - Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku - Tokyo 152-8552 - Japan - - Phone: +81 3 5734 3299 - Fax: +81 3 5734 3299 - Email: mohta@necom830.hpcl.titech.ac.jp - - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics - 416 Maetan-3dong, Yeongtong-Gu - Suwon, Gyeonggi-Do 443-742 - Korea - - - - -Jeong Expires November 6, 2005 [Page 26] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - Phone: +82 31 200 4508 - Email: soohong.park@samsung.com - - - Suresh Satapati - Cisco Systems, Inc. - San Jose, CA 95134 - US - - Email: satapati@cisco.com - - - Juha Wiljakka - Nokia - Visiokatu 3 - FIN-33720, TAMPERE - Finland - - Phone: +358 7180 48372 - Email: juha.wiljakka@nokia.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 27] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -8. Acknowledgements - - This draft has greatly benefited from inputs by David Meyer, Rob - Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, - Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. - Also, Tony Bonanno proofread this draft. The authors appreciate - their contribution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 28] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -9. References - -9.1 Normative References - - [1] Bradner, S., "IETF Rights in Contributions", RFC 3667, - February 2004. - - [2] Bradner, S., "Intellectual Property Rights in IETF Technology", - RFC 3668, February 2004. - - [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery - for IP Version 6 (IPv6)", RFC 2461, December 1998. - - [4] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [5] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [6] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) - Service for IPv6", RFC 3736, April 2004. - - [7] Droms, R., Ed., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. - -9.2 Informative References - - [8] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS - Discovery based on Router Advertisement", - draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress), - February 2005. - - [9] Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01.txt (Work in Progress), - February 2004. - - [10] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time - Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in - Progress), January 2005. - - [11] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - - [13] Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6 - - - -Jeong Expires November 6, 2005 [Page 29] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - into ISP Networks", RFC 4029, March 2005. - - [14] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, - March 2005. - - [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", - RFC 3118, June 2001. - - [16] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", - draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress), - July 2004. - - [17] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host - Configuration Protocol (DHCP) version 6", RFC 3633, - December 2003. - - [18] Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP - Standards", RFC 3314, September 2002. - - [19] Soininen, J., Ed., "Transition Scenarios for 3GPP Networks", - RFC 3574, August 2003. - - [20] Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in - Progress), October 2004. - - [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); - Service description; Stage 2 (Release 5)", December 2002. - - [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 - specification; Core network protocols; Stage 3 (Release 5)", - June 2003. - - [23] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering - Requirements for Stateless DHCPv6", - draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in - Progress), October 2004. - - [24] Huitema, C., Ed., "Unmanaged Networks IPv6 Transition - Scenarios", RFC 3750, April 2004. - - [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access - Control (MAC) and Physical Layer (PHY) Specifications", - March 1999. - - [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control - (MAC) and Physical Layer (PHY) specifications: High-speed - Physical Layer in the 5 GHZ Band", September 1999. - - - -Jeong Expires November 6, 2005 [Page 30] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - - [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control - (MAC) and Physical Layer (PHY) specifications: Higher-Speed - Physical Layer Extension in the 2.4 GHz Band", September 1999. - - [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access - Control (MAC) and Physical Layer (PHY) specifications: Further - Higher Data Rate Extension in the 2.4 GHz Band", April 2003. - - [29] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [30] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in - Progress), December 2004. - - [31] Guette, G. and O. Courtay, "Requirements for Automated Key - Rollover in DNSSEC", - draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in - Progress), January 2005. - - [32] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M - and O Flags of IPv6 Router Advertisement", - draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress), - March 2005. - - -Author's Address - - Jaehoon Paul Jeong (editor) - ETRI/Department of Computer Science and Engineering - University of Minnesota - 117 Pleasant Street SE - Minneapolis, MN 55455 - US - - Phone: +1 651 587 7774 - Fax: +1 612 625 2002 - Email: jjeong@cs.umn.edu - URI: http://www.cs.umn.edu/~jjeong/ - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 31] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -Appendix A. Link-layer Multicast Acknowledgements for RA Option - - One benefit of an RA option [8] is to be able to multicast the - advertisements, reducing the need for duplicated unicast - communications. - - However, some link-layers may not support this as well as others. - Consider, for example, WLAN networks where multicast is unreliable. - The unreliability problem is caused by lack of ACK for multicast, - especially on the path from the Access Point (AP) to the Station - (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11 - a/b/g [25]-[28]. That is, a multicast packet is unacknowledged on - the path from the AP to the STA, but acknowledged in the reverse - direction from the STA to the AP [25]. For example, when a router is - placed at wired network connected to an AP, a host may sometimes not - receive RA message advertised through the AP. Therefore, the RA - option solution might not work well on a congested medium that uses - unreliable multicast for RA. - - The fact that this problem has not been addressed in Neighbor - Discovery [3] indicates that the extra link-layer acknowledgements - have not been considered a serious problem till now. - - A possible mitigation technique could be to map all-nodes link- local - multicast address to the link-layer broadcast address, and to rely on - the ND retransmissions for message delivery in order to achieve more - reliability. - - - - - - - - - - - - - - - - - - - - - - - - -Jeong Expires November 6, 2005 [Page 32] - -Internet-Draft IPv6 Host Configuration of DNS Server May 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Jeong Expires November 6, 2005 [Page 33] - diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt deleted file mode 100644 index b2e2341be9..0000000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt +++ /dev/null @@ -1,300 +0,0 @@ -Internet Engineering Task Force A.Durand -INTERNET-DRAFT SUN Microsystems,inc. -November, 24, 2003 J. Ihren -Expires May 25, 2004 Autonomica - - - DNS IPv6 transport operational guidelines - - - - -Status of this Memo - - This memo provides information to the Internet community. It does not - specify an Internet standard of any kind. This memo is in full - conformance with all provisions of Section 10 of RFC2026 - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - -Abstract - - This memo provides guidelines and Best Current Practice to operate - DNS in a world where queries and responses are carried in a mixed - environment of IPv4 and IPv6 networks. - - -Acknowledgment - - This document is the result of many conversations that happened in - the DNS community at IETF and elsewhere since 2001. During that - period of time, a number of Internet drafts have been published to - clarify various aspects of the issues at stake. This document focuses - on the conclusion of those discussions. - - The authors would like to acknowledge the role of Pekka Savola in his - thorough review of the document. - - -1. Terminology - - The phrase "IPv4 name server" indicates a name server available over - IPv4 transport. It does not imply anything about what DNS data is - served. Likewise, "IPv6 name server" indicates a name server - available over IPv6 transport. The phrase "dual-stack DNS server" - indicates a DNS server that is actually configured to run both - protocols, IPv4 and IPv6, and not merely a server running on a system - capable of running both but actually configured to run only one. - - 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 [2119]. - - -2. Introduction to the Problem of Name Space Fragmentation: - following the referral chain - - The caching resolver that tries to look up a name starts out at the - root, and follows referrals until it is referred to a nameserver that - is authoritative for the name. If somewhere down the chain of - referrals it is referred to a nameserver that is only accessible over - an unavailable type of transport, a traditional nameserver is unable - to finish the task. - - When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is - only a matter of time until this starts to happen. The complete DNS - hierarchy then starts to fragment into a graph where authoritative - nameservers for certain nodes are only accessible over a certain - transport. What is feared is that a node using only a particular - version of IP, querying information about another node using the same - version of IP can not do it because, somewhere in the chain of - servers accessed during the resolution process, one or more of them - will only be accessible with the other version of IP. - - With all DNS data only available over IPv4 transport everything is - simple. IPv4 resolvers can use the intended mechanism of following - referrals from the root and down while IPv6 resolvers have to work - through a "translator", i.e. they have to use a second name server on - a so-called "dual stack" host as a "forwarder" since they cannot - access the DNS data directly. - - With all DNS data only available over IPv6 transport everything would - be equally simple, with the exception of old legacy IPv4 name servers - having to switch to a forwarding configuration. - - However, the second situation will not arise in a foreseeable time. - Instead, it is expected that the transition will be from IPv4 only to - a mixture of IPv4 and IPv6, with DNS data of theoretically three - categories depending on whether it is available only over IPv4 - transport, only over IPv6 or both. - - Having DNS data available on both transports is the best situation. - The major question is how to ensure that it as quickly as possible - becomes the norm. However, while it is obvious that some DNS data - will only be available over v4 transport for a long time it is also - obvious that it is important to avoid fragmenting the name space - available to IPv4 only hosts. I.e. during transition it is not - acceptable to break the name space that we presently have available - for IPv4-only hosts. - - -3. Policy Based Avoidance of Name Space Fragmentation - - Today there are only a few DNS "zones" on the public Internet that - are available over IPv6 transport, and most of them can be regarded - as "experimental". However, as soon as the root and top level domains - are available over IPv6 transport, it is reasonable to expect that it - will become more common to have zones served by IPv6 servers. - - Having those zones served only by IPv6-only name server would not be - a good development, since this will fragment the previously - unfragmented IPv4 name space and there are strong reasons to find a - mechanism to avoid it. - - The RECOMMENDED approach to maintain name space continuity is to use - administrative policies, as described in the next section. - - -4. DNS IPv6 Transport RECOMMENDED Guidelines - - In order to preserve name space continuity, the following administrative - policies are RECOMMENDED: - - every recursive DNS server SHOULD be either IPv4-only or dual - stack, - - every single DNS zone SHOULD be served by at least one IPv4 - reachable DNS server. - - This rules out IPv6-only DNS servers performing full recursion and - DNS zones served only by IPv6-only DNS servers. However, one could - very well design a configuration where a chain of IPv6 only DNS - servers forward queries to a set of dual stack DNS servers actually - performing those recursive queries. This approach could be revisited - if/when translation techniques between IPv4 and IPv6 were to be - widely deployed. - - In order to help enforcing the second point, the optional operational - zone validation processes SHOULD ensure that there is at least one - IPv4 address record available for the name servers of any child - delegations within the zone. - - -5. Security Considerations - - Being a critical piece of the Internet infrastructure, the DNS is a - potential value target and thus should be protected. Great care - should be taken not to weaken the security of DNS while introducing - IPv6 operation. - - Keeping the DNS name space from fragmenting is a critical thing for - the availability and the operation of the Internet; this memo - addresses this issue by clear and simple operational guidelines. - - The RECOMMENDED guidelines are compatible with the operation of - DNSSEC and do not introduce any new security issues. - - -6. Author Addresses - - Alain Durand - SUN Microsystems, Inc - 17 Network circle UMPK17-202 - Menlo Park, CA, 94025 - USA - Mail: Alain.Durand@sun.com - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm, Sweden - Mail: johani@autonomica.se - - -7. Normative References - - [2119] Bradner, S., "Key Words for Use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - -8. Full Copyright Statement - - "Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt deleted file mode 100644 index 6bece56182..0000000000 --- a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt +++ /dev/null @@ -1,389 +0,0 @@ - -DNSOP G. Guette -Internet-Draft IRISA / INRIA -Expires: July 19, 2005 O. Courtay - Thomson R&D - January 18, 2005 - - Requirements for Automated Key Rollover in DNSSEC - draft-ietf-dnsop-key-rollover-requirements-02.txt - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 19, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). All Rights Reserved. - -Abstract - - This document describes problems that appear during an automated - rollover and gives the requirements for the design of communication - between parent zone and child zone during an automated rollover - process. This document is essentially about in-band key rollover. - - - - -Guette & Courtay Expires July 19, 2005 [Page 1] -Internet-Draft Automated Rollover Requirements January 2005 - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 - 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Messages authentication and information exchanged . . . . . . 5 - 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 - A. Documents details and changes . . . . . . . . . . . . . . . . 7 - Intellectual Property and Copyright Statements . . . . . . . . 8 - - - - - - - - - - - - - - - - - - - -Guette & Courtay Expires July 19, 2005 [Page 2] -Internet-Draft Automated Rollover Requirements January 2005 - -1. Introduction - - The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key - cryptography and digital signatures. It stores the public part of - keys in DNSKEY Resource Records (RRs). Because old keys and - frequently used keys are vulnerable, they must be renewed - periodically. In DNSSEC, this is the case for Zone Signing Keys - (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key - exchanges between parents and children is necessary for large zones - because there are too many changes to handle. - - Let us consider for example a zone with 100000 secure delegations. - If the child zones change their keys once a year on average, that - implies 300 changes per day for the parent zone. This amount of - changes is hard to manage manually. - - Automated rollover is optional and resulting from an agreement - between the administrator of the parent zone and the administrator of - the child zone. Of course, key rollover can also be done manually by - administrators. - - This document describes the requirements for a protocol to perform - the automated key rollover process and focusses on interaction - between parent and child zone. - -2. The Key Rollover Process - - Key rollover consists of renewing the DNSSEC keys used to sign - resource records in a given DNS zone file. There are two types of - rollover, ZSK rollovers and KSK rollovers. - - During a ZSK rollover, all changes are local to the zone that renews - its key: there is no need to contact other zones administrators to - propagate the performed changes because a ZSK has no associated DS - record in the parent zone. - - During a KSK rollover, new DS RR(s) must be created and stored in the - parent zone. In consequence, data must be exchanged between child - and parent zones. - - The key rollover is built from two parts of different nature: - o An algorithm that generates new keys and signs the zone file. It - can be local to the zone, - o the interaction between parent and child zones. - - One example of manual key rollover [3] is: - o The child zone creates a new KSK, - - -Guette & Courtay Expires July 19, 2005 [Page 3] -Internet-Draft Automated Rollover Requirements January 2005 - - o the child zone waits for the creation of the DS RR in its parent - zone, - o the child zone deletes the old key, - o the parent zone deletes the old DS RR. - - This document concentrates on defining interactions between entities - present in key rollover process. - -3. Basic Requirements - - This section provides the requirements for automated key rollover in - case of normal use. Exceptional case like emergency rollover is - specifically described later in this document. - - The main condition during a key rollover is that the chain of trust - must be preserved to every validating DNS client. No matter if this - client retrieves some of the RRs from recursive caching name server - or from the authoritative servers for the zone involved in the - rollover. - - Automated key rollover solution may be interrupted by a manual - intervention. This manual intervention should not compromise the - security state of the chain of trust. If the chain is safe before - the manual intervention, the chain of trust must remain safe during - and after the manual intervention - - Two entities act during a KSK rollover: the child zone and its parent - zone. These zones are generally managed by different administrators. - These administrators should agree on some parameters like - availability of automated rollover, the maximum delay between - notification of changes in the child zone and the resigning of the - parent zone. The child zone needs to know this delay to schedule its - changes and/or to verify that the changes had been taken into account - in the parent zone. Hence, the child zone can also avoid some - critical cases where all child key are changed prior to the DS RR - creation. - - By keeping some resource records during a given time, the recursive - cache servers can act on the automated rollover. The existence of - recursive cache servers must be taken into account by automated - rollover solution. - - Indeed, during an automated key rollover a name server could have to - retrieve some DNSSEC data. An automated key rollover solution must - ensure that these data are not old DNSSEC material retrieved from a - recursive name server. - - - -Guette & Courtay Expires July 19, 2005 [Page 4] -Internet-Draft Automated Rollover Requirements January 2005 - -4. Messages authentication and information exchanged - - This section addresses in-band rollover, security of out-of-band - mechanisms is out of scope of this document. - - The security provided by DNSSEC must not be compromised by the key - rollover, thus every exchanged message must be authenticated to avoid - fake rollover messages from malicious parties. - - Once the changes related to a KSK are made in a child zone, there are - two ways for the parent zone to take this changes into account: - o the child zone notify directly or not directly its parent zone in - order to create the new DS RR and store this DS RR in parent zone - file, - o or the parent zone poll the child zone. - - In both cases, the parent zone must receive all the child keys that - need the creation of associated DS RRs in the parent zone. - - Because errors could occur during the transmission of keys between - child and parent, the key exchange protocol must be fault tolerant. - Should an error occured during the automated key rollover, an - automated key rollover solution must be able to keep the zone files - in a consistent state. - -5. Emergency Rollover - - Emergency key rollover is a special case of rollover decided by the - zone administrator generally for security reasons. In consequence, - emergency key rollover can break some of the requirement described - above. - - A zone key might be compromised and an attacker can use the - compromised key to create and sign fake records. To avoid this, the - zone administrator may change the compromised key or all its keys as - soon as possible, without waiting for the creation of new DS RRs in - its parent zone. - - Fast changes may break the chain of trust. The part of DNS tree - having this zone as apex can become unverifiable, but the break of - the chain of trust is necessary if the administrator wants to prevent - the compromised key from being used (to spoof DNS data). - - Parent and child zones sharing an automated rollover mechanism, - should have an out-of-band way to re-establish a consistent state at - the delegation point (DS and DNSKEY RRs). This allows to avoid that - a malicious party uses the compromised key to roll the zone keys. - - -Guette & Courtay Expires July 19, 2005 [Page 5] -Internet-Draft Automated Rollover Requirements January 2005 - -6. Security consideration - - The automated key rollover process in DNSSEC allows automated renewal - of any kind of DNS key (ZSK or KSK). It is essential that parent - side and child side can do mutual authentication. Moreover, - integrity of the material exchanged between the parent and child zone - must be provided to ensure the right DS are created. - - As in any application using public key cryptography, in DNSSEC a key - may be compromised. What to do in such a case can be describe in the - zone local policy and can violate some requirements described in this - draft. The emergency rollover can break the chain of trust in order - to protect the zone against the use of the compromised key. - -7. Acknowledgments - - The authors want to thank members of IDsA project for their - contribution to this document. - -8 Normative References - - [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - [3] Kolkman, O., "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practice-01 (work in - progress), May 2004. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-11 (work in progress), October - 2004. - - [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-13 (work in progress), October - 2004. - - [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October - - -Guette & Courtay Expires July 19, 2005 [Page 6] -Internet-Draft Automated Rollover Requirements January 2005 - - 2004. - -Authors' Addresses - - Gilles Guette - IRISA / INRIA - Campus de Beaulieu - 35042 Rennes CEDEX - FR - - EMail: gilles.guette@irisa.fr - URI: http://www.irisa.fr - - Olivier Courtay - Thomson R&D - 1, avenue Belle Fontaine - 35510 Cesson S?vign? CEDEX - FR - - EMail: olivier.courtay@thomson.net - -Appendix A. Documents details and changes - - This section is to be removed by the RFC editor if and when the - document is published. - - Section about NS RR rollover has been removed - - Remarks from Samuel Weiler and Rip Loomis added - - Clarification about in-band rollover and in emergency section - - Section 3, details about recursive cache servers added - - - - - - - - -Guette & Courtay Expires July 19, 2005 [Page 7] -Internet-Draft Automated Rollover Requirements January 2005 - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described - in this document or the extent to which any license under such - rights might or might not be available; neither does it represent - that it has made any effort to identify any such rights. - Information on the IETF's procedures with respect to rights in - IETF Documents can be found in BCP 78 and 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention - any copyrights, patents or patent applications, or other - proprietary rights which may cover technology that may be required - to implement this standard. Please address the information to the - IETF at ietf-ipr.org. - - - Full Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - -Guette & Courtay Expires July 19, 2005 [Page 8] diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt deleted file mode 100644 index c6ec7e42a5..0000000000 --- a/doc/draft/draft-ietf-dnsop-serverid-06.txt +++ /dev/null @@ -1,618 +0,0 @@ - - - - -Network Working Group S. Woolf -Internet-Draft Internet Systems Consortium, Inc. -Expires: September 6, 2006 D. Conrad - Nominum, Inc. - March 5, 2006 - - - Requirements for a Mechanism Identifying a Name Server Instance - draft-ietf-dnsop-serverid-06 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 6, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid for - administrators. Existing ad hoc mechanisms for addressing this need - - - -Woolf & Conrad Expires September 6, 2006 [Page 1] - -Internet-Draft Serverid March 2006 - - - have some shortcomings, not the least of which is the lack of prior - analysis of exactly how such a mechanism should be designed and - deployed. This document describes the existing convention used in - some widely deployed implementations of the DNS protocol, including - advantages and disadvantages, and discusses some attributes of an - improved mechanism. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 2] - -Internet-Draft Serverid March 2006 - - -1. Introduction and Rationale - - Identifying which name server is responding to queries is often - useful, particularly in attempting to diagnose name server - difficulties. This is most obviously useful for authoritative - nameservers in the attempt to diagnose the source or prevalence of - inaccurate data, but can also conceivably be useful for caching - resolvers in similar and other situations. Furthermore, the ability - to identify which server is responding to a query has become more - useful as DNS has become more critical to more Internet users, and as - network and server deployment topologies have become more complex. - - The traditional means for determining which of several possible - servers is answering a query has traditionally been based on the use - of the server's IP address as a unique identifier. However, the - modern Internet has seen the deployment of various load balancing, - fault-tolerance, or attack-resistance schemes such as shared use of - unicast IP addresses as documented in [RFC3258]. An unfortunate side - effect of these schemes has been to make the use of IP addresses as - identifiers somewhat problematic. Specifically, a dedicated DNS - query may not go to the same server as answered a previous query, - even though sent to the same IP address. Non-DNS methods such as - ICMP ping, TCP connections, or non-DNS UDP packets (such as those - generated by tools like "traceroute"), etc., may well be even less - certain to reach the same server as the one which receives the DNS - queries. - - There is a well-known and frequently-used technique for determining - an identity for a nameserver more specific than the possibly-non- - unique "server that answered the query I sent to IP address XXX". - The widespread use of the existing convention suggests a need for a - documented, interoperable means of querying the identity of a - nameserver that may be part of an anycast or load-balancing cluster. - At the same time, however, it also has some drawbacks that argue - against standardizing it as it's been practiced so far. - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 3] - -Internet-Draft Serverid March 2006 - - -2. Existing Conventions - - For some time, the commonly deployed Berkeley Internet Name Domain - implementation of the DNS protocol suite from the Internet Systems - Consortium [BIND] has supported a way of identifying a particular - server via the use of a standards-compliant, if somewhat unusual, DNS - query. Specifically, a query to a recent BIND server for a TXT - resource record in class 3 (CHAOS) for the domain name - "HOSTNAME.BIND." will return a string that can be configured by the - name server administrator to provide a unique identifier for the - responding server. (The value defaults to the result of a - gethostname() call). This mechanism, which is an extension of the - BIND convention of using CHAOS class TXT RR queries to sub-domains of - the "BIND." domain for version information, has been copied by - several name server vendors. - - A refinement to the BIND-based mechanism, which dropped the - implementation-specific string, replaces ".BIND" with ".SERVER". - Thus the query string to learn the unique name of a server may be - queried as "ID.SERVER". - - (For reference, the other well-known name used by recent versions of - BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A - query for a CHAOS TXT RR for this name will return an - administratively defined string which defaults to the version of the - server responding. This is, however, not generally implemented by - other vendors.) - -2.1. Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - - 1. The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is - within the DNS protocol itself. An identification mechanism that - relies on the DNS protocol is more likely to be successful - (although not guaranteed) in going to the same system as a - "normal" DNS query. - - 2. Since the identity information is requested and returned within - the DNS protocol, it doesn't require allowing any other query - mechanism to the server, such as holes in firewalls for - otherwise-unallowed ICMP Echo requests. Thus it is likely to - reach the same server over a path subject to the same routing, - resource, and security policy as the query, without any special - exceptions to site security policy. - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 4] - -Internet-Draft Serverid March 2006 - - - 3. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - - 4. It allows the administrator complete control of what information - is given out in the response, minimizing passive leakage of - implementation or configuration details. Such details are often - considered sensitive by infrastructure operators. - - 5. Hypothetically, since it's an ordinary DNS record and the - relevant DNSSEC RRs are class independent, the id.server response - RR could be signed, which has the advantages described in - [RFC4033]. - -2.2. Disadvantages - - At the same time, there are some serious drawbacks to the CHAOS/TXT - query mechanism that argue against standardizing it as it currently - operates. - - 1. It requires an additional query to correlate between the answer - to a DNS query under normal conditions and the supposed identity - of the server receiving the query. There are a number of - situations in which this simply isn't reliable. - - 2. It reserves an entire class in the DNS (CHAOS) for what amounts - to one zone. While CHAOS class is defined in [RFC1034] and - [RFC1035], it's not clear that supporting it solely for this - purpose is a good use of the namespace or of implementation - effort. - - 3. The initial and still common form, using .BIND, is implementation - specific. BIND is one DNS implementation. At the time of this - writing, it is probably the most prevalent for authoritative - servers. This does not justify standardizing on its ad hoc - solution to a problem shared across many operators and - implementors. Meanwhile, the proposed refinement changes the - string but preserves the ad hoc CHAOS/TXT mechanism. - - 4. There is no convention or shared understanding of what - information an answer to such a query for a server identity could - or should include, including a possible encoding or - authentication mechanism. - - The first of the listed disadvantages may be technically the most - serious. It argues for an attempt to design a good answer to the - problem that "I need to know what nameserver is answering my - queries", not simply a convenient one. - - - - -Woolf & Conrad Expires September 6, 2006 [Page 5] - -Internet-Draft Serverid March 2006 - - -2.3. Characteristics of an Implementation Neutral Convention - - The discussion above of advantages and disadvantages to the - HOSTNAME.BIND mechanism suggest some requirements for a better - solution to the server identification problem. These are summarized - here as guidelines for any effort to provide appropriate protocol - extensions: - - 1. The mechanism adopted must be in-band for the DNS protocol. That - is, it needs to allow the query for the server's identifying - information to be part of a normal, operational query. It should - also permit a separate, dedicated query for the server's - identifying information. But it should preserve the ability of - the CHAOS/TXT query-based mechanism to work through firewalls and - in other situations where only DNS can be relied upon to reach - the server of interest. - - 2. The new mechanism should not require dedicated namespaces or - other reserved values outside of the existing protocol mechanisms - for these, i.e. the OPT pseudo-RR. In particular, it should not - propagate the existing drawback of requiring support for a CLASS - and top level domain in the authoritative server (or the querying - tool) to be useful. - - 3. Support for the identification functionality should be easy to - implement and easy to enable. It must be easy to disable and - should lend itself to access controls on who can query for it. - - 4. It should be possible to return a unique identifier for a server - without requiring the exposure of information that may be non- - public and considered sensitive by the operator, such as a - hostname or unicast IP address maintained for administrative - purposes. - - 5. It should be possible to authenticate the received data by some - mechanism analogous to those provided by DNSSEC. In this - context, the need could be met by including encryption options in - the specification of a new mechanism. - - 6. The identification mechanism should not be implementation- - specific. - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 6] - -Internet-Draft Serverid March 2006 - - -3. IANA Considerations - - This document proposes no specific IANA action. Protocol extensions, - if any, to meet the requirements described are out of scope for this - document. A proposed extension, specified and adopted by normal IETF - process, is described in [NSID], including relevant IANA action. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 7] - -Internet-Draft Serverid March 2006 - - -4. Security Considerations - - Providing identifying information as to which server is responding to - a particular query from a particular location in the Internet can be - seen as information leakage and thus a security risk. This motivates - the suggestion above that a new mechanism for server identification - allow the administrator to disable the functionality altogether or - partially restrict availability of the data. It also suggests that - the serverid data should not be readily correlated with a hostname or - unicast IP address that may be considered private to the nameserver - operator's management infrastructure. - - Propagation of protocol or service meta-data can sometimes expose the - application to denial of service or other attack. As DNS is a - critically important infrastructure service for the production - Internet, extra care needs to be taken against this risk for - designers, implementors, and operators of a new mechanism for server - identification. - - Both authentication and confidentiality of serverid data are - potentially of interest to administrators-- that is, operators may - wish to make serverid data available and reliable to themselves and - their chosen associates only. This would imply both an ability to - authenticate it to themselves and keep it private from arbitrary - other parties. This led to Characteristics 4 and 5 of an improved - solution. - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 8] - -Internet-Draft Serverid March 2006 - - -5. Acknowledgements - - The technique for host identification documented here was initially - implemented by Paul Vixie of the Internet Software Consortium in the - Berkeley Internet Name Daemon package. Comments and questions on - earlier drafts were provided by Bob Halley, Brian Wellington, Andreas - Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the - ICANN Root Server System Advisory Committee. The newest version - takes a significantly different direction from previous versions, - owing to discussion among contributors to the DNSOP working group and - others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam - Weiler, and Rob Austein. - -6. References - - [1] Mockapetris, P., "Domain Names - Concepts and Facilities", - RFC 1034, STD 0013, November 1987. - - [2] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, STD 0013, November 1987. - - [3] Hardie, T., "Distributing Authoritative Name Servers via Shared - Unicast Addresses", RFC 3258, April 2002. - - [4] ISC, "BIND 9 Configuration Reference". - - [5] Austein, S., "DNS Name Server Identifier Option (NSID)", - Internet Drafts http://www.ietf.org/internet-drafts/ - draft-ietf-dnsext-nsid-01.txt, January 2006. - - [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 9] - -Internet-Draft Serverid March 2006 - - -Authors' Addresses - - Suzanne Woolf - Internet Systems Consortium, Inc. - 950 Charter Street - Redwood City, CA 94063 - US - - Phone: +1 650 423-1333 - Email: woolf@isc.org - URI: http://www.isc.org/ - - - David Conrad - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - US - - Phone: +1 1 650 381 6003 - Email: david.conrad@nominum.com - URI: http://www.nominum.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 10] - -Internet-Draft Serverid March 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Woolf & Conrad Expires September 6, 2006 [Page 11] - - diff --git a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt deleted file mode 100644 index 3353b3bb42..0000000000 --- a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt +++ /dev/null @@ -1,1588 +0,0 @@ - - Mark Foster -Internet Draft Tom McGarry -Document: James Yu - NeuStar, Inc. -Category: Informational June 24, 2002 - - - Number Portability in the GSTN: An Overview - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [RFC]. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. Internet-Drafts are draft documents valid for a maximum of - six months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet- Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - Copyright Notice - - Copyright (C) The Internet Society (2002). All rights reserved. - - - Abstract - - This document provides an overview of E.164 telephone number - portability (NP) in the Global Switched Telephone Network (GSTN). - NP is a regulatory imperative seeking to liberalize local telephony - service competition, by enabling end-users to retain telephone - numbers while changing service providers. NP changes the - fundamental nature of a dialed E.164 number from a hierarchical - physical routing address to a virtual address, thereby requiring the - transparent translation of the later to the former. In addition, - there are various regulatory constraints that establish relevant - parameters for NP implementation, most of which are not network - technology specific. Consequently, the implementation of NP - behavior consistent with applicable regulatory constraints, as well - as the need for interoperation with the existing GSTN NP - implementations, are relevant topics for numerous areas of IP - telephony work-in-progress at IETF. - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 1] - -Number Portability in the GSTN: An Overview June 24, 2002 - - - Table of Contents - - 1. Introduction ............................................... 2 - 2. Abbreviations and Acronyms ................................. 4 - 3. Types of Number Portability ................................ 5 - 4. Service Provider Number Portability Schemes ................ 7 - 4.1 All Call Query (ACQ) .................................. 7 - 4.2 Query on Release (QoR) ................................ 8 - 4.3 Call Dropback ......................................... 9 - 4.4 Onward Routing (OR) ................................... 9 - 4.5 Comparisons of the Four Schemes ....................... 10 - 5. Database Queries in the NP Environment ..................... 11 - 5.1 U.S. and Canada ....................................... 12 - 5.2 Europe ................................................ 13 - 6. Call Routing in the NP Environment ......................... 14 - 6.1 U.S. and Canada ....................................... 14 - 6.2 Europe ................................................ 15 - 7. NP Implementations for Geographic E.164 Numbers ............ 17 - 8. Number Conservation Method Enabled By NP ................... 20 - 8.1 Block Pooling ......................................... 20 - 8.2 ITN Pooling ........................................... 21 - 9. Potential Implications ..................................... 21 - 10. Security Considerations .................................... 24 - 11. IANA Considerations ........................................ 24 - 12. Normative References ....................................... 24 - 13. Informative References ..................................... 25 - 14. Acknowledgement ............................................ 25 - 15. Authors Addresses ......................................... 25 - - - -1. Introduction - - This document provides an overview of E.164 telephone number - portability in the Global Switched Telephone Network (GSTN). There - are considered to be three types of number portability (NP): service - provider portability (SPNP), location portability (not to be - confused with terminal mobility), and service portability. - - Service provider portability (SPNP), the focus of the present draft, - is a regulatory imperative in many countries seeking to liberalize - telephony service competition, especially local service. - Historically, local telephony service (as compared to long distance - or international service) has been regulated as a utility-like form - of service. While a number of countries had begun liberalization - (e.g. privatization, de-regulation, or re-regulation) some years - ago, the advent of NP is relatively recent (since ~1995). - - E.164 numbers can be non-geographic and geographic numbers. Non- - geographic numbers do not reveal the locations information of those - numbers. Geographic E.164 numbers were intentionally designed as - hierarchical routing addresses which could systematically be digit- - analyzed to ascertain the country, serving network provider, serving - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 2] - -Number Portability in the GSTN: An Overview June 24, 2002 - - end-office switch, and specific line of the called party. As such, - without NP a subscriber wishing to change service providers would - incur a number change as a consequence of being served off of a - different end-office switch operated by the new service provider. - The cost and convenience impact to the subscriber of changing - numbers is seen as barrier to competition. Hence NP has become - associated with GSTN infrastructure enhancements associated with a - competitive environment driven by regulatory directives. - - Forms of SPNP have been deployed or are being deployed widely in the - GSTN in various parts of the world, including the U.S., Canada, - Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). - Other regions, such as South America (e.g. Brazil) are actively - considering it. - - Implementation of NP within a national telephony infrastructure - entails potentially significant changes to numbering administration, - network element signaling, call routing and processing, billing, - service management, and other functions. - - NP changes the fundamental nature of a dialed E.164 number from a - hierarchical physical routing address to a virtual address. NP - implementations attempt to encapsulate the impacts to the GSTN and - make NP transparent to subscribers by incorporating a translation - function to map a dialed, potentially ported E.164 address, into a - network routing address (either a number prefix or another E.164 - address) which can be hierarchically routed. - - This is roughly analogous to the use of network address translation - on IP addresses to enable IP address portability by containing the - impact of the address change to the edge of the network and retain - the use of CIDR blocks in the core which can be route aggregated by - the network service provider to the rest of the internet. - - NP bifurcates the historical role of a subscribers E.164 address - into two or more data elements (a dialed or virtual address, and a - network routing address) that must be made available to network - elements through an NP translations database, carried by forward - call signaling, and recorded on call detail records. Not only is - call processing and routing affected, but also so is SS7/C7 - messaging. A number of TCAP-based SS7 messaging sets utilize an - E.164 address as an application-level network element address in the - global title address (GTA) field of the SCCP message header. - Consequently, SS7/C7 signaling transfer points (STPs) and gateways - need to be able to perform n-digit global title translation (GTT) to - translate a dialed E.164 address into its network address - counterpart via the NP database. - - In addition, there are various national regulatory constraints that - establish relevant parameters for NP implementation, most of which - are not network technology specific. Consequently, implementations - of NP behavior in IP telephony consistent with applicable regulatory - constraints, as well as the need for interoperation with the - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 3] - -Number Portability in the GSTN: An Overview June 24, 2002 - - existing GSTN NP implementations, are relevant topics for numerous - areas of IP telephony work-in-progress at IETF. - - This document describes three types of number portability and the - four schemes that have been standardized to support SPNP for - geographic E.164 numbersspecifically. Following that, specific - information regarding the call routing and database query - implementations are described for several regions (North American - and Europe) and industries (wireless vs. wireline). The Number - Portability Database (NPDB) interfaces and the call routing schemes - that are used in the North America and Europe are described to show - the variety of standards that may be implemented worldwide. A - glance of the NP implementations worldwide is provided. Number - pooling is briefly discussed to show how NP is being enhanced in the - U.S. to conserve North American area codes. The conclusion briefly - touches the potential impacts of NP on IP & Telecommunications - Interoperability. Appendix A provides some specific technical and - regulatory information on NP in North America. Appendix B describes - the number portability administration process that manages the - number portability database in North America. - - -2. Abbreviations and Acronyms - - ACQ All Call Query - AIN Advanced Intelligent Network - AMPS Advanced Mobile Phone System - ANSI American National Standards Institute - CDMA Code Division Multiple Access - CdPA Called Party Address - CdPN Called Party Number - CH Code Holder - CMIP Common Management Information Protocol - CS1 Capability Set 1 - CS2 Capability Set 2 - DN Directory Number - DNS Domain Name System - ETSI European Technical Standards Institute - FCI Forward Call Indicator - GAP Generic Address Parameter - GMSC Gateway Mobile Services Switching Center or Gateway Mobile - Switching Center - GSM Global System for Mobile Communications - GSTN Global Switched Telephone Network - GW Gateways - HLR Home Location Register - IAM Initial Address Message - IETF Internet Engineering Task Force - ILNP Interim LNP - IN Intelligent Network - INAP Intelligent Network Application Part - INP Interim NP - IP Internet Protocol - IS-41 Interim Standards Number 41 - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 4] - -Number Portability in the GSTN: An Overview June 24, 2002 - - ISDN Integrated Services Digital Network - ISUP ISDN User Part - ITN Individual Telephony Number - ITU International Telecommunication Union - ITU-TS ITU-Telecommunication Sector - LDAP Lightweight Directory Access Protocol - LEC Local Exchange Carrier - LERG Local Exchange Routing Guide - LNP Local Number Portability - LRN Location Routing Number - MAP Mobile Application Part - MNP Mobile Number Portability - MSRN Mobile Station Roaming Number - MTP Message Transfer Part - NANP North American Numbering Plan - NP Number Portability - NPDB Number Portability Database - NRN Network Routing Number - OR Onward Routing - OSS Operation Support System - PCS Personal Communication Services - PNTI Ported Number Translation Indicator - PODP Public Office Dialing Plan - PUC Public Utility Commission - QoR Query on Release - RN Routing Number - RTP Return to Pivot - SCCP Signaling Connection Control Part - SCP Service Control Point - SIP Session Initiation Protocol - SMR Special Mobile Radio - SMS Service Management System - SPNP Service Provider Number Portability - SRF Signaling Relaying Function - SRI Send Routing Information - SS7 Signaling System Number 7 - STP Signaling Transfer Point - TCAP Transaction Capabilities Application Part - TDMA Time Division Multiple Access - TN Telephone Number - TRIP Telephony Routing Information Protocol - URL Universal Resource Locator - U.S. United States - - -3. Types of Number Portability - - As there are several types of E.164 numbers (telephone numbers, or - just TN) in the GSTN, there are correspondingly several types of - E.164 NP in the GSTN. First there are so-call non-geographic E.164 - numbers, commonly used for service-specific applications such as - freephone (800 or 0800). Portability of these numbers is called - non-geographic number portability (NGNP). NGNP, for example, was - deployed in the U.S. in 1986-92. - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 5] - -Number Portability in the GSTN: An Overview June 24, 2002 - - - Geographic number portability, which includes traditional fixed or - wireline numbers as well as mobile numbers which are allocated out - of geographic number range prefixes, is called NP or GNP or in the - U.S. local number portability (LNP). - - Number portability allows the telephony subscribers in the Global - Switched Telephone Network (GSTN) to keep their phone numbers when - they change their service providers or subscribed services, or when - they move to a new location. - - The ability to change the service provider while keeping the same - phone number is called service provider portability (SPNP) also - known as "operator portability." - - The ability to change the subscribers fixed service location while - keeping the same phone number is called location portability. - - The ability to change the subscribed services (e.g., from the plain - old telephone service to Integrated Services Digital Network (ISDN) - services) while keeping the same phone number is called service - portability. Another aspect of service portability is to allow the - subscribers to enjoy the subscribed services in the same way when - they roam outside their home networks as is supported by the - cellular/wireless networks. - - In addition, mobile number portability (MNP) refers to specific NP - implementation in mobile networks either as part of a broader NP - implementation in the GSTN or on a stand-alone basis. Where - interoperation of LNP and MNP is supported, service portability - between fixed and mobile service types is possible. - - At present, SPNP has been the primary form of NP deployed due to its - relevance in enabling local service competition. - - Also in use in the GSTN are the terms interim NP (INP) or Interim - LNP (ILNP) and true NP. Interim NP usually refers to the use of - remote call forwarding-like measures to forward calls to ported - numbers through the donor network to the new service network. These - are considered interim relative to true NP, which seeks to remove - the donor network or old service provider from the call or signaling - path altogether. Often the distinction between interim and true NP - is a national regulatory matter relative to the - technical/operational requirements imposed on NP in that country. - - Implementations of true NP in certain countries (e.g. U.S., Canada, - Spain, Belgium, Denmark) may pose specific requirements for IP - telephony implementations as a result of regulatory and industry - requirements for providing call routing and signaling independent of - the donor network or last previous serving network. - - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 6] - -Number Portability in the GSTN: An Overview June 24, 2002 - - -4. Service Provider Number Portability Schemes - - Four schemes can be used to support service provider portability and - are briefly described below. But first, some further terms are - introduced. - - The donor network is the network that first assigned a telephone - number (e.g., TN +1-202-533-1234) to a subscriber, out of a number - range administratively (e.g., +1 202-533) assigned to it. The - current service provider (new SP) or new serving network is the - network that currently serves the ported number. The old serving - network (or old SP) is the network that previously served the ported - number before the number was ported to the new serving network. - Since a TN can port a number of times, the old SP is not necessarily - the same as the donor network, except for the first time the TN - ports away, or if the TN ports back into the donor network and away - again. While the new SP and old SP roles are transitory as a TN - ports around, the donor network is always the same for any - particular TN based on the service provider to whom the subtending - number range was administratively assigned. See the discussion - below on number pooling, as this enhancement to NP further - bifurcates the role of donor network into two (the number range or - code holder network, and the block holder network). - - To simplify the illustration, all the transit networks are ignored, - the originating or donor network is the one that performs the - database queries or call redirection, and the dialed directory - number (TN) has been ported out of the donor network before. - - It is assumed that the old serving network, the new serving network - and the donor network are different networks so as to show which - networks are involved in call handling and routing and database - queries in each of four schemes. Please note that the port of the - number (process of moving it from one network to another) happened - prior to the call setup and is not included in the call steps. - Information carried in the signaling messages to support each of the - four schemes is not discussed to simplify the explanation. - - -4.1 All Call Query (ACQ) - - Figure 1 shows the call steps for the ACQ scheme. Those call steps - are as follows: - - (1) The Originating Network receives a call from the caller and - sends a query to a centrally administered Number Portability - Database (NPDB), a copy of which is usually resident on a - network element within its network or through a third party - provider. - (2) The NPDB returns the routing number associated with the dialed - directory number. The routing number is discussed later in - Section 6. - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 7] - -Number Portability in the GSTN: An Overview June 24, 2002 - - (3) The Originating Network uses the routing number to route the - call to the new serving network. - - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | ported | Old Serv. | - | NPDB | +-------->| Network |<------------| Network | - +-------------+ | +-----------+ +-----------+ - ^ | | - | | | - 1| | 3.| - | | 2. | - | | | - | v | - +----------+ | +----------+ +----------+ - | Orig. |------+ | Donor | | Internal | - | Network | | Network | | NPDB | - +----------+ +----------+ +----------+ - - - Figure 1 - All Call Query (ACQ) Scheme. - - -4.2 Query on Release (QoR) - - Figure 2 shows the call steps for the QoR scheme. Those call steps - are as follows: - - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | ported | Old Serv. | - | NPDB | | Network |<------------| Network | - +-------------+ +-----------+ +-----------+ - ^ | ^ - | | 4. | - 3.| | 5. | - | | +----------------------+ - | | | - | v | - +----------+ 2. +----------+ +----------+ - | Orig. |<---------------| Donor | | Internal | - | Network |--------------->| Network | | NPDB | - +----------+ 1. +----------+ +----------+ - - - Figure 2 - Query on Release (QoR) Scheme. - - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network releases the call and indicates that the - dialed directory number has been ported out of that switch. - (3) The Originating Network sends a query to its copy of the - centrally administered NPDB. - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 8] - -Number Portability in the GSTN: An Overview June 24, 2002 - - (4) The NPDB returns the routing number associated with the dialed - directory number. - (5) The Originating Network uses the routing number to route the - call to the new serving network. - - -4.3 Call Dropback - - Figure 3 shows the call steps for the Dropback scheme. This scheme - is also known as "Return to Pivot (RTP)." Those call steps are as - follows: - - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network detects that the dialed directory number has - been ported out of the donor switch and checks with an internal - network-specific NPDB. - (3) The internal NPDB returns the routing number associated with the - dialed directory number. - (4) The donor network releases the call by providing the routing - number. - (5) The Originating Network uses the routing number to route the - call to the new serving network. - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | porting | Old Serv. | - | NPDB | | Network |<------------| Network | - +-------------+ +-----------+ +-----------+ - /\ - | - 5. | - +------------------------+ - | - | - +----------+ 4. +----------+ 3. +----------+ - | Orig. |<---------------| Donor |<----------| Internal | - | Network |--------------->| Network |---------->| NPDB | - +----------+ 1. +----------+ 2. +----------+ - - - Figure 3 - Dropback Scheme. - - -4.4 Onward Routing (OR) - - Figure 4 shows the call steps for the OR scheme. Those call steps - are as follows: - - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network detects that the dialed directory number has - been ported out of the donor switch and checks with an internal - network-specific NPDB. - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 9] - -Number Portability in the GSTN: An Overview June 24, 2002 - - (3) The internal NPDB returns the routing number associated with the - dialed directory number. - (4) The donor network uses the routing number to route the call to - the new serving network. - - - +-------------+ +-----------+ Number +-----------+ - | Centralized | | New Serv. | porting | Old Serv. | - | NPDB | | Network |<------------| Network | - +-------------+ +-----------+ +-----------+ - /\ - | - 4.| - | - +----------+ +----------+ 3. +----------+ - | Orig. | | Donor |<----------| Internal | - | Network |--------------->| Network |---------->| NPDB | - +----------+ 1. +----------+ 2. +----------+ - - - Figure 4 - Onward Routing (OR) Scheme. - -4.5 Comparisons of the Four Schemes - - Only the ACQ scheme does not involve the donor network when routing - the call to the new serving network of the dialed ported number. - The other three schemes involve call setup to or signaling with the - donor network. - - Only the OR scheme requires the setup of two physical call segments, - one from the Originating Network to the donor network and the other - from the donor network to the new serving network. The OR scheme is - the least efficient in terms of using the network transmission - facilities. The QoR and Dropback schemes set up calls to the donor - network first but release the call back to the Originating Network - that then initiates a new call to the Current Serving Network. For - the QoR and Dropback schemes, circuits are still reserved one by one - between the Originating Network and the donor network when the - Originating Network sets up the call towards the donor network. - Those circuits are released one by one when the call is released - from the donor network back to the Originating Network. The ACQ - scheme is the most efficient in terms of using the switching and - transmission facilities for the call. - - Both the ACQ and QoR schemes involve Centralized NPDBs for the - Originating Network to retrieve the routing information. - Centralized NPDB means that the NPDB contains ported number - information from multiple networks. This is in contrast to the - internal network-specific NPDB that is used for the Dropback and OR - schemes. The internal NPDB only contains information about the - numbers that were ported out of the donor network. The internal - NPDB can be a stand-alone database that contains information about - all or some ported-out numbers from the donor network. It can also - reside on the donor switch and only contains information about those - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 10] - -Number Portability in the GSTN: An Overview June 24, 2002 - - numbers ported out of the donor switch. In that case, no query to a - stand-alone internal NPDB is required. The donor switch for a - particular phone number is the switch to which the number range is - assigned from which that phone number was originally assigned. - - For example, number ranges in the North American Numbering Plan - (NANP) are usually assigned in the form of central office codes (CO - codes) comprising a six-digit prefix formatted as a NPA+NXX. Thus a - switch serving +1-202-533 would typically serve +1-202-533-0000 - through +1-202-533-9999. In major cities, switches usually host - several CO codes. NPA stands for Numbering Plan Area that is also - known as the area code. It is three-digit long and has the format - of NXX where N is any digit from 2 to 9 and X is any digit from 0 to - 9. NXX in the NPA+NXX format is known as the office code that has - the same format as the NPA. When a NPA+NXX code is set as - portable in the Local Exchange Routing Guide (LERG), it becomes a - "portable NPA+NXX" code. - - Similarly, in other national E.164 numbering plans, number ranges - cover a contiguous range of numbers within that range. Once a - number within that range has ported away from the donor network, all - numbers in that range are considered potentially ported and should - be queried in the NPDB. - - The ACQ scheme has two versions. One version is for the Originating - Network to always query the NPDB when a call is received from the - caller regardless whether the dialed directory number belongs to any - number range that is portable or has at least one number ported out. - The other version is to check whether the dialed directory number - belongs to any number range that is portable or has at least one - number ported out. If yes, an NPDB query is sent. If not, no NPDB - query is sent. The former performs better when there are many - portable number ranges. The latter performs better when there are - not too many portable number ranges at the expense of checking every - call to see whether NPDB query is needed. The latter ACQ scheme is - similar to the QoR scheme except that the QoR scheme uses call setup - and relies on the donor network to indicate "number ported out" - before launching the NPDB query. - - -5. Database Queries in the NP Environment - - As indicated earlier, the ACQ and QoR schemes require that a switch - query the NPDB for routing information. Various standards have been - defined for the switch-to-NPDB interface. Those interfaces with - their protocol stacks are briefly described below. The term "NPDB" - is used for a stand-alone database that may support just one or some - or all of the interfaces mentioned below. The NPDB query contains - the dialed directory number and the NPDB response contains the - routing number. There are certainly other information that is sent - in the query and response. The primary interest is to get the - routing number from the NPDB to the switch for call routing. - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 11] - -Number Portability in the GSTN: An Overview June 24, 2002 - -5.1 U.S. and Canada - - One of the following five NPDB interfaces can be used to query an - NPDB: - - (a) Advanced Intelligent Network (AIN) using the American National - Standards Institute (ANSI) version of the Intelligent Network - Application Part (INAP) [ANSI SS] [ANSI DB]. The INAP is - carried on top of the protocol stack that includes the (ANSI) - Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling - Connection Control Part (SCCP), and ANSI Transaction - Capabilities Application Part (TCAP). This interface can be - used by the wireline or wireless switches, is specific to the NP - implementation in North America, and is modeled on the Public - Office Dialing Plan (PODP) trigger defined in the Advanced - Intelligent Network (AIN) 0.1 call model. - - (b) Intelligent Network (IN), which is similar to the one used for - querying the 800 databases. The IN protocol is carried on top - of the protocol stack that includes the ANSI MTP Levels 1 - through 3, ANSI SCCP, and ANSI TCAP. This interface can be used - by the wireline or wireless switches. - - (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the - protocol stack that includes the ANSI MTP Levels 1 through 3, - ANSI SCCP, and ANSI TCAP. This interface can be used by the IS- - 41 based cellular/Personal Communication Services (PCS) wireless - switches (e.g., AMPS, TDMA and CDMA). Cellular systems use - spectrum at 800 MHz range and PCS systems use spectrum at 1900 - MHz range. - - (d) Global System for Mobile Communication Mobile Application Part - (GSM MAP) [GSM], which is carried on top of the protocol stack - that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and - International Telecommunication Union - Telecommunication Sector - (ITU-TS) TCAP. It can be used by the PCS1900 wireless switches - that are based on the GSM technologies. GSM is a series of - wireless standards defined by the European Telecommunications - Standards Institute (ETSI). - - (e) ISUP triggerless translation. NP translations are performed - transparently to the switching network by the signaling network - (e.g. Signaling Transfer Points (STPs) or signaling gateways). - ISUP IAM messages are examined to determine if the CdPN field - has already been translated, and if not, an NPDB query is - performed, and the appropriate parameters in the IAM message - modified to reflect the results of the translation. The - modified IAM message is forwarded by the signaling node on to - the designated DPC in a transparent manner to continue call - setup. The NPDB can be integrated with the signaling node or be - accessed via an API locally or by a query to a remote NPDB using - a proprietary protocol or the schemes described above. - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 12] - -Number Portability in the GSTN: An Overview June 24, 2002 - - Wireline switches have the choice of using either (a), (b), or (e). - IS-41 based wireless switches have the choice of using (a), (b), - (c), or (e). PCS1900 wireless switches have the choice of using - (a), (b), (d), or (e). In the United States, service provider - portability will be supported by both the wireline and wireless - systems, not only within the wireline or wireless domain but also - across the wireline/wireless boundary. However, this is not true in - Europe where service provider portability is usually supported only - within the wireline or wireless domain, not across the - wireline/wireless boundary due to explicit use of service-specific - number range prefixes. The reason is to avoid caller confusion - about the call charge. GSM systems in Europe are assigned - distinctive destination network codes, and the caller pays a higher - charge when calling a GSM directory number. - - -5.2 Europe - - One of the following two interfaces can be used to query an NPDB: - - (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is - carried on top of the protocol stack that includes the ITU-TS - MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. - - (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is - carried on top of the protocol stack that includes the ITU-TS - MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, - and ITU-TS TCAP. - - Wireline switches have the choice of using either (a) or (b); - however, all the implementations in Europe so far are based on CS1. - As indicated earlier that number portability in Europe does not go - across the wireline/wireless boundary. The wireless switches can - also use (a) or (b) to query the NPDBs if those NPDBs contains - ported wireless directory numbers. The term "Mobile Number - Portability (MNP)" is used for the support of service provider - portability by the GSM networks in Europe. - - In most, if not all, cases in Europe, the calls to the wireless - directory numbers are routed to the wireless donor network first. - Over there, an internal NPDB is queried to determine whether the - dialed wireless directory number has been ported out or not. In - this case, the interface to the internal NPDB is not subject to - standardization. - - MNP in Europe can also be supported via MNP Signaling Relay Function - (MNP-SRF). Again, an internal NPDB or a database integrated at the - MNP-SRF is used to modify the SCCP Called Party Address parameter in - the GSM MAP messages so that they can be re-directed to the wireless - serving network. Call routing involving MNP will be explained in - Section 6.2. - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 13] - -Number Portability in the GSTN: An Overview June 24, 2002 - -6. Call Routing in the NP Environment - - This section discusses the call routing after the routing - information has been retrieved either through an NPDB query or an - internal database lookup at the donor switch, or from the Integrated - Services Digital Network User Part (ISUP) signaling message (e.g., - for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it - is the Originating Network that has the routing information and is - ready to route the call. For the OR scheme, it is the donor network - that has the routing information and is ready to route the call. - - A number of triggering schemes may be employed that determine where - in the call path the NPDB query is performed. In the U.S. an N-1 - policy is used, which essentially says that for domestic calls, the - originating local carriers performs the query, otherwise, the long - distance carrier is expected to. To ensure independence of the - actual trigger policy employed in any one carrier, forward call - signaling is used to flag that an NPDB query has already been - performed and to therefore suppress any subsequent NP triggers that - may be encountered in downstream switches, in downstream networks. - This allows the earliest able network in the call path to perform - the query without introducing additional costs and call setup delays - were redundant queries performed downstream. - - -6.1 U.S. and Canada - - In the U.S. and Canada, a ten-digit North American Numbering Plan - (NANP) number called Location Routing Number (LRN) is assigned to - every switch involved in NP. In the NANP, a switch is not reachable - unless it has a unique number range (CO code) assigned to it. - Consequently, the LRN for a switch is always assigned out of a CO - code that is assigned to that switch. - - The LRN assigned to a switch currently serving a particular ported - telephone number is returned as the network routing address in the - NPDB response. The service portability scheme that was adopted in - the North America is very often referred to as the LRN scheme or - method. - - LRN serves as a network address for terminating calls served off - that switch using ported numbers. The LRN is assigned by the switch - operator using any of the unique CO codes (NPA+NXX) assigned to that - switch. The LRN is considered a non-dialable address, as the same - 10-digit number value may be assigned to a line on that switch. A - switch may have more than one LRN. - - During call routing/processing, a switch performs an NPDB query to - obtain the LRN associated with the dialed directory number. NPDB - queries are performed for all the dialed directory numbers whose - NPA+NXX codes are marked as portable NPA+NXX at that switch. When - formulating the ISUP Initial Address Message (IAM) to be sent to the - next switch, the switch puts the ten-digit LRN in the ISUP Called - Party Number (CdPN) parameter and the originally dialed directory - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 14] - -Number Portability in the GSTN: An Overview June 24, 2002 - - number in the ISUP Generic Address parameter (GAP). A new code in - the GAP was defined to indicate that the address information in the - GAP is the dialed directory number. A new bit in the ISUP Forward - Call Indicator (FCI) parameter, the Ported Number Translation - Indicator (PNTI) bit, is set to imply that NPDB query has already - been performed. All the switches in the downstream will not perform - the NPDB query if the PNTI bit is set. - - When the terminating switch receives the IAM and sees the PNTI bit - in the FCI parameter set and its own LRN in the CdPN parameter, it - retrieves the originally dialed directory number from the GAP and - uses the dialed directory number to terminate the call. - - A dialed directory number with a portable NPA+NXX does not imply - that directory number has been ported. The NPDBs currently do not - store records for non-ported directory numbers. In that case, the - NPDB will return the same dialed directory number instead of the - LRN. The switch will then set the PNTI bit but keep the dialed - directory number in the CdPN parameter. - - In the real world environment, the Originating Network is not always - the one that performs the NPDB query. For example, it is usually - the long distance carriers that query the NPDBs for long distance - calls. In that case, the Originating Network operated by the local - exchange carrier (LEC) simply routes the call to the long distance - carrier that is to handle that call. A wireless network acting as - the Originating Network can also route the call to the - interconnected local exchange carrier network if it does not want to - support the NPDB interface at its mobile switches. - - -6.2 Europe - - In some European countries, a routing number is prefixed to the - dialed directory number. The ISUP CdPN parameter in the IAM will - contain the routing prefix and the dialed directory number. For - example, United Kingdom uses routing prefixes with the format of - 5XXXXX and Italy uses C600XXXXX as the routing prefix. The networks - use the information in the ISUP CdPN parameter to route the call to - the New/Current Serving Network. - - The routing prefix can identify the Current Serving Network or the - Current Serving Switch of a ported number. For the former case, - another query to the "internal" NPDB at the Current Serving Network - is required to identify the Current Serving Switch before routing - the call to that switch. This shields the Current Serving Switch - information for a ported number from the other networks at the - expense of an additional NPDB query. Another routing number, may be - meaningful within the Current Serving Network, will replace the - previously prefixed routing number in the ISUP CdPN parameter. For - the latter case, the call is routed to the Current Serving Switch - without an additional NPDB query. - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 15] - -Number Portability in the GSTN: An Overview June 24, 2002 - - When the terminating switch receives the IAM and sees its own - routing prefix in the CdPN parameter, it retrieves the originally - dialed directory number after the routing prefix, and uses the - dialed directory number to terminate the call. - - The call routing example described above shows one of the three - methods that can be used to transport the Directory Number (DN) and - the Routing Number (RN) in the ISUP IAM message. In addition, some - other information may be added/modified as is listed in the ETSI 302 - 097 document [ETSIISUP], which is based on the ITU-T Recommendation - Q.769.1 [ITUISUP]. The three methods and the enhancements in the - ISUP to support number portability are briefly described below - - (a) Two separate parameters with the CdPN parameter containing the - RN and a new Called Directory Number (CdDN) parameter containing - the DN. A new value for the Nature of Address (NOA) indicator in - the CdPN parameter is defined to indicate that the RN is in the - CdPN parameter. The switches use the CdPN parameter to route the - call as is done today. - - (b) Two separate parameters with the CdPN parameter containing the - DN and a new Network Routing Number (NRN) parameter containing - the RN. This method requires that the switches use the NRN - parameter to route the call. - - (c) Concatenated parameter with the CdPN parameter containing the RN - plus the DN. A new Nature of Address (NOA) indicator in the CdPN - parameter is defined to indicate that the RN is concatenated with - the DN in the CdPN parameter. Some countries may not use new NOA - value because the routing prefix does not overlap with the dialed - directory numbers. But if the routing prefix overlaps with the - dialed directory numbers, a new NOA value must be assigned. For - example, Spain uses "XXXXXX" as the routing prefix to identify - the new serving network and uses a new NOA value of 126. - - There is also a network option to add a new ISUP parameter called - Number Portability Forwarding Information parameter. This parameter - has a four-bit Number Portability Status Indicator field that can - provide an indication whether number portability query is done for - the called directory number and whether the called directory number - is ported or not if the number portability query is done. - - Please note that all those NP enhancements for a ported number can - only be used in the country that defined them. This is because - number portability is supported within a nation. Within each - nation, the telecommunications industry or the regulatory bodies can - decide which method or methods to use. Number portability related - parameters and coding are usually not passed across the national - boundaries unless the interconnection agreements allow that. For - example, a UK routing prefix can only be used in UK, and would cause - routing problem if it appears outside UK. - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 16] - -Number Portability in the GSTN: An Overview June 24, 2002 - - As indicated earlier, an originating wireless network can query the - NPDB and concatenate the RN with DN in the CdPN parameter and route - the call directly to the Current Serving Network. - - If NPDBs do not contain information about the wireless directory - numbers, the call, originated from either a wireline or a wireless - network, will be routed to the Wireless donor network. Over there, - an internal NPDB is queried to retrieve the RN that then is - concatenated with the DN in the CdPN parameter. - - There are several ways of realizing MNP. When MNP-SRF is supported, - the Gateway Mobile Services Switching Center (GMSC) at the wireless - donor network, when receiving a call from the wireline network, can - send the GSM MAP Send Routing Information (SRI) message to the MNP- - SRF. The MNP-SRF interrogates an internal or integrated NPDB for - the RN of the MNP-SRF of the wireless Current Serving Network and - prefixes the RN to the dialed wireless directory number in the - global title address information in the SCCP Called Party Address - (CdPA) parameter. This SRI message will be routed to the MNP-SRF of - the wireless Current Serving Network, which then responds with an - acknowledgement by providing the RN plus the dialed wireless - directory number as the Mobile Station Roaming Number (MSRN). The - GMSC of the wireless donor network formulates the ISUP IAM with the - RN plus the dialed wireless directory number in the CdPN parameter - and routes the call to the wireless Current Serving Network. A GMSC - of the wireless Current Serving Network receives the call and sends - an SRI message to the associated MNP-SRF where the global title - address information of the SCCP CdPA parameter contains only the - dialed wireless directory number. The MNP-SRF then replaces the - global title address information in the SCCP CdPA parameter with the - address information associated with a Home Location Register (HLR) - that hosts the dialed wireless directory number and forwards the - message to that HLR after verifying that the dialed wireless - directory number is a ported-in number. The HLR then returns an - acknowledgement by providing an MSRN for the GMSC to route the call - to the MSC that currently serves the mobile station that is - associated with the dialed wireless directory number. Please see - [MNP] for details and additional scenarios. - - -7. NP Implementations for Geographic E.164 Numbers - - This section shows the known SPNP implementations worldwide. - - +-------------+----------------------------------------------------+ - + Country + SPNP Implementation + - +-------------+----------------------------------------------------+ - + Argentina + Analyzing operative viability now. Will determine + - + + whether portability should be made obligatory + - + + after a technical solution has been determined. + - +-------------+----------------------------------------------------+ - + Australia + NP supported by wireline operators since 11/30/99. + - + + NP among wireless operators in March/April 2000, + - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 17] - -Number Portability in the GSTN: An Overview June 24, 2002 - - + + but may be delayed to 1Q01. The access provider + - + + or long distance provider has the obligation to + - + + route the call to the correct destination. The + - + + donor network is obligated to maintain and make + - + + available a register of numbers ported away from + - + + its network. Telstra uses onward routing via an + - + + on-switch solution. + - +-------------+----------------------------------------------------+ - + Austria + Uses onward routing at the donor network. Routing + - + + prefix is "86xx" where "xx" identifies the + - + + recipient network. + - +-------------+----------------------------------------------------+ - + Belgium + ACQ selected by the industry. Routing prefix is + - + + "Cxxxx" where "xxxx" identifies the recipient + - + + switch. Another routing prefix is "C00xx" with "xx"+ - + + identifying the recipient network. Plan to use NOA+ - + + to identify concatenated numbers and abandon the + - + + hexadecimal routing prefix. + - +-------------+----------------------------------------------------+ - + Brazil + Considering NP for wireless users. + - +-------------+----------------------------------------------------+ - + Chile + There has been discussions lately on NP. + - +-------------+----------------------------------------------------+ - + Colombia + There was an Article 3.1 on NP to support NP prior + - + + to December 31, 1999 when NP became technically + - + + possible. Regulator has not yet issued regulations + - + + concerning this matter. + - +-------------+----------------------------------------------------+ - + Denmark + Uses ACQ. Routing number not passed between + - + + operators; however, NOA is set to "112" to + - + + indicate "ported number." QoR can be used based + - + + on bilateral agreements. + - +-------------+----------------------------------------------------+ - + Finland + Uses ACQ. Routing prefix is "1Dxxy" where "xxy" + - + + identifies the recipient network and service type. + - +-------------+----------------------------------------------------+ - + France + Uses onward routing. Routing prefix is "Z0xxx" + - + + where "xxx" identifies the recipient switch. + - +-------------+----------------------------------------------------+ - + Germany + The originating network needs to do necessary + - + + rerouting. Operators decide their own solution(s).+ - + + Deutsche Telekom uses ACQ. Routing prefix is + - + + "Dxxx" where "xxx" identifies the recipient + - + + network. + - +-------------+----------------------------------------------------+ - + Hong Kong + Recipient network informs other networks about + - + + ported-in numbers. Routing prefix is "14x" where + - + + "14x" identifies the recipient network, or a + - + + routing number of "4x" plus 7 or 8 digits is used + - + + where "4x" identifies the recipient network and + - + + the rest of digits identify the called party. + - +-------------+----------------------------------------------------+ - + Ireland + Operators choose their own solution but use onward + - + + routing now. Routing prefix is "1750" as the intra-+ - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 18] - -Number Portability in the GSTN: An Overview June 24, 2002 - - + + network routing code (network-specific) and + - + + "1752xxx" to "1759xxx" for GNP where "xxx" + - + + identifies the recipient switch. + - +-------------+----------------------------------------------------+ - + Italy + Uses onward routing. Routing prefix is "C600xxxxx" + - + + where "xxxxx" identifies the recipient switch. + - + + Telecom Italia uses IN solution and other operators+ - + + use on-switch solution. + - +-------------+----------------------------------------------------+ - + Japan + Uses onward routing. Donor switch uses IN to get + - + + routing number. + - +-------------+----------------------------------------------------+ - + Mexico + NP is considered in the Telecom law; however, the + - + + regulator (Cofetel) or the new local entrants have + - + + started no initiatives on this process. + - +-------------+----------------------------------------------------+ - + Netherlands + Operators decide NP scheme to use. Operators have + - + + chosen ACQ or QoR. KPN implemented IN solution + - + + similar to U.S. solution. Routing prefix is not + - + + passed between operators. + - +-------------+----------------------------------------------------+ - + Norway + OR for short-term and ACQ for long-term. QoR is + - + + optional. Routing prefix can be "xxx" with NOA=8, + - + + or "142xx" with NOA=3 where "xxx" or "xx" + - + + identifies the recipient network. + - +------------ +----------------------------------------------------+ - + Peru + Wireline NP may be supported in 2001. + - +-------------+----------------------------------------------------+ - + Portugal + No NP today. + - +-------------+----------------------------------------------------+ - + Spain + Uses ACQ. Telefonica uses QoR within its network. + - + + Routing prefix is "xxyyzz" where "xxyyzz" + - + + identifies the recipient network. NOA is set to + - + + 126. + - +-------------+----------------------------------------------------+ - + Sweden + Standardized the ACQ but OR for operators without + - + + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + - + + with NOA=3 where "xxx" identifies the recipient + - + + network. But operators decide NP scheme to use. + - + + Telia uses onward routing between operators. + - +-------------+----------------------------------------------------+ - + Switzerland + Uses OR now and QoR in 2001. Routing prefix is + - + + "980xxx" where "xxx" identifies the recipient + - + + network. + - +-------------+----------------------------------------------------+ - + UK + Uses onward routing. Routing prefix is "5xxxxx" + - + + where "xxxxx" identifies the recipient switch. NOA + - + + is 126. BT uses the dropback scheme in some parts + - + + of its network. + - +-------------+----------------------------------------------------+ - + US + Uses ACQ. "Location Routing Number (LRN)" is used + - + + in the Called Party Number parameter. Called party+ - + + number is carried in the Generic Address Parameter + - + + Use a PNTI indicator in the Forward Call Indicator + - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 19] - -Number Portability in the GSTN: An Overview June 24, 2002 - - + + parameter to indicate that NPDB dip has been + - + + performed. + - +-------------+----------------------------------------------------+ - - -8. Number Conservation Methods Enabled by NP - - In addition to porting numbers NP provides the ability for number - administrators to assign numbering resources to operators in smaller - increments. Today it is common for numbering resources to be - assigned to telephone operators in a large block of consecutive - telephone numbers (TNs). For example, in North America each of - these blocks contains 10,000 TNs and is of the format NXX+0000 to - NXX+9999. Operators are assigned a specific NXX, or block. That - operator is referred to as the block holder. In that block there - are 10,000 TNs with line numbers ranging from 0000 to 9999. - - Instead of assigning an entire block to the operator NP allows the - administrator to assign a sub-block or even an individual telephone - number. This is referred to as block pooling and individual - telephone number (ITN) pooling, respectively. - - -8.1 Block Pooling - - Block Pooling refers to the process whereby the number administrator - assigns a range of numbers defined by a logical sub-block of the - existing block. Using North America as an example, block pooling - would allow the administrator to assign sub-blocks of 1,000 TNs to - multiple operators. That is, NXX+0000 to NXX+0999 can be assigned - to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, - NXX-2000 to 2999 can be assigned to operator C, etc. In this - example block pooling divides one block of 10,000 TNs into ten - blocks of 1,000 TNs. - - Porting the sub-blocks from the block holder enables block pooling. - Using the example above operator A is the block holder, as well as, - the holder of the first sub-block, NXX+0000 to NXX+0999. The second - sub-block, NXX+1000 to NXX+1999, is ported from operator A to - operator B. The third sub-block, NXX+2000 to NXX+2999, is ported - from operator A to operator C, and so on. NP administrative - processes and call processing will enable proper and efficient - routing. - - From a number administration and NP administration perspective block - pooling introduces a new concept, that of the sub-block holder. - Block pooling requires coordination between the number - administrator, the NP administrator, the block holder, and the sub- - block holder. Block pooling must be implemented in a manner that - allows for NP within the sub-blocks. Each TN can have a different - serving operator, sub-block holder, and block holder. - - - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 20] - -Number Portability in the GSTN: An Overview June 24, 2002 - -8.2 ITN Pooling - - ITN pooling refers to the process whereby the number administrator - assigns individual telephone numbers to operators. Using the North - American example, one block of 10,000 TNs can be divided into 10,000 - ITNs. ITN is more commonly deployed in freephone services. - - In ITN the block is not assigned to an operator but to a central - administrator. The administrator then assigns ITNs to operators. - NP administrative processes and call processing will enable proper - and efficient routing. - - -9. Potential Implications - - There are three general areas of impact to IP telephony work-in- - progress at IETF: - - - Interoperation between NP in GSTN and IP telephony - - NP implementation or emulation in IP telephony - - Interconnection to NP administrative environment - - A good understanding of how number portability is supported in the - GSTN is important when addressing the interworking issues between - IP-based networks and the GSTN. This is especially important when - the IP-based network needs to route the calls to the GSTN. As shown - in Section 5, there are a variety of standards with various protocol - stacks for the switch-to-NPDB interface. Not only that, the - national variations of the protocol standards make it very - complicated to deal with in a global environment. If an entity in - the IP-based network needs to query those existing NPDBs for routing - number information to terminate the calls to the destination GSTN, - it would be impractical, if not an impossible, job for that entity - to support all those interface standards to access the NPDBs in many - countries. - - Several alternatives may address this particular problem. One - alternative is to use certain entities in the IP-based networks for - dealing with NP query, similar to the International Switches that - are used in the GSTN to interwork different national ISUP - variations. This will force signaling information associated with - the calls to certain NP-capable networks in the terminating GSTN to - be routed to those IP entities that support the NP functions. Those - IP entities then query the NPDBs in the terminating country. This - will limit the number of NPDB interfaces that certain IP entities - need to support. Another alternative can be to define a "common" - interface to be supported by all the NPDBs so that all the IP - entities use that standardized protocol to query them. The - existing NPDBs can support this additional interface, or new NPDBs - can be deployed that contain the same information but support the - common IP interface. The candidates for such a common interface - include Lightweight Directory Access Protocol (LDAP) and SIP - [SIP](e.g., using the SIP redirection capability). Certainly - - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 21] - -Number Portability in the GSTN: An Overview June 24, 2002 - - another possibility is to use interworking function to convert from - one protocol to another. - - IP-based networks can handle the domestic calls between two GSTNs. - If the originating GSTN has performed NPDB query, SIP will need to - transport and make use of some of the ISUP signaling information - even if ISUP signaling may be encapsulated in SIP. Also, IP-based - networks may perform the NPDB queries, as the N-1 carrier. In that - case, SIP also needs to transport the NP related information while - the call is being routed to the destination GSTN. There are three - pieces of NP related information that SIP needs to transport. They - are 1) the called directory number, 2) a routing number, and 3) a - NPDB dip indicator. The NPDB dip indicator is needed so that the - terminating GSTN will not perform another NPDB dip. The routing - number is needed so that it is used to route the call to the - destination network or switch in the destination GSTN. The called - directory number is needed so that the terminating GSTN switch can - terminate the call. When the routing number is present, the NPDB - dip indicator may not be present because there are cases where - routing number is added for routing the call even if NP is not - involved. One issue is how to transport the NP related information - via SIP. The SIP Universal Resource Locator (URL) is one mechanism. - Another better choice may be to add an extension to the "tel" URL - [TEL] that is also supported by SIP. Please see [TELNP] for the - proposed extensions to the "tel" URL to support NP and freephone - service. Those extensions to the "tel" URL will be automatically - supported by SIP because they can be carried as the optional - parameters in the user portion of the "sip" URL. - - For a called directory number that belongs to a country that - supports NP, and if the IP-based network is to perform the NPDB - query, the logical step is to perform the NPDB dip first to retrieve - the routing number and use that routing number to select the correct - IP telephony gateways that can reach the serving switch that serves - the called directory number. Therefore, if the "rn" parameter is - present in the "tel" URL or sip URL in the SIP INVITE message, it - instead of the called directory number should be used for making - routing decisions assuming that no other higher priority routing- - related parameters such as the cic are present. If "rn" is not - present, then the dialed directory number can be used as the routing - number for making routing decisions. - - Telephony Routing Information Protocol (TRIP) [TRIP] is a policy - driven inter-administrative domain protocol for advertising the - reachability of telephony destinations between location servers, and - for advertising attributes of the routes to those destinations. - With the NP in mind, it is very important to know that it is the - routing number, if present, not the called directory number that - should be used to check against the TRIP tables for making the - routing decisions. - - Overlap signaling exists in the GSTN today. For a call routing from - the originating GSTN to the IP-based network that involves overlap - signaling, NP will impact the call processing within the IP-based - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 22] - -Number Portability in the GSTN: An Overview June 24, 2002 - - networks if they must deal with the overlap signaling. The entities - in the IP-based networks that are to retrieve the NP information - (e.g., the routing number) must collect a complete called directory - number information before retrieving the NP information for a ported - number. Otherwise, the information retrieval won't be successful. - This is an issue for the IP-based networks if the originating GSTN - does not handle the overlap signaling by collecting the complete - called directory number. - - The IETF enum working group is defining the use of Domain Name - System (DNS) for identifying available services associated with a - particular E.164 number [ENUM]. [ENUMPO] outlines the principles - for the operation of a telephone number service that resolves - telephone numbers into Internet domain name addresses and service- - specific directory discovery. [ENUMPO] implements a three-level - approach where the first level is the mapping of the telephone - number delegation tree to the authority to which the number has been - delegated, the second level is the provision of the requested DNS - resource records from a service registrar, and the third level is - the provision of service specific data from the service provider - itself. NP certainly must be considered at the first level because - the telephony service providers do not "own" or control the - telephone numbers under the NP environment; therefore, they may not - be the proper entities to have the authority for a given E.164 - number. Not only that, there is a regulatory requirement on NP in - some countries that the donor network should not be relied on to - reach the delegated authority during the DNS process . The - delegated authority for a given E.164 number is likely to be an - entity designated by the end user that owns/controls a specific - telephone number or one that is designated by the service registrar. - - Since the telephony service providers may have the need to use ENUM - for their network-related services (e.g., map an E.164 number to a - HLR Identifier in the wireless networks), their ENUM records must be - collocated with those of the telephony subscribers. If that is the - case, NP will impact ENUM when a telephony subscriber who has ENUM - service changes the telephony service provider. This is because - that the ENUM records from the new telephony service provider must - replace those from the old telephony service provider. To avoid the - NP impact on ENUM, it is recommended that the telephony service - providers use a different domain tree for their network-related - service. For example, if e164.arpa is chosen for end user ENUM, a - domain tree different from e164.arpa should be used for carrier - ENUM. - - The IP-based networks also may need to support some forms of number - portability in the future if E.164 numbers [E164] are assigned to - the IP-based end users. One method is to assign a GSTN routing - number for each IP-based network domain or entity in a NP-capable - country. This may increase the number of digits in the routing - number to incorporate the IP entities and impact the existing - routing in the GSTN. Another method is to associate each IP entity - with a particular GSTN gateway. At that particular GSTN gateway, - the called directory number then is used to locate the IP-entity - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 23] - -Number Portability in the GSTN: An Overview June 24, 2002 - - that serves that dialed directory number. Yet, another method can - be to assign a special routing number so that the call to an end - user currently served by an IP entity is routed to the nearest GSTN - gateway. The called directory number then is used to locate the IP- - entity that serves that dialed directory number. A mechanism can be - developed or used for the IP-based network to locate the IP entity - that serves a particular dialed directory number. Many other types - of networks use E.164 numbers to identify the end users or terminals - in those networks. Number portability among GSTN, IP-based network - and those various types of networks may also need to be supported in - the future. - - -10. Security Considerations - - This document does not raise any security issues. - - -11. IANA Considerations - - This document introduces no new values for IANA registration. - - -12. Normative References - - [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability - - Operator Services Switching Systems," April 1999. - - [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability - - Switching Systems," April 1999. - - [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability - Database and Global Title Translation," April 1999. - - [CS1] ITU-T Q-series Recommendations - Supplement 4, "Number - portability Capability set 1 requirements for service provider - portability (All call query and onward routing)," May 1998. - - [CS2] ITU-T Q-series Recommendations - Supplement 5, "Number - portability -Capability set 2 requirements for service provider - portability (Query on release and Dropback)," March 1999. - - [E164] ITU-T Recommendation E.164, "The International Public - Telecommunications Numbering Plan," 1997. - - [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. - - [ETSIISUP] ETSI EN 302 097 V.1.2.2, Integrated Services Digital - Network (ISDN); Signalling System No.7 (SS7); ISDN User Part - (ISUP); Enhancement for support of Number Portability (NP) - [ITU-T Recommendation Q.769.1 (2000), modified] - - [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase - 2+); Mobile Application Part (MAP) specification". - -Foster,McGarry,Yu Expired on December 23, 2002 [Page 24] - -Number Portability in the GSTN: An Overview March 1, 2002 - - - - [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for - Wireless Number Portability Phase II (December 1998)"Number - Portability Network Support," April 1998. - - [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - - ISDN User Part Enhancements for the Support of Number - Portability," December 1999. - - [MNP] ETSI EN 301 716 (2000-10) European Standard - (Telecommunications series) Digital cellular telecommunications - system (Phase 2+); Support of Mobile Number Portability (MNP); - Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 - Release 1998). - - [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- - Revision 3," October 1996. - - -13. Informative References - - [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific - Provisioning: Principles of Operations," draft-ietf-enum- - operation-02.txt, February 23, 2001. - - [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: - Session Initiation Protocol," February 27, 2002. - - [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis- - 04.txt, "URIs for Telephone Calls," May 24, 2002. - - [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL - to support Number Portability and Freephone Service," June 14, - 2002. - - [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony - Routing Information Protocol (TRIP)," January 2002. - - -14. Acknowledgment - - The authors would like to thank Monika Muench for providing - information on ISUP and MNP. - - -15. Authors' Addresses - - Mark D. Foster - NeuStar, Inc. - 1120 Vermont Avenue, NW, - Suite 400 - Washington, D.C. 20005 - United States - -Foster,McGarry,Yu Expired on August 31, 2002 [Page 25] - -Number Portability in the GSTN: An Overview March 1, 2002 - - - - Phone: +1-202-533-2800 - Fax: +1-202-533-2987 - Email: mark.foster@neustar.biz - - Tom McGarry - NeuStar, Inc. - 1120 Vermont Avenue, NW, - Suite 400 - Washington, D.C. 20005 - United States - - Phone: +1-202-533-2810 - Fax: +1-202-533-2987 - Email: tom.mcgarry@neustar.biz - - James Yu - NeuStar, Inc. - 1120 Vermont Avenue, NW, - Suite 400 - Washington, D.C. 20005 - United States - - Phone: +1-202-533-2814 - Fax: +1-202-533-2987 - Email: james.yu@neustar.biz - - - -Full Copyright Statement - - "Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - - -Foster,McGarry,Yu Expired on August 31, 2002 [Page 26] - -Number Portability in the GSTN: An Overview March 1, 2002 - - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Foster,McGarry,Yu Expired on August 31, 2002 [Page 27] - \ No newline at end of file diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt deleted file mode 100644 index 2d5c87eb3c..0000000000 --- a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt +++ /dev/null @@ -1,1200 +0,0 @@ - - - - - - -IPv6 Working Group John Loughney (ed) -Internet-Draft Nokia - January 14, 2004 - -Expires: July 14, 2004 - - - - IPv6 Node Requirements - draft-ietf-ipv6-node-requirements-08.txt - - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document defines requirements for IPv6 nodes. It is expected - that IPv6 will be deployed in a wide range of devices and situations. - Specifying the requirements for IPv6 nodes allows IPv6 to function - well and interoperate in a large number of situations and - deployments. - - - - - -Loughney (editor) February 16, 2004 [Page 1] - - - - - -Internet-Draft - - -Table of Contents - - 1. Introduction - 1.1 Requirement Language - 1.2 Scope of this Document - 1.3 Description of IPv6 Nodes - 2. Abbreviations Used in This Document - 3. Sub-IP Layer - 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 - 3.2 IP version 6 over PPP - RFC2472 - 3.3 IPv6 over ATM Networks - RFC2492 - 4. IP Layer - 4.1 Internet Protocol Version 6 - RFC2460 - 4.2 Neighbor Discovery for IPv6 - RFC2461 - 4.3 Path MTU Discovery & Packet Size - 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 - 4.5 Addressing - 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 - 5. Transport and DNS - 5.1 Transport Layer - 5.2 DNS - 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - 6. IPv4 Support and Transition - 6.1 Transition Mechanisms - 7. Mobility - 8. Security - 8.1 Basic Architecture - 8.2 Security Protocols - 8.3 Transforms and Algorithms - 8.4 Key Management Methods - 9. Router Functionality - 9.1 General - 10. Network Management - 10.1 MIBs - 11. Security Considerations - 12. References - 12.1 Normative - 12.2 Non-Normative - 13. Authors and Acknowledgements - 14. Editor's Address - Notices - - - - - - - - - - -Loughney (editor) February 16, 2004 [Page 2] - - - - - -Internet-Draft - - -1. Introduction - - The goal of this document is to define the common functionality - required from both IPv6 hosts and routers. Many IPv6 nodes will - implement optional or additional features, but all IPv6 nodes can be - expected to implement the mandatory requirements listed in this - document. - - This document tries to avoid discussion of protocol details, and - references RFCs for this purpose. In case of any conflicting text, - this document takes less precedence than the normative RFCs, unless - additional clarifying text is included in this document. - - Although the document points to different specifications, it should - be noted that in most cases, the granularity of requirements are - smaller than a single specification, as many specifications define - multiple, independent pieces, some of which may not be mandatory. - - As it is not always possible for an implementer to know the exact - usage of IPv6 in a node, an overriding requirement for IPv6 nodes is - that they should adhere to Jon Postel's Robustness Principle: - - Be conservative in what you do, be liberal in what you accept from - others [RFC-793]. - -1.1 Requirement Language - - 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 RFC 2119 [RFC-2119]. - -1.2 Scope of this Document - - IPv6 covers many specifications. It is intended that IPv6 will be - deployed in many different situations and environments. Therefore, - it is important to develop the requirements for IPv6 nodes, in order - to ensure interoperability. - - This document assumes that all IPv6 nodes meet the minimum - requirements specified here. - -1.3 Description of IPv6 Nodes - - From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we - have the following definitions: - - Description of an IPv6 Node - - - - -Loughney (editor) February 16, 2004 [Page 3] - - - - - -Internet-Draft - - - - a device that implements IPv6 - - Description of an IPv6 router - - - a node that forwards IPv6 packets not explicitly addressed to - itself. - - Description of an IPv6 Host - - - any node that is not a router. - -2. Abbreviations Used in This Document - - ATM Asynchronous Transfer Mode - - AH Authentication Header - - DAD Duplicate Address Detection - - ESP Encapsulating Security Payload - - ICMP Internet Control Message Protocol - - IKE Internet Key Exchange - - MIB Management Information Base - - MLD Multicast Listener Discovery - - MTU Maximum Transfer Unit - - NA Neighbor Advertisement - - NBMA Non-Broadcast Multiple Access - - ND Neighbor Discovery - - NS Neighbor Solicitation - - NUD Neighbor Unreachability Detection - - PPP Point-to-Point Protocol - - PVC Permanent Virtual Circuit - - SVC Switched Virtual Circuit - -3. Sub-IP Layer - - - -Loughney (editor) February 16, 2004 [Page 4] - - - - - -Internet-Draft - - - An IPv6 node must include support for one or more IPv6 link-layer - specifications. Which link-layer specifications are included will - depend upon what link-layers are supported by the hardware available - on the system. It is possible for a conformant IPv6 node to support - IPv6 on some of its interfaces and not on others. - - As IPv6 is run over new layer 2 technologies, it is expected that new - specifications will be issued. This section highlights some major - layer 2 technologies and is not intended to be complete. - -3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 - - Nodes supporting IPv6 over Ethernet interfaces MUST implement - Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. - -3.2 IP version 6 over PPP - RFC2472 - - Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- - 2472]. - -3.3 IPv6 over ATM Networks - RFC2492 - - Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM - Networks [RFC-2492]. Additionally, RFC 2492 states: - - A minimally conforming IPv6/ATM driver SHALL support the PVC mode - of operation. An IPv6/ATM driver that supports the full SVC mode - SHALL also support PVC mode of operation. - -4. IP Layer - -4.1 Internet Protocol Version 6 - RFC2460 - - The Internet Protocol Version 6 is specified in [RFC-2460]. This - specification MUST be supported. - - Unrecognized options in Hop-by-Hop Options or Destination Options - extensions MUST be processed as described in RFC 2460. - - The node MUST follow the packet transmission rules in RFC 2460. - - Nodes MUST always be able to send, receive and process fragment - headers. All conformant IPv6 implementations MUST be capable of - sending and receving IPv6 packets; forwarding functionality MAY be - supported - - RFC 2460 specifies extension headers and the processing for these - headers. - - - -Loughney (editor) February 16, 2004 [Page 5] - - - - - -Internet-Draft - - - A full implementation of IPv6 includes implementation of the - following extension headers: Hop-by-Hop Options, Routing (Type 0), - Fragment, Destination Options, Authentication and Encapsulating - Security Payload. [RFC-2460] - - An IPv6 node MUST be able to process these headers. It should be - noted that there is some discussion about the use of Routing Headers - and possible security threats [IPv6-RH] caused by them. - -4.2 Neighbor Discovery for IPv6 - RFC2461 - - Neighbor Discovery SHOULD be supported. RFC 2461 states: - - "Unless specified otherwise (in a document that covers operating - IP over a particular link type) this document applies to all link - types. However, because ND uses link-layer multicast for some of - its services, it is possible that on some link types (e.g., NBMA - links) alternative protocols or mechanisms to implement those - services will be specified (in the appropriate document covering - the operation of IP over a particular link type). The services - described in this document that are not directly dependent on - multicast, such as Redirects, Next-hop determination, Neighbor - Unreachability Detection, etc., are expected to be provided as - specified in this document. The details of how one uses ND on - NBMA links is an area for further study." - - Some detailed analysis of Neighbor Discovery follows: - - Router Discovery is how hosts locate routers that reside on an - attached link. Router Discovery MUST be supported for - implementations. - - Prefix Discovery is how hosts discover the set of address prefixes - that define which destinations are on-link for an attached link. - Prefix discovery MUST be supported for implementations. Neighbor - Unreachability Detection (NUD) MUST be supported for all paths - between hosts and neighboring nodes. It is not required for paths - between routers. However, when a node receives a unicast Neighbor - Solicitation (NS) message (that may be a NUD's NS), the node MUST - respond to it (i.e. send a unicast Neighbor Advertisement). - - Duplicate Address Detection MUST be supported on all links supporting - link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take - place on all unicast addresses). - - A host implementation MUST support sending Router Solicitations. - - Receiving and processing Router Advertisements MUST be supported for - - - -Loughney (editor) February 16, 2004 [Page 6] - - - - - -Internet-Draft - - - host implementations. The ability to understand specific Router - Advertisement options is dependent on supporting the specification - where the RA is specified. - - Sending and Receiving Neighbor Solicitation (NS) and Neighbor - Advertisement (NA) MUST be supported. NS and NA messages are required - for Duplicate Address Detection (DAD). - - Redirect functionality SHOULD be supported. If the node is a router, - Redirect functionality MUST be supported. - -4.3 Path MTU Discovery & Packet Size - -4.3.1 Path MTU Discovery - RFC1981 - - Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal - implementations MAY choose to not support it and avoid large packets. - The rules in RFC 2460 MUST be followed for packet fragmentation and - reassembly. - -4.3.2 IPv6 Jumbograms - RFC2675 - - IPv6 Jumbograms [RFC-2675] MAY be supported. - -4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 - - ICMPv6 [RFC-2463] MUST be supported. - -4.5 Addressing - -4.5.1 IP Version 6 Addressing Architecture - RFC3513 - - The IPv6 Addressing Architecture [RFC-3513] MUST be supported. - -4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 - - IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. - This specification MUST be supported for nodes that are hosts. - - Nodes that are routers MUST be able to generate link local addresses - as described in RFC 2462 [RFC-2462]. - - From 2462: - - The autoconfiguration process specified in this document applies - only to hosts and not routers. Since host autoconfiguration uses - information advertised by routers, routers will need to be - configured by some other means. However, it is expected that - - - -Loughney (editor) February 16, 2004 [Page 7] - - - - - -Internet-Draft - - - routers will generate link-local addresses using the mechanism - described in this document. In addition, routers are expected to - successfully pass the Duplicate Address Detection procedure - described in this document on all addresses prior to assigning - them to an interface. - - Duplicate Address Detection (DAD) MUST be supported. - -4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 - - Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] - SHOULD be supported. It is recommended that this behavior be - configurable on a connection basis within each application when - available. It is noted that a number of applications do not work - with addresses generated with this method, while other applications - work quite well with them. - -4.5.4 Default Address Selection for IPv6 - RFC3484 - - The rules specified in the Default Address Selection for IPv6 [RFC- - 3484] document MUST be implemented. It is expected that IPv6 nodes - will need to deal with multiple addresses. - -4.5.5 Stateful Address Autoconfiguration - - Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- - 3315] is the standard stateful address configuration protocol; see - section 5.3 for DHCPv6 support. - - Nodes which do not support Stateful Address Autoconfiguration may be - unable to obtain any IPv6 addresses aside from link-local addresses - when it receives a router advertisement with the 'M' flag (Managed - address configuration) set and which contains no prefixes advertised - for Stateless Address Autoconfiguration (see section 4.5.2). - Additionally, such nodes will be unable to obtain other configuration - information such as the addresses of DNS servers when it is connected - to a link over which the node receives a router advertisement in - which the 'O' flag ("Other stateful configuration") is set. - -4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 - - Nodes that need to join multicast groups SHOULD implement MLDv2 - [MLDv2]. However, if the node has applications, which only need - support for Any- Source Multicast [RFC3569], the node MAY implement - MLDv1 [MLDv1] instead. If the node has applications, which need - support for Source- Specific Multicast [RFC3569, SSMARCH], the node - MUST support MLDv2 [MLDv2]. - - - - -Loughney (editor) February 16, 2004 [Page 8] - - - - - -Internet-Draft - - - When MLD is used, the rules in "Source Address Selection for the - Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be - followed. - -5. Transport Layer and DNS - -5.1 Transport Layer - -5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 - - This specification MUST be supported if jumbograms are implemented - [RFC- 2675]. - -5.2 DNS - - DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] - and [RFC-3596] MAY be supported. Not all nodes will need to resolve - names. All nodes that need to resolve names SHOULD implement stub- - resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with - support for: - - - AAAA type Resource Records [RFC-3596]; - - reverse addressing in ip6.arpa using PTR records [RFC-3152]; - - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 - octets. - - Those nodes are RECOMMENDED to support DNS security extentions - [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. - - Those nodes are NOT RECOMMENDED to support the experimental A6 and - DNAME Resource Records [RFC-3363]. - -5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 - - RFC 2732 MUST be supported if applications on the node use URL's. - -5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 - -5.3.1 Managed Address Configuration - - Those IPv6 Nodes that use DHCP for address assignment initiate DHCP - to obtain IPv6 addresses and other configuration information upon - receipt of a Router Advertisement with the 'M' flag set, as described - in section 5.5.3 of RFC 2462. In addition, in the absence of a - router, those IPv6 Nodes that use DHCP for address assignment MUST - initiate DHCP to obtain IPv6 addresses and other configuration - information, as described in section 5.5.2 of RFC 2462. Those IPv6 - nodes that do not use DHCP for address assignment can ignore the 'M' - - - -Loughney (editor) February 16, 2004 [Page 9] - - - - - -Internet-Draft - - - flag in Router Advertisements. - -5.3.2 Other Configuration Information - - Those IPv6 Nodes that use DHCP to obtain other configuration - information initiate DHCP for other configuration information upon - receipt of a Router Advertisement with the 'O' flag set, as described - in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP - for other configuration information can ignore the 'O' flag in Router - Advertisements. - - An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to - obtain other configuration information. - -6. IPv4 Support and Transition - - IPv6 nodes MAY support IPv4. - -6.1 Transition Mechanisms - -6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 - - If an IPv6 node implements dual stack and tunneling, then RFC2893 - MUST be supported. - - RFC 2893 is currently being updated. - -7. Mobile IP - - The Mobile IPv6 [MIPv6] specification defines requirements for the - following types of nodes: - - - mobile nodes - - correspondent nodes with support for route optimization - - home agents - - all IPv6 routers - - Hosts MAY support mobile node functionality described in Section 8.5 - of [MIPv6], including support of generic packet tunneling [RFC-2473] - and secure home agent communications [MIPv6-HASEC]. - - Hosts SHOULD support route optimization requirements for - correspondent nodes described in Section 8.2 of [MIPv6]. - - Routers SHOULD support the generic mobility-related requirements for - all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY - support the home agent functionality described in Section 8.4 of - [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. - - - -Loughney (editor) February 16, 2004 [Page 10] - - - - - -Internet-Draft - - -8. Security - - This section describes the specification of IPsec for the IPv6 node. - -8.1 Basic Architecture - - Security Architecture for the Internet Protocol [RFC-2401] MUST be - supported. RFC-2401 is being updated by the IPsec Working Group. - -8.2 Security Protocols - - ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. - RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group. - - -8.3 Transforms and Algorithms - - Current IPsec RFCs specify the support of certain transforms and - algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. - The requirements for these are discussed first, and then additional - algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed. - - NULL encryption algorithm [RFC-2410] MUST be supported for providing - integrity service and also for debugging use. - - The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD - NOT be supported. Security issues related to the use of DES are - discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as - required by the existing IPsec RFCs, but as it is currently viewed as - an inherently weak algorithm, and no longer fulfills its intended - role. - - The NULL authentication algorithm [RFC-2406] MUST be supported within - ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- - 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP, - described in [RFC-2403] MUST be supported. An implementer MUST refer - to Keyed- Hashing for Message Authentication [RFC-2104]. - - 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC - and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES- - CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected - to be a widely available, secure algorithm that is required for - interoperability. It is not required by the current IPsec RFCs, but - is expected to become required in the future. - - In addition to the above requirements, "Cryptographic Algorithm - Implementation Requirements For ESP And AH" [CRYPTREQ] contains the - current set of mandatory to implement algorithms for ESP and AH as - - - -Loughney (editor) February 16, 2004 [Page 11] - - - - - -Internet-Draft - - - well as specifying algorithms that should be implemented because they - may be promoted to mandatory at some future time. It is RECOMMENDED - that IPv6 nodes conform to the requirements in this document. - -8.4 Key Management Methods - - Manual keying MUST be supported. - - IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast - traffic. Where key refresh, anti-replay features of AH and ESP, or - on- demand creation of Security Associations (SAs) is required, - automated keying MUST be supported. Note that the IPsec WG is working - on the successor to IKE [IKE2]. Key management methods for multicast - traffic are also being worked on by the MSEC WG. - - "Cryptographic Algorithms for use in the Internet Key Exchange - Version 2" [IKEv2ALGO] defines the current set of mandatory to - implement algorithms for use of IKEv2 as well as specifying - algorithms that should be implemented because they made be promoted - to mandatory at some future time. It is RECOMMENDED that IPv6 nodes - implementing IKEv2 conform to the requirements in this - document. - -9. Router-Specific Functionality - - This section defines general host considerations for IPv6 nodes that - act as routers. Currently, this section does not discuss routing- - specific requirements. - -9.1 General - -9.1.1 IPv6 Router Alert Option - RFC2711 - - - The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- - Hop Header that is used in conjunction with some protocols (e.g., - RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will - need to be implemented whenever protocols that mandate its usage are - implemented. See Section 4.6. - -9.1.2 Neighbor Discovery for IPv6 - RFC2461 - - Sending Router Advertisements and processing Router Solicitation MUST - be supported. - -10. Network Management - - Network Management MAY be supported by IPv6 nodes. However, for IPv6 - - - -Loughney (editor) February 16, 2004 [Page 12] - - - - - -Internet-Draft - - - nodes that are embedded devices, network management may be the only - possibility to control these nodes. - -10.1 Management Information Base Modules (MIBs) - - The following two MIBs SHOULD be supported by nodes that support an - SNMP agent. - -10.1.1 IP Forwarding Table MIB - - IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes - that support an SNMP agent. - -10.1.2 Management Information Base for the Internet Protocol (IP) - - IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an - SNMP agent. - -11. Security Considerations - - This draft does not affect the security of the Internet, but - implementations of IPv6 are expected to support a minimum set of - security features to ensure security on the Internet. "IP Security - Document Roadmap" [RFC-2411] is important for everyone to read. - - The security considerations in RFC2460 describe the following: - - The security features of IPv6 are described in the Security - Architecture for the Internet Protocol [RFC-2401]. - -12. References - -12.1 Normative - - [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- - tion Requirements For ESP And AH", draft-ietf-ipsec- - esp-ah-algorithms-01.txt, January 2004. - - [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the - Internet Key Exchange Version 2", draft-ietf-ipsec- - ikev2-algorithms-04.txt, Work in Progress. - - [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 - Service", draft- ietf-dhc-dhcpv6-stateless-00.txt, - Work in Progress. - - [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support - in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in - - - -Loughney (editor) February 16, 2004 [Page 13] - - - - - -Internet-Draft - - - progress. - - [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec - to Protect Mobile IPv6 Signaling between Mobile Nodes - and Home Agents", draft-ietf- mobileip-mipv6-ha- - ipsec-06.txt, Work in Progress. - - [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version - 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in - Progress. - - [RFC-1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU - Discovery for IP version 6", RFC 1981, August 1996. - - [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table - MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in - Progress. - - [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the - Internet Protocol (IP)", draft-ietf-ipv6-rfc2011- - update-07.txt, Work in progress. - - [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: - Keyed-Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for - the Internet Protocol", RFC 2401, November 1998. - - [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication - Header", RFC 2402, November 1998. - - [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within - ESP and AH", RFC 2403, November 1998. - - [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 - within ESP and AH", RFC 2404, November 1998. - - [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher - Algorithm With Explicit IV", RFC 2405, November 1998. - - [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security - - - -Loughney (editor) February 16, 2004 [Page 14] - - - - - -Internet-Draft - - - Protocol (ESP)", RFC 2406, November 1998. - - [RFC-2407] Piper, D., "The Internet IP Security Domain of - Interpretation for ISAKMP", RFC 2407, November 1998. - - [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner, - J., "Internet Security Association and Key Management - Protocol (ISAKMP)", RFC 2408, November 1998. - - [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key - Exchange (IKE)", RFC 2409, November 1998. - - [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm - and Its Use With IPsec", RFC 2410, November 1998. - - [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- - sion 6 (IPv6) Specification", RFC 2460, December 1998. - - [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor - Discovery for IP Version 6 (IPv6)", RFC 2461, December - 1998. - - [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address - Autoconfiguration", RFC 2462. - - [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro- - tocol Version 6 (IPv6)", RFC 2463, December 1998. - - [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC - 2472, December 1998. - - [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling - in IPv6 Specification", RFC 2473, December 1998. Xxx - add - - [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast - Listener Discovery (MLD) for IPv6", RFC 2710, October - 1999. - - [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert - Option", RFC 2711, October 1999. - - - - -Loughney (editor) February 16, 2004 [Page 15] - - - - - -Internet-Draft - - - [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC - 3041, January 2001. - - [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August - 2001. - - [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol - for IPv6 (DHCPv6)", RFC 3315, July 2003. - - [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver- - sion 6 (IPv6) Addresses in the Domain Name System - (DNS)", RFC 3363, August 2002. - - [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC - 3484, February 2003. - - [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing - Architecture", RFC 3513, April 2003. - - [RFC-3590] Haberman, B., "Source Address Selection for the Multi- - cast Listener Discovery (MLD) Protocol", RFC 3590, - September 2003. - - [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP - version 6", RFC 3596, October 2003. - - [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use - with IPsec", RFC 3602, September 2003. - -12.2 Non-Normative - - [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", - draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in - Progress. - - [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of - DES-like cryptosystems", Journal of Cryptology Vol 4, Jan - 1991. - - [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. - - [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without - Strong Integrity", Proceedings of the 32nd IETF, Danvers, - MA, April 1995. - - [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser- - vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in - - - -Loughney (editor) February 16, 2004 [Page 16] - - - - - -Internet-Draft - - - Progress. - - [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, - S., "DNS Security Introduction and Requirements" draft- - ietf-dnsext-dnssec-intro- 06.txt, Work in Progress. - - [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, - S., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro- - gress. - - [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, - S., "Protocol Modifications for the DNS Security Exten- - sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work - in Progress. - - [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- - col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress. - - [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home - Address Options", draft-savola-ipv6-rh-ha-security- - 03.txt, Work in Progress, March 2002. - - [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- - rity Threats and Counter-Measures; In Proceedings "Sympo- - sium on Network and Distributed System Security", Febru- - ary 1995, pp.2-16. - - [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, - August 1980. - - [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- - ties", RFC 1034, November 1987. - - [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, - May 1997. - - [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and - S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC - 2205, September 1997. - - [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet - Networks", RFC 2462, December 1998. - - [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over - ATM Networks", RFC 2492, January 1999. - - [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 - - - -Loughney (editor) February 16, 2004 [Page 17] - - - - - -Internet-Draft - - - Jumbograms", RFC 2675, August 1999. - - [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal - IPv6 Addresses in URL's", RFC 2732, December 1999. - - [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, - "Textual Conventions for Internet Network Addresses", RFC - 2851, June 2000. - - [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for - IPv6 Hosts and Routers", RFC 2893, August 2000. - - [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific - Multicast (SSM)", RFC 3569, July 2003. - - [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", - draft-ietf- ssm-arch-03.txt, Work in Progress. - -13. Authors and Acknowledgements - - This document was written by the IPv6 Node Requirements design team: - - Jari Arkko - [jari.arkko@ericsson.com] - - Marc Blanchet - [marc.blanchet@viagenie.qc.ca] - - Samita Chakrabarti - [samita.chakrabarti@eng.sun.com] - - Alain Durand - [alain.durand@sun.com] - - Gerard Gastaud - [gerard.gastaud@alcatel.fr] - - Jun-ichiro itojun Hagino - [itojun@iijlab.net] - - Atsushi Inoue - [inoue@isl.rdc.toshiba.co.jp] - - Masahiro Ishiyama - [masahiro@isl.rdc.toshiba.co.jp] - - John Loughney - [john.loughney@nokia.com] - - - -Loughney (editor) February 16, 2004 [Page 18] - - - - - -Internet-Draft - - - Rajiv Raghunarayan - [raraghun@cisco.com] - - Shoichi Sakane - [shouichi.sakane@jp.yokogawa.com] - - Dave Thaler - [dthaler@windows.microsoft.com] - - Juha Wiljakka - [juha.wiljakka@Nokia.com] - - The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- - penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, - Juha Ollila and Pekka Savola for their comments. - -14. Editor's Contact Information - - Comments or questions regarding this document should be sent to the - IPv6 Working Group mailing list (ipv6@ietf.org) or to: - - John Loughney - Nokia Research Center - Itamerenkatu 11-13 - 00180 Helsinki - Finland - - Phone: +358 50 483 6242 - Email: John.Loughney@Nokia.com - -Notices - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to per- - tain to the implementation or use of the technology described in this - document or the extent to which any license under such rights might - or might not be available; neither does it represent that it has made - any effort to identify any such rights. Information on the IETF's - procedures with respect to rights in standards-track and standards- - related documentation can be found in BCP-11. Copies of claims of - rights made available for publication and any assurances of licenses - to be made available, or the result of an attempt made to obtain a - general license or permission for the use of such proprietary rights - by implementors or users of this specification can be obtained from - the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - - - -Loughney (editor) February 16, 2004 [Page 19] - - - - - -Internet-Draft - - - rights, which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Loughney (editor) February 16, 2004 [Page 20] - - diff --git a/doc/draft/draft-ietf-secsh-dns-05.txt b/doc/draft/draft-ietf-secsh-dns-05.txt deleted file mode 100644 index a272d81b0a..0000000000 --- a/doc/draft/draft-ietf-secsh-dns-05.txt +++ /dev/null @@ -1,614 +0,0 @@ -Secure Shell Working Group J. Schlyter -Internet-Draft OpenSSH -Expires: March 5, 2004 W. Griffin - SPARTA - September 5, 2003 - - - Using DNS to Securely Publish SSH Key Fingerprints - draft-ietf-secsh-dns-05.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on March 5, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document describes a method to verify SSH host keys using - DNSSEC. The document defines a new DNS resource record that contains - a standard SSH key fingerprint. - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 1] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 - 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 - 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 - 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 - 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5 - 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 - 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 - 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 - Normative References . . . . . . . . . . . . . . . . . . . . 8 - Informational References . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 - A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - Intellectual Property and Copyright Statements . . . . . . . 10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 2] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -1. Introduction - - The SSH [6] protocol provides secure remote login and other secure - network services over an insecure network. The security of the - connection relies on the server authenticating itself to the client - as well as the user authenticating itself to the server. - - If a connection is established to a server whose public key is not - already known to the client, a fingerprint of the key is presented to - the user for verification. If the user decides that the fingerprint - is correct and accepts the key, the key is saved locally and used for - verification for all following connections. While some - security-conscious users verify the fingerprint out-of-band before - accepting the key, many users blindly accept the presented key. - - The method described here can provide out-of-band verification by - looking up a fingerprint of the server public key in the DNS [1][2] - and using DNSSEC [5] to verify the lookup. - - In order to distribute the fingerprint using DNS, this document - defines a new DNS resource record, "SSHFP", to carry the fingerprint. - - Basic understanding of the DNS system [1][2] and the DNS security - extensions [5] is assumed by 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 RFC 2119 [3]. - -2. SSH Host Key Verification - -2.1 Method - - Upon connection to a SSH server, the SSH client MAY look up the SSHFP - resource record(s) for the host it is connecting to. If the - algorithm and fingerprint of the key received from the SSH server - match the algorithm and fingerprint of one of the SSHFP resource - record(s) returned from DNS, the client MAY accept the identity of - the server. - -2.2 Implementation Notes - - Client implementors SHOULD provide a configurable policy used to - select the order of methods used to verify a host key. This document - defines one method: Fingerprint storage in DNS. Another method - defined in the SSH Architecture [6] uses local files to store keys - for comparison. Other methods that could be defined in the future - might include storing fingerprints in LDAP or other databases. A - - - -Schlyter & Griffin Expires March 5, 2004 [Page 3] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - configurable policy will allow administrators to determine which - methods they want to use and in what order the methods should be - prioritized. This will allow administrators to determine how much - trust they want to place in the different methods. - - One specific scenario for having a configurable policy is where - clients do not use fully qualified host names to connect to servers. - In this scenario, the implementation SHOULD verify the host key - against a local database before verifying the key via the fingerprint - returned from DNS. This would help prevent an attacker from injecting - a DNS search path into the local resolver and forcing the client to - connect to a different host. - -2.3 Fingerprint Matching - - The public key and the SSHFP resource record are matched together by - comparing algorithm number and fingerprint. - - The public key algorithm and the SSHFP algorithm number MUST - match. - - A message digest of the public key, using the message digest - algorithm specified in the SSHFP fingerprint type, MUST match the - SSHFP fingerprint. - - -2.4 Authentication - - A public key verified using this method MUST NOT be trusted if the - SSHFP resource record (RR) used for verification was not - authenticated by a trusted SIG RR. - - Clients that do validate the DNSSEC signatures themselves SHOULD use - standard DNSSEC validation procedures. - - Clients that do not validate the DNSSEC signatures themselves MUST - use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8], - between themselves and the entity performing the signature - validation. - -3. The SSHFP Resource Record - - The SSHFP resource record (RR) is used to store a fingerprint of a - SSH public host key that is associated with a Domain Name System - (DNS) name. - - The RR type code for the SSHFP RR is TBA. - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 4] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -3.1 The SSHFP RDATA Format - - The RDATA for a SSHFP RR consists of an algorithm number, fingerprint - type and the fingerprint of the public host key. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | algorithm | fp type | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / - / / - / fingerprint / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 Algorithm Number Specification - - This algorithm number octet describes the algorithm of the public - key. The following values are assigned: - - Value Algorithm name - ----- -------------- - 0 reserved - 1 RSA - 2 DSS - - Reserving other types requires IETF consensus [4]. - -3.1.2 Fingerprint Type Specification - - The fingerprint type octet describes the message-digest algorithm - used to calculate the fingerprint of the public key. The following - values are assigned: - - Value Fingerprint type - ----- ---------------- - 0 reserved - 1 SHA-1 - - Reserving other types requires IETF consensus [4]. - - For interoperability reasons, as few fingerprint types as possible - should be reserved. The only reason to reserve additional types is - to increase security. - -3.1.3 Fingerprint - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 5] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - The fingerprint is calculated over the public key blob as described - in [7]. - - The message-digest algorithm is presumed to produce an opaque octet - string output which is placed as-is in the RDATA fingerprint field. - -3.2 Presentation Format of the SSHFP RR - - The RDATA of the presentation format of the SSHFP resource record - consists of two numbers (algorithm and fingerprint type) followed by - the fingerprint itself presented in hex, e.g: - - host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 - - The use of mnemonics instead of numbers is not allowed. - -4. Security Considerations - - Currently, the amount of trust a user can realistically place in a - server key is proportional to the amount of attention paid to - verifying that the public key presented actually corresponds to the - private key of the server. If a user accepts a key without verifying - the fingerprint with something learned through a secured channel, the - connection is vulnerable to a man-in-the-middle attack. - - The overall security of using SSHFP for SSH host key verification is - dependent on the security policies of the SSH host administrator and - DNS zone administrator (in transferring the fingerprint), detailed - aspects of how verification is done in the SSH implementation, and in - the client's diligence in accessing the DNS in a secure manner. - - One such aspect is in which order fingerprints are looked up (e.g. - first checking local file and then SSHFP). We note that in addition - to protecting the first-time transfer of host keys, SSHFP can - optionally be used for stronger host key protection. - - If SSHFP is checked first, new SSH host keys may be distributed by - replacing the corresponding SSHFP in DNS. - - If SSH host key verification can be configured to require SSHFP, - SSH host key revocation can be implemented by removing the - corresponding SSHFP from DNS. - - As stated in Section 2.2, we recommend that SSH implementors provide - a policy mechanism to control the order of methods used for host key - verification. One specific scenario for having a configurable policy - is where clients use unqualified host names to connect to servers. In - this case, we recommend that SSH implementations check the host key - - - -Schlyter & Griffin Expires March 5, 2004 [Page 6] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - against a local database before verifying the key via the fingerprint - returned from DNS. This would help prevent an attacker from injecting - a DNS search path into the local resolver and forcing the client to - connect to a different host. - - A different approach to solve the DNS search path issue would be for - clients to use a trusted DNS search path, i.e., one not acquired - through DHCP or other autoconfiguration mechanisms. Since there is no - way with current DNS lookup APIs to tell whether a search path is - from a trusted source, the entire client system would need to be - configured with this trusted DNS search path. - - Another dependency is on the implementation of DNSSEC itself. As - stated in Section 2.4, we mandate the use of secure methods for - lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This - is especially important if SSHFP is to be used as a basis for host - key rollover and/or revocation, as described above. - - Since DNSSEC only protects the integrity of the host key fingerprint - after it is signed by the DNS zone administrator, the fingerprint - must be transferred securely from the SSH host administrator to the - DNS zone administrator. This could be done manually between the - administrators or automatically using secure DNS dynamic update [11] - between the SSH server and the nameserver. We note that this is no - different from other key enrollment situations, e.g. a client sending - a certificate request to a certificate authority for signing. - -5. IANA Considerations - - IANA needs to allocate a RR type code for SSHFP from the standard RR - type space (type 44 requested). - - IANA needs to open a new registry for the SSHFP RR type for public - key algorithms. Defined types are: - - 0 is reserved - 1 is RSA - 2 is DSA - - Adding new reservations requires IETF consensus [4]. - - IANA needs to open a new registry for the SSHFP RR type for - fingerprint types. Defined types are: - - 0 is reserved - 1 is SHA-1 - - Adding new reservations requires IETF consensus [4]. - - - -Schlyter & Griffin Expires March 5, 2004 [Page 7] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [5] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. - Lehtinen, "SSH Protocol Architecture", - draft-ietf-secsh-architecture-14 (work in progress), July 2003. - - [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. - Lehtinen, "SSH Transport Layer Protocol", - draft-ietf-secsh-transport-16 (work in progress), July 2003. - -Informational References - - [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document - Roadmap", RFC 2411, November 1998. - - [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [10] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 8] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Authors' Addresses - - Jakob Schlyter - OpenSSH - 812 23rd Avenue SE - Calgary, Alberta T2G 1N8 - Canada - - EMail: jakob@openssh.com - URI: http://www.openssh.com/ - - - Wesley Griffin - SPARTA - 7075 Samuel Morse Drive - Columbia, MD 21046 - USA - - EMail: wgriffin@sparta.com - URI: http://www.sparta.com/ - -Appendix A. Acknowledgements - - The authors gratefully acknowledge, in no particular order, the - contributions of the following persons: - - Martin Fredriksson - - Olafur Gudmundsson - - Edward Lewis - - Bill Sommerfeld - - - - - - - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 9] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Schlyter & Griffin Expires March 5, 2004 [Page 10] - -Internet-Draft DNS and SSH Fingerprints September 2003 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter & Griffin Expires March 5, 2004 [Page 11] - diff --git a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt deleted file mode 100644 index 3578d2a15e..0000000000 --- a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt +++ /dev/null @@ -1,519 +0,0 @@ - -Internet Draft Johan Ihren -draft-ihren-dnsext-threshold-validation-00.txt Autonomica -February 2003 -Expires in six months - - - Threshold Validation: - - A Mechanism for Improved Trust and Redundancy for DNSSEC Keys - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - -Abstract - - This memo documents a proposal for a different method of validation - for DNSSEC aware resolvers. The key change is that by changing from - a model of one Key Signing Key, KSK, at a time to multiple KSKs it - will be possible to increase the aggregated trust in the signed - keys by leveraging from the trust associated with the different - signees. - - By having multiple keys to chose from validating resolvers get the - opportunity to use local policy to reflect actual trust in - different keys. For instance, it is possible to trust a single, - particular key ultimately, while requiring multiple valid - signatures by less trusted keys for validation to succeed. - Furthermore, with multiple KSKs there are additional redundancy - benefits available since it is possible to roll over different KSKs - at different times which may make rollover scenarios easier to - manage. - -Contents - - 1. Terminology - 2. Introduction and Background - - 3. Trust in DNSSEC Keys - 3.1. Key Management, Split Keys and Trust Models - 3.2. Trust Expansion: Authentication versus Authorization - - 4. Proposed Semantics for Signing the KEY Resource Record - Set - 4.1. Packet Size Considerations - - 5. Proposed Use of Multiple "Trusted Keys" in a Validating - Resolver - 5.1. Not All Possible KSKs Need to Be Trusted - 5.2. Possible to do Threshold Validation - 5.3. Not All Trusted Keys Will Be Available - - 6. Additional Benefits from Having Multiple KSKs - 6.1. More Robust Key Rollovers - 6.2. Evaluation of Multiple Key Distribution Mechanisms - - 7. Security Considerations - 8. IANA Considerations. - 9. References - 9.1. Normative. - 9.2. Informative. - 10. Acknowledgments. - 11. Authors' Address - - -1. Terminology - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in - RFC 2119. - - The term "zone" refers to the unit of administrative control in the - Domain Name System. "Name server" denotes a DNS name server that is - authoritative (i.e. knows all there is to know) for a DNS zone, - typically the root zone. A "resolver", is a DNS "client", i.e. an - entity that sends DNS queries to authoritative nameservers and - interpret the results. A "validating resolver" is a resolver that - attempts to perform DNSSEC validation on data it retrieves by doing - DNS lookups. - - -2. Introduction and Background - - From a protocol perspective there is no real difference between - different keys in DNSSEC. They are all just keys. However, in - actual use there is lots of difference. First and foremost, most - DNSSEC keys have in-band verification. I.e. the keys are signed by - some other key, and this other key is in its turn also signed by - yet another key. This way a "chain of trust" is created. Such - chains have to end in what is referred to as a "trusted key" for - validation of DNS lookups to be possible. - - A "trusted key" is a the public part of a key that the resolver - acquired by some other means than by looking it up in DNS. The - trusted key has to be explicitly configured. - - A node in the DNS hierarchy that issues such out-of-band "trusted - keys" is called a "security apex" and the trusted key for that apex - is the ultimate source of trust for all DNS lookups within that - entire subtree. - - DNSSEC is designed to be able to work with more than on security - apex. These apexes will all share the problem of how to distribute - their "trusted keys" in a way that provides validating resolvers - confidence in the distributed keys. - - Maximizing that confidence is crucial to the usefulness of DNSSEC - and this document tries to address this issue. - - -3. Trust in DNSSEC Keys - - In the end the trust that a validating resolver will be able to put - in a key that it cannot validate within DNSSEC will have to be a - function of - - * trust in the key issuer, aka the KSK holder - - * trust in the distribution method - - * trust in extra, out-of-band verification - - The KSK holder needs to be trusted not to accidentally lose private - keys in public places. Furthermore it needs to be trusted to - perform correct identification of the ZSK holders in case they are - separate from the KSK holder itself. - - The distribution mechanism can be more or less tamper-proof. If the - key holder publishes the public key, or perhaps just a secure - fingerprint of the key in a major newspaper it may be rather - difficult to tamper with. A key acquired that way may be easier to - trust than if it had just been downloaded from a web page. - - Out-of-band verification can for instance be the key being signed - by a certificate issued by a known Certificate Authority that the - resolver has reason to trust. - -3.1. Simplicity vs Trust - - The fewer keys that are in use the simpler the key management - becomes. Therefore increasing the number of keys should only be - considered when the complexity is not the major concern. A perfect - example of this is the distinction between so called Key Signing - Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds - overall complexity but simplifies real life operations and was an - overall gain since operational simplification was considered to be - a more crucial issue than the added complexity. - - In the case of a security apex there are additional issues to - consider, among them - - * maximizing trust in the KSK received out-of-band - - * authenticating the legitimacy of the ZSKs used - - In some cases this will be easy, since the same entity will manage - both ZSKs and KSKs (i.e. it will authenticate itself, somewhat - similar to a self-signed certificate). In some environments it will - be possible to get the trusted key installed in the resolver end by - decree (this would seem to be a likely method within corporate and - government environments). - - In other cases, however, this will possibly not be sufficient. In - the case of the root zone this is obvious, but there may well be - other cases. - -3.2. Expanding the "Trust Base" - - For a security apex where the ZSKs and KSK are not held by the same - entity the KSK will effectively authenticate the identity of - whoever does real operational zone signing. The amount of trust - that the data signed by a ZSK will get is directly dependent on - whether the end resolver trusts the KSK or not, since the resolver - has no OOB access to the public part of the ZSKs (for practical - reasons). - - Since the KSK holder is distinct from the ZSK holder the obvious - question is whether it would then be possible to further improve - the situation by using multiple KSK holders and thereby expanding - the trust base to the union of that available to each individual - KSK holder. "Trust base" is an invented term intended to signify - the aggregate of Internet resolvers that will eventually choose to - trust a key issued by a particular KSK holder. - - A crucial issue when considering trust expansion through addition - of multiple KSK holders is that the KSK holders are only used to - authenticate the ZSKs used for signing the zone. I.e. the function - performed by the KSK is basically: - - "This is indeed the official ZSK holder for this zone, - I've verified this fact to the best of my abilitites." - - Which can be thought of as similar to the service of a public - notary. I.e. the point with adding more KSK holders is to improve - the public trust in data signed by the ZSK holders by improving the - strength of available authentication. - - Therefore adding more KSK holders, each with their own trust base, - is by definition a good thing. More authentication is not - controversial. On the contrary, when it comes to authentication, - the more the merrier. - - -4. Proposed Semantics for Signing the KEY Resource Record Set - - In DNSSEC according to RFC2535 all KEY Resource Records are used to - sign all authoritative data in the zone, including the KEY RRset - itself, since RFC2535 makes no distinction between Key Signing - Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS] - it is possible to change this to the KEY RRset being signed with - all KSKs and ZSKs but the rest of the zone only being signed by the - ZSKs. - - This proposal changes this one step further, by recommending that - the KEY RRset is only signed by the Key Signing Keys, KSK, and - explicitly not by the Zone Signing Keys, ZSK. The reason for this - is to maximize the amount of space in the DNS response packet that - is available for additional KSKs and signatures thereof. The rest - of the authoritative zone contents are as previously signed by only - the ZSKs. - -4.1. Packet Size Considerations - - The reason for the change is to keep down the size of the aggregate - of KEY RRset plus SIG(KEY) that resolvers will need to acquire to - perform validation of data below a security apex. For DNSSEC data - to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be - set, and therefore the allowed packet size can be assumed to be at - least the EDNS0 minimum of 4000 bytes. - - When querying for KEY + SIG(KEY) for "." (the case that is assumed - to be most crucial) the size of the response packet after the - change to only sign the KEY RR with the KSKs break down into a - rather large space of possibilities. Here are a few examples for - the possible alternatives for different numbers of KSKs and ZSKs - for some different key lengths (all RSA keys, with a public - exponent that is < 254). This is all based upon the size of the - response for the particular example of querying for - - ". KEY IN" - - with a response of entire KEY + SIG(KEY) with the authority and - additional sections empty: - - ZSK/768 and KSK/1024 (real small) - Max 12 KSK + 3 ZSK at 3975 - 10 KSK + 8 ZSK at 3934 - 8 KSK + 13 ZSK at 3893 - - ZSK/768 + KSK/1280 - MAX 10 KSK + 2 ZSK at 3913 - 8 KSK + 9 ZSK at 3970 - 6 KSK + 15 ZSK at 3914 - - ZSK/768 + KSK/1536 - MAX 8 KSK + 4 ZSK at 3917 - 7 KSK + 8 ZSK at 3938 - 6 KSK + 12 ZSK at 3959 - - ZSK/768 + KSK/2048 - MAX 6 KSK + 5 ZSK at 3936 - 5 KSK + 10 ZSK at 3942 - - ZSK/1024 + KSK/1024 - MAX 12 KSK + 2 ZSK at 3943 - 11 KSK + 4 ZSK at 3930 - 10 KSK + 6 ZSK at 3917 - 8 KSK + 10 ZSK at 3891 - - ZSK/1024 + KSK/1536 - MAX 8 KSK + 3 ZSK at 3900 - 7 KSK + 6 ZSK at 3904 - 6 KSK + 9 ZSK at 3908 - - ZSK/1024 + KSK/2048 - MAX 6 KSK + 4 ZSK at 3951 - 5 KSK + 8 ZSK at 3972 - 4 KSK + 12 ZSK at 3993 - - Note that these are just examples and this document is not making - any recommendations on suitable choices of either key lengths nor - number of different keys employed at a security apex. - - This document does however, based upon the above figures, make the - recommendation that at a security apex that expects to distribute - "trusted keys" the KEY RRset should only be signed with the KSKs - and not with the ZSKs to keep the size of the response packets - down. - - -5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver - - In DNSSEC according to RFC2535[RFC2535] validation is the process - of tracing a chain of signatures (and keys) upwards through the DNS - hierarchy until a "trusted key" is reached. If there is a known - trusted key present at a security apex above the starting point - validation becomes an exercise with a binary outcome: either the - validation succeeds or it fails. No intermediate states are - possible. - - With multiple "trusted keys" (i.e. the KEY RRset for the security - apex signed by multiple KSKs) this changes into a more complicated - space of alternatives. From the perspective of complexity that may - be regarded as a change for the worse. However, from a perspective - of maximizing available trust the multiple KSKs add value to the - system. - -5.1. Possible to do Threshold Validation - - With multiple KSKs a new option that opens for the security - concious resolver is to not trust a key individually. Instead the - resolver may decide to require the validated signatures to exceed a - threshold. For instance, given M trusted keys it is possible for - the resolver to require N-of-M signatures to treat the data as - validated. - - I.e. with the following pseudo-configuration in a validating - resolver - - security-apex "." IN { - keys { ksk-1 .... ; - ksk-2 .... ; - ksk-3 .... ; - ksk-4 .... ; - ksk-5 .... ; - }; - validation { - # Note that ksk-4 is not present below - keys { ksk-1; ksk-2; ksk-3; ksk-5; }; - # 3 signatures needed with 4 possible keys, aka 75% - needed-signatures 3; - }; - }; - - we configure five trusted keys for the root zone, but require two - valid signatures for the top-most KEY for validation to - succeed. I.e. threshold validation does not force multiple - signatures on the entire signature chain, only on the top-most - signature, closest to the security apex for which the resolver has - trusted keys. - -5.2. Not All Trusted Keys Will Be Available - - With multiple KSKs held and managed by separate entities the end - resolvers will not always manage to get access to all possible - trusted keys. In the case of just a single KSK this would be fatal - to validation and necessary to avoid at whatever cost. But with - several fully trusted keys available the resolver can decide to - trust several of them individually. An example based upon more - pseudo-configuration: - - security-apex "." IN { - keys { ksk-1 .... ; - ksk-2 .... ; - ksk-3 .... ; - ksk-4 .... ; - ksk-5 .... ; - }; - validation { - # Only these two keys are trusted independently - keys { ksk-1; ksk-4; }; - # With these keys a single signature is sufficient - needed-signatures 1; - }; - }; - - Here we have the same five keys and instruct the validating - resolver to fully trust data that ends up with just one signature - from by a fully trusted key. - - The typical case where this will be useful is for the case where - there is a risk of the resolver not catching a rollover event by - one of the KSKs. By doing rollovers of different KSKs with - different schedules it is possible for a resolver to "survive" - missing a rollover without validation breaking. This improves - overall robustness from a management point of view. - -5.3. Not All Possible KSKs Need to Be Trusted - - With just one key available it simply has to be trusted, since that - is the only option available. With multiple KSKs the validating - resolver immediately get the option of implementing a local policy - of only trusting some of the possible keys. - - This local policy can be implemented either by simply not - configuring keys that are not trusted or, possibly, configure them - but specify to the resolver that certain keys are not to be - ultimately trusted alone. - - -6. Additional Benefits from Having Multiple KSKs - -6.1. More Robust Key Rollovers - - With only one KSK the rollover operation will be a delicate - operation since the new trusted key needs to reach every validating - resolver before the old key is retired. For this reason it is - expected that long periods of overlap will be needed. - - With multiple KSKs this changes into a system where different - "series" of KSKs can have different rollover schedules, thereby - changing from one "big" rollover to several "smaller" rollovers. - - If the resolver trusts several of the available keys individually - then even a failure to track a certain rollover operation within - the overlap period will not be fatal to validation since the other - available trusted keys will be sufficient. - -6.2. Evaluation of Multiple Key Distribution Mechanisms - - Distribution of the trusted keys for the DNS root zone is - recognized to be a difficult problem that ... - - With only one trusted key, from one single "source" to distribute - it will be difficult to evaluate what distribution mechanism works - best. With multiple KSKs, held by separate entitites it will be - possible to measure how large fraction of the resolver population - that is trusting what subsets of KSKs. - - -7. Security Considerations - - From a systems perspective the simplest design is arguably the - best, i.e. one single holder of both KSK and ZSKs. However, if that - is not possible in all cases a more complex scheme is needed where - additional trust is injected by using multiple KSK holders, each - contributing trust, then there are only two alternatives - available. The first is so called "split keys", where a single key - is split up among KSK holders, each contributing trust. The second - is the multiple KSK design outlined in this proposal. - - Both these alternatives provide for threshold mechanisms. However - split keys makes the threshold integral to the key generating - mechanism (i.e. it will be a property of the keys how many - signatures are needed). In the case of multiple KSKs the threshold - validation is not a property of the keys but rather local policy in - the validating resolver. A benefit from this is that it is possible - for different resolvers to use different trust policies. Some may - configure threshold validation requiring multiple signatures and - specific keys (optimizing for security) while others may choose to - accept a single signature from a larger set of keys (optimizing for - redundancy). Since the security requirements are different it would - seem to be a good idea to make this choice local policy rather than - global policy. - - Furthermore, a clear issue for validating resolvers will be how to - ensure that they track all rollover events for keys they - trust. Even with operlap during the rollover (which is clearly - needed) there is still a need to be exceedingly careful not to miss - any rollovers (or fail to acquire a new key) since without this - single key validation will fail. With multiple KSKs this operation - becomes more robust, since different KSKs may roll at different - times according to different rollover schedules and losing one key, - for whatever reason, will not be crucial unless the resolver - intentionally chooses to be completely dependent on that exact key. - -8. IANA Considerations. - - NONE. - - -9. References - -9.1. Normative. - - [RFC2535] Domain Name System Security Extensions. D. Eastlake. - March 1999. - - [RFC3090] DNS Security Extension Clarification on Zone Status. - E. Lewis. March 2001. - - -9.2. Informative. - - [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System - (DNS). D. Eastlake 3rd. May 2001. - - [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. - December 2001. - - [DS] Delegation Signer Resource Record. - O. Gudmundsson. October 2002. Work In Progress. - -10. Acknowledgments. - - Bill Manning came up with the original idea of moving complexity - from the signing side down to the resolver in the form of threshold - validation. I've also had much appreciated help from (in no - particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and - Olaf Kolkman. - - -11. Authors' Address -Johan Ihren -Autonomica AB -Bellmansgatan 30 -SE-118 47 Stockholm, Sweden -johani@autonomica.se diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt deleted file mode 100644 index f9eaf26819..0000000000 --- a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt +++ /dev/null @@ -1,1830 +0,0 @@ - - - - INTERNET-DRAFT S. Daniel Park - Expires: October 2003 Syam Madanapalli - File: SAMSUNG Electronics - draft-park-ipv6-extensions-dns-pnp-00.txt April 2003 - - - - - IPv6 Extensions for DNS Plug and Play - - - - Status of This Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - - Abstract - - This document proposes automatic configuration of domain name (FQDN) - for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as - a part of IPv6 plug and play feature. 6DNAC allows the automatic - registration of domain name and corresponding IPv6 Addresses with - the DNS server. In order to provide 6DNAC function, Neighbor Discovery - Protocol [2461] will be used. Moreover, 6DNAC does not require any - changes to the existing DNS system. - - - Table of Contents - - 1. Introduction ............................................. 3 - 2. Terminology .............................................. 3 - 3. 6DNAC Design Principles .................................. 4 - 4. 6DNAC Overview ........................................... 4 - 5. 6DNAC Requirements ....................................... 5 - 5.1. 6DANR Client Requirements ................................ 5 - 5.2. 6DNAC Server Requirements ................................ 6 - -Park & Madanapalli Expires October 2003 [Page 1] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 6. 6DNAC Messages and Option Formats ........................ 6 - 6.1. Router Advertisement (RA) Message Format ................. 6 - 6.2. Neighbor Solicitation (NS) Message Format ................ 7 - 6.3. Neighbor Advertisement (NA) Message Format ............... 8 - 6.4. Option Formats ........................................... 8 - 6.4.1. DNS Zone Suffix Information Option Format ................ 8 - 6.4.2. Domain Name (FQDN) Option Format ......................... 9 - 6.4.3. Router Alert Option for 6DNAC ............................ 10 - 7. 6DNAC Operation .......................................... 10 - 7.1. 6DNAC Network Topology ................................... 11 - 7.2. 6DNAC Operational Scenarios .............................. 12 - 7.2.1. Domain Name Registration-Success Case .................... 12 - 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2.... 14 - 7.2.3. Domain Name Registration-Defend Case ..................... 16 - 7.2.4. Domain Name Registration in Retry Mode ................... 19 - 7.2.5. Domain Name Registration when DAD Fails .................. 20 - 7.3. DNS Zone Suffix Discovery and FQDN Construction .......... 22 - 7.3.1. Sending Router Advertisement Messages .................... 22 - 7.3.2. Processing Router Advertisement Messages ................. 22 - 7.3.3. FQDN Lifetime expiry ..................................... 23 - 7.3.4. Host Naming Algorithm .................................... 23 - 7.4. Duplicate Domain Name Detection .......................... 23 - 7.4.1. DAD with All Nodes Multicast Address ..................... 24 - 7.4.1.1. Sending Neighbor Solicitation Messages ................... 24 - 7.4.1.2. Processing Neighbor Solicitation Messages ................ 24 - 7.4.1.3. Sending Neighbor Advertisement Messages .................. 25 - 7.4.1.4. Processing Neighbor Advertisement Messages ............... 25 - 7.4.1.5. Pros and Cons ............................................ 25 - 7.4.2. DAD with Router Alert Option for 6DNAC ................... 25 - 7.4.2.1. Sending Neighbor Solicitation Messages ................... 25 - 7.4.2.2. Processing Neighbor Solicitation Messages ................ 26 - 7.4.2.3. Sending Neighbor Advertisement Messages .................. 26 - 7.4.2.4. Processing Neighbor Advertisement Messages ............... 26 - 7.4.2.5. Pros and Cons ............................................ 26 - 7.4.3. Explicit Detection of Duplicate Domain Name .............. 26 - 7.4.3.1. Sending Neighbor Solicitation Messages ................... 26 - 7.4.3.2. Processing Neighbor Solicitation Messages ................ 26 - 7.4.3.3. Sending Neighbor Advertisement Messages .................. 27 - 7.4.3.4. Processing Neighbor Advertisement Messages ............... 27 - 7.4.3.5. Pros and Cons ............................................ 27 - 7.4.4. Retry Mode for Re-registering Domain Name ................ 27 - 7.5. Domain Name Registration ................................. 27 - 8. Security Consideration ................................... 27 - 9. IANA Consideration ....................................... 28 - 10. Acknowledgement .......................................... 28 - 11. Intellectual Property .................................... 28 - 12. Copyright ................................................ 28 - 13. References ............................................... 29 - 14. Author's Addresses ....................................... 30 - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 2] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 1. Introduction - - Today, most networks use DNS[1034][1035] for convenience. In case of - IPv6, DNS is more important element because of IPv6 long addresses - which are difficult to remember. In addition, small networks like home - networks using IPv6, should be able to make network easily without - manual configuration. Also, these small networks may not have DHCP - Server, DNS Server etc. that are used to configure the network. This - document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure - for generating and registering the Domain Name and IPv6 addresses with - the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are - required to implement lightweight functions specified in this document. - 6DNAC can be applied to all defined IPv6 unicast addresses except Link - local IPv6 addresses, viz: Site-local and Global addresses. - - 6DNAC uses Neighbor Discovery Protocol [2461] with new additions - (defined in section 6) and DAD procedures for generating and - registering the Domain Name with the DNS server automatically. - - - 2. Terminology - - 6DNAC - IPv6 Domain Name Auto Configuration. It can provide - IPv6 hosts with Domain Name Generation and - Registration automatically. - - 6DNAC Client - An IPv6 node that can generate its own unique Domain - Name. Section 3 identifies the new requirements that - 6DNAC places on an IPv6 node to be a 6DNAC node. - - 6DNAC Server - An IPv6 node that can collect and registrate Domain - Name and IPv6 addresses automatically. 6DNAC server - uses the information from the DAD operation messages - with newly defined options for the registration of the - Domain Name and IPv6 Addresses. Section 3 identifies - the new requirements that 6DNAC places on an IPv6 - node to be a 6DNAC server. Also 6DNAC server can have - various other functions depending on network - environment and the network operator. For instance - 6DNAC Server can acts as a Gateway as well Home Server - in Home Networks. - - DAD - Duplicate Address Detection (is defined [2461]) - - DFQDND - Duplicate Domain Name Detection - - FQDN - Fully Qualified Domain Name - FQDN and Domain Name are - used interchangeably in this document. - - NA - Neighbor Advertisement message (is defined [2461]) - - NS - Neighbor Solicitation message (is defined [2461]) - - RA - Router Advertisement message (is defined [2461]) - - SLAAC - Stateless Address Autoconfiguration [2462]. - -Park & Madanapalli Expires October 2003 [Page 3] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 3. 6DNAC Design Principles - - This section discusses the design principles of 6DNAC mechanism. - - 1. The new procedures for plug and play DNS should not cause changes - to existing DNS system. 6DNAC requires lightweight functions to be - implemented only at the client side of the DNS system, and uses the - existing DDNS UPDATE [2136] to communicate with DNS Servers. - - 2. Introducing a new protocol will always introduce new problems. - 6DNAC uses the existing protocols NDP [2461] with minor extensions - for generating and registering the domain name automatically - without defining a new protocol - - 3. Reusing proven and well understood design principles/patterns - will always yield a robust system. 6DNAC is based on IPv6 Address - Auotoconfiguration principle, where routers advertise the prefix - and host adds the interface ID to the prefix and forms the IPv6 - address. Domain Name (FQDN) also contains two parts: host name - and DNS zone suffix. Routers can advertise the DNS zone suffix - on a particular link in Router Advertisements (RA Messages) and - hosts can prefix their preferred host name to the DNS zone suffix - and form the fully qualified domain name. Also the detection of - duplicate domain name is similar to Duplicate Address Detection - (DAD) and can be part of DAD operation itself. - - - 4. 6DNAC Overview - - 6DNAC proposes minor extensions to NDP [2461] for automatic generation - and registration of domain name with the DNS server. It introduces two - new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone - Suffix option is carried in Router Advertisement (RA) messages for - notifying IPv6 nodes about the valid DNS Zone Suffix on the link and - FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement - (NA) messages to detect duplicate domain name. 6DNAC consists of two - components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the - domain name based on DNS Zone Suffix using Host Naming Algorithm (see - section 7.3.1) and 6DNAC Server collects and registers the DNS - information with the DNS Server on behalf of 6DNAC Clients. - - The automatic configuration of domain name using 6DNAC consists of - three parts. - - - DNS Zone Suffix Discovery and FQDN Construction: - - IPv6 Nodes collect DNS Zone Suffix information from Router - Advertisements and constructs FQDN by prefixing host name to the - DNS Zone Suffix. The IPv6 Nodes are required to implement Host - Naming Algorithm for generating host part of the FQDN in the - absence of administrator. - - Generation of node's FQDN within the node itself has advantages. Nodes - can provide forward and reverse name lookups independent of the DNS - System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain - Name is some thing that is owned by the node. - -Park & Madanapalli Expires October 2003 [Page 4] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - Duplicate Domain Name Detection - - All nodes are expected to go for DAD for all new IPv6 unicast - addresses, regardless of whether they are obtained through - stateful, stateless or manual configuration. 6DNAC uses the DAD - messages with new option for carrying the Domain Name along with - the new IPv6 Address. 6DNAC Server captures this information and - updates DNS Server provided that the IPv6 Address and its domain - name are not duplicate. If the domain name is already in use, - the 6DNAC server replies to the sender with FQDN Option in NA - message indicating that the domain name is duplicate. Then the - node is expected to generate another domain name using host - naming algorithm and go for DAD. This time the DAD is only for - duplicate domain name detection (DFQDND). In order to avoid - confusion with the normal NDP processing, the target address - field of the NS message must carry the unspecified address - in retry mode. This can be repeated depending on number of - retries defined by the administrator in the host naming algorithm. - - - - Domain Name Registration - - 6DNAC Server detects the DNS information (IPv6 Address and - corresponding FQDN) from DAD/DFQDND messages and updates DNS - Server using existing protocol DDNS UPDATE [2136] provided that - the IPv6 Address and its domain name are not duplicate. - - If an IPv6 Address is duplicate, the IPv6 node cannot perform - stateless address autoconfiguration repeatedly. Unlike IPv6 stateless - address autoconfiguration, 6DNAC allows the automatic configuration of - domain name repeatedly if the domain name is duplicate depending on - number of retries defined by the administrator in the host naming - algorithm. - - - 5. 6DNAC Requirements - - Depending on the 6DNAC functionality, the IPv6 nodes implement, they - are called either 6DNAC Clients or 6DNAC Servers. The following - sections lists the requirements that the 6DNAC Client and 6DNAC server - must support. - - - 5.1. 6DANC Client Requirements - - - 6DNAC Client must recognize and process the following NDP - extensions - - - DNS Zone Suffix option in RA messages for generating its - domain name (FQDN). - - - Domain Name option in NS and NA messages for detecting - the duplicate domain name - - - - -Park & Madanapalli Expires October 2003 [Page 5] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - It must generate its domain name (FQDN) based on the DNS - suffix that it got from the router advertisement. And it must - have a host naming algorithm for generating the host part of - the FQDN. - - - If NA message is received with unspecified target address and - FQDN option, then the node must treat that the domain is - duplicate. - - - 5.2. 6DNAC Server Requirements - - - 6DNAC Server must recognize and process the following NDP - extensions - - - If the 6DNAC Server is a router on the link, then it - must advertise DNS Zone Suffix option in RA messages - for hosts to generate their domain name (FQDN). - - - FQDN option in NS messages for detecting new DNS - information for of nodes on the link for which it - must update the AAAA RR and PTR RR in DNS Server. - - - FQDN option in NA messages for notifying duplicate - domain name with unspecified target address. - - - 6DNAC server must update the DNS Server (both AAAA RR and - PTR RR) dynamically using DDNS UPDATE [2136]. - - - 6DNAC server must cache this (newly detected) FQDN, Link - Layer Address, and IPv6 Address information, so that it can - decide whether it really needs to update DNS Server or not, - to avoid redundant updates. This information will also be - used for notifying the duplicate domain name. - - - 6. 6DNAC Messages and Option Formats - - In order to achieve the plug and play DNS, 6DNAC proposes new - extensions to the NDP [2461]. This section specifies the new - additions to NDP messages and formats of new options. - - - 6.1. Router Advertisement (RA) Message Format - - Routers send out Router Advertisement (RA) message periodically, or - in response to a Router Solicitation. 6DNAC does not modify the format - of the RA message, but proposes new option (DNS Zone Suffix Information) - to be carried in RA messages. - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 6] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Code | Checksum | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Cur Hop Limit |M|O| Reserved | Router Lifetime | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reachable Time | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Retrans Timer | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... | - / / - | DNS Zone Suffix Information | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - 6.2. Neighbor Solicitation (NS) Message Format - - 6DNAC does not modify the format of the Neighbor Solicitation (NS) - message, but proposes new option (FQDN Option) to be carried in NS - messages. When a node is going for DAD, the node must include FQDN - option in NS message to participate in plug and play DNS. If the - node is going for Explicit Detection of Duplicate Domain Name, the - node must use FQDN option in NS message and unspecified address in - the target address field. - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Code | Checksum | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... | - / / - | Domain Name | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - -Park & Madanapalli Expires October 2003 [Page 7] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 6.3. Neighbor Advertisement (NA) Message Format - - 6DNAC does not modify the format of the Neighbor Advertisement (NA) - message, but proposes new option (FQDN Option) to be carried in NA - messages. 6DNAC Server sends NA message with FQDN option to 6DNAC - Client that is performing duplicate domain name detection in case - the domain name found to be duplicate. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Code | Checksum | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |R|S|O| Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Options ... | - / / - | FQDN Option | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - 6.4 Option Formats - - 6.4.1. DNS Zone Suffix Information Option Format - - IPv6 nodes require DNS Zone Suffix for constructing their FQDN. - 6DNAC introduces new option for routers to advertise the DNS Zone - Suffix Information for IPv6 nodes on the link. The suffix information - should be configured into routers manually. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Valid Lifetime | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - / DNS Zone Suffix / - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - -Park & Madanapalli Expires October 2003 [Page 8] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - Type [TBD] - - Length 8-bit unsigned integer. The length of the option - (including the type and length fields) in units of - 8 octets. - - Reserved This field is unused. It must be initialized to zero - by the sender and must be ignored by the receiver. - - Valid Life Time 32-bit signed integer. The maximum time, in - seconds, over which this suffix is valid. Nodes - should treat this as the life time for their domain - name. Nodes should contact the source of this - information before expiry of this time interval. - A value of all one bits (0xFFFFFFFF) represents - infinity. - - DNS Zone Suffix The suffix part of the FQDN. The data in the DNS - Zone Suffix field should be encoded according to - DNS encoding rules specified in [1035]. - - - - 6.4.2. Domain Name (FQDN) Option Format - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Valid Lifetime | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - + + - | | - + FQDN Target Address + - | | - + + - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - / Domain Name / - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - Type [TBD] - - Length 8-bit unsigned integer. The length of the option - (including the type and length fields) in units - of 8 octets. It must be greater than 3. - - - -Park & Madanapalli Expires October 2003 [Page 9] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - Reserved This field is unused. It must be initialized to - zero by the sender and must be ignored by the - receiver. - - Valid Life Time 32-bit signed integer. The maximum time, in - seconds, over which this domain name is valid - 6DNAC should deregister this domain name at - the expiry of this interval. 6DNAC clients - should send updates by the expiry of this - interval. A value of all one bits (0xFFFFFFFF) - represents infinity. - - FQDN Target Address The Address for which the FQDN maps to. It - should be same as Target Address field of the - NS message in case of DAD & duplicate FQDN are - running in parallel. - - Domain Name The domain name (FQDN) of the node. The data in - the domain name should be encoded according to - DNS encoding rules specified in [1035]. - - - 6.4.3. Router Alert Option for 6DNAC - - Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop - Header for using in NDP messages. The presence of this option in NS - message informs the router that this NS message is carrying Domain - Name information and must be processed by the 6DNAC Server on the router. - 6DNAC Clients can use this option for sending DAD packets instead - of addressing the DAD packets to the all-nodes multicast address - when 6DNAC Server is implemented on router. - - The Router Alert option has the following format: - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Length = 2 - - Values are registered and maintained by the IANA. For 6DNAC, the - value has to be assigned by IANA. - - Further information about this option can be obtained from - IPv6 Router Alert Option [2711]. - - - 7. 6DNAC Operation - - 6DNAC provides mechanisms for automatic generation of domain name - and registering it with the DNS Server for IPv6 nodes. 6DNAC consists - of two components: 6DNAC Client and 6DNAC Server. All nodes that want - to participate in plug and play DNS are required to implement 6DNAC - Client functionality, and one of the IPv6 nodes is required to - implement 6DNAC Server functionality. The IPv6 node that implements - the 6DNAC Server functionality must know the location of the DNS - Server and must be a trusted node to send DDNS UPDATE [2136] messages. - -Park & Madanapalli Expires October 2003 [Page 10] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 7.1. 6DNAC Network Topology - - This section identifies the possible locations for the 6DNAC Server. - Note that, all nodes are required to implement 6DNAC Client - functionality for constructing the domain name from the DNS Zone - Suffix Information advertised by the router. Figure 6 illustrates - IPv6 host (H4) implementing 6DNAC Server functionality. In this case - H4 can serve only one link (that it belongs to) for automatic - registration of domain name. H4 must observe the DAD packets on the - link to detect the DNS information, this requires all nodes on the - link must belong to same solicited node multicast address. In general, - this may not be the case. So the node that is going for DAD must use - all nodes multicast address for DAD packets, so that the 6DNAC Server - (H4) can observe the DAD packets, detects IPv6 address and - corresponding domain name, checks if this domain name is duplicate - and finally registers the domain name with the DNS Server. - - - 6DNAC Server - +---+ +---+ +----------+ - | H1| | H4|<--- DDNS UPDATE --->|DNS Server| - +-+-+ +-+-+ +----+-----+ - | | +----+ +---/ - | | | | / - ---+-----+-----------+-----+-----------+ R1 +-----+ - | | | | - | | +----+ - +-+-+ +-+-+ - | H2| | H3| - +---+ +---+ - - - H1, H2, H3 - 6DNAC Clients - H4 - 6DNAC Server - R1 - Router - - - - - - Figure 7 shows the 6DNAC Server implemented on a router R1. In this - case a single 6DNAC server can serve multiple links for automatic - configuration of the domain name. This topology also has flexibility - of using DAD packets with Router Alert option instead of sending DAD - packets to all nodes multicast address. The routers are required to - process all the packets with Router Alert option as per [2711]. - - In case of Home Networks, R1 is will acts as a Home Gateway (CPE) - connected to ISP. R1 delegates the prefix from the ISP edge router. - After delegating the prefix the CPE can advertise the DNS Zone suffix - along with the prefix information to the nodes on the links to which - the router is connected to. Note that the R1 must be configured with - the DNS Zone suffix Information manually. - - - - -Park & Madanapalli Expires October 2003 [Page 11] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---+ +---+ - | H3+ | H4| - +-+-+ +-+-+ - | | - | LINK2 | - +---+ ---+--------+--+-- +----------+ - | H1| | |DNS Server| - +-+-+ | +----+-----+ - | +--+-+ -------/ - | LINK 1 | | / - ---+-----+------------------+ R1 +---------+ - | | | DDNS UPDATE - | +----+ - +-+-+ 6DNAC Server - | H2| - +---+ - - - H1, H2 - 6DNAC Clients on Link1 - H3, H4 - 6DNAC Clients on Link2 - R1 - Router with 6DNAC Server, serving both Link1 and Link2 - - - - - - 7.2. 6DNAC Operational Scenarios - - This section provides message sequence charts for various 6DNAC - operational scenarios assuming that the 6DNAC Server is implemented - on a router. All the scenarios assume that the normal boot up time - stateless address autoconfiguration of Link Local address derived - from the Interface Identifier has been completed successfully. And - it is also assumed that the router is already configured with the - DNS Zone Suffix Information. - - - Legend: - - 6DNAC-A, B, C : 6DNAC Clients - 6DNAC-S : 6DNAC Server/Router - DAD : Duplicate Address Detection - DFQDND : Duplicate Domain Name Detection - DNS-S : DNS Server - - - 7.2.1. Domain Name Registration-Successful Case - - This scenario starts when a 6DNAC Client receives RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and wants configure its IPv6 address (Global - or Site Local) and domain name. It is Assumed that the - DupAddrDetectTransmits is set to 1. - - - - -Park & Madanapalli Expires October 2003 [Page 12] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---------+ +---------+ +---------+ - | 6DNAC-C | | 6DNAC-S | | DNS-S | - +----+----+ +----+----+ +----+----+ - | | | - | RA with | | - | DNS Suffix Opt | | - |<---------------| | - | #1 | | - |---+ | | - Construct |#2 | | - FQDN | | | - |<--+ | | -DAD/DFQDND Starts | | - | | | - | | | - | NS With | | - | FQDN Opt | | - |--------------->| | - | #3 | | - | | | - | |------+ | - | Create FQDN | #4 | - | | | - | |<-----+ | - | | | - | | Register FQDN | - | |--------------->| - | | #5 | - | #6 | | - |--------+ | | - No Response | | | - DFQDND-Success | | | - |<-------+ | | - | | | - | | | - v V v - - - - - - #1. 6DNAC Server (Router) sends out router advertisement with DNS - Suffix information along with other parameters as specified in - NDP [2461]. - - #2. 6DNAC Client processes the router advertisement and constructs - the FQDN by prefixing hostname to the DNS Zone Suffix. It also - constructs IPv6 address from the autoconfiguration prefix - information option. - - #3. 6DNAC Client starts duplicate address & FQDN detection for the - IPv6 address & FQDN constructed and sends out a Neighbor - Solicitation message with FQDN option. - - Note that the DAD packets must be addressed to all nodes multicast - address if Router Alert option is not used. - -Park & Madanapalli Expires October 2003 [Page 13] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #4. 6DNAC Server processes the Neighbor Solicitation message sent by - 6DNAC Client as part of duplicate FQDN detection procedure and - creates a FQDN entry in its FQDN Cache (assuming that there is no - entry ), where C is Link Layer Address of the 6DNAC Client. - - #5. 6DNAC Server then registers FQDN and corresponding IPv6 address - through the existing protocol DDNS UPDATE. - - #6. 6DNAC Client times out and observes that there is no response to - defend its duplicate FQDN detection procedure and the node is - successful in configuring its domain name. - - Note that, Stateless Address Autoconfiguration DAD procedure is not - depicted in the following message sequence chart, which simultaneously - happens along with duplicate FQDN detection. - - - 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 - - This scenario starts when a 6DNAC Client receives RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and wants configure its IPv6 address (Global - or Site Local) and domain name. The node is configured with - DupAddrDetectTransmits = 2 for reliability in delivering DAD messages. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 14] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---------+ +---------+ +---------+ - | 6DNAC-C | | 6DNAC-S | | DNS-S | - +----+----+ +----+----+ +----+----+ - | | | - | RA with | | - | DNS Suffix Opt | | - |<---------------| | - | #1 | | - |---+ | | - Construct |#2 | | - FQDN | | | - |<--+ | | -DAD/DFQDND Starts | | - | | | - | | | - | NS With | | - | FQDN Opt | | - |--------------->| | - | #3 | | - | | | - | |------+ | - | Create FQDN | #4 | - | | | - | |<-----+ | - | | | - | | Register FQDN | - | |--------------->| - | | #5 | - | NS With | | - | FQDN Opt | | - |--------------->| | - | #6 | | - | | | - | Lookup FQDN | - | Entry exists | - | |------+ | - | Ignore | #7 | - | |<-----+ | - | #8 | | - |--------+ | | - No Response | | | - DFQDND-Success | | | - |<-------+ | | - | | | - | | | - v V v - - - - - - - Steps from #1 to #5 are same as that of scenario.7.2.1. - - #6. 6DNAC Client sends out second Neighbor Solicitation message with - FQDN option as part of duplicate FQDN detection. - -Park & Madanapalli Expires October 2003 [Page 15] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #7. 6DNAC Server receives and observes that the FQDN Cache exactly - matches with that of the NS information and ignores the NS message. - - #8. 6DNAC Client times out and observes that there is no response to - defend its duplicate FQDN detection procedure and the node is - successful in configuring its domain name.. - - - 7.2.3. Domain Name Registration-Defend Case - - This scenario starts when two 6DNAC Client receive RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and both the nodes want configure their IPv6 - address (Global or Site Local) and domain name. In this scenario both - the nodes want to have same domain name. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 16] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - - +---------+ +---------+ +---------+ +---------+ - | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | - +----+----+ +----+----+ +----+----+ +----+----+ - | | | | - | RA with | RA with | | - | DNS Suffix Opt | DNS Suffix Opt | | - |<---------------|--------------->| | - | #1 | #1 | | - |---+ | |---+ | - Construct | #2 | Construct | #2 | - FQDN | | FQDN | | - |<--+ | |<--+ | - DAD/DFQDND Starts | DAD/DFQDND Starts | - | | | - | | | | - | NS with | | | - | FQDN Opt | | | - |--------------->| | | - | #3 | | | - | No Entry | | - | |------+ | | - | Create FQDN | #4 | | - | | | | - | |<-----+ | | - | | | | - | | Register FQDN #5 | - | |-------------------------------->| - | | | | - | | NS with | | - | | FQDN Opt | | - | |<---------------| | - | | #6 | | - | |------+ | | - | FQDN is in use| | | - | Defend DFQDND| #7 | | - | |<-----+ | | - | | | | - | | NA with | | - | | D-flag Set | | - | |--------------->| | - | | #8 | | - |------+ | |---+ | - No Response | #9 | Enter | #10 | - DFQDND Success| | Retry Mode| | - |<-----+ | |<--+ | - | | | | - v v v v - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 17] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #1. 6DNAC Server (Router) sends out router advertisement with DNS - Suffix information. - - #2. 6DNAC Clients A&B process the router advertisement and construct - their FQDN by prefixing hostname to the DNS Zone Suffix. They - also construct IPv6 address from the autoconfiguration prefix - information option. - - When each host is trying to go for DAD, all hosts must have - random delay to avoid the traffic congestion according to [2461]. - So here it is assumed that 6DNAC Client-A starts DAD first and - 6DNAC Client-B starts DAD later. - - #3. 6DNAC Client-A starts duplicate address & FQDN detection for the - IPv6 address & FQDN constructed and sends out a Neighbor - Solicitation message with FQDN option. - - #4. 6DNAC Server processes the Neighbor Solicitation message sent by - 6DNAC Client-A as part of duplicate FQDN detection procedure and - creates a FQDN entry in its FQDN Cache (assuming that there is no - entry ), where A is Link Layer Address of the 6DNAC Client-A. - - #5. 6DNAC Server then registers FQDN and corresponding IPv6 address - through the existing protocol DDNS UPDATE. - - #6. 6DNAC Client-B starts duplicate address & FQDN detection for the - IPv6 address & FQDN constructed and sends out a Neighbor Solicitation - message with FQDN option. - - #7. 6DNAC Server processes the Neighbor Solicitation message sent by - 6DNAC Client-B as part of duplicate FQDN detection procedure and - finds that the domain name is already in use by the 6DNAC Client-A. - Hence, concludes to defend the duplicate FQDN detection of 6DNAC - Client-B. - - #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN - option to 6DNAC Client-B to defend its duplicate FQDN detection. - - #9. 6DNAC Client-A times out and observes that there is no response to - defend its duplicate FQDN detection procedure and the node is - successful in configuring its domain name. - - #10. 6DNAC Client-B observes that there is a NA with FQDN option - indicating that the domain name is duplicate and enters Retry - Mode. In retry mode, 6DNAC Client constructs another FQDN based - on Host Naming Algorithm. The number of retries is defined by the - administrator and must be a configurable value. - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 18] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - 7.2.4. Domain Name Registration in Retry Mode - - Pre-Conditions: - - 1. Duplicate Address Detection has succeeded - 2. Duplicate FQDN Detection FAILED - 3. FQDN is the first FQDN one constructed and FAILED - 4. FQDN2 is the second FQDN to be constructed - 5. The Neighbor Solicitation in the 'Retry Mode' - carries unspecified address in its target field (NS*). - - +---------+ +---------+ +---------+ - | 6DNAC-C | | 6DNAC-S | | DNS-S | - +----+----+ +----+----+ +----+----+ - | | | - |--------+ | | - Construct | #1 | | - new FQDN2 | | | - |<-------+ | | - | | | - DFQDND Restarts | | - | | | - | | | - | NS* With | | - | FQDN Opt | | - |--------------->| | - | #2 | | - | | | - | No Entry | - | |------+ | - | Create FQDN | #3 | - | | | - | |<-----+ | - | | | - | | Register FQDN2 | - | |--------------->| - | | #4 | - | | | - |--------+ | | - No Response | #5 | | - DFQDND-Success | | | - |<-------+ | | - | | | - v V v - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 19] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm, - the DNS Zone Suffix, and it is FQDN2. - #2. It then starts Duplicate Detection only for Domain Name. 6DNAC - Client sends out NS with FQDN option and unspecified target - address. - - #3. 6DNAC Server processes the Retry Mode NS message and finds that - the FQDN2 is not in use and creates Cache entry as . - - #4. It then starts registration procedures with the DNS Server. - - #5. Meanwhile, 6DNAC Client timesout and observes that there is no - defending NA for its DFQDND NS sent out and successfully - configures its domain name. - - - 7.2.5. Domain Name Registration when DAD Fails - - Duplicate domain name detection and subsequent registration starts - if and only if the DAD for IPv6 address succeeds. If the DAD for - IPv6 address fails then no actions are taken for domain name. When - DAD fails for stateless address autoconfiguration, then the domain - configuration starts only when the address has been configured using - Stateful Address Configuration methods and the node is going on DAD - for this address. - - This scenario starts when a 6DNAC Client receives RA message with - DNS Zone Suffix and other parameters including address prefix as - specified in NDP [2461] and wants configure its IPv6 address (Global - or Site Local) and domain name. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 20] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - +---------+ +---------+ +---------+ +---------+ - | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | - +----+----+ +----+----+ +----+----+ +----+----+ - | | | | - | | | | - | RA with | | | - | DNS Suffix Opt | | | - |<---------------| | | - | #1 | | | - |-----+ | | | - Construct | | | | - FQDN& | #2 | | | - IPv6 Addr | | | | - |<----+ | | | - DAD/DFQDND Starts | | | - | | | | - | | | | - | NS with | | | - | FQDN Opt | | | - |--------------->+--------------->| | - | #3 | #3 | | - | No Entry | | - | |------+ | | - | Create FQDN | | | - | | #4 | | - | |<-----+ | | - | | | | - | | |------+ | - | | My IPv6 Addr| #5 | - | | |<-----+ | - | | Defend DAD | | - | | with NA | | - |<---------------+<---------------| | - | #6 | #6 | | - | Entry | | - | |------+ | | - | Delete FQDN | #7 | | - | |<-----+ | | - | | | | - |----+ | | | - DAD Failed | #8 | | | - Stop DFQDND | | | | - |<---+ | | | - | | | | - v v v v - - - - #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A. - - #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and - FQDN as per Host Naming Algorithm. - - #3. It then starts Duplicate address & FQDN Detection, for the newly - constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS - with FQDN option. - -Park & Madanapalli Expires October 2003 [Page 21] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - #4. 6DNAC Server processes the DAD/DFQDND NS message and finds - that there is no entry for the FQDN in its cache. And, - creates Cache entry as and starts a Registration - timer with RegistrationWaitTime seconds. - - #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is - in its unicast address list. - - #6. It then starts defending DAD by sending NA to all-nodes multicast. - - #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A. - And, deletes its FQDN Cache entry . - - #8. 6DNAC Client gets defending DAD-NA and desists from DAD. - And also, stops Duplicate FQDN Detection as well. - At this point the address must be configured using stateful - methods and the domain name registration starts with the DAD - for the newly constructed IPv6 address. - - 7.3. DNS Zone Suffix Discovery and FQDN Construction - - 7.3.1. Sending Router Advertisement Messages - - Routers send out Router Advertisement message periodically, - or in response to a Router Solicitation. Router should include - the DNS Zone Suffix Option in their advertisements. If the DNS - Zone Suffix changes (similar to Site Renumbering), then it should - advertise the Old Zone Suffix with zero Valid Lifetime and New - Zone Suffix with proper non-zero Valid Lifetime. In any other - case, a router should not send this option twice in a single - router advertisement. - - 7.3.2. Processing Router Advertisement Messages - - For each DNS Zone Suffix Option in Router Advertisement, - - a. 6DNAC node stores the Zone Suffix information in its local - database. Also, constructs FQDN as per Host Naming Algorithm. - - b. If the node has not configured FQDN yet, - - 1. If the node is going to perform DAD for either Site local or - Global Address, then it should include FQDN option to perform - Duplicate FQDN Detection in parallel with DAD. - - 2. If the node has already got either Site local or Global - address, then it should send out NS with FQDN option and - unspecified target address to perform Duplicate FQDN - Detection. - - c. If the node has already configured FQDN, and if the - advertisement carries two DNS Zone Suffix Options, - First DNS Zone Suffix should match with the configured FQDN - Suffix and its Valid Lifetime must be zero. Second DNS Zone - - - -Park & Madanapalli Expires October 2003 [Page 22] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - Suffix should have non-zero Valid Lifetime. In this case, the - node constructs new FQDN based on the new DNS Zone Suffix (from - second DNS Zone Suffix option), and perform Duplicate FQDN - Detection with unspecified target address. Also, it should - overwrite the old FQDN with the newly constructed FQDN. - - - 7.3.3. FQDN Lifetime expiry - - 6DNAC Server: - It should delete the FQDN cache entry and should de-register from - the DNS Server. - - 6DNAC Client: - It should send update to 6DNAC Server by restarting the Duplicate - FQDN Detection. - - 7.3.4. Host Naming Algorithm - - A node constructs FQDN by combining DNS Zone Suffix and the hostname - as depicted in the following diagram. - - +------------------+----------------------------------+ - | Host Name | Advertised Suffix | - +------------------+----------------------------------+ - -

- - A node can choose Host Name using any of the following methods: - - a. String form of random number generated from the Interface - Identifier. - - b. List of configured Host Names provided by the administrator. - - - The number of retries must be specified in this algorithm in - case of domain name duplication. - - - 7.4. Duplicate Domain Name Detection - - The procedure for detecting duplicated FQDNs uses Neighbor - Solicitation and Advertisement messages as described below. - - If a duplicate FQDN is detected during the procedure, the - FQDN cannot be assigned to the node. - - An FQDN on which the DFQDND Procedure is applied is said - to be tentative until the procedure has completed successfully. - A tentative FQDN is not considered "assigned to the node" in the - traditional sense. That is, the node must accept Neighbor - Advertisement message containing the tentative FQDN in the FQDN - Option. - - -Park & Madanapalli Expires October 2003 [Page 23] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - It should also be noted that DFQDN must be performed prior to - registering with DNS Server to prevent multiple nodes from using - the same FQDN simultaneously. All the Duplicate Address Detection - Neighbor Solicitation messages must carry Source Link Layer Address - Option as specified in NDP [2461]. - - The detection of duplicate FQDN can be achieved through one of the - following three types of procedures. - - 1. DAD with All Nodes Multicast Address - 2. DAD with Router Alert Option for 6DNAC. - 3. Explicit Detection of Duplicate Domain Name - - Even though three solutions are listed, authors prefer only one - procedure to be followed in future based on further analysis and - comments received from others. - - 7.4.1. DAD with All Nodes Multicast Address - - 7.4.1.1. Sending Neighbor Solicitation Messages - - 6DNAC Client sends Neighbor Solicitation Messages as part - of Duplicate Address Detection SLAAC [2462] with the following - extra information and modifications: - - a. Include FQDN Option in the DAD Neighbor Solicitation Message - b. Destination Address is set to All Nodes Multicast Address - - There may be a case where DAD has succeeded but DFQDND is in Retry - Mode. In such case, the Neighbor Solicitation must carry unspecified - address in the ICMP target address field and new domain name in FQDN - option to re-try the registration of the domain name. - - 7.4.1.2. Processing Neighbor Solicitation Messages - - 6DNAC Clients must ignore the FQDN option found in any of the - neighbor solicitation messages. - - 6DNAC Server processes FQDN Option found in the Duplicate Address - Detection Neighbor Solicitation Messages as described below: - - Lookup FQDN Cache for the domain name in FQDN Option. - - If the entry exists and - i. Link Layer Address matches with SLLA option, this is the case, - where node has changed its IPv6 address or updating the valid - life time. 6DNAC Server updates its cache and also updates DNS - Server using DDNS-UPDATE. If there is no change in IPv6 address - or life time then no updates are sent to the DNS server. - - ii. Link Layer Address differs with SLLA option, defend the duplicate - FQDN Detection by sending Neighbor Advertisement Message as - described in $7.4.1.3$. - - - -Park & Madanapalli Expires October 2003 [Page 24] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - else, - Lookup FQDN Cache for the Link Layer Address in SLLA Option. - - If the entry exists, update the FQDN Cache and update DNS Server - using DDNS-UPDATE. This is the case, where node has changed its - domain name (similar to Site Re-numbering). - - If then entry does not exists, then it means that this is the new - registration. It must create a cache entry and start Registration - - timer with RegistrationWaitTime. At the expiry of the Registration - timer, it should update DNS Server with DDNS-UPDATE. - - 7.4.1.3. Sending Neighbor Advertisement Messages - - 6DNAC Server sends Neighbor Advertisement Messages as part - of Duplicate Address Detection SLAAC [2462] with the FQDN Option - in Neighbor Advertisement message to defend duplicate FQDN - detection. - - There may be the case where defending of duplicate address detection - is not required but defending of FQDN is required. In such instance, - the defending Neighbor Advertisement must carry FQDN and unspecified - address in the ICMP target address field. - - 7.4.1.4. Processing Neighbor Advertisement Messages - - 6DNAC Server must ignore the any FQDN option found any of - the neighbor advertisement messages. If the Neighbor Advertisement - is a DAD defending, then it must delete its FQDN Cache entry created - on the reception of DAD Neighbor Solicitation message. - - When 6DNAC Clients gets the duplicate address detection neighbor - advertisement messages with FQDN option set it means that its - duplicate FQDN detection failed and enters Retry Mode. - - 7.4.1.5. Pros and Cons - - The advantage of this procedure is that it does not need any - extension header options to be included. The disadvantage of this - procedure is that, it needs change in the existing DAD procedure. - The change is only that the DAD neighbor solicitations are to be - addressed to all nodes multicast address instead of solicited - node multicast address. The another disadvantage is that, it needs - the existence of Duplicate Address Detection Procedure to - perform duplicate FQDN detection. - - 7.4.2. DAD with Router Alert Option for 6DNAC - - 7.4.2.1. Sending Neighbor Solicitation Messages - - 6DNAC Client sends Neighbor Solicitation Messages as part - of Duplicate Address Detection SLAAC [2462] with the following - extra information: - - -Park & Madanapalli Expires October 2003 [Page 25] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - a. Include Hop-by-Hop extension Header with Router Alert Option - for 6DNAC as described in IPv6 Router Alert Option[2711]. - - b. Include FQDN Option in the DAD Neighbor Solicitation Message - - 7.4.2.2. Processing Neighbor Solicitation Messages - - This is same as described in $7.4.1.2$. - - 7.4.2.3. Sending Neighbor Advertisement Messages - - This is same as described in $7.4.1.3$. - - 7.4.2.4. Processing Neighbor Advertisement Messages - - This is same as described in $7.4.1.4$. - - 7.4.2.5. Pros and Cons - - The advantage of this procedure is that it does not disturb - the existing implementation and their way of processing the - packets. The disadvantage is that, it needs the existence - of Duplicate Address Detection Procedure to perform duplicate - FQDN detection. Another disadvantage is that this procedure - requires 6DNAC Server functionality to be implemented on Router. - However, in this case 6DNAC Server can serve multiple links. - - 7.4.3. Explicit Detection of Duplicate Domain Name - - In this procedure Duplicate FQDN Detection starts after completion - of successful Site local or Global Address configuration. - - 7.4.3.1. Sending Neighbor Solicitation Messages - - 6DNAC Client sends Neighbor Solicitation Messages as part - of Duplicate FQDN Detection with the following information: - - a. Include FQDN Option in the Neighbor Solicitation Message - - b. Destination Address is set to All Nodes Multicast Address - or uses Router Alert Option for 6DNAC, when 6DNAC Server is - implemented on router. - - c. Target Address is set to Unspecified Address - - d. Other fields are set as per DAD SLAAC [2462]. - - 7.4.3.2. Processing Neighbor Solicitation Messages - - This is same as described in $7.4.1.2$. - - - - - - -Park & Madanapalli Expires October 2003 [Page 26] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - 7.4.3.3. Sending Neighbor Advertisement Messages - - This is same as described in $7.4.1.3$. - - 7.4.3.4. Processing Neighbor Advertisement Messages - - This is same as described in $7.4.1.4$. - - 7.4.3.5. Pros and Cons - - The advantage of this procedure is that it does not need the - existing duplicate address detection procedure. This is introduced - as the DAD procedure is found to be redundant in when IPv6 addresses - are constructed from the interface ID [DIID]. - - Note that, if 6DNAC Clients know the address of 6DNAC Server then - they can directly send DFQDND-NS to 6DNAC Server. - - 7.4.4. Retry Mode for Re-registering Domain Name - - In retry mode, nodes construct new FQDN as per Host Naming Algorithm. - Then they restart Duplicate FQDN Detection as described in $7.4.3$. - - - 7.5. Domain Name Registration - - 6DNAC Server must be an authenticated to update the DNS Server. - 6DNAC Server must also be configured with the DNS Server - information. - - 6DNAC Server detects the DNS information (IPv6 Address and - corresponding FQDN) from DAD/DFQDND messages and caches the - information. It also have an associated Registration Timer with - RegistrationWaitTime to wait for the successful completion of - DFQDND and update DNS Server using existing protocol DDNS UPDATE - [2136]. - - - 8. Security Consideration - - If someone wants to hijack correct Domain Name registration, they - could send a NS message with incorrect or same Domain Name to the - 6DNAC server repeatedly and server would start the Domain Name - registration through above mechanism, which is a security hole. - As described in [2461], a host can check validity of NDP messages. - If the NDP message include an IP Authentication Header, the message - authenticates correctly. For DNS UPDATE processing, secure DNS - Dynamic Update is described in [3007]. - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 27] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - 9. IANA Consideration - - Values in the Router Alert Option are registered and maintained by - IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is - required to assign the Type values for DNS Zone Suffix Information - option and FADN option. - - - 10. Acknowledgement - - Special thanks are due to Badrinarayana N.S. and Christian Huitema for - many helpful suggestions and revisions. - - - 11. Intellectual Property - - The following notice is copied from RFC 2026 [Bradner, 1996], - Section 10.4, and describes the position of the IETF concerning - intellectual property claims made against this document. - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use other technology described in - - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances - of licenses to be made available, or the result of an attempt made - to obtain a general license or permission for the use of such - proprietary rights by implementers or users of this specification - can be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - 12. Copyright - - The following copyright notice is copied from RFC 2026 [Bradner, - 1996], Section 10.4, and describes the applicable copyright for this - document. - - Copyright (C) The Internet Society July 12, 2001. All Rights - Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - -Park & Madanapalli Expires October 2003 [Page 28] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - 13. References - - [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - [2460] Deering, S. abd R. Hinden, "Internet Protocol, - Version 6 (IPv6) Specification", RFC 2460, - December 1998. - - [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor - Discovery for IP version 6(IPv6)", RFC 2461, December - 1998. - - [2462] S. Thomson and Narten T, "IPv6 Stateless Address Auto- - Configuration", RFC 2462, December 1998. - - [2711] C. Patridge and A.Jackson, "IPv6 Router Alert Option", - RFC 2711, October 1999. - - [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND - FACILITIES", RFC 1034, November 1987. - - [1035] P. Mockapetris, "Domain Names - Implementation and - Specification" RFC 1035, November 1987. - - [2136] P. Vixie et al., "Dynamic Updates in the Domain Name - System (DNS UPDATE)", RFC2136, April 1997. - - [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - -Park & Madanapalli Expires October 2003 [Page 29] - -INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 - - - [DIID] yokohama-dad-vs-diid.pdf - at http://playground.sun.com/ipng/presentations/July2002/ - - [DNSISSUES] Durand, A., "IPv6 DNS transition issues", draft-ietf- - dnsop-ipv6-dns-issues-00.txt, work in progress. - - [PREFIX] S. Miyakawa, R. Droms, "Requirements for IPv6 prefix - delegation", draft-ietf-ipv6-prefix-delegation- - requirement-01.txt, work in progress. - - [Autoreg] H. Kitamura, "Domain Name Auto-Registration for - Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name- - auto-reg-00.txt, work in progress. - - [NIQ] Matt Crawford, "IPv6 Node Information Queries", , work in progress. - - - 14. Author's Addresses - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics, KOREA - Phone: +82-31-200-3728 - Email:soohong.park@samsung.com - - Syam Madanapalli - Network Systems Division, SAMSUNG India Software Operations, INDIA - Phone: +91-80-5550555 - Email:syam@samsung.com - - - - - - - - - - - - - - - - - - - - - - - - - - - -Park & Madanapalli Expires October 2003 [Page 30] diff --git a/doc/rfc/index b/doc/rfc/index index 2858658729..5d48ee4e6e 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -106,6 +106,8 @@ 4159: Deprecation of "ip6.int" 4193: Unique Local IPv6 Unicast Addresses 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints +4294: IPv6 Node Requirements +4339: IPv6 Host Configuration of DNS Server Information Approaches 4343: Domain Name System (DNS) Case Insensitivity Clarification 4367: What's in a Name: False Assumptions about DNS Names 4398: Storing Certificates in the Domain Name System (DNS) @@ -114,11 +116,13 @@ in E-Mail, Version 1 4470: Minimally Covering NSEC Records and DNSSEC On-line Signing 4471: Derivation of DNS Name Predecessor and Successor +4472: Operational Considerations and Issues with IPv6 DNS 4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) 4634: US Secure Hash Algorithms (SHA and HMAC-SHA) 4635: HMAC SHA TSIG Algorithm Identifiers 4641: DNSSEC Operational Practices 4648: The Base16, Base32, and Base64 Data Encodings +4697: Observed DNS Resolution Misbehavior 4701: A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) 4892: Requirements for a Mechanism Identifying a Name Server Instance diff --git a/doc/rfc/rfc4294.txt b/doc/rfc/rfc4294.txt new file mode 100644 index 0000000000..8fea5c311b --- /dev/null +++ b/doc/rfc/rfc4294.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group J. Loughney, Ed. +Request for Comments: 4294 Nokia +Category: Informational April 2006 + + + IPv6 Node Requirements + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document defines requirements for IPv6 nodes. It is expected + that IPv6 will be deployed in a wide range of devices and situations. + Specifying the requirements for IPv6 nodes allows IPv6 to function + well and interoperate in a large number of situations and + deployments. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirement Language .......................................3 + 1.2. Scope of This Document .....................................3 + 1.3. Description of IPv6 Nodes ..................................3 + 2. Abbreviations Used in This Document .............................3 + 3. Sub-IP Layer ....................................................4 + 3.1. Transmission of IPv6 Packets over Ethernet Networks + - RFC 2464 .................................................4 + 3.2. IP version 6 over PPP - RFC 2472 ...........................4 + 3.3. IPv6 over ATM Networks - RFC 2492 ..........................4 + 4. IP Layer ........................................................5 + 4.1. Internet Protocol Version 6 - RFC 2460 .....................5 + 4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5 + 4.3. Path MTU Discovery and Packet Size .........................6 + 4.4. ICMP for the Internet Protocol Version 6 (IPv6) - + RFC 2463 ...................................................7 + 4.5. Addressing .................................................7 + 4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8 + 5. DNS and DHCP ....................................................8 + 5.1. DNS ........................................................8 + + + + +Loughney Informational [Page 1] + +RFC 4294 IPv6 Node Requirements April 2006 + + + 5.2. Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) - RFC 3315 ........................................9 + 6. IPv4 Support and Transition ....................................10 + 6.1. Transition Mechanisms .....................................10 + 7. Mobile IP ......................................................10 + 8. Security .......................................................10 + 8.1. Basic Architecture ........................................10 + 8.2. Security Protocols ........................................11 + 8.3. Transforms and Algorithms .................................11 + 8.4. Key Management Methods ....................................12 + 9. Router-Specific Functionality ..................................12 + 9.1. General ...................................................12 + 10. Network Management ............................................12 + 10.1. Management Information Base Modules (MIBs) ...............12 + 11. Security Considerations .......................................13 + 12. References ....................................................13 + 12.1. Normative References .....................................13 + 12.2. Informative References ...................................16 + 13. Authors and Acknowledgements ..................................18 + +1. Introduction + + The goal of this document is to define the common functionality + required from both IPv6 hosts and routers. Many IPv6 nodes will + implement optional or additional features, but this document + summarizes requirements from other published Standards Track + documents in one place. + + This document tries to avoid discussion of protocol details, and + references RFCs for this purpose. This document is informational in + nature and does not update Standards Track RFCs. + + Although the document points to different specifications, it should + be noted that in most cases, the granularity of requirements are + smaller than a single specification, as many specifications define + multiple, independent pieces, some of which may not be mandatory. + + As it is not always possible for an implementer to know the exact + usage of IPv6 in a node, an overriding requirement for IPv6 nodes is + that they should adhere to Jon Postel's Robustness Principle: + + Be conservative in what you do, be liberal in what you accept from + others [RFC-793]. + + + + + + + + +Loughney Informational [Page 2] + +RFC 4294 IPv6 Node Requirements April 2006 + + +1.1. Requirement Language + + 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 RFC 2119 [RFC-2119]. + +1.2. Scope of This Document + + IPv6 covers many specifications. It is intended that IPv6 will be + deployed in many different situations and environments. Therefore, + it is important to develop the requirements for IPv6 nodes to ensure + interoperability. + + This document assumes that all IPv6 nodes meet the minimum + requirements specified here. + +1.3. Description of IPv6 Nodes + + From the Internet Protocol, Version 6 (IPv6) Specification + [RFC-2460], we have the following definitions: + + Description of an IPv6 Node + + - a device that implements IPv6. + + Description of an IPv6 router + + - a node that forwards IPv6 packets not explicitly addressed + to itself. + + Description of an IPv6 Host + + - any node that is not a router. + +2. Abbreviations Used in This Document + + ATM Asynchronous Transfer Mode + + AH Authentication Header + + DAD Duplicate Address Detection + + ESP Encapsulating Security Payload + + ICMP Internet Control Message Protocol + + IKE Internet Key Exchange + + + + +Loughney Informational [Page 3] + +RFC 4294 IPv6 Node Requirements April 2006 + + + MIB Management Information Base + + MLD Multicast Listener Discovery + + MTU Maximum Transfer Unit + + NA Neighbor Advertisement + + NBMA Non-Broadcast Multiple Access + + ND Neighbor Discovery + + NS Neighbor Solicitation + + NUD Neighbor Unreachability Detection + + PPP Point-to-Point Protocol + + PVC Permanent Virtual Circuit + + SVC Switched Virtual Circuit + +3. Sub-IP Layer + + An IPv6 node must include support for one or more IPv6 link-layer + specifications. Which link-layer specifications are included will + depend upon what link-layers are supported by the hardware available + on the system. It is possible for a conformant IPv6 node to support + IPv6 on some of its interfaces and not on others. + + As IPv6 is run over new layer 2 technologies, it is expected that new + specifications will be issued. This section highlights some major + layer 2 technologies and is not intended to be complete. + +3.1. Transmission of IPv6 Packets over Ethernet Networks - RFC 2464 + + Nodes supporting IPv6 over Ethernet interfaces MUST implement + Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. + +3.2. IP version 6 over PPP - RFC 2472 + + Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP + [RFC-2472]. + +3.3. IPv6 over ATM Networks - RFC 2492 + + Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM + Networks [RFC-2492]. Additionally, RFC 2492 states: + + + +Loughney Informational [Page 4] + +RFC 4294 IPv6 Node Requirements April 2006 + + + A minimally conforming IPv6/ATM driver SHALL support the PVC mode + of operation. An IPv6/ATM driver that supports the full SVC mode + SHALL also support PVC mode of operation. + +4. IP Layer + +4.1. Internet Protocol Version 6 - RFC 2460 + + The Internet Protocol Version 6 is specified in [RFC-2460]. This + specification MUST be supported. + + Unrecognized options in Hop-by-Hop Options or Destination Options + extensions MUST be processed as described in RFC 2460. + + The node MUST follow the packet transmission rules in RFC 2460. + + Nodes MUST always be able to send, receive, and process fragment + headers. All conformant IPv6 implementations MUST be capable of + sending and receiving IPv6 packets; the forwarding functionality MAY + be supported. + + RFC 2460 specifies extension headers and the processing for these + headers. + + A full implementation of IPv6 includes implementation of the + following extension headers: Hop-by-Hop Options, Routing (Type 0), + Fragment, Destination Options, Authentication and Encapsulating + Security Payload [RFC-2460]. + + An IPv6 node MUST be able to process these headers. It should be + noted that there is some discussion about the use of Routing Headers + and possible security threats [IPv6-RH] that they cause. + +4.2. Neighbor Discovery for IPv6 - RFC 2461 + + Neighbor Discovery SHOULD be supported. [RFC-2461] states: + + "Unless specified otherwise (in a document that covers operating + IP over a particular link type) this document applies to all link + types. However, because ND uses link-layer multicast for some of + its services, it is possible that on some link types (e.g., NBMA + links) alternative protocols or mechanisms to implement those + services will be specified (in the appropriate document covering + the operation of IP over a particular link type). The services + described in this document that are not directly dependent on + multicast, such as Redirects, Next-hop determination, Neighbor + Unreachability Detection, etc., are expected to be provided as + + + + +Loughney Informational [Page 5] + +RFC 4294 IPv6 Node Requirements April 2006 + + + specified in this document. The details of how one uses ND on + NBMA links is an area for further study." + + Some detailed analysis of Neighbor Discovery follows: + + Router Discovery is how hosts locate routers that reside on an + attached link. Router Discovery MUST be supported for + implementations. + + Prefix Discovery is how hosts discover the set of address prefixes + that define which destinations are on-link for an attached link. + Prefix discovery MUST be supported for implementations. Neighbor + Unreachability Detection (NUD) MUST be supported for all paths + between hosts and neighboring nodes. It is not required for paths + between routers. However, when a node receives a unicast Neighbor + Solicitation (NS) message (that may be a NUD's NS), the node MUST + respond to it (i.e., send a unicast Neighbor Advertisement). + + Duplicate Address Detection MUST be supported on all links supporting + link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take + place on all unicast addresses). + + A host implementation MUST support sending Router Solicitations. + + Receiving and processing Router Advertisements MUST be supported for + host implementations. The ability to understand specific Router + Advertisement options is dependent on supporting the specification + where the RA is specified. + + Sending and Receiving Neighbor Solicitation (NS) and Neighbor + Advertisement (NA) MUST be supported. NS and NA messages are + required for Duplicate Address Detection (DAD). + + Redirect functionality SHOULD be supported. If the node is a router, + Redirect functionality MUST be supported. + +4.3. Path MTU Discovery and Packet Size + +4.3.1. Path MTU Discovery - RFC 1981 + + Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal + implementations MAY choose to not support it and avoid large packets. + The rules in RFC 2460 MUST be followed for packet fragmentation and + reassembly. + +4.3.2. IPv6 Jumbograms - RFC 2675 + + IPv6 Jumbograms [RFC-2675] MAY be supported. + + + +Loughney Informational [Page 6] + +RFC 4294 IPv6 Node Requirements April 2006 + + +4.4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463 + + ICMPv6 [RFC-2463] MUST be supported. + +4.5. Addressing + +4.5.1. IP Version 6 Addressing Architecture - RFC 3513 + + The IPv6 Addressing Architecture [RFC-3513] MUST be supported as + updated by [RFC-3879]. + +4.5.2. IPv6 Stateless Address Autoconfiguration - RFC 2462 + + IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. + This specification MUST be supported for nodes that are hosts. + Static address can be supported as well. + + Nodes that are routers MUST be able to generate link local addresses + as described in RFC 2462 [RFC-2462]. + + From 2462: + + The autoconfiguration process specified in this document applies + only to hosts and not routers. Since host autoconfiguration uses + information advertised by routers, routers will need to be + configured by some other means. However, it is expected that + routers will generate link-local addresses using the mechanism + described in this document. In addition, routers are expected to + successfully pass the Duplicate Address Detection procedure + described in this document on all addresses prior to assigning + them to an interface. + + Duplicate Address Detection (DAD) MUST be supported. + +4.5.3. Privacy Extensions for Address Configuration in IPv6 - RFC 3041 + + Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] + SHOULD be supported. It is recommended that this behavior be + configurable on a connection basis within each application when + available. It is noted that a number of applications do not work + with addresses generated with this method, while other applications + work quite well with them. + +4.5.4. Default Address Selection for IPv6 - RFC 3484 + + The rules specified in the Default Address Selection for IPv6 + [RFC-3484] document MUST be implemented. It is expected that IPv6 + nodes will need to deal with multiple addresses. + + + +Loughney Informational [Page 7] + +RFC 4294 IPv6 Node Requirements April 2006 + + +4.5.5. Stateful Address Autoconfiguration + + Stateful Address Autoconfiguration MAY be supported. DHCPv6 + [RFC-3315] is the standard stateful address configuration protocol; + see Section 5.3 for DHCPv6 support. + + Nodes which do not support Stateful Address Autoconfiguration may be + unable to obtain any IPv6 addresses, aside from link-local addresses, + when it receives a router advertisement with the 'M' flag (Managed + address configuration) set and that contains no prefixes advertised + for Stateless Address Autoconfiguration (see Section 4.5.2). + Additionally, such nodes will be unable to obtain other configuration + information, such as the addresses of DNS servers when it is + connected to a link over which the node receives a router + advertisement in which the 'O' flag ("Other stateful configuration") + is set. + +4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 + + Nodes that need to join multicast groups SHOULD implement MLDv2 + [RFC-3810]. However, if the node has applications that only need + support for Any-Source Multicast [RFC-3569], the node MAY implement + MLDv1 [RFC-2710] instead. If the node has applications that need + support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node + MUST support MLDv2 [RFC-3810]. + + When MLD is used, the rules in the "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be + followed. + +5. DNS and DHCP + +5.1. DNS + + DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363], + and [RFC-3596]. Not all nodes will need to resolve names; those that + will never need to resolve DNS names do not need to implement + resolver functionality. However, the ability to resolve names is a + basic infrastructure capability that applications rely on and + generally needs to be supported. All nodes that need to resolve + names SHOULD implement stub-resolver [RFC-1034] functionality, as in + RFC 1034, Section 5.3.1, with support for: + + - AAAA type Resource Records [RFC-3596]; + + - reverse addressing in ip6.arpa using PTR records [RFC-3152]; + + + + + +Loughney Informational [Page 8] + +RFC 4294 IPv6 Node Requirements April 2006 + + + - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 + octets. + + Those nodes are RECOMMENDED to support DNS security extensions + [RFC-4033], [RFC-4034], and [RFC-4035]. + + Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC-3363]. + +5.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 + +5.2.1. Managed Address Configuration + + The method by which IPv6 nodes that use DHCP for address assignment + can obtain IPv6 addresses and other configuration information upon + receipt of a Router Advertisement with the 'M' flag set is described + in Section 5.5.3 of RFC 2462. + + In addition, in the absence of a router, those IPv6 nodes that use + DHCP for address assignment MUST initiate DHCP to obtain IPv6 + addresses and other configuration information, as described in + Section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP for + address assignment can ignore the 'M' flag in Router Advertisements. + +5.2.2. Other Configuration Information + + The method by which IPv6 nodes that use DHCP to obtain other + configuration information can obtain other configuration information + upon receipt of a Router Advertisement with the 'O' flag set is + described in Section 5.5.3 of RFC 2462. + + Those IPv6 nodes that use DHCP to obtain other configuration + information initiate DHCP for other configuration information upon + receipt of a Router Advertisement with the 'O' flag set, as described + in Section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP + for other configuration information can ignore the 'O' flag in Router + Advertisements. + + An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to + obtain other configuration information. + +5.3.3. Use of Router Advertisements in Managed Environments + + Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + are expected to determine their default router information and on- + link prefix information from received Router Advertisements. + + + + + +Loughney Informational [Page 9] + +RFC 4294 IPv6 Node Requirements April 2006 + + +6. IPv4 Support and Transition + + IPv6 nodes MAY support IPv4. + +6.1. Transition Mechanisms + +6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893 + + If an IPv6 node implements dual stack and tunneling, then [RFC-4213] + MUST be supported. + +7. Mobile IP + + The Mobile IPv6 [RFC-3775] specification defines requirements for the + following types of nodes: + + - mobile nodes + + - correspondent nodes with support for route optimization + + - home agents + + - all IPv6 routers + + Hosts MAY support mobile node functionality described in Section 8.5 + of [RFC-3775], including support of generic packet tunneling [RFC- + 2473] and secure home agent communications [RFC-3776]. + + Hosts SHOULD support route optimization requirements for + correspondent nodes described in Section 8.2 of [RFC-3775]. + + Routers SHOULD support the generic mobility-related requirements for + all IPv6 routers described in Section 8.3 of [RFC-3775]. Routers MAY + support the home agent functionality described in Section 8.4 of + [RFC-3775], including support of [RFC-2473] and [RFC-3776]. + +8. Security + + This section describes the specification of IPsec for the IPv6 node. + +8.1. Basic Architecture + + Security Architecture for the Internet Protocol [RFC-4301] MUST be + supported. + + + + + + + +Loughney Informational [Page 10] + +RFC 4294 IPv6 Node Requirements April 2006 + + +8.2. Security Protocols + + ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported. + +8.3. Transforms and Algorithms + + Current IPsec RFCs specify the support of transforms and algorithms + for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and + HMAC-MD5-96. However, "Cryptographic Algorithm Implementation + Requirements For ESP And AH" [RFC-4305] contains the current set of + mandatory to implement algorithms for ESP and AH. It also specifies + algorithms that should be implemented because they are likely to be + promoted to mandatory at some future time. IPv6 nodes SHOULD conform + to the requirements in [RFC-4305], as well as the requirements + specified below. + + Since ESP encryption and authentication are both optional, support + for the NULL encryption algorithm [RFC-2410] and the NULL + authentication algorithm [RFC-4303] MUST be provided to maintain + consistency with the way these services are negotiated. However, + while authentication and encryption can each be NULL, they MUST NOT + both be NULL. The NULL encryption algorithm is also useful for + debugging. + + The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported + within ESP. Security issues related to the use of DES are discussed + in [DESDIFF], [DESINT], and [DESCRACK]. DES-CBC is still listed as + required by the existing IPsec RFCs, but updates to these RFCs will + be published in the near future. DES provides 56 bits of protection, + which is no longer considered sufficient. + + The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP + MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC-2403] + within AH and ESP MAY also be supported. + + The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the + same security issues as DES-CBC, and the 3DES-CBC algorithm within + ESP MUST be supported to ensure interoperability. + + The AES-128-CBC algorithm [RFC-3602] MUST also be supported within + ESP. AES-128 is expected to be a widely available, secure, and + efficient algorithm. While AES-128-CBC is not required by the + current IPsec RFCs, it is expected to become required in the future. + + + + + + + + +Loughney Informational [Page 11] + +RFC 4294 IPv6 Node Requirements April 2006 + + +8.4. Key Management Methods + + An implementation MUST support the manual configuration of the + security key and SPI. The SPI configuration is needed in order to + delineate between multiple keys. + + Key management SHOULD be supported. Examples of key management + systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include + key management functions. + + Where key refresh, anti-replay features of AH and ESP, or on-demand + creation of Security Associations (SAs) is required, automated keying + MUST be supported. + + Key management methods for multicast traffic are also being worked on + by the MSEC WG. + +9. Router-Specific Functionality + + This section defines general host considerations for IPv6 nodes that + act as routers. Currently, this section does not discuss routing- + specific requirements. + +9.1. General + +9.1.1. IPv6 Router Alert Option - RFC 2711 + + The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- + Hop Header that is used in conjunction with some protocols (e.g., + RSVP [RFC-2205] or MLD [RFC-2710]). The Router Alert option will + need to be implemented whenever protocols that mandate its usage are + implemented. See Section 4.6. + +9.1.2. Neighbor Discovery for IPv6 - RFC 2461 + + Sending Router Advertisements and processing Router Solicitation MUST + be supported. + +10. Network Management + + Network Management MAY be supported by IPv6 nodes. However, for IPv6 + nodes that are embedded devices, network management may be the only + possible way of controlling these nodes. + +10.1. Management Information Base Modules (MIBs) + + The following two MIBs SHOULD be supported by nodes that support an + SNMP agent. + + + +Loughney Informational [Page 12] + +RFC 4294 IPv6 Node Requirements April 2006 + + +10.1.1. IP Forwarding Table MIB + + IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that + support an SNMP agent. + +10.1.2. Management Information Base for the Internet Protocol (IP) + + IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP + agent. + +11. Security Considerations + + This document does not affect the security of the Internet, but + implementations of IPv6 are expected to support a minimum set of + security features to ensure security on the Internet. "IP Security + Document Roadmap" [RFC-2411] is important for everyone to read. + + The security considerations in RFC 2460 state the following: + + The security features of IPv6 are described in the Security + Architecture for the Internet Protocol [RFC-2401]. + + RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for + the security features of IPv6. + +12. References + +12.1. Normative References + + [RFC-1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [RFC-2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 + within ESP and AH", RFC 2403, November 1998. + + [RFC-2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 + within ESP and AH", RFC 2404, November 1998. + + + + +Loughney Informational [Page 13] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm + and Its Use With IPsec", RFC 2410, November 1998. + + [RFC-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security + Document Roadmap", RFC 2411, November 1998. + + [RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC-2463] Conta, A. and S. Deering, "Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 + (IPv6) Specification", RFC 2463, December 1998. + + [RFC-2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC + 2472, December 1998. + + [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in + IPv6 Specification", RFC 2473, December 1998. + + [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC-2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert + Option", RFC 2711, October 1999. + + [RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC + 3041, January 2001. + + [RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + + +Loughney Informational [Page 14] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC-3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and + T. Hain, "Representing Internet Protocol version 6 + (IPv6) Addresses in the Domain Name System (DNS)", RFC + 3363, August 2002. + + [RFC-3484] Frye, R., Levi, D., Routhier, S., and B. Wijnen, + "Coexistence between Version 1, Version 2, and Version + 3 of the Internet-standard Network Management + Framework", BCP 74, RFC 3584, August 2003. + + [RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version + 6 (IPv6) Addressing Architecture", RFC 3513, April + 2003. + + [RFC-3590] Haberman, B., "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol", RFC + 3590, September 2003. + + [RFC-3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [RFC-3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC + Cipher Algorithm and Its Use with IPsec", RFC 3602, + September 2003. + + [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility + Support in IPv6", RFC 3775, June 2004. + + [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using + IPsec to Protect Mobile IPv6 Signaling Between Mobile + Nodes and Home Agents", RFC 3776, June 2004. + + [RFC-3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [RFC-3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + [RFC-4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, + April 2006. + + [RFC-4293] Routhier, S., Ed., "Management Information Base for + the Internet Protocol (IP)", RFC 4293, April 2006. + + + +Loughney Informational [Page 15] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-4301] Kent, S. and R. Atkinson, "Security Architecture for + the Internet Protocol", RFC 4301, December 2005. + + [RFC-4302] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [RFC-4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + [RFC-4305] Eastlake 3rd, D., "Cryptographic Algorithm + Implementation Requirements for Encapsulating Security + Payload (ESP) and Authentication Header (AH)", RFC + 4305, December 2005. + +12.2. Informative References + + [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of + DES-like cryptosystems", Journal of Cryptology Vol 4, + Jan 1991. + + [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA + 2000. + + [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without + Strong Integrity", Proceedings of the 32nd IETF, + Danvers, MA, April 1995. + + [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home + Address Options", Work in Progress. + + [RFC-793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC-1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- + Version 1 Functional Specification", RFC 2205, + September 1997. + + [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over + Ethernet Networks", RFC 2464, December 1998. + + [RFC-2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over + ATM Networks", RFC 2492, January 1999. + + + + + +Loughney Informational [Page 16] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-2675] Borman, D., Deering, S., and R. Hinden, "IPv6 + Jumbograms", RFC 2675, August 1999. + + [RFC-4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + [RFC-3569] Bhattacharyya, S., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [RFC-3736] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP) Service for IPv6", RFC 3736, April + 2004. + + [RFC-4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet + Network Addresses", RFC 4001, February 2005. + + [RFC-4033] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC-4034] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. + + [RFC-4035] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC-4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) + Protocol", RFC 4306, December 2005. + + [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for + IP", Work in Progress. + + + + + + + + + + + + + + + + +Loughney Informational [Page 17] + +RFC 4294 IPv6 Node Requirements April 2006 + + +13. Authors and Acknowledgements + + This document was written by the IPv6 Node Requirements design team: + + Jari Arkko + [jari.arkko@ericsson.com] + + Marc Blanchet + [marc.blanchet@viagenie.qc.ca] + + Samita Chakrabarti + [samita.chakrabarti@eng.sun.com] + + Alain Durand + [alain.durand@sun.com] + + Gerard Gastaud + [gerard.gastaud@alcatel.fr] + + Jun-ichiro itojun Hagino + [itojun@iijlab.net] + + Atsushi Inoue + [inoue@isl.rdc.toshiba.co.jp] + + Masahiro Ishiyama + [masahiro@isl.rdc.toshiba.co.jp] + + John Loughney + [john.loughney@nokia.com] + + Rajiv Raghunarayan + [raraghun@cisco.com] + + Shoichi Sakane + [shouichi.sakane@jp.yokogawa.com] + + Dave Thaler + [dthaler@windows.microsoft.com] + + Juha Wiljakka + [juha.wiljakka@Nokia.com] + + The authors would like to thank Ran Atkinson, Jim Bound, Brian + Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas + Narten, Juha Ollila, and Pekka Savola for their comments. + + + + + +Loughney Informational [Page 18] + +RFC 4294 IPv6 Node Requirements April 2006 + + +Editor's Contact Information + + Comments or questions regarding this document should be sent to the + IPv6 Working Group mailing list (ipv6@ietf.org) or to: + + John Loughney + Nokia Research Center + Itamerenkatu 11-13 + 00180 Helsinki + Finland + + Phone: +358 50 483 6242 + EMail: John.Loughney@Nokia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney Informational [Page 19] + +RFC 4294 IPv6 Node Requirements April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Loughney Informational [Page 20] + diff --git a/doc/rfc/rfc4339.txt b/doc/rfc/rfc4339.txt new file mode 100644 index 0000000000..a6f29d9f43 --- /dev/null +++ b/doc/rfc/rfc4339.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group J. Jeong, Ed. +Request for Comments: 4339 ETRI/University of Minnesota +Category: Informational February 2006 + + + IPv6 Host Configuration of DNS Server Information Approaches + + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +IESG Note + + This document describes three different approaches for the + configuration of DNS name resolution server information in IPv6 + hosts. + + There is not an IETF consensus on which approach is preferred. The + analysis in this document was developed by the proponents for each + approach and does not represent an IETF consensus. + + The 'RA option' and 'Well-known anycast' approaches described in this + document are not standardized. Consequently the analysis for these + approaches might not be completely applicable to any specific + proposal that might be proposed in the future. + +Abstract + + This document describes three approaches for IPv6 recursive DNS + server address configuration. It details the operational attributes + of three solutions: RA option, DHCPv6 option, and well-known anycast + addresses for recursive DNS servers. Additionally, it suggests the + deployment scenarios in four kinds of networks (ISP, enterprise, + 3GPP, and unmanaged networks) considering multi-solution resolution. + + + + + + + + + + +Jeong Informational [Page 1] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 3. IPv6 DNS Configuration Approaches ...............................3 + 3.1. RA Option ..................................................3 + 3.1.1. Advantages ..........................................4 + 3.1.2. Disadvantages .......................................5 + 3.1.3. Observations ........................................5 + 3.2. DHCPv6 Option ..............................................6 + 3.2.1. Advantages ..........................................7 + 3.2.2. Disadvantages .......................................8 + 3.2.3. Observations ........................................9 + 3.3. Well-known Anycast Addresses ...............................9 + 3.3.1. Advantages .........................................10 + 3.3.2. Disadvantages ......................................10 + 3.3.3. Observations .......................................10 + 4. Interworking among IPv6 DNS Configuration Approaches ...........11 + 5. Deployment Scenarios ...........................................12 + 5.1. ISP Network ...............................................12 + 5.1.1. RA Option Approach .................................13 + 5.1.2. DHCPv6 Option Approach .............................13 + 5.1.3. Well-known Anycast Addresses Approach ..............14 + 5.2. Enterprise Network ........................................14 + 5.3. 3GPP Network ..............................................15 + 5.3.1. Currently Available Mechanisms and + Recommendations ....................................15 + 5.3.2. RA Extension .......................................16 + 5.3.3. Stateless DHCPv6 ...................................16 + 5.3.4. Well-known Addresses ...............................17 + 5.3.5. Recommendations ....................................18 + 5.4. Unmanaged Network .........................................18 + 5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18 + 5.4.2. Case B: A Dual-stack Gateway Connected to a + Dual-stack ISP .....................................19 + 5.4.3. Case C: A Dual-stack Gateway Connected to + an IPv4-only ISP ...................................19 + 5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19 + 6. Security Considerations ........................................19 + 6.1. RA Option .................................................20 + 6.2. DHCPv6 Option .............................................21 + 6.3. Well-known Anycast Addresses ..............................21 + 7. Contributors ...................................................21 + 8. Acknowledgements ...............................................23 + 9. References .....................................................23 + 9.1. Normative References ......................................23 + 9.2. Informative References ....................................23 + + + + +Jeong Informational [Page 2] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +1. Introduction + + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide ways to configure either fixed or mobile + nodes with one or more IPv6 addresses, default routes, and some other + parameters [1][2]. To support the access to additional services in + the Internet that are identified by a DNS name, such as a web server, + the configuration of at least one recursive DNS server is also needed + for DNS name resolution. + + This document describes three approaches of recursive DNS server + address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6 + option [3]-[5], and (c) well-known anycast addresses for recursive + DNS servers [7]. Also, it suggests the applicable scenarios for four + kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP + network, and (d) unmanaged network. + + This document is just an analysis of each possible approach, and it + does not recommend a particular approach or combination of + approaches. Some approaches may even not be adopted at all as a + result of further discussion. + + Therefore, the objective of this document is to help the audience + select the approaches suitable for IPv6 host configuration of + recursive DNS servers. + +2. Terminology + + This document uses the terminology described in [1]-[7]. In + addition, a new term is defined below: + + o Recursive DNS Server (RDNSS): Server which provides a recursive + DNS resolution service. + +3. IPv6 DNS Configuration Approaches + + In this section, the operational attributes of the three solutions + are described in detail. + +3.1. RA Option + + The RA approach defines a new ND option, called the RDNSS option, + that contains a recursive DNS server address [6]. Existing ND + transport mechanisms (i.e., advertisements and solicitations) are + used. This works in the same way that nodes learn about routers and + prefixes. An IPv6 host can configure the IPv6 addresses of one or + more RDNSSes via RA message periodically sent by a router or + solicited by a Router Solicitation (RS). + + + +Jeong Informational [Page 3] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + This approach needs RDNSS information to be configured in the routers + doing the advertisements. The configuration of RDNSS addresses can + be performed manually by an operator or in other ways, such as + automatic configuration through a DHCPv6 client running on the + router. An RA message with one RDNSS option can include as many + RDNSS addresses as needed [6]. + + Through the ND protocol and RDNSS option, along with a prefix + information option, an IPv6 host can perform network configuration of + its IPv6 address and RDNSS simultaneously [1][2]. The RA option for + RDNSS can be used on any network that supports the use of ND. + + The RA approach is useful in some mobile environments where the + addresses of the RDNSSes are changing because the RA option includes + a lifetime field that allows client to use RDNSSes nearer to the + client. This can be configured to a value that will require the + client to time out the entry and switch over to another RDNSS address + [6]. However, from the viewpoint of implementation, the lifetime + field would seem to make matters a bit more complex. Instead of just + writing to a DNS configuration file, such as resolv.conf for the list + of RDNSS addresses, we have to have a daemon around (or a program + that is called at the defined intervals) that keeps monitoring the + lifetime of RDNSSes all the time. + + The preference value of RDNSS, included in the RDNSS option, allows + IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this + can be used for the load balancing of RDNSSes. + +3.1.1. Advantages + + The RA option for RDNSS has a number of advantages. These include: + + 1. The RA option is an extension of existing ND/Autoconfig + mechanisms [1][2] and does not require a change in the base ND + protocol. + + 2. This approach, like ND, works well on a variety of link types, + including point-to-point links, point-to-multipoint, and + multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1] + states, however, that there may be some link types on which ND is + not feasible; on such links, some other mechanisms will be needed + for DNS configuration. + + 3. All the information a host needs to run the basic Internet + applications (such as the email, web, ftp, etc.) can be obtained + with the addition of this option to ND and address + autoconfiguration. The use of a single mechanism is more + reliable and easier to provide than when the RDNSS information is + + + +Jeong Informational [Page 4] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + learned via another protocol mechanism. Debugging problems when + multiple protocol mechanisms are being used is harder and much + more complex. + + 4. This mechanism works over a broad range of scenarios and + leverages IPv6 ND. This works well on links that are high + performance (e.g., Ethernet LANs) and low performance (e.g., + cellular networks). In the latter case, by combining the RDNSS + information with the other information in the RA, the host can + learn all the information needed to use most Internet + applications, such as the web, in a single packet. This not only + saves bandwidth, but also minimizes the delay needed to learn the + RDNSS information. + + 5. The RA approach could be used as a model for similar types of + configuration information. New RA options for other server + addresses, such as NTP server address, that are common to all + clients on a subnet would be easy to define. + +3.1.2. Disadvantages + + 1. ND is mostly implemented in the kernel of the operating system. + Therefore, if ND supports the configuration of some additional + services, such as DNS servers, ND should be extended in the + kernel and complemented by a user-land process. DHCPv6, however, + has more flexibility for the extension of service discovery + because it is an application layer protocol. + + 2. The current ND framework should be modified to facilitate the + synchronization between another ND cache for RDNSSes in the + kernel space and the DNS configuration file in the user space. + Because it is unacceptable to write and rewrite to the DNS + configuration file (e.g., resolv.conf) from the kernel, another + approach is needed. One simple approach to solve this is to have + a daemon listening to what the kernel conveys, and to have the + daemon do these steps, but such a daemon is not needed with the + current ND framework. + + 3. It is necessary to configure RDNSS addresses at least at one + router on every link where this information needs to be + configured via the RA option. + +3.1.3. Observations + + The proposed RDNSS RA option, along with the IPv6 ND and + Autoconfiguration, allows a host to obtain all of the information it + needs to access basic Internet services like the web, email, ftp, + etc. This is preferable in the environments where hosts use RAs to + + + +Jeong Informational [Page 5] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + autoconfigure their addresses and all the hosts on the subnet share + the same router and server addresses. If the configuration + information can be obtained from a single mechanism, it is preferable + because it does not add additional delay, and because it uses a + minimum of bandwidth. Environments like this include homes, public + cellular networks, and enterprise environments where no per host + configuration is needed. + + DHCPv6 is preferable where it is being used for address configuration + and if there is a need for host specific configuration [3]-[5]. + Environments like this are most likely to be the enterprise + environments where the local administration chooses to have per host + configuration control. + +3.2. DHCPv6 Option + + DHCPv6 [3] includes the "DNS Recursive Name Server" option, through + which a host can obtain a list of IP addresses of recursive DNS + servers [5]. The DNS Recursive Name Server option carries a list of + IPv6 addresses of RDNSSes to which the host may send DNS queries. + The DNS servers are listed in the order of preference for use by the + DNS resolver on the host. + + The DNS Recursive Name Server option can be carried in any DHCPv6 + Reply message, in response to either a Request or an Information + request message. Thus, the DNS Recursive Name Server option can be + used either when DHCPv6 is used for address assignment, or when + DHCPv6 is used only for other configuration information as stateless + DHCPv6 [4]. + + Stateless DHCPv6 can be deployed either by using DHCPv6 servers + running on general-purpose computers, or on router hardware. Several + router vendors currently implement stateless DHCPv6 servers. + Deploying stateless DHCPv6 in routers has the advantage that no + special hardware is required, and it should work well for networks + where DHCPv6 is needed for very straightforward configuration of + network devices. + + However, routers can also act as DHCPv6 relay agents. In this case, + the DHCPv6 server need not be on the router; it can be on a general + purpose computer. This has the potential to give the operator of the + DHCPv6 server more flexibility in how the DHCPv6 server responds to + individual clients that can easily be given different configuration + information based on their identity, or for any other reason. + Nothing precludes adding this flexibility to a router, but generally, + in current practice, DHCP servers running on general-purpose hosts + tend to have more configuration options than those that are embedded + in routers. + + + +Jeong Informational [Page 6] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 + clients that use a stateful configuration assignment. To do this, + the DHCPv6 server sends a Reconfigure message to the client. The + client validates the Reconfigure message, and then contacts the + DHCPv6 server to obtain updated configuration information. By using + this mechanism, it is currently possible to propagate new + configuration information to DHCPv6 clients as this information + changes. + + The DHC Working Group has standardized an additional mechanism + through which configuration information, including the list of + RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns + a lifetime to configuration information obtained through DHCPv6. At + the expiration of the lifetime, the host contacts the DHCPv6 server + to obtain updated configuration information, including the list of + RDNSSes. This lifetime gives the network administrator another + mechanism to configure hosts with new RDNSSes by controlling the time + at which the host refreshes the list. + + The DHC Working Group has also discussed the possibility of defining + an extension to DHCPv6 that would allow the use of multicast to + provide configuration information to multiple hosts with a single + DHCPv6 message. Because of the lack of deployment experience, the WG + has deferred consideration of multicast DHCPv6 configuration at this + time. Experience with DHCPv4 has not identified a requirement for + multicast message delivery, even in large service provider networks + with tens of thousands of hosts that may initiate a DHCPv4 message + exchange simultaneously. + +3.2.1. Advantages + + The DHCPv6 option for RDNSS has a number of advantages. These + include: + + 1. DHCPv6 currently provides a general mechanism for conveying + network configuration information to clients. Configuring DHCPv6 + servers in this way allows the network administrator to configure + RDNSSes, the addresses of other network services, and location- + specific information, such as time zones. + + 2. As a consequence, when the network administrator goes to + configure DHCPv6, all the configuration information can be + managed through a single service, typically with a single user + interface and a single configuration database. + + + + + + + +Jeong Informational [Page 7] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + 3. DHCPv6 allows for the configuration of a host with information + specific to that host, so that hosts on the same link can be + configured with different RDNSSes and with other configuration + information. + + 4. A mechanism exists for extending DHCPv6 to support the + transmission of additional configuration that has not yet been + anticipated. + + 5. Hosts that require other configuration information, such as the + addresses of SIP servers and NTP servers, are likely to need + DHCPv6 for other configuration information. + + 6. The specification for configuration of RDNSSes through DHCPv6 is + available as an RFC. No new protocol extensions (such as new + options) are necessary. + + 7. Interoperability among independent implementations has been + demonstrated. + +3.2.2. Disadvantages + + The DHCPv6 option for RDNSS has a few disadvantages. These include: + + 1. Update currently requires a message from server (however, see + [8]). + + 2. Because DNS information is not contained in RA messages, the host + must receive two messages from the router and must transmit at + least one message to the router. On networks where bandwidth is + at a premium, this is a disadvantage, although on most networks + it is not a practical concern. + + 3. There is an increased latency for initial configuration. In + addition to waiting for an RA message, the client must now + exchange packets with a DHCPv6 server. Even if it is locally + installed on a router, this will slightly extend the time + required to configure the client. For clients that are moving + rapidly from one network to another, this will be a disadvantage. + + + + + + + + + + + + +Jeong Informational [Page 8] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +3.2.3. Observations + + In the general case, on general-purpose networks, stateless DHCPv6 + provides significant advantages and no significant disadvantages. + Even in the case where bandwidth is at a premium and low latency is + desired, if hosts require other configuration information in addition + to a list of RDNSSes or if hosts must be configured selectively, + those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive + name server option will be advantageous. + + However, we are aware of some applications where it would be + preferable to put the RDNSS information into an RA packet; for + example, in a mobile phone network, where bandwidth is at a premium + and extremely low latency is desired. The DNS configuration based on + RA should be standardized so as to allow these special applications + to be handled using DNS information in the RA packet. + +3.3. Well-known Anycast Addresses + + Anycast uses the same routing system as unicast [9]. However, + administrative entities are local ones. The local entities may + accept unicast routes (including default routes) to anycast servers + from adjacent entities. The administrative entities should not + advertise their peer routes to their internal anycast servers, if + they want to prohibit external access from some peers to the servers. + If some advertisement is inevitable (such as the case with default + routes), the packets to the servers should be blocked at the boundary + of the entities. Thus, for this anycast, not only unicast routing + but also unicast ND protocols can be used as is. + + First of all, the well-known anycast addresses approach is much + different from that discussed by the IPv6 Working Group in the past + [7]. Note that "anycast" in this memo is simpler than that of RFC + 1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to + have multiple servers on a single link sharing an anycast address. + That is, on a link, an anycast address is assumed to be unique. DNS + clients today already have redundancy by having multiple well-known + anycast addresses configured as RDNSS addresses. There is no point + in having multiple RDNSSes sharing an anycast address on a single + link. + + The approach with well-known anycast addresses is to set multiple + well-known anycast addresses in clients' resolver configuration files + from the beginning as, say, factory default. Thus, there is no + transport mechanism and no packet format [7]. + + An anycast address is an address shared by multiple servers (in this + case, the servers are RDNSSes). A request from a client to the + + + +Jeong Informational [Page 9] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + anycast address is routed to a server selected by the routing system. + However, it is a bad idea to mandate "site" boundary on anycast + addresses, because most users do not have their own servers and want + to access their ISPs across their site boundaries. Larger sites may + also depend on their ISPs or may have their own RDNSSes within "site" + boundaries. + +3.3.1. Advantages + + The basic advantage of the well-known addresses approach is that it + uses no transport mechanism. Thus, the following apply: + + 1. There is no delay to get the response and no further delay by + packet losses. + + 2. The approach can be combined with any other configuration + mechanisms, such as the RA-based approach and DHCP-based + approach, as well as the factory default configuration. + + 3. The approach works over any environment where DNS works. + + Another advantage is that this approach only needs configuration of + the DNS servers as a router (or configuration of a proxy router). + Considering that DNS servers do need configuration, the amount of + overall configuration effort is proportional to the number of DNS + servers and it scales linearly. Note that, in the simplest case, + where a subscriber to an ISP does not have a DNS server, the + subscriber naturally accesses DNS servers of the ISP, even though the + subscriber and the ISP do nothing and there is no protocol to + exchange DNS server information between the subscriber and the ISP. + +3.3.2. Disadvantages + + The well-known anycast addresses approach requires that DNS servers + (or routers near to them as a proxy) act as routers to advertise + their anycast addresses to the routing system, which requires some + configuration (see the last paragraph of the previous section on the + scalability of the effort). In addition, routers at the boundary of + the "site" might need the configuration of route filters to prevent + providing DNS services for parties outside the "site" and the + possibility of denial of service attacks on the internal DNS + infrastructure. + +3.3.3. Observations + + If other approaches are used in addition, the well-known anycast + addresses should also be set in RA or DHCP configuration files to + reduce the configuration effort of users. + + + +Jeong Informational [Page 10] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + The redundancy by multiple RDNSSes is better provided by multiple + servers with different anycast addresses than by multiple servers + sharing the same anycast address, because the former approach allows + stale servers to generate routes to their anycast addresses. Thus, + in a routing domain (or domains sharing DNS servers), there will be + only one server with an anycast address unless the domain is so large + that load distribution is necessary. + + Small ISPs will operate one RDNSS at each anycast address that is + shared by all the subscribers. Large ISPs may operate multiple + RDNSSes at each anycast address to distribute and reduce load, where + the boundary between RDNSSes may be fixed (redundancy is still + provided by multiple addresses) or change dynamically. DNS packets + with the well-known anycast addresses are not expected (though not + prohibited) to cross ISP boundaries, as ISPs are expected to be able + to take care of themselves. + + Because "anycast" in this memo is simpler than that of RFC 1546 [9] + and RFC 3513 [10], where it is assumed to be administratively + prohibited to have multiple servers on a single link sharing an + anycast address, anycast in this memo should be implemented as + UNICAST of RFC 2461 [1] and RFC 3513 [10]. As a result, ND-related + instability disappears. Thus, in the well-known anycast addresses + approach, anycast can and should use the anycast address as a source + unicast (according to RFC 3513 [10]) address of packets of UDP and + TCP responses. With TCP, if a route flips and packets to an anycast + address are routed to a new server, it is expected that the flip is + detected by ICMP or sequence number inconsistency, and that the TCP + connection is reset and retried. + +4. Interworking among IPv6 DNS Configuration Approaches + + Three approaches can work together for IPv6 host configuration of + RDNSS. This section shows a consideration on how these approaches + can interwork. + + For ordering between RA and DHCP approaches, the O (Other stateful + configuration) flag in the RA message can be used [6][28]. If no + RDNSS option is included, an IPv6 host may perform DNS configuration + through DHCPv6 [3]-[5] regardless of whether the O flag is set or + not. + + The well-known anycast addresses approach fully interworks with the + other approaches. That is, the other approaches can remove the + configuration effort on servers by using the well-known addresses as + the default configuration. Moreover, the clients preconfigured with + the well-known anycast addresses can be further configured to use + other approaches to override the well-known addresses, if the + + + +Jeong Informational [Page 11] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + configuration information from other approaches is available. + Otherwise, all the clients need to have the well-known anycast + addresses preconfigured. In order to use the anycast approach along + with two other approaches, there are three choices as follows: + + 1. The first choice is that well-known addresses are used as last + resort, when an IPv6 host cannot get RDNSS information through RA + and DHCP. The well-known anycast addresses have to be + preconfigured in all of IPv6 hosts' resolver configuration files. + + 2. The second is that an IPv6 host can configure well-known + addresses as the most preferable in its configuration file even + though either an RA option or DHCP option is available. + + 3. The last is that the well-known anycast addresses can be set in + RA or DHCP configuration to reduce the configuration effort of + users. According to either the RA or DHCP mechanism, the well- + known addresses can be obtained by an IPv6 host. Because this + approach is the most convenient for users, the last option is + recommended. + + Note: This section does not necessarily mean that this document + suggests adopting all of these three approaches and making them + interwork in the way described here. In fact, as a result of further + discussion some approaches may not even be adopted at all. + +5. Deployment Scenarios + + Regarding the DNS configuration on the IPv6 host, several mechanisms + are being considered by the DNSOP Working Group, such as RA option, + DHCPv6 option, and well-known preconfigured anycast addresses as of + today, and this document is a final result from the long thread. In + this section, we suggest four applicable scenarios of three + approaches for IPv6 DNS configuration. + + Note: In the applicable scenarios, authors do not implicitly push any + specific approaches into the restricted environments. No enforcement + is in each scenario, and all mentioned scenarios are probable. The + main objective of this work is to provide a useful guideline for IPv6 + DNS configuration. + +5.1. ISP Network + + A characteristic of an ISP network is that multiple Customer Premises + Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) + routers and that each PE connects multiple CPE devices to the + backbone network infrastructure [11]. The CPEs may be hosts or + routers. + + + +Jeong Informational [Page 12] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + If the CPE is a router, there is a customer network that is connected + to the ISP backbone through the CPE. Typically, each customer + network gets a different IPv6 prefix from an IPv6 PE router, but the + same RDNSS configuration will be distributed. + + This section discusses how the different approaches to distributing + DNS information are compared in an ISP network. + +5.1.1. RA Option Approach + + When the CPE is a host, the RA option for RDNSS can be used to allow + the CPE to get RDNSS information and /64 prefix information for + stateless address autoconfiguration at the same time when the host is + attached to a new subnet [6]. Because an IPv6 host must receive at + least one RA message for stateless address autoconfiguration and + router configuration, the host could receive RDNSS configuration + information in the RA without the overhead of an additional message + exchange. + + When the CPE is a router, the CPE may accept the RDNSS information + from the RA on the interface connected to the ISP and copy that + information into the RAs advertised in the customer network. + + This approach is more valuable in the mobile host scenario, in which + the host must receive at least an RA message for detecting a new + network, than in other scenarios generally, although the + administrator should configure RDNSS information on the routers. + Secure ND [12] can provide extended security when RA messages are + used. + +5.1.2. DHCPv6 Option Approach + + DHCPv6 can be used for RDNSS configuration through the use of the DNS + option, and can provide other configuration information in the same + message with RDNSS configuration [3]-[5]. The DHCPv6 DNS option is + already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or + stateless DHCP [4] is not nearly as complex as a full DHCPv6 + implementation. DHCP is a client-server model protocol, so ISPs can + handle user identification on its network intentionally; also, + authenticated DHCP [13] can be used for secure message exchange. + + The expected model for deployment of IPv6 service by ISPs is to + assign a prefix to each customer, which will be used by the customer + gateway to assign a /64 prefix to each network in the customer's + network. Prefix delegation with DHCP (DHCPv6 PD) has already been + adopted by ISPs for automating the assignment of the customer prefix + to the customer gateway [15]. DNS configuration can be carried in + the same DHCPv6 message exchange used for DHCPv6 to provide that + + + +Jeong Informational [Page 13] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + information efficiently, along with any other configuration + information needed by the customer gateway or customer network. This + service model can be useful to Home or SOHO subscribers. The Home or + SOHO gateway, which is a customer gateway for ISP, can then pass that + RDNSS configuration information to the hosts in the customer network + through DHCP. + +5.1.3. Well-known Anycast Addresses Approach + + The well-known anycast addresses approach is also a feasible and + simple mechanism for ISP [7]. The use of well-known anycast + addresses avoids some of the security risks in rogue messages sent + through an external protocol such as RA or DHCPv6. The configuration + of hosts for the use of well-known anycast addresses requires no + protocol or manual configuration, but the configuration of routing + for the anycast addresses requires intervention on the part of the + network administrator. Also, the number of special addresses would + be equal to the number of RDNSSes that could be made available to + subscribers. + +5.2. Enterprise Network + + An enterprise network is defined as a network that has multiple + internal links, one or more router connections to one or more + providers, and is actively managed by a network operations entity + [14]. An enterprise network can get network prefixes from an ISP by + either manual configuration or prefix delegation [15]. In most + cases, because an enterprise network manages its own DNS domains, it + operates its own DNS servers for the domains. These DNS servers + within enterprise networks process recursive DNS name resolution + requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the + enterprise network can be performed as it is in Section 4, in which + three approaches can be used together as follows: + + 1. An IPv6 host can decide which approach is or may be used in its + subnet with the O flag in RA message [6][28]. As the first + choice in Section 4, well-known anycast addresses can be used as + a last resort when RDNSS information cannot be obtained through + either an RA option or a DHCP option. This case needs IPv6 hosts + to preconfigure the well-known anycast addresses in their DNS + configuration files. + + 2. When the enterprise prefers the well-known anycast approach to + others, IPv6 hosts should preconfigure the well-known anycast + addresses as it is in the first choice. + + 3. The last choice, a more convenient and transparent way, does not + need IPv6 hosts to preconfigure the well-known anycast addresses + + + +Jeong Informational [Page 14] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + because the addresses are delivered to IPv6 hosts via either the + RA option or DHCPv6 option as if they were unicast addresses. + This way is most recommended for the sake of the user's + convenience. + +5.3. 3GPP Network + + The IPv6 DNS configuration is a missing part of IPv6 + autoconfiguration and an important part of the basic IPv6 + functionality in the 3GPP User Equipment (UE). The higher-level + description of the 3GPP architecture can be found in [16], and + transition to IPv6 in 3GPP networks is analyzed in [17] and [18]. + + In the 3GPP architecture, there is a dedicated link between the UE + and the GGSN called the Packet Data Protocol (PDP) Context. This + link is created through the PDP Context activation procedure [19]. + There is a separate PDP context type for IPv4 and IPv6 traffic. If a + 3GPP UE user is communicating by using IPv6 (i.e., by having an + active IPv6 PDP context), it cannot be assumed that the user + simultaneously has an active IPv4 PDP context, and DNS queries could + be done using IPv4. A 3GPP UE can thus be an IPv6 node, and somehow + it needs to discover the address of the RDNSS. Before IP-based + services (e.g., web browsing or e-mail) can be used, the IPv6 (and + IPv4) RDNSS addresses need to be discovered in the 3GPP UE. + + Section 5.3.1 briefly summarizes currently available mechanisms in + 3GPP networks and recommendations. 5.3.2 analyzes the Router + Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6 + mechanism, and 5.3.4 analyzes the well-known addresses approach. + Section 5.3.5 summarizes the recommendations. + +5.3.1. Currently Available Mechanisms and Recommendations + + 3GPP has defined a mechanism in which RDNSS addresses can be received + in the PDP context activation (a control plane mechanism). That is + called the Protocol Configuration Options Information Element (PCO- + IE) mechanism [20]. The RDNSS addresses can also be received over + the air (using text messages) or typed in manually in the UE. Note + that the two last mechanisms are not very well scalable. The UE user + most probably does not want to type IPv6 RDNSS addresses manually in + the user's UE. The use of well-known addresses is briefly discussed + in section 5.3.4. + + It is seen that the mechanisms above most probably are not sufficient + for the 3GPP environment. IPv6 is intended to operate in a zero- + configuration manner, no matter what the underlying network + infrastructure is. Typically, the RDNSS address is needed to make an + IPv6 node operational, and the DNS configuration should be as simple + + + +Jeong Informational [Page 15] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + as the address autoconfiguration mechanism. Note that there will be + additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP- + specific DNS configuration mechanisms (such as PCO-IE [20]) do not + work for those IP interfaces. In other words, a good IPv6 DNS + configuration mechanism should also work in a multi-access network + environment. + + From a 3GPP point of view, the best IPv6 DNS configuration solution + is feasible for a very large number of IPv6-capable UEs (even + hundreds of millions in one operator's network), is automatic, and + thus requires no user action. It is suggested that a lightweight, + stateless mechanism be standardized for use in all network + environments. The solution could then be used for 3GPP, 3GPP2, and + other access network technologies. Thus, not only is a light, + stateless IPv6 DNS configuration mechanism needed in 3GPP networks, + but also 3GPP networks and UEs would certainly benefit from the new + mechanism. + +5.3.2. RA Extension + + Router Advertisement extension [6] is a lightweight IPv6 DNS + configuration mechanism that requires minor changes in the 3GPP UE + IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in + the 3GPP architecture) IPv6 stack. This solution can be specified in + the IETF (no action is needed in the 3GPP) and taken in use in 3GPP + UEs and GGSNs. + + In this solution, an IPv6-capable UE configures DNS information via + an RA message sent by its default router (GGSN); i.e., the RDNSS + option for a recursive DNS server is included in the RA message. + This solution is easily scalable for a very large number of UEs. The + operator can configure the RDNSS addresses in the GGSN as a part of + normal GGSN configuration. The IPv6 RDNSS address is received in the + Router Advertisement, and an extra Round Trip Time (RTT) for asking + RDNSS addresses can be avoided. + + When one considers the cons, this mechanism still requires + standardization effort in the IETF, and the end nodes and routers + need to support this mechanism. The equipment software update + should, however, be pretty straightforward, and new IPv6 equipment + could support RA extension already from the beginning. + +5.3.3. Stateless DHCPv6 + + A DHCPv6-based solution needs the implementation of Stateless DHCP + [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the + operator's network. A possible configuration is such that the GGSN + works as a DHCP relay. + + + +Jeong Informational [Page 16] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + The pros of a stateless DHCPv6-based solution are: + + 1. Stateless DHCPv6 is a standardized mechanism. + + 2. DHCPv6 can be used for receiving configuration information other + than RDNSS addresses; e.g., SIP server addresses. + + 3. DHCPv6 works in different network environments. + + 4. When DHCPv6 service is deployed through a single, centralized + server, the RDNSS configuration information can be updated by the + network administrator at a single source. + + Some issues with DHCPv6 in 3GPP networks are listed below: + + 1. DHCPv6 requires an additional server in the network unless the + (Stateless) DHCPv6 functionality is integrated into an existing + router. This means that there might be one additional server to + be maintained. + + 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing + (3GPP Stateless Address Autoconfiguration is typically used) and + is not automatically implemented in 3GPP IPv6 UEs. + + 3. Scalability and reliability of DHCPv6 in very large 3GPP networks + (with tens or hundreds of millions of UEs) may be an issue; at + least the redundancy needs to be taken care of. However, if the + DHCPv6 service is integrated into the network elements, such as a + router operating system, scalability and reliability is + comparable with other DNS configuration approaches. + + 4. It is sub-optimal to utilize the radio resources in 3GPP networks + for DHCPv6 messages if there is a simpler alternative is + available. + + * The use of stateless DHCPv6 adds one round-trip delay to the + case in which the UE can start transmitting data right after + the Router Advertisement. + + 5. If the DNS information (suddenly) changes, Stateless DHCPv6 + cannot automatically update the UE; see [21]. + +5.3.4. Well-known Addresses + + Using well-known addresses is also a feasible and light mechanism for + 3GPP UEs. Those well-known addresses can be preconfigured in the UE + software and the operator can make the corresponding configuration on + the network side. Thus, this is a very easy mechanism for the UE, + + + +Jeong Informational [Page 17] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + but it requires some configuration work in the network. When using + well-known addresses, UE forwards queries to any of the preconfigured + addresses. In the current proposal [7], IPv6 anycast addresses are + suggested. + + Note: An IPv6 DNS configuration proposal, based on the use of well- + known site-local addresses, was developed by the IPv6 Working Group; + it was seen as a feasible mechanism for 3GPP UEs, although no IETF + consensus was reached on this proposal. In the end, the deprecation + of IPv6 site-local addresses made it impossible to standardize a + mechanism that uses site-local addresses as well-known addresses. + However, as of this writing, this mechanism is implemented in some + operating systems and 3GPP UEs as a last resort of IPv6 DNS + configuration. + +5.3.5. Recommendations + + It is suggested that a lightweight, stateless DNS configuration + mechanism be specified as soon as possible. From a 3GPP UE and + network point of view, the Router Advertisement-based mechanism looks + most promising. The sooner a light, stateless mechanism is + specified, the sooner we can stop using well-known site-local + addresses for IPv6 DNS configuration. + +5.4. Unmanaged Network + + There are four deployment scenarios of interest in unmanaged networks + [22]: + + 1. A gateway that does not provide IPv6 at all, + + 2. A dual-stack gateway connected to a dual-stack ISP, + + 3. A dual-stack gateway connected to an IPv4-only ISP, and + + 4. A gateway connected to an IPv6-only ISP. + +5.4.1. Case A: Gateway Does Not Provide IPv6 at All + + In this case, the gateway does not provide IPv6; the ISP may or may + not provide IPv6. Automatic or Configured tunnels are the + recommended transition mechanisms for this scenario. + + The case where dual-stack hosts behind an NAT need access to an IPv6 + RDNSS cannot be entirely ruled out. The DNS configuration mechanism + has to work over the tunnel, and the underlying tunneling mechanism + could implement NAT traversal. The tunnel server assumes the role of + a relay (for both DHCP and well-known anycast addresses approaches). + + + +Jeong Informational [Page 18] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + The RA-based mechanism is relatively straightforward in its + operation, assuming the tunnel server is also the IPv6 router + emitting RAs. The well-known anycast addresses approach also seems + simple in operation across the tunnel, but the deployment model using + well-known anycast addresses in a tunneled environment is unclear or + not well understood. + +5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP + + This is similar to a typical IPv4 home user scenario, where DNS + configuration parameters are obtained using DHCP. The exception is + that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where + the DHCP server is stateful (it maintains the state for clients). + +5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP + + This is similar to Case B. If a gateway provides IPv6 connectivity + by managing tunnels, then it is also supposed to provide access to an + RDNSS. Like this, the tunnel for IPv6 connectivity originates from + the dual-stack gateway instead of from the host. + +5.4.4. Case D: A Gateway Connected to an IPv6-only ISP + + This is similar to Case B. + +6. Security Considerations + + As security requirements depend solely on applications and differ + from application to application, there can be no generic requirement + defined at the IP or application layer for DNS. + + However, note that cryptographic security requires configured secret + information and that full autoconfiguration and cryptographic + security are mutually exclusive. People insisting on secure, full + autoconfiguration will get false security, false autoconfiguration, + or both. + + In some deployment scenarios [17], where cryptographic security is + required for applications, the secret information for the + cryptographic security is preconfigured, through which application- + specific configuration data, including those for DNS, can be securely + configured. Note that if applications requiring cryptographic + security depend on DNS, the applications also require cryptographic + security to DNS. Therefore, the full autoconfiguration of DNS is not + acceptable. + + However, with full autoconfiguration, weaker but still reasonable + security is being widely accepted and will continue to be acceptable. + + + +Jeong Informational [Page 19] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + That is, with full autoconfiguration, which means there is no + cryptographic security for the autoconfiguration, it is already + assumed that the local environment is secure enough that the + information from the local autoconfiguration server has acceptable + security even without cryptographic security. Thus, the + communication between the local DNS client and local DNS server has + acceptable security. + + In autoconfiguring recursive servers, DNSSEC may be overkill, because + DNSSEC [23]-[25] needs the configuration and reconfiguration of + clients at root key roll-over [26][27]. Even if additional keys for + secure key roll-over are added at the initial configuration, they are + as vulnerable as the original keys to some forms of attack, such as + social hacking. Another problem of using DNSSEC and + autoconfiguration together is that DNSSEC requires secure time, which + means secure communication with autoconfigured time servers, which + requires configured secret information. Therefore, in order that the + autoconfiguration may be secure, configured secret information is + required. + + If DNSSEC [23]-[25] is used and the signatures are verified on the + client host, the misconfiguration of a DNS server may simply be + denial of service. Also, if local routing environment is not + reliable, clients may be directed to a false resolver with the same + IP address as the true one. + +6.1. RA Option + + The security of RA option for RDNSS is the same as the ND protocol + security [1][6]. The RA option does not add any new vulnerability. + + Note that the vulnerability of ND is not worse and is a subset of the + attacks that any node attached to a LAN can do independently of ND. + A malicious node on a LAN can promiscuously receive packets for any + router's MAC address and send packets with the router's MAC address + as the source MAC address in the L2 header. As a result, the L2 + switches send packets addressed to the router to the malicious node. + Also, this attack can send redirects that tell the hosts to send + their traffic somewhere else. The malicious node can send + unsolicited RA or NA replies, answer RS or NS requests, etc. All of + this can be done independently of implementing ND. Therefore, the RA + option for RDNSS does not add to the vulnerability. + + Security issues regarding the ND protocol were discussed by the IETF + SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for + the ND security has been published [12]. + + + + + +Jeong Informational [Page 20] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +6.2. DHCPv6 Option + + The DNS Recursive Name Server option may be used by an intruder DHCP + server to cause DHCP clients to send DNS queries to an intruder DNS + recursive name server [5]. The results of these misdirected DNS + queries may be used to spoof DNS names. + + To avoid attacks through the DNS Recursive Name Server option, the + DHCP client SHOULD require DHCP authentication (see "Authentication + of DHCP messages" in RFC 3315 [3][13]) before installing a list of + DNS recursive name servers obtained through authenticated DHCP. + +6.3. Well-known Anycast Addresses + + The well-known anycast addresses approach is not a protocol, thus + there is no need to secure the protocol itself. + + However, denial of service attacks on the DNS resolver system might + be easier to achieve as the anycast addresses used are by definition + well known. + +7. Contributors + + Ralph Droms + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxboro, MA 01719 + US + + Phone: +1 978 936 1674 + EMail: rdroms@cisco.com + + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + US + + Phone: +1 650 625 2004 + EMail: bob.hinden@nokia.com + + + + + + + + + + +Jeong Informational [Page 21] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + Ted Lemon + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94043 + US + + EMail: Ted.Lemon@nominum.com + + Masataka Ohta + Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku + Tokyo 152-8552 + Japan + + Phone: +81 3 5734 3299 + Fax: +81 3 5734 3299 + EMail: mohta@necom830.hpcl.titech.ac.jp + + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics + 416 Maetan-3dong, Yeongtong-Gu + Suwon, Gyeonggi-Do 443-742 + Korea + + Phone: +82 31 200 4508 + EMail: soohong.park@samsung.com + + + Suresh Satapati + Cisco Systems, Inc. + San Jose, CA 95134 + US + + EMail: satapati@cisco.com + + + Juha Wiljakka + Nokia + Visiokatu 3 + FIN-33720, TAMPERE + Finland + + Phone: +358 7180 48372 + EMail: juha.wiljakka@nokia.com + + + + + + +Jeong Informational [Page 22] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +8. Acknowledgements + + This document has greatly benefited from inputs by David Meyer, Rob + Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, + Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. + Also, Tony Bonanno proofread this document. The authors appreciate + their contribution. + +9. References + +9.1. Normative References + + [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. + + [2] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. + Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 3315, July 2003. + + [4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) + Service for IPv6", RFC 3736, April 2004. + + [5] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December + 2003. + +9.2. Informative References + + [6] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 + Router Advertisement Option for DNS Configuration", Work in + Progress, September 2005. + + [7] Ohta, M., "Preconfigured DNS Server Addresses", Work in + Progress, February 2004. + + [8] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time + Option for Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 4242, November 2005. + + [9] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + + + +Jeong Informational [Page 23] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + [11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, + "Scenarios and Analysis for Introducing IPv6 into ISP Networks", + RFC 4029, March 2005. + + [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", + RFC 3118, June 2001. + + [14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June + 2005. + + [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host + Configuration Protocol (DHCP) version 6", RFC 3633, December + 2003. + + [16] Wasserman, M., "Recommendations for IPv6 in Third Generation + Partnership Project (3GPP) Standards", RFC 3314, September 2002. + + [17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC + 3574, August 2003. + + [18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation + Partnership Project (3GPP) Networks", RFC 4215, October 2005. + + [19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); + Service description; Stage 2 (Release 5)", December 2002. + + [20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 + specification; Core network protocols; Stage 3 (Release 5)", + June 2003. + + [21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering + Requirements for Stateless Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 4076, May 2005. + + [22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, + "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April + 2004. + + [23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Jeong Informational [Page 24] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + [25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work + in Progress, October 2005. + + [27] Guette, G. and O. Courtay, "Requirements for Automated Key + Rollover in DNSSEC", Work in Progress, January 2005. + + [28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M + and O Flags of IPv6 Router Advertisement", Work in Progress, + March 2005. + +Author's Address + + Jaehoon Paul Jeong (editor) + ETRI/Department of Computer Science and Engineering + University of Minnesota + 117 Pleasant Street SE + Minneapolis, MN 55455 + US + + Phone: +1 651 587 7774 + Fax: +1 612 625 2002 + EMail: jjeong@cs.umn.edu + URI: http://www.cs.umn.edu/~jjeong/ + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Informational [Page 25] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Jeong Informational [Page 26] + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/doc/rfc/rfc4472.txt similarity index 54% rename from doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt rename to doc/rfc/rfc4472.txt index 1276f9f91d..b396e9a11a 100644 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt +++ b/doc/rfc/rfc4472.txt @@ -2,62 +2,36 @@ -DNS Operations WG A. Durand -Internet-Draft SUN Microsystems, Inc. -Expires: January 17, 2006 J. Ihren + + +Network Working Group A. Durand +Request for Comments: 4472 Comcast +Category: Informational J. Ihren Autonomica P. Savola CSC/FUNET - July 16, 2005 + April 2006 Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-11.txt -Status of this Memo +Status of This Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 17, 2006. + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 - addresses, documentation of known DNS implementation misbehaviour, + addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, - - - -Durand, et al. Expires January 17, 2006 [Page 1] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who @@ -65,63 +39,62 @@ Internet-Draft Considerations with IPv6 DNS July 2005 Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 - 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 - 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 - 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 - 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 - 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 - 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 - 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 - 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 - 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 - 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 - 4. Recommendations for Service Provisioning using DNS . . . . . . 7 - 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 - 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 - 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 - 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10 - 4.4.1 TTL With Courtesy Additional Data . . . . . . . . . . 10 - 4.4.2 TTL With Critical Additional Data . . . . . . . . . . 10 - 4.5 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11 - 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 13 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16 - 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . 19 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 20 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . 20 + 1. Introduction ....................................................3 + 1.1. Representing IPv6 Addresses in DNS Records .................3 + 1.2. Independence of DNS Transport and DNS Records ..............4 + 1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4 + 1.4. Query Type '*' and A/AAAA Records ..........................4 + 2. DNS Considerations about Special IPv6 Addresses .................5 + 2.1. Limited-Scope Addresses ....................................5 + 2.2. Temporary Addresses ........................................5 + 2.3. 6to4 Addresses .............................................5 + 2.4. Other Transition Mechanisms ................................5 + 3. Observed DNS Implementation Misbehavior .........................6 + 3.1. Misbehavior of DNS Servers and Load-balancers ..............6 + 3.2. Misbehavior of DNS Resolvers ...............................6 -Durand, et al. Expires January 17, 2006 [Page 2] +Durand, et al. Informational [Page 1] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - 11.2 Informative References . . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 - A. Unique Local Addressing Considerations for DNS . . . . . . . . 25 - B. Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25 - B.1 Description of Additional Data Scenarios . . . . . . . . . 26 - B.2 Which Additional Data to Keep, If Any? . . . . . . . . . . 27 - B.3 Discussion of the Potential Problems . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . 30 + 4. Recommendations for Service Provisioning Using DNS ..............7 + 4.1. Use of Service Names instead of Node Names .................7 + 4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8 + 4.3. Adding the Records Only When Fully IPv6-enabled ............8 + 4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9 + 4.4.1. TTL with Courtesy Additional Data ...................9 + 4.4.2. TTL with Critical Additional Data ..................10 + 4.5. IPv6 Transport Guidelines for DNS Servers .................10 + 5. Recommendations for DNS Resolver IPv6 Support ..................10 + 5.1. DNS Lookups May Query IPv6 Records Prematurely ............10 + 5.2. Obtaining a List of DNS Recursive Resolvers ...............12 + 5.3. IPv6 Transport Guidelines for Resolvers ...................12 + 6. Considerations about Forward DNS Updating ......................13 + 6.1. Manual or Custom DNS Updates ..............................13 + 6.2. Dynamic DNS ...............................................13 + 7. Considerations about Reverse DNS Updating ......................14 + 7.1. Applicability of Reverse DNS ..............................14 + 7.2. Manual or Custom DNS Updates ..............................15 + 7.3. DDNS with Stateless Address Autoconfiguration .............16 + 7.4. DDNS with DHCP ............................................17 + 7.5. DDNS with Dynamic Prefix Delegation .......................17 + 8. Miscellaneous DNS Considerations ...............................18 + 8.1. NAT-PT with DNS-ALG .......................................18 + 8.2. Renumbering Procedures and Applications' Use of DNS .......18 + 9. Acknowledgements ...............................................19 + 10. Security Considerations .......................................19 + 11. References ....................................................20 + 11.1. Normative References .....................................20 + 11.2. Informative References ...................................22 + Appendix A. Unique Local Addressing Considerations for DNS ........24 + Appendix B. Behavior of Additional Data in IPv4/IPv6 + Environments ..........................................24 + B.1. Description of Additional Data Scenarios ..................24 + B.2. Which Additional Data to Keep, If Any? ....................26 + B.3. Discussion of the Potential Problems ......................27 @@ -138,36 +111,9 @@ Internet-Draft Considerations with IPv6 DNS July 2005 - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires January 17, 2006 [Page 3] +Durand, et al. Informational [Page 2] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 1. Introduction @@ -189,18 +135,18 @@ Internet-Draft Considerations with IPv6 DNS July 2005 The second section summarizes the special IPv6 address types and how they relate to DNS. The third section describes observed DNS - implementation misbehaviours which have a varying effect on the use - of IPv6 records with DNS. The fourth section lists recommendations - and considerations for provisioning services with DNS. The fifth - section in turn looks at recommendations and considerations about - providing IPv6 support in the resolvers. The sixth and seventh - sections describe considerations with forward and reverse DNS - updates, respectively. The eighth section introduces several - miscellaneous IPv6 issues relating to DNS for which no better place - has been found in this memo. Appendix A looks briefly at the - requirements for unique local addressing. + implementation misbehaviors that have a varying effect on the use of + IPv6 records with DNS. The fourth section lists recommendations and + considerations for provisioning services with DNS. The fifth section + in turn looks at recommendations and considerations about providing + IPv6 support in the resolvers. The sixth and seventh sections + describe considerations with forward and reverse DNS updates, + respectively. The eighth section introduces several miscellaneous + IPv6 issues relating to DNS for which no better place has been found + in this memo. Appendix A looks briefly at the requirements for + unique local addressing. Appendix B discusses additional data. -1.1 Representing IPv6 Addresses in DNS Records +1.1. Representing IPv6 Addresses in DNS Records In the forward zones, IPv6 addresses are represented using AAAA records. In the reverse zones, IPv6 address are represented using @@ -208,24 +154,28 @@ Internet-Draft Considerations with IPv6 DNS July 2005 [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] for background information. - In particular one should note that the use of A6 records in the + In particular, one should note that the use of A6 records in the forward tree or Bitlabels in the reverse tree is not recommended [RFC3363]. Using DNAME records is not recommended in the reverse tree in conjunction with A6 records; the document did not mean to take a stance on any other use of DNAME records [RFC3364]. -1.2 Independence of DNS Transport and DNS Records + + + + + + + +Durand, et al. Informational [Page 3] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +1.2. Independence of DNS Transport and DNS Records DNS has been designed to present a single, globally unique name space [RFC2826]. This property should be maintained, as described here and - - - -Durand, et al. Expires January 17, 2006 [Page 4] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - in Section 1.3. The IP version used to transport the DNS queries and responses is @@ -249,8 +199,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 independent of the protocol version of the resource records; e.g., IPv4 transport can be used to query IPv6 records and vice versa. - -1.3 Avoiding IPv4/IPv6 Name Space Fragmentation +1.3. Avoiding IPv4/IPv6 Name Space Fragmentation To avoid the DNS name space from fragmenting into parts where some parts of DNS are only visible using IPv4 (or IPv6) transport, the @@ -258,7 +207,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 IPv4-enabled, and to ensure that recursive DNS servers support IPv4. See DNS IPv6 transport guidelines [RFC3901] for more information. -1.4 Query Type '*' and A/AAAA Records +1.4. Query Type '*' and A/AAAA Records QTYPE=* is typically only used for debugging or management purposes; it is worth keeping in mind that QTYPE=* ("ANY" queries) only return @@ -267,35 +216,37 @@ Internet-Draft Considerations with IPv6 DNS July 2005 they have all the RRsets. Therefore, to get both A and AAAA records reliably, two separate queries must be made. + + + + + + + +Durand, et al. Informational [Page 4] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + 2. DNS Considerations about Special IPv6 Addresses - There are a couple of IPv6 address types which are somewhat special; + There are a couple of IPv6 address types that are somewhat special; these are considered here. +2.1. Limited-Scope Addresses - - - - -Durand, et al. Expires January 17, 2006 [Page 5] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - -2.1 Limited-scope Addresses - - The IPv6 addressing architecture [RFC3513] includes two kinds of + The IPv6 addressing architecture [RFC4291] includes two kinds of local-use addresses: link-local (fe80::/10) and site-local (fec0::/10). The site-local addresses have been deprecated [RFC3879] but are discussed with unique local addresses in Appendix A. Link-local addresses should never be published in DNS (whether in forward or reverse tree), because they have only local (to the - connected link) significance [I-D.durand-dnsop-dont-publish]. + connected link) significance [WIP-DC2005]. -2.2 Temporary Addresses +2.2. Temporary Addresses - Temporary addresses defined in RFC3041 [RFC3041] (sometimes called + Temporary addresses defined in RFC 3041 [RFC3041] (sometimes called "privacy addresses") use a random number as the interface identifier. Having DNS AAAA records that are updated to always contain the current value of a node's temporary address would defeat the purpose @@ -303,55 +254,54 @@ Internet-Draft Considerations with IPv6 DNS July 2005 possible to return a non-identifiable name (e.g., the IPv6 address in hexadecimal format), as described in [RFC3041]. -2.3 6to4 Addresses +2.3. 6to4 Addresses - 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps - a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. + 6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a + public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. If the reverse DNS population would be desirable (see Section 7.1 for applicability), there are a number of possible ways to do so. - The main proposal [I-D.huston-6to4-reverse-dns] aims to design an - autonomous reverse-delegation system that anyone being capable of - communicating using a specific 6to4 address would be able to set up a - reverse delegation to the corresponding 6to4 prefix. This could be - deployed by e.g., Regional Internet Registries (RIRs). This is a - practical solution, but may have some scalability concerns. + [WIP-H2005] aims to design an autonomous reverse-delegation system + that anyone being capable of communicating using a specific 6to4 + address would be able to set up a reverse delegation to the + corresponding 6to4 prefix. This could be deployed by, e.g., Regional + Internet Registries (RIRs). This is a practical solution, but may + have some scalability concerns. -2.4 Other Transition Mechanisms +2.4. Other Transition Mechanisms 6to4 is mentioned as a case of an IPv6 transition mechanism requiring - special considerations. In general, mechanisms which include a - special prefix may need a custom solution; otherwise, for example + special considerations. In general, mechanisms that include a + special prefix may need a custom solution; otherwise, for example, when IPv4 address is embedded as the suffix or not embedded at all, special solutions are likely not needed. - Note that it does not seem feasible to provide reverse DNS with - another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops- - teredo]; this is because the IPv6 address is based on the IPv4 - address and UDP port of the current NAT mapping which is likely to be - -Durand, et al. Expires January 17, 2006 [Page 6] +Durand, et al. Informational [Page 5] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - relatively short-lived. + Note that it does not seem feasible to provide reverse DNS with + another automatic tunneling mechanism, Teredo [RFC4380]; this is + because the IPv6 address is based on the IPv4 address and UDP port of + the current Network Address Translation (NAT) mapping, which is + likely to be relatively short-lived. -3. Observed DNS Implementation Misbehaviour +3. Observed DNS Implementation Misbehavior - Several classes of misbehaviour in DNS servers, load-balancers and + Several classes of misbehavior in DNS servers, load-balancers, and resolvers have been observed. Most of these are rather generic, not only applicable to IPv6 -- but in some cases, the consequences of - this misbehaviour are extremely severe in IPv6 environments and + this misbehavior are extremely severe in IPv6 environments and deserve to be mentioned. -3.1 Misbehaviour of DNS Servers and Load-balancers +3.1. Misbehavior of DNS Servers and Load-balancers - There are several classes of misbehaviour in certain DNS servers and - load-balancers which have been noticed and documented [RFC4074]: some + There are several classes of misbehavior in certain DNS servers and + load-balancers that have been noticed and documented [RFC4074]: some implementations silently drop queries for unimplemented DNS records types, or provide wrong answers to such queries (instead of a proper negative reply). While typically these issues are not limited to @@ -363,7 +313,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 to query the AAAA records of the name, and after receiving a response, query the A records. This is done in a serial fashion -- if the first query is never responded to (instead of properly - returning a negative answer), significant timeouts will occur. + returning a negative answer), significant time-outs will occur. In consequence, this is an enormous problem for IPv6 deployments, and in some cases, IPv6 support in the software has even been disabled @@ -372,32 +322,31 @@ Internet-Draft Considerations with IPv6 DNS July 2005 The solution is to fix or retire those misbehaving implementations, but that is likely not going to be effective. There are some possible ways to mitigate the problem, e.g., by performing the - lookups somewhat in parallel and reducing the timeout as long as at - least one answer has been received; but such methods remain to be + lookups somewhat in parallel and reducing the time-out as long as at + least one answer has been received, but such methods remain to be investigated; slightly more on this is included in Section 5. -3.2 Misbehaviour of DNS Resolvers +3.2. Misbehavior of DNS Resolvers - Several classes of misbehaviour have also been noticed in DNS - resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem - to directly impair IPv6 use, and are only referred to for - completeness. + Several classes of misbehavior have also been noticed in DNS + resolvers [WIP-LB2005]. However, these do not seem to directly + impair IPv6 use, and are only referred to for completeness. -4. Recommendations for Service Provisioning using DNS + + + +Durand, et al. Informational [Page 6] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +4. Recommendations for Service Provisioning Using DNS When names are added in the DNS to facilitate a service, there are - - - -Durand, et al. Expires January 17, 2006 [Page 7] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - several general guidelines to consider to be able to do it as smoothly as possible. -4.1 Use of Service Names instead of Node Names +4.1. Use of Service Names instead of Node Names It makes sense to keep information about separate services logically separate in the DNS by using a different DNS hostname for each @@ -406,17 +355,17 @@ Internet-Draft Considerations with IPv6 DNS July 2005 o It allows more flexibility and ease for migration of (only a part of) services from one node to another, - o It allows configuring different properties (e.g., TTL) for each - service, and + o It allows configuring different properties (e.g., Time to Live + (TTL)) for each service, and - o It allows deciding separately for each service whether to publish - the IPv6 addresses or not (in cases where some services are more + o It allows deciding separately for each service whether or not to + publish the IPv6 addresses (in cases where some services are more IPv6-ready than others). Using SRV records [RFC2782] would avoid these problems. Unfortunately, those are not sufficiently widely used to be applicable in most cases. Hence an operation technique is to use - service names instead of node names (or, "hostnames"). This + service names instead of node names (or "hostnames"). This operational technique is not specific to IPv6, but required to understand the considerations described in Section 4.2 and Section 4.3. @@ -424,32 +373,37 @@ Internet-Draft Considerations with IPv6 DNS July 2005 For example, assume a node named "pobox.example.com" provides both SMTP and IMAP service. Instead of configuring the MX records to point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one could use + look up the mail via IMAP from "pobox.example.com", one could use, e.g., "smtp.example.com" for SMTP (for both message submission and mail relaying between SMTP servers) and "imap.example.com" for IMAP. Note that in the specific case of SMTP relaying, the server itself must typically also be configured to know all its names to ensure - loops do not occur. DNS can provide a layer of indirection between - service names and where the service actually is, and using which - addresses. (Obviously, when wanting to reach a specific node, one - should use the hostname rather than a service name.) + that loops do not occur. DNS can provide a layer of indirection + between service names and where the service actually is, and using + which addresses. (Obviously, when wanting to reach a specific node, + one should use the hostname rather than a service name.) -4.2 Separate vs the Same Service Names for IPv4 and IPv6 + + + + + + + + +Durand, et al. Informational [Page 7] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +4.2. Separate vs. the Same Service Names for IPv4 and IPv6 The service naming can be achieved in basically two ways: when a service is named "service.example.com" for IPv4, the IPv6-enabled - service could either be added to "service.example.com", or added - separately under a different name, e.g., in a sub-domain, like, + service could either be added to "service.example.com" or added + separately under a different name, e.g., in a sub-domain like "service.ipv6.example.com". - - - -Durand, et al. Expires January 17, 2006 [Page 8] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - These two methods have different characteristics. Using a different name allows for easier service piloting, minimizing the disturbance to the "regular" users of IPv4 service; however, the service would @@ -469,7 +423,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 confident enough that the service level will not degrade for the users unaware of IPv6. -4.3 Adding the Records Only when Fully IPv6-enabled +4.3. Adding the Records Only When Fully IPv6-enabled The recommendation is that AAAA records for a service should not be added to the DNS until all of following are true: @@ -478,7 +432,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 2. The address is configured on the interface. - 3. The interface is on a link which is connected to the IPv6 + 3. The interface is on a link that is connected to the IPv6 infrastructure. In addition, if the AAAA record is added for the node, instead of @@ -489,32 +443,33 @@ Internet-Draft Considerations with IPv6 DNS July 2005 (e.g., it is not connected to IPv6 Internet) constraint #3 would mean that it should not have an address in the DNS. - Consider the case of two dual-stack nodes, which both have IPv6 + + + + +Durand, et al. Informational [Page 8] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + Consider the case of two dual-stack nodes, which both are IPv6- enabled, but the server does not have (global) IPv6 connectivity. As the client looks up the server's name, only A records are returned (if the recommendations above are followed), and no IPv6 communication, which would have been unsuccessful, is even attempted. - The issues are not always so black-and-white. Usually it's important - that the service offered using both protocols is of roughly equal - quality, using the appropriate metrics for the service (e.g., - - - -Durand, et al. Expires January 17, 2006 [Page 9] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - latency, throughput, low packet loss, general reliability, etc.) -- - this is typically very important especially for interactive or real- + The issues are not always so black-and-white. Usually, it's + important that the service offered using both protocols is of roughly + equal quality, using the appropriate metrics for the service (e.g., + latency, throughput, low packet loss, general reliability, etc.). + This is typically very important especially for interactive or real- time services. In many cases, the quality of IPv6 connectivity may - not yet be equal to that of IPv4, at least globally -- this has to be + not yet be equal to that of IPv4, at least globally; this has to be taken into consideration when enabling services. -4.4 The Use of TTL for IPv4 and IPv6 RRs +4.4. The Use of TTL for IPv4 and IPv6 RRs - The behaviour of DNS caching when different TTL values are used for + The behavior of DNS caching when different TTL values are used for different RRsets of the same name calls for explicit discussion. For example, let's consider two unrelated zone fragments: @@ -532,7 +487,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 latter, we have "critical" additional data. See more extensive background discussion of additional data handling in Appendix B. -4.4.1 TTL With Courtesy Additional Data +4.4.1. TTL with Courtesy Additional Data When a caching resolver asks for the MX record of example.com, it gets back "foo.example.com". It may also get back either one or both @@ -545,32 +500,33 @@ Internet-Draft Considerations with IPv6 DNS July 2005 this case, for the AAAA record) expires; this would avoid the situation where there would be a window of 200 seconds when incomplete information is returned from the cache. Further argument + + + +Durand, et al. Informational [Page 9] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + for discarding is that in the normal operation, the TTL values are so high that very likely the incurred additional queries would not be noticeable, compared to the obtained performance optimization. The - behaviour in this scenario is unspecified. + behavior in this scenario is unspecified. -4.4.2 TTL With Critical Additional Data +4.4.2. TTL with Critical Additional Data The difference to courtesy additional data is that the A/AAAA records - served by the parent zone cannot be queried explicitly. Therefore - - - -Durand, et al. Expires January 17, 2006 [Page 10] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - + served by the parent zone cannot be queried explicitly. Therefore, after 100 seconds the AAAA record is removed from the cache(s), but the A record remains. Queries for the remaining 200 seconds - (provided that there are no further queries from the parent which + (provided that there are no further queries from the parent that could refresh the caches) only return the A record, leading to a - potential opererational situation with unreachable servers. + potential operational situation with unreachable servers. - Similar cache flushing strategies apply in this scenario; the record. + Similar cache flushing strategies apply in this scenario; the + behavior is likewise unspecified. -4.5 IPv6 Transport Guidelines for DNS Servers +4.5. IPv6 Transport Guidelines for DNS Servers As described in Section 1.3 and [RFC3901], there should continue to be at least one authoritative IPv4 DNS server for every zone, even if @@ -583,16 +539,16 @@ Internet-Draft Considerations with IPv6 DNS July 2005 When IPv6 is enabled on a node, there are several things to consider to ensure that the process is as smooth as possible. -5.1 DNS Lookups May Query IPv6 Records Prematurely +5.1. DNS Lookups May Query IPv6 Records Prematurely The system library that implements the getaddrinfo() function for looking up names is a critical piece when considering the robustness - of enabling IPv6; it may come in basically three flavours: + of enabling IPv6; it may come in basically three flavors: 1. The system library does not know whether IPv6 has been enabled in the kernel of the operating system: it may start looking up AAAA records with getaddrinfo() and AF_UNSPEC hint when the system is - upgraded to a system library version which supports IPv6. + upgraded to a system library version that supports IPv6. 2. The system library might start to perform IPv6 queries with getaddrinfo() only when IPv6 has been enabled in the kernel. @@ -600,43 +556,42 @@ Internet-Draft Considerations with IPv6 DNS July 2005 IPv6 connectivity (e.g., the node could be isolated from the other IPv6 networks, only having link-local addresses). - 3. The system library might implement a toggle which would apply - some heuristics to the "IPv6-readiness" of the node before - starting to perform queries; for example, it could check whether - only link-local IPv6 address(es) exists, or if at least one - global IPv6 address exists. + + + +Durand, et al. Informational [Page 10] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + 3. The system library might implement a toggle that would apply some + heuristics to the "IPv6-readiness" of the node before starting to + perform queries; for example, it could check whether only link- + local IPv6 address(es) exists, or if at least one global IPv6 + address exists. First, let us consider generic implications of unnecessary queries for AAAA records: when looking up all the records in the DNS, AAAA records are typically tried first, and then A records. These are done in serial, and the A query is not performed until a response is - - - -Durand, et al. Expires January 17, 2006 [Page 11] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - received to the AAAA query. Considering the misbehaviour of DNS - servers and load-balancers, as described in Section 3.1, the look-up + received to the AAAA query. Considering the misbehavior of DNS + servers and load-balancers, as described in Section 3.1, the lookup delay for AAAA may incur additional unnecessary latency, and introduce a component of unreliability. One option here could be to do the queries partially in parallel; for example, if the final response to the AAAA query is not received in 0.5 seconds, start performing the A query while waiting for the - result (immediate parallelism might be unoptimal, at least without - information sharing between the look-up threads, as that would - probably lead to duplicate non-cached delegation chain lookups). + result. (Immediate parallelism might not be optimal, at least + without information-sharing between the lookup threads, as that would + probably lead to duplicate non-cached delegation chain lookups.) An additional concern is the address selection, which may, in some circumstances, prefer AAAA records over A records even when the node - does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. - In some cases, the implementation may attempt to connect or send a - datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], - incurring very long protocol timeouts, instead of quickly failing - back to IPv4. + does not have any IPv6 connectivity [WIP-RDP2004]. In some cases, + the implementation may attempt to connect or send a datagram on a + physical link [WIP-R2006], incurring very long protocol time-outs, + instead of quickly falling back to IPv4. Now, we can consider the issues specific to each of the three possibilities: @@ -653,66 +608,74 @@ Internet-Draft Considerations with IPv6 DNS July 2005 The second case is similar to the first, except it happens to a smaller set of nodes when IPv6 has been enabled but connectivity has - not been provided yet; similar considerations apply, with the + not been provided yet. Similar considerations apply, with the exception that IPv6 records, when returned, will be actually tried - first which may typically lead to long timeouts. + first, which may typically lead to long time-outs. + + + + +Durand, et al. Informational [Page 11] + +RFC 4472 Considerations with IPv6 DNS April 2006 + The third case is a bit more complex: optimizing away the DNS lookups with only link-locals is probably safe (but may be desirable with - different lookup services which getaddrinfo() may support), as the + different lookup services that getaddrinfo() may support), as the link-locals are typically automatically generated when IPv6 is enabled, and do not indicate any form of IPv6 connectivity. That is, performing DNS lookups only when a non-link-local address has been configured on any interface could be beneficial -- this would be an - indication that either the address has been configured either from a - router advertisement, DHCPv6 [RFC3315], or manually. Each would - - - -Durand, et al. Expires January 17, 2006 [Page 12] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - indicate at least some form of IPv6 connectivity, even though there - would not be guarantees of it. + indication that the address has been configured either from a router + advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + [RFC3315], or manually. Each would indicate at least some form of + IPv6 connectivity, even though there would not be guarantees of it. These issues should be analyzed at more depth, and the fixes found consensus on, perhaps in a separate document. -5.2 Obtaining a List of DNS Recursive Resolvers +5.2. Obtaining a List of DNS Recursive Resolvers In scenarios where DHCPv6 is available, a host can discover a list of - DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" - option [RFC3646]. This option can be passed to a host through a - subset of DHCPv6 [RFC3736]. + DNS recursive resolvers through the DHCPv6 "DNS Recursive Name + Server" option [RFC3646]. This option can be passed to a host + through a subset of DHCPv6 [RFC3736]. The IETF is considering the development of alternative mechanisms for obtaining the list of DNS recursive name servers when DHCPv6 is unavailable or inappropriate. No decision about taking on this - development work has been reached as of this writing (Aug 2004) - [I-D.ietf-dnsop-ipv6-dns-configuration]. + development work has been reached as of this writing [RFC4339]. In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms - under consideration for development include the use of well-known - addresses [I-D.ohta-preconfigured-dns] and the use of Router - Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns- - discovery]. + under consideration for development include the use of [WIP-O2004] + and the use of Router Advertisements to convey the information + [WIP-J2006]. Note that even though IPv6 DNS resolver discovery is a recommended procedure, it is not required for dual-stack nodes in dual-stack networks as IPv6 DNS records can be queried over IPv4 as well as - IPv6. Obviously, nodes which are meant to function without manual + IPv6. Obviously, nodes that are meant to function without manual configuration in IPv6-only networks must implement the DNS resolver discovery function. -5.3 IPv6 Transport Guidelines for Resolvers +5.3. IPv6 Transport Guidelines for Resolvers As described in Section 1.3 and [RFC3901], the recursive resolvers should be IPv4-only or dual-stack to be able to reach any IPv4-only DNS server. Note that this requirement is also fulfilled by an IPv6- only stub resolver pointing to a dual-stack recursive DNS resolver. + + + + + +Durand, et al. Informational [Page 12] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + 6. Considerations about Forward DNS Updating While the topic of how to enable updating the forward DNS, i.e., the @@ -720,47 +683,39 @@ Internet-Draft Considerations with IPv6 DNS July 2005 IPv6, it should be considered especially due to the advent of Stateless Address Autoconfiguration [RFC2462]. - Typically forward DNS updates are more manageable than doing them in + Typically, forward DNS updates are more manageable than doing them in the reverse DNS, because the updater can often be assumed to "own" a - - - -Durand, et al. Expires January 17, 2006 [Page 13] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - certain DNS name -- and we can create a form of security relationship - with the DNS name and the node which is allowed to update it to point + with the DNS name and the node that is allowed to update it to point to a new address. A more complex form of DNS updates -- adding a whole new name into a DNS zone, instead of updating an existing name -- is considered out of scope for this memo as it could require zone-wide authentication. - Adding a new name in the forward zone is a problem which is still + Adding a new name in the forward zone is a problem that is still being explored with IPv4, and IPv6 does not seem to add much new in that area. -6.1 Manual or Custom DNS Updates +6.1. Manual or Custom DNS Updates The DNS mappings can also be maintained by hand, in a semi-automatic fashion or by running non-standardized protocols. These are not considered at more length in this memo. -6.2 Dynamic DNS +6.2. Dynamic DNS Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized mechanism for dynamically updating the DNS. It works equally well - with stateless address autoconfiguration (SLAAC), DHCPv6 or manual + with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual address configuration. It is important to consider how each of these behave if IP address-based authentication, instead of stronger mechanisms [RFC3007], was used in the updates. - 1. manual addresses are static and can be configured + 1. Manual addresses are static and can be configured. 2. DHCPv6 addresses could be reasonably static or dynamic, depending on the deployment, and could or could not be configured on the - DNS server for the long term + DNS server for the long term. 3. SLAAC addresses are typically stable for a long time, but could require work to be configured and maintained. @@ -770,6 +725,13 @@ Internet-Draft Considerations with IPv6 DNS July 2005 requires that the authorization keying will be explicitly configured using unspecified operational methods. + + +Durand, et al. Informational [Page 13] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + Note that with DHCP it is also possible that the DHCP server updates the DNS, not the host. The host might only indicate in the DHCP exchange which hostname it would prefer, and the DHCP server would @@ -778,18 +740,9 @@ Internet-Draft Considerations with IPv6 DNS July 2005 does not help much with "content" security, i.e., whether the hostname was acceptable -- if the DNS server does not include policies, they must be included in the DHCP server (e.g., a regular - - - -Durand, et al. Expires January 17, 2006 [Page 14] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - host should not be able to state that its name is "www.example.com"). DHCP-initiated DDNS updates have been extensively described in - [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and - [I-D.ietf-dnsext-dhcid-rr]. + [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b]. The nodes must somehow be configured with the information about the servers where they will attempt to update their addresses, sufficient @@ -806,14 +759,13 @@ Internet-Draft Considerations with IPv6 DNS July 2005 that if the node is renumbered in a managed fashion, the amount of stale DNS information is kept to the minimum. That is, if the preferred lifetime of an address expires, the TTL of the record needs - be modified unless it was already done before the expiration. For + to be modified unless it was already done before the expiration. For better flexibility, the DNS TTL should be much shorter (e.g., a half or a third) than the lifetime of an address; that way, the node can start lowering the DNS TTL if it seems like the address has not been renewed/refreshed in a while. Some discussion on how an - administrator could manage the DNS TTL is included in [I-D.ietf- - v6ops-renumbering-procedure]; this could be applied to (smart) hosts - as well. + administrator could manage the DNS TTL is included in [RFC4192]; this + could be applied to (smart) hosts as well. 7. Considerations about Reverse DNS Updating @@ -821,27 +773,28 @@ Internet-Draft Considerations with IPv6 DNS July 2005 authority over an address. However, first we have to consider the applicability of reverse DNS in the first place. -7.1 Applicability of Reverse DNS +7.1. Applicability of Reverse DNS - Today, some applications use reverse DNS to either look up some hints - about the topological information associated with an address (e.g. - resolving web server access logs), or as a weak form of a security - check, to get a feel whether the user's network administrator has - "authorized" the use of the address (on the premises that adding a + Today, some applications use reverse DNS either to look up some hints + about the topological information associated with an address (e.g., + resolving web server access logs) or (as a weak form of a security + check) to get a feel whether the user's network administrator has + + + + +Durand, et al. Informational [Page 14] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + "authorized" the use of the address (on the premise that adding a reverse record for an address would signal some form of authorization). One additional, maybe slightly more useful usage is ensuring that the reverse and forward DNS contents match (by looking up the pointer to the name by the IP address from the reverse tree, and ensuring that a - - - -Durand, et al. Expires January 17, 2006 [Page 15] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - record under the name in the forward tree points to the IP address) and correspond to a configured name or domain. As a security check, it is typically accompanied by other mechanisms, such as a user/ @@ -858,14 +811,13 @@ Internet-Draft Considerations with IPv6 DNS July 2005 reverse DNS records be updated. In many cases, it would just make more sense to use proper mechanisms for security (or topological information lookup) in the first place. At minimum, the applications - which use it as a generic authorization (in the sense that a record + that use it as a generic authorization (in the sense that a record exists at all) should be modified as soon as possible to avoid such lookups completely. - The applicability is discussed at more length in [I-D.ietf-dnsop- - inaddr-required]. + The applicability is discussed at more length in [WIP-S2005c]. -7.2 Manual or Custom DNS Updates +7.2. Manual or Custom DNS Updates Reverse DNS can of course be updated using manual or custom methods. These are not further described here, except for one special case. @@ -874,30 +826,32 @@ Internet-Draft Considerations with IPv6 DNS July 2005 example, by configuring one name for a subnet (/64) or a site (/48). As a concrete example, a site (or the site's ISP) could configure the reverses of the prefix 2001:db8:f00::/48 to point to one name using a - wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR - site.example.com." Naturally, such a name could not be verified from - the forward DNS, but would at least provide some form of "topological - information" or "weak authorization" if that is really considered to - be useful. Note that this is not actually updating the DNS as such, - as the whole point is to avoid DNS updates completely by manually - configuring a generic name. + wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR + site.example.com.". Naturally, such a name could not be verified + from the forward DNS, but would at least provide some form of + "topological information" or "weak authorization" if that is really + considered to be useful. Note that this is not actually updating the + DNS as such, as the whole point is to avoid DNS updates completely by + manually configuring a generic name. -7.3 DDNS with Stateless Address Autoconfiguration + + + + + +Durand, et al. Informational [Page 15] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +7.3. DDNS with Stateless Address Autoconfiguration Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in some regard, while being more difficult in another, as described below. - The address space administrator decides whether the hosts are trusted - to update their reverse DNS records or not. If they are trusted and - - - -Durand, et al. Expires January 17, 2006 [Page 16] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - + The address space administrator decides whether or not the hosts are + trusted to update their reverse DNS records. If they are trusted and deployed at the same site (e.g., not across the Internet), a simple address-based authorization is typically sufficient (i.e., check that the DNS update is done from the same IP address as the record being @@ -912,21 +866,21 @@ Internet-Draft Considerations with IPv6 DNS July 2005 DNS. However, when a stronger form of security is used, forward DNS updates are simpler to manage because the host can be assumed to have an association with the domain. Note that the user may roam to - different networks, and does not necessarily have any association - with the owner of that address space -- so, assuming stronger form of + different networks and does not necessarily have any association with + the owner of that address space. So, assuming a stronger form of authorization for reverse DNS updates than an address association is generally infeasible. Moreover, the reverse zones must be cleaned up by an unspecified janitorial process: the node does not typically know a priori that it - will be disconnected, and cannot send a DNS update using the correct - source address to remove a record. + will be disconnected, and it cannot send a DNS update using the + correct source address to remove a record. A problem with defining the clean-up process is that it is difficult to ensure that a specific IP address and the corresponding record are no longer being used. Considering the huge address space, and the unlikelihood of collision within 64 bits of the interface - identifiers, a process which would remove the record after no traffic + identifiers, a process that would remove the record after no traffic has been seen from a node in a long period of time (e.g., a month or year) might be one possible approach. @@ -938,28 +892,29 @@ Internet-Draft Considerations with IPv6 DNS July 2005 authorization is trusted) must also be established by some other means. - One should note that Cryptographically Generated Addresses [RFC3972] - (CGAs) may require a slightly different kind of treatment. CGAs are - addresses where the interface identifier is calculated from a public - key, a modifier (used as a nonce), the subnet prefix, and other data. - Depending on the usage profile, CGAs might or might not be changed - periodically due to e.g., privacy reasons. As the CGA address is not - predicatable, a reverse record can only reasonably be inserted in the - DNS by the node which generates the address. -Durand, et al. Expires January 17, 2006 [Page 17] +Durand, et al. Informational [Page 16] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 -7.4 DDNS with DHCP + One should note that Cryptographically Generated Addresses (CGAs) + [RFC3972] may require a slightly different kind of treatment. CGAs + are addresses where the interface identifier is calculated from a + public key, a modifier (used as a nonce), the subnet prefix, and + other data. Depending on the usage profile, CGAs might or might not + be changed periodically due to, e.g., privacy reasons. As the CGA + address is not predictable, a reverse record can only reasonably be + inserted in the DNS by the node that generates the address. + +7.4. DDNS with DHCP With DHCPv4, the reverse DNS name is typically already inserted to - the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One + the DNS that reflects the name (e.g., "dhcp-67.example.com"). One can assume similar practice may become commonplace with DHCPv6 as - well; all such mappings would be pre-configured, and would require no + well; all such mappings would be pre-configured and would require no updating. If a more explicit control is required, similar considerations as @@ -981,7 +936,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 similar properties except that the janitorial process could be integrated with DHCP address assignment. -7.5 DDNS with Dynamic Prefix Delegation +7.5. DDNS with Dynamic Prefix Delegation In cases where a prefix, instead of an address, is being used and updated, one should consider what is the location of the server where @@ -993,25 +948,25 @@ Internet-Draft Considerations with IPv6 DNS July 2005 the authority of the DNS reverse zone corresponding to the delegated prefix is also delegated to the site. + + + +Durand, et al. Informational [Page 17] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + 3. Elsewhere; this implies a relationship between the site and where - DNS server is located, and such a relationship should be rather - straightforward to secure as well. Like in the previous case, - the authority of the DNS reverse zone is also delegated. + the DNS server is located, and such a relationship should be + rather straightforward to secure as well. Like in the previous + case, the authority of the DNS reverse zone is also delegated. In the first case, managing the reverse DNS (delegation) is simpler as the DNS server and the prefix delegator are in the same administrative domain (as there is no need to delegate anything at all); alternatively, the prefix delegator might forgo DDNS reverse - - - -Durand, et al. Expires January 17, 2006 [Page 18] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - capability altogether, and use e.g., wildcard records (as described - in Section 7.2). In the other cases, it can be slighly more + capability altogether, and use, e.g., wildcard records (as described + in Section 7.2). In the other cases, it can be slightly more difficult, particularly as the site will have to configure the DNS server to be authoritative for the delegated reverse zone, implying automatic configuration of the DNS server -- as the prefix may be @@ -1030,56 +985,56 @@ Internet-Draft Considerations with IPv6 DNS July 2005 8. Miscellaneous DNS Considerations - This section describes miscellaneous considerations about DNS which + This section describes miscellaneous considerations about DNS that seem related to IPv6, for which no better place has been found in this document. -8.1 NAT-PT with DNS-ALG +8.1. NAT-PT with DNS-ALG - The DNS-ALG component of NAT-PT mangles A records to look like AAAA - records to the IPv6-only nodes. Numerous problems have been - identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is - a strong reason not to use NAT-PT in the first place. + The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look + like AAAA records to the IPv6-only nodes. Numerous problems have + been identified with [WIP-AD2005]. This is a strong reason not to + use NAT-PT in the first place. -8.2 Renumbering Procedures and Applications' Use of DNS +8.2. Renumbering Procedures and Applications' Use of DNS One of the most difficult problems of systematic IP address - renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that - an application which looks up a DNS name disregards information such - as TTL, and uses the result obtained from DNS as long as it happens - to be stored in the memory of the application. For applications - which run for a long time, this could be days, weeks or even months; - some applications may be clever enough to organize the data - structures and functions in such a manner that look-ups get refreshed - now and then. + renumbering procedures [RFC4192] is that an application that looks up + a DNS name disregards information such as TTL, and uses the result + obtained from DNS as long as it happens to be stored in the memory of + the application. For applications that run for a long time, this + + + + +Durand, et al. Informational [Page 18] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + could be days, weeks, or even months. Some applications may be + clever enough to organize the data structures and functions in such a + manner that lookups get refreshed now and then. While the issue appears to have a clear solution, "fix the - applications", practically this is not reasonable immediate advice; - the TTL information is not typically available in the APIs and - libraries (so, the advice becomes "fix the applications, APIs and + applications", practically, this is not reasonable immediate advice. + The TTL information is not typically available in the APIs and + libraries (so, the advice becomes "fix the applications, APIs, and libraries"), and a lot more analysis is needed on how to practically - - - -Durand, et al. Expires January 17, 2006 [Page 19] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - go about to achieve the ultimate goal of avoiding using the names longer than expected. 9. Acknowledgements Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik - Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided - useful feedback and improvements. Scott Rose, Rob Austein, Masataka - Ohta, and Mark Andrews helped in clarifying the issues regarding - additional data and the use of TTL. Jefsey Morfin, Ralph Droms, - Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and - Rob Austein provided useful feedback during the WG last call. Thomas - Narten provided extensive feedback during the IESG evaluation. + provisioning were moved here from [RFC4213] by Erik Nordmark and Bob + Gilligan. Havard Eidnes and Michael Patton provided useful feedback + and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark + Andrews helped in clarifying the issues regarding additional data and + the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei + Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided + useful feedback during the WG last call. Thomas Narten provided + extensive feedback during the IESG evaluation. 10. Security Considerations @@ -1087,7 +1042,7 @@ Internet-Draft Considerations with IPv6 DNS July 2005 operations and does not have security considerations in itself. However, it is worth noting that in particular with Dynamic DNS - Updates, security models based on the source address validation are + updates, security models based on the source address validation are very weak and cannot be recommended -- they could only be considered in the environments where ingress filtering [RFC3704] has been deployed. On the other hand, it should be noted that setting up an @@ -1100,274 +1055,249 @@ Internet-Draft Considerations with IPv6 DNS July 2005 (questionable) security-related use for them may be in conjunction with other mechanisms when authenticating a user. + + + + + + + + +Durand, et al. Informational [Page 19] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + 11. References -11.1 Normative References +11.1. Normative References - [I-D.ietf-dnsop-ipv6-dns-configuration] - Jeong, J., "IPv6 Host Configuration of DNS Server - Information Approaches", - draft-ietf-dnsop-ipv6-dns-configuration-06 (work in - progress), May 2005. + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. - [I-D.ietf-ipv6-unique-local-addr] - Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in - progress), January 2005. + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS + UPDATE)", RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, + "Selection and Operation of Secondary DNS Servers", + BCP 16, RFC 2182, July 1997. + + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) + Dynamic Update", RFC 3007, November 2000. + + [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 3041, + January 2001. + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. -Durand, et al. Expires January 17, 2006 [Page 20] +Durand, et al. Informational [Page 20] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - [I-D.ietf-v6ops-renumbering-procedure] - Baker, F., "Procedures for Renumbering an IPv6 Network - without a Flag Day", - draft-ietf-v6ops-renumbering-procedure-05 (work in - progress), March 2005. + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) + Support for Internet Protocol version 6 (IPv6)", + RFC 3364, August 2002. - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. + [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP) Service for IPv6", RFC 3736, + April 2004. - [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. + [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. - [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. + [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport + Operational Guidelines", BCP 91, RFC 3901, + September 2004. - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. + [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. + Castro, "Application Aspects of IPv6 Transition", + RFC 4038, March 2005. - [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, - April 2001. + [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior + Against DNS Queries for IPv6 Addresses", RFC 4074, + May 2005. - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. + [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for + Renumbering an IPv6 Network without a Flag Day", + RFC 4192, September 2005. - [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., - and M. Carney, "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. - Hain, "Representing Internet Protocol version 6 (IPv6) + [RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server + Information Approaches", RFC 4339, February 2006. -Durand, et al. Expires January 17, 2006 [Page 21] + + + + + +Durand, et al. Informational [Page 21] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. +11.2. Informative References - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", RFC 3364, - August 2002. + [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. - [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR + for specifying the location of services (DNS SRV)", + RFC 2782, February 2000. - [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IP Version 6", RFC 3596, - October 2003. + [RFC2826] Internet Architecture Board, "IAB Technical Comment on + the Unique DNS Root", RFC 2826, May 2000. - [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for + Multihomed Networks", BCP 84, RFC 3704, March 2004. - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. + [RFC3972] Aura, T., "Cryptographically Generated Addresses + (CGA)", RFC 3972, March 2005. - [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", RFC 3879, September 2004. + [RFC4025] Richardson, M., "A Method for Storing IPsec Keying + Material in DNS", RFC 4025, March 2005. - [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational - Guidelines", BCP 91, RFC 3901, September 2004. + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. - [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. - Castro, "Application Aspects of IPv6 Transition", - RFC 4038, March 2005. + [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third + Generation Partnership Project (3GPP) Networks", + RFC 4215, October 2005. - [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against - DNS Queries for IPv6 Addresses", RFC 4074, May 2005. + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + February 2006. -11.2 Informative References + [TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit + handling and additional data" on DNSEXT mailing list, + Message- + Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August + 1, 2005, . - [I-D.durand-dnsop-dont-publish] - Durand, A. and T. Chown, "To publish, or not to publish, - that is the question.", draft-durand-dnsop-dont-publish-00 - (work in progress), February 2005. + [WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to + Experimental", Work in Progress, October 2005. - [I-D.huitema-v6ops-teredo] - Huitema, C., "Teredo: Tunneling IPv6 over UDP through - NATs", draft-huitema-v6ops-teredo-05 (work in progress), - April 2005. - - [I-D.huston-6to4-reverse-dns] - Huston, G., "6to4 Reverse DNS Delegation", + [WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to + publish, that is the question", Work in Progress, + October 2005. -Durand, et al. Expires January 17, 2006 [Page 22] + +Durand, et al. Informational [Page 22] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - draft-huston-6to4-reverse-dns-03 (work in progress), - October 2004. + [WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation + Specification", Work in Progress, November 2005. - [I-D.ietf-dhc-ddns-resolution] - Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among - DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in - progress), June 2005. + [WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS + Configuration", Work in Progress, January 2006. - [I-D.ietf-dhc-fqdn-option] - Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", - draft-ietf-dhc-fqdn-option-10 (work in progress), - February 2005. + [WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution + Misbehavior", Work in Progress, February 2006. - [I-D.ietf-dnsext-dhcid-rr] - Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for - encoding DHCP information (DHCID RR)", - draft-ietf-dnsext-dhcid-rr-09 (work in progress), - February 2005. + [WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in + Progress, February 2004. - [I-D.ietf-dnsop-bad-dns-res] - Larson, M. and P. Barber, "Observed DNS Resolution - Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in - progress), October 2004. + [WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption + Considered Harmful", Work in Progress, January 2006. - [I-D.ietf-dnsop-inaddr-required] - Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", - draft-ietf-dnsop-inaddr-required-06 (work in progress), - February 2005. + [WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual + Stack IPv6 on by Default", Work in Progress, July 2004. - [I-D.ietf-v6ops-3gpp-analysis] - Wiljakka, J., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in - progress), October 2004. + [WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in + Progress, March 2006. - [I-D.ietf-v6ops-mech-v2] - Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms - for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 - (work in progress), March 2005. + [WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information + (DHCID RR)", Work in Progress, March 2006. - [I-D.ietf-v6ops-natpt-to-exprmntl] - Aoun, C. and E. Davies, "Reasons to Move NAT-PT to - Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work - in progress), July 2005. + [WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR + Mapping", Work in Progress, August 2005. - [I-D.ietf-v6ops-onlinkassumption] - Roy, S., "IPv6 Neighbor Discovery On-Link Assumption - Considered Harmful", draft-ietf-v6ops-onlinkassumption-03 - (work in progress), May 2005. + [WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts + among DHCP Clients", Work in Progress, March 2006. -Durand, et al. Expires January 17, 2006 [Page 23] + + + + + + + + + + + + + + + + + + + +Durand, et al. Informational [Page 23] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - [I-D.ietf-v6ops-v6onbydefault] - Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack - IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 - (work in progress), July 2004. - - [I-D.jeong-dnsop-ipv6-dns-discovery] - Jeong, J., "IPv6 DNS Configuration based on Router - Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04 - (work in progress), February 2005. - - [I-D.ohta-preconfigured-dns] - Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01 (work in progress), - February 2004. - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [RFC2826] Internet Architecture Board, "IAB Technical Comment on the - Unique DNS Root", RFC 2826, May 2000. - - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed - Networks", BCP 84, RFC 3704, March 2004. - - [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", - RFC 3972, March 2005. - - [RFC4025] Richardson, M., "A Method for Storing IPsec Keying - Material in DNS", RFC 4025, March 2005. - - -Authors' Addresses - - Alain Durand - SUN Microsystems, Inc. - 17 Network circle UMPL17-202 - Menlo Park, CA 94025 - USA - - Email: Alain.Durand@sun.com - - - - - - -Durand, et al. Expires January 17, 2006 [Page 24] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - Email: johani@autonomica.se - - - Pekka Savola - CSC/FUNET - Espoo - Finland - - Email: psavola@funet.fi - Appendix A. Unique Local Addressing Considerations for DNS - Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have - replaced the now-deprecated site-local addresses [RFC3879]. From the - perspective of the DNS, the locally generated unique local addresses - (LUL) and site-local addresses have similar properties. + Unique local addresses [RFC4193] have replaced the now-deprecated + site-local addresses [RFC3879]. From the perspective of the DNS, the + locally generated unique local addresses (LUL) and site-local + addresses have similar properties. The interactions with DNS come in two flavors: forward and reverse DNS. @@ -1378,31 +1308,21 @@ Appendix A. Unique Local Addressing Considerations for DNS procedures to achieve this are not elaborated here. The implication is that local addresses must not be published in the public DNS. - To faciliate reverse DNS (if desired) with local addresses, the stub + To facilitate reverse DNS (if desired) with local addresses, the stub resolvers must look for DNS information from the local DNS servers, - not e.g. starting from the root servers, so that the local + not, e.g., starting from the root servers, so that the local information may be provided locally. Note that the experience of private addresses in IPv4 has shown that the root servers get loaded for requests for private address lookups in any case. This - requirement is discussed in [I-D.ietf-ipv6-unique-local-addr]. + requirement is discussed in [RFC4193]. -Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments +Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments DNS responses do not always fit in a single UDP packet. We'll - examine the cases which happen when this is due to too much data in - the Additional Section. + examine the cases that happen when this is due to too much data in + the Additional section. - - - - - -Durand, et al. Expires January 17, 2006 [Page 25] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - -B.1 Description of Additional Data Scenarios +B.1. Description of Additional Data Scenarios There are two kinds of additional data: @@ -1418,12 +1338,19 @@ B.1 Description of Additional Data Scenarios Only those additional data records (even if sometimes carelessly termed "glue") are considered "critical" or real "glue" if and only - if they meet the abovementioned condition, as specified in Section + if they meet the above-mentioned condition, as specified in Section 4.2.1 of [RFC1034]. + + +Durand, et al. Informational [Page 24] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + Remember that resource record sets (RRsets) are never "broken up", so if a name has 4 A records and 5 AAAA records, you can either return - all 9, all 4 A records, all 5 AAAA records or nothing. In + all 9, all 4 A records, all 5 AAAA records, or nothing. In particular, notice that for the "critical" additional data getting all the RRsets can be critical. @@ -1433,14 +1360,14 @@ B.1 Description of Additional Data Scenarios the TC bit, and the recipient should discard the whole response and retry using mechanism allowing larger responses such as TCP. - b. "courtesy" additional data should not cause the setting of TC + b. "courtesy" additional data should not cause the setting of the TC bit, but instead all the non-fitting additional data RRsets should be removed. An example of the "courtesy" additional data is A/AAAA records in conjunction with MX records as shown in Section 4.4; an example of the "critical" additional data is shown below (where getting both the - A and AAAA RRsets is critical w.r.t. to the NS RR): + A and AAAA RRsets is critical with respect to the NS RR): child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 @@ -1451,25 +1378,38 @@ B.1 Description of Additional Data Scenarios additional data is not critical, even all of it could be safely removed. - - -Durand, et al. Expires January 17, 2006 [Page 26] - -Internet-Draft Considerations with IPv6 DNS July 2005 - - When there is too much "critical" additional data, TC bit will have to be set, and the recipient should ignore the response and retry using TCP; if some data were to be left in the UDP response, the issue is which data could be retained. - Failing to discard the response with TC bit or omitting critical - information but not setting TC bit lead to an unrecoverable problem. - Omitting only some of the RRsets if all would not fit (but not - setting TC bit) leads to a performance problem. These are discussed - in the next two subsections. + However, the practice may differ from the specification. Testing and + code analysis of three recent implementations [TC-TEST] confirm this. + None of the tested implementations have a strict separation of + critical and courtesy additional data, while some forms of additional + data may be treated preferably. All the implementations remove some + (critical or courtesy) additional data RRsets without setting the TC + bit if the response would not otherwise fit. -B.2 Which Additional Data to Keep, If Any? + Failing to discard the response with the TC bit or omitting critical + information but not setting the TC bit lead to an unrecoverable + problem. Omitting only some of the RRsets if all would not fit (but + not setting the TC bit) leads to a performance problem. These are + discussed in the next two subsections. + + + +Durand, et al. Informational [Page 25] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +B.2. Which Additional Data to Keep, If Any? + + NOTE: omitting some critical additional data instead of setting the + TC bit violates a 'should' in Section 9 of RFC2181. However, as many + implementations still do that [TC-TEST], operators need to understand + its implications, and we describe that behavior as well. If the implementation decides to keep as much data (whether "critical" or "courtesy") as possible in the UDP responses, it might @@ -1501,24 +1441,26 @@ B.2 Which Additional Data to Keep, If Any? than a random process would seem justifiable. That is, leaving in some intelligently selected critical additional - data is a tradeoff between creating an optimization for those - resolvers which ignore the "should discard" recommendation, and - causing a protocol problem by propagating inconsistent information - about "critical" records in the caches. - - - - -Durand, et al. Expires January 17, 2006 [Page 27] - -Internet-Draft Considerations with IPv6 DNS July 2005 - + data is a trade-off between creating an optimization for those + resolvers that ignore the "should discard" recommendation and causing + a protocol problem by propagating inconsistent information about + "critical" records in the caches. Similarly, leaving in the complete courtesy additional data RRsets - instead of removing all the RRsets is a performance tradeoff as + instead of removing all the RRsets is a performance trade-off as described in the next section. -B.3 Discussion of the Potential Problems + + + + + +Durand, et al. Informational [Page 26] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +B.3. Discussion of the Potential Problems As noted above, the temptation for omitting only some of the additional data could be problematic. This is discussed more below. @@ -1537,42 +1479,69 @@ B.3 Discussion of the Potential Problems requestor (e.g., a recursive server in the middle) uses makes no difference to the ultimate user of the records, whose transport capabilities might differ from those of the requestor. This might - result in e.g., inappropriately returning A records to an IPv6-only + result in, e.g., inappropriately returning A records to an IPv6-only node, going through a translation, or opening up another IP-level - session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). + session (e.g., a Packet Data Protocol (PDP) context [RFC4215]). Therefore, at least in many scenarios, it would be very useful if the information returned would be consistent and complete -- or if that - is not feasible, return no misleading information but rather leave it - to the client to query again. + is not feasible, leave it to the client to query again. The problem of too much additional data seems to be an operational - one: the zone administrator entering too many records which will be - returned either truncated (or missing some RRsets, depending on + one: the zone administrator entering too many records that will be + returned truncated (or missing some RRsets, depending on implementations) to the users. A protocol fix for this is using - EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, - pushing up the relevant threshold. Further, DNS server - implementations should rather omit courtesy additional data - completely rather than including only some RRsets [RFC2181]. An + Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity + for larger UDP packet sizes, pushing up the relevant threshold. + Further, DNS server implementations should omit courtesy additional + data completely rather than including only some RRsets [RFC2181]. An operational fix for this is having the DNS server implementations - return a warning when the administrators create zones which would + return a warning when the administrators create zones that would result in too much additional data being returned. Further, DNS server implementations should warn of or disallow such zone - configurations which are recursive or otherwise difficult to manage - by the protocol. - - Additionally, to avoid the case where an application would not get an - address at all due to some of courtesy additional data being omitted, + configurations that are recursive or otherwise difficult to manage by + the protocol. -Durand, et al. Expires January 17, 2006 [Page 28] + + + + + + + + +Durand, et al. Informational [Page 27] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 - the resolvers should be able to query the specific records of the - desired protocol, not just rely on getting all the required RRsets in - the additional section. +Authors' Addresses + + Alain Durand + Comcast + 1500 Market St. + Philadelphia, PA 19102 + USA + + EMail: Alain_Durand@cable.comcast.com + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + Sweden + + EMail: johani@autonomica.se + + + Pekka Savola + CSC/FUNET + Espoo + Finland + + EMail: psavola@funet.fi @@ -1598,35 +1567,28 @@ Internet-Draft Considerations with IPv6 DNS July 2005 - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires January 17, 2006 [Page 29] +Durand, et al. Informational [Page 28] -Internet-Draft Considerations with IPv6 DNS July 2005 +RFC 4472 Considerations with IPv6 DNS April 2006 -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -1650,33 +1612,16 @@ Intellectual Property Statement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. +Acknowledgement -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). -Durand, et al. Expires January 17, 2006 [Page 30] + + + +Durand, et al. Informational [Page 29] - diff --git a/doc/rfc/rfc4697.txt b/doc/rfc/rfc4697.txt new file mode 100644 index 0000000000..773507ca69 --- /dev/null +++ b/doc/rfc/rfc4697.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group M. Larson +Request for Comments: 4697 P. Barber +BCP: 123 VeriSign, Inc. +Category: Best Current Practice October 2006 + + + Observed DNS Resolution Misbehavior + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This memo describes DNS iterative resolver behavior that results in a + significant query volume sent to the root and top-level domain (TLD) + name servers. We offer implementation advice to iterative resolver + developers to alleviate these unnecessary queries. The + recommendations made in this document are a direct byproduct of + observation and analysis of abnormal query traffic patterns seen at + two of the thirteen root name servers and all thirteen com/net TLD + name servers. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. A Note about Terminology in this Memo ......................3 + 1.2. Key Words ..................................................3 + 2. Observed Iterative Resolver Misbehavior .........................3 + 2.1. Aggressive Requerying for Delegation Information ...........3 + 2.1.1. Recommendation ......................................5 + 2.2. Repeated Queries to Lame Servers ...........................6 + 2.2.1. Recommendation ......................................6 + 2.3. Inability to Follow Multiple Levels of Indirection .........7 + 2.3.1. Recommendation ......................................7 + 2.4. Aggressive Retransmission when Fetching Glue ...............8 + 2.4.1. Recommendation ......................................9 + 2.5. Aggressive Retransmission behind Firewalls .................9 + 2.5.1. Recommendation .....................................10 + 2.6. Misconfigured NS Records ..................................10 + 2.6.1. Recommendation .....................................11 + + + + +Larson & Barber Best Current Practice [Page 1] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + 2.7. Name Server Records with Zero TTL .........................11 + 2.7.1. Recommendation .....................................12 + 2.8. Unnecessary Dynamic Update Messages .......................12 + 2.8.1. Recommendation .....................................13 + 2.9. Queries for Domain Names Resembling IPv4 Addresses ........13 + 2.9.1. Recommendation .....................................14 + 2.10. Misdirected Recursive Queries ............................14 + 2.10.1. Recommendation ....................................14 + 2.11. Suboptimal Name Server Selection Algorithm ...............15 + 2.11.1. Recommendation ....................................15 + 3. Security Considerations ........................................16 + 4. Acknowledgements ...............................................16 + 5. Internationalization Considerations ............................16 + 6. References .....................................................16 + 6.1. Normative References ......................................16 + 6.2. Informative References ....................................16 + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net Top-Level Domain (TLD) name servers has revealed + that a large proportion of the total traffic often consists of + "requeries". A requery is the same question () + asked repeatedly at an unexpectedly high rate. We have observed + requeries from both a single IP address and multiple IP addresses + (i.e., the same query received simultaneously from multiple IP + addresses). + + By analyzing requery events, we have found that the cause of the + duplicate traffic is almost always a deficient iterative resolver, + stub resolver, or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of indirection must be followed, and aggressive retry by stub + resolvers or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (Denial of Service (DoS) attacks, crashes, maintenance, + routing failures, congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. None of the changes recommended affects the core DNS protocol + specification; instead, this document consists of guidelines to + implementors of iterative resolvers. + + + + + +Larson & Barber Best Current Practice [Page 2] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +1.1. A Note about Terminology in This Memo + + To recast an old saying about standards, the nice thing about DNS + terms is that there are so many of them to choose from. Writing or + talking about DNS can be difficult and can cause confusion resulting + from a lack of agreed-upon terms for its various components. Further + complicating matters are implementations that combine multiple roles + into one piece of software, which makes naming the result + problematic. An example is the entity that accepts recursive + queries, issues iterative queries as necessary to resolve the initial + recursive query, caches responses it receives, and which is also able + to answer questions about certain zones authoritatively. This entity + is an iterative resolver combined with an authoritative name server + and is often called a "recursive name server" or a "caching name + server". + + This memo is concerned principally with the behavior of iterative + resolvers, which are typically found as part of a recursive name + server. This memo uses the more precise term "iterative resolver", + because the focus is usually on that component. In instances where + the name server role of this entity requires mentioning, this memo + uses the term "recursive name server". As an example of the + difference, the name server component of a recursive name server + receives DNS queries and the iterative resolver component sends + queries. + + The advent of IPv6 requires mentioning AAAA records as well as A + records when discussing glue. To avoid continuous repetition and + qualification, this memo uses the general term "address record" to + encompass both A and AAAA records when a particular situation is + relevant to both types. + +1.2. Key Words + + 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 RFC 2119 [1]. + +2. Observed Iterative Resolver Misbehavior + +2.1. Aggressive Requerying for Delegation Information + + There can be times when every name server in a zone's NS RRSet is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host), or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider an iterative resolver + that attempts to resolve a query for a domain name in such a zone and + + + +Larson & Barber Best Current Practice [Page 3] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation whose + iterative resolver then verifies the zone's NS RRSet in its cache by + querying for the zone's delegation information: it sends a query for + the zone's NS RRSet to one of the parent zone's name servers. (Note + that queries with QTYPE=NS are not required by the standard + resolution algorithm described in Section 4.3.2 of RFC 1034 [2]. + These NS queries represent this implementation's addition to that + algorithm.) + + For example, suppose that "example.com" has the following NS RRSet: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this iterative resolver implementation immediately queries a + "com" zone name server for the "example.com" NS RRSet to verify that + it has the proper delegation information. This implementation + performs this query to a zone's parent zone for each recursive query + it receives that fails because of a completely unresponsive set of + name servers for the target zone. Consider the effect when a popular + zone experiences a catastrophic failure of all its name servers: now + every recursive query for domain names in that zone sent to this + recursive name server implementation results in a query to the failed + zone's parent name servers. On one occasion when several dozen + popular zones became unreachable, the query load on the com/net name + servers increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: when an iterative resolver is resolving a query for a + domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent would be pointless: this query to the parent would come so + quickly on the heels of the referral that it would be almost certain + to contain the same list of name servers. The chance of discovering + any new information is slim. + + The other possibility is that the iterative resolver successfully + contacts one of the target zone's name servers and then caches the NS + RRSet from the authority section of a response, the proper behavior + according to Section 5.4.1 of RFC 2181 [3], because the NS RRSet from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the iterative resolver discovers that none of the name servers + + + +Larson & Barber Best Current Practice [Page 4] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + specified in the cached NS RRSet is available or authoritative, + querying the parent would be wrong. An NS RRSet from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured or decommissioned AND the + delegation information in the parent zone would have to be updated + with the new set of name servers, all within the Time to Live (TTL) + of the target zone's NS RRSet. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually when at all possible, with servers + removed from the NS RRSet left authoritative for the zone as long as + possible. The scenarios that we can envision that would benefit from + the parent requery behavior do not outweigh its damaging effects. + + This section should not be understood to claim that all queries to a + zone's parent are bad. In some cases, such queries are not only + reasonable but required. Consider the situation when required + information, such as the address of a name server (i.e., the address + record corresponding to the RDATA of an NS record), has timed out of + an iterative resolver's cache before the corresponding NS record. If + the name of the name server is below the apex of the zone, then the + name server's address record is only available as glue in the parent + zone. For example, consider this NS record: + + example.com. IN NS ns.example.com. + + If a cache has this NS record but not the address record for + "ns.example.com", it is unable to contact the "example.com" zone + directly and must query the "com" zone to obtain the address record. + Note, however, that such a query would not have QTYPE=NS according to + the standard resolution algorithm. + +2.1.1. Recommendation + + An iterative resolver MUST NOT send a query for the NS RRSet of a + non-responsive zone to any of the name servers for that zone's parent + zone. For the purposes of this injunction, a non-responsive zone is + defined as a zone for which every name server listed in the zone's NS + RRSet: + + 1. is not authoritative for the zone (i.e., lame), or + + 2. returns a server failure response (RCODE=2), or + + 3. is dead or unreachable according to Section 7.2 of RFC 2308 [4]. + + + + +Larson & Barber Best Current Practice [Page 5] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.2. Repeated Queries to Lame Servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is when a subset of a zone's name servers is + unavailable or misconfigured. Different failure modes have different + expected durations. Some symptoms indicate problems that are + potentially transient, for example, various types of ICMP unreachable + messages because a name server process is not running or a host or + network is unreachable, or a complete lack of a response to a query. + Such responses could be the result of a host rebooting or temporary + outages; these events do not necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + + It should also be noted, however, that some authoritative name server + implementations appear to be lame only for queries of certain types + as described in RFC 4074 [5]. In this case, it makes sense to retry + the "lame" servers for other types of queries, particularly when all + known authoritative name servers appear to be "lame". + +2.2.1. Recommendation + + Iterative resolvers SHOULD cache name servers that they discover are + not authoritative for zones delegated to them (i.e., lame servers). + If this caching is performed, lame servers MUST be cached against the + specific query tuple . Zone + name can be derived from the owner name of the NS record that was + referenced to query the name server that was discovered to be lame. + + Implementations that perform lame server caching MUST refrain from + sending queries to known lame servers for a configurable time + interval after the server is discovered to be lame. A minimum + interval of thirty minutes is RECOMMENDED. + + + + + + + + +Larson & Barber Best Current Practice [Page 6] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + An exception to this recommendation occurs if all name servers for a + zone are marked lame. In that case, the iterative resolver SHOULD + temporarily ignore the servers' lameness status and query one or more + servers. This behavior is a workaround for the type-specific + lameness issue described in the previous section. + + Implementors should take care not to make lame server avoidance logic + overly broad: note that a name server could be lame for a parent zone + but not a child zone, e.g., lame for "example.com" but properly + authoritative for "sub.example.com". Therefore, a name server should + not be automatically considered lame for subzones. In the case + above, even if a name server is known to be lame for "example.com", + it should be queried for QNAMEs at or below "sub.example.com" if an + NS record indicates that it should be authoritative for that zone. + +2.3. Inability to Follow Multiple Levels of Indirection + + Some iterative resolver implementations are unable to follow + sufficient levels of indirection. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + An iterative resolver resolving the name "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" or "ns2.test.example.net" in order to obtain + address records for "ns1.example.com" or "ns2.example.com" in order + to query those name servers for the address records of + "www.foo.example". Although this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + top-level domains (gTLDs) become active. We anticipate many zones in + new gTLDs will use name servers in existing gTLDs, increasing the + number of delegations using out-of-zone name servers. + +2.3.1. Recommendation + + Clearly constructing a delegation that relies on multiple levels of + indirection is not a good administrative practice. However, the + practice is widespread enough to require that iterative resolvers be + able to cope with it. Iterative resolvers SHOULD be able to handle + arbitrary levels of indirection resulting from out-of-zone name + + + +Larson & Barber Best Current Practice [Page 7] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + servers. Iterative resolvers SHOULD implement a level-of-effort + counter to avoid loops or otherwise performing too much work in + resolving pathological cases. + + A best practice that avoids this entire issue of indirection is to + name one or more of a zone's name servers in the zone itself. For + example, if the zone is named "example.com", consider naming some of + the name servers "ns{1,2,...}.example.com" (or similar). + +2.4. Aggressive Retransmission when Fetching Glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in Section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include address records for every NS record in + the authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing address records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such an entity will not + normally generate any queries of its own. Instead it answers non- + recursive queries from iterative resolvers looking for information in + zones it serves. With glue fetching enabled, however, an + authoritative server invokes an iterative resolver to look up an + unknown address record to complete the additional section of a + response. + + We have observed situations where the iterative resolver of a glue- + fetching name server can send queries that reach other name servers, + but is apparently prevented from receiving the responses. For + example, perhaps the name server is authoritative-only and therefore + its administrators expect it to receive only queries and not + responses. Perhaps unaware of glue fetching and presuming that the + name server's iterative resolver will generate no queries, its + administrators place the name server behind a network device that + prevents it from receiving responses. If this is the case, all + glue-fetching queries will go unanswered. + + We have observed name server implementations whose iterative + resolvers retry excessively when glue-fetching queries are + unanswered. A single com/net name server has received hundreds of + queries per second from a single such source. Judging from the + + + +Larson & Barber Best Current Practice [Page 8] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + specific queries received and based on additional analysis, we + believe these queries result from overly aggressive glue fetching. + +2.4.1. Recommendation + + Implementers whose name servers support glue fetching SHOULD take + care to avoid sending queries at excessive rates. Implementations + SHOULD support throttling logic to detect when queries are sent but + no responses are received. + +2.5. Aggressive Retransmission behind Firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, an + iterative resolver is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose iterative resolvers' + traffic is improperly filtered in this manner. Stub resolvers in the + organization could be configured to query multiple recursive name + servers. Consider the case where a stub resolver queries a filtered + recursive name server first. The iterative resolver of this + recursive name server sends one or more queries whose replies are + filtered, so it cannot respond to the stub resolver, which times out. + Then the stub resolver retransmits to a recursive name server that is + able to provide an answer. Since resolution ultimately succeeds the + underlying problem might not be recognized or corrected. A popular + stub resolver implementation has a very aggressive retransmission + schedule, including simultaneous queries to multiple recursive name + servers, which could explain how such a situation could persist + without being detected. + + + + + + + + +Larson & Barber Best Current Practice [Page 9] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.5.1. Recommendation + + The most obvious recommendation is that administrators SHOULD take + care not to place iterative resolvers behind a firewall that allows + queries, but not the resulting replies, to pass through. + + Iterative resolvers SHOULD take care to avoid sending queries at + excessive rates. Implementations SHOULD support throttling logic to + detect when queries are sent but no responses are received. + +2.6. Misconfigured NS Records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. An iterative resolver + attempting to resolve address records for "www.example.com" with no + cached information for this zone will query a "com" authoritative + server. The "com" server responds with a referral to the + "example.com" zone, consisting of NS records with valid RDATA and + associated glue records. (This example assumes that the + "example.com" zone delegation information is correct in the "com" + zone.) The iterative resolver caches the NS RRSet from the "com" + server and follows the referral by querying one of the "example.com" + authoritative servers. This server responds with the + "www.example.com" address record in the answer section and, + typically, the "example.com" NS records in the authority section and, + if space in the message remains, glue address records in the + additional section. According to Section 5.4.1 of RFC 2181 [3], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a non- + authoritative answer. Thus, the "example.com" NS RRSet just received + from the "example.com" authoritative server overrides the + "example.com" NS RRSet received moments ago from the "com" + authoritative server. + + + + + +Larson & Barber Best Current Practice [Page 10] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + But the "example.com" zone contains the erroneous NS RRSet as shown + in the example above. Subsequent queries for names in "example.com" + will cause the iterative resolver to attempt to use the incorrect NS + records and so it will try to resolve the nonexistent names + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the iterative resolver cannot reach any "example.com" name + servers. Therefore, attempts to resolve these names result in + address record queries to the "com" authoritative servers. Queries + for such obviously bogus glue address records occur frequently at the + com/net name servers. + +2.6.1. Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that exists somewhere under the apex of the zone + that the NS record appears in. Note that further levels of + delegation are possible, so a missing trailing dot could + inadvertently create a name server name that actually exists in a + subzone. + + An authoritative name server SHOULD issue a warning when one of a + zone's NS records references a name server below the zone's apex when + a corresponding address record does not exist in the zone AND there + are no delegated subzones where the address record could exist. + +2.7. Name Server Records with Zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRSet, however, carries + additional consequences beyond the zone itself: if an iterative + resolver cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRSet expected to change frequently is extreme but + permissible. A zone's NS RRSet is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + zone parent/child relationships that we are aware of, there is + + + +Larson & Barber Best Current Practice [Page 11] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + typically some delay involved in effecting changes. Furthermore, + changes to the set of a zone's authoritative name servers (and + therefore to the zone's NS RRSet) are typically relatively rare: + providing reliable authoritative service requires a reasonably stable + set of servers. Therefore, an extremely low or zero TTL on a zone's + NS RRSet rarely makes sense, except in anticipation of an upcoming + change. In this case, when the zone's administrator has planned a + change and does not want iterative resolvers throughout the Internet + to cache the NS RRSet for a long period of time, a low TTL is + reasonable. + +2.7.1. Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers resulting from a zero TTL on a zone's NS RRSet, + under such circumstances authoritative name servers SHOULD issue a + warning when loading a zone. + +2.8. Unnecessary Dynamic Update Messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's Start of Authority (SOA) + record's MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone entails walking up the name + space tree by sending repeated UPDATE messages until successful. For + example, consider an agent attempting to add an address record with + the name "foo.bar.example.com". The agent could first attempt to + update the "foo.bar.example.com" zone. If the attempt failed, the + update could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A valid question is why the algorithm proceeds to send + updates all the way to TLD and root name servers. This behavior is + not entirely unreasonable: in enterprise DNS architectures with an + + + +Larson & Barber Best Current Practice [Page 12] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + "internal root" design, there could conceivably be private, non- + public TLD or root zones that would be the appropriate targets for a + dynamic update. + + A significant deficiency with this algorithm is that knowledge of a + given UPDATE message's failure is not helpful in directing future + UPDATE messages to the appropriate servers. A better algorithm would + be to find the closest enclosing zone by walking up the name space + with queries for SOA or NS rather than "probing" with UPDATE + messages. Once the appropriate zone is found, an UPDATE message can + be sent. In addition, the results of these queries can be cached to + aid in determining the closest enclosing zones for future updates. + Once the closest enclosing zone is determined with this method, the + update will either succeed or fail and there is no need to send + further updates to higher-level zones. The important point is that + walking up the tree with queries yields cacheable information, + whereas walking up the tree by sending UPDATE messages does not. + +2.8.1. Recommendation + + Dynamic update agents SHOULD send SOA or NS queries to progressively + higher-level names to find the closest enclosing zone for a given + name to update. Only after the appropriate zone is found should the + client send an UPDATE message to one of the zone's authoritative + servers. Update clients SHOULD NOT "probe" using UPDATE messages by + walking up the tree to progressively higher-level zones. + +2.9. Queries for Domain Names Resembling IPv4 Addresses + + The root name servers receive a significant number of A record + queries where the QNAME looks like an IPv4 address. The source of + these queries is unknown. It could be attributed to situations where + a user believes that an application will accept either a domain name + or an IP address in a given configuration option. The user enters an + IP address, but the application assumes that any input is a domain + name and attempts to resolve it, resulting in an A record lookup. + There could also be applications that produce such queries in a + misguided attempt to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. An iterative + resolver can negatively cache such responses, but each response + requires a separate cache entry; i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + + + + + + + +Larson & Barber Best Current Practice [Page 13] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.9.1. Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + bandwidth. A possible solution is to delegate these numeric TLDs + from the root zone to a separate set of servers to absorb the + traffic. The "black hole servers" used by the AS 112 Project + (http://www.as112.net), which are currently delegated the + in-addr.arpa zones corresponding to RFC 1918 [7] private use address + space, would be a possible choice to receive these delegations. Of + course, the proper and usual root zone change procedures would have + to be followed to make such a change to the root zone. + +2.10. Misdirected Recursive Queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the Recursion Desired (RD) bit set in the + header). Since none of the root servers offers recursion, the + servers' response in such a situation ignores the request for + recursion and the response probably does not contain the data the + querier anticipated. Some of these queries result from users + configuring stub resolvers to query a root server. (This situation + is not hypothetical: we have received complaints from users when this + configuration does not work as hoped.) Of course, users should not + direct stub resolvers to use name servers that do not offer + recursion, but we are not aware of any stub resolver implementation + that offers any feedback to the user when so configured, aside from + simply "not working". + +2.10.1. Recommendation + + When the IP address of a name server that supposedly offers recursion + is configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server indeed + supports recursion (i.e., verify that the response has the RA bit set + in the header). The user could be notified immediately if the server + is non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting SHOULD be throttled to avoid a + notification or log message for every response from a non-recursive + server. + + + + + + + + +Larson & Barber Best Current Practice [Page 14] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.11. Suboptimal Name Server Selection Algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully under-specified, requiring + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by an iterative resolver. When an iterative resolver wants + to contact one of a zone's authoritative name servers, how does it + choose from the NS records listed in the zone's NS RRSet? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1. Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. That is, these changes + would help spread the query load evenly. + + o Do not make assumptions based on NS RRSet order: all NS RRs SHOULD + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for + "a.gtld-servers.net" first in the authority section of referrals. + Apparently as a result, this server receives disproportionately + more traffic than the other twelve authoritative servers for + "com".) + + o Use all NS records in an RRSet. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + + o Do not lock onto the best-performing of a zone's name servers. An + iterative resolver SHOULD periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + +Larson & Barber Best Current Practice [Page 15] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +3. Security Considerations + + The iterative resolver misbehavior discussed in this document exposes + the root and TLD name servers to increased risk of both intentional + and unintentional Denial of Service attacks. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + +4. Acknowledgements + + The authors would like to thank the following people for their + comments that improved this document: Andras Salamon, Dave Meyer, + Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, + Olafur Gudmundsson, Pekka Savola, Peter Koch, and Rob Austein. We + apologize if we have omitted anyone; any oversight was unintentional. + +5. Internationalization Considerations + + There are no new internationalization considerations introduced by + this memo. + +6. References + +6.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + +6.2. Informative References + + [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS + Queries for IPv6 Addresses", RFC 4074, May 2005. + + [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April + 1997. + + + +Larson & Barber Best Current Practice [Page 16] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + [7] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: pbarber@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Best Current Practice [Page 17] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Larson & Barber Best Current Practice [Page 18] + From acf4c059533bf09f31b230781d3cd48695597604 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 19 Nov 2009 05:58:22 +0000 Subject: [PATCH 18/18] new draft --- ...aft-ietf-dnsop-default-local-zones-09.txt} | 501 ++++++++++-------- 1 file changed, 279 insertions(+), 222 deletions(-) rename doc/draft/{draft-ietf-dnsop-default-local-zones-05.txt => draft-ietf-dnsop-default-local-zones-09.txt} (60%) diff --git a/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt similarity index 60% rename from doc/draft/draft-ietf-dnsop-default-local-zones-05.txt rename to doc/draft/draft-ietf-dnsop-default-local-zones-09.txt index 230c036776..7e81e4c4bf 100644 --- a/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt +++ b/doc/draft/draft-ietf-dnsop-default-local-zones-09.txt @@ -3,19 +3,27 @@ Network Working Group M. Andrews Internet-Draft ISC -Intended status: BCP June 5, 2008 -Expires: December 7, 2008 +Intended status: BCP November 19, 2009 +Expires: May 23, 2010 Locally-served DNS Zones - draft-ietf-dnsop-default-local-zones-05 + draft-ietf-dnsop-default-local-zones-09 + +Abstract + + Experience with the Domain Name System (DNS) has shown that there are + a number of DNS zones all iterative resolvers and recursive + nameservers should automatically serve, unless configured otherwise. + RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This + document extends the practice to cover the IN-ADDR.ARPA zones for RFC + 1918 address space and other well known zones with similar + characteristics. Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -33,28 +41,76 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 7, 2008. + This Internet-Draft will expire on May 23, 2010. -Abstract +Copyright Notice - Experience has shown that there are a number of DNS zones all - iterative resolvers and recursive nameservers should, unless - configured otherwise, automatically serve. RFC 4193 specifies that - this should occur for D.F.IP6.ARPA. This document extends the - practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space - and other well known zones with similar characteristics. + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal - - - - - - -Andrews Expires December 7, 2008 [Page 1] +Andrews Expires May 23, 2010 [Page 1] -Internet-Draft Locally-served DNS Zones June 2008 +Internet-Draft Locally-served DNS Zones November 2009 + + + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Andrews Expires May 23, 2010 [Page 2] + +Internet-Draft Locally-served DNS Zones November 2009 Table of Contents @@ -64,30 +120,34 @@ Table of Contents 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5 - 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5 - 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. RFC1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. RFC3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7 + 4.6. IPv6 Example Prefix . . . . . . . . . . . . . . . . . . . 7 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Change History [To Be Removed on Publication] . . . . 10 - A.1. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 10 - A.2. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 10 - A.3. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10 - A.4. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10 - A.5. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11 - A.6. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11 - A.7. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11 - A.8. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11 - Appendix B. Proposed Status [To Be Removed on Publication] . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 - Intellectual Property and Copyright Statements . . . . . . . . . . 12 + A.1. draft-ietf-dnsop-default-local-zones-09.txt . . . . . . . 10 + A.2. draft-ietf-dnsop-default-local-zones-08.txt . . . . . . . 10 + A.3. draft-ietf-dnsop-default-local-zones-07.txt . . . . . . . 10 + A.4. draft-ietf-dnsop-default-local-zones-06.txt . . . . . . . 10 + A.5. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 11 + A.6. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 11 + A.7. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 11 + A.8. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 11 + A.9. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11 + A.10. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11 + A.11. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11 + A.12. draft-andrews-full-service-resolvers-02.txt . . . . . . . 12 + Appendix B. Proposed Status [To Be Removed on Publication] . . . 12 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 @@ -104,23 +164,20 @@ Table of Contents - - - - -Andrews Expires December 7, 2008 [Page 2] +Andrews Expires May 23, 2010 [Page 3] -Internet-Draft Locally-served DNS Zones June 2008 +Internet-Draft Locally-served DNS Zones November 2009 1. Introduction - Experience has shown that there are a number of DNS [RFC 1034] [RFC - 1035] zones that all iterative resolvers and recursive nameservers - SHOULD, unless intentionally configured otherwise, automatically - serve. These zones include, but are not limited to, the IN-ADDR.ARPA - zones for the address space allocated by [RFC 1918] and the IP6.ARPA - zones for locally assigned unique local IPv6 addresses, [RFC 4193]. + Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035]) + has shown that there are a number of DNS zones that all iterative + resolvers and recursive nameservers SHOULD automatically serve, + unless intentionally configured otherwise. These zones include, but + are not limited to, the IN-ADDR.ARPA zones for the address space + allocated by [RFC1918] and the IP6.ARPA zones for locally assigned + unique local IPv6 addresses defined in [RFC4193]. This recommendation is made because data has shown that significant leakage of queries for these name spaces is occurring, despite @@ -141,9 +198,9 @@ Internet-Draft Locally-served DNS Zones June 2008 configuration will address all these issues for the zones listed in Section 4. - [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled + [RFC4193] recommends that queries for D.F.IP6.ARPA be handled locally. This document extends the recommendation to cover the IN- - ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and + ADDR.ARPA zones for [RFC1918] and other well known IN-ADDR.ARPA and IP6.ARPA zones for which queries should not appear on the public Internet. @@ -151,27 +208,26 @@ Internet-Draft Locally-served DNS Zones June 2008 [AS112] will not have to be increased, and may in time be reduced. This recommendation should also help DNS responsiveness for sites - which are using [RFC 1918] addresses but do not follow the last - paragraph in Section 3 of [RFC 1918]. + which are using [RFC1918] addresses but do not follow the last + paragraph in Section 3 of [RFC1918]. 1.1. Reserved Words 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 [RFC 2119]. + document are to be interpreted as described in [RFC2119]. - -Andrews Expires December 7, 2008 [Page 3] +Andrews Expires May 23, 2010 [Page 4] -Internet-Draft Locally-served DNS Zones June 2008 +Internet-Draft Locally-served DNS Zones November 2009 2. Effects on sites using RFC 1918 addresses. - For most sites using [RFC 1918] addresses, the changes here will have + For most sites using [RFC1918] addresses, the changes here will have little or no detrimental effect. If the site does not already have the reverse tree populated the only effect will be that the name error responses will be generated locally rather than remotely. @@ -182,7 +238,7 @@ Internet-Draft Locally-served DNS Zones June 2008 recommendation will not be relevant. The most significant impact will be felt at sites that make use of - delegations for [RFC 1918] addresses and have populated these zones. + delegations for [RFC1918] addresses and have populated these zones. These sites will need to override the default configuration expressed in this document to allow resolution to continue. Typically, such sites will be fully disconnected from the Internet and have their own @@ -196,7 +252,7 @@ Internet-Draft Locally-served DNS Zones June 2008 zones in Section 4, with the obvious exception of queries for the zone name itself where SOA, NS and "no data" responses will be returned as appropriate to the query type. One common way to do this - is to serve empty (SOA and NS only) zones. + all at once is to serve empty (SOA and NS only) zones. An implementation of this recommendation MUST provide a mechanism to disable this new behaviour, and SHOULD allow this decision on a zone @@ -208,7 +264,7 @@ Internet-Draft Locally-served DNS Zones June 2008 Internet servers. This document recommends that the NS record defaults to the name of the zone and the SOA MNAME defaults to the name of the only NS RR's target. The SOA RNAME should default to - "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a + "nobody.invalid." [RFC2606]. Implementations SHOULD provide a mechanism to set these values. No address records need to be provided for the name server. @@ -220,12 +276,12 @@ Internet-Draft Locally-served DNS Zones June 2008 -Andrews Expires December 7, 2008 [Page 4] +Andrews Expires May 23, 2010 [Page 5] -Internet-Draft Locally-served DNS Zones June 2008 +Internet-Draft Locally-served DNS Zones November 2009 - The SOA RR is needed to support negative caching [RFC 2308] of name + The SOA RR is needed to support negative caching [RFC2308] of name error responses and to point clients to the primary master for DNS dynamic updates. @@ -234,7 +290,7 @@ Internet-Draft Locally-served DNS Zones June 2008 SOA timer values MAY be chosen arbitrarily since they are not intended to control any zone transfer activity. - The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries + The NS RR is needed as some UPDATE [RFC2136] clients use NS queries to discover the zone to be updated. Having no address records for the name server is expected to abort UPDATE processing in the client. @@ -245,10 +301,10 @@ Internet-Draft Locally-served DNS Zones June 2008 requested in the IANA Considerations Section. The zone name is the entity to be registered. -4.1. RFC 1918 Zones +4.1. RFC1918 Zones The following zones correspond to the IPv4 address space reserved in - [RFC 1918]. + [RFC1918]. +----------------------+ | Zone | @@ -276,17 +332,16 @@ Internet-Draft Locally-served DNS Zones June 2008 -Andrews Expires December 7, 2008 [Page 5] +Andrews Expires May 23, 2010 [Page 6] -Internet-Draft Locally-served DNS Zones June 2008 +Internet-Draft Locally-served DNS Zones November 2009 -4.2. RFC 3330 Zones +4.2. RFC3330 Zones - The following zones correspond to those address ranges from [RFC - 3330] that are not expected to appear as source or destination - addresses on the public Internet and to not have a unique name to - associate with. + The following zones correspond to those address ranges from [RFC3330] + that are not expected to appear as source or destination addresses on + the public Internet and to not have a unique name to associate with. The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a attempt to discourage any practice to provide a PTR RR for @@ -308,17 +363,17 @@ Internet-Draft Locally-served DNS Zones June 2008 4.3. Local IPv6 Unicast Addresses - The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for - the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291], + The reverse mappings ([RFC3596], Section 2.5 IP6.ARPA Domain) for the + IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291], Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones: +-------------------------------------------+ | Zone | +-------------------------------------------+ | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | - | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | + | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | - | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | + | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | +-------------------------------------------+ Note: Line breaks and a escapes '\' have been inserted above for @@ -327,14 +382,15 @@ Internet-Draft Locally-served DNS Zones June 2008 4.4. IPv6 Locally Assigned Local Addresses - Section 4.4 of [RFC 4193] already required special treatment of: + Section 4.4 of [RFC4193] already required special treatment of: -Andrews Expires December 7, 2008 [Page 6] + +Andrews Expires May 23, 2010 [Page 7] -Internet-Draft Locally-served DNS Zones June 2008 +Internet-Draft Locally-served DNS Zones November 2009 +--------------+ @@ -345,7 +401,7 @@ Internet-Draft Locally-served DNS Zones June 2008 4.5. IPv6 Link Local Addresses - IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered + IPv6 Link-Local Addresses as of [RFC4291], Section 2.5.6 are covered by four distinct reverse DNS zones: +----------------+ @@ -357,27 +413,49 @@ Internet-Draft Locally-served DNS Zones June 2008 | B.E.F.IP6.ARPA | +----------------+ +4.6. IPv6 Example Prefix + + IPv6 example prefix [RFC3849]. + + +--------------------------+ + | Zone | + +--------------------------+ + | 8.B.D.0.1.0.0.2.IP6.ARPA | + +--------------------------+ + + Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as a example here. + 5. Zones that are Out-Of-Scope - IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and - IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered - here. It is expected that IPv6 site-local addresses will be self - correcting as IPv6 implementations remove support for site-local - addresses. However, sacrificial servers for C.E.F.IP6.ARPA through + IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and + 2.5.7), and IPv6 Non-Locally Assigned Local addresses ([RFC4193]) are + not covered here. + + It is expected that IPv6 site-local addresses will be self correcting + as IPv6 implementations remove support for site-local addresses. + However, sacrificial servers for the zones C.E.F.IP6.ARPA through F.E.F.IP6.ARPA may still need to be deployed in the short term if the traffic becomes excessive. - For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193], + For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC4193], there has been no decision made about whether the Regional Internet Registries (RIRs) will provide delegations in this space or not. If + + + +Andrews Expires May 23, 2010 [Page 8] + +Internet-Draft Locally-served DNS Zones November 2009 + + they don't, then C.F.IP6.ARPA will need to be added to the list in Section 4.4. If they do, then registries will need to take steps to ensure that name servers are provided for these addresses. This document also ignores IP6.INT. IP6.INT has been wound up with only legacy resolvers now generating reverse queries under IP6.INT - [RFC 4159]. + [RFC4159]. This document has also deliberately ignored names immediately under the root domain. While there is a subset of queries to the root name @@ -387,21 +465,15 @@ Internet-Draft Locally-served DNS Zones June 2008 for unqualified hostnames, IPv6 addresses). - -Andrews Expires December 7, 2008 [Page 7] - -Internet-Draft Locally-served DNS Zones June 2008 - - 6. IANA Considerations This document requests that IANA establish a registry of zones which - require this default behaviour. The initial contents of which are in - Section 4. Implementors are encouraged to check this registry and - adjust their implementations to reflect changes therein. + require this default behaviour. The initial contents of this + registry are defined in Section 4. Implementors are encouraged to + periodically check this registry and adjust their implementations to + reflect changes therein. - This registry can be amended through "IETF Consensus" as per [RFC - 2434]. + This registry can be amended through "IETF Review" as per [RFC5226]. IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is deployed in the reverse tree, delegations for these zones are made in @@ -410,7 +482,7 @@ Internet-Draft Locally-served DNS Zones June 2008 7. Security Considerations - During the initial deployment phase, particularly where [RFC 1918] + During the initial deployment phase, particularly where [RFC1918] addresses are in use, there may be some clients that unexpectedly receive a name error rather than a PTR record. This may cause some service disruption until their recursive name server(s) have been re- @@ -423,8 +495,16 @@ Internet-Draft Locally-served DNS Zones June 2008 being answered from the delegated servers. It is recommended that sites actively using these namespaces secure - them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust + them using DNSSEC [RFC4035] by publishing and using DNSSEC trust anchors. This will protect the clients from accidental import of + + + +Andrews Expires May 23, 2010 [Page 9] + +Internet-Draft Locally-served DNS Zones November 2009 + + unsigned responses from the Internet. @@ -438,138 +518,137 @@ Internet-Draft Locally-served DNS Zones June 2008 9.1. Normative References - [RFC 1034] - Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", + [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, RFC 1034, November 1987. - - -Andrews Expires December 7, 2008 [Page 8] - -Internet-Draft Locally-served DNS Zones June 2008 - - - [RFC 1035] - Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND + [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", STD 13, RFC 1035, November 1987. - [RFC 1918] - Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. - [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC 2136] - Vixie, P., Thomson, A., Rekhter, Y., and J. Bound, + [RFC2136] Vixie, P., Thomson, A., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. - [RFC 2308] - Andrews, M., "Negative Caching of DNS Queries (DNS + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2398, March 1998. - [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS + [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. - [RFC 3596] - Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IPv6", RFC 3596, October 2003. - [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. - [RFC 4159] - Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159, + [RFC4159] Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159, August 2005. - [RFC 4193] - Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. - -Andrews Expires December 7, 2008 [Page 9] +Andrews Expires May 23, 2010 [Page 10] -Internet-Draft Locally-served DNS Zones June 2008 +Internet-Draft Locally-served DNS Zones November 2009 - [RFC 4291] - Hinden, R. and S. Deering, "IP Version 6 Addressing + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + October 2008. + 9.2. Informative References [AS112] "AS112 Project", . [I-D.draft-ietf-dnsop-as112-ops] Abley, J. and W. Maton, "AS112 Nameserver Operations", - draft-ietf-dnsop-as112-ops-00 (work in progress), - February 2007. + draft-ietf-dnsop-as112-ops-01 (work in progress), + November 2007. [I-D.draft-ietf-dnsop-as112-under-attack-help-help] Abley, J. and W. Maton, "I'm Being Attacked by PRISONER.IANA.ORG!", - draft-ietf-dnsop-as112-under-attack-help-help-00 (work in - progress), February 2007. + draft-ietf-dnsop-as112-under-attack-help-help-01 (work in + progress), November 2007. - [RFC 3330] - "Special-Use IPv4 Addresses", RFC 3330, September 2002. + [RFC3330] "Special-Use IPv4 Addresses", RFC 3330, September 2002. + + [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix + Reserved for Documentation", RFC 3849, July 2004. Appendix A. Change History [To Be Removed on Publication] -A.1. draft-ietf-dnsop-default-local-zones-05.txt +A.1. draft-ietf-dnsop-default-local-zones-09.txt + + refresh awaiting writeup + +A.2. draft-ietf-dnsop-default-local-zones-08.txt + + editorial, reference updates + +A.3. draft-ietf-dnsop-default-local-zones-07.txt none, expiry prevention -A.2. draft-ietf-dnsop-default-local-zones-04.txt +A.4. draft-ietf-dnsop-default-local-zones-06.txt + + add IPv6 example prefix + + + + + + +Andrews Expires May 23, 2010 [Page 11] + +Internet-Draft Locally-served DNS Zones November 2009 + + +A.5. draft-ietf-dnsop-default-local-zones-05.txt + + none, expiry prevention + +A.6. draft-ietf-dnsop-default-local-zones-04.txt Centrally Assigned Local addresses -> Non-Locally Assigned Local address -A.3. draft-ietf-dnsop-default-local-zones-03.txt +A.7. draft-ietf-dnsop-default-local-zones-03.txt expanded section 4 descriptions - Added references [RFC 2136], [RFC 3596], + Added references [RFC2136], [RFC3596], [I-D.draft-ietf-dnsop-as112-ops] and [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. Revised language. -A.4. draft-ietf-dnsop-default-local-zones-02.txt +A.8. draft-ietf-dnsop-default-local-zones-02.txt RNAME now "nobody.invalid." - - - -Andrews Expires December 7, 2008 [Page 10] - -Internet-Draft Locally-served DNS Zones June 2008 - - Revised language. -A.5. draft-ietf-dnsop-default-local-zones-01.txt +A.9. draft-ietf-dnsop-default-local-zones-01.txt Revised impact description. Updated to reflect change in IP6.INT status. -A.6. draft-ietf-dnsop-default-local-zones-00.txt +A.10. draft-ietf-dnsop-default-local-zones-00.txt Adopted by DNSOP. @@ -579,11 +658,22 @@ A.6. draft-ietf-dnsop-default-local-zones-00.txt Title changed. -A.7. draft-andrews-full-service-resolvers-03.txt +A.11. draft-andrews-full-service-resolvers-03.txt Added "Proposed Status". -A.8. draft-andrews-full-service-resolvers-02.txt + + + + + + +Andrews Expires May 23, 2010 [Page 12] + +Internet-Draft Locally-served DNS Zones November 2009 + + +A.12. draft-andrews-full-service-resolvers-02.txt Added 0.IN-ADDR.ARPA. @@ -612,61 +702,28 @@ Author's Address -Andrews Expires December 7, 2008 [Page 11] + + + + + + + + + + + + + + + + + + + + + + +Andrews Expires May 23, 2010 [Page 13] -Internet-Draft Locally-served DNS Zones June 2008 - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - - - - - - - - - -Andrews Expires December 7, 2008 [Page 12] -