Re: Reply to opsec feedback from Harald Alvestrand

[Harald Tveit Alvestrand <harald@alvestrand.no>]

Thanks George!

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
prematurely.....

Sigh. How is it going with collecting people willing to give it a serious
review before/in Korea?

                       Harald


--On 22. februar 2004 05:56 -0800 George Jones <gmj@pobox.com> wrote:

> Date and Time: 2004-02-05, 02:37:59
> Version: 03
> Commented by: Alvestrand, Harald
> State before Comment: 0
> State after Comment: 0
>
> This paragraph is just plain wrong:
>
> ha>   Spoofed Packet.
> ha>
> ha>       A "spoofed packet" is defined as a "packet having a source
> ha>       address
> ha>       that, by application of the current forwarding tables, would not
> ha>       have its return traffic routed back through the interface on
> ha>       which
> ha>       it was received."
> ha>
> 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.
>
> Thanks,
> ---George Jones