Subject: [mif] New Charter Items

From: Margaret Cullen <[email-masked]>
Date: Wed, 2 Mar 2016 07:24:45 -0500

At the last IETF meeting, and later on the mailing list, we reached consensus that we would use a two-step approach for the configuration of explicit PVDs.  RAs would be used to provide the information to do a second-step look up, including the PVD name.  Then a second step would be used to look up further information about the PVD.

The only proposal we currently have on the table for a second-step look-up is a DNS look-up, and no one seems to proposing any other second step, so I believe there are three things that we need to define in order for this to work:

- An NTP server option for RAs, so that DNSSEC can be used for the lookup.
- A PVD Name option for RAs, so that we can tell hosts what PVD to look up.
- What PVD information can be stored in the DNS and how it will be retrieved.

Those things would need to be added to our charter, so that we can accept corresponding work items.

Does anyone have any objection to adding these three things to the MIF charter?  If not, the chairs and the AD will put together a propos

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 2 Mar 2016 15:42:12 -0800

Got questions & observations here..

> - A PVD Name option for RAs, so that we can tell hosts what PVD to look up.

I thought we already got a WG I-D that is able to carry required name 
information if needed - maybe not in the "format" at the moment folks 
want it to be but it is up to WG to steer the content, right?

> - What PVD information can be stored in the DNS and how it will be retrieved.

While DNS is a good thing and actually a good idea in the context we are 
discussing here, few things to think in addition to those already found 
in the meeting minutes: does not quite work if DNS is not there and 
going to DNS all time even for the simplies form of PVD configuration 
seems a bit unefficient. These are not really concern of homenet type 
setups but maybe for other deployments where links come and go.

My 0.02ZWD,
	Jouni

> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 2 Mar 2016 23:51:53 +0000

+1

I missed the last meeting and looks like I missed this discussion and the conclusions around this new approach.

Sent from my iPad

> On Mar 3, 2016, at 5:12 AM, Jouni Korhonen <[email-masked]> wrote:
> 
> I thought we already got a WG I-D that is able to carry required name information if needed - maybe not in the "format" at the moment folks want it to be but it is up to WG to steer the content, right?
> 
> While DNS is a good thing and actually a good idea in the context we are discussing here, few things to think in addition to those already found in the meeting minutes: does not quite work if DNS is not there and going to DNS all time even for the simplies form of PVD configuration seems a bit unefficient. These are not really concern of homenet type setups but maybe for other deployments where links come and go.
> 
> My 0.02ZWD,
>    Jouni
> 
> 
> 
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 8 Mar 2016 13:55:37 +0100

> - An NTP server option for RAs, so that DNSSEC can be used for the lookup.

Sounds like a good idea.

I guess DNSSEC operation needs the querier to have the right time 
otherwise it's insecure?  Hence the need for NTP?

I could find 2 earlier drafts on this, maybe there are others.
draft-chen-ntps-ra-opt-00
draft-bcd-6man-ntp-server-ra-opt-00

If extending RA then it's good to use the RA "flags option" RFC5075.

Alex

---

From: Margaret Cullen <[email-masked]>
Date: Sat, 12 Mar 2016 19:06:15 -0500

On Mar 8, 2016, at 7:55 AM, Alexandre Petrescu <[email-masked]> wrote:
> I guess DNSSEC operation needs the querier to have the right time otherwise it's insecure?  Hence the need for NTP?

As I understand it, DNSSEC needs the right time, otherwise it doesn't work.

> If extending RA then it's good to use the RA "flags option" RFC5075.

I don't think we'd probably do an NTP RA option in the MIF WG.  I suspect it would make more sense to do it in 6man -- we'd have to discuss it with them and see if they agree.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 12 Mar 2016 19:14:18 -0500

> I thought we already got a WG I-D that is able to carry required name information if needed - maybe not in the "format" at the moment folks want it to be but it is up to WG to steer the content, ri…

Right.

> While DNS is a good thing and actually a good idea in the context we are discussing here, few things to think in addition to those already found in the meeting minutes: does not quite work if DNS i…

This mechanism would not be used for implicit PVDs (which I think have at least 80% of the benefit of explicit ones), only for explicit PVDs, and perhaps only for explicit PVDs that have a flag set saying that hosts should seek more information (?).  Presumably, if a host could not reach the DNS to find additional information about an explicit PVD, it would treat the PVD like an implicit one.  

I think it is a question for any two-step method, what to do if the first step configures and explicit PVD, but the second step can't be completed and/or returns an error?

Margaret

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 13 Mar 2016 11:26:27 +0200

On 13.3.2016, at 2.06, Margaret Cullen <[email-masked]> wrote:
> As I understand it, DNSSEC needs the right time, otherwise it doesn’t work.

Yes. Although given sane RTCs it can most of the time work even without _accurate_ time.

> I don't think we'd probably do an NTP RA option in the MIF WG.  I suspect it would make more sense to do it in 6man — we'd have to discuss it with them and see if they agree.

NTP RA option would not really fix the solution securely anyway, as secure RA does not really happen. And secure NTP is also something that does not really happen. So there is chicken and egg problem there that is relatively far out of MIF scope I think.

IETF being IETF, we cannot specify insecure things these days officially but all base things are insecure and/or undeployed.

Cheers,

-Markus

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 13 Mar 2016 07:54:45 -0400

> NTP RA option would not really fix the solution securely anyway, as secure RA does not really happen. And secure NTP is also something that does not really happen. So there is chicken and egg probl…

Since we get our information on how to reach the DNS from RAs, getting our NTP information there isn't any less secure than getting our time information somewhere else, and then using to to reach the DNS we received in an RA, is it?

Having NTP information passed in an RA doesn't make RAs more secure, but it does change the threat model of a DNS lookup.  For regular DNS, the attacker only needs to spoof a DNS server (ours or one higher up in the tree), whereas to attack us in the case where we are getting an NTP server in an RA and using DNSSEC, the attacker also needs to be able to inject traffic on our local network that looks like it came form our router.  So, configuring an NTP Server via RAs and using DNSSEC is more secure than just using DNS, even if we can't/don't secure the mechanism via which our DNS and NTP Server are configured.

> IETF being IETF, we cannot specify insecure things these days officially but all base things are insecure and/or undeployed.

The spectre of the intractable security AD who blocks your work until you secure the entire Internet is just a holdover from a less reasonable time, IMO.  With the current ADs, you can generally specify something that is (1) more secure than the alternative, and/or (2) not less secure than what you are replacing.  It sometimes requires that you work with the ADs to help them understand that.

I am really quite sure that the security ADs would not block a new RA option because we didn't figure out how to get the world to deploy SEND.

Margaret