Re: [homenet] Benjamin Kaduk's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)

[Benjamin Kaduk]

On Wed, Jul 18, 2018 at 04:30:17PM +0200, Juliusz Chroboczek wrote:
> >REQ5: a Homenet implementation of Babel MUST use metrics that are of
> >a similar magnitude to the values suggested in Appendix A of
> >RFC 6126bis.
> 
> > "MUST" and "similar magnitude" are not a great pairing.
> 
> Fixed.  This is now "must", the exact values are still SHOULD.
> 
> > I agree with the secdir reviewer that the link classification is
> > important, and would suggest a that SHOULD become MUST for "if it is
> > unable to determine whether a link is wired or wireless, it MUST
> > make the worst-case hypothesis".
> 
> I most humbly disagree.  Babel is sufficiently robust to survive
> misassignment, the consequence will be sub-optimal routing, and only if
> mis-assignment happens on both ends of a wireless link, and only in
> non-trivial topologies.
> 
> I think the consequences are sufficiently benign for us to afford leaving
> some latitude to implementers.
> 
> > Section 4
> 
> > I always worry a little bit about the ability to classify links as
> > "trusted", but there are probably cases where it's valid to do so.
> 
> I agree that HNCP edge detection is not satisfactory, but that's the best
> we've got right now, and it's time we moved forward.  Hopefully the
> security work will progress so that we can make crypto the default at some
> point, thus making this issue moot, but I request that this document
> should not be held up waiting for the security work to complete.

Well, this is a non-blocking comment, so I do not intend to hold up the
document for it.

> > I do wonder whether it's worth enumerating the "upper-layer security
> > protocol"s that HNCP and Babel support, as there are tradeoffs among
> > the PSK/PKI/TOFU options that the implementor may need to consider.
> 
> Since this document is intended for standards track, I worry that an
> enumeration will be taken as exhaustive, and limit the choices of the WG.

An understandable concern; thanks for clarifying.  (Again, this was
non-blocking, so I defer to your judgment.)

-Benjamin

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Juliusz Chroboczek]

> One way to automate this would be using mud.

A bright light shines from the heavens, bathing you in its warm glow.  An
enormous, white temple stands to the north, taking most of your view.

In order to enter the Temple of Homenet Naming, you must travel up the
large staircase that stands in front of you.

Exits: North, West, East, South.

(Perhaps you had something else in mind when you said MUD?)

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Jacques Latour]

The provisioning process for front end naming delegation we’re thinking of 
includes the provisioning of the domain name itself at the registry, and the 
setup on the home gateway itself and registration with an external secondary 
anycast for global name resolution. The gateway would have an internal and 
external view, where the external view would sync with the outsourced DNS 
service, could be using standard IXFR/AXFR methods.  We would sign both 
internal/external views with DNSSEC and publish a CDS that the registry can 
take to bootstrap the delegation. We need to add a Dyn like process to sync 
external dynamic addresses to the external zone file.

We’re not planning to use home.arpa because it will not have a secure chain of 
trust and if we have a domain name for external reachability (example.ca) then 
might as well use it internally.

As a side note, I don’t think we should even think of building a solution to 
make home.arpa a secure delegation, it’s a good domain name for internal use 
and avoid name collisions, not good for DNSSEC.

From: homenet  On Behalf Of Ted Lemon
Sent: Thursday, July 19, 2018 9:31 AM
To: Stephen Farrell 
Cc: Homenet ; Daniel Migault ; 
Juliusz Chroboczek 
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

One way to automate this would be using mud.

On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>> wrote:

(with no hats...)

On 19/07/18 10:42, Juliusz Chroboczek wrote:

>> Also, think of the privacy implications if all of the services on the
>> homenet had to be discovered from a shared zone like 
>> dyndns.org.

> Quite the opposite.  In the trivial update protocol, the update is
> end-to-end, encrypted, and only the host and the DNS provider see the
> data.  Every Homenet, every host, heck, even every application can use
> a different DNS provider, and each DNS provider only sees the data that
> was explicitly sent to it.

I'm also a bit puzzled by how the subset of records to be
globally published relates to the set of records that are
to be internally visible. I guess this is not something
that we'd fully standardise, but there are privacy issues
here if too much gets published globally, so there may be
some protocol (change/tweak) required to make it possible
for implementers to distinguish which information ought be
globally visible, and which not.

