Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Juliusz Chroboczek]

>> If the fast connection's DNS server replies after a delay or not at all,
>> and the slow connection's DNS server replies in a timely manner, using
>> a smart resolver across all the available DNS servers will improve latenc

> Yes, but if your fast connection is lossy, it's not fast. Lossy looks like
> congestion, so TCP slows down.

I never said the fast connection was lossy.  The scenario I'm envisioning
is one in which the DNS server behind the fast link is laggy.

Ted, DNS latency is a significant part of what the web people call "time
to first byte".  DNS resolvers make serious efforts to minimise that
latency by keeping RTT and loss statistics and picking the best resolver.
I don't know if you agree, but I suspect that any protocol that causes web
latency to increase is not going to get deployed easily.

-- Juliusz

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

Re: [homenet] [secdir] Secdir last call review of draft-ietf-homenet-dot-12

[Daniel Migault]

Hi, 

I used the web form and expected that the boilerplate would automatically be 
added. This explains why the introduction may look a bit directive or dry. To 
clarify the scope of my reviews, I am adding the boilerplate below.

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Yours, 
Daniel
-Original Message-
From: secdir [mailto:secdir-boun...@ietf.org] On Behalf Of Daniel Migault
Sent: Friday, August 18, 2017 12:44 PM
To: sec...@ietf.org
Cc: draft-ietf-homenet-dot@ietf.org; homenet@ietf.org; i...@ietf.org
Subject: [secdir] Secdir last call review of draft-ietf-homenet-dot-12

Reviewer: Daniel Migault
Review result: Has Nits

Thank you for writing the draft. Please find my comments. I hope they are 
helpful. 

Yours,
Daniel  

Special Use Domain 'home.arpa.'
   draft-ietf-homenet-dot-12

Abstract

   This document specifies the behavior that is expected from the Domain
   Name System with regard to DNS queries for names ending with
   '.home.arpa.', and designates this domain as a special-use domain
   name. 'home.arpa.' is designated for non-unique use in residential
   home networks.  Home Networking Control Protocol (HNCP) is updated to
   use the 'home.arpa.' domain instead of '.home'.

%%%  
MGLT: I would personally start by saying the document defines a  special-use 
domain name and then defines the behavior. 
%%%  


   
Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on February 11, 2018.

Copyright Notice

   Copyright (c) 2017 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Pfister & Lemon Expires February 11, 2018   [Page 1]


Internet-Draft dot homenet   August 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  General Guidance  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Domain Name Reservation Considerations  . . . . . . . . . . .   3
   5.  Updates to Home Networking Control Protocol . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Delegation of 'home.arpa.'  . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
 10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
 10.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Users and devices within a home network (hereafter "homenet") require
   devices and services to be identified by names that are unique within
   the boundaries of the homenet [RFC7368].  The naming mechanism needs
   to function without configuration from the user.  While it may be
   possible for a name to be delegated by an ISP, homenets must also
   function in the absence of such a delegation.  A default name with a
   scope limited to each individual homenet needs to be used.

   This document corrects an error in [RFC7788], replacing '.home' with
   'home.arpa.' as the default domain-name 

Re: [homenet] homenet "no host changes" assumption and DNS

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> I think that what you are proposing here is great, except that I don't
> think we actually _need_ to go out of charter on this.   I think that
> what Toke has been advocating can be worked into the framework you are
> describing, so that you and I! get what we want, and Toke gets what he
> wants.

Yeah, I think so too. I.e., we can create a framework that will work for
existing hosts and still provide the information for more capable hosts
to do their thing.

Whether these more capable hosts will actually end up performing better
is another matter; but I guess we'll see about that... ;)

-Toke

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

Re: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA

[Michael Richardson]

STARK, BARBARA H  wrote:
>> This suggests to me that the next step in HOMENET, which I think the 
naming
>> architecture could lead, is to provide for (automatic) collection of 
statistics for
>> diagnostics purposes.
>> i.e. Homenet OAM.

> Not as chair...

> I disagree this has anything to do with the naming architecture.

The reason I suggest that the naming architecture could lead this, is because
due to the multi-provider nature, we get specifically interesting statistics
From end-systems about how well they are communicating with their intended
targets.  Further, in order to deal with this kind of thing, there are host
changes desired, so doing OAM on those changes seems like not too much a 
stretch.

For instance, how many times did they pick a src/dst combination for a DNS
query, or a data transmission, for which there was a communication failure?

> I have long felt the best way to accomplish this would be to have a
> discoverable (DNS-SD) NetJSON (http://netjson.org/) "service" on all
> consumer routers, which would supply NetJSON types via http.

> I agree supplying statistics info to the home network would be a good
> thing for homenet to tackle.
> I've been wanting to propose this for a while, but keep getting 
side-tracked.

You have described a mechanism to collect the statistics, and it seems like a
very good suggestion.


--
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] homenet "no host changes" assumption and DNS

[Andrew Sullivan]

Hi,

