Skip to main content

Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-09

Yes

(Sean Turner)
(Stewart Bryant)

No Objection

(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)

Note: This ballot was opened for revision 07 and is now closed.

Richard Barnes Former IESG member
Yes
Yes (2013-11-20 for -07) Unknown
Stylistically: The "* are considered a threat" phrases seem singsongy and unnecessary.  The use of the verb "to effect" seems antiquated and, well, affected.
Sean Turner Former IESG member
Yes
Yes (for -07) Unknown

                            
Stewart Bryant Former IESG member
Yes
Yes (for -07) Unknown

                            
Ted Lemon Former IESG member
Yes
Yes (2013-11-21 for -07) Unknown
I support Barry's DISCUSS as well.
Adrian Farrel Former IESG member
No Objection
No Objection (2013-11-20 for -07) Unknown
Section 8. Really? No-one provided useful or notable individual input? 
Sigh.
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2013-11-22 for -08) Unknown
Thanks for addressing my comments.
Brian Haberman Former IESG member
No Objection
No Objection (2013-11-18 for -07) Unknown
I support the publication of this document and I only have two quick points...

1. I agree with Barry's DISCUSS point on providing a definition of PATHSEC in the document rather than referencing the WG charter.

2. It may be worthwhile to mention in section 3 that "inaccurate" is a subjective term when discussing network operators' views of a BGP Update.  Given the flexibility noted in section 4 about local policy, it is difficult to externally judge whether the result of a network operator's action is inaccurate or simply a change in local policy.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-11-19 for -07) Unknown
The distinctions in the threat characterized seems somewhat arbitrary, and appear to have  conflated motivation with methodology. e.g. hacker crimnal isp nation-state and so on seem somewhat arbirary categories, nation states might easily for example employ the methodologoies of the other(s) and vice-versa.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-11-27 for -08) Unknown
Thanks for the discussion. I've made my previous discuss
point a comment that you can handle as you choose. I do
still think that editing the draft to reduce the number of
references to the charter (and adding a URL for the 
version you mean if you keep some) would be a fine 
improvement. 

-- old discuss

I'm not sure that arguing that some residual threat ought
not be addressed because its not defined in an RFC or
because of the current charter is really ok. Shouldn't the
underlying technical reasons be what's presented in this
document?

-- old comments

- section 3: nations might want to censor (or get others
to do that on their behalf)

- section 4, intro: shouldn't we now also consider passive
wiretapping, at least to the extent that visible BGP
traffic might assist in setting that up more efficiently?
While that might not translate into a requirement for
confidentiality, I think it may be worth considering as
part of the attack.