Subject: [rohc] Feedback on draft-ietf-rohc-hcoipsec-02

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 11 Oct 2006 15:29:19 +0200

HCoIPsec folks,

I've reviewed the HCoIPsec draft on a more detailed level, and a
couple of comments (of varying complexity) can be found below. One
may note that the overall structure of the solution is still not
completely settled, and it might be a good idea to make this clear
in the document, wherever these uncertainties applies.

1) Abstract: Replace "defines" with "outlines". This document is
   not a specification, it does not define any necessary technology,
   it only describes informally what is needed to do HCoIPsec, and
   how the various pieces may be put together.

2) Section 1., "Introduction", paragraphs 2-3:
 2a) It is not clear that all existing HC schemes really need to be
     extended for this purpose, I would e.g. claim ROHC does not.
 2b) We are addressing tunnel mode SAs, and that is it. We should
     not talk about potential future work, the last sentence
     currently says why, and that we can keep as a motivation.

  A suggested rewrite of these two paragraphs follows:

 "For HCoIPsec, this document assumes existing header compression
  protocols, Robust Header Compression [ROHC], Internet Protocol
  Header Compression [IPHC], Compressed Real Time Protocol [CRTP],
  and Enhanced Compressed Real Time Protocol [ECRTP], will be used
  to compress the inner headers of IP packets traversing an IPsec
  tunnel.  Since these traditional HC protocols are designed to 
  operate on a hop-by-hop basis, they may require extensions to be
  defined to enable their operation over IPsec SAs. This document
  outlines a framework for extending the usage of these traditional
  hop-by-hop HC protocols to operate at IPsec SA endpoints.

  Transport mode SAs only encrypt/authenticate the payload of an IP
  packet, leaving the IP header untouched. Intermediate routers
  subsequently use the outer IP header to route the packet to a
  decryption device. Therefore, if HC mechanisms were to operate
  between IPsec transport-mode SA endpoints, (de)compression
  functionality could only be applied to the transport layer
  headers, and not to the IP header. Since compression of transport
  layer headers alone does not provide substantial efficiency gains,
  the outlined HCoIPsec framework provided by this document concerns
  only the application of HC to tunnel mode SAs."

3) Section 2., "Audience": I have the same comment as above about
   the actual need for "extensions". A suggested rewrite of this 
   section as follows:

 "The target audience of this document includes those who are
  involved with the development of HC protocols, and IPsec
  implementations. Since traditional HC protocols have been designed
  to operate on a hop-by-hop basis, they may need to be modified or
  extended to be operational over IPsec SAs. Therefore, this
  document targets various HC and IPsec communities who may consider
  extending existing HC and IPsec protocols to meet the requirements
  put forward in this document. Finally, this document is directed
  towards vendors developing IPsec devices which will be deployed in
  bandwidth-constrained IP networks."

4) Section 3., "Terminology":
 4a) RFC 2119 keywords are listed here, but there is no reference in
     the reference section, neither are these keywords used, and
     nor should they be since this document does not really specify
     any new technology. So, please remove this paragraph from the
     terminology section.
 4b) I suggest the following rewrite of "Compressed Traffic":

 "Header Compressed Traffic

     Traffic that is processed by the compressor. Packet headers are
     compressed using a specific header compression protocol." 

 4c) What about "next header"? This term is frequently used and is
     the proper name when considering IPv6, but with this we also
     mean the corresponding v4 field, which is called "Protocol".
     Either we should:
     * add something to the terminology section to define "Next
       Header" as corresponding to IPv4-Protocol or IPv6-NextHeader
     ...or...
     * make this clear at each occurrence by writing 
       NextHeader/Protocol, preferably with an explanation at the
       first occurrence

     Independent of solution, this should be consistently handled
     throughout the whole document.

5) Section 4., "Problem Statement":
 5a) Can we reduce the second part of the section title to "IPsec
     Packet Header Overhead"??
 5b) Remove the specific mentioning of G.729, otherwise we should
     have a reference to it, and it is also questionable to refer
     to any specific coded, as no codec is more representative than
     any other.
 5c) We should further point out that the use of various security
     measures on an end2end-basis (in a tunnel in this case) means
     header compression can not be efficiently applied on a per-hop
     basis over bandwidth-constrained links. I suggest to add the
     following (or something similar) between the sentence ending
     with "...not overprovisioned." and the sentence beginning with
     "Consequently, the...":

 "Header compression applied on a per-hop basis over bandwidth-
  limited link technologies will also suffer from reduced
  performance when encryption is used on tunnelled header, since
  encrypted headers can not be compressed."

