Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

[George Michaelson]

Thank you for a quick, informed and above all open decision Terry.

-George

On Thu, Mar 30, 2017 at 3:54 PM, Ted Lemon  wrote:
> Thanks, Terry!  I know this wasn't a fun discussion, but it is good to get a
> clear answer that sets or expectations, so thanks for that!
>
> ___
> DNSOP mailing list
> dn...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D.ietf-homenet-dot

[David Schinazi]

Ted,

Apologies, I did not mean to reopen that debate,
I just wanted to say that I was in favor of moving quickly, whatever the chosen 
name.

David


> On Mar 30, 2017, at 18:11, Ted Lemon  wrote:
> 
> On Mar 30, 2017, at 6:05 PM, David Schinazi  > wrote:
>> However, since this string shouldn't be visible to users, this sounds like 
>> the color of the roof of the bike shed.
> 
> David, unless something has changed since the last time we had this argument, 
> let's set it aside.   Certainly there are people participating in this 
> discussion who believe that users will see names, even if you don't believe 
> that.   I don't see how we could gain consensus on your position, nor do I 
> see any advantage to trying, since you lose nothing if the name is 
> human-readable.
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D.ietf-homenet-dot

[Ted Lemon]

On Mar 30, 2017, at 6:05 PM, David Schinazi  wrote:
> However, since this string shouldn't be visible to users, this sounds like 
> the color of the roof of the bike shed.

David, unless something has changed since the last time we had this argument, 
let's set it aside.   Certainly there are people participating in this 
discussion who believe that users will see names, even if you don't believe 
that.   I don't see how we could gain consensus on your position, nor do I see 
any advantage to trying, since you lose nothing if the name is human-readable.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D.ietf-homenet-dot

[David Schinazi]

I support science fiction.

However, since this string shouldn't be visible to users, this sounds like the 
color of the roof of the bike shed.

David


> On Mar 30, 2017, at 18:01, james woodyatt  wrote:
> 
> 
> On Mar 30, 2017, at 17:54, Ted Lemon  > wrote:
>> 
>> I'm okay with either hm or hab.   I would very much like for us not to tube 
>> on a beauty contest discussion, though.   It would be nice to turn this 
>> draft around quickly.
> 
> So, it’s settled then. :)
> 
> --james woodyatt >
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D.ietf-homenet-dot

[Ted Lemon]

I'm okay with either hm or hab.   I would very much like for us not to tube on 
a beauty contest discussion, though.   It would be nice to turn this draft 
around quickly.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

[Ted Lemon]

Leaving dnsop of the cc list, I would like to propose that we cut to the
chase and choose hm.arpa. If some vendor with deep pockets wants to find a
good application, we could talk about that, but I don't expect that, and
even if it were to happen, it wouldn't happen soon since there is no
schedule for the next gtld fiasco.

I think demanding that validating resolvers be specially modified doesn't
scale, so my personal preference is to not go down that road. But I think
that is the only option of we want to keep .homenet.

On Mar 30, 2017 3:54 PM, "Ted Lemon"  wrote:

> Thanks, Terry!  I know this wasn't a fun discussion, but it is good to get
> a clear answer that sets or expectations, so thanks for that!
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

[Ted Lemon]

Thanks, Terry!  I know this wasn't a fun discussion, but it is good to get
a clear answer that sets or expectations, so thanks for that!
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

[Terry Manderson]

Dear WGs (HOMENET and DNSOP)

Based on the reviews from many folk, the discussions in DNSOP and HOMENET, the 
clarifying questions and responses during the HOMENET session at IETF98, a 
number of other DNS expert level discussions I have had, and the IAB statement 
[1] my final assessment on the HOMENET domain is as follows.

A TLD request is not the ideal architectural direction that would encompass the 
goals of the greater Internet along with the ethos and scope of the IETF.

I shall be returning the document (draft-ietf-homenet-dot) to the WG to 
consider and find consensus on a domain under .ARPA

The already stated technical assessment is a .ARPA subdomain can satisfy the 
requirement for a special use domain, in addition to being resolvable in the 
DNS with the requested characteristics. The WG should consider the situations 
where the name of the device is escalated to the user, not that I believe the 
WG should engage in UI/UX design, but to ensure that if it is desired by the WG 
that the name be suitably obfuscated, HOMENET features should exist to ensure 
that.

Thanks
Terry

[1] 
https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/


On 29/03/2017, 3:32 AM, "DNSOP on behalf of Terry Manderson" 
 wrote:

Dear HOMENET and DNSOP WG(s),

