tf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
> Savolainen Teemu (Nokia-MS/Tampere)
> Sent: 19. tammikuuta 2011 11:12
> To: ted.le...@nominum.com
> Cc: dnsop@ietf.org; carls...@workingcode.com; k...@syce.net
> Subject: Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
Hi,
> Your assertions about the state of the art in DNS resolver
> implementations is probably correct. However, essentially what you
> are proposing is to take this broken behavior as a standard, and then
> build new functionality on it. The problem is that the behavior is
Well, if the only
On Jan 17, 2011, at 9:34 AM, Nicholas Weaver wrote:
> Why bother? IMO A better approach is NOT to try to patch DHCP/IPv6 Route
> Advertisements/ARP etc, but just ACCEPT these as insecure. [1]
Right, but people keep trying to treat them as if they conveyed some sort of
trustworthiness. Hence
On Jan 17, 2011, at 6:25 AM, Ted Lemon wrote:
> On Jan 17, 2011, at 9:22 AM, Andrew Sullivan wrote:
>> (RFC 4035, section 4.9.3). Presumably, then, the stub needs somehow
>> to have authenticated the DNS server in question otherwise before
>> accepting the claims about signature validation. I c
On Jan 17, 2011, at 9:22 AM, Andrew Sullivan wrote:
> (RFC 4035, section 4.9.3). Presumably, then, the stub needs somehow
> to have authenticated the DNS server in question otherwise before
> accepting the claims about signature validation. I can't think of any
> way to do this under DHCP, but ma
On Mon, Jan 17, 2011 at 08:54:05AM -0500, Ted Lemon wrote:
> Hm. Okay, so the reason this is an issue is that I'm assuming the
> resolver doesn't do its own validation. And you're right that if it
> doesn't do its own validation, it's not much worse off using this
> option than not using it; th
On Jan 17, 2011, at 5:29 AM, wrote:
> This option directs a host to ask question from some of the servers it could
> have anyway send its question to. How DNSSEC cannot manage to secure DNS
> queries in that case?
Your assertions about the state of the art in DNS resolver implementations is
pr
On Mon, Jan 17, 2011 at 10:29:45AM +, teemu.savolai...@nokia.com wrote:
> That particular case I have been told is protected against by using DNSSEC,
> which ensures the host will detect the fraudulent answer to this directed
> attack and will fall back to use other DNS server (or fail)...
>
> A rogue DHCPv6 server can add entries to that file, but can't delete
> them. Thus, it's possible for a bad DHCPv6 server to make life
> annoying for a client, but (at least for DNS) it can't prevent the client from
> eventually working.
The rogue DHCPv6 server can insert its DNS server as the p
the interface this attacker has control over.
Teemu
> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf
> Of ext Andrew Sullivan
> Sent: 14. tammikuuta 2011 18:01
> To: dnsop@ietf.org
> Subject: Re: [DNSOP] draft-savolainen-mif-dn
ubject: Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
>
> On Jan 14, 2011, at 10:53 AM, wrote:
> > If I now have e.g. multihomed Linux, often or usually the
> /etc/resolv.conf points to the DNS server address learned most recently
> via some mean (RA, DHCPv6). Bu
On Fri, Jan 14, 2011 at 04:01:35PM +, teemu.savolai...@nokia.com wrote:
>
> E.g. by definition. Implement this only if you are a CPE or if you
> are 3GPP handset and then only for this class of interface. Or
> such. Those two scenarios are my main focus. Not believe what
> CoffeeShopFreeAP tel
teemu.savolai...@nokia.com wrote:
> I have to admit one thing I have not really understood is why the level of
> concern here is so deep.
>
> If I now have e.g. multihomed Linux, often or usually the /etc/resolv.conf
> points to the DNS server address learned most recently via some mean (RA,
>
> > You can ignore the option and talk to the DNS server of your
> preference. You can also choose to listen for the option only from one
> or more trusted sources.
> >
>
> I'm really unclear about this "trusted sources" thing, though. Is
> that "trust only if you're on a trusted network"? Becau
On Fri, Jan 14, 2011 at 03:53:25PM +, teemu.savolai...@nokia.com wrote:
>
> Shouldn't we work e.g. on securing all DHCPv6 signaling?
I would say so, yes.
But note that this particular option makes it easier to target one
domain in particular. That's a more directed attack, so it seems to
me
On Jan 14, 2011, at 10:53 AM, wrote:
> If I now have e.g. multihomed Linux, often or usually the /etc/resolv.conf
> points to the DNS server address learned most recently via some mean (RA,
> DHCPv6). But people are not too worried what is the content of that file?
> I.e. attacker could just se
ilto:ted.le...@nominum.com]
> Sent: 14. tammikuuta 2011 17:13
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: carls...@workingcode.com; dnsop@ietf.org; k...@syce.net
> Subject: Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
>
> On Jan 14, 2011, at 9:58 AM, wrote:
> > Lac
On Fri, Jan 14, 2011 at 03:09:21PM +, teemu.savolai...@nokia.com wrote:
>
> You can ignore the option and talk to the DNS server of your preference. You
> can also choose to listen for the option only from one or more trusted
> sources.
>
I'm really unclear about this "trusted sources" thi
On Jan 14, 2011, at 9:58 AM, wrote:
> Lack of trust on information contained in all options?
Right. Generally, we assume that the higher-level protocol will have some
sort of security mechanism--e.g., DNSSEC. Or we assume that the environment
in which DHCP is being done is one in which ther
> To put it another way, if I hear through this new mechanism that some
> DNS server will handle requests for "example.com.", that does *NOT*
> imply in any way that I want bare names to be resolved by that server
> preferentially. Perhaps I do -- but perhaps I don't. That's what the
> search lis
t
> Subject: Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
>
> On Jan 14, 2011, at 9:28 AM,
> wrote:
> > This is a generic feature of DHCPv6, right?
>
> What is?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Jan 14, 2011, at 9:28 AM,
wrote:
> This is a generic feature of DHCPv6, right?
What is?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
>
> On Jan 14, 2011, at 9:00 AM, James Carlson wrote:
> > Or should the resolver somehow "know" whether the DHCPv6 information
> is
> > "secure," for whatever "secure" means? And how would it
On Jan 14, 2011, at 9:00 AM, James Carlson wrote:
> Or should the resolver somehow "know" whether the DHCPv6 information is
> "secure," for whatever "secure" means? And how would it know that the
> information is as valid as the DNSSEC information?
This is, of course, the key problem. The resol
On 01/14/11 07:06, teemu.savolai...@nokia.com wrote:
>> The two seem quite distinct to me. The existing search list option
>> provides a global setting for the client, and is intended to affect how
>> unqualified (or partially-qualified) names are resolved.
>
> Right, but the same information c
Hi,
> -Original Message-
> From: ext James Carlson [mailto:carls...@workingcode.com]
> Sent: 13. tammikuuta 2011 17:53
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: k...@syce.net; dnsop@ietf.org
> Subject: Re: draft-savolainen-mif-dns-server-selection-06.txt
>
> > My thinking evolved fr
teemu.savolai...@nokia.com wrote:
> Hi James,
>
> My thinking evolved from DNS search list option defined in RFC3646, hence
> using DHCPv6 seemed like a logical choice.
The two seem quite distinct to me. The existing search list option
provides a global setting for the client, and is intended t
Hi James,
My thinking evolved from DNS search list option defined in RFC3646, hence using
DHCPv6 seemed like a logical choice.
Additionally collecting information required for multi-homing configuration
into one place (DHCPv6) seemed useful: this option, DHCPv6 Route Option
(draft-ietf-mif-dhc
I read this draft with some interest, as I've run into this sort of
problem many times myself.
I'm curious, though, about the architectural implications of the
described design. In particular, the use of DHCPv6 to convey
suffix/prefix information means that the DHCP server needs to be updated
as
29 matches
Mail list logo
