Subject: RE: [RPSEC] Chrater Question

From: "Michel Py" <[email-masked]>
Date: Tue, 12 Nov 2002 14:04:17 -0800

Russ,

[Where did you get the asbestos suit? I need one too]

> Russ White wrote:
> Should this working only focus on "generic" requirements
> docs, or do we believe that there will, by nature, need
> to be one requirements doc per routing protocol?

It depends on what you call "generic".
- If it's truly generic, I don't see how one size could fit all.
- If you are talking about a single document that has a chapter for each
known protocol and an author list that takes half a page, I don't see
the point of creating such a monster and one doc per protocol would be
preferable, IMHO.

> If there will be, by nature, one requirements doc per
> protocol, should this working group consider those, or
> simply refer them to the protocol working group?

Consider them here, IMHO. Do feedback often to the protocol working
group though, because impossible to meet requirements or requirements
that do not reach consensus in the protocol working group are of no use.

> Note also that it will probably be easier to get security
> smart people looking at things here than in the individual
> routing protocol working groups.

Agreed.

> Should this working group be limited to two documents,
> a single threats draft, and a single requirements draft,
> or is there more latitude, and more documents which would
> be appropriate to address?

My view as a protocol developer:

- I see a need for a single threats doc and a single requirements doc,
but IMHO these should be truly generic and short, which means that there
also is a need for protocol-specific docs.

Which leads me to what I would like this WG to do:
1. Assess what is wrong with my protocol's security.
2. Evaluate what I could or should do to enhance it.
3. Produce a recommendations doc that includes both generic security
issues and the ones that are specific to my protocol.

Note that this should be, IMHO, a continuing process for new protocols
that still are work in progress, as there is flexibility in releasing
interim drafts.

Michel.

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Russ White <[email-masked]>
Date: Wed, 13 Nov 2002 07:53:39 -0500 (EST)

> Note that this should be, IMHO, a continuing process for new
> protocols that still are work in progress, as there is
> flexibility in releasing interim drafts.

Thanks, Michael, for the feedback. I think we probably need to
have some further discussion on this: so far, we have:

-- We should have one generic threats and one generic
requirements draft.
-- We should also have protocol specific recommendations (or
requirements?) drafts, as we can get them done.
-- We shouldn't have protocol specific requirements drafts, but
only one generic requirements draft.

Any other thoughts/issues/etc.? It's be nice to be able to wrap
this discussion up in Atlanta, with the AD's present, so we can
understand where we are going....

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Nov 2002 14:23:33 +0100 (CET)

> understand where we are going....

I think it would be useful to separate IGP and EGP issues. Once again
I'll risk getting ahead of things by naming instances of real-world
routing protocols, but bear with me as I think it will make things
clearer.

IGPs such as OSPF or IS-IS (do we even want to look at RIP???) simply
detect routers and start exchanging routing information. Obviously some
level of protection can and should be used here, but at what point is
the advantage of having a dynamic routing protocol in the first place
lost as more and more information must be explicitly stated in order to
validate the potential flow of packets?

BGP on the other hand requires neighbor relationships to be set up
explicitly, so adding some means to better secure this doesn't really go
against the grain of the protocol, and since the whole point of an IGP
is to exchange routing information with other autonomous systems,
checking the received routing information to see if it's valid makes
much more sense than in an IGP.

Then there is the fact that there are "competing" IGPs, you get to
control the IGP yourself, and if you really, really hate them, you can
run without one. Running without BGP or using a different EGP is not an
option for most people at this time, so the level of consensus about
what's good for BGP and what isn't should be much higher than that for
an IGP.