Subject: Re: [RPSEC] Potential requirements

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

>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 multicast 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 we 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: [email-masked]
Date: Tue, 12 Nov 2002 10:28:30 -0500 (EST)

>Routing security that does not take one the systems approach is making
>fundamental errors. If you want to make improvements in BGP's security, then
>you HAVE TO UNDERSTAND WHAT YOU CAN DO WITH TODAY'S TOOLS! You also have to
>understand why people do and do not used these tools. Not know those factors
>will mean you go down a path of designing undeployable "routing protocol
>security features."

Understanding today's tools is one thing.  Writing requirements about
how ISPs are supposed to use today's tools IS ANOTHER THING ENTIRELY
AND NOT THE JOB OF THIS WORKING GROUP.

>If you want the two worlds to reach
>consensus, then efforts to make sure both side understands the other. If
>that means documents to clue in both sides as a foundation document, then
>yes, it would be within the charter.

I'm all for understanding.  Foundation documents are OK.  Requirements
for how ISP's operate are not.

Defining what it means to evaluate the security mechanisms and
configurations (SSH, HTTPS, SNMPv3, Kerberos, SMIME, IPSEC, Secure
FTP, etc., and of course OSPF/RIP/BGP authentication) an ISP uses is a
huge task well beyond our capabilities.

--Sandy

---

From: [email-masked]
Date: Tue, 12 Nov 2002 16:44:05 -0500 (EST)

Russ said:

>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? 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, when answering this, that requirements docs do not
>entail suggested changes to the protocols, and could be fed, once
>they are rfc'd to the appropriate working group as input towards
>protocol changes, if they are handled here. 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.
>
>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?

For my two cents worth, I would say that there should be one threats
and one requirements document, with different instantiations of the
requirements document or both for individual protocols.  But there
could not possibly be an instantiation done in this working group for
each and every routing protocol - we would never finish.  OTOH, we
need some worked examples to test out the opinion that the threats and
requirements are generic - so we'll need to choose a representative
set.

--Sandy

---

From: [email-masked]
Date: Tue, 12 Nov 2002 16:46:17 -0500 (EST)

Russ said:

>Before we say that we should or should not address a "routing
>system," we need to define the term first. Is the authorization
>and vlaidity of routing information a part of the protocol, or
>the system? 
>
>Can you, in fact, secure a protocol simply by securing the
>communication between two devices running that protocol, and when
>you move into areas of validity of membership, and authorization,
>you are, by definition, moving into a "system," rather than a
>"protocol?"

and then

>Well, most protocol designers and implementors would disagree on
>this point--a protocol is simply a set of signals for sending
>information, and knowing how to parse it intelligently. Protocols
>do not, in any way, imply the correctness of what is sent. IPsec
>cannot validate the contents of what is sent, only that it is
>sent without medling, prying eyes seeing it, etc.

I would disagree with your characterization of protocols.  I believe
that a protocol spec always includes the actions that a receiver takes
upon receiving protocol messages as well as when and what a sender
sends.  "Actions taken when certain syntax is seen" is the usual way
of specifying semantics.  So protocol specs always include semantics.

The problems with many protocols is that the actions taken indicate
assumptions about the message contents that are not guaranteed to be
true.

So IP (and TCP) takes certain actions on receiving an IP packet from an
IP address that assume that the sender of the IP packet is the source
IP address.  That assumption was false and led to the development of
IPSEC to make the assumption true.

So DNS takes certain actions on receiving a query response that
assume that the information in the response originated from an
authoritative zone.  That assumption was false and led to the
development of DNSSEC to make the assumption true.

So BGP takes certain actions on receiving an UPDATE that assume that
the originator of an address is authorized to originate that address
and that the UPDATE has passed through the AS's in the AS_PATH.
That assumption was false and led to the development of S-BGP (and
SoBGP and filters and etc.) to make the assumption true.

So OSPF takes certain actions on receiving LSA's that assume that the
Advertising Router in the LSA is the ID of the (original) sender of
the LSA.  That assumption was false and led to Radia Perlman's work
and RFC 2154.

Information that is communicated in the protocol message and must satisfy
certain security properties for the protocol to behave properly should
be considered part of the protocol.

Information that is not communicated in the protocol might be part of the
protocol configuration (like routing policy, for example) but can't
be secured by anything the protocol does aren't protocol security
requirements.  (Maybe "infrastructure" could be used to talk about
these things that the protocol relies on being there.)

--Sandy

---

From: [email-masked]
Date: Wed, 13 Nov 2002 08:25:17 -0500 (EST)

>> I am stating that BGP correct operation is based on an
>> implicit assumption that the origin AS is authorized to
>> advertise the address block by the owner, etc. Do you
>> disagree?
>
>Yes. :-)
>If my daughter walks into a store with my credit card and
>attempts to buy something, does her physical access to my credit
>card mean that she is authorized to use it? No. Does a router's
>apparent physical access to a given destination mean it is
>authorized to advertise that destination? No.

Russ, I think you've missed the point.  Steve's not saying that the
appearance of a network originiation in the message is authorization,
he's saying that the appearance is treated as though it were.  The BGP
protocol behaves as if the appearance of an origination in a message
means that AS is authorized to originate that network.  So the analogy
would be if the merchant behaves as if the physical access to the card
meant your daughter was authorized to use it.  And then you'd be in
trouble.  But the merchant does not make that assumption - the
merchant wants a signature on the credit card slip that matches the
signature on the card.  And S-BGP provides the proof of authorization
that is missing but assumed in the current protocol.

>I think you're saying that the manual configuration which
>(today) constitutes the authorization to advertise a given
>reachable destination is part of the routing protocol.

It is precisely because the receiving router can't possible know
from the message it receives that the sender was manually configured
to send that info or that the manual configuration was authorized
that we find ourselves in these straits.  The crypto protections
provide the proof of the authorization that can be carried in the
protocol.  The manual configuration is not part of the protocol,
the crypto enhancements could be.

--Sandy