Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"

[Mark Andrews <[e-mail]>]

In message <CAH1iCir6R=[e-mail]>
, Brian Dickson writes:
> 
> On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews <[e-mail]> wrote:
> 
> >
> > In message <CAH1iCioPZiO78j478BV7t=pTN9LZXQbweeBZQF2w3O1gKwx3XA@mail.
> > gmail.com>
> > , Brian Dickson writes:
> > >
> > > On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon <[e-mail]> wrote:
> > >
> > > > On Dec 14, 2016, at 5:04 PM, John Levine <[e-mail]> wrote:
> > > >
> > > > But it's worse than that -- if your client software does DNSSEC
> > > > validation it needs to understand that homenet is a special case and
> > > > it's OK not to validate.
> > > >
> > > > [etc]
> > > >
> > > >
> > > > That is precisely why we need an unsecured delegation.
> > > >
> > > >
> > >
> > >
> > > I agree that in the current world, an unsigned delegation is required.
> > >
> > > I would humbly suggest that use of an AS112-like set of well-known names
> > > and IP addresses, would be the preferred way of DOING that delegation.
> > >
> > > A well-known address set would allow homenet-aware devices to be
> > > pre-loaded
> > > with the address of the NS, while non-aware would learn it through the
> > > delegation.
> > >
> > > If it were possible to have the names be served by root servers (as a
> > > consequence of being in the set of domains served by the root servers),
> > > then the glue data would be signed and validate-able, which is about as
> > > good as you can get (security-wise), while making homenet strictly local.
> > >
> > > (Within a given homenet, the well known IP(s) could be handled via
> > > anycast
> > > or similar mechanisms, presuming the homenet mechanisms support things
> > > like
> > > that.)
> > >
> > > My personal recommendation would be non-RFC-1918 well known addresses.
> > >
> > > This ensures that for queries that leak from non-1918 space sourced
> > > queries, that the delegation is to an address that is guaranteed to be
> > > reachable, even if the local set-up is badly broken.
> > >
> > > That IP would be configured to give itself as the answer to any query,
> > > and
> > > be configured to provide (rate-limed) HTTP (wild-card) responses,
> > > that serve up the RFC for how to set up homenet. (If that RFC doesn't
> > > exist, that really should be next on the WG milestones.)
> > >
> > > All roads would then lead to the answer to the question, which is, "How
> > > do
> > > I get this stuff to work?".
> > >
> > > Brian
> >
> > Why is this any better than a referral to the existing root servers
> > and a empty locally served .homenet zone with the previously mentioned
> > constraint of only enabling it when the namespace is not being
> > forwarded.  We do this for all the default local zones so this will
> > just be a extra name in the list of empty local zones that are
> > automatically configured.  A 5 minute job to commit to all the
> > branches once the name is approved.  Other vendors do similar.  The
> > root servers will always need to be answering for homenet/DS.  The
> > locally served .homenet zone will stop most of the leaks for *.homenet
> > at the ISP level.
> >
> 
> It depends on perspective, and your definition of "better".
> 
> The homenet folks want zero configuration, want it to work, and don't want
> to wait.
> 
> The difference between the scenarios are:
> - How a non-aware resolver within a homenet (which has a correctly deployed
> aware resolver) behaves
> - How much infrastructure requires changes before the first improperly
> deployed homenet gets any help
>   - In your scenario, it never gets help, and leaks to the root until ISPs
> and/or resolvers get changes deployed
>   - In my scenario, the first instance of an upgraded AS112 node (with new
> address being anycast) results in universal support, modulo available
> capacity

Add this or the equivalent to each root server.