Cheers,
S.

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Juliusz Chroboczek]

> On the other hand same thing using nsupdate (using TSIG and dynamic
> dns) is one command line + input file for nsupdate:

Cool.

Whichever end-to-end (host to DNS provider with no intermediate proxying)
encrypted and authentified protocol you pick, I'm with you.

-- Juliusz

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Tero Kivinen]

Juliusz Chroboczek writes:
> And it's literally four lines of shell:
> 
> while true; do
> wget --post-data 'name=gameserver.myhome.net=topsecret' \
>  https://dyndns.example.com
> sleep $((24 * 3600))
> done

How does that get both IPv4 and IPv6 addresses published? Perhaps bit
more parameters are needed?

The reason people use those dyndns services is because they only use
IPv4, and they have NATs, and they want to publish the outer address
of the NAT. I would hope we are getting proper non-natted IPv6
networks with globally routable address at home too, so you do not
need to use such hacks.

On the other hand same thing using nsupdate (using TSIG and dynamic
dns) is one command line + input file for nsupdate:
--
nsupdate -k $KEYFILE << EOF
server ns.example.com.
zone myhome.net.
update add gameserver.myhome.net. 3600 A $IP4
update add gameserver.myhhome.net. 3600  $IP6
send
EOF
--
No need to sleep and do operations periodically, you only need to run
this when the IP-addresses change...
-- 
kivi...@iki.fi

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Juliusz Chroboczek]

>> And it's literally four lines of shell:

> vs

> while true; do
> (omitted for brevity)

You're doing end-to-end dynamic update over DNS, which is fine with me.
The exact transport we end up using doesn't matter that much.

You're not doing the proxying through a hidden master mandated by Daniel's
draft, which is what I find complex and fragile.

-- Juliusz

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Mark Andrews]

> On 19 Jul 2018, at 11:58 pm, Mark Andrews  wrote:
> 
> 
> 
>> On 19 Jul 2018, at 11:30 pm, Juliusz Chroboczek  wrote:
>> 
>>>   I am not speaking about discovery within the Homenet. I am speaking about
>>>   exporting names into the global DNS, which is what Daniel's draft is
>>>   about.
>> 
>>> Yes, but the problem is that you are treating this as if these are two
>>> separate problems, but they are not.
>> 
>> These are two completely different problems, with different default
>> behaviours and different failure modes.
>> 
>> The default behaviour for the local zone is that devices should be
>> discoverable.  The default behaviour for the public DNS is that a device
>> should not be published unless it takes explicit action.
>> 
>> It makes a lot of sense to have two different protocols, rather than
>> essentially leaking a local zone into the ISP's DNS servers.
>> 
>>>   I'm not following your reasoning here -- why does the zone being tied to
>>>   the ISP imply that we must use a more complex protocol?
>> 
>>> Doing this transaction over HTTP means another service that the ISP has
>>> to operate,
>> 
>> Not the ISP, a third-party DNS provider.  That's the whole point.
>> 
>>> and another service that the HNR has to connect to.
>> 
>> Not the HNR, the end host.  That's the whole point.
>> 
>> And it's literally four lines of shell:
>> 
>>   while true; do
>>   wget --post-data 'name=gameserver.myhome.net=topsecret' \
>>https://dyndns.example.com
>>   sleep $((24 * 3600))
>>   done
> 
> vs
> 
> while true; do
>   (
>   # delete all the existing  records
>   update delete host.example.com IN 
>   # add in all the GUA  records
>   ifconfig -a inet6 |
>   sed -n -e '/%/d' -e '/ ::1 /d' -e '/ 
> fd[0-9a-f][[0-9a-f]:/d’ \
>   -e 's/inet6/update add host.example.com 3600 IN /‘ \
>   -e 's/ prefixlen.*//p’
>   # tell nsupdate to send the update request.  Nsupdate will work 
> out zone and
>   # DNS servers to send the update request too.
>   echo send
>   ) | nsupdate -y Khost.example.net.+001+56524
>   sleep $((24 * 3600))
> done

And I forgot to mention that this supports multiple  records.

> 
>>>   Quite the opposite. In the trivial update protocol, the update is
>>>   end-to-end, encrypted, and only the host and the DNS provider see the
>>>   data.
>> 
>>> You've published a record in a public zone. It doesn't matter that the
>>> protocol you used to publish it is privacy-protecting, because the
>>> publication of the name immediately negated that.
>> 
>> With delegation through an ISP-controlled hidden master, the ISP gets
>> a database of all the names published by all of its users.
>> 
>> With an encrypted connection to a DNS provider, the ISP needs to troll all
>> of the DNS providers in order to build such a database.
>> 
>>> I actually share your concern that what he's got written down right now
>>> is more complicated than it needs to be, and this is partly because it
>>> was originally motivated by his work at an ISP.
>> 
>> Uh-huh.
>> 
>> -- Juliusz
>> 
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Mark Andrews]

