CCNx Messages in TLV Format
draft-irtf-icnrg-ccnxmessages-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8609.
|
|
|---|---|---|---|
| Author | Marc Mosko | ||
| Last updated | 2016-01-11 | ||
| RFC stream | Internet Research Task Force (IRTF) | ||
| Formats | |||
| IETF conflict review | conflict-review-irtf-icnrg-ccnxmessages, conflict-review-irtf-icnrg-ccnxmessages, conflict-review-irtf-icnrg-ccnxmessages, conflict-review-irtf-icnrg-ccnxmessages, conflict-review-irtf-icnrg-ccnxmessages, conflict-review-irtf-icnrg-ccnxmessages | ||
| Additional resources | Mailing list discussion | ||
| Stream | IRTF state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8609 (Experimental) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-irtf-icnrg-ccnxmessages-01
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 4 |
+---------------+---------------+---------------+---------------+
| T_CRC32 | 0 |
+---------------+---------------+---------------+---------------+
As an example of a MAC type validation, the encoding for an HMAC
using a SHA256 hash would be:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 40 |
+---------------+---------------+---------------+---------------+
| T_HMAC-SHA256 | 36 |
+---------------+---------------+---------------+---------------+
| T_KEYID | 32 |
+---------------+---------------+---------------+---------------+
/ KeyId /
/---------------+---------------+-------------------------------+
As an example of a Signature type validation, the encoding for an RSA
public key signing using a SHA256 digest and Public Key would be:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 44 + Variable Length |
+---------------+---------------+---------------+---------------+
| T_RSA-SHA256 | 40 + Variable Length |
+---------------+---------------+---------------+---------------+
| T_KEYID | 32 |
+---------------+---------------+---------------+---------------+
/ KeyId /
/---------------+---------------+-------------------------------+
| T_PUBLICKEY | Variable Length (~ 160) |
+---------------+---------------+---------------+---------------+
/ Public Key (DER encoded SPKI) /
+---------------+---------------+---------------+---------------+
Mosko & Solis Expires July 14, 2016 [Page 29]
Internet-Draft CCNx TLV January 2016
3.6.4.2. Validation Payload
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_PAYLOAD | ValidationPayloadLength |
+---------------+---------------+---------------+---------------+
/ Type-dependent data /
+---------------+---------------+---------------+---------------+
The ValidationPayload contains the validation output, such as the
CRC32C code or the RSA signature.
Mosko & Solis Expires July 14, 2016 [Page 30]
Internet-Draft CCNx TLV January 2016
4. Acknowledgements
Mosko & Solis Expires July 14, 2016 [Page 31]
Internet-Draft CCNx TLV January 2016
5. IANA Considerations
TODO: Work with IANA to define the type space for: Top level types,
Hop-by-hop header types, Name segment types, CCNx messages types,
Interest message TLV types, Content Object TLV message types,
Validation types, and Validation dependent data types.
All drafts are required to have an IANA considerations section (see
Guidelines for Writing an IANA Considerations Section in RFCs
[RFC5226] for a guide). If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above). If there are no requirements for IANA, the section
will be removed during conversion into an RFC by the RFC Editor.
Mosko & Solis Expires July 14, 2016 [Page 32]
Internet-Draft CCNx TLV January 2016
6. Security Considerations
All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide.
Mosko & Solis Expires July 14, 2016 [Page 33]
Internet-Draft CCNx TLV January 2016
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[CCN] PARC, Inc., "CCNx Open Source", 2007,
<http://www.CCNx.org>.
[CCNSemantics]
Mosko, M. and I. Solis, "CCNx Semantics (Internet draft)",
2016, <http://tools.ietf.org/html/
draft-mosko-icnrg-ccnxsemantics-01>.
[ECC] Certicom Research, "SEC 2: Recommended Elliptic Curve
Domain Parameters", 2010,
<http://www.secg.org/sec2-v2.pdf>.
[EpriseNumbers]
IANA, "IANA Private Enterprise Numbers", 2015, <http://
www.iana.org/assignments/enterprise-numbers/
enterprise-numbers>.
[LCI] Mosko, M., "Labeled Content Information (Internet draft)",
2015, <http://tools.ietf.org/html/
draft-mosko-icnrg-ccnxlabeledcontent-01>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
Mosko & Solis Expires July 14, 2016 [Page 34]
Internet-Draft CCNx TLV January 2016
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<http://www.rfc-editor.org/info/rfc6920>.
[VMAC] Krovertz, T. and W. Dai, "VMAC: Message Authentication
Code using Universal Hashing", 2007,
<http://www.fastcrypto.org/vmac/
draft-krovetz-vmac-01.txt>.
Mosko & Solis Expires July 14, 2016 [Page 35]
Internet-Draft CCNx TLV January 2016
Authors' Addresses
Marc Mosko
PARC, Inc.
Palo Alto, California 94304
USA
Phone: +01 650-812-4405
Email: marc.mosko@parc.com
Ignacio Solis
PARC, Inc.
Palo Alto, California 94304
USA
Phone: +01 650-812-4405
Email: marc.mosko@parc.com
Mosko & Solis Expires July 14, 2016 [Page 36]