Wearing the INT AD hat.

Firstly, thank you to the DNSOP WG for the deep review, thoughts, and 
considered responses to my request for review.

Secondly, my apologies for not sharing my throughs before the HOMENET 
session. It would have been impractical to do so as this is a very (VERY) fluid 
situation with IETF leadership also engaged in discussions.

This is simply an iteration of my description of the current situation as 
delivered yesterday. Do be aware that conversations are continuing and you 
should NOT take this as a declarative statement. During the HOMENET WG session 
I specified that for this topic I am comfortable answering _ clarifying _ 
questions. The same applies here. My answers may or may not change due to the 
fluid nature of the concern and I hope you appreciate that.

My summary of the situation is this.

1) .homenet _COULD_ be added to the special use domain registry based on 
RFC6761 

2) The expected future operation of HOMENET resolution for DNSSEC 
validating stub resolvers requires a break in the DNSSEC chain of trust.

3) To achieve "2", the document _additionally_ asks IANA to insert an 
insecure delegation into the root zone

4) The ask for "3" is not covered in IETF policy terms, in fact it tries to 
put an entry into someone else's registry (the root zone), and will require a 
set of collaborative discussions with the ICANN community and a new process 
that handles this situation. There are no expectations that this process will 
be defined in a reasonable time for the uses of HOMENET.


Options, possibly not an exhaustive list

A) seek a .homenet special use domain with the request for an insecure 
delegation in the root zone. (This is what the document asks for NOW, and here 
we are)

B) seek a .homenet special use domain WITHOUT the delegation request AND 
ask the IETF/IESG/IAB to commence the discussion with the ICANN community to 
achieve an insecure delegation

c) seek a .arpa insecure special use delegation

d) go for "B" and if that doesn't work shift to "C"


Each of these have different positive and negatives in a raw technical 
sense, UI design desires, and policy and political frames.

Again, this situation is fluid and as discussions evolve I will provide 
more information when it is appropriate. In the mean-time I would very much 
like everyone to take a calming breath and understand that I am taking a very 
pragmatic view of this concern.

Cheers,
Terry
INT AD



smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

[Ted Lemon]

On Mar 30, 2017, at 1:11 PM, Steve Crocker  wrote:
> And I remain puzzled as to why a simple NXDOMAIN response from the root isn’t 
> exactly the right thing and why it matters whether it’s signed or not.

Because DNSSEC.   A validating stub will see a proof of nonexistence and ignore 
anything the local recursive resolver offers.___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

[Mark Andrews]

In message 
, Brian Di
ckson writes:
> 
> Mark,
> 
> When I say, "never reaches the roots", this is what I mean:
> Resolution of "example." is, by design, intercepted by
> homenet resolvers, and never reaches the outside world.
> Do you concur with this statement?

Yes, but that isn't the complete picture.  "never" doesn't mean "most of the
time".  "never" means "never".
 
> Please stop conflating the issue of "the homenet namespace is local" (and
> thus not resolvable from outside starting at the DNS root) from the issue
> of the need for an insecure delegation IF homenet end systems do their own
> DNSSEC validation AND those same end systems don't special-case homenet
> from validation AND IF homenet is not signed with a separate trust anchor.

I want RFC 4035 compliant validating systems to be able to resolve
local names with the default homenet domain name when they are
connected to a homenet. That cannot happen without there being a
insecure delegation in the global namespace that breaks the DNSSEC
chain of trust.  Additionally the chosen name MUST exist in the
global namespace to avoid QNAME minimisation issues.

> Yes, IF validating stubs need to confirm the unsigned nature of homenet,
> THEN there is a need for retrieving the appropriate DNSSEC proof showing
> that there is a delegation out of the chain of trust anchored at the DNS
> root.
> 
> What that proof looks like is dependent on the issue under discussion,
> which is what the domain name for homenet should be, and why.

RFC 4035 states what that proof needs to look like.  That proof needs to
exist at whatever name is chosen.