On Fri, Aug 18, 2017 at 01:21:06PM +, STARK, BARBARA H wrote:

> Currently, there is no host that expects to use .home.arpa (or any other 
> domain) inside the premises.

I don't think the "or any other domain" claim is true.  At the very
least, _lots_ of hosts are already using local. in homenets -- indeed,
that's how we got to this pass.

> There is no host that expects a general-purpose in-home domain name system to 
> work or be present.

That's because there is no host that "expects an in-home domain name
system" at all.  I think your position is starting from a position
with which I disagree pretty strongly.  In my view, what we did many
years ago was hook up individual machines to an ISP's network.  When
broadband home access came along, we continued to pretend that the
link in the CPE was just a node in an ISP's network, and pretended
that the home network was not a first-class network that was
internetworked together with other networks to make the Internet.  We
ended up with multiple classes of network, some of which are only
kinda part of the Internet.

The reason that homenet is being worked on in the IETF as opposed to,
say, the Broadband Forum, is exactly that we are trying to provide
internetworking services for these surprisingly sophisticated,
unmanaged networks.  So to say that there's no "general-purpose
in-home domain name system" misses the point: it's _the_ domain name
system, and the homenet is part of that global DNS just as surely as
com. is, and participates in the global name space just as surely as
onion. and local. do.

So, the reason we can't expect host changes for naming is because any
plan for internetworking that starts, "First, upgrade all the hosts,"
is doomed.  That hasn't worked since 1983.

> If we got rid of the "no changes to host" tenet (for hosts that can make use 
> of the home naming architecture), that would give us much more freedom to 
> create an in-home DNS architecture without a dependency on homenet routers 
> implementing the DNS Proxy kludge. Or any other kludge. It would let us 
> create an architecture that would finally start to move us away from DNS 
> Proxy and other methods that intercept DNS queries to make supposedly 
> "intelligent" decisions on behalf of stupid hosts. And we would not be 
> further entrenching use of these DNS intercept functions.
> 

I don't understand how you can claim the above: the plain fact of the
matter is that we have multiple domain-name-using protocols in action
here: at the very least, mDNS, DNS, and LLMNR, and maybe Tor
resolution and some other stuff.  If what you're saying instead is
that hosts are supposed to know which networking context they're
living in, then perhaps we need a radical rethinking of what we're
working on.  It _might_ be the case that end to end is the wrong model
given the kinds of things we turn out to be attaching to the Internet
(this was part of what got discussed in the IAB's technical plenary
last November).  But if that's what we're doing, I think this WG needs
at the very least to go through a round of rechartering so that the
rest of the IETF understands that we are proposing a really
significant break with the nominal Internet architecture.  I'm not
convinced that the WG has the patience to do such an effort, BTW.  But
I think this is a pretty fundamental change you're proposing, and I
think it would not be wrong for the IETF to push back pretty hard
against such a change should the WG come out with documents that embed
such an assumption.

> I would like to require the hosts that want to make use of the new homenet 
> naming architecture responsible for understanding the different provisioning 
> domains and simultaneously launching queries to the advertised (or internally 
> configured) DNS servers for each provisioning domain. 
> 

DNS doesn't work that way, is the problem.  It doesn't have a mode
bit.  What you are proposing is homenet-DNS; it's a new protocol.
Maybe that's the right answer, but I'm far from convinced that this is
the place to create DNSbis.

Best regards,

A
-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Ted Lemon]

El 18 ag 2017, a les 5:40, Juliusz Chroboczek  va escriure:
> If the fast connection's DNS server replies after a delay or not at all,
> and the slow connection's DNS server replies in a timely manner, using
> a smart resolver across all the available DNS servers will improve latenc

Yes, but if your fast connection is lossy, it's not fast.   Lossy looks like 
congestion, so TCP slows down.   There's nothing we can do in the resolver to 
fix this.   You want less complexity, but to successfully determine which link 
is the right one to use at the network level is a very hard problem, much 
harder than anything we are talking about here.   It might be an interesting 
research topic, but it doesn't make sense for you to raise it as an argument in 
favor of one or another options for configuring resolvers.

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

Re: [homenet] homenet "no host changes" assumption and DNS

[Ted Lemon]

I think that what you are proposing here is great, except that I don't think we 
actually _need_ to go out of charter on this.   I think that what Toke has been 
advocating can be worked into the framework you are describing, so that you and 
I! get what we want, and Toke gets what he wants.