6) Section 5.2., "HCoIPsec Description":
 6a) First sentence of first paragraph, add "intra-", i.e.:

     "...by exploiting intra- and inter-packet redundancies of
      network- and transport-layer headers fields..."

 6b) Remove the first sentence of the second paragraph, since it is
     redundant with the last sentence of the same paragraph.

 6c) Rewrite the last sentence of the second paragraph, add "may":

     "...hop-by-hop schemes may need to be extended to..."

 6d) Rewrite second sentence of the fourth paragraph to be correct
     also when considering ROHC (which is not dependent on link-
     layer packet type multiplexing functionality):

     "...end of the link, and some schemes (e.g., IPHC, CRTP, ECRTP)
     are also dependent on the link layer framing for identifying
     different types of header-compressed packets."

 6e) Rewrite the last sentence of the fourth paragraph to make it
     correct regarding packet type identification:

     "The HCoIPsec framework proposes that HC channel parameter
     configuration is accomplished by the SA management protocol
     (e.g., IKEv2), while identification of compressed header
     packets (in contrast to uncompressed packets) is provided
     through the Next Header field of the security protocol. HC
     schemes that require identification of different types of
     header-compressed packets will have to be extended with such
     a mechanism."

 6f) Considering the third paragraph of section 5.2. When we talk
     about reordering, I think we should also make clear that 
     tunneling protocols usually have a sequence number that can
     help an "aware" decompressor handle reordering. Decompression
     of headers of reordered packets is not that troublesome if the
     decompressor knows a packet is "sequentially late", knowledge
     that can be provided from the tunneling header.

7) Section 6.1., "HC and IPsec Integration":
 7a) What does "path 1, 2, 3" mean in terms of SAs?? Are 1 & 2 one
     single SA, while 3 is a different SA?? Should be made clear, 
     preferably in the figure.
 7b) In both first and second paragraphs following figure 1, the
     term "compression profile" is used. This term is undefined,
     and is actually very confusing, since ROHC makes use of this
     term as part of the ROHC framework platform. I think 
     "compression protocol" would be a proper term in this text.

8) Section 6.1.1, "Header Compression Scheme Considerations":
 8a) Rewrite first two sentences of the section:

    "Traditional hop-by-hop HC schemes may have to be extended to
    operate over IPsec SAs. To ensure efficient operation, there
    are also particular implementation aspects to consider, most
    specifically to increase tolerance to packet reordering and
    packet loss between the compressor and decompressor, and to
    minimize the amount of feedback sent from the decompressor to
    the compressor."

 8b) What is IPLR??

 8c) When saying that Feedback should be sent sparingly, are we
     taking into account that ROHC sends feedback piggybacked on
     compressed header traffic going in the opposite direction?
     Other schemes can not do this...true...uuuhh...how much harder
     it is to get everything correct when covering multiple
     solutions (protocols) addressing the same problem.

9) Section 6.1.2., "Initialization and Negotiation of HC Channel":
   Put a reference to the IKEv2 HC extensions draft.

10) Section 6.1.3., "Encapsulation and Identification...":
 10a) The first sentence talks about new state information, "HC data
      item", defined for each SA. Where is this defined??? Document?
 10b) Remove the two last sentences from the section, or mark them
      as tentative in some way, as we have not yet figured out these
      concepts.

11) Section 6.2., "HCoIPsec Framework Summary":
    Remove the RFC Ed note, this section can stay. Before we send
    the document for publication, we may even have references to
    available solutions for each bullet.

12) Most important...=)
    Check the spelling of my name!!

Cheers,
/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc.
Senior Research Engineer
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]                      /"\
Phone: +46 8 404 29 61                                      \ /
Fax: +46 920 996 21               ASCII Ribbon Campaign      X
Home: +46 63 355 24            against HTML email & vCards  / \

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Ertekin Emre" <[email-masked]>
Date: Fri, 13 Oct 2006 15:59:29 -0400

Lars-Erik,

Thanks for your thorough review!!  My responses are inline.
 
>    how the various pieces may be put together.

Ok, I will make the proposed change.

>      extended for this purpose, I would e.g. claim ROHC does not.

I would agree.  RoHCv2 profiles are great solutions that do not require
any modifications.

>   only the application of HC to tunnel mode SAs."

I agree, and will make the proposed change.

>   bandwidth-constrained IP networks."

Again, I would agree.  I will make the proposed change.

>      any new technology. So, please remove this paragraph from the

OK.