> If the domain for homenet is "homenet." anchored in the root zone, then
> yes, "homenet/DS" will need to be obtained (or more correctly,
> "homenet/NSEC" proving no DS exists), signed by the ZSK of the root, along
> with the signed DNSKEY set (signed by the KSK of the root, i.e. the ICANN
> root trust anchor).
> 
> If the domain for homenet is something else, such as "homenet.arpa.", then
> the proof contains more elements, such as the DS for arpa, and the NSEC for
> homenet.arpa (proving no homenet.arpa/DS exists).
> 
> Brian
> 
> On Thu, Mar 30, 2017 at 12:20 AM, Mark Andrews  wrote:
> 
> >
> > In message  > gmail.com>, Brian Dickson writes:
> > > On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley 
> > wrote:
> > >
> > > >
> > > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson
> > > 
> > > > wrote:
> > > > >
> > > > >
> > > > > Terry Manderson  wrote:
> > > > >> B) seek a .homenet special use domain WITHOUT the delegation reque=
> st
> > > > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICAN=
> N
> > > > >> community to achieve an insecure delegation
> > > > >
> > > > >> c) seek a .arpa insecure special use delegation
> > > > >
> > > > >> d) go for "B" and if that doesn't work shift to "C"
> > > > >
> > > > > Is there some reason we can not proceed with "C", concurrently with
> > (B).
> > > >
> > > > I think that would require a new consensus call. There was a lot of
> > work
> > > > done to get to the point of agreeing on a path forward at the last
> > IETF,
> > > > and this path would be rather different than that.
> > > >
> > > > > This might cause stub resolvers to have to have two cases
> > > > > (SOMETHING.arpa, and .homenet) eventually, but at least we could
> > deploy
> > > > > and attempt interop with SOMETHING.arpa NOW, and it would more
> > clearly
> > > > > permit "home." to be removed from code.
> > > > >
> > > >
> > > > /chair-hat-off
> > > >
> > > > I don=E2=80=99t think we want to have two defaults in our specs. It=
> =E2=80=99s bad
> > enough
> > > > that we are already going to end up with .home and .homenet depending
> > on
> > > > the version of code used or forked from, I really don=E2=80=99t want =
> to do
> > anything
> > > > that could lead to a third if we can avoid it.
> > > >
> > > > - Mark
> > > >
> > >
> > > Taking a STRICTLY devil's advocate position here:
> > >
> > > Isn't it the case that the thing that knows what the  label is=
> ,
> > > should be able to masquerade on behalf of anything that isn't aware of
> > the
> > > divergence of the three possible values for ? If you end up wi=
> th
> > > some boxes thinking it is ".home", some ".homenet", and some
> > > ".homenet.arpa", as long as one of them knows about all three, it shoul=
> d
> > > be possible to resolve the differences.
> > >
> > > The scope of the namespace is "the home network", and never reaches the
> > > real DNS (roots), so at worst it would be folding the three fake
> > > namespaces into a unified (three-headed) fake namespace.
> >
> > Can we please stop with this "and never reaches the real DNS (roots)"
> > garbage.  Queries for homenet/DS *will* reach the roots.  That is
> > how DNSSEC 

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

[Paul Vixie]

On Thursday, March 30, 2017 6:11:00 PM GMT Steve Crocker wrote:
> On the other hand, might there be value in seeing how much errant traffic
> goes to the root so it can be reported and used to inform vendors, network
> architects, network administrators, et al?

it seems unlikely to me that any of them would care. they didn't for RFC 1918, 
and i did try, for years, before DNS-OARC existed, using f-root trace data.

> Given the amount of bogus traffic already goes to the root, I’m not
> immediately worried this will increase the traffic level to a point of
> concern.

that's what we've said about every other incremental increase. some day we 
will reach a tipping point and be wrong. i think if we know that dreck is 
coming, we should prepare for it, perhaps with an NS RR pointing to the AS112 
project, whose operators are ready to share data with researchers on request.

perversely, the ~90+% garbage we receive helps motivate overprovisioning, and 
helps ensure that when some server is down, its impact (less than 10% of load 
that should be answered) is statistically spread out across a large amount of 
dreck. if only good queries made it to the roots, then the statisticaly 
likelihood of not being able to answer one that mattered, would be higher. 
it's a congestion-based form of forward error correction, i suppose.

> And I remain puzzled as to why a simple NXDOMAIN response from the root
> isn’t exactly the right thing and why it matters whether it’s signed or
> not.

nxdomain isn't cached by everyone who should, and of those who cache it, 
nxdomain doesn't stop downward cache traversal everywhere (which it should), 
and in any case nxdomain covers the full qname and so would only stop 
traversals through a full (foo.bar.) qname, which is why we need 
query-minimization (which would permit queries for just  or 
perhaps .) whose cached nxdomains would have a broader 
impact (if they stopped traversal and if they are cached at all.)

executive summary: the dns works at all, and we love that, but it's not happy 
and it's not healthy and it's never going to be.

vixie

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

[Steve Crocker]

On the other hand, might there be value in seeing how much errant traffic goes 
to the root so it can be reported and used to inform vendors, network 
architects, network administrators, et al?

