Re: [Anima] a new anima draft on grasp objective ip to group mapping

[Liyizhou <[e-mail]>]

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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide