Feature #2901
open
CompressionType and EncryptionType in MetaInfo
Added by Tai-Lin Chu over 9 years ago.
Updated over 1 year ago.
Description
These two fields are optional for non-encrypted or uncompressed packet.
However, if a data packet is encrypted or compressed, they should be set accordingly.
Normally, encryption or compression is applied on data before segmentation, one may choose to just set those fields in the final block.
type MetaInfo struct {
ContentType uint64 `tlv:"24?"`
FreshnessPeriod uint64 `tlv:"25?"`
FinalBlockID FinalBlockID `tlv:"26?"`
EncryptionType uint64 `tlv:"30?"`
CompressionType uint64 `tlv:"31?"`
}
const (
CompressionTypeGZIP uint64 = 1
)
const (
EncryptionTypeAESWithCTR uint64 = 1
)
- Tracker changed from Task to Feature
- Subject changed from Introduce CompressionType and EncryptionType to MetaInfo to CompressionType and EncryptionType in MetaInfo
- Description updated (diff)
- Start date deleted (
06/14/2015)
ndn-cxx allows arbitrary application-defined TLVs to appear at the end of MetaInfo.
Defining EncryptionType and CompressionType globally may not be necessary, because they are specific to applications.
Questions on the proposal:
When encryption or compression happens before segmentation, why is EncryptionType and CompressionType recommended to appear in the last segment, not the first segment?
Having them appear in the first segment allows the receiver to start decryption or decompression before all segments are collected.
Stream ciphers and stream compression algorithms can decrypt/decompress the initial octets as long as segments are being retrieved in order.
If the packet the both encrypted and compressed, is there a recommendation on whether the application should do encryption first, or compression first?
Can we use the order of EncryptionType appearance and CompressionType appearance to express this information?
EncryptionType appears before CompressionType if plaintext is encrypted then ciphertext is compressedCompressionType appears before EncryptionType if plaintext is compressed then compressed octets are encrypted
For text-based contents (eg. text/html), compression would be more effective if it's applied before encryption.
Those two fields are so common that ndn might want to define them globally. The purpose is to let all applications understand that a packet is encrypted or compressed and handle it accordingly.
In that case, then the first segment makes sense.
Normally it is compressed then encrypted (If the encryption is done properly then the result is basically random data). If one does the other way around, the compression ratio will be terrible.
NDN Protocol Design Principle says:
NDN protocol and packet format should include only elements directly related to data, i.e., universally required, needed, and meaningful in all communication environments. Other elements needed in specific environments (e.g., in today’s infrastructure-based Internet) should go to the network adaptation layer(s).
Therefore, it makes sense for compression type and encryption type fields to be universal, if they are needed.
However, I doubt they are needed.
For compression type, it should be in the name. In HTTP, browser can include Accept-Encoding request header to ask for gzipped response, or omit this header to ask for non-compressed response. The NDN equivalent would be a typed name component in the Interest.
For encryption type, it should be in the payload or inferred from communication context. Knowing the encryption type does not help. Consumer must also know the index of a decryption key.
- Tags set to needs-discussion
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by