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

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Jun 2021 11:57:15 -0400

WRT: https://datatracker.ietf.org/doc/draft-yizhou-anima-ip-to-access-control-groups/

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

---

From: Liyizhou <[email-masked]>
Date: Tue, 29 Jun 2021 11:42:14 +0000

Hi Michael,

Thank you for your posting. Please see inlines with [yz] for some thoughts..

[snipped]

[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.

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.

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)

_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.  

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