> On 19 Jul 2018, at 11:30 pm, Juliusz Chroboczek  wrote:
> 
>>I am not speaking about discovery within the Homenet. I am speaking about
>>exporting names into the global DNS, which is what Daniel's draft is
>>about.
> 
>> Yes, but the problem is that you are treating this as if these are two
>> separate problems, but they are not.
> 
> These are two completely different problems, with different default
> behaviours and different failure modes.
> 
> The default behaviour for the local zone is that devices should be
> discoverable.  The default behaviour for the public DNS is that a device
> should not be published unless it takes explicit action.
> 
> It makes a lot of sense to have two different protocols, rather than
> essentially leaking a local zone into the ISP's DNS servers.
> 
>>I'm not following your reasoning here -- why does the zone being tied to
>>the ISP imply that we must use a more complex protocol?
> 
>> Doing this transaction over HTTP means another service that the ISP has
>> to operate,
> 
> Not the ISP, a third-party DNS provider.  That's the whole point.
> 
>> and another service that the HNR has to connect to.
> 
> Not the HNR, the end host.  That's the whole point.
> 
> And it's literally four lines of shell:
> 
>while true; do
>wget --post-data 'name=gameserver.myhome.net=topsecret' \
> https://dyndns.example.com
>sleep $((24 * 3600))
>done

vs

while true; do
(
# delete all the existing  records
update delete host.example.com IN 
# add in all the GUA  records
ifconfig -a inet6 |
sed -n -e '/%/d' -e '/ ::1 /d' -e '/ 
fd[0-9a-f][[0-9a-f]:/d’ \
-e 's/inet6/update add host.example.com 3600 IN /‘ \
-e 's/ prefixlen.*//p’
# tell nsupdate to send the update request.  Nsupdate will work 
out zone and
# DNS servers to send the update request too.
echo send
) | nsupdate -y Khost.example.net.+001+56524
sleep $((24 * 3600))
done

>>Quite the opposite. In the trivial update protocol, the update is
>>end-to-end, encrypted, and only the host and the DNS provider see the
>>data.
> 
>> You've published a record in a public zone. It doesn't matter that the
>> protocol you used to publish it is privacy-protecting, because the
>> publication of the name immediately negated that.
> 
> With delegation through an ISP-controlled hidden master, the ISP gets
> a database of all the names published by all of its users.
> 
> With an encrypted connection to a DNS provider, the ISP needs to troll all
> of the DNS providers in order to build such a database.
> 
>> I actually share your concern that what he's got written down right now
>> is more complicated than it needs to be, and this is partly because it
>> was originally motivated by his work at an ISP.
> 
> Uh-huh.
> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Ted Lemon]

One way to automate this would be using mud.

On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell 
wrote:

>
> (with no hats...)
>
> On 19/07/18 10:42, Juliusz Chroboczek wrote:
>
> >> Also, think of the privacy implications if all of the services on the
> >> homenet had to be discovered from a shared zone like dyndns.org.
>
> > Quite the opposite.  In the trivial update protocol, the update is
> > end-to-end, encrypted, and only the host and the DNS provider see the
> > data.  Every Homenet, every host, heck, even every application can use
> > a different DNS provider, and each DNS provider only sees the data that
> > was explicitly sent to it.
>
> I'm also a bit puzzled by how the subset of records to be
> globally published relates to the set of records that are
> to be internally visible. I guess this is not something
> that we'd fully standardise, but there are privacy issues
> here if too much gets published globally, so there may be
> some protocol (change/tweak) required to make it possible
> for implementers to distinguish which information ought be
> globally visible, and which not.
>
> Cheers,
> S.
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Juliusz Chroboczek]

