[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on VPN framework document
Stephen,
> So the difference would be:
>
> [IP2][IPSEC][UDP][L2TP][PPP][IP1][TCP][APP] now
>
> [IP2][IPSEC][ New Headers ][IP1][TCP][APP] later.
>
> The 'Newheader' would need to cover PPP-like and L2TP-like features.
I think it depends on what the 'new headers' are and what procedures
are needed to support them. At one extreme is a brand new tunneling
protocol with its own set of signalling procedures, divorced from
ISAKMP. In the middle would be a new protocol which did its signalling
in an ISAKMP context, and which negotiated an extra layered 'SA'
on top of an ESP/AH SA. The simplest approach is just to add some
extra attributes to an ESP/AH SA. While there may be some scenarios
which demanded the first or second cases, e.g. some new flow or
congestion control scheme, I think that the third case can handle
most common needs (e.g. multiprotocol / opaque transport for VPNs),
and that for the common case the simplest solution possible should
be pursued.
> Thanks for the response Bryan. One aspect I wanted to see
> some focus on (and didn't spot) was end-to-end QOS monitoring -
> measuring dynamically how much of the 'guaranteed bandwidth'
> I'm actually getting through a VPN.
This is certainly an area that needs more analysis. I think
one approach is to use a combination of RSVP, to reserve
bandwidth between tunnel endpoints, and to treat a VLL just
like any other (logical) interface on which traffic shaping,
scheduling and policing can be carried out.
Bryan