Security Assessment of the Internet Protocol Version 4
draft-ietf-opsec-ip-security-07

[Ballot comment]
I still think the document would benefit greatly from a restructuring to explicitly address goals and threats,
then structure the body to address the various threats.  It would have been nice to address protocol-specific issues
first, then go into implementation details.

[Ballot comment]
I still think the document would benefit greatly from a restructuring to explicitly address goals and threats,
then structure the body to address the various threats.  It would have been nice to address protocol-specific issues
first, then go into implementation details.

[Ballot discuss]
[Revised discuss, removing issues that have been addressed and adding detail where the email thread indicates I was unclear.]

The intro has been significantly improved by the new paragraph on "packet-of-death".  I think one additional paragraph should be inserted that notes security implications from the changes in operational environment since IP was designed are also in scope.  For example, sections 3.6 and 3.8 include material on compatibility with Network Intrusion detection systems.  I would not characterize incompatibility with NIDS as a bug in an IPv4 implementation or a protocol issue, but NIDS area feature of common deployments and so the material is needed

I still believe a rationale for sections 3.1 (Version field) and 3.2 (Internet Header Length) is needed.  Does this material address known "packet-of-death" implementations?  If not, I am at a loss to determine the relevant security goals or threats.

[Ballot discuss]
This is an updated discuss based on some exchanges with the author.  Original #ing is retained.

#1) I support Tim's discuss.

#2) addressed

#3) addressed

#4) addressed

#5) addressed

#6) addressed

#7) addressed

[Ballot discuss]
The text in 3.5.2.2 on not using UDP c/s does not do justice to systems where performance requirements make this impractical, for example systems such as LISP where UDP is a tunnel, and IPFIX where the exporter is often a linecard forwarder. Equally, the text glosses over  just how poor the UDP c/s is.

Following on from discussion at the review call, I need to add the following additional item to this discuss.

The document has a lot of text discussing the issues with IP options, but fails to educate the reader that options are very rare, particularly options addressed to a host. Thus the implementer should be instructed to treat any option received by a host, and any option other than router alert received by a router as extremely suspicious.

[Ballot discuss]
This is an updated discuss based on some exchanges with the author.  Original #ing is retained.

#1) I support Tim's discuss.

#2) The 2119 key words paragraph is included in Section 1.1 but there are no requirements in this draft (two MUST NOTs and one SHOULD but all in quotes from other RFCs).  Should the paragraph be be removed or are all the lower case must, should, etc. supposed to be upper case?  I suspect it's the former.

#5) Section 3.3.2.2, Does RFC 6040 come in to play here at all?

#6) Section 3.5.2.1/2, add a pointer to RFC 4086 (advice on good random # generator).  Should also mention that generating these #s will have some impact (however small) on performance.

#7) Sec 3.8.1, I understand that defaults can be used to "help" fingerprint a system - but between the bazillion windows boxes, millions of mac os/linux/etc boxes isn't this some small value of help?  Is this mentioned somewhere else (that I've obviously glossed over).

[Ballot discuss]
#1) I support Tim's discuss.

#2) The 2119 key words paragraph is included in Section 1.1 but there are no requirements in this draft (two MUST NOTs and one SHOULD but all in quotes from other RFCs).  Should the paragraph be be removed or are all the lower case must, should, etc. supposed to be upper case?  I suspect it's the former.

#3) Should there a big disclaimer that some of these recommendations might not hold true for closed networks?  Maybe a closed network need to use LSSR, for example?

#4) Is it universally accepted that the right thing to do is drop all packets that include obsolete options?

#5) Section 3.3.2.2, Does RFC 6040 come in to play here at all?

#6) Section 3.5.2.1/2, add a pointer to RFC 4086 (advice on good random # generator).  Should also mention that generating these #s will have some impact (however small) on performance.

#7) Sec 3.8.1, I understand that defaults can be used to "help" fingerprint a system - but between the bazillion windows boxes, millions of mac os/linux/etc boxes isn't this some small value of help?  Is this mentioned somewhere else (that I've obviously glossed over).

