Hi Michael,
Thank you for your posting. Please see inlines with [yz] for some thoughts..
[snipped]
I was surprised by figure 1, that the PEP would be in the core.
It seems to me that doing PEP at the WiFi AP1 would scale much better.
Or, if wired, then at the access switches.
Maybe the issue is that accX and APX are effectively Layer-2 only devices?
If so, then it's probably worth stating that.
[yz] Yes, more text could be added to make it clearer. There are some variants.
One possibility is as what you mentioned it is a L2 network. Also, in some
small network, traffic is forced to pass through the core node (tree-root) so
PEP is placed there for simplicity. Then every AAP would only inform a single
PEP. Figure 1 tried to elaborate this simplest case.
I also thought that in the age of SDN-everything (I remain somewhat cynical
about SDN), that the engineering laptop would get placed into the engineering
VIP-VLAN, and thus the L2 would be the same, and so the problem of addressing
goes away.
{ In your example, btw, to make the situation more understandable, the engineer
should be having a meeting with the sales department, in their board room, and
the engineer needs access to the engineering file server :-) }
[yz] That sounds like a vivid example. Will try to use it when updating.
Figure 2 is very nice. I would drop the "SSL" from the VPN, because really, it
could be any kind of VPN. IPsec, Wireguard, OpenVPN, etc. right?
[yz] Right, SSL is one of the examples. Will drop it in next version.
} When a PEP receives a data packet, it queries the
} controller for the group IDs of the source and/or destination IP
} addresses and then enforce the group based policy. This approach }
requires an explicit controller able to talk to each and every AAP } and PEP.
looking up policy at each data packet is pretty unusual in my experience.
Many designers attempt this on their first design, and then learn that it's
hard to scale and very vulnerable to denial of service attack.
For higher QoS ("VIP") sometimes it is done asynchronously: when a new
"NetFlow" is detected by the control plane a lookup is done, and then the flow
is assigned the new QoS after it has already started. For forbidden
destinations, it's hard to get right.
So I'm asking: do you really have an architecture like this, where you look
things up on-demand?
[yz] The policy is provisioned in advance. The lookup is to fetch the group id
based on ip but not to download the policy rule. So it is only done once for
the first unknown packet. It is normally used as a complementary mechanism to
pre-fetching ip to group mapping info to PEP when the cache is missing/expired.
So grasp based mechanism should be also helpful in this pre-fetching phase
other than the last-resort lookup stage. I guess this point should be covered
as well in text.
} Autonomic Networking (AN) puts the intelligence at the node level, to
} minimize dependency on human administrators and central management
} such as a controller.
I'm not sure that this is an accurate characterization of AN.
AN certainly can facilitating distributing intelligence, but I wouldn't say
that AN mandates it.
[yz] I would like to re-phrase it as " Autonomic Networking (AN) can facilitate
putting the intelligence at the node level...."
In section 4.1, you dance around the question about whether source IP addresses
are unique enough to be mapped to users/groups. IPv4 sources likely are not,
and will always require some kind of provider domain mapping to go along with
them. IPv6 could go either way in the end: architects of campus IPv6 networks
would be advised to always fold the provider domain info into the IPv6 prefix.
(It's an argument for running an IPv6-only campus network actually)
you may find that the terminology from:
https://datatracker.ietf.org/wg/mif/documents/
RFC7556
_Provisioning Domain_ useful here. MIF otherwise is about the problem from the
end-node point of view, not the network point of view!
Section 4.1 suggests, but does not yet say, that PEPs might answer queries from
other PEPs for which they happen to have cached a result. Section 4.2
paragraph two, begins to say that. Perhaps this concept, that the PEPs help
each other belongs in the annotation to figure 1?
[yz] I did not expect PEPs help each other in request/reply mode. When
flooding, it is true that multiple PEPs get the same set of information. If
PEPs can help each other, that is something requiring a little more
considerations like inconsistent entry from different PEP, trustship etc.
Currently AAP is the owner of a particular mapping information.
okay, so in 5.1, you get to the IP prefix encoding.
I think that yes, you ought to use the
draft-richardson-cbor-network-addresses format here.
You are sending a single address, and there is no point in sending the bits of
the prefix which are irrelevant, and you need a way to distinguish between
IPv4 and IPv6 in the same spot.
[yz] I have used the ietf- cbor-network-addresses format.
Your security considerations will need to address how the PEPs can trust each
other, what the impact of a compromise of a PEP's cache, and how, if there are
no caches of policy information, what the impact of the longer latency to the
authoritative source of information is.
There is also the question of what happens when policy cache is full, and some
entries are expunged.
[yz] Will try to address in next version. I guess the first question would be
whether PEPs helping each other should be allowed or only AAP-PEP communication
should be allowed. Current document allows the latter only.
BUT, overall, I think that this is actually a really good document, and a
really interesting ASA, thank you for posting it to the DT.
Thank you,
Yizhou
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
