RFC Errata
Found 1 record.
Status: Held for Document Update (1)
RFC 4380, "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", February 2006
Note: This RFC has been updated by RFC 5991, RFC 6081, RFC 9601
Source of RFC: IETF - NON WORKING GROUPArea Assignment: tsv
Errata ID: 107
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-16
Held for Document Update by: Wes Eddy
(1) Inconsistency on cryptographic algorithm (MAC) requirements
Within section 5.2.2, on the upper half of page 21, RFC 4380 states:
To maximize interoperability, this specification defines a default
algorithm in which the authentication value is computed according the
| HMAC specification [RFC2104] and the SHA1 function [FIPS-180].
Clients and servers may agree to use HMAC combined with a different
function, or to use a different algorithm altogether, such as for
example AES-XCBC-MAC-96 [RFC3566].
The default authentication algorithm is based on the HMAC algorithm
according to the following specifications:
| - the hash function shall be the SHA1 function [FIPS-180].
- the secret value shall be the shared secret with which the client
was configured.
Contrary to that, within Section 7.2.1, in the paragraph extending
from page 39 to page 40, the same RFC says:
If the shared secret contains sufficient entropy, the attacker would
have to defeat the one-way function used to compute the
authentication value. This specification suggests a default
<<page break>>
| algorithm combining HMAC and MD5. If the protection afforded by MD5
was not deemed sufficient, clients and servers can agree to use a
different algorithm, e.g., SHA1.
I have been educated repeatedly that Security Considerations in RFCs
contain normative content when describing protocol behaviour.
Therefore, it should not happen that text in Security Considerations
contradicts normative content of other sections of an RFC.
Regarding the well known security issues that make MD5 appear much
weaker than SHA-1, according to contemporary comprehension by the
cryptographic community, the former specification (Section 5.2.2)
seems to be the better choice.
I therefore strongly recommend to publish an Author's Errata Note
for RFC 4380 correcting Section 7.2.1, replacing the snippit above
by text conforming to the rules specified in Section 5.2.2, e.g.:
If the shared secret contains sufficient entropy, the attacker would
have to defeat the one-way function used to compute the
| authentication value. This specification defines a default algorithm
| combining HMAC and SHA-1. Clients and servers can agree to use a
| different message authentication algorithm, e.g. AES-XCBC-MAC-96.
| See Section 5.2.2 for details.
(2) Incomplete IANA Considerations
Section 9 of RFC 4380, on page 50, says:
This memo documents a request to IANA to allocate a 32-bit Teredo
IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4
multicast address, as specified in Section 2.17.
It should say:
| On requests documented in this memo, IANA has allocated a 32-bit
| Teredo IPv6 service prefix, as specified in Section 2.6, a Teredo
| IPv4 multicast address, as specified in Section 2.17, and a Teredo
| UDP Port number, as specified in Section 2.7.
Rationale:
As per publication of the RFC, these assignments *have been* performed
by the IANA; I propose modified wording reflecting this fact.
Apparently, an IANA assignment also has been performed on behalf of the
Teredo proposal as documented in Section 2.7; for completeness, this
assignment should be mentioned in the IANA Considerations section as
well. This will also serve as an easy-to-find "pointer" for readers
looking for the purpose of the assignment found in the IANA registry.
(3) Various typos
I have found a couple of apparent typos in RFC 4380. The sub-items
below are pre-formatted for easy inclusion into an RFC errata note.
(3.1) Section 5.2.2, page 21
The first paragraph on page 21 contains the sentence:
[...]. Before transmission,
the authentication value is computed according to the specified
algorithm; on reception, the same algorithm is used to compute a
target value from the content of the receive packet. [...]
It should say:
[...]. Before transmission,
the authentication value is computed according to the specified
algorithm; on reception, the same algorithm is used to compute a
| target value from the content of the received packet. [...]
^
(3.2) Section 5.2.3, page 23
The second paragraph on page 23 [numbered list item 4)] says:
[...]. The client SHOULD reply with a unicast Teredo bubble, sent
to the source IPv4 address and source port of the local discovery
bubble; the IPv6 source address of the bubble will be set to local
Teredo IPv6 address; [...]
It should say:
[...]. The client SHOULD reply with a unicast Teredo bubble, sent
to the source IPv4 address and source port of the local discovery
| bubble; the IPv6 source address of the bubble will be set to the local
Teredo IPv6 address; [...]
^^^^
(3.3) Section 5.2.7, page 27
The long paragraph in the middle of page 27 says:
[...]. If the secondary
qualification fails, the interval determination procedure will not be
used, and the interval value will remain to the default value, 30
seconds. [...]
It should say:
[...]. If the secondary
qualification fails, the interval determination procedure will not be
| used, and the interval value will remain at the default value, 30
seconds. [...]
^^^^
(3.4) Section 5.2.9, page 30
The last paragraph of Section 5.2.9 says:
[...] The nonce value and the date at which the packet was
sent will be documented in a provisional peer entry for the IPV6
destination. The ICMPv6 packet will then be sent [...]
It should say:
[...] The nonce value and the date at which the packet was
| sent will be documented in a provisional peer entry for the IPv6
destination. The ICMPv6 packet will then be sent [...]
^^^^
(3.5) Section 7.2, page 39
The last sentence of Section 7.2 says:
[...] The attacker may have one of two objectives: it may try to
deny service to the Teredo client by providing it with an address
that is in fact unreachable, or it may try to insert itself as a
relay for all client communications, effectively enabling a variety
of "man-in-the-middle" attack.
It should say:
[...] The attacker may have one of two objectives: it may try to
deny service to the Teredo client by providing it with an address
that is in fact unreachable, or it may try to insert itself as a
relay for all client communications, effectively enabling a variety
| of "man-in-the-middle" attacks.
^
(4) Formatting issue
RFC 4380 contains a striking number of spurious blank lines inserted
in the middle of running text, interrupting proper paragraph formating.
Browsing through RFC 4380, I have found such spurious blank lines on
pages 23, 30, 33, 35, 41, 44, and 46.
Notes:
from pending