#8) Section 3.11: Should CGAs be discussed as a counter measure?

#9) Section 3.13.2.4: Is it really true there is absolutely no good use for SSRR?  In a walled garden they couldn't use it?

[Ballot discuss]
This document includes a lot of important information, but the utility is undermined by (1) omission of background
information, (2) inconsistent scope, and (3) structural issues resulting from (1) and (2).

Given the title, I expected the document to articulate a set of security goals of IP and present a set of threats
as background material.  Without this, it is difficult to understand why some sections are included.  For example,
section 3.1 covers the Version field.  The text notes that the version field needs to be 4 or the packet should be silently dropped.  Similarly, section 3.2 covers the Internet Header Length and the checks to be performed.  I cannot
hazard a guess what security goal or threat this applies to.  In addition, goals and threats are introduced implicitly
throughout the document. For example, section 3.8 implies that topology hiding and compatibility with Network
Intrusion Detection Systems are security goals for IP.

The document scope is inconsistent as well.  Some of the issues are vulnerabilities associated with IP implementations, but others have to do with the protocol itself.  If the document has to address both kinds of
vulnerabilities, then it needs to be much clearer about each vulnerability.

I actually think the document would benefit greatly from a restructuring to explicitly address goals and threats,
then structure the body to address the various threats.  It would be nice to address protocol-specific issues
first, then go into implementation details.

Anyway, I believe that this document could be a significant asset to the community, but it will require a lot of work.
Publication as-is will not have a positive effect IMHO.

[Ballot discuss]
This document includes a lot of important information, but the utility is undermined by (1) omission of background
information, (2) inconsistent scope, (3) structural issues resulting from (1) and (2), and (4) some surprising
omissions in terms of IP features.

Given the title, I expected the document to articulate a set of security goals of IP and present a set of threats
as background material.  Without this, it is difficult to understand why some sections are included.  For example,
section 3.1 covers the Version field.  The text notes that the version field needs to be 4 or the packet should be silently dropped.  Similarly, section 3.2 covers the Internet Header Length and the checks to be performed.  I cannot
hazard a guess what security goal or threat this applies to.  In addition, goals and threats are introduced implicitly
throughout the document. For example, section 3.8 implies that topology hiding and compatibility with Network
Intrusion Detection Systems are security goals for IP.

The document scope is inconsistent as well.  Some of the issues are vulnerabilities associated with IP implementations, but others have to do with the protocol itself.  If the document has to address both kinds of
vulnerabilities, then it needs to be much clearer about each vulnerability.

I actually think the document would benefit greatly from a restructuring to explicitly address goals and threats,
then structure the body to address the various threats.  It would be nice to address protocol-specific issues
first, then go into implementation details.

Finally, I was very surprised that the document omits traditional security features like the authentication options
(TCP-MD5 and TCP-AO).  This may be a scope issue, but I think that is an unfortunate decision...

Anyway, I believe that this document could be a significant asset to the community, but it will require a lot of work.
Publication as-is will not have a positive effect IMHO.

[Ballot discuss]
Section 4.3.4 claims that based on ongoing work, the treatment
of Class E address space (240/4) should be changed in current routers
and hosts. I think this is inappropriate because the referred work is not
actually currently pursued in any way. There are also numerous
technical problems in deploying something like that. Finally, while
this is a great and much needed document, it should not be used as
a vehicle to specify specific technical proposals of controversial nature.

[Ballot comment]
Thank you for writing this helpful document.

Appendix A borders on marketing and seems like a strange thing to include in an RFC. Why is this here?

[Ballot comment]
The introduction appears to incorrectly uses the term TCP/IP when the author means the Internet Protocol suit.

"This document is the result of an assessment of the IETF specifications of the Internet Protocol (IP)"  - The document only discusses IPv4.

I am surprised that Section 3 does not have a normative reference to RFC791

In Figure 3, an attacker sends a 17914-byte datagram meant to the
s/to/for/

NDIS is used before it is defined.

Section 3.11 (related to the aside on SA being an interface)  ought to have some text on loop-back addresses, and unnumbered interfaces.

