Skip to main content

Security Assessment of the Internet Protocol Version 4
RFC 6274

Revision differences

Document history

Date Rev. By Action
2020-01-21
07 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
07 (System) Notify list changed from opsec-chairs@ietf.org, draft-ietf-opsec-ip-security@ietf.org to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Stewart Bryant
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2011-07-07
07 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2011-07-05
07 (System) RFC published
2011-04-18
07 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-04-18
07 (System) IANA Action state changed to No IC from In Progress
2011-04-18
07 (System) IANA Action state changed to In Progress
2011-04-18
07 Amy Vezza IESG state changed to Approved-announcement sent
2011-04-18
07 Amy Vezza IESG has approved the document
2011-04-18
07 Amy Vezza Closed "Approve" ballot
2011-04-18
07 Amy Vezza Approval announcement text regenerated
2011-04-18
07 Amy Vezza Ballot writeup text changed
2011-04-16
07 Ron Bonica State changed to Approved-announcement to be sent from IESG Evaluation.
2011-04-08
07 Ron Bonica State changed to IESG Evaluation from IESG Evaluation - Defer::AD Followup.
2011-04-08
07 Stewart Bryant [Ballot discuss]
2011-04-08
07 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2011-04-08
07 (System) New version available: draft-ietf-opsec-ip-security-07.txt
2011-03-28
07 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-03-25
07 Tim Polk
[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 …
[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.
2011-03-25
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss
2011-03-10
07 Tim Polk
[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 …
[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.
2011-03-10
07 Tim Polk
[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 …
[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.
2011-01-26
06 (System) New version available: draft-ietf-opsec-ip-security-06.txt
2011-01-13
07 Sean Turner
[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 …
[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
2010-12-25
07 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2010-12-16
07 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2010-12-16
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-12-16
05 (System) New version available: draft-ietf-opsec-ip-security-05.txt
2010-12-03
07 Stewart Bryant
[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 …
[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.
2010-12-02
07 Sean Turner
[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 …
[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).
2010-12-02
07 Cindy Morgan State changed to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer.
2010-12-02
07 Sean Turner [Ballot comment]
#1) Section 3.13.2.4: r/shoudl/should

#2) Section 4.1.2.3: r/described in throughout/described throughout
2010-12-02
07 Sean Turner
[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 …
[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?
2010-12-02
07 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2010-12-02
07 Tim Polk
[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 …
[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.
2010-12-02
07 Tim Polk [Ballot comment]
I support Adrian's discuss regarding the router alert issues.
2010-12-02
07 Tim Polk
[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) …
[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.
2010-12-02
07 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded
2010-12-02
07 Jari Arkko
[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 …
[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.
2010-12-02
07 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2010-12-01
07 Peter Saint-Andre
[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. …
[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?
2010-12-01
07 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2010-12-01
07 Stewart Bryant
[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 …
[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.
2010-12-01
07 Stewart Bryant
[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 …
[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.
2010-12-01
07 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded
2010-11-19
07 (System) Removed from agenda for telechat - 2010-11-18
2010-11-16
07 Tim Polk State changed to IESG Evaluation - Defer from Waiting for AD Go-Ahead.
2010-11-15
07 Adrian Farrel
[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 …
[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.
2010-11-15
07 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from No Objection
2010-11-13
07 Adrian Farrel
[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 …
[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.
2010-11-13
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2010-11-12
07 Ron Bonica Placed on agenda for telechat - 2010-11-18 by Ron Bonica
2010-11-12
07 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2010-11-12
07 Ron Bonica Ballot has been issued by Ron Bonica
2010-11-12
07 Ron Bonica Created "Approve" ballot
2010-11-08
07 (System) State changed to Waiting for AD Go-Ahead from In Last Call by system
2010-11-01
07 Amanda Baber IANA understands that, upon approval of this document, there are no IANA
Actions that need completion.
2010-10-29
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Eric Rescorla
2010-10-29
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Eric Rescorla
2010-10-25
07 Cindy Morgan Last call sent
2010-10-25
07 Cindy Morgan State changed to In Last Call from Last Call Requested by Cindy Morgan
2010-10-25
07 Ron Bonica Last Call was requested by Ron Bonica
2010-10-25
07 (System) Ballot writeup text was added
2010-10-25
07 (System) Last call text was added
2010-10-25
07 (System) Ballot approval text was added
2010-10-25
07 Ron Bonica State Changes to Last Call Requested from Publication Requested by Ron Bonica
2010-10-22
07 Amy Vezza [Note]: 'The Document Shepherd is Joel Jaeggli (joelja@bogus.com).' added by Amy Vezza
2010-10-22
07 Amy Vezza
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 …
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.
2010-10-22
07 Amy Vezza Draft Added by Amy Vezza in state Publication Requested
2010-10-21
04 (System) New version available: draft-ietf-opsec-ip-security-04.txt
2010-10-15
07 (System) Document has expired
2010-04-13
03 (System) New version available: draft-ietf-opsec-ip-security-03.txt
2010-02-20
02 (System) New version available: draft-ietf-opsec-ip-security-02.txt
2009-08-20
01 (System) New version available: draft-ietf-opsec-ip-security-01.txt
2009-01-29
00 (System) New version available: draft-ietf-opsec-ip-security-00.txt