Subject: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-ttz-05: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 05 Jan 2017 06:16:56 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-ospf-ttz-05: 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-ospf-ttz/

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

- section 13: I don't agree that there are no new
security considerations, and in fact you seem to raise
one so I'd suggest dropping the "nothing to see here"
pseudo-boilerplate;-)

- section 13: If a router inside a TTZ is borked, then
mechanisms that detect borked routers won't work as
well from outside the TTZ I guess (e.g. they might
identify the wrong router as the borked one). And
contrary-wise, hiding topology may help in that it may
make it harder for an attacker to find a desirable
target. Did anyone think about this? (This is not a
discuss only because I'm not familiar enough with ospf
but I bet a beer that hiding topology will create more
new security issues that are not described here;-)

- 8.1: Did I miss where "Z flag" was described?

- nit: six authors again, plus 2 contributors plus 4
"other authors." I really don't get why it's not
possible to reduce to 5 in cases like this.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 5 Jan 2017 08:36:38 -0600

Make Stephen happy, but ...

On Jan 5, 2017 08:17, "Stephen Farrell" <[email-masked]> wrote:

I think the changes we discussed on my comments to make it clearer what TTZ
looks like to anything outside the TTZ will help, at least a bit, for SEC
types to understand security threats. Maybe it's worth remembering
Stephen's comments when you're adding context early in the document?

Thanks,

Spencer

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 5 Jan 2017 16:01:52 +0000

Hi Stephen,

    Thank you very much for your time to review the document and your valuable comments.
    Your comments are addressed inline below with prefix [HC].

Best Regards,
Huaimo
-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, January 05, 2017 9:17 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Stephen Farrell's No Objection on draft-ietf-ospf-ttz-05: (with COMMENT)

- section 13: I don't agree that there are no new
security considerations, and in fact you seem to raise
one so I'd suggest dropping the "nothing to see here"
pseudo-boilerplate;-)
[HC]: We will change the text accordingly.

- section 13: If a router inside a TTZ is borked, then
mechanisms that detect borked routers won't work as
well from outside the TTZ I guess (e.g. they might
identify the wrong router as the borked one). And
contrary-wise, hiding topology may help in that it may
make it harder for an attacker to find a desirable
target. Did anyone think about this? (This is not a
discuss only because I'm not familiar enough with ospf
but I bet a beer that hiding topology will create more
new security issues that are not described here;-)
[HC]: When a router in a TTZ is borked, mechanisms that 
detect borked routers might not detect the borked router
inside the TTZ from outside the TTZ since the topology
of the TTZ is hidden from outside. If the mechanisms 
are put to detect borked routers inside the TTZ, then they
might identify the wrong router as the borked one.
In general, hiding topology makes it harder to be attacked.

- 8.1: Did I miss where "Z flag" was described?
[HC]: Z flag is described in section 6.2. 

- nit: six authors again, plus 2 contributors plus 4
"other authors." I really don't get why it's not
possible to reduce to 5 in cases like this.
[HC]: We will fix this nit.

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 5 Jan 2017 16:06:26 +0000

Hi Spencer,

    Thanks much for your comments/suggestions.
    We will consider them together.

Best Regards,
Huaimo
From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Thursday, January 05, 2017 9:37 AM
To: Stephen Farrell
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's No Objection on draft-ietf-ospf-ttz-05: (with COMMENT)

On Jan 5, 2017 08:17, "Stephen Farrell" <[email-masked]<mailto:[email-masked]>> wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-ospf-ttz-05: No Objection

I think the changes we discussed on my comments to make it clearer what TTZ looks like to anything outside the TTZ will help, at least a bit, for SEC types to understand security threats. Maybe it's worth remembering Stephen's comments when you're adding context early in the document?

Thanks,

Spencer