> El 18 ag 2017, a les 9:21, STARK, BARBARA H  va escriure:
> 
> No hat.
> I'm proposing something radical here. Let the tomatoes fly.
> I'd like to question whether we really need to maintain the "no changes to 
> the host" assumption when it comes to architecting homenet DNS.
> Currently, there is no host that expects to use .home.arpa (or any other 
> domain) inside the premises. There is no host that expects a general-purpose 
> in-home domain name system to work or be present. The widest use of in-home 
> domains is the way ISPs use domains like ".home". To the best of my 
> knowledge, they use those for access to the ISP-supplied router's HTTP-served 
> content. Nothing else. The "no host changes" tenet was primarily about not 
> breaking existing host functionality. A fully functional in-home domain name 
> system is not something any legacy host has expectations or functionality 
> for. As long as we don't break usage of Internet DNS, there should not be any 
> requirement or mandate that we have to make in-home DNS work for legacy hosts.
> 
> If we got rid of the "no changes to host" tenet (for hosts that can make use 
> of the home naming architecture), that would give us much more freedom to 
> create an in-home DNS architecture without a dependency on homenet routers 
> implementing the DNS Proxy kludge. Or any other kludge. It would let us 
> create an architecture that would finally start to move us away from DNS 
> Proxy and other methods that intercept DNS queries to make supposedly 
> "intelligent" decisions on behalf of stupid hosts. And we would not be 
> further entrenching use of these DNS intercept functions.
> 
> I would like to require the hosts that want to make use of the new homenet 
> naming architecture responsible for understanding the different provisioning 
> domains and simultaneously launching queries to the advertised (or internally 
> configured) DNS servers for each provisioning domain. 
> 
> The host that gets multiple DNS responses needs to be responsible for making 
> the decision that's right for it. In the case of multiple Internet 
> connections: if the application needs high bandwidth and low loss but latency 
> isn't important (e.g., streaming video), then maybe it picks the high 
> bandwidth high latency low loss connection. If it needs low latency but not 
> much bandwidth (e.g., VoIP), then maybe it picks the low bandwidth low 
> latency connection. The CE router should not be making this decision (which 
> DNS response to supply to the host) on behalf of apps it knows nothing about.
> 
> Make the home domain a different provisioning domain, and insist that hosts 
> wanting to make use of domain names in the home domain must understand 
> provisioning domains and how to use and interact with them. The home domain 
> DNS server can be advertised by mDNS or other means.
> 
> I truly believe we need to start moving towards providing hosts with the info 
> they need to make their own decisions. DNS Proxy mandates (or other DNS 
> intercept mechanisms) are antithetical to this. 
> Barbara
> 
> 
> 
> ___
> 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

[homenet] homenet "no host changes" assumption and DNS

[STARK, BARBARA H]

No hat.
I'm proposing something radical here. Let the tomatoes fly.
I'd like to question whether we really need to maintain the "no changes to the 
host" assumption when it comes to architecting homenet DNS.
Currently, there is no host that expects to use .home.arpa (or any other 
domain) inside the premises. There is no host that expects a general-purpose 
in-home domain name system to work or be present. The widest use of in-home 
domains is the way ISPs use domains like ".home". To the best of my knowledge, 
they use those for access to the ISP-supplied router's HTTP-served content. 
Nothing else. The "no host changes" tenet was primarily about not breaking 
existing host functionality. A fully functional in-home domain name system is 
not something any legacy host has expectations or functionality for. As long as 
we don't break usage of Internet DNS, there should not be any requirement or 
mandate that we have to make in-home DNS work for legacy hosts.

If we got rid of the "no changes to host" tenet (for hosts that can make use of 
the home naming architecture), that would give us much more freedom to create 
an in-home DNS architecture without a dependency on homenet routers 
implementing the DNS Proxy kludge. Or any other kludge. It would let us create 
an architecture that would finally start to move us away from DNS Proxy and 
other methods that intercept DNS queries to make supposedly "intelligent" 
decisions on behalf of stupid hosts. And we would not be further entrenching 
use of these DNS intercept functions.

I would like to require the hosts that want to make use of the new homenet 
naming architecture responsible for understanding the different provisioning 
domains and simultaneously launching queries to the advertised (or internally 
configured) DNS servers for each provisioning domain. 

The host that gets multiple DNS responses needs to be responsible for making 
the decision that's right for it. In the case of multiple Internet connections: 
if the application needs high bandwidth and low loss but latency isn't 
important (e.g., streaming video), then maybe it picks the high bandwidth high 
latency low loss connection. If it needs low latency but not much bandwidth 
(e.g., VoIP), then maybe it picks the low bandwidth low latency connection. The 
CE router should not be making this decision (which DNS response to supply to 
the host) on behalf of apps it knows nothing about.

Make the home domain a different provisioning domain, and insist that hosts 
wanting to make use of domain names in the home domain must understand 
provisioning domains and how to use and interact with them. The home domain DNS 
server can be advertised by mDNS or other means.

I truly believe we need to start moving towards providing hosts with the info 
they need to make their own decisions. DNS Proxy mandates (or other DNS 
intercept mechanisms) are antithetical to this. 
Barbara



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

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Juliusz Chroboczek]

> I don't think anything we are talking about here would actually help
> with that.

If the fast connection's DNS server replies after a delay or not at all,
and the slow connection's DNS server replies in a timely manner, using
a smart resolver across all the available DNS servers will improve latency.

Both dnsmasq and (I believe) bind will do the smart thing.  (Which does
not consist in sending the request to all servers, contrary to what you
appear to believe.)

-- Juliusz

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