Subject: Re: [RPSEC] Potential requirements

From: [email-masked]
Date: Tue, 12 Nov 2002 10:33:27 -0500 (EST)

(Oops.  Some weird editing error there.  The following should make more
sense.)

>I don't think this falls outside the scope of routing security
>requirements, although it comes close and you are right that we
>shouldn't require things that are out of scope for what we're doing
>here.

Ah, and there's my point right there.  We are not developing
"routing security requirements", we are developing "routing protocol
security requirements".  Try thinking of routing in wireless networks
or routing in peer-peer networks.  What we develop is supposed to be
applicable to routing protocols in those realms as well.  We aren't
even supposed to restrict ourselves to inter-AS routing protocols
(e.g., BGP).

Charlie's requirement:

>Proposed Requirement:
>    There must be a way for an ISP to evaluate their security
>    mechanisms and configurations in both a laboratory setting and in
>    the live Internet without impacting any router's Decision Process.

and your suggested rewording:

>        It must be possible for any routing protocol security mechanisms
>        to be used in a "warning-only" mode, where the security
>        information is processed, but it is ignored in the route
>        selection process. The instances where application of the
>        security information would lead to different routing decisions
>        are logged.

This rewording is not what I had thought the original statement to
mean.  If this is the point of the requirement, then that *is* a
legitimate requirement for routing protocols - that the security
mechanism should be capable of operating in an observatory mode where
it checks security protections but merely reports the results without
rejecting packets or adding any security protections to packets.  That
would be the only way to ensure that the routing protocol's security
mechanisms did not alter any router's decisions.

Note, however, that your statement is focussed only on what the
receiver of protected information might do.  If a router does not
produce protections, the fact that protections are not there might
change the decision some other router down the line might make.
And protections that are produced are sometimes reliant on protections
that are checked.  So it might be possible to make the security
mechanisms invisible locally, but much tougher to make that stick
globally.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Nov 2002 19:57:45 +0100 (CET)

> mean.

That's why I used the word "generalize" rather than "reword".

> If this is the point of the requirement, then that *is* a

Yes.

> mechanisms invisible locally, but much tougher to make that stick

There will be problems if you're going to flip this switch in a router
that is in the middle of a secure cloud, yes. However, it should be
possible to do some good testing this way at the edge of the secure part
of the network.

Iljitsch