Subject: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-sync-optimizations-09: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Mon, 13 Mar 2017 11:39:39 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-stateful-sync-optimizations-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-sync-optimizations/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) The Speaker Entity Identifier concerns me a lot because of the
spoofing vector it introduces, and because I don't think the uniqueness
is strongly specified.  I understand that the risk of spoofing is limited
to the State Timeout Interval, but that is a long time:  at least 30 sec
by default!  It looks like the main use case is to avoid state
synchronization after an IP address change -- are there other?  

(2) By making TCP-AO/TLS "RECOMMENDED", this document is not in line with
RFC5440, where only TCP-MD5 is mandatory.  I don't think the intent of
this document is to Update RFC5440, is it?  Also, why would the
recommendations for this extension be different than those in
draft-ietf-pce-stateful-pce (which doesn't go beyond what RFC5440
mentions)?  If you do keep the current recommendation, then
draft-ietf-pce-pceps should be a Normative reference.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 Mar 2017 21:33:18 -0000

> draft-ietf-pce-pceps should be a Normative reference.

It is (should be?) clear that moving PCEP on beyond MD5 is a Good Thing.

Ideally, everyone just gets on with it and the security update is handled by
draft-ietf-pce-pceps. But that I-D is chugging along in the WG for some reason.

Do we want:
1. All output from the WG to be blocked waiting for draft-ietf-pce-pceps?
2. All I-Ds to continue to say "just do MD5 per RFC 5440"?
3. To write sensible text in the Security Considerations and get on with life?

Adrian

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 13 Mar 2017 22:13:05 +0000

On 3/13/17, 5:33 PM, "iesg on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> wrote:

> draft-ietf-pce-pceps.

I agree.  That security update doesn’t belong in this document.

Alvaro.

---

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 14 Mar 2017 10:04:48 +0000

I also agree and I think the right thing to do is to make PCEPS a normative reference, as Alvaro suggested.  We should have PCEPS submitted for publication in time for the Chicago meeting, so we can all "just get on with it".

Jon

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[email-masked]] 
Sent: 13 March 2017 22:13
To: [email-masked]; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-stateful-sync-optimizations-09: (with COMMENT)

On 3/13/17, 5:33 PM, "iesg on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> wrote:

> Ideally, everyone just gets on with it and the security update is 
> handled by draft-ietf-pce-pceps.

Alvaro.

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 15 Mar 2017 17:05:05 +0000

Hi all,

After digging out from snow yesterday and some off-line discussion digging, here's an update for the IESG.

For this draft, we will retain the text as is, with the RECOMMENDED and the informative reference to draft-ietf-pcep-pceps.

Background info:

- this draft does not update any previous pce document on their recommendations for security. This document is referencing pce-stateful-pce which references RFC5440. The "RECOMMENDED" is in support of a new capability defined in this draft, speaker-entity-id. As it is a "RECOMMENDED" and not a "MUST", the reference is appropriately Informative.
- there is no need to hold this document until pceps is progressed. Pceps is an additional way to do security for RFC5440. PCEP (and this document) may operate with or without PCEPS.
- as this document normatively references RFC5440, when folks refer to RFC5440, they will also get the update for pceps.

Thanks,
Deborah

> From: Pce [mailto:[email-masked]] On Behalf Of Alvaro Retana (aretana)
> Sent: Monday, March 13, 2017 6:13 PM
> Cc: [email-masked]; [email-masked]; draft-ietf-pce-stateful-sync-
> [email-masked]
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_pce&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=EbtjkuYlaNR3zleQwr
> 7LKJpaol49I5ZQ7HdLhn-
> jh54&s=JZdG8WaaKkquKV_CQfa0_PjXlKu44wDbOG8VaryGhck&e=