Subject: RSVP aggregation draft

From: "Bruce Davie" <[email-masked]>
Date: Wed, 3 Jan 2001 16:48:41 -0500

Folks,
 As those of you who attended the meeting in San Diego know, the reason we
haven't seen draft-ietf-issll-rsvp-aggr-02.txt pop out as an RFC is that the
IESG didn't like the notion of swapping protocol numbers on RSVP messages,
for security reasons. I took the action item to describe what the benefits
of the current approach are, and would appreciate your comments. If no
alternative approach is proposed in the next couple of weeks, we will have
to write a new "Security Considerations" section and resubmit it to the
IESG. Along with my co-authors, I have composed a list of possible
alternative solutions, none of which fully captures the benefits of the
current approach. Thus, my suggestion is that we go ahead with the current
approach. I believe the deadline for finding an alternative is January 15 or
thereabouts.

Below are the claimed benefits of the current protocol-number changing
approach. I'm assuming familiarity with draft-ietf-issll-rsvp-aggr-02.txt.

1. An E2E RSVP message can be sent across a core of RSVP-capable routers and
will be ignored by them. Because router alert is still set, the cost of
processing the messages is not zero, but no RSVP code is invoked by the
messages.

2. The backbone routers don't need any new code to effectively ignore the
messages Although some new RSVP code is needed to handle aggregate session
types, it's not in the fast path, in contrast to the code which needs to
decide if a packet with RA set should be ignored.

3. The backbone routers can process E2E reservations as well as aggregate
reservations if desired. This allows aggregation to be used selectively,
e.g. only when the number of E2E flows sharing a common ingress & egress
exceeds some threshold.

4. The messages can be intercepted by the appropriate egress router and
treated appropriately because they still have router alert set; without
router alert, this wouldn't work.

5. Hierarchical aggregation is possible using the router alert "value" to
distinguish the different levels of aggregation.

6. There is no need to have a priori knowledge of where a particular E2E
flow egresses from the aggregation region. The correct egress is
automatically discovered and the egress is able to notify the ingress of its
identify using the RSVP PHOP information.

7. Changes of topology are automatically detected. If routing changes so
that an E2E flow has a new ingress or egress router for the aggregation
region, the new ingress-egress pair automatically learn about the change,
and old state times out for the old ingress or egress.

Now let us consider some alternative approaches:

A. IP-in-IP tunneling.

We could wrap the E2E RSVP messages in an IP header destined for the
appropriate egress, thus causing them to be ignored by the backbone routers.
Such an approach loses benefits 6 & 7, which I consider quite valuable.

B. Add an "E2E ignore" object to RSVP.

One could put some extra information inside the RSVP message to identify it
as an E2E message that should be ignored (as distinct from an E2E message
that needs processing, or an aggregate message) and the aggregation level
(to allow for hierarchy). But you would be forcing backbone routers to do
some RSVP processing on all the ignored messages which is a potentially
serious performance issue. Benefits 1 and 2 are lost.

C. Use the router-alert "value" to indicate E2E-ignore

Rather than modifying the protocol number of RSVP messages, we could modify
the "value" field in the RA option. There would be a reserved "E2E" ignore
value as well as the "aggregation level" values currently described in the
draft. This means the IP header is still being modified in a potentially
hostile way, so it may not address the IESG's security concerns. E2E
messages that are to be hidden from the core routers will need to have the
value field modified so that the backbone routers ignore them while still
processing un-aggregated E2E messages and aggregate messages.

This approach loses benefit 2 - you still need to modify backbone routers to
get them to ignore E2E messages. Note that this is fastpath code in general,
which is sometimes difficult to modify, and that there may be performance
impact.

On balance, I think this is the second-best approach after the current one,
but it may not satisfy the security folks any more than our current draft.

D. Use a new protocol number for aggregate reservations.

Another possibility is to leave the protocol number unchanged on E2E
messages but to use a new protocol number for aggregate messages. This means
that backbone routers need to be told to ignore protocol 46, which rules out
the possibility of making plain old E2E reservations and aggregate
reservations at the same time (lose benefit 3). Also lose benefit 2, as in
the preceding approach.

That's as many approaches as we've been able to come up with, so now we need
to hear from the WG:

 - Does anyone have a better alternative than the ones proposed here?
 - Does anyone have a problem with keeping the current approach and our
