Subject: [Anima] unsolicited synchronizaiton in draft-yizhou-anima-ip-to-access-control-groups-01.txt

From: Liyizhou <[email-masked]>
Date: Mon, 25 Oct 2021 09:04:04 +0000

Hi all,

The Unsolicited Synchronization message (as defined in section 5.1 in draft-ietf-anima-grasp-distribution) is greatly leveraged in this document to allow the access authentication point to pass IP to Group mapping info to policy enforcement point. 

That would make the information retrieval more efficient compared to request and reply (sync) mode.

I guess a missing part is to a flag to be added to objective-flag, i.e.

      objective-flag = &(
        F_DISC: 0    ; valid for discovery
        F_NEG: 1     ; valid for negotiation
        F_SYNCH: 2   ; valid for synchronization
        F_NEG_DRY: 3 ; negotiation is a dry run
        F_UNSLC_SYNCH: 4 ; this is a missing line to indicate valid for unsolicited synchronization
      )

Looks like the future grasp objectives would require to consider if they are valid for unsolicited synchronization or not. 

Rgds,
Yizhou

---

From: Xun Xiao <[email-masked]>
Date: Tue, 26 Oct 2021 07:12:49 +0000

Hi, ANIMAer,

It sounds reasonable that GRASP messages can be utilized in such a way. Detailed procedures and relevant interactions should be studied accordingly.

BR/Xun

-----Original Message-----
From: Liyizhou 
Sent: Monday, 25 October 2021 11:04
To: [email-masked]
Cc: Xun Xiao <[email-masked]>
Subject: unsolicited synchronizaiton in draft-yizhou-anima-ip-to-access-control-groups-01.txt

