Integration of Robust Header Compression over IPsec Security Associations
draft-ietf-rohc-hcoipsec-13

[Ballot discuss]
Section 6.1.4 addresses a number of issues that a reader might expect to see in the security
considerations.  Rather than repeat them, could we get a pointer from Section 7 (Security
Considerations) to Section 6.1.4 (Motivations for the ROHC ICV)?

I would also like to see the Security Considerations expanded to address malicious (as opposed
to malfunctioning) nodes.  My knowledge of ROHC is embarrassingly limited, but it seems
that a malicious compressor can efficiently mount a Denial of Service attack since it is far
cheaper to construct an invalid packet than to perform the decryption operations.  Similarly,
a malicious decompressor can simply discard packets, claim that decryption failed,
and request retransmission.

[Ballot discuss]
The OPS-DIR review by David Black raised several issues which were discussed with the authors. However, at least a couple of the problems seem to have remained unresolved in this version.

(1) Add text describing the limited use of the new Internet Protocol
Number.  Specifically, this new number never occurs in the outer
IP header and is encrypted when ESP encryption is in use, but
may nonetheless require additional policies on firewalls or
other filtering middleboxes to ensure that ROHCOIPsec traffic
is not dropped.

(2) Explain what happens (how ROHCOIPsec behaves) when the IPsec traffic
is UDP-encapsulated (UDP header is between the outer IP header and
the ESP header).  UDP encapsulation is very common for IPsec NAT
traversal purposes.

[Ballot discuss]
I have reviewed draft-ietf-rohc-hcoipsec-12, and have couple of
concerns about the security considerations that I'd like to see
addressed before recommending approval of the document:

- Section 6.1.4, 3rd paragraph, doesn't really say why the current
ROHC integrity mechanisms are not sufficient (they're intended for
random packet loss/reordering, not malicious behavior). Perhaps
rephrase the second sentence as "However, bits in the original IP
header are not protected by this ICV, only by ROHC's integrity
mechanisms (which are designed for random packet loss/reordering, not
malicious packet loss/reordering introduced by an attacker)."?

- Section 6.1.4, 1st paragraph, should note that reconstructing
erronous packets can also happen without reordering (perhaps add
"Significant packet loss can have similar consequences." to the
end of the paragraph)

Document write-up for draft-ietf-rohc-hcoipsec

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Carl Knutsson is the Document Shepherd. The document has
been personally reviewed by Document Shepherd and is ready
to be published as "Informational".

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, it has been reviewed by members of both ipsecme and rohc
WGs. The Document Shepherd have no concerns about the
depth or breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is a strong consensus behind the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No conflicts or display of extreme discontent.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, No.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

IP Security (IPsec) provides various security services for
IP traffic. However, the benefits of IPsec come at the cost
of increased overhead. This document outlines a framework
for integrating Robust Header Compression (ROHC) over IPsec
(ROHCoIPsec). By compressing the inner headers of IP
packets, ROHCoIPsec proposes to reduce the amount of
overhead associated with the transmission of traffic over
IPsec Security Associations (SAs).


Working Group Summary

The document represents rough consensus of the working group.

Document Quality

The document have been reviewed extensively by both members
from the ipsecme and the rohc working groups. During the WG
Last-Call the document was reviewed by the committed WG
reviewers Robert A. Stangarone Jr. and Yoav Nir.