Subject: Re: [Int-area] The small address use case in FlexIP

From: Jiayihao <[email-masked]>
Date: Mon, 8 Feb 2021 10:05:01 +0000

Hi Stewart,

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.

While for the prefix table lookup, method like Multi-Entrance-Trie (METrie) can be used to support fast table lookup (see https://dl.acm.org/doi/pdf/10.1145/3341558.3342204), the evaluation in this paper shows it is possible to achieve efficient packet forwarding for length variable IP address.

Thanks,
Yihao

发件人: Stewart Bryant [mailto:[email-masked]]
发送时间: 2021年2月5日 22:59
收件人: Jiayihao <[email-masked]>
抄送: Stewart Bryant <[email-masked]>; int-area <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Lin Han <[email-masked]>
主题: Re: The small address use case in FlexIP

On 5 Feb 2021, at 12:06, Jiayihao <[email-masked]<mailto:[email-masked]>> wrote:

- Indeed, the network scale of limited domain is supposed to be less that IPv6, but it doesn't mean the address space should be strictly less than 128-bit. If the space of the address is abundant enough, the public key could be embedded without truncation (compare to CGA in IPv6) for certain security purpose.

Interesting, what are the advantages in adding the signature of the address in the address as opposed to carrying it in a different field?

The disadvantage is that you bind the address to the signature algorithm which you would not want to do since you would expect to change the signature algorithm during the lifetime of the protocol.

Also would you really want to feed the signature into the longest match engine? Of course you could and there are some advantages in that you look up both the address and it signature, but I think you loose longest match capability and you significantly increase the size of the TCAM or other FIB design memory, and that memory is very expensive as it determines the line rate of the forwarder.

So this points back to the need for a holistic discussion of what we are trying to achieve, the extent to which modifying existing protocols satisfies that need, and whether (given the presupposed need for a gateway) we should be looking for a single protocol, a family of protocols, or an adaptable protocol.

I don’t think we can design the addressing system in the absence of a discussion on those points.

Best regards

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 8 Feb 2021 11:31:46 +0000

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-masked]> wrote:
>

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 9 Feb 2021 04:47:43 +0000

Hi Stewart,
Isn’t it good to have separate crypto functions for the payload and the address? With separate public keys, for payload they are only exchanged between the 2 end points and for addresses by select entities responsible for forwarding.
-Kiran

From: Int-area <[email-masked]> on behalf of Stewart Bryant <[email-masked]>
Date: Monday, February 8, 2021 at 03:32
To: Jiayihao <[email-masked]>
Cc: [email-masked] <[email-masked]>, int-area <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Int-area] 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.

- Stewart

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