Given the amount of bogus traffic already goes to the root, I’m not immediately 
worried this will increase the traffic level to a point of concern.

And I remain puzzled as to why a simple NXDOMAIN response from the root isn’t 
exactly the right thing and why it matters whether it’s signed or not.

Steve

> On Mar 30, 2017, at 2:05 PM, Paul Vixie  wrote:
> 
> On Thursday, March 30, 2017 5:54:50 PM GMT Brian Dickson wrote:
>> Mark,
>> 
>> When I say, "never reaches the roots", this is what I mean:
>> Resolution of "example." is, by design, intercepted by
>> homenet resolvers, and never reaches the outside world.
>> Do you concur with this statement?
>> 
>> ...
> 
> i'm not mark, but i'd like to speak on a related topic.
> 
> by design, queries that result in RFC 1918 addresses, and queries for RFC 
> 1918 
> PTR names, were to be intercepted by local resolvers.
> 
> let me know if you can't access DNS-OARC's DITL archives, which will show you 
> how prominent both kinds those queries loom in actual root name service load.
> 
> i predict that foo.bar. will do likewise, whatever its design. 
> this is the one saving grace in asking for a real root zone delegation: we 
> can 
> add an NS pointing to localhost, and try to get subsequent queries to go to 
> heck rather than to the root servers.
> 
> vixie
> 
> ___
> DNSOP mailing list
> dn...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [DNSOP] My assessment of .homenet as described during the WG session yesterday.

[Paul Vixie]

On Thursday, March 30, 2017 5:54:50 PM GMT Brian Dickson wrote:
> Mark,
> 
> When I say, "never reaches the roots", this is what I mean:
> Resolution of "example." is, by design, intercepted by
> homenet resolvers, and never reaches the outside world.
> Do you concur with this statement?
> 
> ...

i'm not mark, but i'd like to speak on a related topic.

by design, queries that result in RFC 1918 addresses, and queries for RFC 1918 
PTR names, were to be intercepted by local resolvers.

let me know if you can't access DNS-OARC's DITL archives, which will show you 
how prominent both kinds those queries loom in actual root name service load.

i predict that foo.bar. will do likewise, whatever its design. 
this is the one saving grace in asking for a real root zone delegation: we can 
add an NS pointing to localhost, and try to get subsequent queries to go to 
heck rather than to the root servers.

vixie

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [Anima] prefix assignment

[Brian E Carpenter]

On 31/03/2017 03:50, Ted Lemon wrote:
> On Mar 30, 2017, at 9:45 AM, Michael Richardson  wrote:
>> It would hand out space via HNCP, and if it ran out of space, get more.
> 
> This can also be done with DHCP.

Indeed. I'm not trying to force the Anima approach, just pointing out that
it will be available in contexts where more than a simple PD operation might
be appropriate.

Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [Anima] prefix assignment

[Michael Richardson]

Pierre Pfister  wrote:
> Absolutely. RFC7695 Applicability Statement (Section 3.) explains that
> the algorithm can be used as
> long as participating nodes gets configured with an eventually
> consistent set of non-overlaping prefixes,
> which are then used to carve-out sub-prefixes that are assigned to
> link/nodes/objects/toasters.

I think that I can envision a situation where a largish distributed
enterprise could use auto-configuring Homenet technology in a "Small Office"
configuration, and would use a CASM/ANIMA mechanism at the edge to ask for
more address space from HQ.  (That could well be occuring via a VPN, or some
dark fiber, doesn't matter)

In that case, the HNCP and ANIMA parts would be in a common trust environment.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment

[Ted Lemon]

On Mar 30, 2017, at 9:45 AM, Michael Richardson  wrote:
> It would hand out space via HNCP, and if it ran out of space, get more.

This can also be done with DHCP.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] prefix assignment

[Michael Richardson]

Juliusz Chroboczek  wrote:
>>> Could you please clarify what you mean by "negotiate"?  Current HNCP
>>> implementations are provided with a bunch of External Prefixes, which 
they
>>> then carve into /64, one per prefix.  Are you envisioning a scenario 
where
>>> the HNCP implementation actually performs active negotiation on its
>>> external interfaces?

>> Yes, that's what Brian is suggesting.
>> The HNCP daemon would speak GRASP ASA on the "northbound" interface.

> Sorry if I wasn't clear.  Would it merely request address space and handle
> it out using HNCP, or would it actively renegotiate address space in
> response to HNCP events?

> If the latter -- why?

It would hand out space via HNCP, and if it ran out of space, get more.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet