Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes
draft-ietf-cbor-network-addresses-13

[Ballot comment]
The updated version looks good, thanks!

Text of former DISCUSS below for posterity.

--

Thanks for this document. In general I found it easy to read, blessedly concise, and useful. I do have one concern with how you treat the covert channel concern you raise, which I'm making a DISCUSS (which I think will be easily cleared).

Section 4 says:

  even though variations like:

  54([44, h'20010db81233'])
  54([45, h'20010db8123f'])

  would be parsed in the exact same way; they MUST be considered
  invalid.

You choose to use a RFC 2119 keyword here, and this is in the encoder section, so presumably you are insisting that the encoder MUST... what? You already said, in an earlier paragraph, that the encoder MUST set the trailing bits to zero, so I can't figure out what the quoted text is telling me to do. (Presumably any compliant encoder won't produce the depicted values, and an encoder that's noncompliant for the purpose of deliberately exfiltrating data using this covert channel won't be put off by this MUST.)

Then in Section 5 we have:

  A particularly paranoid decoder could examine the lower non-relevant
  bits to determine if they are non-zero, and reject the prefix.  This
  would detect non-compliant encoders, or a possible covert channel.

The fairly dismissive tone ("paranoid decoder could"), not to mention the preceding pseudocode, suggests that you have no real expectation the decoder will do anything to "consider invalid" values with nonzero low bits. So probably the MUST from Section 4 isn't meant to apply to the decoder.

In short I don't understand what that clause in Section 4 is telling me to do. One fix would simply be to weaken the text, as in

  would be parsed in the exact same way, they should not be
  considered legitimate encodings.
 
P.S.: The semicolon in the quoted text is also either wrong, or I'm even more confused about what's being specified than I thought I was.

[Ballot comment]
Thank you for the work put into this document and addressing my previous ballot points (DISCUSS & COMMENT); those points are kept below for archiving purposes only.

Special thanks to Barry Leiba for his concise shepherd's write-up but very clear about the WG consensus.

Thank you also to Donald Eastlake for this INT directorate review that I am vastly supporting:
https://mailarchive.ietf.org/arch/msg/int-dir/6Ox8iEBMqXkUoC2aUEF3wi4-c5g/

I hope that this helps to improve the document,

Regards,

-éric


== PREVIOUS DISCUSS (for archive) ==

Generic comment how are link-local address (LLA) with scope encoded ? I would expect CBOR to work also on LLA only networks... At the bare minimum, please state that link-local addresses cannot be encoded with their scope, hence, they cannot represent an interface.

-- Section 3.1.3 --
How can 2 valid link-local addresses (fe80::1%eth0, fe80::1%eth1) can be represented in order to identity two interfaces ?

== PREVIOUS COMMENTS (for archive) ==

I love how your start with IPv6 in section 3 and use the ASCII codes for '6' and '4' ;-)

-- Section 3.2 --
Is there any reason why part of the IPv6 is in lowercase (as in RFC 5952) and the other part in uppercase ? This is confusing to the reader (even if hexadecimal numbers are obviously case insensitive).

== NITS ==

-- Abstract --
Should CBOR be expanded ?

[Ballot discuss]
Thanks for this document. In general I found it easy to read, blessedly concise, and useful. I do have one concern with how you treat the covert channel concern you raise, which I'm making a DISCUSS (which I think will be easily cleared).

Section 4 says:

  even though variations like:

  54([44, h'20010db81233'])
  54([45, h'20010db8123f'])

  would be parsed in the exact same way; they MUST be considered
  invalid.

You choose to use a RFC 2119 keyword here, and this is in the encoder section, so presumably you are insisting that the encoder MUST... what? You already said, in an earlier paragraph, that the encoder MUST set the trailing bits to zero, so I can't figure out what the quoted text is telling me to do. (Presumably any compliant encoder won't produce the depicted values, and an encoder that's noncompliant for the purpose of deliberately exfiltrating data using this covert channel won't be put off by this MUST.)

Then in Section 5 we have:

  A particularly paranoid decoder could examine the lower non-relevant
  bits to determine if they are non-zero, and reject the prefix.  This
  would detect non-compliant encoders, or a possible covert channel.

The fairly dismissive tone ("paranoid decoder could"), not to mention the preceding pseudocode, suggests that you have no real expectation the decoder will do anything to "consider invalid" values with nonzero low bits. So probably the MUST from Section 4 isn't meant to apply to the decoder.

In short I don't understand what that clause in Section 4 is telling me to do. One fix would simply be to weaken the text, as in

  would be parsed in the exact same way, they should not be
  considered legitimate encodings.
 
P.S.: The semicolon in the quoted text is also either wrong, or I'm even more confused about what's being specified than I thought I was.

[Ballot discuss]
Thanks for this document. In general I found it easy to read, blessedly concise, and useful. I do have one concern with how you treat the covert channel concern you raise, which I'm making a DISCUSS (which I think will be easily cleared).

Section 4 says:

  even though variations like:

  54([44, h'20010db81233'])
  54([45, h'20010db8123f'])

  would be parsed in the exact same way; they MUST be considered
  invalid.

You choose to use a RFC 2119 keyword here, and this is in the encoder section, so presumably you are insisting that the encoder MUST... what? You already said, in an earlier paragraph, that the encoder MUST set the trailing bits to zero, so I can't figure out what the quoted text is telling me to do. (Presumably any compliant encoder won't produce the depicted values, and an encoder that's noncompliant for the purpose of deliberately exfiltrating data using this covert channel won't be put off by this MUST.)

Then in Section 5 we have:

  A particularly paranoid decoder could examine the lower non-relevant
  bits to determine if they are non-zero, and reject the prefix.  This
  would detect non-compliant encoders, or a possible covert channel.

The fairly dismissive tone ("paranoid decoder could"), not to mention the preceding pseudocode, suggests that you have no real expectation the decoder will do anything to "consider invalid" values with nonzero low bits. So probably the MUST from Section 4 isn't meant to apply to the decoder.

In short I don't understand what that clause in Section 4 is telling me to do. One fix would simply to weaken the text, as in

  would be parsed in the exact same way, they should not be
  considered legitimate encodings.
 
P.S.: The semicolon in the quoted text is also either wrong, or I'm even more confused about what's being specified than I thought I was.

[Ballot comment]
I am curious about Eric’s 2nd discuss point, hence supporting his discuss on that.

I also support Lars’s and Murray’s comments.


Thanks for working on this specification.

[Ballot discuss]
Thank you for the work put into this document.

Please find below two blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Barry Leiba for his concise shepherd's write-up but very clear about the WG consensus.

Thank you also to Donald Eastlake for this INT directorate review that I am vastly supporting:
https://mailarchive.ietf.org/arch/msg/int-dir/6Ox8iEBMqXkUoC2aUEF3wi4-c5g/


I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS ==

Generic comment how are link-local address (LLA) with scope encoded ? I would expect CBOR to work also on LLA only networks... At the bare minimum, please state that link-local addresses cannot be encoded with their scope, hence, they cannot represent an interface.

-- Section 3.1.3 --
How can 2 valid link-local addresses (fe80::1%eth0, fe80::1%eth1) can be represented in order to identity two interfaces ?

[Ballot comment]
== COMMENTS ==

I love how your start with IPv6 in section 3 and use the ASCII codes for '6' and '4' ;-)

-- Section 3.2 --
Is there any reason why part of the IPv6 is in lowercase (as in RFC 5952) and the other part in uppercase ? This is confusing to the reader (even if hexadecimal numbers are obviously case insensitive).

== NITS ==

-- Abstract --
Should CBOR be expanded ?

[Ballot comment]
** Section 7.  Recommend generalizing the text.

OLD
  Identifying which byte sequences in a protocol are addresses may
  allow an attacker or eavesdropper to better understand what parts of
  a packet to attack.  That information, however, is likely to be found
  in the relevant RFCs anyway, so this is not a significant exposure.

NEW
This document provides an CBOR encoding for IPv4 and IPv6 address information.  Any applications using these encodings will need to consider the security implications of this data in their specific context.  For example, identifying which byte sequences in a protocol are addresses may allow an attacker or eavesdropper to better understand what parts of a packet to attack.


** Section 8.3.  Recommend making the text clearer on what’s getting deprecated

OLD
  IANA is requested to add the note "DEPRECATED in favor of 52 and 54
  for IP addresses" to registrations 260 and 261

NEW
IANA is requested to add the note "DEPRECATED for use with IP addresses in favor of 52 and 54" to registrations 260 and 261

[Ballot comment]
What should a recipient do if they encounter something in a form that is
expected to include a "natural length" byte string for the IP address
family indicated, but the byte string is a different length?  Do we just
need to say that it is "invalid" and thereby invoke the core CBOR rules
that require protocols to specify how their decoders handle invalid
data?  Or is even that implicit from the CDDL?

In light of the genart reviewer's comment, I think we should say
something like "this specification does not deal with Ethernet
addresses, and tag 260 remains available for that usage" to clarify that
we are not deprecating use of that tag for Ethernet addresses.

  This specification defines tags 54 and 52.  These new tags are
  intended to be used in preference to tags 260 and 261.  They provide
  formats for IPv6 and IPv4 addresses, prefixes, and addresses with
  prefixes, achieving an explicit indication of IPv6 or IPv4.  The

I'd suggest saying here that the tag number is the differentiator
between IPv4 and IPv6 -- that could be helpful to know before we go into
the discussion of address/prefix/interface format.  Perhaps "achieving
an explicit indication of IPv6 or IPv4 by the tag number"?

Section 3.1.3

  When applied to an array that starts with a byte string, which stands
  for an IP address, followed by an unsigned integer giving the bit
  length of a prefix built out of the first "length" bits of the
  address, they represent information that is commonly used to specify
  both the network prefix and the IP address of an interface.

We say "full-length" down in §3.2 and 3.3 (and in the CDDL), but should
we perhaps also say here that this byte string need to be the "natural
length" or "full length" for the IP address family in question?

Section 5

  unused_bits = (-prefix_length_in_bits) & 7;
  if (length_in_bytes > 0)
    address_bytes[length_in_bytes - 1] &= (0xFF << unused_bits);

This looks like it's trying to be C, and the XML agrees.  I think it
only has the desired effect when two's-complement representation for
signed integers is used, though (this is not guaranteed by C through at
least C11, though I have not been closely tracking whether the proposal
to make C and C++ two's-complement-only has been adopted), and suggest
reformulating to something like:

  unused_bits = (8 - (prefix_length_in_bits & 7)) % 8;

(This would be DISCUSS level if it was the only specification for the
behavior, but since it is "or simply", it seems more illustrative in
intent.)

NITS

Section 3.2

  54([h'20010db81234DEEDBEEFCAFEFACEFEED', 56])

DEADBEEF (rather than DEEDBEEF) is in somewhat common usage as a pattern
for indicating "tainted" memory in various sanitizer codes...

Section 5

  A particularly paranoid decoder could examine the lower non-relevant
  bits to determine if they are non-zero, and reject the prefix.  This

This would have to be done before the clearing done by the previous
snippet, of course...

[Ballot comment]
I concur with Lars' comment.

I'm not sure about the "WRONG" labels.  I suggest including that in prose instead; for instance, something like the following:

OLD:

  even though variations like:

  54([44, h'20010db81233'])  WRONG
  54([45, h'20010db8123f'])  WRONG

  would be parsed in the exact same way.

NEW:

  even though variations like:

  54([44, h'20010db81233'])
  54([45, h'20010db8123f'])

  would be parsed in the exact same way; they MUST be
  considered invalid.

[Ballot comment]
Thanks for defining these, they generally looks useful.

I note that this encoding doesn't cover RFC 4007 scoped IP addressed, e.g., that can be expressed by YANG's IPv4-address and IPv6-address (RFC 6991).  Is there any thought or plan to support scoped IP addresses, either by extending this tag format, or would these use separate tag numbers if support for them was ever required?  Perhaps the introduction should indicate that scoped IP addresses are out of scope ;-)

Section 3.1.2 and 3.1.3.  Is the array always of length 2 and if so is that worth explicitly stating here?

Section 4, is the last bad example right, i.e., with a prefix length of 45 rather than 44?

  54([45, h'20010db8123f'])  WRONG

Would this not be interpreted as the prefix: "2001:db8:1238::/45"?

I have to confess that I'm not super keen on the ordering of the array arguments defining the meaning of whether it is a prefix or interface definition.  This feels a bit too much like magic for my liking.

Rob

[Ballot comment]
Section 1. , paragraph 3, comment:
>    This specification does not
>    deal with 6- or 8-byte Ethernet addresses.

I read this and kept wondering about what other Ethernet addresses there are
that I didn't know about... It might be clearer to say something like "does not
include support for Ethernet addresses".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

These URLs in the document can probably be converted to HTTPS:
* http://www.iana.org/assignments/cbor-tags

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cbor-network-addresses-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

two early registrations will have their references changed to [ RFC-to-be ]. They are:

Tag: 52
Data Item: byte-string or array
Semantics: An IPv4 address or IPv4 prefix

Tag: 54
Data Item: byte-string or array
Semantics: An IPv6 address or IPv6 prefix

Second, also in the Concise Binary Object Representation (CBOR) Tags registry located at:

https://www.iana.org/assignments/cbor-tags/

