Hi Stewart,

Thanks for all the comments. They are great suggestions and inputs to improve 
this idea.
Multi-semantics could be a large topic for separate drafts, indeed, and it is 
what we intended.
As now, we are updating a “problem statement” draft for it, and an update 
version for it will be upload around 20th Feb.
Probably it will be a good point to discuss then.

Many thanks,
Yihao


发件人: Stewart Bryant [mailto:[email protected]]
发送时间: 2021年2月8日 19:32
收件人: Jiayihao <[email protected]>
抄送: Stewart Bryant <[email protected]>; int-area <[email protected]>; 
[email protected]; 
[email protected]
主题: Re: The small address use case in FlexIP

The problem with this approach is that you only secure the address and not the 
rest of the packet, so you end up with two crypto functions to execute.

Also there are other contenders for the suffix such as the arrival action as 
per network programming, and the perhaps per hop action as per foam. Now I 
suppose that this simply means a much longer address and the semantics of the 
stuff that follows the prefix is defined by the address, but then I think that 
it is better to simply call that a blob defined by the prefix rather with no 
formal semantics in the protocol and leave the definition of the blob to the 
network application designers.

There is clearly quite a lot to study in terms of multi-semantics which I think 
really should be taken out and put in its own draft.

- Stewart


On 8 Feb 2021, at 10:05, Jiayihao 
<[email protected]<mailto:[email protected]>> wrote:

As for address embedding public key, it need not to carry any algorithm in the 
address. It would be much better to carry the public key by address, while 
indicate the algorithm by protocol. I think CGA is a good instance for involve 
address in cryptography. For forwarding efficiency, a public key can be only 
set as a suffix, thus forwarder could process the prefix only, and thus the 
cryptography related stuff may not hinder the looking up efficiency.


_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to