page 1  (8 pages)
2to next section

SMCC Technology Development

Futures

n PATH/RESV/PTEAR/RTEAR Authentication

n Internet Draft by the next RSVP Teleconference.

SMCC Technology Development

Proxy Relay / Bastion Host

n PATH/RESV messages mapped from one side of host to other.

n Apply application-based admission control to determine if proxy can provided requested QoS.

n Only passed if other application-based authentication criteria met.

n Issues:

n Reply with RESV immediately or only after down-stream host/router responds?

n Relationship between flow state and session state (e.g., does RTEAR cause termination of proxy)? Initial assertion: should be independent.

SMCC Technology Development

Issues

n Source Spoofing

n Bandwidth Attacks

SMCC Technology Development

Filtering Routers

n Router multicast/RSVP-aware:

n Normal state is to disallow multicast data without filter criteria, but allow RSVP PATH/RESV messages.

n Authenticated RESV/PATH messages used to instantiate firewall filters in addition to flow reservation filters. PTEAR/RTEAR/Timeouts clear firewall filters in addition to flow reservation state.

n Can restrict to just one side of firewall, and to just PATH- or RESV-based instantiation.

n Standard packet scheduling mechanisms apply. Can prevent bandwidth-based denial of service via flow separation.

SMCC Technology Development

Filtering Routers

n Router not multicast/RSVP-aware (i.e., encapsulated tunnel through allowed through filter):

n Allow all packets, or filter on encapsulated header.

n If filter on encapsulated header, add additional filter criteria for RSVP messages.

n No RSVP reservations at router. Bandwidth-based denial of service still possible

n Router multicast-aware but not RSVP-aware:

n Add additional filter criteria for RSVP messages.

n No RSVP reservations at router. Bandwidth-based denial of service still possible.

SMCC Technology Development

Goals (Continued)

n PATH/RESV/TEAR messages that originated from one of the firewall should be authenticated before being relayed to the other side of the firewall

n RSVP Messages should available for:

n Firewall local resource management

n Traffic policing of flows to prevent bandwidth attacks from the outside and traffic disruption from the inside.

SMCC Technology Development

Goals

n It should be possible to propagate a flow over the firewall while maintaining the conceptual identify of the flow. This implies:

n PATH/RESV/TEAR messages from a sender on one side of the firewall should be forwarded/regenerated on the on the other side for the benefit of downstream routers and potential receivers.

n The data packets that make up the flow should be forwarded/regenerated on the other side of the firewall.

n RSVP messages should on be allowed to cross the firewall when the corresponding data packets that make up a flow are allowed to cross the firewall (and vice versa).

SMCC Technology Development

Firewall Architecture for

RSVP

Michael Speer

speer@eng.sun.com