Skip to main content

IPsec Extensions to Support Robust Header Compression over IPsec
RFC 5858

Yes

(Magnus Westerlund)

No Objection

Lars Eggert
(Alexey Melnikov)
(Cullen Jennings)
(Lisa Dusseault)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)

Note: This ballot was opened for revision 08 and is now closed.

Lars Eggert No Objection

(Magnus Westerlund; former steering group member) Yes

Yes ()

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection (2009-12-16)
The OPS-DIR review performed by Bert Wijnen on version 05 of the document included the following comment: 

> If I understand the document correctly, then a user of this protocol will have to
add additional paramters in the SPD and SAD databases (as defined in RFC4301).
 
> I do not see any discussion as to what implications (if any) that may have to
existing entries in the databases?. Might that cause interupts to ongoing operations?
Or can existing entries be left untouched and could one choose to just add these
new paramters to new entries in the databases?
 
> Answers to these questions are probably best added in the document itself.

The answer from the document editor mentioned that: 

> Bert's understanding is correct; we are adding additional parameters to the SPD and SAD databases.  Fortunately, I do not think that these new parameters will cause issues for existing entries in the SPD and SAD.   The additional ROHCoIPsec SPD parameters are simply configured (e.g., along with the other parameters in the SPD).  Based on the these SPD parameters, the ROHCoIPsec SAD parameters will be populated during the initialization/rekey of a child SA (e.g., along with the other SAD parameters).  

I am satisfied with the answer, but I believe that the issue should be documented in the future RFC.

(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection (2009-12-17)
Neither the abstract or the introduction made it clear whether the header compression is inside or outside IPsec headers. Maybe its obvious for the
authors, but as a reader I would have wanted to see that early on.

> 4. Extensions to IPsec Processing
>
> 4.1. Addition to the IANA Protocol Numbers Registry

Mixing IANA considerations and behaviour rules.

> ICV

The document does a poor job of explaining why ICVs are needed.
I think you should add a paragraph about this.

> IPComp and ROHC

I would personally rather just say use one, not both.
Do we need this complexity?

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection (2009-12-09)
In my opinion, including support for ROHC segmentation (Section 4.3)
is misguided, and unnecessary complexity.  While AH/ESP sequence
numbers could be used in theory to reconstruct the correct segment
sequence, I have doubts that anyone will actually implement this: ROHC
is useful mostly for small packets (where the header is large part of
the total packet) -- but those won't require fragmentation...

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection (2009-12-17)
I suggest spelling out robust header compression once somewhere in the abstract.  It should
be relatively obvious given the document's title, but in isolation the abstract is difficult to sort.