writing a security issues section to address the IESG concerns?

Bruce Davie

---

From: Bob Braden <[email-masked]>
Date: Wed, 3 Jan 2001 23:45:51 GMT

Bruce,

I unfortunately missed the ISSLL meeting, so I don't understand the
security concerns.  It seems generally true that mischievous intermediate
nodes can mess up RSVP in lots of ways; signaling across malevolent nodes
seems like a recipe for disaster.  Perhaps one should consider IP-in-IP
encapsulation of RSVP messages across untrusted parts of the network
(on the shakey assumption that a bad guy is not going to go to the
trouble of looking inside the outer IP header to discover what is RSVP).

Whether or not this is a fatal flaw depends on your viewpoint.  If
bad guys inhabit routers on major transit paths, then RSVP signal
disruption would seem to be the least of one's worries.  And RSVP
still seems useful even if it is limited to relatively benign
environments.

Is there a suggestion that the ISPs are going to actively attack
transit RSVP service crossing their domains?

..

(good exhaustive list...)

  *> 
  *> Now let us consider some alternative approaches:
  *> 
  *> A. IP-in-IP tunneling.
  *> 
  *> We could wrap the E2E RSVP messages in an IP header destined for the
  *> appropriate egress, thus causing them to be ignored by the backbone routers.
  *> Such an approach loses benefits 6 & 7, which I consider quite valuable.
  *> 
  *> B. Add an "E2E ignore" object to RSVP.
  *> 
  *> One could put some extra information inside the RSVP message to identify it
  *> as an E2E message that should be ignored (as distinct from an E2E message
  *> that needs processing, or an aggregate message) and the aggregation level
  *> (to allow for hierarchy). But you would be forcing backbone routers to do
  *> some RSVP processing on all the ignored messages which is a potentially
  *> serious performance issue. Benefits 1 and 2 are lost.
  *> 
  *> C. Use the router-alert "value" to indicate E2E-ignore
  *> 
  *> Rather than modifying the protocol number of RSVP messages, we could modify
  *> the "value" field in the RA option. There would be a reserved "E2E" ignore
  *> value as well as the "aggregation level" values currently described in the
  *> draft. This means the IP header is still being modified in a potentially
  *> hostile way, so it may not address the IESG's security concerns. E2E
  *> messages that are to be hidden from the core routers will need to have the
  *> value field modified so that the backbone routers ignore them while still
  *> processing un-aggregated E2E messages and aggregate messages.

I must admit that I thought we were still planning to use C., revealing
that I have not read the aggregation draft recently.  C. still feels
better to me than your current solution, but it is a fine point.

  *> 
  *> This approach loses benefit 2 - you still need to modify backbone routers to
  *> get them to ignore E2E messages. Note that this is fastpath code in general,

So, this sounds slightly bogus to me.  The "modification" is changing
a mapping table, that determines how/whether to interpret RA values.
Since RA is used for other things (isn't it?), there is no possibility
of casting a single value into silicon.

  *> which is sometimes difficult to modify, and that there may be performance
  *> impact.
  *> 
  *> On balance, I think this is the second-best approach after the current one,
  *> but it may not satisfy the security folks any more than our current draft.
  *> 
  *> D. Use a new protocol number for aggregate reservations.
  *> 
  *> Another possibility is to leave the protocol number unchanged on E2E
  *> messages but to use a new protocol number for aggregate messages. This means
  *> that backbone routers need to be told to ignore protocol 46, which rules out
  *> the possibility of making plain old E2E reservations and aggregate
  *> reservations at the same time (lose benefit 3). Also lose benefit 2, as in
  *> the preceding approach.
  *> 

Again, this sounds slightly bogus.  There must be some mapping function
between RA parameters and background routines.  This function can be
set to map either or both RSVP values to the RSVP routine, can't it?

In any case, I would write the security section.
 
Bob

---

From: Bob Braden <[email-masked]>
Date: Fri, 5 Jan 2001 22:03:34 GMT

*> 
  *> In any case, I would write the security section.
  *>  
  *> Bob
  *> 
Let me rephrase that.  What I meant was: I believe that writing the
security section is the correct approach.

Bob