[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reply to opsec feedback from Harald Alvestrand
It was good to hear that the "spoofed packet" thing was a quickly fixed
glitch. It seems you were thinking "spoofed packet = not sent by the
claimed origniator, detection of spoofed packet in stub networks = RPF
catches it", and somehow got the start and end of that sequence into the
definition rather than having the first part in the definition and the
second part in a section on simple stub networks.
Yes, we all know the problem of getting enough attention - and enough
attention from the RIGHT people. Sometimes it seems that the only workable
way is to grab them by the throat one by one.... and that can only be done
if you have significant credit with them already.....
I'm worried, though, about the fact that things are bad enough that we have
to get a document on the IESG's table for *approval* in order to get
serious review on it..... that just ain't right; not only does it create
needless work and feelings of confrontation, there's also a real risk that
the IESG could miss the fact that it isn't ready and approve things
Sigh. How is it going with collecting people willing to give it a serious
review before/in Korea?
--On 22. februar 2004 05:56 -0800 George Jones <firstname.lastname@example.org> wrote:
Date and Time: 2004-02-05, 02:37:59
Commented by: Alvestrand, Harald
State before Comment: 0
State after Comment: 0
This paragraph is just plain wrong:
ha> Spoofed Packet.
ha> A "spoofed packet" is defined as a "packet having a source
ha> that, by application of the current forwarding tables, would not
ha> have its return traffic routed back through the interface on
ha> it was received."
ha> Multihoming and asymmetric routing is now outlawed in the
Internet? No way!
Sigh. That was a very late change before -03 went out. The intent
was to say that for the simple *single homed stub networks* there
should be an easy way to apply protections such as uRPF to implement
the style of filtering suggested by rfc2827.
I apparently was not clear enough about that and there was immediate
feedback about it on the list (from C&W and others) and it was the
first thing fixed after -03 went out.
I've asked Pekka Savola to sanity check the new text.
ha> Comment: I'm joining the club - this document can't possibly have
ha> had enough review.
A couple of observations here.
The people who really need to give in put on this, and the people it's
primarily intended to benefit are the people who do the day-to-day,
in-the-trenches work of securing the operations of large networks.
The reality seems to be that they are generally either too busy
with day-to-day tasks, or possibly to cynical about the potential
for real positive change coming as a result of efforts such as this
to get involved. In the past year, I've presented this @ IETF
meetings twice (BOF in Vienna, security area directorate meeting @
Minneapolis), NANOG (Chicago), and RIPE/EOF/techsec-wg (Amsterdam).
In addition, I've solicited input from the nsp-sec mailing list.
There has been some response, but certainly not what I had hoped.
They're just too busy keeping things going.
Second, while some people have provided input on the opsec list
(thanks to all who have), it seems that, as a whole people
didn't start paying attention until the last call.
The feedback is good. I'm processing.
The goal from the start has been to collect the ideas and publish them
in a useful format/forum. Thoughts/direction on how to achieve that
goal are also welcome.