WRT: https://datatracker.ietf.org/doc/draft-yizhou-anima-ip-to-access-control-groups/
Liyizhou <[email protected]> wrote: > Dr. Brian Carpenter mentioned you have a draft > draft-ietf-cbor-network-addresses to generally support addresses and > prefixes in CBOR. We used a different format in our draft from CDDL at > https://www.rfc-editor.org/rfc/rfc8992.html#section-5.2 to represent > the prefix/address. Do you have any thoughts on the best way for > representations? I'll need to read your draft, it may be that you've picked the best thing, but the entire encoding is probably arbitrary. More common representation means more support from libraries. > We are planning to submit the draft for IETF111 after reviews by key > contributors of anima wg. That's a very academic way to do things, but not the IETF way. Never show things until they are done. But, you will get better acceptance if you post the document *NOW*, and then reviews occur on the ML. > draft-yizhou-anima-ip-to-access-control-groups-00-0625.txt --- > text/plain; > draft-yizhou-anima-ip-to-access-control-groups-00-0625.txt]... 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. 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 :-) } 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? } 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? } 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. 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? 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. 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. 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. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
