[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Issue 102: NAS/QoS Filter Rule
[pc] Comments on Pasi's issue 102...
1) Section 3.5 is currently quite difficult to follow since it mixes L2,
IP, tunneling and HTTP redirect rules... It's not always even clear when
some element is just a name for a rule (like "ipno") and when it's a
literal string (like "from").
So some editing work is needed here. Maybe describing the L2, IP
filtering, IP tunneling and HTTP rules one-by-one (instead of mixing
their descriptions) would make this more understandable.
(The IPFilterRule description in RFC3588 isn't nearly as complicated as
this, since it doesn't have the L2, tunneling or HTTP rules.)
[pc] ok, assuming the rest of the discussion addresses this first point.
2) Or would using ABNF be of any help? Here's a first sketch (probably
buggy..)
rule = flush-rule /
l2-filter-rule /
ip-filter-rule /
ip-tunnel-rule /
http-redirect-rule
flush-rule = "flush"
l2-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " l2-filter [" Cnt"]
l2-filter = l2-proto " from " l2-address " to " l2-address
l2-filter =/ l2-rmon-str
l2-proto = "l2:ether2" [":0x" 1*4HEXDIG]
l2-rmon-str = "l2:" 1*DIGIT *("." 1*DIGIT)
l2-address = ["!"] (macaddr / (macaddr "/" mask) / "any")
macaddr = 2HEXDIG 5("-" 2HEXDIG)
mask = 1*2DIGIT
ip-filter-rule = ("permit" / "deny") " " ("in" / "out" / "inout")
" " ip-filter
ip-filter = ("ip" / ip-proto)
" from " ip-address [" " ip-ports]
" to " ip-address [" " ip-ports]
*(" " ip-option)
ip-proto = 1*3DIGIT
ip-address = ["!"] (ipv4-address ["/" bits] /
ipv6-address ["/" bits] /
"any" /
"assigned")
ipv4-address = 1*3DIGIT 3("." 1*3DIGIT)
ipv6-address = ;; TODO
bits = 1*3DIGIT
ip-ports = ip-port *("," ip-port)
ip-port = 1*5DIGIT / (1*5DIGIT "-" 1*5DIGIT)
ip-option = "Cnt"
ip-option = "frag"
ip-option =/ "ipoptions " ["!"] ipopt *("," ["!"] ipopt)
ip-option =/ "tcpoptions " ["!"] tcpopt *("," ["!"] tcpopt)
ip-option =/ "established"
ip-option =/ "setup"
ip-option =/ "tcpflags " ["!"] tcpflag *("," ["!"] tcpflag)
ip-option =/ "icmptypes " icmptype *("," icmptype)
ipopt = "ssrr" / "lsrr" / "rr" / "ts"
tcpopt = "mss" / "window" / "sack" / "ts" / "cc"
tcpflag = "fin" / "syn" / "rst" / "psh" / "ack" / "urg"
icmptype = 1*3DIGIT
icmptype =/ 1*3DIGIT "-" 1*3DIGIT
icmptype =/ ;; TODO (names)
ip-tunnel-rule = "tunnel " tunnel-id " in " ip-filter
tunnel-id = ;; TODO
http-redirect-rule = "redirect " [redir-cnt " "]
redir-url " in " ip-filter
redir-cnt = 1*DIGIT
redir-url = ;; TODO
(Ok, maybe this is not so clear either... but at least it's unambiguous
when something is just a rule name and when it's a literal string )
[pc] We can insert this if we can complete the TODO parts above. Do we
insert it before the current description or completely replace what is
there with just the ABNF? I'm assuming this would be inserted in front
of the current descriptions and we would leave the existing text with
fixes discussed below. Can you help complete the TODOs or provide a
good reference guide on ABNF somewhere?
3) Example of "macaddr/mask": The example should use some other width
than /24 to make it clearer how the counting works. Also, the example
given is an invalid one, since it does not meet the "The MAC address
MUST NOT have bits set beyond the mask"
requirement. Suggested change: use 00-10-A4-23-00-00/32 as the example.
[pc] accept suggestion
4) Description of "ipno/bits" says "the IP number MUST NOT have bits set
beyond the mask", but the example given, "1.2.3.4/24", does not follow
this. Suggested change: use 192.0.2.0/24 as the example.
[pc] accept suggestion, maybe change the first 0 to something else to
further disambiguate.
5) Description of tunnel_id: according to RFC 2868, there are no
restrictions on the format of the Tunnel-Assignment-ID.
Currently it's not clear if the NAS-Filter-Rule syntax supports
correctly parsing arbitrary IDs (what happens if the ID includes spaces,
for instance?)
[pc] Good observation. This needs fixing. Seems like we have two
choices; put restrictions on the usage of Tunnel-Assignment-ID so that
the strings are parse-able (not really a good idea), or encapsulate the
string in quotes when used in the rule. Since there are no restrictions
on the format of the string used in Tunnel-Assignment-ID we MUST provide
a way to parse it as a single element in the entire attribute string.
Of course, the Tunnel-Assignment-ID could itself contain quotes, so we
will also need to describe some escaping function before including them
in the rule. The escaping function would be: For all occurrence of "
replace with \" and for all occurrence of \ replace with \\. While this
is a little ugly, I think it is the only course of action.
6) Near the end of Section 3.5: The "concise syntax statements"
don't exactly match the definitions earlier. I catched at least these:
- IP rule is missing "[ports]" before "to"
- IP rule is missing "|" after "redirect"
- HTTP redirect rule is missing the "proto" part after the direction
- HTTP redirect rule does not have "[ports]"
[pc] agreed, fix these and double check the rest..
7) The document does not seem to describe what HTTP filter rules are or
how they work (HTTP redirect rules are explained, but not HTTP filter
rules).
[pc] There really aren't specific HTTP filter rules per-se. We don't
filter based upon HTTP content, but it is possible to filter all HTTP
traffic using normal IP filter rules. The text is a little unclear at
the end of the section that indicates there are 'redirect' and 'filter'
rules. Seems like we need to discuss redirect rules separately from
filter rules. There are really two types of redirect rules; tunnel and
http, and two filter rules; L2 and IP.
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.
9) Currently the text says "A flush rule MUST appear before all other
rule types." I first read this to mean that a flush rule must always be
present, but I guess that was not what was meant. Furthermore, it's not
easy to parse the ordering requirements.
Suggested change: Rewrite that paragraph to "Furthermore, if the list
contains different types of rules, they MUST appear in the following
order: flush rules, base encapsulation filter rules, IP tunnel rules,
HTTP redirect rules, IP filter rules, and HTTP filter rules."
[pc] Agreed. This is better than my suggestion to change this part of
the text to, "Base encapsulation filter rules MUST appear after a flush
rule (if present) and before IP tunnel,..."
10) The document should explain why different types of rules must be
given in exactly that order. Placing L2 rules before IP is
understandable, but for some of the other cases it's not totally obvious
why other orderings need to be forbidden.
[pc] We had considerable discussion about this early on in the document
development. If my memory serves me correctly, we decided upon this
order to maximize interoperability and to address the fact that it
didn't make sense to filter out packets before putting them into the
tunnel. Perhaps others can recall more detail - sorry.
11) The document should have some examples of NAS filter rules,
preferably showing most of the different features at least once.
[pc] agreed.
12) The document should somewhere describe the differences to Diameter's
NAS-Filter-Rule syntax.
[pc] agreed this relates to Bernard's comment as well. Text to be
developed.
13) If the NAS just concatenates all the NAS-Filter-Rule (or
QoS-Filter-Rule) attributes together to overcome the 255-byte attribute
length limit, then boundaries between individual rules are lost. This is
not necessarily a big problem, as it looks like the syntax can be
unambiguously parsed anyway, but should be mentioned explicitly
(alternatively, we could delimit the individual rules somehow).
[pc] yes, this should not be a problem and implementations will split
the string in different ways, but if they are following the rules of
fragmentation and reassembly properly there is no issue. We really
don't need to say anything here as this is part of standard attribute
parsing. No action proposed.
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.