> I am not speaking about discovery within the Homenet. I am speaking about
> exporting names into the global DNS, which is what Daniel's draft is
> about.

> Yes, but the problem is that you are treating this as if these are two
> separate problems, but they are not.

These are two completely different problems, with different default
behaviours and different failure modes.

The default behaviour for the local zone is that devices should be
discoverable.  The default behaviour for the public DNS is that a device
should not be published unless it takes explicit action.

It makes a lot of sense to have two different protocols, rather than
essentially leaking a local zone into the ISP's DNS servers.

> I'm not following your reasoning here -- why does the zone being tied to
> the ISP imply that we must use a more complex protocol?

> Doing this transaction over HTTP means another service that the ISP has
> to operate,

Not the ISP, a third-party DNS provider.  That's the whole point.

> and another service that the HNR has to connect to.

Not the HNR, the end host.  That's the whole point.

And it's literally four lines of shell:

while true; do
wget --post-data 'name=gameserver.myhome.net=topsecret' \
 https://dyndns.example.com
sleep $((24 * 3600))
done

> Quite the opposite. In the trivial update protocol, the update is
> end-to-end, encrypted, and only the host and the DNS provider see the
> data.

> You've published a record in a public zone. It doesn't matter that the
> protocol you used to publish it is privacy-protecting, because the
> publication of the name immediately negated that.

With delegation through an ISP-controlled hidden master, the ISP gets
a database of all the names published by all of its users.

With an encrypted connection to a DNS provider, the ISP needs to troll all
of the DNS providers in order to build such a database.

> I actually share your concern that what he's got written down right now
> is more complicated than it needs to be, and this is partly because it
> was originally motivated by his work at an ISP.

Uh-huh.

-- Juliusz

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Stephen Farrell]

(with no hats...)

On 19/07/18 10:42, Juliusz Chroboczek wrote:

>> Also, think of the privacy implications if all of the services on the
>> homenet had to be discovered from a shared zone like dyndns.org.

> Quite the opposite.  In the trivial update protocol, the update is
> end-to-end, encrypted, and only the host and the DNS provider see the
> data.  Every Homenet, every host, heck, even every application can use
> a different DNS provider, and each DNS provider only sees the data that
> was explicitly sent to it.

I'm also a bit puzzled by how the subset of records to be
globally published relates to the set of records that are
to be internally visible. I guess this is not something
that we'd fully standardise, but there are privacy issues
here if too much gets published globally, so there may be
some protocol (change/tweak) required to make it possible
for implementers to distinguish which information ought be
globally visible, and which not.

Cheers,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Ted Lemon]

On Thu, Jul 19, 2018 at 5:42 AM, Juliusz Chroboczek  wrote:

> > In order for services to be discoverable on the homenet, they have to
> > publish their contact info on the homenet. The protocol that everyone
> > uses for this is DNSSD. This is how you find your printer when you want
> > to print to it. Nobody uses the ad-hoc DynDNS protocol for this.
>
> I am not speaking about discovery within the Homenet.  I am speaking about
> exporting names into the global DNS, which is what Daniel's draft is about.
>

Yes, but the problem is that you are treating this as if these are two
separate problems, but they are not.   If we need devices to know how to do
one thing, that's enough.   We shouldn't demand that they know how to do
two things that accomplish the same thing.   So if we need service
registration, we shouldn't also have a second method of publishing names,
because that's additional work for the device manufacturer.


> > The reverse mapping zone has to be delegated by the ISP, so we might as
> > well do it in a prefix delegation transaction.
>
> I'm not following your reasoning here -- why does the zone being tied to
> the ISP imply that we must use a more complex protocol?
>

Again, we are already doing DHCP PD to get the prefix from the ISP.   The
transaction is already happening.   Sending our ZSK to the root along with
the IP address of our public or hidden primary for the reverse zone isn't a
lot of additional work.   Doing this transaction over HTTP means another
service that the ISP has to operate, and another service that the HNR has
to connect to.   So it's not a simplication—it's a complexification, even
though the protocol itself is simple.