two existing registrations will be marked "DEPRECATED in favor of 52 and 54." They are:

Tag: 260
Data Item: byte-string
Semantics: Network Address (IPv4 or IPv6 or MAC Address)

Tag: 261
Data Item: byte-string
Semantics: map (IPAddress + Mask Length) Network Address Prefix (IPv4 or IPv6 Address + Mask Length)

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-09-22):

From: The IESG
To: IETF-Announce
CC: barryleiba@computer.org, cbor-chairs@ietf.org, cbor@ietf.org, draft-ietf-cbor-network-addresses@ietf.org, francesca.palombini@ericsson.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CBOR tags for IPv4 and IPv6 addresses and prefixes) to Proposed Standard


The IESG has received a request from the Concise Binary Object Representation
Maintenance and Extensions WG (cbor) to consider the following document: -
'CBOR tags for IPv4 and IPv6 addresses and prefixes'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines two CBOR Tags to be used with IPv6 and
  IPv4 addresses and prefixes.


  // RFC-EDITOR-please-remove: This work is tracked at
  // https://github.com/cbor-wg/cbor-network-address




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/



No IPR declarations have been submitted directly on this I-D.

1. Summary

This specification defines two new CBOR tags, 54 and 52, which provide formats for IPv6 and IPv4 addresses, respectively.  The new tags are intended to be used in place of the existing 260 and 261 tags, and make a clear distinction between v6 and v4 while also allowing specification of addresses, prefixes, and addresses with prefixes.  These new tags are proposed as standard tags, so the document is a Proposed Standard.

The document shepherd is Barry Leiba; the responsible AD is Francesca Palombini.

2. Review and Consensus

The document is a simple one, and had discussion among a relatively small group of participants.  On request during working group last call we confirmed that the support in the working group is broad, and that the working group as a whole agrees with it.  External reviews have been requested during WGLC and received from OpsDir and IoTDir.  Discussion in general has been largely editorial.  There are broad plans to implement these tags; the desire for the features provided here, noting how 260 and 261 are lacking, was the reason for creating this.

There has been some late discussion to do with zone index, which might continue during IETF-wide last call.  At this time, we don't think changes are needed as a result of that discussion.

3. Intellectual Property

The authors are in full compliance with BCPs 78 and 79, and there have been no IPR issues raised.

4. Other Points

There is nothing else of note here.

1. Summary

This specification defines two new CBOR tags, 54 and 52, which provide formats for IPv6 and IPv4 addresses, respectively.  The new tags are intended to be used in place of the existing 260 and 261 tags, and make a clear distinction between v6 and v4 while also allowing specification of addresses, prefixes, and addresses with prefixes.  These new tags are proposed as standard tags, so the document is a Proposed Standard.

The document shepherd is Barry Leiba; the responsible AD is Francesca Palombini.

2. Review and Consensus

The document is a simple one, and had discussion among a relatively small group of participants.  On request during working group last call we confirmed that the support in the working group is broad, and that the working group as a whole agrees with it.  External reviews have been requested during WGLC and received from OpsDir and IoTDir.  Discussion in general has been largely editorial.  There are broad plans to implement these tags; the desire for the features provided here, noting how 260 and 261 are lacking, was the reason for creating this.

There has been some late discussion to do with zone index, which might continue during IETF-wide last call.  At this time, we don't think changes are needed as a result of that discussion.

3. Intellectual Property

The authors are in full compliance with BCPs 78 and 79, and there have been no IPR issues raised.

4. Other Points

There is nothing else of note here.

1. Summary

This specification defines two new CBOR tags, 54 and 52, which provide formats for IPv6 and IPv4 addresses, respectively.  The new tags are intended to be used in place of the existing 260 and 261 tags, and make a clear distinction between v6 and v4 while also allowing specification of addresses, prefixes, and addresses with prefixes.  These new tags are proposed as standard tags, so the document is a Proposed Standard.

The document shepherd is Barry Leiba; the responsible AD is Francesca Palombini.

2. Review and Consensus

The document is a simple one, and had discussion among a relatively small group of participants.  On request during working group last call we confirmed that the support in the working group is broad, and that the working group as a whole agrees with it.  External reviews have been requested during WGLC and received from OpsDir and IoTDir.  Discussion in general has been largely editorial.  There are broad plans to implement these tags; the desire for the features provided here, noting how 260 and 261 are lacking, was the reason for creating this.

3. Intellectual Property

The authors are in full compliance with BCPs 78 and 79, and there have been no IPR issues raised.

4. Other Points

There is nothing else of note here.