RE: Issue 102: NAS/QoS Filter Rule

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

The following additional text to the Appendix is proposed to satisfy
Pasi's issue around tunneling clarity.  This text inserts nicely into
the existing Appendix A.  In less we hear otherwise, the following text
will be inserted as is.

Paul


A.1.4 Tunnel Redirection Examples

The following examples illustrate how traffic flows when subjected to a
NAS-Filter-Rule using tunnel redirection.  In these scenarios, the
following notation is used to represent traffic flows:

------>  Flow in one direction
<----->  Flow in two directions
======>  Flow in a tunnel in one direction <=====>  and in both
directions


A RADIUS server that wishes all traffic to flow between the client and a
selected redirection destination will issue an Access-Accept that
contains the specification for the tunnel using the attributes defined
by RFC 2868 and an NAS-Filter-Rule attribute using the tunnel action and
arguments.

An example NAS-Filter-Rule will look like:

tunnel "t1" in from assigned to any

This will cause all traffic that flows from the client to any
destination to be tunneled over the named tunnel "t1" to the tunnel
endpoint (TEP).

   +-------+            +------+         +------+       +------+
   |       |            |      |         |Tunnel|       |      |
   |client +<---------->+ NAS  +<==t1===>+ End  +<----->+ Dest |
   |       |            |      |         |Point |       |      |
   +-------+            +------+         +------+       +------+

The direction argument takes the values of "in", "out" or "inout" and is
important because it controls how information is routed. The following
diagram demonstrates how traffic is routed. In all these diagrams time
is increasing as we proceed down the page.

When rule direction is "in":

   client       NAS       TEP    DESTINATION
     |           |         |          |
     |---------->|===t1===>|--------->|
     |           |         |          |
     |<----------|<-------------------|  (flows directly to NAS)
     |           |         |          |
     
The inbound traffic from the client matches the specified filter rule
and the IP packet is placed in the tunnel to the TEP. The TEP forwards
the packet to the Destination using the destination IP address in the
packet header. Note that the source address of the packet is the address
assigned at the NAS. Therefore if the destination were to reply to the
packet it would use the NAS source address and the packet would flow
directly to the NAS and to the client bypassing the TEP.  The Home
network would use this capability if it was only interested in metering
or seeing the inbound traffic from the client.

However, if the home network wanted to see the traffic in both
directions it could deploy a NAT function at the TEP.

Here is the flow when the TEP is acting like a NAT: 

   client       NAS       TEP/NAT DESTINATION
     |           |         |          |
     |---------->|===t1===>|--------->|
     |           |         |          |
     |<----------|<==t1====|<---------|


The client establishes a connection to the Destination, but the TEP
acting as NAT, changes the source address of the IP packet(as NATs do)
to that of the TEP/NAT.  Now any replies from the Destination are sent
to the TEP/NAT.  The TEP/NAT then forwards these packets to the client
through the NAS.

When the TEP is acting as a NAT, using the direction argument "in" is
important.
The direction argument set to "out" will have no effect on traffic
coming from the tunnel since all traffic to the client should come from
the TEP/NAT inside the tunnel.  The direction argument set to "inout"
will have the same effect as if it were set to "in".

The TEP/NAT forwards all traffic for the client into the tunnel to the
NAS.
The NAS always forwards any egressing traffic from the tunnel to the
client.
It does not apply any redirection rules on traffic egressing a tunnel.
The NAS does not care whether the TEP is transparent or is acting as a
NAT. 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of 
> Pasi.Eronen@nokia.com
> Sent: Tuesday, November 22, 2005 12:24 AM
> To: Sanchez, Mauricio (PNB Roseville); radiusext@ops.ietf.org
> Subject: RE: Issue 102: NAS/QoS Filter Rule
> 
> Mauricio Sanchez wrote:
> > 
> > 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?
> 
> The most useful part of Avi's document to me was the section 
> titled "Directing flows to a single tunnel". Perhaps adding 
> an appendix containing roughly that material would be sufficient?
> 
> Best regards,
> Pasi
> 
> --
> to unsubscribe send a message to 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>