On 12 Mar 2009, at 10:24, Pekka Savola wrote:
On Thu, 12 Mar 2009, RJ Atkinson wrote:
A single UDP/IP session (one example is ONC RPC, but that is
not the only example) between a pair of nodes might have
different packets with different Sensitivity Labels. This
is also described in the draft.
I took one of Lars' concerns as having essentially multiple different
sessions (with different labels) under a single session as being a
problematic. I don't see why such approach is needed and this is the
right place to handle this, and even done like this, why this could
not be solved using other approaches (e.g. destination option).
I accept that you don't see it.
None the less, this problem has been studied for over 2 decades,
without any better approach being proposed. There is also about
2 decades of deployed operational experience that the approach
proposed here works well, AND that it does not cause problems
operationally or for implementations.
Have you either used or implemented an MLS system ever ?
How familiar are you with MLS concepts ?
MLS is an odd universe, to be sure, but it has long-standing,
and (slightly) growing deployments in many different countries,
by many different organisations, on most continents of the globe.
In the special case where a node or link is not MLS, then the edge
router facing that non-MLS link inserts/removes the labels on behalf
of those (typically MS Windows) systems -- as described in the
document.
This breaks RFC 2460's assumption that boxes in the middle don't add
or remove options or headers.
A device that inserts/strips this unique option is a router,
in that it forwards IP packets. However, it is also a highly
trusted device that is a kind of security gateway.
There is ample precedent, both in IPv4 MLS deployments and in
the deployed non-MLS global IPv4 and IPv6 Internet, for security
gateways to modify packets in transit under certain circumstances,
including modifying header bits and options.
Problems caused by this are both
architectural and technical;
You have identified several areas where you are concerned.
You have not yet demonstrated that any real problems exist.
Further, you haven't bothered to try to refute my several
comments that we have 2 decades of experience with this
type of option showing that it does work well, and does NOT
have problems (operational, architectural, or implementation).
one technical issue not (AFAICS) addressed in the text happens
if the packet size would exceed MTU when the option is added.
If you have proposed text, I am happy to make reasonable
clarifying edits.
L3 VPNs simply aren't, and never have been, an ACL mechanism
for drop/no-drop decisions on a per-packet basis.
Access lists and various other access control mechanisms have been
applied in almost every conceivable place in the architecture,
however.
Which does not contradict my statement that L3 VPNs simply are
not an ACL mechanism and that L3 VPNs are not a solution.
I'd really suggest you go chat off-list with the Routing ADs
about this. They are likely much more eloquent than I am.
If the label were a destination option, then routers would
be incapable of applying ACL rules (drop or not drop) based
on this option, and could not enable non-MLS end systems
to participate in the MLS deployment.
Not true. Routers can have code that examines the content of the
destination options of a packet. I have a recollection that there are
multiple implementations already capable of doing that.
I've talked with several IPv6 router vendors, who disagree with
your claim above, and further point to RFCs saying that routers
ought not examine any Destination Options on transit packets.
The several vendors that I've talked with have implementations
that can only look at Hop-by-Hop options, and some of those either
have already -- or are planning to add -- configuration options
to ignore all hop-by-hop options as well for transit packets.
(Frankly, I think having that particular configuration knob
makes a lot of sense, regardless of this proposal, just as having
an implementation that ignores all Destination Options on transit
packets makes sense.)
Just to apply ACL rules, hop-by-hop option is not necessary, though
from some perspective, it may be the simplest approach.
That is not consistent with what several vendors with shipping
IPv6 routers have said.
THe reasons a router wants to look at this option are:
1) to decide whether to drop the packet rather than forward it
out some interface or accept it in from some interface. This
is also described in the document. [Cisco even has some
documentation on this if one grep's for RFC-1108 in their IOS
manuals.]
Again, regular ACLs inspecting content are able to do that.
Your assertion is opposite to what I am told by several IPv6
router vendors with shipping products and deployments.
I'm the original author of Cisco's IPv6 code for router IOS.
I'm sure it has evolved since (and I hope they've fixed my
bugs by now), but I do have experience building IPv6 routers.
So far, I've worked on 4 different IPv6 implementations for
forwarding IPv6 packets (Net/2 BSD, 4.4 BSD, Cisco IOS, Extreme).
(I think that I'm tied with Margaret W for having worked on
the largest number of separate implementations.)
So I'm speaking from actual implementation experience here.
2) to decide whether to insert/remove a label from a packet,
in the special case of packets from/to a non-labelled link,
as described in the draft.
This has issued mentioned above, but even if it is true, equally
possible would be to do that insertion with dst options or some other
marking.
Agree that insertion/deletion of one option is functionally
equivalent to another -- of either flavour. That doesn't
address any of the reasons I have outlined why this really
does need to be a hop-by-hop option.
I also note that you deleted (without responding to) my
observations that we have 2 decades of operational experience
proving that a hop-by-hop semantic is NOT problematic for this
unique type of IP option. I gather that means you either
agree with my statement, or have no contrary evidence to hand.
To be honest, I think that sra's generic comment of a day or two
ago (about the current set of "concerns" about this option being
misplaced given the IPv6 protocol history) was pretty on the mark.
The effective choice in front of the WG is whether to block
deployment of IPv6 MLS networks -- and force various governments
to keep expanding their IPv6 deployments instead. I'd suggest
that is NOT in the best interest of the IPv6 community, or in
the best interest of the IETF.
Yours,
Ran
r...@extremenetworks.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
