Re: [Anima] Discussion regarding draft-dang-anima-network-service-auto-deployment

[Brian E Carpenter <[e-mail]>]

Hi Yujing,

> [yj] I think use an extra(virtual) domain like the attached diagram is a good idea to solve the problem about different domain ASAs communication. But as you say, there are some security issues we should discuss in more detail. So do you know which draft can involves this problem?


It's really not a network security problem, is it? If we have a secure network (such as the ACP) and a software component on the boundary (such as 
an ASA that also communicates with the outside world), we have a security 
risk that the network itself cannot block.

Actually this is a point we should mention in the Security Considerations 
of draft-ietf-anima-asa-guidelines. That will need an extension to the first paragraph at https://www.ietf.org/archive/id/draft-ietf-anima-asa-guidelines-02.html#section-11-1 .

Regards
    Brian

On 29-Oct-21 20:35, zhouyujing (A) wrote:
> Hi Brian,
> 	
> 	Thanks for your reply, allowing me to think about my draft more clearly.
> 
> 	Please see inlines with [yj]. Thanks.
> 
> Best Regards
> Yujing Zhou
> 
> -----Original Message-----
> From: Brian E Carpenter <[e-mail]>
> Sent: 2021年10月29日 11:31
> To: zhouyujing (A) <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [Anima] Discussion regarding draft-dang-anima-network-service-auto-deployment
> 
> Hi Yujing,
> On 28-Oct-21 20:18, zhouyujing (A) wrote:
>> Hi Brian,
>>
>> 	I am very grateful for the GRASP tutorial that you gave me. It solved 
a lot of my misunderstandings.
>>
>> 	According your suggestion, I think a GRASP flood is sufficient. The
>> object data we design in the draft is not very large. I think 2kB is
>> enough
> and it will not be sent very frequently. I will add this part in the new version.
>>
>> 	I have some confusion about GRASP and hope you help me. RFC8990 defined GRASP does not currently support selective distribution when they use GRASP flooding message. But in my draft, SI and APE are kind of ASA, when 
the negotiation process are succeed, APE should send message to other ASAs in the network not include SI. How can we deal this situation?
> 
> Do you mean to *all* ASAs? In that case you can use a flood again. Of course, a receiver can simply ignore a flood. If that is not sutiable, please explain the requirement a bit more.
> 
> [yj] According to our previous discussion, I think the problem in our draft is that ASAs need to communicate with another domain ASA instead of selectively sending message to some ASA nodes in the domain. So we should 
send to *all ASAs in the domain. In that case reuse a GRASP flood message 
is OK. But I think how the different domain ASAs communicate with other is not suitable for discuss in draft-dang-anima-network-service-auto-deployment.
> 
> 
>> 	Furthermore, If the negotiated ASA belong to different domain, will
>> the GRASP flooding message of one ASA be sent to the other ASA which
>> is not
> in a same domain? Do we need to make some mechanisms to prevent flooding message spreading to other domains?
> 
> 
> We did not specify what happens if two separate ACPs overlap physically. What happens then is undefined. Normally a flood will never reach an ASA in a different domain, because the ACP only includes nodes that have correctly authenticated themselves to the current domain.
> 
> If ASAs need to communicate with another domain, it would need to be like the attached diagram, possibly with an extra (virtual?) domain to separate the two security environments. The boundary ASAs would have two halves, one in each domain. Obviously, there would be security issues there.
> 
> [yj] I think use an extra(virtual) domain like the attached diagram is a good idea to solve the problem about different domain ASAs communication. But as you say, there are some security issues we should discuss in more detail. So do you know which draft can involves this problem?
> 
> Regards
>      Brian
> 
> 
>> 	
>> Best Regards
>> Yujing Zhou
>>
>> -----Original Message-----
>> From: Brian E Carpenter <[e-mail]>
>> Sent: 2021年10月28日 10:54
>> To: zhouyujing (A) <[e-mail]>; [e-mail];
>> [e-mail]
>> Subject: Re: [Anima] Discussion regarding
>> draft-dang-anima-network-service-auto-deployment
>>
>> How big is the data likely to be, and what is the approximate rate of refreshes?
>>
>> If these values are low (e.g. 2 kB data once per minute), a GRASP
>> flood
> would be sufficient.
>>
>> If you want an acknowledgment, a flood is not suitable. GRASP synch is
>> acknowledged implicitly by TCP. If you want any information beyond "I
>> got
> it" you need GRASP negotiation (only one step of negotiation in each direction).
>>
>> I put some logic flows in the GRASP tutorial that should explain this.
>> https://tinyurl.com/Gtut2021
>>
>> Regards
>>       Brian
>>
>> On 28-Oct-21 15:01, zhouyujing (A) wrote:
>>> Hi, Zongpeng
>>>
>>>                    I prefer the second method, because I think
>>> distributed is a feature of ASA. So an ASA should synchronize the
>>> information it
> receives to other ASAs. But I'm not sure that it is necessary for other 
ASAs need response this synchronization message. Whether to send a flooding message is OK?
>>>
>>>                    In my think, this draft pay attention to the negotiation between SI to APE. And how to reservate resource hop-by-hop is not we discuss in this draft.
>>>
>>> Best Regards
>>>
>>> Yujing Zhou
>>>
>>> *From:* [e-mail] <[e-mail]>
>>> *Sent:* 2021年10月26日 23:31
>>> *To:* zhouyujing (A) <[e-mail]>; [e-mail]
>>> *Subject:* Re: [Anima] Discussion regarding
>>> draft-dang-anima-network-service-auto-deployment
>>>
>>> Hi, Yujing
>>>
>>>        Some personal understandings are listed here. If any misunderstandings, please correct me. Thanks.
>>>
>>>
>>>        Just like the two mechanisms existed, we can use a hop-by-hop method or a centralized method.
>>>
>>>
>>>        The first method looks like the RSVP-TE. The APE can send a "PATH" message including the whole path. Whenever an intermediate node can not provide the resource, the auto deployment is failed and some errors are reported.
>>>        The DPE needs to respond a "RESV" message.
>>>
>>>
>>>        The second method looks like the PCE-CC. The APE sends a request message to each node on the path. Only if all the responses are ok, the auto deployment succeeds.
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Zongpeng Du
>>>
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> ------------------------
>>>
>>> [e-mail] <mailto:[e-mail]> &
>>> [e-mail] <mailto:[e-mail]>
>>>
>>>       *From:*zhouyujing (A) <mailto:[e-mail]>
>>>
>>>       *Date:* 2021-10-21 14:31
>>>
>>>       *To:*[e-mail] <mailto:[e-mail]>
>>>
>>>       *Subject:* [Anima] Discussion regarding
>>> draft-dang-anima-network-service-auto-deployment
>>>
>>>       Hi,
>>>
>>>       Our discussion in the previous mailing list basically focused on
>>> the definition of GRASP and we modified the objective based on the
>>> feedback. The related draft is listed in
>>> https://datatracker.ietf.org/doc/draft-dang-anima-network-service-aut
>>> o-deployment/
>>> <https://datatracker.ietf.org/doc/draft-dang-anima-network-service-au
>>> to-deployment/>
>>>
>>>       The draft want to build a general solution for resource-based
>>> network services auto-deployment. So I think is a useful work for
>>> ANIMA. But
> in the draft, I'm not sure some questions about process part and hope to get your help.
>>>
>>>       * If the SI accepting the negotiation, APE will receive this message. How can APE tell other ASAs to remove the acceptable resource from 
there resource pool? It is enough to re-use GRASP Flooding message.
>>>
>>>       * When the SI and APE is negotiating the resource, should APE
>>> need to tell other ASAs reserve this resource? If two SIs request
>>> resources at
>> the same time, this may cause a conflict.
>>>
>>>       * Is it necessary to establish an auto-deployment mechanism to release or increase resources when the SI change its need?
>>>
>>>       For the above question, I want to start a discussion to help the draft more clarified about this part. So I specially write this email.
>>>
>>>       I hope to listen your opinions, and am looking forward to your reply.
>>>
>>>       Best wishes,
>>>
>>>       Yujing
>>>
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>