> > Also, think of the privacy implications if all of the services on the
> > homenet had to be discovered from a shared zone like dyndns.org.
>
> Quite the opposite.  In the trivial update protocol, the update is
> end-to-end, encrypted, and only the host and the DNS provider see the
> data.  Every Homenet, every host, heck, even every application can use
> a different DNS provider, and each DNS provider only sees the data that
> was explicitly sent to it.
>

You've published a record in a public zone.   It doesn't matter that the
protocol you used to publish it is  privacy-protecting, because the
publication of the name immediately negated that.

In Daniel's protocol, the data goes from host to hidden primary to DNS
> provider.  The hidden primary is probably controlled by the ISP, which is
> convenient if you happen to be a privacy-violating ISP.


The hidden primary would be on an HNR, so unless the HNR is controlled by
the ISP, the hidden primary isn't either.   In principle, at least, the
hidden primary should only be exposing names to the ISP that are intended
to be exposed.

The reason I was hassling  Daniel about implementations at the mic is that
I actually share your concern that what he's got written down right now is
more complicated than it needs to be, and this is partly because it was
originally motivated by his work at an ISP.   Now that he isn't doing that,
we have an opportunity to do a rethink about what is good and bad about the
proposal, and I think we should take advantage of this opportunity.

That said, DNS delegation and IXFR are well-understood technologies that
are well-suited to the purpose we have here, so I think we should be
careful when trying to simplify this to make sure that what is being
proposed actually has that effect!
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] In-network connectivity and HNCP: IPv6 ULA

[Juliusz Chroboczek]

> I think the local ULA should be used for all intra-ULA connections. We had a
> debate about this about four years ago, and apparently the text in the HNCP
> spec reflects the outcome of that discussion, but I think we understand the
> problem better now and we should fix this.

Agreed.

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

Re: [homenet] In-network connectivity and HNCP: IPv6 ULA

[Juliusz Chroboczek]

I've re-read Section 6.5 of 7788, and it looks like I was wrong.  Sorry,
I should not be writing technical mails in the middle of the night.

As far as I can tell from the wording of 6.5:

  - creating ULA is SHOULD if there's no global IPv6, MUST NOT otherwise;
  - creating private IPv4 is MAY if there's no global IPv4, MUST NOT otherwise.

If my reading is correct, that sucks.  I don't see how the MAY can be
implemented, since there's no obvious way to distinguish global from local
IPv4, and if you don't implement the MAY, then you'll lose local IPv4
whenever your IPv4 provider has a glitch, as you described.

> if you have a connection over IPv4 and suddenly your IPv4 network is
> deconfigured, your connection will hang.

The point Brian and I are trying to make is that you should have no
intra-Homenet IPv4 traffic -- your applications should prefer IPv6 to
IPv4, and and there should always be IPv6 in your Homenet.

Unfortunately, our point is made moot by the first MUST NOT above, since
the ULA becomes deprecated whenever there's global IPv6.

-- Juliusz

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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Juliusz Chroboczek]

> In order for services to be discoverable on the homenet, they have to
> publish their contact info on the homenet. The protocol that everyone
> uses for this is DNSSD. This is how you find your printer when you want
> to print to it. Nobody uses the ad-hoc DynDNS protocol for this.

I am not speaking about discovery within the Homenet.  I am speaking about
exporting names into the global DNS, which is what Daniel's draft is about.

> It's certainly true that we could use an HTTPS-based protocol for setting up
> delegations for the forward mapping zone. This makes a great deal of sense,

Good.

> The reverse mapping zone has to be delegated by the ISP, so we might as
> well do it in a prefix delegation transaction.

I'm not following your reasoning here -- why does the zone being tied to
the ISP imply that we must use a more complex protocol?

> So if you are advocating this second thing, that makes sense, and we should
> definitely talk about whether it makes sense to do it this way.

Let's.

> Also, think of the privacy implications if all of the services on the
> homenet had to be discovered from a shared zone like dyndns.org.

Quite the opposite.  In the trivial update protocol, the update is
end-to-end, encrypted, and only the host and the DNS provider see the
data.  Every Homenet, every host, heck, even every application can use
a different DNS provider, and each DNS provider only sees the data that
was explicitly sent to it.

In Daniel's protocol, the data goes from host to hidden primary to DNS
provider.  The hidden primary is probably controlled by the ISP, which is
convenient if you happen to be a privacy-violating ISP.

-- Juliusz

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