Hiya,
Snipped various bits...
On 12/12/2013 12:22 PM, Stewart Bryant wrote:
On 12/12/2013 11:21, Stephen Farrell wrote:
Stewart,
On 12/12/2013 10:42 AM, Stewart Bryant wrote:
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".
I'd argue its not needed on the basis that the draft
just highlights the consensus on this threat but makes
no process innovation. But if you want to suggest text...
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.
Ok, I get the concern. One could argue that the
better routing security we hope to have soon was
actually a good outcome though:-) But we don't
have to go there.
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.
Honest answer? I don't know. Let's consider source
addresses say. I for one would not try to make a case
that we could do away with those, nor that we know
for sure how to make them less leaky when considered
as identifying meta-data, when operating at the scale
of the Internet. So for me, its similar to the e2e
email security situation, which I understand a lot
better. We do know there are issues but I don't think
we have a practical mitigation that we could stand
over as "the" way to solve either problem.
But other folks know a *lot* more about lower layers
than me, so what'd happen would likely depend on
their analysis of the situation and of what's
practical. And that analysis should be done in
whatever is the relevant WG and should consider
the pervasive monitoring threat. But from what I
know, I don't think this BCP as-written could
justify blocking say some new IPv6 transition
mechanism just because source addresses were leaky
assuming that there really is no good mitigation
for the transition mechanism in question.
If at some point someone does come up with a
good practical way to mitigate the threat for
a protocol that is being developed or updated
then this BCP would call for that mitigation to
be seriously considered. And the usual set of
judgement calls as to whether or not that has
happened would follow. So YMMV as usual.
Again, I don't think there's any process change
here - sometimes we just don't have good mitigations
ready to go, even where we do know a threat exists.
And even when we do, or someone claims we do, have
a good mitigation the usual engineering analysis
and consensus processes are how we figure out what
to do.
Does that help?
S.
PS: "hasty" - are you trying to sound like an Ent? :-)