Hi all,

      objective-flag = &(

Rgds,
Yizhou

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 26 Oct 2021 22:04:51 +0800

Hi, Yizhou

    I have read the draft, and I think it is good to have a convince way to update the policies in the network.

    Also, I want to share some personal understandings here. If any misunderstandings, please correct me. Thanks.

    The AAPs need to inform the PEPs of the policies of the users by using the GRASP. It can happen when the user logs in, logs out, or triggers some policy changes.

    Maybe the first step is that the PEPs subscribe to the policy changing even that they are interested in.  Do they send some GRASP messages to AAPs here?

    And then, if the user logs in, logs out, or triggers some policy changes, the AAP informs the PEPs that have subscribed. GRASP is used here. Is it a multicast?

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Liyizhou
Date: 2021-10-25 17:04
To: [email-masked]
CC: Xun Xiao
Subject: [Anima] unsolicited synchronizaiton in draft-yizhou-anima-ip-to-access-control-groups-01.txt
Hi all,

 
 
      objective-flag = &(

Rgds,
Yizhou
 
_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Oct 2021 09:54:33 +1300

I want to be very clear that we do not currently have a design for "unsolicited synchronization" in GRASP that works.

https://mailarchive.ietf.org/arch/msg/anima/31UnJbFe45FZF7u_YQHtJLe9Xv8/

Regards
    Brian

On 27-Oct-21 03:04, [email-masked] wrote:
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> [email-masked] <mailto:[email-masked]> & [email-masked]
> 
>     *From:* Liyizhou <mailto:[email-masked]>
>     *Date:* 2021-10-25 17:04
>     *To:* [email-masked] <mailto:[email-masked]>
>     *CC:* Xun Xiao <mailto:[email-masked]>
>     *Subject:* [Anima] unsolicited synchronizaiton in draft-yizhou-anima-ip-to-access-control-groups-01.txt
>     Hi all,
>              F_UNSLC_SYNCH: 4 ; this 
is a missing line to indicate valid for unsolicited synchronization
>            )
>     Looks like the future grasp objectives would require to consider if 
they are valid for unsolicited synchronization or not.

---

From: Liyizhou <[email-masked]>
Date: Wed, 27 Oct 2021 02:18:50 +0000

Hi Zongpeng,

Thanks for your review.

In most of the cases, the number of PEP is very limited, say 2 maybe 3.

So the normal procedure is that AAP discovers the PEP and remembers it in the discovery procedure. ( Maybe a parameter such as "role" can be added to the IPAddressToAccessControlGroups Objective to distinguish their roles. It is missing currently. )

Whenever AAP has some updates (new/delete/updated), it sends the unicast based unsolicited synchronization to PEP. If there are two PEPs , send two unicast respectively.

Whether an PEP will install the received mapping information, that's PEP's choice.

I would like to highlight one thing which was asked in last meeting as well. This defined objective is for distributing the mapping information but not the policy itself. The group based policies should be provisioned upfront at PEPs. So PEP knows what groups would have related policies at its spot.
It can selectively install related mapping information. There could be some waste that AAP sends mapping information to PEP which has no coupled group policy to be enforced at that spot. But that is not a big concern in most cases.

Thanks,
Yizhou

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 26, 2021 10:05 PM
To: Liyizhou <[email-masked]>; [email-masked]
Cc: Xun Xiao <[email-masked]>
Subject: Re: [Anima] unsolicited synchronizaiton in draft-yizhou-anima-ip-to-access-control-groups-01.txt

Hi, Yizhou

Best Regards
Zongpeng Du

________________________________
[email-masked]<mailto:[email-masked]> & [email-masked]<mailto:[email-masked]>

From: Liyizhou<mailto:[email-masked]>
Date: 2021-10-25 17:04
To: [email-masked]<mailto:[email-masked]>
CC: Xun Xiao<mailto:[email-masked]>
Subject: [Anima] unsolicited synchronizaiton in draft-yizhou-anima-ip-to-access-control-groups-01.txt
Hi all,

      objective-flag = &(

Rgds,
Yizhou

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

---

From: Liyizhou <[email-masked]>
Date: Wed, 27 Oct 2021 02:27:59 +0000

Hi Brian,

I do not really intended to use a generic pub/sub mechanism, though it would work if it is there.

I explained a little bit more in the email to Zongpeng that how it works with unsolicited synchronization without pub/sub objectives.

If I understand your previous email correctly, you talked about pub/sub functionalities to be implemented with (unsolicited synchronization msg + pub/sub objectives) are not ready to be used right now.

I kind of think the co-authors of that draft will be keeping working on pub/sub functions.

But at the same time, even without a full functional pub/sub, a unicast unsolicited sync would be still useful in distributing the mapping info. 

The number of PEP is very limited and the purpose is not to disseminate the policies themselves but to inform the group mapping information. PEP can selectively use those mapping information based on the group based policies provisioned upfront. 

Or did I misunderstand the relationship of pub/sub and unsolicited sync proposed in another draft?

Thanks,
Yizhou

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, October 27, 2021 4:55 AM
To: [email-masked]; Liyizhou <[email-masked]>; [email-masked]
Cc: Xun Xiao <[email-masked]>
Subject: Re: [Anima] unsolicited synchronizaiton in draft-yizhou-anima-ip-to-access-control-groups-01.txt

Regards
    Brian

On 27-Oct-21 03:04, [email-masked] wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ---------- [email-masked] <mailto:[email-masked]> & 
> [email-masked]
> 
>     The Unsolicited Synchronization message (as defined in section 5.1 
> in draft-ietf-anima-grasp-distribution) is greatly leveraged in this 
> document to allow the access authentication point to pass IP to Group 
> mapping
info to policy enforcement point.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Oct 2021 16:07:30 +1300

> unicast unsolicited sync would be still useful in distributing the mapping info. 

I understand the requirement, my comment is simply that this is undefined.

GRASP synch is a discover/request/response/close sequence. As I understand
unsolicited synch, it is discover/request/response...response...response...
That means keeping a TCP connection open indefinitely, and keeping
corresponding connection state at each end indefinitely.

Alternatively, it would mean designing a way to use UDP unicast for
this, but there must still be state at both ends, indefinitely.
I never wanted to make GRASP synch or negotiation use UDP, because
each time I tried to design an implementation, I found that I had to
create state at both ends to make the UDP session work properly - in
effect, much of the work that TCP does anyway. So I think the way to
implement unsolicited synch is probably to use TCP.

Regards
    Brian

On 27-Oct-21 15:27, Liyizhou wrote:
> If I understand your previous email correctly, you talked about pub/sub 
functionalities to be implemented with (unsolicited synchronization msg + 
pub/sub objectives) are not ready to be used right now.
> But at the same time, even without a full functional pub/sub, a unicast 
unsolicited sync would be still useful in distributing the mapping info.
> 
> The number of PEP is very limited and the purpose is not to disseminate 
the policies themselves but to inform the group mapping information. PEP can selectively use those mapping information based on the group based policies provisioned upfront.

---

From: Liyizhou <[email-masked]>
Date: Fri, 29 Oct 2021 01:19:40 +0000

Hi Brian,

I gave a second thoughts on using the unsolicited sync.

I agree with your TCP/UDP comments. So I think the conveying message of mapping info can be changed to rapid mode of discovery instead. 
That's efficient and simple. And also removes the requirement of state maintenance.

I am also thinking to add a "role" parameter to distinguish the info provider and consumer. 

Hope that works.

Thanks,
Yizhou

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, October 28, 2021 11:08 AM
To: Liyizhou <[email-masked]>; [email-masked]; [email-masked]
Cc: Xun Xiao <[email-masked]>
Subject: Re: [Anima] unsolicited synchronizaiton in draft-yizhou-anima-ip-to-access-control-groups-01.txt

GRASP synch is a discover/request/response/close sequence. As I understand unsolicited synch, it is discover/request/response...response...response...
That means keeping a TCP connection open indefinitely, and keeping corresponding connection state at each end indefinitely.

Alternatively, it would mean designing a way to use UDP unicast for this, but there must still be state at both ends, indefinitely.
I never wanted to make GRASP synch or negotiation use UDP, because each time I tried to design an implementation, I found that I had to create state at both ends to make the UDP session work properly - in effect, much of the work that TCP does anyway. So I think the way to implement unsolicited synch is probably to use TCP.

Regards
    Brian

> If I understand your previous email correctly, you talked about 
functionalities to be implemented with (unsolicited synchronization msg + pub/sub objectives) are not ready to be used right now.
> 
> I kind of think the co-authors of that draft will be keeping working 
> on
pub/sub functions.
> 
> Or did I misunderstand the relationship of pub/sub and unsolicited 
> sync
proposed in another draft?
> Subject: Re: [Anima] unsolicited synchronizaiton in 
> draft-yizhou-anima-ip-to-access-control-groups-01.txt
> 
>>      The Unsolicited Synchronization message (as defined in section 
>> 5.1 in draft-ietf-anima-grasp-distribution) is greatly leveraged in 
>> this document to allow the access authentication point to pass IP to 
>> Group mapping
>>      That would make the information retrieval more efficient 
>> compared
to request and reply (sync) mode.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2021 15:47:48 +1300

On 29-Oct-21 14:19, Liyizhou wrote:
> I agree with your TCP/UDP comments. So I think the conveying message of 
mapping info can be changed to rapid mode of discovery instead.
> I am also thinking to add a "role" parameter to distinguish the info provider and consumer.

Good idea. I like Toerless's idea of using a JSON-like dictionary for complicated objectives, since it makes it very easy to add features like "role". I used that idea in draft-carpenter-anima-grasp-config-00 and when you understand it, it is quite powerful. (It's very natural to use in "modern" programming languages, but a bit tricky in plain C.)

    Brian

> I never wanted to make GRASP synch or negotiation use UDP, because each 
time I tried to design an implementation, I found that I had to create state at both ends to make the UDP session work properly - in effect, much of the work that TCP does anyway. So I think the way to implement unsolicited synch is probably to use TCP.
> functionalities to be implemented with (unsolicited synchronization msg 
+ pub/sub objectives) are not ready to be used right now.