I should add to this response that Dave Crocker
proposed that we pull back on this BCP and
explicitly consider its impact in each of our
working groups.
I think that this is a useful and necessary approach
to the problem in order to ensure that we calmly
address the threat in a measured and proportionate
way and fully understanding the impact on the
Internet, the users of internet technology and
the operation of the IETF of this proposed BCP.
- Stewart
On 12/12/2013 12:22, Stewart Bryant wrote:
On 12/12/2013 11:21, Stephen Farrell wrote:
Stewart,
On 12/12/2013 10:42 AM, Stewart Bryant wrote:
On 11/12/2013 15:07, Scott Brim wrote:
Regarding "where possible", since every situation is different, I do
not think the IETF should try to find a balance, or say anything
universal about deployment. There is no position that will work for
everyone. The IETF should absolutely try to make privacy/security a
_possibility_, and that's why every effort should offer the
_possibility_ of mitigation. That's as far as we should go.
.
I would like to explore this a bit more if I may.
RFC3552 says we must describe
1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against
I'll note that many of the 2119 MUSTs in 3552 aren't
enforced in practice - generally secdir reviews and
the like are much more reasonable and try to figure
out whether or not a draft has done a good enough
job and those reviews do not include mindless checking
of boxes as to whether the MUSTs from 3552 have been
met. I'm sure the same is true for other area reviews
as well - we're all basically a fairly practical bunch
who want work to get done and done well, but we don't
want to build a form-filling bureaucracy. (Well, the
IETF does have a tendency to wander in that direction
but then some of us also push back the other way as
well:-)
Sure, and I think I am looking for considered text in
the BCP that ensures, to be able to "do the right thing".
Separately, I would argue that this draft takes a
better approach than the overly prescriptive parts of
3552. I think the informative parts of 3552 are much
more useful than the 2119 language parts.
So if you're worried that this BCP will suddenly
mean that the security area starts to jump down
everyone's throat, then I'd say you should relax.
The security area already has plenty of BCP
ammunition in that respect, but luckily doesn't
behave like a set of process-obsessed fools. And
it won't start doing that either is my pretty
confident prediction. This BCP will have no effect
on that at all.
Please remember, not so long ago, we had a situation
where routing protocols and updates to existing routing
protocols consistently stalled on concerns about
their security.
Now consider the attack that caused us to start this work programme
and think about RFC791. Would that pass security review against
the new hurdles?
I think that the answer to 2.1 is: This protocol is susceptible to a
metadata harvesting attack of the protocol, and moreover it
provides an essential clue in analyzing the payload. It also
provides essential clues in determining the topology of the
network to an observer and thus making other network
elements vulnerable to attack.
So would RFC791 be accepted for publication with its vulnerability
to a pervasive monitoring attack?
Answers to counterfactual questions won't get us very
far, so please take this with the large pinch of salt
it deserves.
The text of RFC791 would almost certainly be bounced
today for loads of reasons. Things have moved along a
lot in the 32 years since that was published. So my
answer is "no" - it'd not be accepted for publication
for lots of reasons. I don't think its useful to
speculate as to which issue would be the most blocking
in the alternative universe you're envisaging where
we re-invent IP in 2013. (And I hope people who want
to explore that alternative universe start new threads
for that:-)
But I don't see what you're hoping to learn from any
answer to that counterfactual question to be honest.
I am trying to understand the impact of the BCP you propose
on the Routing and Internet layers. In particular whether
its publication will mean that new lower layer protocols
designed in the same "protocol style" as we have used
in the past will continue to be accepted and whether
we will be asked to revise work in progress on the
modification of those protocols to include these issue
in the base protocol.
Remember we reached a point a few years ago where
routing work almost stalled due to concerns about security
of the base routing protocols. Hence my concern about
the wider consequences of this fairly hasty document
on work in these area.
I constructed an example based on IP as a
lower layer protocol that that everyone is familiar with.
As you will gather I am concerned that without greater
care in the proposed BCP text we might be unable to
publish anything like it in the future, or at least not
be able to publish it without considerable argument with
the Security Area.
So, let's go back to the example, or use IPv6 if you prefer,
and explain what technical changes (if any) we would
need to make to it to be able to publish, post the publication
of this BCP, or tell me what an acceptable security
considerations section would look like for the existing packet
design.
- Stewart
.
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html