Subject: Re: Question about integrity

From: Bob Lindell <[email-masked]>
Date: Mon, 03 Apr 2000 10:06:43 -0700

> What is the proper procedure for an RSVP router if an incoming message
> has an INTEGRITY object, but the router does not have INTEGRITY support
> implemented?
> 
> I think it should go ahead and process the message anyway (akin to
> someone giving you a key to a room, and you find out that the room does
> not have a lock on the door.)
> 
> Others here, however, have suggested that the message should be
> ignored.  Possibly sending back an error message.  The idea here being
> that the sender of the message is asking for a level of security that
> can not be provided.

I also think it should go ahead and process the message.

If the sender was really concerned about security, it would make sure
the next hop supported integrity.  There are 2 basic cases I can think
of at the moment.

	1) A sender would require that the replay protection handshake
	complete successfully.  By definition the next hop supports
	integrity.

	2) A sender does not handshake over a point to point link
	that is assumed to be secure from replay attacks.  It is
	likely in this case that the sender has apriori knowledge
	that the peer supports integrity as part of a peering
	agreement.

Bob Lindell

---

From: David Charlap <[email-masked]>
Date: Fri, 07 Apr 2000 20:37:27 -0400

Bora Akyol wrote:
> 
> I would think that if you cared enough to insert an INTEGRITY object,
> then if the node does not support it, it should respond with an error
> saying "INTEGRITY not supported". Note that my answer is biased
> towards use of RSVP in a backbone type network where authentication
> and correctness really are important and the operator is likely to
> have knowledge that all of his nodes will support a given capability.

Keeping in mind that there doesn't exist any such error.  As a matter of
fact, Appendix B explicitly lists INTEGRITY failure as a condition that
is not signalled to other nodes, but is dealt with silently (possibly
involving logging and/or administrative alerts.)

-- David

---

From: Bora Akyol <[email-masked]>
Date: Fri, 07 Apr 2000 17:30:53 -0700

I would think that if you cared enough to insert an INTEGRITY object, then if
the node does not support it, it should respond with an error saying
"INTEGRITY not supported". Note that my answer is biased towards use of RSVP
in a backbone type network where authentication and correctness really are
important and the operator is likely to have knowledge that all of his nodes
will support a given capability.

Bora

ps. Of course we can build in capability negotiation to RSVP :-)

---

From: Bora Akyol <[email-masked]>
Date: Fri, 07 Apr 2000 20:18:43 -0700

The fact that an error or an object doesn't exist did not stop us before
(see. RSVP-TE), I suggest that we define such an error condition.

Even if we did not, a message should not be accepted under the conditions
specified in this thread. This is unacceptable for a backbone application.

It may be acceptable for PC-to router and enterprise application for some
people, I would rather just drop the message since putting an INTEGRITY
object indicates that the sender of the message cared about security enough.

Regards

Bora Akyol

---

From: Bob Lindell <[email-masked]>
Date: Mon, 10 Apr 2000 09:36:49 -0700

First, let me correct my previous email message.  The word "sender" under
points (1) and (2) below should really say "receiver".  Receivers protect
themselves on accepting the messages they process.  Senders are likely to
know apriori whether receivers support integrity, but they are unlikely
to keep state on whether a receiver has issued a challenge to them as
part of a handshake.

Now on to the real discussion...

First, I think it important to differentiate the concepts of end to
end RSVP signalling and the use of the optional hop by hop integrity.
RSVP signalling is an end to end signalling between hosts in the Internet.
Hosts should expect to be notified of errors when RSVP signalling does
not complete successfully along the end to end path.

The integrity option, by definition, is hop by hop.  There is no
expectation by hosts that an integrity option is required along an
entire path.  The lack of use of the integrity option over portions
of a path is not an error, but is dictated by engineering decisions.
Adminstrative domains will independently implement security solutions for
RSVP signalling.  Some may choose to use the RSVP hop by hop integrity
option between routers in their domain and with peering routers from
other domains.  Others may only use it for peering with other domains
and may use "secured" links internally, thus not requiring the interior
usage of the integrity option.

In the end, hosts expect to achieve end to end signalling, be able to
request QoS, and be billed only for the resources they have requested.

An example may be useful here.  Let us say I have two remote campuses
which are connected by commercial providers to the Internet.   End hosts
within these campuses routinely make RSVP QoS requests to the Internet
for resources on paths from one campus to the other.  I run my own campus
networks and I trust the infrastructure.  I do not configure the usage
of the integrity option between end hosts and routers in my networks.
At the peering points between my campuses and the Internet providers I
do use integrity because the provider requires it's usage.  The provider
uses integrity mainly as a protective measure for billing purposes.
Combined with policy, the provider will bill me for all RSVP related
services which appear to be coming from my routers (using my key(s)).

I have no idea how my RSVP signalling requests are protected in the
Internet, nor do I care.  I do care that I can signal end to end,
obtain resources, and be billed correctly for the services I use.

Back to the original questions...

First, should a receiver process a message that carries an integrity
option but it does not implement integrity?  I still believe the answer
is yes.  If a receiver does not need the integrity support to trust the
message it receives, it should process the message.

Second, is the integrity option geared towards backbone type network where
authentication and correctness really are important?  I say the answer
is a definite yes!  This is what I tried to say correctly in my previous
response, but didn't get it exactly right.  In a backbone environment,
you protect yourself and trust no one.  Of course, that isn't exactly
true, but you must trust your peering domains routing advertisements to
some extent if you want to get useful work done.  But you probably have
an extensive set of filters to reject what you believe may be incorrect.
In a backbone, I am likely to require all my peers to secure their RSVP
signalling packets with the integrity option to protect my network.
My border routers will be ruthless and not accept RSVP messages that
are not correctly keyed.  But inside my domain, I may see no use to
carrying the integrity option between my own routers.

Bob Lindell