>      compressed using a specific header compression protocol."

Ok, I will make the proposed change.

>      throughout the whole document.

Yes... though in the context of HCoIPsec, we are referencing strictly to
the "next header" field in the security protocol header.  As you have
suggested, I've added a definition in the terminology section, and all
references in the document are now changed to "Next Header". 

>      Packet Header Overhead"??

That's fine. 

>      to any specific coded, as no codec is more representative than

OK...G.729 was simply an example.  I can remove it.

>   encrypted headers can not be compressed."

Sounds good, thanks. 

>       network- and transport-layer headers fields..."

Ok, I will make the proposed change.

>      redundant with the last sentence of the same paragraph.

Ok, I will make the proposed change.

>      "...hop-by-hop schemes may need to be extended to..."

Yes, again I agree with this.  

>      different types of header-compressed packets."

OK, thanks for catching this.

>      header-compressed packets will have to be extended with such

Fair comment, thanks.

>      that can be provided from the tunneling header.

This is a good point.  How about adding the following paragraph:

"Additional techniques may be used to augment a traditional HC
protocol's tolerance to packet reordering.  For example, various
security protocols are equipped with a sequence number; this value may
be used by the decompressor to identify a packet as "sequentially late".
This knowledge can increase the likelihood of successful decompression
of a reordered packet."

Perhaps we add this paragraph to section 6.1.1 "Header Compression
Scheme Considerations", following the list of candidate HC schemes? 

>      preferably in the figure.

As depicted in the figure, the decision block at 'A' determines if the
packet is selected on an HC-enabled SA, or an HC-disabled SA.  We will
clarify the picture.

>      "compression protocol" would be a proper term in this text.

We will substitute 'compression protocol' for 'compression profile'.
Thanks.

>     minimize the amount of feedback sent from the decompressor to

Sounds good, thank you.

>  8b) What is IPLR??

Packet loss.  We will substitute "packet loss" for IPLR.

>      solutions (protocols) addressing the same problem.

OK -- I have a few questions on this comment.  Does RoHC _always_ send
feedback piggybacked on compressed header traffic going in the opposite
direction? How about scenarios where only one unidirectional stream
exists?  Does this mean that RoHC cannot send feedback packets from
decompressor to the compressor?

In addition, I'm not sure I fully understand the problem.  If feedback
packets are piggybacked on compressed header traffic going in the
opposite direction, that's fine.  Piggyback the feedback on the
header-compressed packet, and subsequently IPsec process the
piggybacked-packet.  In scenarios where feedback cannot be piggybacked
on compressed header traffic going in the opposite direction, that's
fine too -- just IPsec process the feedback only.

>    Put a reference to the IKEv2 HC extensions draft.

Thanks.  Sounds good.

>       item", defined for each SA. Where is this defined??? Document?

Yes, this is a good question.  My suggestion is a new draft, IPsec
extensions to support HCoIPsec.  If we are going to request a new
allocation from IANA, this draft _could_ be where we make the IANA
request.

>       as tentative in some way, as we have not yet figured out these

Fair comment.  I'll make the changes.

>     available solutions for each bullet.

This is fine.

>     Check the spelling of my name!!

Rats... wonder why spell check didn't catch this one.  ;)   Our
apologies; we will fix this as well.

> /L-E

After fixing the Figure in section 6.1, I will submit the draft.  Sound
good?

R,
EE

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 17 Oct 2006 14:33:25 +0200

> be used by the decompressor to identify a packet as "sequentially
> late". This knowledge can increase the likelihood of successful
> decompression of a reordered packet." 
> 

Sounds good! 

> packet is selected on an HC-enabled SA, or an HC-disabled SA.  We
> will clarify the picture. 

Yes, my point was to make the picture clear in this regard, especially
in the HC-enabled SA, what the two alternatives mean in terms of SA.

> feedback piggybacked on compressed header traffic going in
> the opposite direction?

No, but it can be if there is bidirectional traffic, to save overhead.

> How about scenarios where only one unidirectional stream

All that is needed to send feedback is a feedback channel of some kind,
potentially a ROHC channel in the opposite direction. In a ROHC channel,
feedback may be sent interspersed or piggybacked, the latter if there
is ROHC traffic going in the channel.

> allocation from IANA, this draft _could_ be where we make the IANA

Ok, we'll have to think about this. I got the feeling something was
missing. Maybe we should include it in this draft, which would then
have to be standards track. Let's think some more about this, it is
not such a tricky question as the PROTOCOL NUMBER issue.

/L-E