[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 102: NAS/QoS Filter Rule
Pasi wrote...
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of
> Pasi.Eronen@nokia.com
> Sent: Monday, September 26, 2005 7:45 AM
> To: Congdon, Paul T (ProCurve); radiusext@ops.ietf.org
> Subject: RE: Issue 102: NAS/QoS Filter Rule
> > 8) The document allows an IP tunnel rule with direction "out", but
> > does not describe what such a rule means (the description seems to
> > apply only to rules with direction "in")
> >
> > [pc] Avi has written a great description of how the tunnel facility
> > works and how the directions apply. I've attached a
> version of this
> > document - perhaps Avi has something more recent? We
> probably want to
> > consider how parts of his document are incorporated into an
> annex or
> > some part of the document to make this clear.
>
> Thanks, this explained things (but something along those
> lines needs to be included in the document).
Can you describe which were the primary points you found useful in
reading Avi's document? Moreover, how would you suggest the RFC draft
incorporate those points you found useful? Should we add yet another
Appendix? A new section? Something else?
Thanks,
MS
Today when we create a tunnel we tunnel all the traffic through that tunnel.
There is no way to specify which flows should be tunneled and which flows should
not.
There is a need to support a method to select which flows to direct to a tunnel.
This concept is not new. Certain advanced VPN products allows us to select which
traffic should be routed to the VPN and which should not.
As well, in certain cases it maybe useful to have multiple tunnels. The tunnels
may have a different end points; or there maybe multiple tunnels but each tunnel
utilizes different technology. It maybe useful to direct certain flows to these
different tunnels.
We will describe a method for directing certain traffic flows to a tunnel; then
we will look at how to support multiple tunnels. We will also look at how to
apply this dynamcially.
This proposal will greatly clean up how hotlining is done and will be useful
beyond just hotlining.
NOTE: this discussion is for simple-ip not mobile-ip.
Tunneling specification for RADIUS is provided by RF2868.
We use NAS-Filter-Rule to specify what traffic to direct into the tunnel. The
syntax is as per NAS-Filter-Rule but with the following (mostly all the same):
action is tunnel (new)
Direction (in|out|inout) (inout is new)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
Note direction: 'in' is from the terminal 'out' is to the terminal
As indicated, a couple of new things here, the rest is the same: New action
called 'tunnel' which can take a tunnel-id as a parameter when we have more then
one possible tunnels. We have added 'inout' to support bidirection to allow us
to specify whether the direction of the flows. This is an optimization -- if it
wasn't there you could use two rules, one with direction 'in' the other with
direction 'out'.
NOTE ON NOTATION
================
------> Flow in one direction
<-----> Flow in two directions
======> Flow in a tunnel in one direction
<=====> and in both direction
TEP Tunnel Endpoint
Directing flows to a single tunnel.
===================================
RADIUS server that wants all traffic that flows between the Mobile and
destination X will issue an Access-Accept that contains: The specification for
the tunnel using the attributes defined by RFC 2868 and an NAS-Filter-rule.
The NAS-Filter-rule will look like:
tunnel inout from assigned to 123.456.34.0
This will cause all traffic that flows between the the Mobile and the
destination (123.456..34.0) to be tunneled over the specified tunnel.
+-------+ +------+ +------+ +------+
| | | | |Tunnel| | |
|Mobile +<---------->+ NAS +<=======>+ End +<----->+Destin|
| | | | |Point | | |
+-------+ +------+ +------+ +------+
The direction attribute is important because it controls how information is
routed. The following will demonstrate how traffic is routed. In all these
diagrams time is increasing as we proceed down the page. As well, there is only
one tunnel.
When direction is out:
Mobile NAS TEP DESTINATION
| | | |
|---------->|========>|--------->|
| | | |
|<----------|<-------------------| (flows directly to NAS)
| | | |
The out bound traffic gets placed in the tunnel to the TEP and then the TEP
forwards the traffic to the Destination. The flow from the destination to the
mobile is routed directly to the mobile via the NAS. The NAS just passes it to
the mobile. The Home network would use this capability if it was only interested
in metering or seeing the outbound traffic from the Mobile.
When direction is in:
Mobile NAS TEP DESTINATION
| | | |
|---------->|------------------->| (flows directly to Destin)
| | | |
| +--|<-------------------| (flows directly to NAS)
| | | | |
| +--|========>|--+ |
| | | | |
|<----------|<========|--+ |
| | | |
| | | |
Outgoing traffic from the mobile gets to the NAS and is passed to the
Destination. Traffic from the destination gets to the NAS and the NAS redirects
the traffic to the tunnel to the TEP. The TEP then sends it back into the tunnel
to the NAS and the NAS forwards the traffic to the Mobile. The Home
When direction is inout:
Mobile NAS TEP DESTINATION
| | | |
|---------->|========>|--------->|
| | | |
| +--|<-------------------| (flows directly to NAS)
| | | | |
| +--|========>|--+ |
| | | | |
|<----------|<========|--+ |
| | | |
This combines the two diagrams together. Output from the Mobile reaches the NAS
and gets directed into the tunnel to the TEP. The TEP forwards the flow to the
Destination. When the Destination sends data to the Mobile it reaches the NAS,
the NAS redirects it to the TEP via the Tunnel. The TEP sends it back to the NAS
via the tunnel and the NAS forwards it to the Mobile.
Inout is useful when the home network wants to examine both incoming and
outgoing traffic.
Note that the above schemes flows the data through the TEP in stealth. That is,
neither the Mobile or the Destination know that the traffic has been redirected.
Also note that there maybe other scenarios as when the TEP acts like a NAT.
If the TEP is acting like a NAT, then we have:
Mobile NAS TEP/NAT DESTINATION
| | | |
|---------->|========>|--------->|
| | | |
|<----------|<========|<---------|
The mobile establishes a connection to the Destination but the TEP acting as
NAT, transforms the request source address (as NATs do) such that the
Destination sees the Source address of the incoming traffic from the Mobile as
TEP/NAT. Therefore any replies from the Destination are sent to the TEP/NAT.
Direction rule of 'in' is important. Direction set to 'out' won't work and
'inout' doesn't matter.
The TEP/NAT then forwards all traffic to the tunnel to the NAS. The NAS (as in
the cases above) always forwards any egressing traffic from the tunnel to the
Mobile.
Therefore, from the point of view of the NAS, it does not care whether the TEP
is transparent or has NAT like behavior, traffic egress a tunnel at the NAT gets
forwarded to the Mobile.
Multiple tunnels
================
As mentioned sometime we want to have different tunnels. The tunnels are either
terminating at different places or they use different technology and some flows
are more suited for some tunnels etc...
RFC 2868 allows for specifying more then one tunnel:
If the RADIUS server returns attributes describing multiple tunnels
then the tunnels SHOULD be interpreted by the tunnel initiator as
alternatives and the server SHOULD include an instance of the
Tunnel-Preference Attribute in the set of Attributes pertaining to
each alternative tunnel.
2868 allows us to specify multiple tunnels but only one tunnel is constructed.
We want a different behavior. That is, we want to have multiple of these tunnels
established.
A NAS filter rule that can identify a tunnel would allow us to bind NAS-Filter
rules to tunnels. For example:
tunnel 5 inout from assigned to 123.456.789.0
Means if the rule matches the flow direct that flow to tunnel 5.
RFC 2868 allows us to label tunnels in two ways. If more then one tunnel
specification is in an Access-Accept then each one needs to be tagged with an
id. There are two options for using assigning an id to a tunnel. One is to use
the Tunnel-Preference attribute the other is the Tunnel-Assignment-ID. Reusing
these will break could break functionality and therefore I propose that we
define a new attribute called tunnel-id.
Note that there is a third possibility and that is to use the TAG as an
identifier. The only problem with a TAG is that the TAG is only valid within an
Access-Accept. TAG value may be different in subsequent COA messages.
Backwards compatibility
=======================
How does a NAS know what to do? That is when it sees multiple tunnel
specification in an Access-Accept, what does it do? Does it instantiate one of
the tunnels as per 2868 or does establish multiple tunnels and bind the Filter
rules to them as per this RFC.
One way forward is that if there is at least one NAS-Filter-Rule with an
action of tunnel then all the tunnels are subject to having flow specifiers
(that is are to behave as per this RFC if it is supported).
Note that if we introduce a new attribute such as tunnel-id to the tunnel
specification then we can use that to tell the NAS that the tunnel specification
is a tunnel that interoperates with NAS Filter-Rules.
If we ever got into a situation where both Tunnel type are present, that is
Tunnels bound to NAS-FIlter rule and the 'old' tyle tunnel then, traffic that
matches the rule will be directed to a specified tunnel and all other traffic
will fall into the 'old' style tunnel. This works neatly.
Dynamic Behavior
================
Instructing the NAS to tunnel traffic dynamically is useful. As well to add a
flow to a tunnel or remove a flow from a tunnel dymanically is also useful.
The toughest challange is to install a redirection via tunneling to a flow that
already exists.
Say the Mobile is already established a tunnel to the a destination. We want to
install the tunnel such that the communication is not interrupted between the
Mobile and the destination. That scenario is the same as shown earlier (and
appears below)
Useing a fitler rule:
tunnel x inout from assigned to 123.456.34.0
Mobile NAS TEP DESTINATION
Before COA message: Mobile and Des communicate directly through the NAS
| | | |
|<--------->|<--------|--------->|
| | | |
After COA Message: Tne NAS passed information to the tunnel in both
directions.
x
|---------->|========>|--------->|
| | | |
| +--|<--------|----------|
| | | x | |
| +--|========>|--+ |
| | x | | |
|<----------|<========|--+ |
| | | |
Summary:
========
It is possible with slight modification to achieve redirection both statically
and dynamically using existing technology in the NAS.
This is useful not only for Hotlining but also for other purposes.
With respect to holtining , where we are only interested to know that the user
is invoking a particular service we would just use NAS-Filter-Rule with a action
= tunnel and direction out.
The only issue is that while we can remove the rules etc dynamically by sending
a flush there is no way to remove a tunnel that has been installed dynamically.
This is probably not a problem since once all the rules are removed nothing will
flow through that tunnel. However, it may be possible to state that once the
rules that redirect traffic to a tunnel are removed then the NAS may close the
tunnel.
Also note that this scheme can use L2 and L3 type packets.
Finally, this feature seems to interoperate with the old style tunnels as
defined by 2868.