[Ballot discuss]
The text in 3.5.2.2 on not using UDP c/s does not do justice to systems where performance requirements make this impractical, for example systems such as LISP where UDP is a tunnel, and IPFIX where the exporter is often a linecard forwarder. Equally, the text glosses over  just how poor the UDP c/s is.

[Ballot discuss]
After discussion and on the request of the Responsible AD, Ron Bonica, I am converting my COmment to a Discuss.

I am disappointed that this document doesn't highlight more fully the issues and concerns for security created by the Router Alert option. A reference to draft-ietf-intarea-router-alert-considerations might serve well.

[Ballot comment]
I am disappointed that this document doesn't highlight more fully the issues and concerns for security created by the Router Alert option. A reference to draft-ietf-intarea-router-alert-considerations might serve well.

1.a

The Document Shepherd is Joel Jaeggli, Opsec WG cochair. The Document
Shepherd has reviewed Draft 03 of draft-ietf-opsec-ip-security and
concluded that the document is prepared for ietf last call and
subsequent publication.

1.b

A previous iteration of the document was published as a UK CPNI report
where it underwent initial vetting.

The document has been reviewed and received extensive commentary in the
opsec WG. It has completed a WG last call process without opposition.
The document was subsequently revised to clean up formating, minor
language issues, and to prevent it from expiring.


1.c

The document covers significant ground in it review of the IP protocol.
Due to it's size, and breadth, high quality review has represented
something of a challenge (several have been performed), we do not view
scope as a reason not to pursue the work. Domain specific experts have
been engaged in a number of areas and we believe that it is of suitable
quality to be advanced to informational status. A detailed review
performed by Alfred Hoenes contributed substantial language changes
during the last call period.

1.d

Concerns, fall along the following lines. Providing implementation
advice in a informational document does not update existing RFC's. While
this document's guidance is we believe quite relevant when it comes to
making sound implementation or alteration choices, it's proposed
status (informational) is a limitation. We further believe that the act
ofattempting to update or obsolete existing RFC's as part of this work
is infeasible, and the goal is therefore to document what we understand
to be good practice today.

1.e

Working group consensus has been tested both on the mailing list and in
meetings.

Subsequent to last call we have no known opposition to publication
within the working group.

1.f

No.

1.g

Nits:

Current idnits are superficial

Idnits returns positive hits on RFC's that have subsequently been
obsoleted, however which discussing the historical state of
implementation it is sometimes necessary to reference both the original
and updated RFC.

1.h

References are divided between normative and informative.

1.i

An IANA consideration section exists, the document has no additional
considerations for iana beyond those cited in preexisting RFCs.

1.j

No formal language is present.

1.k

Technical Summary

This document contains a security assessment of the IETF
specifications of the Internet Protocol version 4, and of a number of
mechanisms and policies in use by popular IPv4 implementations. It
is based on the results of a project carried out by the UK's Centre
for the Protection of National Infrastructure (CPNI).

Working Group Summary

Working group consensus required the settlement of two major points of
contention:

Was this document in scope for the opsec working group charter, and were
the participants sufficiently knowledgeable to provide input?

What status should be pursued by the document authors?

Regarding to former, it was the opinion of the area director and WG
consensus that the document was compatible with the working group
charter. capabilities and limitations of the ipv4 protocol fall within
the scope of operational security capabilities work.

Regarding the second question, consensus that informational status was
the appropriate approach for this document. The number of documents
potentially touched by this document is considerable. It is not
necessary in the process of making recommendations on the basis of
operational experience to update the protocol specification so long as
those recommendations do not result in divergence from the protocol
specification that would result in non-inter-operable operation. That
said, operationaly some such as source routing can be expected not to
work as a product of current practice.

Document Quality

Numerous implementations of the IPv4 protocol exist. The recommendations
contained within this document have accumulated over the course of close
to 30 years worth of operational experience. The information contained
in this document has not been collected in one IETF document before,
doing so has produced a document that is quite challenging to review
from a scale perspective. We have solicited and received a number of
reviews high quality reviews and we believe that prior publication of
previous versions of document also aided considerably with development
and review.