zone homenet {
	file "homenet.db";
	masters { icann's servers; };
	type slave;
};

homenet.db:
HOMENET. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2016121401 1800 900 604800 86400
HOMENET. 86400 IN NS A.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS B.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS C.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS D.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS E.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS F.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS G.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS H.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS I.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS J.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS K.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS L.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS M.ROOT-SERVERS.NET.

and add the following to the root zone

HOMENET. 86400 IN NS A.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS B.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS C.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS D.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS E.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS F.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS G.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS H.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS I.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS J.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS K.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS L.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS M.ROOT-SERVERS.NET.

verses

* getting new IPv4 and IPv6 address blocks for the new anycast servers.
* configuring them to serve the zone.
* getting the prefixes for these servers announced world wide.
* getting the insecure delegation into the root zone as it is still needed.

	HOMENET. 86400 IN NS SOME.NEW.SERVER.
	HOMENET. 86400 IN NS ANOTHER.NEW.SERVER.

* adding the new addresses to the every homenet router since you don't
  want to follow the delegation from the root servers.

In what world is the second senario faster or less work than the first?

Just bringing up undelegated servers for HOMENET does not help is
any way what so ever.  A homenet aware router will not talk to them
ever as it is authoritative for HOMENET or knows the servers that
are authoritative via HNCP and will direct HOMENET queries there
other than for HOMENET/DS which will be directed to the rootserver
(directly or indirectly).  If the domain advertised in via HNCP is
not HOMENET it still configures itself as authoritative for HOMENET
with a empty zone to catch leaks from roaming devices.  A non homenet
aware router will not talk to them ever as they are not delegated
too.

> If you only care about leaking, you are missing the point.
> 
> If you care about both leaking, *and* getting mixed environments to work,
> *and* minimizing deployment support costs, you should be able to see why
> this is better.

No.  You have not shown this.

> > If there are too many leaks after 5 years (give ISPs time to deploy
> > the new servers) then consider a AS112 like solution but I don't
> > think it will be needed.
> 
> IMHO, this is mostly backwards. In this case, I think the AS112 would
> probably need to be permanent.
> 
> But, in general, the fastest way of fixing the leaks is, deploy the leak
> shield (AS112), then fix the leaks, then remove the leak shield when it is
> no longer needed.
> 
> Waiting until the deluge has become a dribble, seems backwards.
> (Plus, look how well that worked for spam.)

There is no deluge at the moment.  There should not be a deluge in
the future as HOMENET routers don't leak HOMENET lookups and HOMENET
aware name servers don't leak HOMENET queries as they self configure
to serve HOMENET.  The delay is to give time to allow ISPs to deploy
HOMENET aware servers.

This is not RFC 1918 where there were just instructions to "don't
leak".  In this case we are deploying software that actively stops
leaks by default.

Mark

> Brian
> 
> 
> >
> > Mark
> >
> > > PS For the DNSSEC-aware humans:
> > >
> > > I think this exposes an unforeseen edge case, not covered in the design
> > of
> > > DNSSEC.
> > >
> > > I think what would have been ideal, would have been the ability to
> > securely
> > > delegate to a well-known name/address, but without a secure entry point.
> > > I.e. where parent/child NS use different RRTYPEs, and the parent NS is
> > > signed (along with glue), and there is no DS.
> > >
> > > The child could exist as an island of security, and have a self-signed
> > > DNSKEY (or KSK/ZSK pair).
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: [phone]                 INTERNET: [e-mail]
> >
> 
> --001a11467d66e3e63d0543a920b7
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
> te">On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews <span dir=3D"ltr">&lt;<a =
> href=3D"mailto:[e-mail]" target=3D"_blank">[e-mail]</a>&gt;</span=
> > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
> rder-left:1px #ccc solid;padding-left:1ex"><br>
> In message &lt;CAH1iCioPZiO78j478BV7t=3D<a href=3D"mailto:pTN9LZXQbweeBZQF2=
> [e-mail]">pTN9LZ<wbr>XQbweeBZQF2w3O1gKwx3XA@mail.<wbr>gma=
> il.com</a>&gt;<br>
> <div><div class=3D"h5">, Brian Dickson writes:<br>
> &gt;<br>
> &gt; On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon &lt;<a href=3D"mailto:mello=
> [e-mail]">[e-mail]</a>&gt; wrote:<br>
> &gt;<br>
> &gt; &gt; On Dec 14, 2016, at 5:04 PM, John Levine &lt;<a href=3D"mailto:jo=
> [e-mail]">[e-mail]</a>&gt; wrote:<br>
> &gt; &gt;<br>
> &gt; &gt; But it&#39;s worse than that -- if your client software does DNSS=
> EC<br>
> &gt; &gt; validation it needs to understand that homenet is a special case =
> and<br>
> &gt; &gt; it&#39;s OK not to validate.<br>
> &gt; &gt;<br>
> &gt; &gt; [etc]<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; That is precisely why we need an unsecured delegation.<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt; I agree that in the current world, an unsigned delegation is required.=
> <br>
> &gt;<br>
> &gt; I would humbly suggest that use of an AS112-like set of well-known nam=
> es<br>
> &gt; and IP addresses, would be the preferred way of DOING that delegation.=
> <br>
> &gt;<br>
> &gt; A well-known address set would allow homenet-aware devices to be pre-l=
> oaded<br>
> &gt; with the address of the NS, while non-aware would learn it through the=
> <br>
> &gt; delegation.<br>
> &gt;<br>
> &gt; If it were possible to have the names be served by root servers (as a<=
> br>
> &gt; consequence of being in the set of domains served by the root servers)=
> ,<br>
> &gt; then the glue data would be signed and validate-able, which is about a=
> s<br>
> &gt; good as you can get (security-wise), while making homenet strictly loc=
> al.<br>
> &gt;<br>
> &gt; (Within a given homenet, the well known IP(s) could be handled via any=
> cast<br>
> &gt; or similar mechanisms, presuming the homenet mechanisms support things=
>  like<br>
> &gt; that.)<br>
> &gt;<br>
> &gt; My personal recommendation would be non-RFC-1918 well known addresses.=
> <br>
> &gt;<br>
> &gt; This ensures that for queries that leak from non-1918 space sourced<br=
> >
> &gt; queries, that the delegation is to an address that is guaranteed to be=
> <br>
> &gt; reachable, even if the local set-up is badly broken.<br>
> &gt;<br>
> &gt; That IP would be configured to give itself as the answer to any query,=
>  and<br>
> &gt; be configured to provide (rate-limed) HTTP (wild-card) responses,<br>
> &gt; that serve up the RFC for how to set up homenet. (If that RFC doesn&#3=
> 9;t<br>
> &gt; exist, that really should be next on the WG milestones.)<br>
> &gt;<br>
> &gt; All roads would then lead to the answer to the question, which is, &qu=
> ot;How do<br>
> &gt; I get this stuff to work?&quot;.<br>
> &gt;<br>
> &gt; Brian<br>
> <br>
> </div></div>Why is this any better than a referral to the existing root ser=
> vers<br>
> and a empty locally served .homenet zone with the previously mentioned<br>
> constraint of only enabling it when the namespace is not being<br>
> forwarded.=C2=A0 We do this for all the default local zones so this will<br=
> >
> just be a extra name in the list of empty local zones that are<br>
> automatically configured.=C2=A0 A 5 minute job to commit to all the<br>
> branches once the name is approved.=C2=A0 Other vendors do similar.=C2=A0 T=
> he<br>
> root servers will always need to be answering for homenet/DS.=C2=A0 The<br>
> locally served .homenet zone will stop most of the leaks for *.homenet<br>
> at the ISP level.<br></blockquote><div><br></div><div>It depends on perspec=
> tive, and your definition of &quot;better&quot;.</div><div><br></div><div>T=
> he homenet folks want zero configuration, want it to work, and don&#39;t wa=
> nt to wait.</div><div><br></div><div>The difference between the scenarios a=
> re:</div><div>- How a non-aware resolver within a homenet (which has a corr=
> ectly deployed aware resolver) behaves</div><div>- How much infrastructure =
> requires changes before the first improperly deployed homenet gets any help=
> </div><div>=C2=A0 - In your scenario, it never gets help, and leaks to the =
> root until ISPs and/or resolvers get changes deployed</div><div>=C2=A0 - In=
>  my scenario, the first instance of an upgraded AS112 node (with new addres=
> s being anycast) results in universal support, modulo available capacity</d=
> iv><div><br></div><div>If you only care about leaking, you are missing the =
> point.</div><div><br></div><div>If you care about both leaking, *and* getti=
> ng mixed environments to work, *and* minimizing deployment support costs, y=
> ou should be able to see why this is better.</div><div>=C2=A0</div><blockqu=
> ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
> olid;padding-left:1ex">
> <br>
> If there are too many leaks after 5 years (give ISPs time to deploy<br>
> the new servers) then consider a AS112 like solution but I don&#39;t<br>
> think it will be needed.<br></blockquote><div><br></div><div>IMHO, this is =
> mostly backwards. In this case, I think the AS112 would probably need to be=
>  permanent.</div><div><br></div><div>But, in general, the fastest way of fi=
> xing the leaks is, deploy the leak shield (AS112), then fix the leaks, then=
>  remove the leak shield when it is no longer needed.</div><div><br></div><d=
> iv>Waiting until the deluge has become a dribble, seems backwards.</div><di=
> v>(Plus, look how well that worked for spam.)</div><div><br></div><div>Bria=
> n</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
>  0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> Mark<br>
> </font></span><span class=3D"im HOEnZb"><br>
> &gt; PS For the DNSSEC-aware humans:<br>
> &gt;<br>
> &gt; I think this exposes an unforeseen edge case, not covered in the desig=
> n of<br>
> &gt; DNSSEC.<br>
> &gt;<br>
> &gt; I think what would have been ideal, would have been the ability to sec=
> urely<br>
> &gt; delegate to a well-known name/address, but without a secure entry poin=
> t.<br>
> &gt; I.e. where parent/child NS use different RRTYPEs, and the parent NS is=
> <br>
> &gt; signed (along with glue), and there is no DS.<br>
> &gt;<br>
> &gt; The child could exist as an island of security, and have a self-signed=
> <br>
> &gt; DNSKEY (or KSK/ZSK pair).<br>
> </span><div class=3D"HOEnZb"><div class=3D"h5">--<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"[phone]">+61 2=
>  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0INTERNET: <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
> </div></div></blockquote></div><br></div></div>
> 
> --001a11467d66e3e63d0543a920b7--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]