From mailnull@www1.ietf.org Tue Apr 1 08:43:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10332 for ; Tue, 1 Apr 2003 08:43:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31E7Wk02585 for rohc-archive@odin.ietf.org; Tue, 1 Apr 2003 09:07:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31E7WK02582 for ; Tue, 1 Apr 2003 09:07:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10315 for ; Tue, 1 Apr 2003 08:43:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31E7HK02258; Tue, 1 Apr 2003 09:07:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31E63K00597 for ; Tue, 1 Apr 2003 09:06:03 -0500 Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10113; Tue, 1 Apr 2003 08:41:45 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h31DggN17061; Tue, 1 Apr 2003 16:42:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Apr 2003 16:44:11 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:44:09 +0300 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 07:44:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Tue, 1 Apr 2003 07:44:03 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL0Oh0S9278a4G2TwGrlMF2MA/VLAAjOLXAAAxkv+AA1e7EEA== To: Cc: , X-OriginalArrivalTime: 01 Apr 2003 13:44:05.0524 (UTC) FILETIME=[C32CF540:01C2F854] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31E63K00604 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Robert, > I don't think it is a problem with SigComp multiplexing, but > more like a SIP internal issue. What if there is a TCP stream > of SIP messages and the Content-Length header is missing or > false? They will screw up the same way with or without > SigComp. Since TCP is a reliable transport, this only happens for a mis-behaved SIP sender. But that is not the "multiplexing" problem I mentioned below, which happens even "during normal functioning" (see below). > During normal functioning both SIP and SigComp > provide their own flow separation mechanism and they work just fine. I don't think so. That is what I intended to show by the example, i.e. the issue to "multiplex uncompressed application messages and SigComp messages on the same port". One solution, as I mentioned before, is to require sigcomp receiver has the ability to parse uncompressed application messages and detect the end. (Of course, I saw Carsten's email and I need understand his point of view, which says there is no such "multiplexing" and it is not possible and necessary.) BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 2 16:55:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11479 for ; Wed, 2 Apr 2003 16:55:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32MJe524200 for rohc-archive@odin.ietf.org; Wed, 2 Apr 2003 17:19:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MJeK24197 for ; Wed, 2 Apr 2003 17:19:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11450 for ; Wed, 2 Apr 2003 16:54:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MJQK24165; Wed, 2 Apr 2003 17:19:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MIqK24133 for ; Wed, 2 Apr 2003 17:18:52 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11411 for ; Wed, 2 Apr 2003 16:53:55 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h32LuOI3001654 for ; Wed, 2 Apr 2003 23:56:24 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2A4R4QKT>; Wed, 2 Apr 2003 23:56:24 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Formal notation, combined thread Date: Wed, 2 Apr 2003 23:54:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, > > > RP: The notation language itself shouldn't make a distinction > > > between EPIC-lite and any other encoding method. > > > > As I have said above, I think it is important to make a clear > > distinction between these, as they are so different. That is also > > what we said last year, when we talked about field encoding vs. > > compressed header encoding. > > As above, I can't see any reason to think of the > discriminator encodings as "special", or to treat them > differently in some way. The distinction between the > various types of encoding method that we made last year > was only intended to clarify how the notation handles all > of the different compression techniques needed by ROHC > profiles. From a technical perspective the notation has > never given special treatment to the discriminator > encodings, and I think that it would be confusing and > unnecessarily restrictive to do so. We obviously disagree here. I still believe it is important to make this distinction. All field encodings that can send compressed data in more than one way calls a discriminator function, but any function could be used, i.e. the notation for a profile can be written independent of the actual discriminator function that is later chosen. > > > RP: If the compressed header formats are created manually then the > > > ROHC-FN description captures the exact hand-crafted packet > > > formats - not just the content of the compressed headers, but the > > > hand-crafted "discriminator" bits as well. > > > > OK, but then we would not even need the notation as a tool, if > > the actual formats (in written form) would just mean the same. > > The notation provides a really useful benefit even when > describing hand-crafted compressed headers, which is the > extra implementation option of writing a "notation compiler" > to automatically convert a notated description of the > packet formats into running code. First of all, I think it would be useful to have the notation to describe what to put in hand made formats, i.e. as a tool in such a process. Further, I think we would make a mistake if we tried to make the notation capable of describing hand made formats, as that would make the notation unnecessary complex, while the reason does not really make sense in my mind. > > > RP: The big advantage of making the adjustments within ROHC-FN > > > is that the description of the compressed packet formats remain > > > machine-readable > > > > We are defining standards, which should be human-readable. There > > are probably disagreements in this regard, but personally I think > > human-readability is more important than machine-readability. > > I agree that human-readability is at least as > important as machine-readability. However, in > my opinion a notated set of packet formats is > actually rather more human-readable than a set > of packet formats drawn out pictorially. Well, protocol headers are usually drawn out pictorially, so that is what protocol folks are more used to. > > 7. EPIC-Lite > > > > The EPIC and EPIC-Lite terms have been overloaded several times by > > now, and they actually do not say much about what they really do. > > If we want to use the "EPIC-Lite" method for "discriminator > > encoding" and potentially define it in the general notation > > document, we should come up with a name that tells us what it does. > > > > Any ideas? > > We originally used the term "EPIC-lite" to mean > the entire notation-based solution, including > the notation itself and the complete library of > encoding methods. The algorithm for generating > the discriminator bits is actually nothing more than > ordinary Huffman encoding, so perhaps we could > just call it that instead? Ok, "Ordinary Huffman" (OH), and "Hierarchical Huffman" (HH) then? /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 2 19:30:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18785 for ; Wed, 2 Apr 2003 19:30:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h330WhF05054 for rohc-archive@odin.ietf.org; Wed, 2 Apr 2003 19:32:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330WhK05050 for ; Wed, 2 Apr 2003 19:32:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18778 for ; Wed, 2 Apr 2003 19:30:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330WTK05016; Wed, 2 Apr 2003 19:32:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330VrK04960 for ; Wed, 2 Apr 2003 19:31:53 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18730 for ; Wed, 2 Apr 2003 19:29:21 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h330VtZ24745 for ; Wed, 2 Apr 2003 18:31:55 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Apr 2003 18:31:49 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Apr 2003 18:31:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Wed, 2 Apr 2003 18:31:48 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL1P5Qe4IYqmFSNTYKHaQBBY4H64AEJxsMg To: , X-OriginalArrivalTime: 03 Apr 2003 00:31:48.0965 (UTC) FILETIME=[6A013150:01C2F978] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h330VsK04962 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Carsten and all, The reason I raised the "binary multiplexing", as you found out, is the following text in RFC 3320. I took the sentence literally, i.e., uncompressed application messages and SigComp messages can be transmitted on the same (destination UDP or TCP) port, one followed by another. If that understanding is incorrect, I'm wondering what else it means or is intended to mean. "... for applications which use this encoding (or ASCII encoding) it is possible to multiplex uncompressed application messages and SigComp messages on the same port." In addition, the above text works - in my mind - at least for case 00, 01, and 10 listed below. Note I assume we are talking about application messages that start with UTF-8 encoding (my interpretation of "use" in above text). Also, I try to visualize the issue in two dimensions: encoding of application messages and transport below SigComp. message-based stream-based transport transport (e.g. UDP) (e.g. TCP) contain no binary data case 00 case 01 contain binary data case 10 case 11 Here is why/how I see it works for case 00-10: - For case 00 and 10, RFC 3320 says "In case of a message-based transport such as UDP, a SigComp message corresponds to exactly one datagram." So, it is trivial for the receiver to tell if a UDP packet carries uncompressed message or sigcomp message by inspecting the first byte. - For case 01, the receiver can detect the beginning of a SigComp message by bit pattern "11111" and the end by END-MESSAGE instruction. Of course, the SigComp message delimiter also works for this purpose. As to case 11, I think we can also make it work, if sigcomp receiver can detect the end of an uncompressed message. Obviously, that means the receiver needs to have some knowledge about the application message format. This is why I separate case 11 from the rest (which are application independent). Now come to the question if the multiplexing is necessary. I think it is useful in cases where a sigcomp sender does not want to compress every application message even though the other end has indicated its support of sigcomp. The reason could be CPU load of the compressor, message uncompressible, etc. I could be wrong by thinking the multiplexing works. But if it indeed works, the next question is whether RFC 3320 already covers some of this or we add extension to RFC 3320. BR, Zhigang > -----Original Message----- > From: ext Carsten Bormann [mailto:cabo@tzi.org] > Sent: March 28, 2003 9:24 AM > To: rohc@ietf.org > Cc: Carsten Bormann > Subject: Re: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > ROHCers, > > in San Francisco, I promised to come back to the "binary multiplexing" > issue after the IETF. > > It has taken me a while to even understand what is being talked about: > There is an assumption in this whole thread that I don't know where it > came from. > > We designed SigComp messages so that they always start with a byte > that cannot be used as a coding symbol in UTF-8 (see > draft-yergeau-rfc2279bis-04.txt for the updated version of RFC2279 > that defines the contemporary version of UTF-8). The assumption was > that most signalling protocols would use UTF-8 headers, so this would > allow some self-describing-ness of SigComp messages. > > RFC3320 says: > > All SigComp messages contain a prefix (the five > most-significant bits > of the first byte are set to one) that does not occur in UTF-8 > encoded text messages [RFC-2279], so for applications > which use this > encoding (or ASCII encoding) it is possible to multiplex > uncompressed > application messages and SigComp messages on the same port. > Applications can still reserve a new port specifically for SigComp > however (e.g., as part of the discovery mechanism). > > I now see that this might be phrased a bit misleading > ("multiplexing"). But clearly, the scheme discussed is about using > the same port for two different *transports*: the raw transport and > the SigComp-compressed transport. Nowhere does it say that you would > multiplex messages from these two *on the same connection*. I don't > believe this is possible or even necessary. > > Record Marking (4.2.2) is used to delimit SigComp messages on stream > transports (TCP, TLS). The assumption, of course, is that the > connection carrying these messages already has been disambiguated to > run SigComp instead of the raw transport protocol. > > This is the end of my main argument for this message. If you disagree > with it, please discuss it and not the interesting speculation below. > >
> > It is somewhat conceivable to occasionally intersperse uncompressed > messages in the SigComp record marking transport, but it remains clear > that the record marking layer is in effect at all times: > > For a stream-based transport, the dispatcher delimits messages by > parsing the compressed data stream for instances of 0xFF > and taking > the following actions: > > So, we are talking about a situation where the data flows to a SigComp > dispatcher, not to an entity that still needs to find out whether we > are running SigComp or not. > > Could SigComp record marking be used to carry both compressed and > uncompressed messages on one connection? (Remember that this is not > part of the standard, but of course could be part of an extension to > RFC 3320.) > > In principle, yes, but there is a problem (see below). In any case, > though, Content-Length headers or any other application message > delimiting protocol would not enter the picture at all -- the SigComp > record marking layer remains in effect throughout a SigComp > connection. > > Now the problem: If you don't have any other way to find out (e.g., > different port numbers for compressed and uncompressed), it becomes > hard to decide whether such a compressed/uncompressed multiplexed > stream is SigComp or not. If it starts with a non-UTF-8 coding > symbol, you know it's SigComp. But if the first message you want to > send on the connection happens to be uncompressed, you need another > way of indicating that a SigComp transport is being used. Of course, > you could simply send 0xFFFF and trust that the receiver will discard > empty messages. So to make this multiplexing business work, you will > have to add a mandate that says empty messages (or at least one 0xFFFF > at the beginning of the connection) are discarded. > > Of course, none of this applys to any hypothetical SigComp application > that does not use UTF-8 headers in their messages -- the multiplexing > would not work this way at all, period. So you would devise another > way of multiplexing, which I'm too lazy to do right now. > >
> > Oh, and we still have to do the work on the SIP binding for SigComp, > which is completely unrelated to this whole thread. There is no known > problem with SigComp-compressing large binary layloads in SIP messages > (except, maybe, that there won't be very good compression schemes for > data that already have been compressed). > > Gruesse, Carsten > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 3 12:31:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02275 for ; Thu, 3 Apr 2003 12:31:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33HXYH05435 for rohc-archive@odin.ietf.org; Thu, 3 Apr 2003 12:33:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33HXXK05432 for ; Thu, 3 Apr 2003 12:33:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01877 for ; Thu, 3 Apr 2003 12:28:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33HURK05140; Thu, 3 Apr 2003 12:30:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33HTvK05088 for ; Thu, 3 Apr 2003 12:29:57 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01618; Thu, 3 Apr 2003 12:27:02 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33HTWH26358; Thu, 3 Apr 2003 11:29:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 11:29:27 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 11:29:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA06.9112EBC2" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Thu, 3 Apr 2003 11:29:23 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL57NkjhdknIYmwRTKBF5JK5rjYiQADhltA To: , Cc: , X-OriginalArrivalTime: 03 Apr 2003 17:29:24.0404 (UTC) FILETIME=[91E1D740:01C2FA06] Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FA06.9112EBC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark, =20 The problem I raised is how "to multiplex uncompressed application = messages and SigComp messages on the same port" when application = messages start with UTF-8 encoded text but contain binary data. For the = problem itself, I don't assume where the demultiplexing is done (that = goes to the solution space, see below). My point is that it needs to be = done somewhere at the receiving endpoint (which by definition, is "one = instance of an application, a SigComp layer, and a transport layer"). =20 Now, the solutions: =20 - One is to let decompressor dispatcher do the demultiplexing (I won't = repeat how it can be done), which means all bytes received on a port = must go through SigComp layer first. This follows the SigComp = architecture in RFC 3320. It makes the layering more clean, i.e., = (de)compression and (de)multiplexing is handled completely by SigComp = layer. The drawback is a bit redundancy in the sense that the = decompressor dispatcher performs some parsing that the application layer = will later do again.=20 =20 - The other one is to let the application do the demultiplexing as you = described below. That means all received data must go through = application first. =20 In my view, either one will work and the choice is a local = implementation issue (although the latter is not described in RFC 3320). = The difference boils down to where do put the demultiplexing function. = It's a matter of preference of SW coding. However, what is NOT an = implementation issue is that - looking at transport layer - a receiving = endpoint must expect it may receive uncompressed messages interspersed = with SigComp messages on the same port and demultiplex them using either = of the above approaches (or any other working solutions). This needs to = be spelled out in a document. =20 BR, Zhigang =20 -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: April 03, 2003 8:24 AM To: Liu Zhigang.C (NRC/Dallas); Sugar Robert (NET/Budapest) Cc: rohc@ietf.org; sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = messages Zhigang,=20 If I understand the solution described by Robert correctly, then the = problem you describe below does not arise. Your problem seems to assume = that demultiplexing of compressed and uncompressed messages will be done = before the SIP parser is invoked, based on the 11111xxx delimiter. My understanding is that messages are passed directly to the SIP parser. = This software must be aware that SIGCOMP may be used, and checks the = first octet of the input stream. If this is 11111xxx then it uses the = sigcomp delimeter OxFFFF to find the end of the compressed message, and = then sends it to the decompressor. If the first octets is not 11111xxx = then it just starts parsing as normal. The only assumption is that the SIP parser has its own way of = recognising the end of an uncompressed message.=20 Regards...Mark=20 > -----Original Message-----=20 > From: zhigang.c.liu@nokia.com [ mailto:zhigang.c.liu@nokia.com]=20 > Sent: 01 April 2003 14:44=20 > To: Robert.Sugar@nokia.com=20 > Cc: rohc@ietf.org; sipping@ietf.org=20 > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = > messages=20 >=20 >=20 > Robert,=20 >=20 > > I don't think it is a problem with SigComp multiplexing, but=20 > > more like a SIP internal issue. What if there is a TCP stream=20 > > of SIP messages and the Content-Length header is missing or=20 > > false? They will screw up the same way with or without=20 > > SigComp.=20 >=20 > Since TCP is a reliable transport, this only happens for a=20 > mis-behaved SIP sender. But that is not the "multiplexing" problem=20 > I mentioned below, which happens even "during normal functioning"=20 > (see below).=20 >=20 > > During normal functioning both SIP and SigComp=20 > > provide their own flow separation mechanism and they work just fine. = >=20 > I don't think so. That is what I intended to show by the example,=20 > i.e. the issue to "multiplex uncompressed application messages and=20 > SigComp messages on the same port". One solution, as I mentioned=20 > before, is to require sigcomp receiver has the ability to parse=20 > uncompressed application messages and detect the end.=20 >=20 > (Of course, I saw Carsten's email and I need understand his=20 > point of view, which says there is no such "multiplexing" and=20 > it is not possible and necessary.)=20 >=20 > BR,=20 > Zhigang=20 > _______________________________________________=20 > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping=20 > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sip@ietf.org for new developments of core SIP=20 >=20 ------_=_NextPart_001_01C2FA06.9112EBC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = messages
Mark,
 
The=20 problem I raised is how "to multiplex uncompressed application messages = and=20 SigComp messages on the same port" when application messages start with=20 UTF-8 encoded text but contain binary data. For the problem = itself, I=20 don't assume where the demultiplexing is done (that goes to the solution = space,=20 see below). My point is that it needs to be done somewhere at the = receiving=20 endpoint (which by definition, is "one instance of an application, a = SigComp=20 layer, and a transport layer").
 
Now, the = solutions:
 
-=20 One is to let decompressor dispatcher do the=20 demultiplexing (I won't repeat how it can be done), which means all = bytes=20 received on a port must go through SigComp layer first. This follows the = SigComp=20 architecture in RFC 3320. It makes the layering more clean, = i.e.,=20 (de)compression and (de)multiplexing is handled completely by SigComp = layer. The=20 drawback is a bit redundancy in the sense that the decompressor = dispatcher=20 performs some parsing that the application layer will later do again.=20
 
- The=20 other one is to let the application do the demultiplexing as you = described=20 below. That means all received data must go through = application=20 first.
 
In my=20 view, either one will work and the choice is a=20 local implementation issue (although the latter is not described in = RFC=20 3320). The difference boils down to where do put the demultiplexing = function. It's a matter of preference of SW coding.=20 However, what is NOT an = implementation issue is=20 that - looking at transport layer - a receiving endpoint = must=20 expect it may receive uncompressed messages interspersed with SigComp = messages=20 on the same port and demultiplex them using either of the above = approaches (or=20 any other working solutions). This needs to be spelled out in a=20 document.
 
BR,
Zhigang
 
-----Original Message-----
From: ext Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: April 03, 2003 = 8:24=20 AM
To: Liu Zhigang.C (NRC/Dallas); Sugar Robert=20 (NET/Budapest)
Cc: rohc@ietf.org;=20 sipping@ietf.org
Subject: RE: [rohc] RE: [Sipping] SIGCOMP = and large=20 binary content SIP messages

Zhigang,

If I understand the solution described by Robert = correctly,=20 then the problem you describe below does not arise. Your problem seems = to=20 assume that demultiplexing of compressed and uncompressed messages = will be=20 done before the SIP parser is invoked, based on the 11111xxx=20 delimiter.

My understanding is that messages are passed = directly to the=20 SIP parser. This software must be aware that SIGCOMP may be used, and = checks=20 the first octet of the input stream. If this is 11111xxx then it uses = the=20 sigcomp delimeter OxFFFF to find the end of the compressed message, = and then=20 sends it to the decompressor. If the first octets is not 11111xxx then = it just=20 starts parsing as normal.

The only assumption is that the SIP parser has its = own way of=20 recognising the end of an uncompressed message.

Regards...Mark

> -----Original Message-----
>=20 From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]=20
> Sent: 01 April 2003 14:44
>=20 To: Robert.Sugar@nokia.com
> Cc: = rohc@ietf.org;=20 sipping@ietf.org
> Subject: RE: [rohc] = RE:=20 [Sipping] SIGCOMP and large binary content SIP
>=20 messages
>
> =
> Robert,
>=20
> >  I don't think it is a = problem with=20 SigComp multiplexing, but
> > more = like a SIP=20 internal issue. What if there is a TCP stream
>=20 > of SIP messages and the Content-Length header is missing or=20
> > false? They will screw up the same = way with=20 or without
> > SigComp. =
>
> Since TCP is a reliable = transport,=20 this only happens for a
> mis-behaved SIP = sender.=20 But that is not the "multiplexing" problem
> I=20 mentioned below, which happens even "during normal functioning"=20
> (see below).
>=20
> > During normal functioning both SIP = and=20 SigComp
> > provide their own flow = separation=20 mechanism and they work just fine.
>=20
> I don't think so. That is what I = intended to show=20 by the example,
> i.e. the issue to = "multiplex=20 uncompressed application messages and
> = SigComp=20 messages on the same port". One solution, as I mentioned =
> before, is to require sigcomp receiver has the ability = to=20 parse
> uncompressed application messages = and=20 detect the end.
>
> (Of=20 course, I saw Carsten's email and I need understand his =
> point of view, which says there is no such = "multiplexing"=20 and
> it is not possible and = necessary.)=20
>
> BR, =
> Zhigang
>=20 _______________________________________________
>=20 Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping= =20
> This list is for NEW development of the = application of=20 SIP
> Use = sip-implementors@cs.columbia.edu for=20 questions on current sip
> Use = sip@ietf.org for new=20 developments of core SIP
>=20

------_=_NextPart_001_01C2FA06.9112EBC2-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 3 13:07:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04718 for ; Thu, 3 Apr 2003 13:07:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33I9O510318 for rohc-archive@odin.ietf.org; Thu, 3 Apr 2003 13:09:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33I9OK10315 for ; Thu, 3 Apr 2003 13:09:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04688 for ; Thu, 3 Apr 2003 13:06:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33I9AK10291; Thu, 3 Apr 2003 13:09:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33I87K10229 for ; Thu, 3 Apr 2003 13:08:07 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04633 for ; Thu, 3 Apr 2003 13:05:15 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h33I7gRs017926 for ; Thu, 3 Apr 2003 20:07:42 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2A4R6R0V>; Thu, 3 Apr 2003 20:07:43 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Thu, 3 Apr 2003 20:05:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > However, what is NOT an implementation issue is that - > looking at transport layer - a receiving endpoint must > expect it may receive uncompressed messages interspersed > with SigComp messages on the same port and demultiplex > them using either of the above approaches (or any other > working solutions). This needs to be spelled out in a > document. From what I remember, this was not the purpose of the multiplexing mechanism in SigComp. The mechanism in SigComp is not there to allow multiplexing of SigComp messages and raw messages within the same connection, but only to identify whether the connection uses SigComp or not. Carsten provided a clarification on this issue, which was rather clear, something we should put in the SigComp implementer's guide. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 3 15:19:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11524 for ; Thu, 3 Apr 2003 15:19:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33KLdd25245 for rohc-archive@odin.ietf.org; Thu, 3 Apr 2003 15:21:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KLdK25242 for ; Thu, 3 Apr 2003 15:21:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11510 for ; Thu, 3 Apr 2003 15:18:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KLQK25223; Thu, 3 Apr 2003 15:21:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KKFK25102 for ; Thu, 3 Apr 2003 15:20:15 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11353; Thu, 3 Apr 2003 15:17:19 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33KJlH28176; Thu, 3 Apr 2003 14:19:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 14:19:47 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 12:19:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Thu, 3 Apr 2003 14:19:31 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL6DB4VislM+eMARAWuaGikcQTswwAC3c+g To: , Cc: X-OriginalArrivalTime: 03 Apr 2003 20:19:33.0719 (UTC) FILETIME=[571BAE70:01C2FA1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33KKFK25103 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > The mechanism in > SigComp is not there to allow multiplexing of SigComp > messages and raw messages within the same connection, > but only to identify whether the connection uses > SigComp or not. If by "multiplex uncompressed application messages and SigComp messages on the same port" RFC 3320 does not mean what I thought it meant, I'd propose to add mutltiplexing (in the true meaning) capability as an extension to RFC 3320. For details and arguments, please see my previous email: http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01423.html BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 3 16:56:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16112 for ; Thu, 3 Apr 2003 16:56:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33LwRG02367 for rohc-archive@odin.ietf.org; Thu, 3 Apr 2003 16:58:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LwRK02364 for ; Thu, 3 Apr 2003 16:58:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16070 for ; Thu, 3 Apr 2003 16:55:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LwDK02339; Thu, 3 Apr 2003 16:58:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LvQK02247 for ; Thu, 3 Apr 2003 16:57:26 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16043; Thu, 3 Apr 2003 16:54:27 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33Lv3Z28728; Thu, 3 Apr 2003 15:57:03 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 15:56:56 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 15:56:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Thu, 3 Apr 2003 15:56:54 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL1fk3vswgjGlylR6KGvyjVp1H/TwEn+5mQ To: , , Cc: , X-OriginalArrivalTime: 03 Apr 2003 21:56:56.0416 (UTC) FILETIME=[F1A07E00:01C2FA2B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33LvQK02248 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Richard, > Regarding point a), I don't see how this can be done without > talking about specific protocols. I agree if you mean the exact logic (see below). But what I had in mind for a) is a generic or abstract logic as follows: 0. Endpoint B informs endpoint A that it supports SigComp AND multiplexing of uncompressed message and SigComp message on a TCP connection. This should be part of the SigComp discovery. 1. Endpoint B reads in one byte. 2. If the first 5 MSB of the byte is 11111. this is the beginning of a SigComp message or a SigComp message delimiter (0xFFFF). Endpoint B enters "SigComp parsing mode" and processes byte stream according to SigComp until it encounters END-MESSAGE instruction or Sigcomp delimiter. When that happens, go to 1. 3. Else, this is the beginning of an uncompressed message. Endpoint B enters "uncompressed parsing mode" and parses the byte stream according to the delimiting scheme of the application messages. When reaching the end of application message, go to 1. Note: it is assumed that uncompressed application messages start with UTF-8 encoded character. Otherwise, the logic does not work. Note: the sigcomp can deliver the bytes to application layer either as they are arriving or at the end of the application message. Note: this abstract demultiplexing logic can be either done at SigComp layer (decompressor dispatcher) or at application layer. That is a choice of local implementation. Now, back to your comment. I certainly agree with you that detecting end of application message in Step 3 depends on a particular application protocol. But other than that, the rest is pretty generic. We can consider the above as the abstract logic that will be "instantiated" when binding SigComp to a particular application. > Regarding point b), it might be good to have some recommendations > on how to implement an efficient compressor for messages with > binary content. Yes. > A suitable home for these would be the SigComp > User Guide, which already talks about the various different > compressors that can be used in conjunction with SigComp. OK. I don't mind where it ends up as long as the issue finds a home. I can provide some text. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 3 19:17:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20985 for ; Thu, 3 Apr 2003 19:17:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h340JYe14317 for rohc-archive@odin.ietf.org; Thu, 3 Apr 2003 19:19:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340JYK14314 for ; Thu, 3 Apr 2003 19:19:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20982 for ; Thu, 3 Apr 2003 19:16:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340JGK14280; Thu, 3 Apr 2003 19:19:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340IgK14247 for ; Thu, 3 Apr 2003 19:18:42 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20969 for ; Thu, 3 Apr 2003 19:15:41 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h340I8H07608 for ; Thu, 3 Apr 2003 18:18:08 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 3 Apr 2003 18:18:07 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 18:17:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA3F.83D1FA1F" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Thu, 3 Apr 2003 18:17:02 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Thread-Index: AcL577PGmAoo5ePvQKe+pm53Lf8dWgAPhCQwAAQgtNA= To: X-OriginalArrivalTime: 04 Apr 2003 00:17:02.0492 (UTC) FILETIME=[8409E5C0:01C2FA3F] Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FA3F.83D1FA1F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Resend (original message exceeded 40 KB limit, so I removed older = discussion texts.) Zhigang =20 -----Original Message----- From: Liu Zhigang.C (NRC/Dallas)=20 Sent: April 03, 2003 6:08 PM To: 'ext Mark Watson'; 'Price, Richard'; cabo@tzi.org; = Lars-Erik.Jonsson@epl.ericsson.se Cc: rohc@ietf.org; sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = mes sages Mark, =20 This is exactly the concern I have regarding the SigComp performance = implication. I see this as a question of *what* states to create. More = precisely, a compressor should create only "useful" state(s) from the = text part(s) of a message while avoiding creating "garbage" state(s) = from the binary part(s).=20 =20 (Of course, it's possible that the binary part may also repeat across = messages and thus become useful. But I wouldn't go there for = simplicity.) =20 So, how can a compressor achieve that? Below are ideas I can think of. = If they are correct, I can compile more "formal" text to be added to the = SigComp user guide. =20 There are two steps involved. First, the compressor needs to know if = current message to be compressed contain binary parts, and if yes, where = they are located in the message. Second, the compressor needs to make = sure it can selectively create states on the decompressor side. =20 For the first step, the best thing can happen is that the application = (SIP in this case) gives hint to sigcomp compressor. This is possible, = since it is a matter of local interface between application and sigcomp = layer within the same endpoint. Otherwise (i.e. no help from = application), the compressor has to figure it out by itself. In general, = this seems to be a difficult problem to solve (if possible at all). But = there are a few simple and practical approaches one can consider. =20 For example, the compressor can check the compression ratio after = compressing the message. If it is close to 1, that is a hint that the = current message probably contains large binary content. The compressor = can choose not to create any state from current message. However, the = compressor may miss a small text segment in the message that turns out = being repeated later in the subsequent messages. The positive side is = that at least the compressor can avoid creating "garbage states".=20 =20 Another factor to make a compressor's (or rather implementer's) life = easier: we can assume that application messages have two parts, namely, = a UTF-8 encoded part at the beginning followed by a binary part. (Note = this is the case at least for SIP.) Then, the compressor can identify = the UTF-8 part (by parsing) and use it to create state. This also has a = good side-effect: compressor can avoid compressing the remaining binary = part.=20 =20 Now to the second step: creating state on decompressor side. One issue I = see is the limitation of decompression memory. On the decompressor side, = the large binary content may overwrite text content previously stored in = the ring/history buffer (part of the UDVM buffer). One solution is that = the compressor should "segment" one large application message into = multiple sigcomp messages, so that one of them contains only text data. = This avoids the overwriting problem. (Note: I don't think this works for = SigComp over UDP. But on the other hand, large SIP messages must be = carried over TCP, not UDP.) =20 BR, Zhigang =20 -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: April 03, 2003 8:35 AM To: 'Price, Richard'; Liu Zhigang.C (NRC/Dallas); cabo@tzi.org; = Lars-Erik.Jonsson@epl.ericsson.se Cc: rohc@ietf.org; sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = mes sages Richard, all,=20 The issue I would like to see addressed is as follows:=20 The text part of SIP/SDP is obviously highly compressible using very = simple algorithms which refer back to previous parts of the = message/earlier messages. In fact, subsequent messages in a SIP dialog = seem to consist almost entirely of repeated text from previous messages. So, it seems important to me that large binary content in SIP messages = does not destroy state that will be useful in compressing subsequent = messages. In a wireless environment, the principle advantage of compression is = reduction in the time taken to actually send the message over the = wireless link (this may even be more important than the overall = reduction in signalling bandwidth). Now if the message contains large binary content, then of course we are = 'out of luck' on the message transfer time stakes, but this shouldn't = affect subsequent messages. I believe we should document recommendations to SIGCOMP compressor = designers to ensure this aspect is not overlooked (although it is not = immediately clear to me how the compressor (being unaware of the SIP = message structure) might achieve this.) Is this something that would be appropriate to item 4 below ?=20 Regards...Mark =20 ------_=_NextPart_001_01C2FA3F.83D1FA1F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes = sages
Resend=20 (original message exceeded 40 KB limit, so I removed older discussion=20 texts.)
Zhigang
 
-----Original Message-----
From: Liu Zhigang.C = (NRC/Dallas)=20
Sent: April 03, 2003 6:08 PM
To: 'ext Mark Watson'; = 'Price,=20 Richard'; cabo@tzi.org; Lars-Erik.Jonsson@epl.ericsson.se
Cc:=20 rohc@ietf.org; sipping@ietf.org
Subject: RE: [rohc] RE: = [Sipping]=20 SIGCOMP and large binary content SIP mes sages

Mark,
 
This=20 is exactly the concern I have regarding the SigComp performance = implication. I=20 see this as a question of *what* states to create. More precisely, a = compressor=20 should create only "useful" state(s) from the text part(s) of a message = while=20 avoiding creating "garbage" state(s) from the binary part(s).=20
 
(Of=20 course, it's possible that the binary part may also repeat = across=20 messages and thus become useful. But I wouldn't go there for=20 simplicity.)
 
So,=20 how can a compressor achieve that? Below are ideas I can = think=20 of. If they are correct, I can compile more "formal" text to be added to = the=20 SigComp user guide.
 
There=20 are two steps involved. First, the compressor needs to know if = current=20 message to be compressed contain binary parts, and if yes, where they = are=20 located in the message. Second, the compressor needs to make sure it can = selectively create states on the decompressor side.
 
For=20 the first step, the best thing can happen is that = the application (SIP=20 in this case) gives hint to sigcomp compressor. This is possible, = since it=20 is a matter of local interface between application and sigcomp = layer within=20 the same endpoint. Otherwise (i.e. no help from application), the = compressor=20 has to figure it out by itself. In general, this seems to be a difficult = problem=20 to solve (if possible at all). But there are a few simple and practical=20 approaches one can consider.
 
For=20 example, the compressor can check the compression ratio after = compressing the=20 message. If it is close to 1, that is a hint that the current = message=20 probably contains large binary content. The compressor can choose not to = create=20 any state from current message. However, the compressor may miss a small = text=20 segment in the message that turns out being repeated later in the = subsequent=20 messages. The positive side is that at least the compressor can avoid = creating=20 "garbage states".
 
Another factor to make a compressor's (or rather = implementer's) life=20 easier: we can assume that application messages have two = parts,=20 namely, a UTF-8 encoded part at the beginning followed by a binary part. = (Note=20 this is the case at least for SIP.) Then, the compressor can identify = the UTF-8=20 part (by parsing) and use it to create state. This also = has a=20 good side-effect: compressor can avoid compressing the = remaining=20 binary part.
 
Now to=20 the second step: creating state on decompressor side. One issue I see is = the=20 limitation of decompression memory. On the decompressor side, the large = binary=20 content may overwrite text content previously stored in the ring/history = buffer=20 (part of the UDVM buffer). One solution is that the compressor = should=20 "segment" one large application message into multiple sigcomp messages, = so that=20 one of them contains only text data. This avoids the overwriting = problem.=20 (Note: I don't think this works for SigComp over UDP. But on = the other=20 hand, large SIP messages must be carried over TCP, not = UDP.)
 
BR,
Zhigang
 
-----Original Message-----
From: ext Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: April 03, 2003 = 8:35=20 AM
To: 'Price, Richard'; Liu Zhigang.C (NRC/Dallas); = cabo@tzi.org;=20 Lars-Erik.Jonsson@epl.ericsson.se
Cc: rohc@ietf.org;=20 sipping@ietf.org
Subject: RE: [rohc] RE: [Sipping] SIGCOMP = and large=20 binary content SIP mes sages

Richard, all,

The issue I would like to see addressed is as = follows:=20

The text part of SIP/SDP is obviously highly = compressible=20 using very simple algorithms which refer back to previous parts of the = message/earlier messages. In fact, subsequent messages in a SIP dialog = seem to=20 consist almost entirely of repeated text from previous = messages.

So, it seems important to me that large binary = content in SIP=20 messages does not destroy state that will be useful in compressing = subsequent=20 messages.

In a wireless environment, the principle advantage = of=20 compression is reduction in the time taken to actually send the = message over=20 the wireless link (this may even be more important than the overall = reduction=20 in signalling bandwidth).

Now if the message contains large binary content, = then of=20 course we are 'out of luck' on the message transfer time stakes, but = this=20 shouldn't affect subsequent messages.

I believe we should document recommendations to = SIGCOMP=20 compressor designers to ensure this aspect is not overlooked (although = it is=20 not immediately clear to me how the compressor (being unaware of the = SIP=20 message structure) might achieve this.)

Is this something that would be appropriate to item = 4 below=20 ?

Regards...Mark   

------_=_NextPart_001_01C2FA3F.83D1FA1F-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 4 03:18:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11010 for ; Fri, 4 Apr 2003 03:18:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h348Lab23844 for rohc-archive@odin.ietf.org; Fri, 4 Apr 2003 03:21:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348LZK23841 for ; Fri, 4 Apr 2003 03:21:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10988 for ; Fri, 4 Apr 2003 03:18:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348LKK23808; Fri, 4 Apr 2003 03:21:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348KQK23779 for ; Fri, 4 Apr 2003 03:20:26 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10893 for ; Fri, 4 Apr 2003 03:17:15 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h348Jg312747 for ; Fri, 4 Apr 2003 09:19:43 +0100 (BST) Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HG1MLYLF; Fri, 4 Apr 2003 09:19:28 +0100 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 09:19:23 +0100 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'rohc@ietf.org'" Subject: FW: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Fri, 4 Apr 2003 09:19:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA82.CC6BD86C" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FA82.CC6BD86C Content-Type: text/plain; charset="iso-8859-1" Resent to rohc as first try didn't work... -----Original Message----- From: Watson, Mark [MOP:EP10:EXCH] Sent: 03 April 2003 15:24 To: 'zhigang.c.liu@nokia.com'; Robert.Sugar@nokia.com Cc: rohc@ietf.org; sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Zhigang, If I understand the solution described by Robert correctly, then the problem you describe below does not arise. Your problem seems to assume that demultiplexing of compressed and uncompressed messages will be done before the SIP parser is invoked, based on the 11111xxx delimiter. My understanding is that messages are passed directly to the SIP parser. This software must be aware that SIGCOMP may be used, and checks the first octet of the input stream. If this is 11111xxx then it uses the sigcomp delimeter OxFFFF to find the end of the compressed message, and then sends it to the decompressor. If the first octets is not 11111xxx then it just starts parsing as normal. The only assumption is that the SIP parser has its own way of recognising the end of an uncompressed message. Regards...Mark > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: 01 April 2003 14:44 > To: Robert.Sugar@nokia.com > Cc: rohc@ietf.org; sipping@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > Robert, > > > I don't think it is a problem with SigComp multiplexing, but > > more like a SIP internal issue. What if there is a TCP stream > > of SIP messages and the Content-Length header is missing or > > false? They will screw up the same way with or without > > SigComp. > > Since TCP is a reliable transport, this only happens for a > mis-behaved SIP sender. But that is not the "multiplexing" problem > I mentioned below, which happens even "during normal functioning" > (see below). > > > During normal functioning both SIP and SigComp > > provide their own flow separation mechanism and they work just fine. > > I don't think so. That is what I intended to show by the example, > i.e. the issue to "multiplex uncompressed application messages and > SigComp messages on the same port". One solution, as I mentioned > before, is to require sigcomp receiver has the ability to parse > uncompressed application messages and detect the end. > > (Of course, I saw Carsten's email and I need understand his > point of view, which says there is no such "multiplexing" and > it is not possible and necessary.) > > BR, > Zhigang > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > ------_=_NextPart_001_01C2FA82.CC6BD86C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = messages

Resent to rohc as first try didn't work...

-----Original Message-----
From: Watson, Mark [MOP:EP10:EXCH]
Sent: 03 April 2003 15:24
To: 'zhigang.c.liu@nokia.com'; = Robert.Sugar@nokia.com
Cc: rohc@ietf.org; sipping@ietf.org
Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large = binary content SIP
messages


Zhigang,

If I understand the solution described by Robert = correctly, then the problem you describe below does not arise. Your = problem seems to assume that demultiplexing of compressed and = uncompressed messages will be done before the SIP parser is invoked, = based on the 11111xxx delimiter.

My understanding is that messages are passed directly = to the SIP parser. This software must be aware that SIGCOMP may be = used, and checks the first octet of the input stream. If this is = 11111xxx then it uses the sigcomp delimeter OxFFFF to find the end of = the compressed message, and then sends it to the decompressor. If the = first octets is not 11111xxx then it just starts parsing as = normal.

The only assumption is that the SIP parser has its = own way of recognising the end of an uncompressed message.

Regards...Mark

> -----Original Message-----
> From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: 01 April 2003 14:44
> To: Robert.Sugar@nokia.com
> Cc: rohc@ietf.org; sipping@ietf.org
> Subject: RE: [rohc] RE: [Sipping] SIGCOMP and = large binary content SIP
> messages
>
>
> Robert,
>
> >  I don't think it is a problem with = SigComp multiplexing, but
> > more like a SIP internal issue. What if = there is a TCP stream
> > of SIP messages and the Content-Length = header is missing or
> > false? They will screw up the same way = with or without
> > SigComp.
>
> Since TCP is a reliable transport, this only = happens for a
> mis-behaved SIP sender. But that is not the = "multiplexing" problem
> I mentioned below, which happens even = "during normal functioning"
> (see below).
>
> > During normal functioning both SIP and = SigComp
> > provide their own flow separation = mechanism and they work just fine.
>
> I don't think so. That is what I intended to = show by the example,
> i.e. the issue to "multiplex uncompressed = application messages and
> SigComp messages on the same port". One = solution, as I mentioned
> before, is to require sigcomp receiver has the = ability to parse
> uncompressed application messages and detect = the end.
>
> (Of course, I saw Carsten's email and I need = understand his
> point of view, which says there is no such = "multiplexing" and
> it is not possible and necessary.)
>
> BR,
> Zhigang
> = _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the = application of SIP
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sip@ietf.org for new developments of core = SIP
>

------_=_NextPart_001_01C2FA82.CC6BD86C-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 4 03:19:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11028 for ; Fri, 4 Apr 2003 03:19:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h348LlI23866 for rohc-archive@odin.ietf.org; Fri, 4 Apr 2003 03:21:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348LkK23863 for ; Fri, 4 Apr 2003 03:21:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10998 for ; Fri, 4 Apr 2003 03:18:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348LLK23824; Fri, 4 Apr 2003 03:21:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h348KsK23789 for ; Fri, 4 Apr 2003 03:20:54 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10900 for ; Fri, 4 Apr 2003 03:17:40 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h348K7312776 for ; Fri, 4 Apr 2003 09:20:07 +0100 (BST) Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HG1MLY3B; Fri, 4 Apr 2003 09:20:08 +0100 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 09:19:45 +0100 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'rohc@ietf.org'" Subject: FW: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Fri, 4 Apr 2003 09:19:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA82.E90CD520" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2FA82.E90CD520 Content-Type: text/plain; charset="iso-8859-1" Resent to rohc as first try didn't work... -----Original Message----- From: Watson, Mark [MOP:EP10:EXCH] Sent: 03 April 2003 15:35 To: 'Price, Richard'; 'zhigang.c.liu@nokia.com'; cabo@tzi.org; Lars-Erik.Jonsson@epl.ericsson.se Cc: rohc@ietf.org; sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Richard, all, The issue I would like to see addressed is as follows: The text part of SIP/SDP is obviously highly compressible using very simple algorithms which refer back to previous parts of the message/earlier messages. In fact, subsequent messages in a SIP dialog seem to consist almost entirely of repeated text from previous messages. So, it seems important to me that large binary content in SIP messages does not destroy state that will be useful in compressing subsequent messages. In a wireless environment, the principle advantage of compression is reduction in the time taken to actually send the message over the wireless link (this may even be more important than the overall reduction in signalling bandwidth). Now if the message contains large binary content, then of course we are 'out of luck' on the message transfer time stakes, but this shouldn't affect subsequent messages. I believe we should document recommendations to SIGCOMP compressor designers to ensure this aspect is not overlooked (although it is not immediately clear to me how the compressor (being unaware of the SIP message structure) might achieve this.) Is this something that would be appropriate to item 4 below ? Regards...Mark > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: 26 March 2003 13:58 > To: 'zhigang.c.liu@nokia.com'; cabo@tzi.org; > Lars-Erik.Jonsson@epl.ericsson.se > Cc: rohc@ietf.org; sipping@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > mes sages > > > Hi, > > I think that the issue with SigComp and large binary > content SIP messages is part of a more general issue - > namely that before using SigComp to compress a particular > application we need to standardise the following: > > 1. Mechanism for SigComp discovery > 2. Resources offered by SigComp > 3. How to delimit messages > 4. When to save state > > Currently the SIPPING WG has provided RFCs for 1 and 2, > but not for 3 and 4. It would be useful to get a draft > out for these ASAP, as it would clarify several issues on > how to get SigComp working with SIP (including the issue > with large binary content SIP messages). > > > Unless someone objects, I'll submit it in ROHC. > > I think that any WG draft should be a product of the > SIPPING WG, because the proposed solution for delimiting > SigComp messages will need to take into account the > behaviour of SIP itself (or we won't be able to multiplex > SigComp and SIP messages on the same port). However, it > would be good to get the ROHC WG involved in generating > the draft as well! > > Regards, > > Richard > > P.S. For anyone who's interested, the mechanisms that > particular applications need to provide before they can > use SigComp are as follows... > > ------------------------------------------------------ > > 1. Mechanism for SigComp discovery > > - How does the application know when to use SigComp? > > For SIP this issue is already sorted (RFC 3486). > > ------------------------------------------------------ > > 2. Resources offered by SigComp > > - Does the application need to offer more than the > minimum amount of resources? > > - Does the application need any extra state (e.g. > a static dictionary)? > > For SIP we've already got a static dictionary (RFC 3485). > However, we haven't currently discussed how much memory > should be provided in a SigComp implementation for SIP. > If we don't specify a value then SigComp defaults to the > minimum possible (2K), which is rather tight for some of > the more generously sized SIP messages! > > ------------------------------------------------------ > > 3. How to delimit messages > > - How does the application distinguish between > SigComp messages and uncompressed messages? > > - Is the application allowed to use "continuous mode"? > > This is the issue that's been raised for large binary > content SIP messages. If we want to send a mix of > uncompressed and SigComp messages within the same TCP > connection, how do we delimit the end of one message and > the start of another? > > A related issue is how to handle very large SIP messages > (> 64K). SigComp is able to compress large SIP messages > by using "continuous mode", where the message boundaries > are ignored completely and the application data is just > transmitted as a stream. However, this mode of operation > raises some additional security issues, so it's up to the > SIPPING WG to decide whether or not to use it in SigComp > for SIP. > > ------------------------------------------------------ > > 4. When to save state > > - How much security is needed in order to save state? > > - Which messages belong to each state "compartment"? > > - How long should the application keep state? > > This is quite an important issue that doesn't seem to > have been discussed in the SIPPING WG. It's up to the > application whether or not to let SigComp save state, > and for interoperability it's important to have at > least a general idea of how long to keep saved state, > when to reject state due to insufficient security etc. > > ------------------------------------------------------ > > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: Tuesday, March 25, 2003 6:00 PM > > To: cabo@tzi.org; Lars-Erik.Jonsson@epl.ericsson.se > > Cc: rohc@ietf.org; sipping@ietf.org > > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary > content SIP > > messages > > > > > > Hi Carsten and Lars-Erik, > > > > I've volunteered to submit a personal draft on this issue. From > > ROHC WG chairs' point of view, do you think this is the way > > to proceed? > > > > Of course, I understood during the IETF56 that Carsten had some > > doubts on whether this is indeed an issue. My email below explained > > the issue a bit. I don't know if it's clear. Either way, we > > can continue discuss this in ROHC mailing list > > > http://www1.ietf.org/mail-archive/working-groups/sipping/curre > nt/msg04115.html > > > > BR, > > Zhigang > > > > > -----Original Message----- > > > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: March 13, 2003 9:55 AM > > > To: Gonzalo.Camarillo@lmf.ericsson.se > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > > mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org > > > Subject: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > > > messages > > > > > > > > > I agree. How to handling binary content is a generic issue for any > > > application messages. What I have in mind is to give generic > > > descriptions/requirements (mainly on the SigComp receiver > parsing part), > > > then touch on SIP (perhaps RTSP too) as a particular example. > > > > > > Unless someone objects, I'll submit it in ROHC. > > > > > > Zhigang > > > > > > > > > > -----Original Message----- > > > > From: ext Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: March 13, 2003 5:36 AM > > > > To: Liu Zhigang.C (NRC/Dallas) > > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > > > mwatson@nortelnetworks.com; sipping@ietf.org > > > > Subject: Re: [Sipping] SIGCOMP and large binary content > SIP messages > > > > > > > > > > > > Zhigang, > > > > > > > > you can submit that draft to ROHC. SIPPING can review > it afterwards. > > > > IMO, the competence needed to generate this draft can > be found more > > > > easily in ROHC than in SIPPING. > > > > > > > > Besides, you could use SigComp to compress RTSP > messages, for instance > > > > And RTSP is not handle by SIPPING either. > > > > > > > > Gonzalo > > > > > > > > zhigang.c.liu@nokia.com wrote: > > > > > > > > > > Yes, that is also what I had in mind for SIP. But my > point is that > > > > > a SigComp receiver now needs to have some knowledge > about application > > > > > message format and do parsing to determine the end of > an uncompressed > > > > > message. This is something new (or at least > unspecified) in RFC 3320 > > > > > and needs to be spelled out in a new (standard track) > RFC. The document > > > > > will be short, but I think it's needed for interoperability. > > > > > > > > > > I'll write up an I-D and submit it after IETF 56. But > I'd like to know > > > > > if folks in SIPPING think it should be done here or in ROHC. > > > > > > > > > > Zhigang > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > > > > Sent: March 11, 2003 9:03 PM > > > > > > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus > > > > > > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org > > > > > > Subject: RE: [Sipping] SIGCOMP and large binary > content SIP messages > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: zhigang.c.liu@nokia.com > [mailto:zhigang.c.liu@nokia.com] > > > > > > > > > > > > > > Having binary content in SIP messages may have > two impacts on > > > > > > > SigComp: > > > > > > > > > > > > > > a) multiplexing of uncompressed messages with > SigComp messages on the > > > > > > > same port. > > > > > > ... > > > > > > > For a), it is only an issue for SigComp/TCP, not > SigComp/UDP (where one > > > > > > > SigComp message maps to one UDP packet). Adam's > point 1 and 2 are related > > > > > > > to this. As to point 1, I think the SigComp > receiver still needs to know > > > > > > > (somehow) the end of an uncompressed message, or > at least the end of the > > > > > > > binary part of each SIP messages. Otherwise, a > bit pattern 11111 in > > > > > > > the binary part will be mistaken by SigComp as > the beginning of a SigComp > > > > > > > message. As to point 2, I would add that the > delimiter 0xFFFF can appear > > > > > > > at the both the beginning and the end of a > SigComp message. So, the > > > > > > > receiver needs to have the same parsing logic > just mentioned for bit pattern > > > > > > > 11111. > > > > > > > > > > > > This isn't any more of an issue than it is without > SigComp. SIP > > > > > > messages provide their own framing, and SigComp > messages do the > > > > > > same. They can be trivially mixed on the same stream: > > > > > > > > > > > > 1. Peek at the first byte waiting in the stream. > > > > > > > > > > > > 2. If it is 0xf8 or higher, the next message in the > stream is > > > > > > a SigComp message. The message continues until a > 0xFFFF is > > > > > > encountered in the stream. > > > > > > > > > > > > 3. Otherwise, the next message in the stream is a > SIP message. > > > > > > Read the stream until a CR/LF/CR/LF is encountered. Parse > > > > > > the headers, and then read the number of bytes specified > > > > > > in the "Content-Length" header. > > > > > > > > > > > > 4. Return to step 1. > > > > > > > > > > > > /a > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > ------_=_NextPart_001_01C2FA82.E90CD520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = mes sages

Resent to rohc as first try didn't work...

-----Original Message-----
From: Watson, Mark [MOP:EP10:EXCH]
Sent: 03 April 2003 15:35
To: 'Price, Richard'; 'zhigang.c.liu@nokia.com'; = cabo@tzi.org;
Lars-Erik.Jonsson@epl.ericsson.se
Cc: rohc@ietf.org; sipping@ietf.org
Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large = binary content SIP
mes sages


Richard, all,

The issue I would like to see addressed is as = follows:

The text part of SIP/SDP is obviously highly = compressible using very simple algorithms which refer back to previous = parts of the message/earlier messages. In fact, subsequent messages in = a SIP dialog seem to consist almost entirely of repeated text from = previous messages.

So, it seems important to me that large binary = content in SIP messages does not destroy state that will be useful in = compressing subsequent messages.

In a wireless environment, the principle advantage of = compression is reduction in the time taken to actually send the message = over the wireless link (this may even be more important than the = overall reduction in signalling bandwidth).

Now if the message contains large binary content, = then of course we are 'out of luck' on the message transfer time = stakes, but this shouldn't affect subsequent messages.

I believe we should document recommendations to = SIGCOMP compressor designers to ensure this aspect is not overlooked = (although it is not immediately clear to me how the compressor (being = unaware of the SIP message structure) might achieve this.)

Is this something that would be appropriate to item 4 = below ?

Regards...Mark

> -----Original Message-----
> From: Price, Richard [mailto:richard.price@roke.co.uk= ]
> Sent: 26 March 2003 13:58
> To: 'zhigang.c.liu@nokia.com'; = cabo@tzi.org;
> Lars-Erik.Jonsson@epl.ericsson.se
> Cc: rohc@ietf.org; sipping@ietf.org
> Subject: RE: [rohc] RE: [Sipping] SIGCOMP and = large binary content SIP
> mes sages
>
>
> Hi,
>
> I think that the issue with SigComp and large = binary
> content SIP messages is part of a more general = issue -
> namely that before using SigComp to compress a = particular
> application we need to standardise the = following:
>
> 1. Mechanism for SigComp discovery
> 2. Resources offered by SigComp
> 3. How to delimit messages
> 4. When to save state
>
> Currently the SIPPING WG has provided RFCs for = 1 and 2,
> but not for 3 and 4. It would be useful to get = a draft
> out for these ASAP, as it would clarify several = issues on
> how to get SigComp working with SIP (including = the issue
> with large binary content SIP messages).
>
> > Unless someone objects, I'll submit it in = ROHC.
>
> I think that any WG draft should be a product = of the
> SIPPING WG, because the proposed solution for = delimiting
> SigComp messages will need to take into account = the
> behaviour of SIP itself (or we won't be able to = multiplex
> SigComp and SIP messages on the same port). = However, it
> would be good to get the ROHC WG involved in = generating
> the draft as well!
>
> Regards,
>
> Richard
>
> P.S. For anyone who's interested, the = mechanisms that
> particular applications need to provide before = they can
> use SigComp are as follows...
>
> = ------------------------------------------------------
>
> 1. Mechanism for SigComp discovery
>
>    - How does the application = know when to use SigComp?
>
> For SIP this issue is already sorted (RFC = 3486).
>
> = ------------------------------------------------------
>
> 2. Resources offered by SigComp
>
>    - Does the application need = to offer more than the
>      minimum amount of = resources?
>
>    - Does the application need = any extra state (e.g.
>      a static = dictionary)?
>
> For SIP we've already got a static dictionary = (RFC 3485).
> However, we haven't currently discussed how = much memory
> should be provided in a SigComp implementation = for SIP.
> If we don't specify a value then SigComp = defaults to the
> minimum possible (2K), which is rather tight = for some of
> the more generously sized SIP messages!
>
> = ------------------------------------------------------
>
> 3. How to delimit messages
>
>    - How does the application = distinguish between
>      SigComp messages = and uncompressed messages?
>
>    - Is the application allowed = to use "continuous mode"?
>
> This is the issue that's been raised for large = binary
> content SIP messages. If we want to send a mix = of
> uncompressed and SigComp messages within the = same TCP
> connection, how do we delimit the end of one = message and
> the start of another?
>
> A related issue is how to handle very large SIP = messages
> (> 64K). SigComp is able to compress large = SIP messages
> by using "continuous mode", where the = message boundaries
> are ignored completely and the application data = is just
> transmitted as a stream. However, this mode of = operation
> raises some additional security issues, so it's = up to the
> SIPPING WG to decide whether or not to use it = in SigComp
> for SIP.
>
> = ------------------------------------------------------
>
> 4. When to save state
>
>    - How much security is needed = in order to save state?
>
>    - Which messages belong to = each state "compartment"?
>
>    - How long should the = application keep state?
>
> This is quite an important issue that doesn't = seem to
> have been discussed in the SIPPING WG. It's up = to the
> application whether or not to let SigComp save = state,
> and for interoperability it's important to have = at
> least a general idea of how long to keep saved = state,
> when to reject state due to insufficient = security etc.
>
> = ------------------------------------------------------
>
> > -----Original Message-----
> > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> > Sent: Tuesday, March 25, 2003 6:00 = PM
> > To: cabo@tzi.org; = Lars-Erik.Jonsson@epl.ericsson.se
> > Cc: rohc@ietf.org; sipping@ietf.org
> > Subject: RE: [rohc] RE: [Sipping] SIGCOMP = and large binary
> content SIP
> > messages
> >
> >
> > Hi Carsten and Lars-Erik,
> >
> > I've volunteered to submit a personal = draft on this issue. From
> > ROHC WG chairs' point of view, do you = think this is the way
> > to proceed?
> >
> > Of course, I understood during the IETF56 = that Carsten had some
> > doubts on whether this is indeed an issue. = My email below explained
> > the issue a bit. I don't know if it's = clear. Either way, we
> > can continue discuss this in ROHC mailing = list
> >
> http://www1.ietf.org/mail-archive/working-groups/sippi= ng/curre
> nt/msg04115.html
> >
> > BR,
> > Zhigang
> >
> > > -----Original Message-----
> > > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> > > Sent: March 13, 2003 9:55 AM
> > > To: = Gonzalo.Camarillo@lmf.ericsson.se
> > > Cc: adam@dynamicsoft.com; Isomaki = Markus (NRC/Helsinki);
> > > mwatson@nortelnetworks.com; = sipping@ietf.org; rohc@ietf.org
> > > Subject: [rohc] RE: [Sipping] SIGCOMP = and large binary content SIP
> > > messages
> > >
> > >
> > > I agree. How to handling binary = content is a generic issue for any
> > > application messages. What I have in = mind is to give generic
> > > descriptions/requirements (mainly on = the SigComp receiver
> parsing part),
> > > then touch on SIP (perhaps RTSP too) = as a particular example.
> > >
> > > Unless someone objects, I'll submit = it in ROHC.
> > >
> > > Zhigang
> > >
> > >
> > > > -----Original = Message-----
> > > > From: ext Gonzalo Camarillo =
> [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > Sent: March 13, 2003 5:36 = AM
> > > > To: Liu Zhigang.C = (NRC/Dallas)
> > > > Cc: adam@dynamicsoft.com; = Isomaki Markus (NRC/Helsinki);
> > > > mwatson@nortelnetworks.com; = sipping@ietf.org
> > > > Subject: Re: [Sipping] SIGCOMP = and large binary content
> SIP messages
> > > >
> > > >
> > > > Zhigang,
> > > >
> > > > you can submit that draft to = ROHC. SIPPING can review
> it afterwards.
> > > > IMO, the competence needed to = generate this draft can
> be found more
> > > > easily in ROHC than in = SIPPING.
> > > >
> > > > Besides, you could use SigComp = to compress RTSP
> messages, for instance
> > > > And RTSP is not handle by = SIPPING either.
> > > >
> > > > Gonzalo
> > > >
> > > > zhigang.c.liu@nokia.com = wrote:
> > > > >
> > > > > Yes, that is also what I = had in mind for SIP. But my
> point is that
> > > > > a SigComp receiver now = needs to have some knowledge
> about application
> > > > > message format and do = parsing to determine the end of
> an uncompressed
> > > > > message. This is something = new (or at least
> unspecified) in RFC 3320
> > > > > and needs to be spelled out = in a new (standard track)
> RFC. The document
> > > > > will be short, but I think = it's needed for interoperability.
> > > > >
> > > > > I'll write up an I-D and = submit it after IETF 56. But
> I'd like to know
> > > > > if folks in SIPPING think = it should be done here or in ROHC.
> > > > >
> > > > > Zhigang
> > > > >
> > > > > > -----Original = Message-----
> > > > > > From: ext Adam Roach = [mailto:adam@dynamicsoft.com]
> > > > > > Sent: March 11, 2003 = 9:03 PM
> > > > > > To: Liu Zhigang.C = (NRC/Dallas); Adam Roach; Isomaki Markus
> > > > > > (NRC/Helsinki); = mwatson@nortelnetworks.com; sipping@ietf.org
> > > > > > Subject: RE: [Sipping] = SIGCOMP and large binary
> content SIP messages
> > > > > >
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: = zhigang.c.liu@nokia.com
> [mailto:zhigang.c.liu@nokia.com]
> > > > > > >
> > > > > > > Having binary = content in SIP messages may have
> two impacts on
> > > > > > > SigComp:
> > > > > > >
> > > > > > > a) multiplexing = of uncompressed messages with
> SigComp messages on the
> > > > > > > same port.
> > > > > > ...
> > > > > > > For a), it is = only an issue for SigComp/TCP, not
> SigComp/UDP (where one
> > > > > > > SigComp message = maps to one UDP packet). Adam's
> point 1 and 2 are related
> > > > > > > to this. As to = point 1, I think the SigComp
> receiver still needs to know
> > > > > > > (somehow) the end = of an uncompressed message, or
> at least the end of the
> > > > > > > binary part of = each SIP messages. Otherwise, a
> bit pattern 11111 in
> > > > > > > the binary part = will be mistaken by SigComp as
> the beginning of a SigComp
> > > > > > > message. As to = point 2, I would add that the
> delimiter 0xFFFF can appear
> > > > > > > at the both the = beginning and the end of a
> SigComp message. So, the
> > > > > > > receiver needs to = have the same parsing logic
> just mentioned for bit pattern
> > > > > > > 11111.
> > > > > >
> > > > > > This isn't any more of = an issue than it is without
> SigComp. SIP
> > > > > > messages provide their = own framing, and SigComp
> messages do the
> > > > > > same. They can be = trivially mixed on the same stream:
> > > > > >
> > > > > > 1. Peek at the first = byte waiting in the stream.
> > > > > >
> > > > > > 2. If it is 0xf8 or = higher, the next message in the
> stream is
> > > > > >    a = SigComp message. The message continues until a
> 0xFFFF is
> > > > > >    = encountered in the stream.
> > > > > >
> > > > > > 3. Otherwise, the next = message in the stream is a
> SIP message.
> > > > > >    Read = the stream until a CR/LF/CR/LF is encountered. Parse
> > > > > >    the = headers, and then read the number of bytes specified
> > > > > >    in = the "Content-Length" header.
> > > > > >
> > > > > > 4. Return to step = 1.
> > > > > >
> > > > > > /a
> > > > > >
> > > > > = _______________________________________________
> > > > > Sipping mailing list =
> https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development = of the application of SIP
> > > > Use = sip-implementors@cs.columbia.edu for questions on
> current sip
> > > > Use sip@ietf.org for new = developments of core SIP
> > >
> > > --
> > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > >
> > = _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc=
> > = _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc=
> >
> = _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the = application of SIP
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sip@ietf.org for new developments of core = SIP
>

------_=_NextPart_001_01C2FA82.E90CD520-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 7 06:22:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13868 for ; Mon, 7 Apr 2003 06:22:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37AR2j30183 for rohc-archive@odin.ietf.org; Mon, 7 Apr 2003 06:27:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37AR2830179 for ; Mon, 7 Apr 2003 06:27:02 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13835 for ; Mon, 7 Apr 2003 06:22:22 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37AHJ829894; Mon, 7 Apr 2003 06:17:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37AE2829731 for ; Mon, 7 Apr 2003 06:14:02 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13650 for ; Mon, 7 Apr 2003 06:09:21 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h37ABqRs001887 for ; Mon, 7 Apr 2003 12:11:52 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4SRFK4; Mon, 7 Apr 2003 12:11:53 +0200 Received: by lms001.lu.erisoft.se id MAA09092; Mon, 7 Apr 2003 12:11:56 +0200 (MET DST) Message-ID: <3E914EF9.7088B105@epl.ericsson.se> Date: Mon, 07 Apr 2003 12:12:09 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Lars-Erik Jonsson (EPL)" CC: rohc@ietf.org Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [rohc] Minor comment on Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Lars-Erik, A small suggestion for better clarity - the last sentence of section 3.2 of the IP-only draft - Note further that additional dynamic chains in compressed packets do not have this sequence number at the end of the chain, as SN is present within compressed base headers. - should be moved to section 3.3, and be slightly reformulated to be put in relation to the figure in that same section: Note that the list of dynamic chains for the additional IP headers in compressed packets do not have a sequence number at the end of the chain, as SN is already present within compressed base headers. The reason for this comment is that section 3.2 is about IR packets, and section 3.3 is about compressed packets; howver the note is about a clarification of the format of the compressed packets and not for the format of the IR packets - therefore I find the current location of the note somewhat confusing. Just a though... Regards, /Ghyslain Ghyslain Pelletier Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Luleå, Sweden Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 70 609 27 73 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 7 10:02:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19976 for ; Mon, 7 Apr 2003 10:02:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37E6lA12754 for rohc-archive@odin.ietf.org; Mon, 7 Apr 2003 10:06:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37E6l812750 for ; Mon, 7 Apr 2003 10:06:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19967 for ; Mon, 7 Apr 2003 10:02:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Dv2812200; Mon, 7 Apr 2003 09:57:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Ds8812091 for ; Mon, 7 Apr 2003 09:54:08 -0400 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19648 for ; Mon, 7 Apr 2003 09:49:21 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Apr 2003 14:51:53 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F20E@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Formal notation, combined thread Date: Mon, 7 Apr 2003 14:51:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > > > RP: The notation language itself shouldn't make a distinction > > > > between EPIC-lite and any other encoding method. > > > > > > As I have said above, I think it is important to make a clear > > > distinction between these, as they are so different. That is also > > > what we said last year, when we talked about field encoding vs. > > > compressed header encoding. > > > > As above, I can't see any reason to think of the > > discriminator encodings as "special", or to treat them > > differently in some way. The distinction between the > > various types of encoding method that we made last year > > was only intended to clarify how the notation handles all > > of the different compression techniques needed by ROHC > > profiles. From a technical perspective the notation has > > never given special treatment to the discriminator > > encodings, and I think that it would be confusing and > > unnecessarily restrictive to do so. > > We obviously disagree here. I still believe it is important to > make this distinction. I think that the distinction only makes sense for a very simple header which is encoded in exactly two steps: first compress each field using a choice of one or more field encodings, and then compress the choices that were made by applying a discriminator encoding. In particular, the distinction only works when a single (unique) discriminator encoding is used to encode all of the discriminator flags for the header. There are a number of cases where this isn't the best solution - three that spring to mind are "list", "nbo" and "format". The "list" encoding method works much like list encoding in 3095 - namely that it allows the various list items to turn up in any order, and thus needs some discriminator bits to send this order information to the decompressor. In theory it would be possible to generate these discriminator bits using EPIC-lite: in practice we would get too many packet formats due to the sheer number of possible list orderings. The alternative is just to allow list encoding to create its own discriminator bits, separately from the ones generated by EPIC-lite. The "nbo" encoding method offers implementers a choice of whether to reverse the IP-ID before compressing it. We could encode the resulting choice using EPIC-lite, but this would be inefficient because we would always be sending the choice in every compressed packet. Much better to store an "NBO flag" entry in the context and to use this when deciding how the IP-ID has been encoded. The "format" encoding method is designed to create multiple sets of compressed packet formats. For example, if we wanted to have separate packet formats for UO-mode and for R-mode then we would write the following: example_packet_formats ::= format(uo_mode, r_mode) We could encode the choice of packet formats using EPIC-lite, but we'd lose efficiency because we'd end up sending the choice in every compressed packet. The solution is to create a new context entry to store the choice of packet formats instead. > All field encodings that can send compressed data in more than > one way calls a discriminator function, but any function could > be used, i.e. the notation for a profile can be written independent > of the actual discriminator function that is later chosen. I outlined three cases where the above assumption fails - i.e. you get a field encoding that can send compressed data in more than one way, but where the resulting choice needs to be encoded using a discriminator function other than EPIC-lite. Currently this poses no problem for the notation, because we invoke EPIC-lite just like any other encoding method. Therefore we have control over when to encode the discriminator flags using EPIC-lite, and when a different encoding method would be more appropriate. We'd run into difficulty if we had to use a single (unspecified) discriminator function for every case where compressed data can be sent in more than one way. We'd be forced to use a single method to encode every discriminator, even for the special cases where a different method is more memory efficient or gets a better compression ratio. > > > > RP: If the compressed header formats are created manually then the > > > > ROHC-FN description captures the exact hand-crafted packet > > > > formats - not just the content of the compressed headers, but the > > > > hand-crafted "discriminator" bits as well. > > > > > > OK, but then we would not even need the notation as a tool, if > > > the actual formats (in written form) would just mean the same. > > > > The notation provides a really useful benefit even when > > describing hand-crafted compressed headers, which is the > > extra implementation option of writing a "notation compiler" > > to automatically convert a notated description of the > > packet formats into running code. > > First of all, I think it would be useful to have the notation to > describe what to put in hand made formats, i.e. as a tool in such > a process. Further, I think we would make a mistake if we tried to > make the notation capable of describing hand made formats, as that > would make the notation unnecessary complex, I disagree with the above - in general, there's no relation between the expressive power of a language and its complexity. The current notation is powerful enough to describe hand-crafted packet formats, as we can compress the discriminator bits using any encoding method we like. We can apply EPIC-lite to the whole header or we can use separate discriminator encoding methods for each field (or any combination of the two). This approach also makes the notation rather more simple than the case where the discriminator flags are treated separately. Currently, discriminator flags are treated exactly like any other data that needs to be sent to the decompressor. In particular, we don't need to worry about having new data structures to hold the discriminator flags - they can be stored in the same data structures that we use for the "ordinary" header fields (namely the labels and the context). Moreover we don't have any special syntax for handling the discriminator flags - we can compress them by applying our choice of encoding method (e.g. EPIC-lite) just like we would apply LSB encoding to compress a particular field. > while the reason does not really make sense in my mind. Having a formal description of the packet formats is a huge saving in terms of implementation effort, because it eliminates all of the confusion and misunderstandings that occur when trying to code a complicated set of packet formats by hand. > > > > RP: The big advantage of making the adjustments within ROHC-FN > > > > is that the description of the compressed packet formats remain > > > > machine-readable > > > > > > We are defining standards, which should be human-readable. There > > > are probably disagreements in this regard, but personally I think > > > human-readability is more important than machine-readability. > > > > I agree that human-readability is at least as > > important as machine-readability. However, in > > my opinion a notated set of packet formats is > > actually rather more human-readable than a set > > of packet formats drawn out pictorially. > > Well, protocol headers are usually drawn out pictorially, so that is > what protocol folks are more used to. Pictorial descriptions are generally restricted to simple protocol headers. For more complex protocols it's usual to define the headers via a formal notation, such as ABNF for SIP or ASN.1 for H.323. > > > 7. EPIC-Lite > > > > > > The EPIC and EPIC-Lite terms have been overloaded several times by > > > now, and they actually do not say much about what they really do. > > > If we want to use the "EPIC-Lite" method for "discriminator > > > encoding" and potentially define it in the general notation > > > document, we should come up with a name that tells us what it does. > > > > > > Any ideas? > > > > We originally used the term "EPIC-lite" to mean > > the entire notation-based solution, including > > the notation itself and the complete library of > > encoding methods. The algorithm for generating > > the discriminator bits is actually nothing more than > > ordinary Huffman encoding, so perhaps we could > > just call it that instead? > > Ok, "Ordinary Huffman" (OH), and "Hierarchical Huffman" (HH) then? Sounds ok to me! Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 7 12:32:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26185 for ; Mon, 7 Apr 2003 12:32:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37GagZ25244 for rohc-archive@odin.ietf.org; Mon, 7 Apr 2003 12:36:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Gag825241 for ; Mon, 7 Apr 2003 12:36:42 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26153 for ; Mon, 7 Apr 2003 12:31:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GUB824790; Mon, 7 Apr 2003 12:30:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GTc824644 for ; Mon, 7 Apr 2003 12:29:38 -0400 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25632; Mon, 7 Apr 2003 12:24:46 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Apr 2003 17:27:17 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F20F@rsys002a.roke.co.uk> From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , cabo@tzi.org, Lars-Erik.Jonsson@epl.ericsson.se Cc: rohc@ietf.org, sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Mon, 7 Apr 2003 17:27:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > Regarding point a), I don't see how this can be done without > > talking about specific protocols. > > I agree if you mean the exact logic (see below). But what I had in > mind for a) is a generic or abstract logic as follows: > > 0. Endpoint B informs endpoint A that it supports SigComp AND > multiplexing of uncompressed message and SigComp message on > a TCP connection. This should be part of the SigComp discovery. > > 1. Endpoint B reads in one byte. > > 2. If the first 5 MSB of the byte is 11111. this is the beginning > of a SigComp message or a SigComp message delimiter (0xFFFF). > Endpoint B enters "SigComp parsing mode" and processes byte stream > according to SigComp until it encounters END-MESSAGE instruction > or Sigcomp delimiter. When that happens, go to 1. > > 3. Else, this is the beginning of an uncompressed message. Endpoint > B enters "uncompressed parsing mode" and parses the byte stream > according to the delimiting scheme of the application messages. > When reaching the end of application message, go to 1. > > Now, back to your comment. I certainly agree with you that detecting > end of application message in Step 3 depends on a particular application > protocol. But other than that, the rest is pretty generic. We can > consider the above as the abstract logic that will be "instantiated" > when binding SigComp to a particular application. Hi Zhigang, Both of Step 1 and Step 2 are already documented in the SigComp RFC. If Step 3 never arises then Endpoint B can decompress the entire stream without any problem, using the delimiting scheme from RFC 3320. Step 0 and Step 3 are not defined in RFC 3320, but this is ok because both steps are 100% application-specific. If the endpoint ever reaches Step 3 then there are at least four ways that it could proceed: i) Always fail (i.e. no multiplexing allowed at all). ii) Fail unless it's the very first byte of the stream. This is just enough to allow application and SigComp streams to be multiplexed on the same port, but not enough to multiplex messages on the same stream. iii) Use SigComp-style delimiters for everything (i.e. for both the application and the SigComp messages). iv) Let the application decide where the message ends and when to hand the parsing back to SigComp. It's up to particular applications to decide which strategy is the most appropriate - currently I haven't seen a convincing reason why we need anything more complex than ii) for the case of SIP. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 10 11:01:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23125 for ; Thu, 10 Apr 2003 11:01:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AF76p17313 for rohc-archive@odin.ietf.org; Thu, 10 Apr 2003 11:07:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AF76817302 for ; Thu, 10 Apr 2003 11:07:06 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23098 for ; Thu, 10 Apr 2003 11:00:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AF3P817065; Thu, 10 Apr 2003 11:03:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AF2R817026 for ; Thu, 10 Apr 2003 11:02:27 -0400 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22986 for ; Thu, 10 Apr 2003 10:56:11 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3AEwiI3016896 for ; Thu, 10 Apr 2003 16:58:44 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VDND03N>; Thu, 10 Apr 2003 16:58:45 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Thu, 10 Apr 2003 16:46:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Preliminary minutes from San Francisco Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , ROHCers, Below are preliminary minutes from IETF 56. Please read them ASAP, and respond about potential corrections or additions. I need to have your comments not later than tomorrow, Friday 11th, at 15:00 GMT. Rgds, /Lars-Erik Preliminary minutes of the ROHC WG session at IETF 56 ===================================================== Hilton San Francisco, San Francisco, USA Monday evening, 2003-03-17 Chairs: Carsten Bormann & Lars-Erik Jonsson Reported by: Lars-Erik Jonsson Note takers: Stephen Casner, Christian Schmidt & Mark West Slides are available at http://www.dmn.tzi.org/ietf/rohc Evening session, 19:30-22:00 ---------------------------- * WG admonishments (Jonsson) Lars-Erik reviewed the IETF working group principles, the IETF standardization process and the IPR rules defined by RFC 2026. Meeting time should be used to advance difficult issues, not for presentation of material that can be read from drafts. We assume that people have read the drafts, and what we decide in meetings must be confirmed on the mailing list. * Agenda bashing (Jonsson) Lars-Erik presented the proposed agenda, which was accepted without modifications. Agenda: - Chair admonishments and agenda bashing - WG and document status update - Signaling compression issues - ROHC RTP DS preparations update - Formal header compression notation * WG and document status (Jonsson) Lars-Erik reviewed WG goals, milestones and document status. Five new ROHC RFC's have been published since November, three SigComp documents, the LLA R-mode extension, and the RTP lower layer guidelines. Currently, we have no documents in the RFC editor's queue, but we have two that were just submitted to the IESG, the ROHC MIB and its companion document with terminology and channel mapping examples. The working group is progressing, but slowly. A milestone update was planned after Atlanta, but has not yet happen for various reasons. However, we should be able to do this rather soon. A new document review concept is to be implemented, where each document is required to have "committed reviewers". These reviewers are designated as such by the chairs, preferably on an early stage, and must have agreed to follow the document evolution, to carefully review the whole document, and to respond openly to working group last-call. Committed reviewers should be non-authors, and will be separately acknowledged in documents. The work items not covered by the agenda of this meeting were: - ROHC TCP, which has not progressed as planned due to editor illness, but an update is expected within a few weeks. - Modified RTP/UDP profiles for UDP-Lite compression, where the current individual draft will be resubmitted as a WG draft. - SCTP compression, which is still on hold. The chairs have asked for interest, motivation, industry support, and commitments for doing the actual work, but answers have not really provided that. Carsten noted that we might not understand future usage of SCTP at this point, so attempting a solution now might produce a result that is not really useful. * Signaling compression issues - SigComp Feedback (Roach) Adam Roach gave a quick summary of the changes in the updated draft. Nack information is now at the end of the messages, and can therefore be distinguished from standalone feedback. The TCP behavior has been changed, and a NACK detection mechanisms has been added. There was a question raised whether we should create an IANA registry for the first 32 bytes of UDVM memory space, but the question was never answered or discussed. More people have to look at this, so far the input has been limited. The meeting suggested that the document should be adopted as a WG document, if we get a few committed draft reviewers, and Mark West and Carsten Bormann volunteered for this. Draft: draft-roach-sigcomp-nack-01.txt - SigComp interoperability report (West) Mark West gave a report from the first SigComp interoperability testing, conducted at SIPit. The point was primarily to test SigComp, with or without SIP, trying to verify that all decompressor/UDVM endpoints behave consistently. Six implementations were present, which was more than expected, and the overall result was good, things mainly worked. The main problem had to do with consumption of decompressor memory because bytecode consumes memory in two places, making bootstrapping very difficult. Adam Roach noted that this problem currently makes SigComp unusable for SIP in 3GPP, and described three potential solutions. It was agreed that the desirable approach would be to increase the UDVM memory size, but there were various opinions on how to achieve that, from a standards point of view. Richard noted that this is an application specific issue, and a larger UDVM memory size should be mandated for SIP. Carsten agreed, but RFC 3486 does not say so, and there are other things missing as well. Carsten suggested that SigComp should not be changed, but that this should be left to each signaling protocol to specify. We should then not consider RFC 3486 as binding SIP to SigComp, but only defining how an application finds out if SigComp is being used. This means that we need a new document to specify other SIP specifics for SigComp. There were a few more issues identified at SIPit, but these were minor, although we should provide some clarifications. To do that, it was agreed to create a SigComp implementer's guide, and Mark agreed to write up an initial version with the current findings. - The SigComp binary multiplexing issues (Price) Richard Price initiated a follow-up to the SigComp multiplexing discussion from the Sipping list. Although SigComp offers an alternative transport service to applications, using SigComp requires more than just an on/off switch. Applications using SigComp must provide mechanisms for SigComp discovery, methods for recognizing SigComp messages, define compartment handling, clarifying whether "continuous mode" can be used, and potentially increase the minimal memory size and/or the maximal number of UDVM cycles. The mixing problem raised was triggered by the requirement that SIP messages may contain binary data. In UDP, framing comes from the packet, but for TCP there are both application and SigComp delimiters. Problems would then arise if uncompressed application messages are multiplexed with SigComp messages. Carsten noted that for TCP, the first byte would indicate whether SigComp is used or not, and there seems to be something wrong with the layering here. If there is a problem, it is probably because of misuse of SigComp. Richard agreed, what should be made clear is that SigComp should not be switched on/off within a connection. If someone wants to send some messages uncompressed, that can be handled within SigComp. Whether to allow "continuous mode" at all must further be specified per application, so we need the SIP-SigComp binding document also for that. * ROHC RTP, Draft Standard preparations status (Jonsson) The MIB draft has been submitted to the IESG, and so has the channel mapping examples document. The feature test document has been updated with additional tests, as well as some initial status figures. Reports are currently being collected, and the next update will be available within a month. An update of the IP profile has also been available for some time, but more feedback would be appreciated before we issue WG last-call. Finally, some minor clarifications have been added to the implementer's guide. Stephen Casner asked whether ROHC RTP Draft Standard advancement is dependent on DS for RTP itself. Although this will probably not be an issue since RTP will soon be published as Draft Standard, Carsten noted that ROHC RTP is not dependent on RTP itself because compression is speculative. Drafts: draft-ietf-rohc-rtp-impl-guide-03.txt draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt draft-ietf-rohc-ip-only-01.txt * Formal header compression notation (Bormann, Ozegovic, Price) Carsten introduced the formal header compression notation, initially answering the question why this work is needed. The lesson we have learned from RFC 3095 is that compressed packet formats easily gets non-trivial, overstressing the RFC box notation. It is not always clear what goes where, since labeling a field in box notation does not necessary mean you know how to interpret it. With a formal notation, the uncompressed data is described, as well as which compression mechanisms that is applied to each field. ROHC formal notation (ROHC-FN) is inspired by BNF, ROHC packet classifications, Huffman probabilities, etc. ROHC-FN is something that needs to get done and out of the way to return to working on profiles, which is what we are really chartered to do. Julije Ozegovic gave a quick presentation of an initial attempt to define a profile for DCCP using a formal notation approach. The purpose of this work was to investigate the usefulness of a formal notation, as well as studying DCCP for compression purposes. DCCP has a fixed header and various options, so the compression must handle the variability. Carsten noted that to use the notation, we will have to nail it down formally in a standardized way. It is easy to do something "wishy- washy", but it is hard to do it clearly. We need to get a common understanding in the WG as to how the notation works. This is not easy, and semantics have to be very clear. Further, we have to find a proper trade-off between top-down and bottom-up design. If we focus too much on specific applications of the notation in a top-down design we will get a smaller set of tools, which would be a good thing, but the solution will probably be inflexible for new uses. With a bottom- up design, we could on the other hand get something too flexible and far from actual application requirements. We need to find a proper middle-way. An idea is to define the notation using a high level programming language, and two examples were given by Carsten (Prolog) and Richard (Haskell). Prolog is a well-known logical programming language, while Haskell is a functional language. As shown by the examples, both provide means to get a rather human-readable notation result, and the difference is minimal, at least on the surface. Carsten finally raised some issues on the way forward. We will have to balance specification/implementation, as it is a danger that we write the whole implementation into the specification. There will have to be "oracle" functions, which are left for implementers to define. Another issue is the actual bits-on-the wire encoding, when there are alternatives in the encoding. To handle alternatives, some discriminators are needed, but it is not obvious how to create these. There have been discussions on the mailing list, but we have not totally converged towards an agreement. This was discussed also at the meeting, but the conclusion was that an agreement should not be difficult to reach, we just have to get a clearer and common picture of what people really mean. One thing is to agree on some terminology for discriminator functions, i.e. Huffman and Hierarchical Huffman. Julije noted that we have two phases, encoding and how to arrange the bits on the wire, i.e. field encoding and discriminators. Carsten clarified that there are really not two phases, just two primitives in the notation, Fields and Discriminators. Another high level question is how complete we want to make the notation. With an academic approach, one would let this take three or four years to get a complete solution, but that is really not the IETF way. Since new stuff can easily be added, if needed for another compression profile, we do not really have to create a complete solution, although we should have a good feeling about future enhancements. There was a strong agreement in the room to go for the proposed approach. One major open issue is about interaction between the formal notation and contexts, which is something that is not well understood at this point. Since contexts may not be the same at compressor and decompressor, due to loss, this must be covered for. We have feedback for context repair, but that is not covered by the notation. We also need to have means to handle things that are optionally present, e.g. list elements in IPv6. Richard noted that we currently do not support unbounded (recursive) encoding, and we have to carefully consider whether we should do that. Julije asked whether we have a problem with contexts and packet classification, i.e. which fields to check to see how to handle the packet and find the right context for it. Carsten commented that this would be a typical oracle function, i.e. an implementation issue, and Lars-Erik agreed that there should not be any difference to RFC 3095 in this respect. Zhigang Liu pointed out that one must be confident that the decompressor has the correct context present. Carsten responded that in 3095 this is handled by the sequence number, which gives the context (or candidate contexts) to be used for decompression. That is an issue for profile specification, nothing to be captured by the notation. Carsten then outlined a direction for moving forward. We should write down both requirements and non-requirements for the notation, and work from those. To get some more bandwidth and get this work going, we may need to consider having an interim meeting, as we had when we created RFC 3095. But first we should continue with the current discussions on the mailing list, which so far have been really helpful for bringing people forward towards a common understanding of concepts and principles. Drafts: draft-ietf-rohc-formal-notation-01.txt draft-ozegovic-mornar-dccp-epic-00.txt * Summing up (Bormann / Jonsson) Let's continue the discussions that we are now having on the mailing list. People who have not been involved are encouraged to read the notation draft, as well as the mail discussions from the last 2 weeks. See you in Vienna, at the latest... _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 10 13:16:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26939 for ; Thu, 10 Apr 2003 13:16:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AHMAF28266 for rohc-archive@odin.ietf.org; Thu, 10 Apr 2003 13:22:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHMA828263 for ; Thu, 10 Apr 2003 13:22:10 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26933 for ; Thu, 10 Apr 2003 13:15:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHFP827896; Thu, 10 Apr 2003 13:15:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHBw827711 for ; Thu, 10 Apr 2003 13:11:58 -0400 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26643 for ; Thu, 10 Apr 2003 13:05:38 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3AH8Db05353 for ; Thu, 10 Apr 2003 12:08:13 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Apr 2003 12:08:10 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 10 Apr 2003 12:07:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Preliminary minutes from San Francisco Date: Thu, 10 Apr 2003 12:06:59 -0500 Message-ID: Thread-Topic: [rohc] Preliminary minutes from San Francisco Thread-Index: AcL/cg7uMfcZq/fDQBSxe+oUe6JX5gABn9Kw To: , X-OriginalArrivalTime: 10 Apr 2003 17:07:00.0675 (UTC) FILETIME=[99D95130:01C2FF83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3AHBw827712 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, According to my notes, the following are missing from the minutes. I would suggest to add them after the text quoted below from the preliminary ROHC minutes. ------------------------------------------------------------------ > - SigComp interoperability report (West) > The main problem had to do with consumption of decompressor memory > because bytecode consumes memory in two places, making bootstrapping > very difficult. Zhigang Liu pointed out that he had raised the "double counting" issue among SigComp authors sometime last year, so it is not a new issue. > We should then not > consider RFC 3486 as binding SIP to SigComp, but only defining how > an application finds out if SigComp is being used. This means that > we need a new document to specify other SIP specifics for SigComp. Lars-Erik Jonsson then asked who were willing to handle this SigComp-SIP binding document. Zhigang Liu volunteered to be the editor. > - The SigComp binary multiplexing issues (Price) > The mixing problem raised was triggered by the requirement that SIP > messages may contain binary data. In UDP, framing comes from the > packet, but for TCP there are both application and SigComp > delimiters. Problems would then arise if uncompressed application > messages are multiplexed with SigComp messages. Carsten noted that > for TCP, the first byte would indicate whether SigComp is used or > not, and there seems to be something wrong with the layering here. > If there is a problem, it is probably because of misuse of SigComp. > Richard agreed, what should be made clear is that SigComp should > not be switched on/off within a connection. If someone wants to send > some messages uncompressed, that can be handled within SigComp. Zhigang Liu pointed out that it seems to be easy to multiplex uncompressed application message and SigComp messages on one TCP connection, since each application message has its own framing. It's a matter spelling out the requirement and logic. It looks not everyone has the same understanding of the issue, and further discussion will continue on the mailing list. ------------------------------------------------------------------ BR, Zhigang > -----Original Message----- > From: ext Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: April 10, 2003 9:46 AM > To: Rohc (E-mail) > Subject: [rohc] Preliminary minutes from San Francisco > > > ROHCers, > > Below are preliminary minutes from IETF 56. Please read them > ASAP, and respond about potential corrections or additions. I > need to have your comments not later than tomorrow, Friday > 11th, at 15:00 GMT. > > Rgds, > /Lars-Erik > > > Preliminary minutes of the ROHC WG session at IETF 56 > ===================================================== > > Hilton San Francisco, San Francisco, USA > Monday evening, 2003-03-17 > > Chairs: Carsten Bormann & Lars-Erik Jonsson > > Reported by: Lars-Erik Jonsson > Note takers: Stephen Casner, Christian Schmidt & Mark West > > Slides are available at http://www.dmn.tzi.org/ietf/rohc > > > Evening session, 19:30-22:00 > ---------------------------- > > * WG admonishments (Jonsson) > > Lars-Erik reviewed the IETF working group principles, the IETF > standardization process and the IPR rules defined by RFC 2026. > Meeting time should be used to advance difficult issues, not > for presentation of material that can be read from drafts. We > assume that people have read the drafts, and what we decide > in meetings must be confirmed on the mailing list. > > > * Agenda bashing (Jonsson) > > Lars-Erik presented the proposed agenda, which was accepted without > modifications. > > Agenda: > - Chair admonishments and agenda bashing > - WG and document status update > - Signaling compression issues > - ROHC RTP DS preparations update > - Formal header compression notation > > > * WG and document status (Jonsson) > > Lars-Erik reviewed WG goals, milestones and document status. Five > new ROHC RFC's have been published since November, three SigComp > documents, the LLA R-mode extension, and the RTP lower layer > guidelines. Currently, we have no documents in the RFC editor's > queue, but we have two that were just submitted to the IESG, the > ROHC MIB and its companion document with terminology and channel > mapping examples. > > The working group is progressing, but slowly. A milestone update > was planned after Atlanta, but has not yet happen for various > reasons. However, we should be able to do this rather soon. > > A new document review concept is to be implemented, where each > document is required to have "committed reviewers". These reviewers > are designated as such by the chairs, preferably on an early stage, > and must have agreed to follow the document evolution, to carefully > review the whole document, and to respond openly to working group > last-call. Committed reviewers should be non-authors, and will be > separately acknowledged in documents. > > The work items not covered by the agenda of this meeting were: > - ROHC TCP, which has not progressed as planned due to editor > illness, but an update is expected within a few weeks. > - Modified RTP/UDP profiles for UDP-Lite compression, where the > current individual draft will be resubmitted as a WG draft. > - SCTP compression, which is still on hold. The chairs have asked > for interest, motivation, industry support, and commitments for > doing the actual work, but answers have not really provided that. > Carsten noted that we might not understand future usage of SCTP > at this point, so attempting a solution now might produce a > result that is not really useful. > > > * Signaling compression issues > > - SigComp Feedback (Roach) > > Adam Roach gave a quick summary of the changes in the updated draft. > Nack information is now at the end of the messages, and can therefore > be distinguished from standalone feedback. The TCP behavior has been > changed, and a NACK detection mechanisms has been added. There was > a question raised whether we should create an IANA registry for the > first 32 bytes of UDVM memory space, but the question was never > answered or discussed. More people have to look at this, so far the > input has been limited. The meeting suggested that the document > should be adopted as a WG document, if we get a few committed draft > reviewers, and Mark West and Carsten Bormann volunteered for this. > > Draft: draft-roach-sigcomp-nack-01.txt > > - SigComp interoperability report (West) > > Mark West gave a report from the first SigComp interoperability > testing, conducted at SIPit. The point was primarily to test SigComp, > with or without SIP, trying to verify that all decompressor/UDVM > endpoints behave consistently. Six implementations were present, > which was more than expected, and the overall result was good, things > mainly worked. > > The main problem had to do with consumption of decompressor memory > because bytecode consumes memory in two places, making bootstrapping > very difficult. Adam Roach noted that this problem currently makes > SigComp unusable for SIP in 3GPP, and described three potential > solutions. It was agreed that the desirable approach would be to > increase the UDVM memory size, but there were various opinions on > how to achieve that, from a standards point of view. Richard noted > that this is an application specific issue, and a larger UDVM memory > size should be mandated for SIP. Carsten agreed, but RFC 3486 does > not say so, and there are other things missing as well. Carsten > suggested that SigComp should not be changed, but that this should > be left to each signaling protocol to specify. We should then not > consider RFC 3486 as binding SIP to SigComp, but only defining how > an application finds out if SigComp is being used. This means that > we need a new document to specify other SIP specifics for SigComp. > > There were a few more issues identified at SIPit, but these were > minor, although we should provide some clarifications. To do that, > it was agreed to create a SigComp implementer's guide, and Mark > agreed to write up an initial version with the current findings. > > - The SigComp binary multiplexing issues (Price) > > Richard Price initiated a follow-up to the SigComp multiplexing > discussion from the Sipping list. Although SigComp offers an > alternative transport service to applications, using SigComp > requires more than just an on/off switch. Applications using > SigComp must provide mechanisms for SigComp discovery, methods > for recognizing SigComp messages, define compartment handling, > clarifying whether "continuous mode" can be used, and potentially > increase the minimal memory size and/or the maximal number of UDVM > cycles. > > The mixing problem raised was triggered by the requirement that SIP > messages may contain binary data. In UDP, framing comes from the > packet, but for TCP there are both application and SigComp > delimiters. Problems would then arise if uncompressed application > messages are multiplexed with SigComp messages. Carsten noted that > for TCP, the first byte would indicate whether SigComp is used or > not, and there seems to be something wrong with the layering here. > If there is a problem, it is probably because of misuse of SigComp. > Richard agreed, what should be made clear is that SigComp should > not be switched on/off within a connection. If someone wants to send > some messages uncompressed, that can be handled within SigComp. > > Whether to allow "continuous mode" at all must further be specified > per application, so we need the SIP-SigComp binding document also > for that. > > > * ROHC RTP, Draft Standard preparations status (Jonsson) > > The MIB draft has been submitted to the IESG, and so has the channel > mapping examples document. The feature test document has been updated > with additional tests, as well as some initial status figures. Reports > are currently being collected, and the next update will be available > within a month. An update of the IP profile has also been available > for some time, but more feedback would be appreciated before we issue > WG last-call. Finally, some minor clarifications have been added to > the implementer's guide. Stephen Casner asked whether ROHC RTP Draft > Standard advancement is dependent on DS for RTP itself. Although this > will probably not be an issue since RTP will soon be published as > Draft Standard, Carsten noted that ROHC RTP is not dependent on RTP > itself because compression is speculative. > > Drafts: draft-ietf-rohc-rtp-impl-guide-03.txt > draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt > draft-ietf-rohc-ip-only-01.txt > > > * Formal header compression notation (Bormann, Ozegovic, Price) > > Carsten introduced the formal header compression notation, initially > answering the question why this work is needed. The lesson we have > learned from RFC 3095 is that compressed packet formats easily gets > non-trivial, overstressing the RFC box notation. It is not always > clear what goes where, since labeling a field in box notation does > not necessary mean you know how to interpret it. With a formal > notation, the uncompressed data is described, as well as which > compression mechanisms that is applied to each field. ROHC formal > notation (ROHC-FN) is inspired by BNF, ROHC packet classifications, > Huffman probabilities, etc. ROHC-FN is something that needs to get > done and out of the way to return to working on profiles, which is > what we are really chartered to do. > > Julije Ozegovic gave a quick presentation of an initial attempt to > define a profile for DCCP using a formal notation approach. The > purpose of this work was to investigate the usefulness of a formal > notation, as well as studying DCCP for compression purposes. DCCP > has a fixed header and various options, so the compression must > handle the variability. > > Carsten noted that to use the notation, we will have to nail it down > formally in a standardized way. It is easy to do something "wishy- > washy", but it is hard to do it clearly. We need to get a common > understanding in the WG as to how the notation works. This is not > easy, and semantics have to be very clear. Further, we have to find > a proper trade-off between top-down and bottom-up design. If we focus > too much on specific applications of the notation in a top-down design > we will get a smaller set of tools, which would be a good thing, but > the solution will probably be inflexible for new uses. With a bottom- > up design, we could on the other hand get something too flexible and > far from actual application requirements. We need to find a proper > middle-way. > > An idea is to define the notation using a high level programming > language, and two examples were given by Carsten (Prolog) and Richard > (Haskell). Prolog is a well-known logical programming language, while > Haskell is a functional language. As shown by the examples, both > provide means to get a rather human-readable notation result, and > the difference is minimal, at least on the surface. > > Carsten finally raised some issues on the way forward. We will have > to balance specification/implementation, as it is a danger that we > write the whole implementation into the specification. There will > have to be "oracle" functions, which are left for implementers to > define. Another issue is the actual bits-on-the wire encoding, when > there are alternatives in the encoding. To handle alternatives, some > discriminators are needed, but it is not obvious how to create these. > There have been discussions on the mailing list, but we have not > totally converged towards an agreement. This was discussed also at > the meeting, but the conclusion was that an agreement should not be > difficult to reach, we just have to get a clearer and common picture > of what people really mean. One thing is to agree on some terminology > for discriminator functions, i.e. Huffman and Hierarchical Huffman. > Julije noted that we have two phases, encoding and how to arrange the > bits on the wire, i.e. field encoding and discriminators. Carsten > clarified that there are really not two phases, just two primitives > in the notation, Fields and Discriminators. > > Another high level question is how complete we want to make the > notation. With an academic approach, one would let this take three > or four years to get a complete solution, but that is really not the > IETF way. Since new stuff can easily be added, if needed for another > compression profile, we do not really have to create a complete > solution, although we should have a good feeling about future > enhancements. There was a strong agreement in the room to go for > the proposed approach. > > One major open issue is about interaction between the formal notation > and contexts, which is something that is not well understood at this > point. Since contexts may not be the same at compressor and > decompressor, due to loss, this must be covered for. We have feedback > for context repair, but that is not covered by the notation. We also > need to have means to handle things that are optionally present, e.g. > list elements in IPv6. Richard noted that we currently do not support > unbounded (recursive) encoding, and we have to carefully consider > whether we should do that. > > Julije asked whether we have a problem with contexts and packet > classification, i.e. which fields to check to see how to handle the > packet and find the right context for it. Carsten commented that this > would be a typical oracle function, i.e. an implementation issue, and > Lars-Erik agreed that there should not be any difference to RFC 3095 > in this respect. > > Zhigang Liu pointed out that one must be confident that the > decompressor has the correct context present. Carsten responded that > in 3095 this is handled by the sequence number, which gives the > context (or candidate contexts) to be used for decompression. That > is an issue for profile specification, nothing to be captured by the > notation. > > Carsten then outlined a direction for moving forward. We should write > down both requirements and non-requirements for the notation, and > work from those. To get some more bandwidth and get this work going, > we may need to consider having an interim meeting, as we had when we > created RFC 3095. But first we should continue with the current > discussions on the mailing list, which so far have been really > helpful for bringing people forward towards a common understanding > of concepts and principles. > > Drafts: draft-ietf-rohc-formal-notation-01.txt > draft-ozegovic-mornar-dccp-epic-00.txt > > > * Summing up (Bormann / Jonsson) > > Let's continue the discussions that we are now having on the mailing > list. People who have not been involved are encouraged to read the > notation draft, as well as the mail discussions from the last 2 > weeks. > > See you in Vienna, at the latest... > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 10 14:00:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28509 for ; Thu, 10 Apr 2003 14:00:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AI6cj31703 for rohc-archive@odin.ietf.org; Thu, 10 Apr 2003 14:06:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AI6c831700 for ; Thu, 10 Apr 2003 14:06:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28504 for ; Thu, 10 Apr 2003 14:00:20 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193g5P-0003BH-00 for rohc-web-archive@ietf.org; Thu, 10 Apr 2003 13:43:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193g5O-0003BE-00 for rohc-web-archive@ietf.org; Thu, 10 Apr 2003 13:43:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AI07831142; Thu, 10 Apr 2003 14:00:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHxp831073 for ; Thu, 10 Apr 2003 13:59:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28082 for ; Thu, 10 Apr 2003 13:53:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193fyp-000363-00 for rohc@ietf.org; Thu, 10 Apr 2003 13:36:55 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 193fyp-000360-00 for rohc@ietf.org; Thu, 10 Apr 2003 13:36:55 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3AHu7Rs014507; Thu, 10 Apr 2003 19:56:07 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VDNFB25>; Thu, 10 Apr 2003 19:56:08 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] Preliminary minutes from San Francisco Date: Thu, 10 Apr 2003 19:56:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Zhigang, Thanks for those comments, these were all missing from the notes I received, but I can personally confirm the first two items. For the third one, I am not sure exactly what was said on the meeting, so I do not know if the text below really reflects how this meeting discussion ended. Anyway I will add some words about your comment, and the fact that there was a disagreement. Cheers, /L-E > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: den 10 april 2003 19:07 > To: Lars-Erik Jonsson (EAB); rohc@ietf.org > Subject: RE: [rohc] Preliminary minutes from San Francisco > > > Hi, > > According to my notes, the following are missing from the minutes. > I would suggest to add them after the text quoted below from the > preliminary ROHC minutes. > > ------------------------------------------------------------------ > > - SigComp interoperability report (West) > > > The main problem had to do with consumption of decompressor memory > > because bytecode consumes memory in two places, making bootstrapping > > very difficult. > > Zhigang Liu pointed out that he had raised the "double > counting" issue > among SigComp authors sometime last year, so it is not a new issue. > > > We should then not > > consider RFC 3486 as binding SIP to SigComp, but only defining how > > an application finds out if SigComp is being used. This means that > > we need a new document to specify other SIP specifics for SigComp. > > Lars-Erik Jonsson then asked who were willing to handle this > SigComp-SIP > binding document. Zhigang Liu volunteered to be the editor. > > > - The SigComp binary multiplexing issues (Price) > > > The mixing problem raised was triggered by the requirement that SIP > > messages may contain binary data. In UDP, framing comes from the > > packet, but for TCP there are both application and SigComp > > delimiters. Problems would then arise if uncompressed application > > messages are multiplexed with SigComp messages. Carsten noted that > > for TCP, the first byte would indicate whether SigComp is used or > > not, and there seems to be something wrong with the layering here. > > If there is a problem, it is probably because of misuse of SigComp. > > Richard agreed, what should be made clear is that SigComp should > > not be switched on/off within a connection. If someone wants to send > > some messages uncompressed, that can be handled within SigComp. > > Zhigang Liu pointed out that it seems to be easy to multiplex > uncompressed > application message and SigComp messages on one TCP connection, since > each application message has its own framing. It's a matter spelling > out the requirement and logic. > > It looks not everyone has the same understanding of the > issue, and further > discussion will continue on the mailing list. > ------------------------------------------------------------------ > > BR, > Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 14 02:31:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25404 for ; Mon, 14 Apr 2003 02:31:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E6cZ826381 for rohc-archive@odin.ietf.org; Mon, 14 Apr 2003 02:38:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6cY826378 for ; Mon, 14 Apr 2003 02:38:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25375 for ; Mon, 14 Apr 2003 02:30:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194xWc-0000AE-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 02:33:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194xWc-0000AA-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 02:33:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6cJ826366; Mon, 14 Apr 2003 02:38:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DIWw807176 for ; Sun, 13 Apr 2003 14:32:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02943 for ; Sun, 13 Apr 2003 14:25:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194mCf-0005uU-00 for rohc@ietf.org; Sun, 13 Apr 2003 14:27:45 -0400 Received: from mail.gmx.net ([213.165.65.60]) by ietf-mx with smtp (Exim 4.12) id 194mCf-0005uQ-00 for rohc@ietf.org; Sun, 13 Apr 2003 14:27:45 -0400 Received: (qmail 31248 invoked by uid 65534); 13 Apr 2003 18:27:10 -0000 Received: from adsl-27-141.barak.net.il (HELO yaronhome) (62.90.27.141) by mail.gmx.net (mp005-rz3) with SMTP; 13 Apr 2003 20:27:10 +0200 From: "Yaron Sheffer" To: "IPSec List" , Date: Sun, 13 Apr 2003 21:26:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [rohc] FW: ESP and header compression (ROHC) Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (please reply to both lists) Below is my question to Steve Kent (author of the new rev of ESP, and co-author of the original RFC) and his reply. I understand that IPCOMP is inferior to ROHC for RTP streams, and I'd like to hear other opinions regarding the usefulness of an "ROHC" indicator in ESP. This might certaily add complexity to IPSec, but if you make it non-negotiable and non-mandatory, it cannot be too terrible. Thanks, Yaron -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, April 10, 2003 12:06 AM To: Yaron Sheffer Cc: Sara Bitan; kent@bbn.com Subject: Re: ESP and header compression (ROHC) At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: >Hi Steve, > >I have lately looked at issues with IPSec encryption of RTP streams (I am >aware of SRTP but I think we will want RTP over IPSec for some time to >come). A major issue is packet overhead. You can use Robust Header >Compression (ROHC) on the external IP+ESP headers - this is defined by the >ROHC RFC. But if you want to header-compress the RTP packets before it is >tunneled in ESP (IP+UDP+RTP headers), you cannot do it because there's no >way to detect ROHC packets in the ESP header. I'd expect ESP to contain a >marker for ROHC packets, similarly to PPP. Has this option been considered >for the new version of ESP? > >Thanks, > Yaron No, the WG has not considered that option. The WG has been striving to make IPsec simpler and thus adding support for ROHC is contrary to that theme. For example, ROHC would have be be implemented within IPsec, after the SA lookup was performed, and ROHC decompression would have to be implemented in IPsec at the receiver, since the receiver has to check the headers against the SAD. IPsec already supports IPCOMP as a compression method for whole packets, not just headers, and thus it might be hard to persuade the WG to add ROHC support too. But, that's just my impression. You can always raise the question on the list. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 14 03:03:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26016 for ; Mon, 14 Apr 2003 03:03:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E7BKd28353 for rohc-archive@odin.ietf.org; Mon, 14 Apr 2003 03:11:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7BK828350 for ; Mon, 14 Apr 2003 03:11:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25999 for ; Mon, 14 Apr 2003 03:03:18 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194y2J-0000G1-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 03:05:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194y2I-0000Fy-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 03:05:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7B8828325; Mon, 14 Apr 2003 03:11:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7AV828287 for ; Mon, 14 Apr 2003 03:10:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25981 for ; Mon, 14 Apr 2003 03:02:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194y1W-0000FZ-00 for rohc@ietf.org; Mon, 14 Apr 2003 03:05:02 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 194y1V-0000FW-00 for rohc@ietf.org; Mon, 14 Apr 2003 03:05:01 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3E754Ru012627; Mon, 14 Apr 2003 09:05:05 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VDNZKVC>; Mon, 14 Apr 2003 09:05:05 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Mon, 14 Apr 2003 09:04:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, A few notes: 1) ROHC is applied on a per-link basis, e.g. over PPP 2) Based on the above point, there are ROHC compression profiles defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) Compressing the network layer header is most important to gain anything, but that can only be done on a per-link basis. Header compression is thus applied per-link to compress network and transport layer headers (and by heuristics also the application layer RTP header). It is also simpler to do compression per-link, as one can optimize for certain assumed characteristics (such as in-order delivery). Further, it makes most sense as header compression is an optimization for "narrow links". Therefore, I can not see why/how one could do "ROHC over ESP". BR /Lars-Erik > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@gmx.net] > Sent: den 13 april 2003 21:26 > To: IPSec List; rohc@ietf.org > Subject: [rohc] FW: ESP and header compression (ROHC) > > > (please reply to both lists) > > Below is my question to Steve Kent (author of the new rev of ESP, and > co-author of the original RFC) and his reply. I understand > that IPCOMP is > inferior to ROHC for RTP streams, and I'd like to hear other opinions > regarding the usefulness of an "ROHC" indicator in ESP. > > This might certaily add complexity to IPSec, but if you make it > non-negotiable and non-mandatory, it cannot be too terrible. > > Thanks, > Yaron > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Thursday, April 10, 2003 12:06 AM > To: Yaron Sheffer > Cc: Sara Bitan; kent@bbn.com > Subject: Re: ESP and header compression (ROHC) > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > >Hi Steve, > > > >I have lately looked at issues with IPSec encryption of RTP > streams (I am > >aware of SRTP but I think we will want RTP over IPSec for > some time to > >come). A major issue is packet overhead. You can use Robust Header > >Compression (ROHC) on the external IP+ESP headers - this is > defined by the > >ROHC RFC. But if you want to header-compress the RTP packets > before it is > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > because there's no > >way to detect ROHC packets in the ESP header. I'd expect ESP > to contain a > >marker for ROHC packets, similarly to PPP. Has this option > been considered > >for the new version of ESP? > > > >Thanks, > > Yaron > > No, the WG has not considered that option. The WG has been striving > to make IPsec simpler and thus adding support for ROHC is contrary to > that theme. For example, ROHC would have be be implemented within > IPsec, after the SA lookup was performed, and ROHC decompression > would have to be implemented in IPsec at the receiver, since the > receiver has to check the headers against the SAD. IPsec already > supports IPCOMP as a compression method for whole packets, not just > headers, and thus it might be hard to persuade the WG to add ROHC > support too. > > But, that's just my impression. You can always raise the > question on the > list. > > Steve > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 14 04:18:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27722 for ; Mon, 14 Apr 2003 04:18:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E8Pc001150 for rohc-archive@odin.ietf.org; Mon, 14 Apr 2003 04:25:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E8Pc801147 for ; Mon, 14 Apr 2003 04:25:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27713 for ; Mon, 14 Apr 2003 04:17:35 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194zCB-0000gg-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 04:20:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194zCB-0000gd-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 04:20:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E8PL801126; Mon, 14 Apr 2003 04:25:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E8OY801092 for ; Mon, 14 Apr 2003 04:24:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27696 for ; Mon, 14 Apr 2003 04:16:31 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194zBA-0000gK-00 for rohc@ietf.org; Mon, 14 Apr 2003 04:19:04 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 194zB9-0000gH-00 for rohc@ietf.org; Mon, 14 Apr 2003 04:19:03 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3E8J7Rs008606 for ; Mon, 14 Apr 2003 10:19:07 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VDN5AG6>; Mon, 14 Apr 2003 10:19:09 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Mon, 14 Apr 2003 10:18:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Minutes of the ROHC WG session at IETF 56 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Minutes of the ROHC WG session at IETF 56 ========================================= Hilton San Francisco, San Francisco, USA Monday evening, 2003-03-17 Chairs: Carsten Bormann & Lars-Erik Jonsson Reported by: Lars-Erik Jonsson Note takers: Stephen Casner, Christian Schmidt & Mark West Slides are available at http://www.dmn.tzi.org/ietf/rohc Evening session, 19:30-22:00 ---------------------------- * WG admonishments (Jonsson) Lars-Erik reviewed the IETF working group principles, the IETF standardization process and the IPR rules defined by RFC 2026. Meeting time should be used to advance difficult issues, not for presentation of material that can be read from drafts. We assume that people have read the drafts, and what we decide in meetings must be confirmed on the mailing list. * Agenda bashing (Jonsson) Lars-Erik presented the proposed agenda, which was accepted without modifications. Agenda: - Chair admonishments and agenda bashing - WG and document status update - Signaling compression issues - ROHC RTP DS preparations update - Formal header compression notation * WG and document status (Jonsson) Lars-Erik reviewed WG goals, milestones and document status. Five new ROHC RFC's have been published since November, three SigComp documents, the LLA R-mode extension, and the RTP lower layer guidelines. Currently, we have no documents in the RFC editor's queue, but we have two that were just submitted to the IESG, the ROHC MIB and its companion document with terminology and channel mapping examples. The working group is progressing, but slowly. A milestone update was planned after Atlanta, but has not yet happen for various reasons. However, we should be able to do this rather soon. A new document review concept is to be implemented, where each document is required to have "committed reviewers". These reviewers are designated as such by the chairs, preferably on an early stage, and must have agreed to follow the document evolution, to carefully review the whole document, and to respond openly to working group last-call. Committed reviewers should be non-authors, and will be separately acknowledged in documents. The work items not covered by the agenda of this meeting were: - ROHC TCP, which has not progressed as planned due to editor illness, but an update is expected within a few weeks. - Modified RTP/UDP profiles for UDP-Lite compression, where the current individual draft will be resubmitted as a WG draft. - SCTP compression, which is still on hold. The chairs have asked for interest, motivation, industry support, and commitments for doing the actual work, but answers have not really provided that. Carsten noted that we might not understand future usage of SCTP at this point, so attempting a solution now might produce a result that is not really useful. * Signaling compression issues - SigComp Feedback (Roach) Adam Roach gave a quick summary of the changes in the updated draft. Nack information is now at the end of the messages, and can therefore be distinguished from standalone feedback. The TCP behavior has been changed, and a NACK detection mechanisms has been added. There was a question raised whether we should create an IANA registry for the first 32 bytes of UDVM memory space, but the question was never answered or discussed. More people have to look at this, so far the input has been limited. The meeting suggested that the document should be adopted as a WG document, if we get a few committed draft reviewers, and Mark West and Carsten Bormann volunteered for this. Draft: draft-roach-sigcomp-nack-01.txt - SigComp interoperability report (West) Mark West gave a report from the first SigComp interoperability testing, conducted at SIPit. The point was primarily to test SigComp, with or without SIP, trying to verify that all decompressor/UDVM endpoints behave consistently. Six implementations were present, which was more than expected, and the overall result was good, things mainly worked. The main problem had to do with consumption of decompressor memory because bytecode consumes memory in two places, making bootstrapping very difficult. Zhigang Liu noted that this is not a new issue, as it was discussed among SigComp authors during last year, but then it was seen as a non-problem. Adam Roach pointed out that this currently makes SigComp unusable for SIP in 3GPP, and described three potential solutions. It was agreed that the desirable approach would be to increase the UDVM memory size, but there were various opinions on how to achieve that, from a standards point of view. Richard noted that this is an application specific issue, and a larger UDVM memory size should be mandated for SIP. Carsten agreed, but RFC 3486 does not say so, and there are other things missing as well. Carsten suggested that SigComp should not be changed, but that this should be left to each signaling protocol to specify. We should then not consider RFC 3486 as binding SIP to SigComp, but only defining how an application finds out if SigComp is being used. This means that we need a new document to specify other SIP specifics for SigComp. Zhigang volunteered to serve as editor for such a document. There were a few more issues identified at SIPit, but these were minor, although we should provide some clarifications. To do that, it was agreed to create a SigComp implementer's guide, and Mark agreed to write up an initial version with the current findings. - The SigComp binary multiplexing issues (Price) Richard Price initiated a follow-up to the SigComp multiplexing discussion from the Sipping list. Although SigComp offers an alternative transport service to applications, using SigComp requires more than just an on/off switch. Applications using SigComp must provide mechanisms for SigComp discovery, methods for recognizing SigComp messages, define compartment handling, clarifying whether "continuous mode" can be used, and potentially increase the minimal memory size and/or the maximal number of UDVM cycles. The mixing problem raised was triggered by the requirement that SIP messages may contain binary data. In UDP, framing comes from the packet, but for TCP there are both application and SigComp delimiters. Problems would then arise if uncompressed application messages are multiplexed with SigComp messages. Carsten noted that for TCP, the first byte would indicate whether SigComp is used or not, and there seems to be something wrong with the layering here. If there is a problem, it is probably because of misuse of SigComp. Richard agreed, what should be made clear is that SigComp should not be switched on/off within a connection. If someone wants to send some messages uncompressed, that can be handled within SigComp. Zhigang argued that we should still define how to do multiplexing of raw application messages and SigComp messages, and this discussion will probably continue on the mailing list. Whether to allow "continuous mode" at all must further be specified per application, so we need the SIP-SigComp binding document also for that. * ROHC RTP, Draft Standard preparations status (Jonsson) The MIB draft has been submitted to the IESG, and so has the channel mapping examples document. The feature test document has been updated with additional tests, as well as some initial status figures. Reports are currently being collected, and the next update will be available within a month. An update of the IP profile has also been available for some time, but more feedback would be appreciated before we issue WG last-call. Finally, some minor clarifications have been added to the implementer's guide. Stephen Casner asked whether ROHC RTP Draft Standard advancement is dependent on DS for RTP itself. Although this will probably not be an issue since RTP will soon be published as Draft Standard, Carsten noted that ROHC RTP is not dependent on RTP itself because compression is speculative. Drafts: draft-ietf-rohc-rtp-impl-guide-03.txt draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt draft-ietf-rohc-ip-only-01.txt * Formal header compression notation (Bormann, Ozegovic, Price) Carsten introduced the formal header compression notation, initially answering the question why this work is needed. The lesson we have learned from RFC 3095 is that compressed packet formats easily gets non-trivial, overstressing the RFC box notation. It is not always clear what goes where, since labeling a field in box notation does not necessary mean you know how to interpret it. With a formal notation, the uncompressed data is described, as well as which compression mechanisms that is applied to each field. ROHC formal notation (ROHC-FN) is inspired by BNF, ROHC packet classifications, Huffman probabilities, etc. ROHC-FN is something that needs to get done and out of the way to return to working on profiles, which is what we are really chartered to do. Julije Ozegovic gave a quick presentation of an initial attempt to define a profile for DCCP using a formal notation approach. The purpose of this work was to investigate the usefulness of a formal notation, as well as studying DCCP for compression purposes. DCCP has a fixed header and various options, so the compression must handle the variability. Carsten noted that to use the notation, we will have to nail it down formally in a standardized way. It is easy to do something "wishy- washy", but it is hard to do it clearly. We need to get a common understanding in the WG as to how the notation works. This is not easy, and semantics have to be very clear. Further, we have to find a proper trade-off between top-down and bottom-up design. If we focus too much on specific applications of the notation in a top-down design we will get a smaller set of tools, which would be a good thing, but the solution will probably be inflexible for new uses. With a bottom- up design, we could on the other hand get something too flexible and far from actual application requirements. We need to find a proper middle-way. An idea is to define the notation using a high level programming language, and two examples were given by Carsten (Prolog) and Richard (Haskell). Prolog is a well-known logical programming language, while Haskell is a functional language. As shown by the examples, both provide means to get a rather human-readable notation result, and the difference is minimal, at least on the surface. Carsten finally raised some issues on the way forward. We will have to balance specification/implementation, as it is a danger that we write the whole implementation into the specification. There will have to be "oracle" functions, which are left for implementers to define. Another issue is the actual bits-on-the wire encoding, when there are alternatives in the encoding. To handle alternatives, some discriminators are needed, but it is not obvious how to create these. There have been discussions on the mailing list, but we have not totally converged towards an agreement. This was discussed also at the meeting, but the conclusion was that an agreement should not be difficult to reach, we just have to get a clearer and common picture of what people really mean. One thing is to agree on some terminology for discriminator functions, i.e. Huffman and Hierarchical Huffman. Julije noted that we have two phases, encoding and how to arrange the bits on the wire, i.e. field encoding and discriminators. Carsten clarified that there are really not two phases, just two primitives in the notation, Fields and Discriminators. Another high level question is how complete we want to make the notation. With an academic approach, one would let this take three or four years to get a complete solution, but that is really not the IETF way. Since new stuff can easily be added, if needed for another compression profile, we do not really have to create a complete solution, although we should have a good feeling about future enhancements. There was a strong agreement in the room to go for the proposed approach. One major open issue is about interaction between the formal notation and contexts, which is something that is not well understood at this point. Since contexts may not be the same at compressor and decompressor, due to loss, this must be covered for. We have feedback for context repair, but that is not covered by the notation. We also need to have means to handle things that are optionally present, e.g. list elements in IPv6. Richard noted that we currently do not support unbounded (recursive) encoding, and we have to carefully consider whether we should do that. Julije asked whether we have a problem with contexts and packet classification, i.e. which fields to check to see how to handle the packet and find the right context for it. Carsten commented that this would be a typical oracle function, i.e. an implementation issue, and Lars-Erik agreed that there should not be any difference to RFC 3095 in this respect. Zhigang pointed out that one must be confident that the decompressor has the correct context present. Carsten responded that in 3095 this is handled by the sequence number, which gives the context (or candidate contexts) to be used for decompression. That is an issue for profile specification, nothing to be captured by the notation. Carsten then outlined a direction for moving forward. We should write down both requirements and non-requirements for the notation, and work from those. To get some more bandwidth and get this work going, we may need to consider having an interim meeting, as we had when we created RFC 3095. But first we should continue with the current discussions on the mailing list, which so far have been really helpful for bringing people forward towards a common understanding of concepts and principles. Drafts: draft-ietf-rohc-formal-notation-01.txt draft-ozegovic-mornar-dccp-epic-00.txt * Summing up (Bormann / Jonsson) Let's continue the discussions that we are now having on the mailing list. People who have not been involved are encouraged to read the notation draft, as well as the mail discussions from the last 2 weeks. See you in Vienna, at the latest... _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 14 08:20:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01973 for ; Mon, 14 Apr 2003 08:20:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ECS9P16447 for rohc-archive@odin.ietf.org; Mon, 14 Apr 2003 08:28:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ECS8816444 for ; Mon, 14 Apr 2003 08:28:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01966 for ; Mon, 14 Apr 2003 08:20:01 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1952yn-0001Zm-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 08:22:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1952yn-0001Zj-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 08:22:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ECRF816422; Mon, 14 Apr 2003 08:27:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ECQv816377 for ; Mon, 14 Apr 2003 08:26:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01904; Mon, 14 Apr 2003 08:18:50 -0400 (EDT) Message-Id: <200304141218.IAA01904@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 14 Apr 2003 08:18:50 -0400 Subject: [rohc] I-D ACTION:draft-ietf-rohc-udp-lite-00.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC):Profiles for UDP-Lite Author(s) : G. Pelletier Filename : draft-ietf-rohc-udp-lite-00.txt Pages : 19 Date : 2003-4-11 This document defines ROHC (Robust Header Compression) profiles for compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. These profiles are defined based on their differences with the profiles specified in [RFC-3095] for UDP [RFC-768]. Although both transport protocols are very similar, ROHC profiles must be defined separately for robust compression of UDP-Lite headers because it does not share protocol identifier with UDP. Also, the UDP-Lite Checksum Coverage field does not share the semantics of the corresponding UDP Length field and as a consequence cannot always be inferred anymore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-udp-lite-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-udp-lite-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-11134049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-udp-lite-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-udp-lite-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-11134049.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 14 09:49:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05640 for ; Mon, 14 Apr 2003 09:49:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EDuoD22985 for rohc-archive@odin.ietf.org; Mon, 14 Apr 2003 09:56:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EDuo822982 for ; Mon, 14 Apr 2003 09:56:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05635 for ; Mon, 14 Apr 2003 09:48:40 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1954Ma-0002Ss-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 09:51:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1954Ma-0002Sp-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 09:51:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EDuJ822967; Mon, 14 Apr 2003 09:56:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EDtU822916 for ; Mon, 14 Apr 2003 09:55:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05600 for ; Mon, 14 Apr 2003 09:47:20 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1954LI-0002SW-00 for rohc@ietf.org; Mon, 14 Apr 2003 09:49:52 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1954LI-0002ST-00 for rohc@ietf.org; Mon, 14 Apr 2003 09:49:52 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3EDnuI4010427; Mon, 14 Apr 2003 15:49:56 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VDN8RYQ>; Mon, 14 Apr 2003 15:49:25 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Mon, 14 Apr 2003 15:46:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Yaron, That clarified the scenario, just note that "ROHC over tunnels" has not yet been addressed in the ROHC WG. I do not say that that there must be problems with that, but it should be noted that the link assumptions made for ROHC might not match a tunneling case. Anyway, I am not sure you need anything special in the ESP header, but can do per-link compression of the whole chain. You would have an outer and an inner IP header, and the ESP header would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). However, if the inner headers are encrypted, you can of course not compress all headers on a per-link basis. Is that the case you are considering? Cheers, /L-E > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@gmx.net] > Sent: den 14 april 2003 15:26 > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > Hi Lars-Erik, > > I may have been misunderstood. To clarify, I am discussing > the following > stack: > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > In some cases, depending on the nature of the flows that use > the ESP tunnel, > ESP plays the role of a link. In those cases, it makes sense > to compress the > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > conversation there will be a single RTP flow within the > tunnel, and ROHC is > beneficial for the internal headers. > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > IP(2)+UDP+RTP. > > Regards, > Yaron > > ----- Original Message ----- > From: "Lars-Erik Jonsson (EAB)" > To: "'Yaron Sheffer'" ; "IPSec List" > ; > Sent: Monday, April 14, 2003 10:04 > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > Hi all, > > > > A few notes: > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > 2) Based on the above point, there are ROHC compression profiles > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > Compressing the network layer header is most important to gain > > anything, but that can only be done on a per-link basis. Header > > compression is thus applied per-link to compress network and > > transport layer headers (and by heuristics also the application > > layer RTP header). It is also simpler to do compression per-link, > > as one can optimize for certain assumed characteristics (such as > > in-order delivery). Further, it makes most sense as header > > compression is an optimization for "narrow links". > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > BR > > /Lars-Erik > > > > > > > > > > > -----Original Message----- > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > Sent: den 13 april 2003 21:26 > > > To: IPSec List; rohc@ietf.org > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > (please reply to both lists) > > > > > > Below is my question to Steve Kent (author of the new rev > of ESP, and > > > co-author of the original RFC) and his reply. I understand > > > that IPCOMP is > > > inferior to ROHC for RTP streams, and I'd like to hear > other opinions > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > This might certaily add complexity to IPSec, but if you make it > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > Thanks, > > > Yaron > > > > > > -----Original Message----- > > > From: Stephen Kent [mailto:kent@bbn.com] > > > Sent: Thursday, April 10, 2003 12:06 AM > > > To: Yaron Sheffer > > > Cc: Sara Bitan; kent@bbn.com > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > >Hi Steve, > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > streams (I am > > > >aware of SRTP but I think we will want RTP over IPSec for > > > some time to > > > >come). A major issue is packet overhead. You can use > Robust Header > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > defined by the > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > before it is > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > because there's no > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > to contain a > > > >marker for ROHC packets, similarly to PPP. Has this option > > > been considered > > > >for the new version of ESP? > > > > > > > >Thanks, > > > > Yaron > > > > > > No, the WG has not considered that option. The WG has > been striving > > > to make IPsec simpler and thus adding support for ROHC is > contrary to > > > that theme. For example, ROHC would have be be implemented within > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > would have to be implemented in IPsec at the receiver, since the > > > receiver has to check the headers against the SAD. IPsec already > > > supports IPCOMP as a compression method for whole > packets, not just > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > support too. > > > > > > But, that's just my impression. You can always raise the > > > question on the > > > list. > > > > > > Steve > > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 14 10:09:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06629 for ; Mon, 14 Apr 2003 10:09:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EEHQt24596 for rohc-archive@odin.ietf.org; Mon, 14 Apr 2003 10:17:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EEHQ824593 for ; Mon, 14 Apr 2003 10:17:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06561 for ; Mon, 14 Apr 2003 10:09:16 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1954gW-0002WS-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 10:11:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1954gW-0002WP-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 10:11:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EEH7824576; Mon, 14 Apr 2003 10:17:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EDWI820579 for ; Mon, 14 Apr 2003 09:32:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04430 for ; Mon, 14 Apr 2003 09:24:09 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1953yr-0002AC-00 for rohc@ietf.org; Mon, 14 Apr 2003 09:26:41 -0400 Received: from mail.gmx.net ([213.165.65.60]) by ietf-mx with smtp (Exim 4.12) id 1953yq-00029h-00 for rohc@ietf.org; Mon, 14 Apr 2003 09:26:41 -0400 Received: (qmail 12666 invoked by uid 65534); 14 Apr 2003 13:26:15 -0000 Received: from adsl-27-141.barak.net.il (HELO Yaron) (62.90.27.141) by mail.gmx.net (mp002-rz3) with SMTP; 14 Apr 2003 15:26:15 +0200 Message-ID: <000601c30289$706f3fe0$5a00a8c0@personeta.com> From: "Yaron Sheffer" To: "Lars-Erik Jonsson \(EAB\)" , "IPSec List" , References: Subject: Re: [rohc] FW: ESP and header compression (ROHC) Date: Mon, 14 Apr 2003 16:26:17 +0300 Organization: Personeta MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Lars-Erik, I may have been misunderstood. To clarify, I am discussing the following stack: PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload In some cases, depending on the nature of the flows that use the ESP tunnel, ESP plays the role of a link. In those cases, it makes sense to compress the "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP conversation there will be a single RTP flow within the tunnel, and ROHC is beneficial for the internal headers. In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for IP(2)+UDP+RTP. Regards, Yaron ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" ; "IPSec List" ; Sent: Monday, April 14, 2003 10:04 Subject: RE: [rohc] FW: ESP and header compression (ROHC) > Hi all, > > A few notes: > 1) ROHC is applied on a per-link basis, e.g. over PPP > 2) Based on the above point, there are ROHC compression profiles > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > Compressing the network layer header is most important to gain > anything, but that can only be done on a per-link basis. Header > compression is thus applied per-link to compress network and > transport layer headers (and by heuristics also the application > layer RTP header). It is also simpler to do compression per-link, > as one can optimize for certain assumed characteristics (such as > in-order delivery). Further, it makes most sense as header > compression is an optimization for "narrow links". > > Therefore, I can not see why/how one could do "ROHC over ESP". > > BR > /Lars-Erik > > > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 13 april 2003 21:26 > > To: IPSec List; rohc@ietf.org > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > (please reply to both lists) > > > > Below is my question to Steve Kent (author of the new rev of ESP, and > > co-author of the original RFC) and his reply. I understand > > that IPCOMP is > > inferior to ROHC for RTP streams, and I'd like to hear other opinions > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > This might certaily add complexity to IPSec, but if you make it > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > Thanks, > > Yaron > > > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Thursday, April 10, 2003 12:06 AM > > To: Yaron Sheffer > > Cc: Sara Bitan; kent@bbn.com > > Subject: Re: ESP and header compression (ROHC) > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > >Hi Steve, > > > > > >I have lately looked at issues with IPSec encryption of RTP > > streams (I am > > >aware of SRTP but I think we will want RTP over IPSec for > > some time to > > >come). A major issue is packet overhead. You can use Robust Header > > >Compression (ROHC) on the external IP+ESP headers - this is > > defined by the > > >ROHC RFC. But if you want to header-compress the RTP packets > > before it is > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > because there's no > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > to contain a > > >marker for ROHC packets, similarly to PPP. Has this option > > been considered > > >for the new version of ESP? > > > > > >Thanks, > > > Yaron > > > > No, the WG has not considered that option. The WG has been striving > > to make IPsec simpler and thus adding support for ROHC is contrary to > > that theme. For example, ROHC would have be be implemented within > > IPsec, after the SA lookup was performed, and ROHC decompression > > would have to be implemented in IPsec at the receiver, since the > > receiver has to check the headers against the SAD. IPsec already > > supports IPCOMP as a compression method for whole packets, not just > > headers, and thus it might be hard to persuade the WG to add ROHC > > support too. > > > > But, that's just my impression. You can always raise the > > question on the > > list. > > > > Steve > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Apr 14 21:37:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29730 for ; Mon, 14 Apr 2003 21:37:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F1jNw09660 for rohc-archive@odin.ietf.org; Mon, 14 Apr 2003 21:45:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1jN809657 for ; Mon, 14 Apr 2003 21:45:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29711 for ; Mon, 14 Apr 2003 21:37:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195FQ3-0006jy-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 21:39:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195FQ2-0006ju-00 for rohc-web-archive@ietf.org; Mon, 14 Apr 2003 21:39:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1jC809649; Mon, 14 Apr 2003 21:45:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F1iF809576 for ; Mon, 14 Apr 2003 21:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29696 for ; Mon, 14 Apr 2003 21:35:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195FOx-0006jd-00 for rohc@ietf.org; Mon, 14 Apr 2003 21:38:23 -0400 Received: from [137.132.31.244] (helo=gandalf.icr.a-star.edu.sg) by ietf-mx with esmtp (Exim 4.12) id 195FOv-0006ja-00 for rohc@ietf.org; Mon, 14 Apr 2003 21:38:21 -0400 Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h3F1cmGi014904 for ; Tue, 15 Apr 2003 09:38:48 +0800 (SGT) Received: from bkdom-MTA by mailer.icr.a-star.edu.sg with Novell_GroupWise; Tue, 15 Apr 2003 09:30:31 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Tue, 15 Apr 2003 09:30:10 +0800 From: "Wang Haiguang" To: , , , Subject: Re: [rohc] FW: ESP and header compression (ROHC) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3F1iF809577 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I have also considered this scheme before, that is, compress the header behind the ESP before encryption and decompress it after decription in the end-to-end scenario. What I am not clear is the effect of header compression to security. If I am not wrong, the IPSec has add some padding bytes at the end of the packet in order to hide the length of packet. If we compress the padding bytes, will it endanger the security of the connection? Best regards. Haiguang >>> Yaron Sheffer 04/14/03 09:26pm >>> Hi Lars-Erik, I may have been misunderstood. To clarify, I am discussing the following stack: PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload In some cases, depending on the nature of the flows that use the ESP tunnel, ESP plays the role of a link. In those cases, it makes sense to compress the "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP conversation there will be a single RTP flow within the tunnel, and ROHC is beneficial for the internal headers. In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for IP(2)+UDP+RTP. Regards, Yaron ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" ; "IPSec List" ; Sent: Monday, April 14, 2003 10:04 Subject: RE: [rohc] FW: ESP and header compression (ROHC) > Hi all, > > A few notes: > 1) ROHC is applied on a per-link basis, e.g. over PPP > 2) Based on the above point, there are ROHC compression profiles > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > Compressing the network layer header is most important to gain > anything, but that can only be done on a per-link basis. Header > compression is thus applied per-link to compress network and > transport layer headers (and by heuristics also the application > layer RTP header). It is also simpler to do compression per-link, > as one can optimize for certain assumed characteristics (such as > in-order delivery). Further, it makes most sense as header > compression is an optimization for "narrow links". > > Therefore, I can not see why/how one could do "ROHC over ESP". > > BR > /Lars-Erik > > > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 13 april 2003 21:26 > > To: IPSec List; rohc@ietf.org > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > (please reply to both lists) > > > > Below is my question to Steve Kent (author of the new rev of ESP, and > > co-author of the original RFC) and his reply. I understand > > that IPCOMP is > > inferior to ROHC for RTP streams, and I'd like to hear other opinions > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > This might certaily add complexity to IPSec, but if you make it > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > Thanks, > > Yaron > > > > -----Original Message----- > > From: Stephen Kent [mailto:kent@bbn.com] > > Sent: Thursday, April 10, 2003 12:06 AM > > To: Yaron Sheffer > > Cc: Sara Bitan; kent@bbn.com > > Subject: Re: ESP and header compression (ROHC) > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > >Hi Steve, > > > > > >I have lately looked at issues with IPSec encryption of RTP > > streams (I am > > >aware of SRTP but I think we will want RTP over IPSec for > > some time to > > >come). A major issue is packet overhead. You can use Robust Header > > >Compression (ROHC) on the external IP+ESP headers - this is > > defined by the > > >ROHC RFC. But if you want to header-compress the RTP packets > > before it is > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > because there's no > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > to contain a > > >marker for ROHC packets, similarly to PPP. Has this option > > been considered > > >for the new version of ESP? > > > > > >Thanks, > > > Yaron > > > > No, the WG has not considered that option. The WG has been striving > > to make IPsec simpler and thus adding support for ROHC is contrary to > > that theme. For example, ROHC would have be be implemented within > > IPsec, after the SA lookup was performed, and ROHC decompression > > would have to be implemented in IPsec at the receiver, since the > > receiver has to check the headers against the SAD. IPsec already > > supports IPCOMP as a compression method for whole packets, not just > > headers, and thus it might be hard to persuade the WG to add ROHC > > support too. > > > > But, that's just my impression. You can always raise the > > question on the > > list. > > > > Steve > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 04:05:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18700 for ; Tue, 15 Apr 2003 04:05:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F89jN14511 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 04:09:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F89j814504 for ; Tue, 15 Apr 2003 04:09:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18601 for ; Tue, 15 Apr 2003 04:01:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195LPs-0000qh-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:03:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195LPr-0000qc-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:03:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F89K814477; Tue, 15 Apr 2003 04:09:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F87k814381 for ; Tue, 15 Apr 2003 04:07:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18565 for ; Tue, 15 Apr 2003 03:59:14 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195LNx-0000qH-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:01:45 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 195LNw-0000qC-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:01:44 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Apr 2003 09:01:15 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC0D99@rsys002a.roke.co.uk> From: "West, Mark" To: "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Tue, 15 Apr 2003 09:01:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, Taking the 'ROHC over re-ordering channels' question more generally; RFC 3095 does not work in such an environment. However, we are (I believe) trying to address this issue as part of ROHC for TCP... Anyway, tunnels (and especially IPsec) can simply be treated as a link. In which case, rohc can be applied on that link. In the case of IPsec/ESP it may make a great deal of sense to compress the headers inside of the tunnel encapsulation. The VPN endpoints are probably disjoint from any particular physical link that benefits from compression and so, to me, it makes sense to do the compression in the two different places. Cheers, Mark. -- Mark A. West, Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 -----Original Message----- From: Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] Sent: 14 April 2003 14:47 To: 'Yaron Sheffer'; IPSec List; rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Yaron, That clarified the scenario, just note that "ROHC over tunnels" has not yet been addressed in the ROHC WG. I do not say that that there must be problems with that, but it should be noted that the link assumptions made for ROHC might not match a tunneling case. Anyway, I am not sure you need anything special in the ESP header, but can do per-link compression of the whole chain. You would have an outer and an inner IP header, and the ESP header would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). However, if the inner headers are encrypted, you can of course not compress all headers on a per-link basis. Is that the case you are considering? Cheers, /L-E > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf@gmx.net] > Sent: den 14 april 2003 15:26 > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > Hi Lars-Erik, > > I may have been misunderstood. To clarify, I am discussing > the following > stack: > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > In some cases, depending on the nature of the flows that use > the ESP tunnel, > ESP plays the role of a link. In those cases, it makes sense > to compress the > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > conversation there will be a single RTP flow within the > tunnel, and ROHC is > beneficial for the internal headers. > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > IP(2)+UDP+RTP. > > Regards, > Yaron > > ----- Original Message ----- > From: "Lars-Erik Jonsson (EAB)" > To: "'Yaron Sheffer'" ; "IPSec List" > ; > Sent: Monday, April 14, 2003 10:04 > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > Hi all, > > > > A few notes: > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > 2) Based on the above point, there are ROHC compression profiles > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > Compressing the network layer header is most important to gain > > anything, but that can only be done on a per-link basis. Header > > compression is thus applied per-link to compress network and > > transport layer headers (and by heuristics also the application > > layer RTP header). It is also simpler to do compression per-link, > > as one can optimize for certain assumed characteristics (such as > > in-order delivery). Further, it makes most sense as header > > compression is an optimization for "narrow links". > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > BR > > /Lars-Erik > > > > > > > > > > > -----Original Message----- > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > Sent: den 13 april 2003 21:26 > > > To: IPSec List; rohc@ietf.org > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > (please reply to both lists) > > > > > > Below is my question to Steve Kent (author of the new rev > of ESP, and > > > co-author of the original RFC) and his reply. I understand > > > that IPCOMP is > > > inferior to ROHC for RTP streams, and I'd like to hear > other opinions > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > This might certaily add complexity to IPSec, but if you make it > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > Thanks, > > > Yaron > > > > > > -----Original Message----- > > > From: Stephen Kent [mailto:kent@bbn.com] > > > Sent: Thursday, April 10, 2003 12:06 AM > > > To: Yaron Sheffer > > > Cc: Sara Bitan; kent@bbn.com > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > >Hi Steve, > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > streams (I am > > > >aware of SRTP but I think we will want RTP over IPSec for > > > some time to > > > >come). A major issue is packet overhead. You can use > Robust Header > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > defined by the > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > before it is > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > because there's no > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > to contain a > > > >marker for ROHC packets, similarly to PPP. Has this option > > > been considered > > > >for the new version of ESP? > > > > > > > >Thanks, > > > > Yaron > > > > > > No, the WG has not considered that option. The WG has > been striving > > > to make IPsec simpler and thus adding support for ROHC is > contrary to > > > that theme. For example, ROHC would have be be implemented within > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > would have to be implemented in IPsec at the receiver, since the > > > receiver has to check the headers against the SAD. IPsec already > > > supports IPCOMP as a compression method for whole > packets, not just > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > support too. > > > > > > But, that's just my impression. You can always raise the > > > question on the > > > list. > > > > > > Steve > > > > > > _______________________________________________ > > > Rohc mailing list > > > Rohc@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 04:19:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18849 for ; Tue, 15 Apr 2003 04:19:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F8RaT15158 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 04:27:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8Ra815155 for ; Tue, 15 Apr 2003 04:27:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18846 for ; Tue, 15 Apr 2003 04:19:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Lh9-0000tW-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:21:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195Lh9-0000tT-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:21:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8RQ815145; Tue, 15 Apr 2003 04:27:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8Qk815122 for ; Tue, 15 Apr 2003 04:26:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18841 for ; Tue, 15 Apr 2003 04:18:14 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195LgL-0000tN-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:20:45 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 195LgL-0000tK-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:20:45 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3F8KpI3012650; Tue, 15 Apr 2003 10:20:51 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VD3F65C>; Tue, 15 Apr 2003 10:19:15 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'West, Mark'" , "Rohc (E-mail)" Subject: RE: [rohc] Minutes of the ROHC WG session at IETF 56 Date: Tue, 15 Apr 2003 10:15:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > You didn't mention the 'singer'... ;-) Oh, you're right, I had already forgotten him...it was not in the notes...=) > But seriously..! > > I thought that I'd commented on this, but maybe my e-mail's > just going haywire. Anyway, for the record: > > Regarding SCTP compression, I don't think that we should > worry about the *future* uses of SCTP, at least not until > we've looked at justifications for compressing it now. Agree, and I think this is what Carsten meant with his comment. Arguments like "some people in the XXX WG are currently proposing to use SCTP for YYY" are actually not arguments for us to do compression of SCTP at this point in time. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 04:26:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18900 for ; Tue, 15 Apr 2003 04:26:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F8YE415358 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 04:34:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8YE815355 for ; Tue, 15 Apr 2003 04:34:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18897 for ; Tue, 15 Apr 2003 04:25:41 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195LnY-0000uL-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:28:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195LnY-0000uI-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:28:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8Y2815346; Tue, 15 Apr 2003 04:34:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8XD815330 for ; Tue, 15 Apr 2003 04:33:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18894 for ; Tue, 15 Apr 2003 04:24:41 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Lma-0000uE-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:27:12 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 195LmZ-0000uB-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:27:12 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3F8REI7014242; Tue, 15 Apr 2003 10:27:17 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VD3F7K7>; Tue, 15 Apr 2003 10:25:54 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Tue, 15 Apr 2003 10:22:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Taking the 'ROHC over re-ordering channels' question more > generally; RFC 3095 does not work in such an environment. > However, we are (I believe) trying to address this issue as > part of ROHC for TCP... This was a design decision we made for 3095, but personally I think the modifications needed to make it work also in case of mis-ordering are small. If someone wants to look at this and write some input on it, I would be more than happy. > Anyway, tunnels (and especially IPsec) can simply be treated > as a link. In which case, rohc can be applied on that link. Yes, a "ROHC over tunnels" document could potentially be justifiable. > In the case of IPsec/ESP it may make a great deal of sense to > compress the headers inside of the tunnel encapsulation. The > VPN endpoints are probably disjoint from any particular > physical link that benefits from compression and so, to me, > it makes sense to do the compression in the two different places. Yes, that is what you would have to do if encryption is applied over the tunnel. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 04:41:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19242 for ; Tue, 15 Apr 2003 04:41:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F8nN716846 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 04:49:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8nN816843 for ; Tue, 15 Apr 2003 04:49:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19232 for ; Tue, 15 Apr 2003 04:40:50 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195M2D-0000xq-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:43:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195M2D-0000xn-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:43:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8n9816835; Tue, 15 Apr 2003 04:49:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8mH816794 for ; Tue, 15 Apr 2003 04:48:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19200 for ; Tue, 15 Apr 2003 04:39:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195M19-0000xL-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:42:15 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 195M19-0000x6-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:42:15 -0400 Received: from tmima-w2k.cisco.com (sjc-vpn4-122.cisco.com [10.21.80.122]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3F8fhGP021913; Tue, 15 Apr 2003 01:41:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20030415013913.026d5b38@mira-sjcm-2.cisco.com> X-Sender: tmima@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 01:40:50 -0700 To: "West, Mark" , "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org From: Tmima Koren Subject: RE: [rohc] FW: ESP and header compression (ROHC) In-Reply-To: <76C92FBBFB58D411AE760090271ED41806AC0D99@rsys002a.roke.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , At 09:01 AM 4/15/2003 +0100, West, Mark wrote: >Hi all, > >Taking the 'ROHC over re-ordering channels' question more generally; RFC >3095 does not work in such an environment. However, we are (I believe) >trying to address this issue as part of ROHC for TCP... > >Anyway, tunnels (and especially IPsec) can simply be treated as a >link. In which case, rohc can be applied on that link. But a tunnel is a re-ordering channel Tmima >In the case of IPsec/ESP it may make a great deal of sense to compress the >headers inside of the tunnel encapsulation. The VPN endpoints are >probably disjoint from any particular physical link that benefits from >compression and so, to me, it makes sense to do the compression in the two >different places. > >Cheers, > >Mark. > > >-- >Mark A. West, Consultant Engineer >Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN >Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > >-----Original Message----- >From: Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] >Sent: 14 April 2003 14:47 >To: 'Yaron Sheffer'; IPSec List; rohc@ietf.org >Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > >Yaron, > >That clarified the scenario, just note that "ROHC over tunnels" >has not yet been addressed in the ROHC WG. I do not say that >that there must be problems with that, but it should be noted >that the link assumptions made for ROHC might not match a >tunneling case. > >Anyway, I am not sure you need anything special in the ESP >header, but can do per-link compression of the whole chain. You >would have an outer and an inner IP header, and the ESP header >would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). > >However, if the inner headers are encrypted, you can of course >not compress all headers on a per-link basis. Is that the case >you are considering? > >Cheers, >/L-E > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 14 april 2003 15:26 > > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > > > > Hi Lars-Erik, > > > > I may have been misunderstood. To clarify, I am discussing > > the following > > stack: > > > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > > > In some cases, depending on the nature of the flows that use > > the ESP tunnel, > > ESP plays the role of a link. In those cases, it makes sense > > to compress the > > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > > conversation there will be a single RTP flow within the > > tunnel, and ROHC is > > beneficial for the internal headers. > > > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > > IP(2)+UDP+RTP. > > > > Regards, > > Yaron > > > > ----- Original Message ----- > > From: "Lars-Erik Jonsson (EAB)" > > To: "'Yaron Sheffer'" ; "IPSec List" > > ; > > Sent: Monday, April 14, 2003 10:04 > > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > > > > Hi all, > > > > > > A few notes: > > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > > 2) Based on the above point, there are ROHC compression profiles > > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > > > Compressing the network layer header is most important to gain > > > anything, but that can only be done on a per-link basis. Header > > > compression is thus applied per-link to compress network and > > > transport layer headers (and by heuristics also the application > > > layer RTP header). It is also simpler to do compression per-link, > > > as one can optimize for certain assumed characteristics (such as > > > in-order delivery). Further, it makes most sense as header > > > compression is an optimization for "narrow links". > > > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > > > BR > > > /Lars-Erik > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > > Sent: den 13 april 2003 21:26 > > > > To: IPSec List; rohc@ietf.org > > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > > > > (please reply to both lists) > > > > > > > > Below is my question to Steve Kent (author of the new rev > > of ESP, and > > > > co-author of the original RFC) and his reply. I understand > > > > that IPCOMP is > > > > inferior to ROHC for RTP streams, and I'd like to hear > > other opinions > > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > > > This might certaily add complexity to IPSec, but if you make it > > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > > > Thanks, > > > > Yaron > > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Thursday, April 10, 2003 12:06 AM > > > > To: Yaron Sheffer > > > > Cc: Sara Bitan; kent@bbn.com > > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > > >Hi Steve, > > > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > > streams (I am > > > > >aware of SRTP but I think we will want RTP over IPSec for > > > > some time to > > > > >come). A major issue is packet overhead. You can use > > Robust Header > > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > > defined by the > > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > > before it is > > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > > because there's no > > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > > to contain a > > > > >marker for ROHC packets, similarly to PPP. Has this option > > > > been considered > > > > >for the new version of ESP? > > > > > > > > > >Thanks, > > > > > Yaron > > > > > > > > No, the WG has not considered that option. The WG has > > been striving > > > > to make IPsec simpler and thus adding support for ROHC is > > contrary to > > > > that theme. For example, ROHC would have be be implemented within > > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > > would have to be implemented in IPsec at the receiver, since the > > > > receiver has to check the headers against the SAD. IPsec already > > > > supports IPCOMP as a compression method for whole > > packets, not just > > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > > support too. > > > > > > > > But, that's just my impression. You can always raise the > > > > question on the > > > > list. > > > > > > > > Steve > > > > > > > > _______________________________________________ > > > > Rohc mailing list > > > > Rohc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 04:51:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18699 for ; Tue, 15 Apr 2003 04:05:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F89jN14512 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 04:09:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F89j814506 for ; Tue, 15 Apr 2003 04:09:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18603 for ; Tue, 15 Apr 2003 04:01:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195LPs-0000qi-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:03:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195LPr-0000qb-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 04:03:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F89U814493; Tue, 15 Apr 2003 04:09:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F87k814385 for ; Tue, 15 Apr 2003 04:07:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18566 for ; Tue, 15 Apr 2003 03:59:14 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195LNx-0000qI-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:01:45 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 195LNw-0000qB-00 for rohc@ietf.org; Tue, 15 Apr 2003 04:01:44 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Apr 2003 09:01:13 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC0D9A@rsys002a.roke.co.uk> From: "West, Mark" To: "Lars-Erik Jonsson (EAB)" , "Rohc (E-mail)" Subject: RE: [rohc] Minutes of the ROHC WG session at IETF 56 Date: Tue, 15 Apr 2003 09:01:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , You didn't mention the 'singer'... ;-) But seriously..! I thought that I'd commented on this, but maybe my e-mail's just going haywire. Anyway, for the record: Regarding SCTP compression, I don't think that we should worry about the *future* uses of SCTP, at least not until we've looked at justifications for compressing it now. After all, if we don't understand the future uses of TCP (for example), doesn't that logic preclude us from ever developing a solution, since it might not useful 'in the future'?! Just a thought, Mark. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 06:30:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20905 for ; Tue, 15 Apr 2003 06:30:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FAcTT24282 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 06:38:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FAcT824279 for ; Tue, 15 Apr 2003 06:38:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20865 for ; Tue, 15 Apr 2003 06:29:54 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Njl-0001KU-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 06:32:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195Njl-0001KR-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 06:32:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FAcE824241; Tue, 15 Apr 2003 06:38:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FAbb824207 for ; Tue, 15 Apr 2003 06:37:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20836 for ; Tue, 15 Apr 2003 06:29:02 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Niw-0001Jq-00 for rohc@ietf.org; Tue, 15 Apr 2003 06:31:34 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 195Niv-0001Jk-00 for rohc@ietf.org; Tue, 15 Apr 2003 06:31:33 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Apr 2003 11:31:10 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41806636942@rsys002a.roke.co.uk> From: "West, Mark" To: "'Tmima Koren'" , "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) Date: Tue, 15 Apr 2003 11:31:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Tmima, Whoops - you're quite right! I really must learn to proof-read my e-mails... I was muddling up two thoughts here; let me try again: a tunnel is a link and can be considered as such by rohc-type-compression-schemes. A rohc-type-compression-scheme could then be applied where its assumptions about channel characteristics match those of the link. FWIW, I agree with Lars-Erik that the modifications to do robust header compression over re-ordering channels are small. I may even contribute some text along these lines (once I've sorted out all the other text I already owe...) Cheers, Mark. -----Original Message----- From: Tmima Koren [mailto:tmima@cisco.com] Sent: 15 April 2003 09:41 To: West, Mark; Lars-Erik Jonsson (EAB); 'Yaron Sheffer'; IPSec List; rohc@ietf.org Subject: RE: [rohc] FW: ESP and header compression (ROHC) At 09:01 AM 4/15/2003 +0100, West, Mark wrote: >Hi all, > >Taking the 'ROHC over re-ordering channels' question more generally; RFC >3095 does not work in such an environment. However, we are (I believe) >trying to address this issue as part of ROHC for TCP... > >Anyway, tunnels (and especially IPsec) can simply be treated as a >link. In which case, rohc can be applied on that link. But a tunnel is a re-ordering channel Tmima >In the case of IPsec/ESP it may make a great deal of sense to compress the >headers inside of the tunnel encapsulation. The VPN endpoints are >probably disjoint from any particular physical link that benefits from >compression and so, to me, it makes sense to do the compression in the two >different places. > >Cheers, > >Mark. > > >-- >Mark A. West, Consultant Engineer >Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN >Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > >-----Original Message----- >From: Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] >Sent: 14 April 2003 14:47 >To: 'Yaron Sheffer'; IPSec List; rohc@ietf.org >Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > >Yaron, > >That clarified the scenario, just note that "ROHC over tunnels" >has not yet been addressed in the ROHC WG. I do not say that >that there must be problems with that, but it should be noted >that the link assumptions made for ROHC might not match a >tunneling case. > >Anyway, I am not sure you need anything special in the ESP >header, but can do per-link compression of the whole chain. You >would have an outer and an inner IP header, and the ESP header >would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). > >However, if the inner headers are encrypted, you can of course >not compress all headers on a per-link basis. Is that the case >you are considering? > >Cheers, >/L-E > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 14 april 2003 15:26 > > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > > > > Hi Lars-Erik, > > > > I may have been misunderstood. To clarify, I am discussing > > the following > > stack: > > > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > > > In some cases, depending on the nature of the flows that use > > the ESP tunnel, > > ESP plays the role of a link. In those cases, it makes sense > > to compress the > > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > > conversation there will be a single RTP flow within the > > tunnel, and ROHC is > > beneficial for the internal headers. > > > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > > IP(2)+UDP+RTP. > > > > Regards, > > Yaron > > > > ----- Original Message ----- > > From: "Lars-Erik Jonsson (EAB)" > > To: "'Yaron Sheffer'" ; "IPSec List" > > ; > > Sent: Monday, April 14, 2003 10:04 > > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > > > > Hi all, > > > > > > A few notes: > > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > > 2) Based on the above point, there are ROHC compression profiles > > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > > > Compressing the network layer header is most important to gain > > > anything, but that can only be done on a per-link basis. Header > > > compression is thus applied per-link to compress network and > > > transport layer headers (and by heuristics also the application > > > layer RTP header). It is also simpler to do compression per-link, > > > as one can optimize for certain assumed characteristics (such as > > > in-order delivery). Further, it makes most sense as header > > > compression is an optimization for "narrow links". > > > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > > > BR > > > /Lars-Erik > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > > Sent: den 13 april 2003 21:26 > > > > To: IPSec List; rohc@ietf.org > > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > > > > (please reply to both lists) > > > > > > > > Below is my question to Steve Kent (author of the new rev > > of ESP, and > > > > co-author of the original RFC) and his reply. I understand > > > > that IPCOMP is > > > > inferior to ROHC for RTP streams, and I'd like to hear > > other opinions > > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > > > This might certaily add complexity to IPSec, but if you make it > > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > > > Thanks, > > > > Yaron > > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Thursday, April 10, 2003 12:06 AM > > > > To: Yaron Sheffer > > > > Cc: Sara Bitan; kent@bbn.com > > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > > >Hi Steve, > > > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > > streams (I am > > > > >aware of SRTP but I think we will want RTP over IPSec for > > > > some time to > > > > >come). A major issue is packet overhead. You can use > > Robust Header > > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > > defined by the > > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > > before it is > > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > > because there's no > > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > > to contain a > > > > >marker for ROHC packets, similarly to PPP. Has this option > > > > been considered > > > > >for the new version of ESP? > > > > > > > > > >Thanks, > > > > > Yaron > > > > > > > > No, the WG has not considered that option. The WG has > > been striving > > > > to make IPsec simpler and thus adding support for ROHC is > > contrary to > > > > that theme. For example, ROHC would have be be implemented within > > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > > would have to be implemented in IPsec at the receiver, since the > > > > receiver has to check the headers against the SAD. IPsec already > > > > supports IPCOMP as a compression method for whole > > packets, not just > > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > > support too. > > > > > > > > But, that's just my impression. You can always raise the > > > > question on the > > > > list. > > > > > > > > Steve > > > > > > > > _______________________________________________ > > > > Rohc mailing list > > > > Rohc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 06:49:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21309 for ; Tue, 15 Apr 2003 06:49:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FAvM925073 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 06:57:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FAvM825070 for ; Tue, 15 Apr 2003 06:57:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21279 for ; Tue, 15 Apr 2003 06:48:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195O21-0001OZ-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 06:51:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195O21-0001OV-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 06:51:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FAvA825060; Tue, 15 Apr 2003 06:57:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FAuU825026 for ; Tue, 15 Apr 2003 06:56:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21256 for ; Tue, 15 Apr 2003 06:47:54 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195O1C-0001OB-00 for rohc@ietf.org; Tue, 15 Apr 2003 06:50:26 -0400 Received: from krumelur.sics.se ([193.10.66.109]) by ietf-mx with esmtp (Exim 4.12) id 195O1B-0001O8-00 for rohc@ietf.org; Tue, 15 Apr 2003 06:50:25 -0400 Received: from krumelur.sics.se (localhost [127.0.0.1]) by krumelur.sics.se (8.12.6/8.12.6) with ESMTP id h3FAoT8X084848; Tue, 15 Apr 2003 12:50:29 +0200 (CEST) (envelope-from bg@krumelur.sics.se) Received: (from bg@localhost) by krumelur.sics.se (8.12.6/8.12.6/Submit) id h3FAoSZi084845; Tue, 15 Apr 2003 12:50:28 +0200 (CEST) To: "Lars-Erik Jonsson (EAB)" Cc: "'Yaron Sheffer'" , IPSec List , rohc@ietf.org Subject: Re: [rohc] FW: ESP and header compression (ROHC) References: From: Bjoern Groenvall Date: 15 Apr 2003 12:50:28 +0200 In-Reply-To: "Lars-Erik Jonsson's message of "Tue, 15 Apr 2003 10:22:30 +0200" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , >>>>> "Lars-Erik" == Lars-Erik Jonsson (EAB) writes: >> Taking the 'ROHC over re-ordering channels' question more >> generally; RFC 3095 does not work in such an environment. However, >> we are (I believe) trying to address this issue as part of ROHC for >> TCP... Lars-Erik> This was a design decision we made for 3095, but personally Lars-Erik> I think the modifications needed to make it work also in Lars-Erik> case of mis-ordering are small. If someone wants to look at Lars-Erik> this and write some input on it, I would be more than Lars-Erik> happy. The ESP and AH headers also have a "Sequence Number"-field that may be used to detect reordering and packet losses. /Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 08:25:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25291 for ; Tue, 15 Apr 2003 08:25:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FCXdw31689 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 08:33:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCXd831686 for ; Tue, 15 Apr 2003 08:33:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25279 for ; Tue, 15 Apr 2003 08:25:01 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195PXB-0002JK-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 08:27:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195PXA-0002JH-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 08:27:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCX9831655; Tue, 15 Apr 2003 08:33:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EEtw827246 for ; Mon, 14 Apr 2003 10:55:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08024 for ; Mon, 14 Apr 2003 10:47:47 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1955Hn-0002hM-00 for rohc@ietf.org; Mon, 14 Apr 2003 10:50:19 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1955Hm-0002h8-00 for rohc@ietf.org; Mon, 14 Apr 2003 10:50:18 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3EEnC5w002682; Mon, 14 Apr 2003 10:49:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 14 Apr 2003 10:49:01 -0400 To: "Yaron Sheffer" From: Stephen Kent Cc: "IPSec List" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [rohc] Re: FW: ESP and header compression (ROHC) Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , At 9:26 PM +0200 4/13/03, Yaron Sheffer wrote: >(please reply to both lists) > >Below is my question to Steve Kent (author of the new rev of ESP, and >co-author of the original RFC) and his reply. I understand that IPCOMP is >inferior to ROHC for RTP streams, and I'd like to hear other opinions >regarding the usefulness of an "ROHC" indicator in ESP. > >This might certaily add complexity to IPSec, but if you make it >non-negotiable and non-mandatory, it cannot be too terrible. > >Thanks, > Yaron Yaron, If the ability to do this was "non-negotiable and non-mandatory" how would two IPsec peers know when to do this? Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 08:25:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25299 for ; Tue, 15 Apr 2003 08:25:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FCXe931705 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 08:33:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCXe831702 for ; Tue, 15 Apr 2003 08:33:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25283 for ; Tue, 15 Apr 2003 08:25:01 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195PXB-0002JQ-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 08:27:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195PXB-0002JN-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 08:27:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCX9831675; Tue, 15 Apr 2003 08:33:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2g3813535 for ; Mon, 14 Apr 2003 22:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00853 for ; Mon, 14 Apr 2003 22:33:38 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195GIs-0006yh-00 for rohc@ietf.org; Mon, 14 Apr 2003 22:36:10 -0400 Received: from bi-01pt1.bluebird.ibm.com ([129.42.208.186] helo=ace.iris.com) by ietf-mx with esmtp (Exim 4.12) id 195GIr-0006yZ-00 for rohc@ietf.org; Mon, 14 Apr 2003 22:36:09 -0400 In-Reply-To: <000601c30289$706f3fe0$5a00a8c0@personeta.com> Subject: Re: [rohc] FW: ESP and header compression (ROHC) To: "Yaron Sheffer" Cc: "IPSec List" , "Lars-Erik Jonsson \(EAB\)" , owner-ipsec@lists.tislabs.com, rohc@ietf.org X-Mailer: Lotus Notes Build V602_04062003NP April 06, 2003 Message-ID: Date: Mon, 14 Apr 2003 22:29:38 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_04072003NP|April 07, 2003) at 04/14/2003 10:36:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > I may have been misunderstood. To clarify, I am discussing the following > stack: > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > In some cases, depending on the nature of the flows that use the ESP tunnel, > ESP plays the role of a link. In those cases, it makes sense to compress the > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > conversation there will be a single RTP flow within the tunnel, and ROHC is > beneficial for the internal headers. > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > IP(2)+UDP+RTP. I am not familiar with the details of ROHC, so these comments may be completely out to lunch. If so, just ignore me. Assuming ROHC is designed to compress an unreliable reorderable packet stream, it would seem the most natural way to do this would be to define a new IPcomp compression algorithm based on ROHC. Then the stack would look like: PPP | IP(1) | ESP | {IPcomp | {IP(2) | UDP | RTP | Payload}compressed }encrypted If ROHC compresses an unreliable but ordered packet stream, it would be still be possible to implement it, though it would force the decompressing end to either discard out of order packets or increase latency trying to reconstruct the original order. If it compresses a reliable packet stream, it seems inappropriate to use it inside ESP. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 08:25:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25320 for ; Tue, 15 Apr 2003 08:25:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FCXmR31721 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 08:33:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCXl831718 for ; Tue, 15 Apr 2003 08:33:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25287 for ; Tue, 15 Apr 2003 08:25:09 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195PXJ-0002JW-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 08:27:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195PXJ-0002JT-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 08:27:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCX8831637; Tue, 15 Apr 2003 08:33:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EEnY827016 for ; Mon, 14 Apr 2003 10:49:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07947 for ; Mon, 14 Apr 2003 10:41:23 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1955Bb-0002gB-00 for rohc@ietf.org; Mon, 14 Apr 2003 10:43:55 -0400 Received: from mail.gmx.net ([213.165.65.60]) by ietf-mx with smtp (Exim 4.12) id 1955Bb-0002fx-00 for rohc@ietf.org; Mon, 14 Apr 2003 10:43:55 -0400 Received: (qmail 3177 invoked by uid 65534); 14 Apr 2003 14:43:23 -0000 Received: from adsl-27-141.barak.net.il (HELO Yaron) (62.90.27.141) by mail.gmx.net (mp007-rz3) with SMTP; 14 Apr 2003 16:43:23 +0200 Message-ID: <000801c30294$377c1540$5a00a8c0@personeta.com> From: "Yaron Sheffer" To: "Lars-Erik Jonsson \(EAB\)" , "IPSec List" , References: Subject: Re: [rohc] FW: ESP and header compression (ROHC) Date: Mon, 14 Apr 2003 17:43:23 +0300 Organization: Personeta MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Lars-Erik, You are right, I was considering the encrypted case. ESP is only interesting if the inner headers (and the payload, of course) are encrypted. Which is why you need to compress the inner part before encryption, and the outer part after. You'd need a special marker in the ESP header to denote a compressed packet, just as you do in PPP. The existing ESP (RFC 2406) has a Next Header field, which contains a "protocol number" (see http://www.iana.org/assignments/protocol-numbers). For ESP in "tunnel mode" this field holds the value for IP. AFAIK, there is no value for ROHC. Best regards, Yaron ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" ; "IPSec List" ; Sent: Monday, April 14, 2003 16:46 Subject: RE: [rohc] FW: ESP and header compression (ROHC) > Yaron, > > That clarified the scenario, just note that "ROHC over tunnels" > has not yet been addressed in the ROHC WG. I do not say that > that there must be problems with that, but it should be noted > that the link assumptions made for ROHC might not match a > tunneling case. > > Anyway, I am not sure you need anything special in the ESP > header, but can do per-link compression of the whole chain. You > would have an outer and an inner IP header, and the ESP header > would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). > > However, if the inner headers are encrypted, you can of course > not compress all headers on a per-link basis. Is that the case > you are considering? > > Cheers, > /L-E > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 14 april 2003 15:26 > > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > > > > Hi Lars-Erik, > > > > I may have been misunderstood. To clarify, I am discussing > > the following > > stack: > > > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > > > In some cases, depending on the nature of the flows that use > > the ESP tunnel, > > ESP plays the role of a link. In those cases, it makes sense > > to compress the > > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > > conversation there will be a single RTP flow within the > > tunnel, and ROHC is > > beneficial for the internal headers. > > > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > > IP(2)+UDP+RTP. > > > > Regards, > > Yaron > > > > ----- Original Message ----- > > From: "Lars-Erik Jonsson (EAB)" > > To: "'Yaron Sheffer'" ; "IPSec List" > > ; > > Sent: Monday, April 14, 2003 10:04 > > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > > > > Hi all, > > > > > > A few notes: > > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > > 2) Based on the above point, there are ROHC compression profiles > > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > > > Compressing the network layer header is most important to gain > > > anything, but that can only be done on a per-link basis. Header > > > compression is thus applied per-link to compress network and > > > transport layer headers (and by heuristics also the application > > > layer RTP header). It is also simpler to do compression per-link, > > > as one can optimize for certain assumed characteristics (such as > > > in-order delivery). Further, it makes most sense as header > > > compression is an optimization for "narrow links". > > > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > > > BR > > > /Lars-Erik > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > > Sent: den 13 april 2003 21:26 > > > > To: IPSec List; rohc@ietf.org > > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > > > > (please reply to both lists) > > > > > > > > Below is my question to Steve Kent (author of the new rev > > of ESP, and > > > > co-author of the original RFC) and his reply. I understand > > > > that IPCOMP is > > > > inferior to ROHC for RTP streams, and I'd like to hear > > other opinions > > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > > > This might certaily add complexity to IPSec, but if you make it > > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > > > Thanks, > > > > Yaron > > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Thursday, April 10, 2003 12:06 AM > > > > To: Yaron Sheffer > > > > Cc: Sara Bitan; kent@bbn.com > > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > > >Hi Steve, > > > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > > streams (I am > > > > >aware of SRTP but I think we will want RTP over IPSec for > > > > some time to > > > > >come). A major issue is packet overhead. You can use > > Robust Header > > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > > defined by the > > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > > before it is > > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > > because there's no > > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > > to contain a > > > > >marker for ROHC packets, similarly to PPP. Has this option > > > > been considered > > > > >for the new version of ESP? > > > > > > > > > >Thanks, > > > > > Yaron > > > > > > > > No, the WG has not considered that option. The WG has > > been striving > > > > to make IPsec simpler and thus adding support for ROHC is > > contrary to > > > > that theme. For example, ROHC would have be be implemented within > > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > > would have to be implemented in IPsec at the receiver, since the > > > > receiver has to check the headers against the SAD. IPsec already > > > > supports IPCOMP as a compression method for whole > > packets, not just > > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > > support too. > > > > > > > > But, that's just my impression. You can always raise the > > > > question on the > > > > list. > > > > > > > > Steve > > > > > > > > _______________________________________________ > > > > Rohc mailing list > > > > Rohc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 09:30:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26946 for ; Tue, 15 Apr 2003 09:30:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FDcih04120 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 09:38:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDch804117 for ; Tue, 15 Apr 2003 09:38:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26920 for ; Tue, 15 Apr 2003 09:30:05 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195QY8-0002a4-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 09:32:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195QY7-0002a1-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 09:32:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDcQ804104; Tue, 15 Apr 2003 09:38:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDbV804062 for ; Tue, 15 Apr 2003 09:37:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26877 for ; Tue, 15 Apr 2003 09:28:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195QWy-0002ZI-00 for rohc@ietf.org; Tue, 15 Apr 2003 09:31:24 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 195QWx-0002ZF-00 for rohc@ietf.org; Tue, 15 Apr 2003 09:31:23 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3FDVTI4001378 for ; Tue, 15 Apr 2003 15:31:30 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VD3KF58>; Tue, 15 Apr 2003 15:31:27 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Ghyslain Pelletier (EAB)" Cc: rohc@ietf.org Date: Tue, 15 Apr 2003 15:31:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3FDbV804063 Subject: [rohc] RE: Minor comment on Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3FDcQ804104 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3FDch804117 Content-Transfer-Encoding: 8bit Ghyslain, Your comment makes sense, I'll change this as suggested! BR, /L-E > -----Original Message----- > From: Ghyslain Pelletier (EAB) > Sent: den 7 april 2003 12:12 > To: Lars-Erik Jonsson (EAB) > Cc: rohc@ietf.org > Subject: Minor comment on > > > Lars-Erik, > > A small suggestion for better clarity - the last sentence of > section 3.2 > of the IP-only draft - > > Note further that additional dynamic chains in compressed packets > do not have this sequence number at the end of the chain, as SN is > present within compressed base headers. > > - should be moved to section 3.3, and be slightly > reformulated to be put > in relation to the figure in that same section: > > Note that the list of dynamic chains for the additional IP headers > in compressed packets do not have a sequence number at the end of > the chain, as SN is already present within compressed base headers. > > The reason for this comment is that section 3.2 is about IR > packets, and > section 3.3 is about compressed packets; howver the note is about a > clarification of the format of the compressed packets and not for the > format of the IR packets - therefore I find the current > location of the > note somewhat confusing. Just a though... > > Regards, > > /Ghyslain > > Ghyslain Pelletier > Wireless IP Optimizations > AWARE - Advanced Wireless Algorithm Research > Ericsson Research, Corporate Unit > Ericsson AB > Luleå, Sweden > Phone : +46 (0) 920 20 24 32 > Mobile: +46 (0) 70 609 27 73 > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 09:33:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27040 for ; Tue, 15 Apr 2003 09:33:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FDfLA04444 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 09:41:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDfL804441 for ; Tue, 15 Apr 2003 09:41:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27016 for ; Tue, 15 Apr 2003 09:32:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Qaf-0002aq-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 09:35:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195Qae-0002an-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 09:35:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDf3804353; Tue, 15 Apr 2003 09:41:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDaV803198 for ; Tue, 15 Apr 2003 09:36:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26869 for ; Tue, 15 Apr 2003 09:27:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195QVz-0002Z5-00 for rohc@ietf.org; Tue, 15 Apr 2003 09:30:23 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 195QVz-0002Z2-00 for rohc@ietf.org; Tue, 15 Apr 2003 09:30:23 -0400 Received: from MCGREW-W2K.cisco.com (dhcp-128-107-163-135.cisco.com [128.107.163.135]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3FDTkB1000712; Tue, 15 Apr 2003 09:29:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 06:29:45 -0700 To: "Wang Haiguang" From: David Mcgrew Cc: , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [rohc] (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Wang, length-hiding is an ESP option. If it is not used, then the traffic protected by ESP might be more susceptible to traffic analysis. For some applications, this is not a big deal. For example: no adversary is going to be surprised that an IP telephone sends 50 voice packets a second, nor would any adversary be fooled by the padding. To my mind, length-hiding is probably incompatible with header compression, though I don't see any security issues that would result from using them in conjunction. There are other security issues, though. The fact that the header compression is stateful (i.e., the decompression of a packet depends on the packets that have been received before) means that an adversary can force the receiver into decompressing incorrectly by re-ordering packets. The use of message authentication and replay protection doesn't stop this attack. ESP was designed to be tolerant of packet reorder, so using it with a stateful decompressor is problematic. There are two ways out of this bind: use a decompressor that won't cause any security failures due to reorder (which requires lots of careful analysis), or authenticate the message *before* it is compressed, rather than after it is compressed (which requires some encapsulation other than ESP). Jan Vilhuber and I have been working on both of these approaches. If there is interest, we could bring this work to the IETF, though I'm not sure that WG would be appropriate. David At 09:30 AM 4/15/2003 +0800, Wang Haiguang wrote: >To: , , , > >Subject: Re: [rohc] FW: ESP and header compression (ROHC) > >Hi, > >I have also considered this scheme before, that is, compress the header >behind the ESP before encryption and decompress it after decription in the >end-to-end scenario. > >What I am not clear is the effect of header compression to security. >If I am not wrong, the IPSec has add some padding bytes at the >end of the packet in order to hide the length of packet. > >If we compress the padding bytes, will it endanger the security of the >connection? > >Best regards. > >Haiguang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 09:33:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27054 for ; Tue, 15 Apr 2003 09:33:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FDfNt04461 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 09:41:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDfN804458 for ; Tue, 15 Apr 2003 09:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27020 for ; Tue, 15 Apr 2003 09:32:45 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Qah-0002aw-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 09:35:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195Qah-0002at-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 09:35:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDf2804337; Tue, 15 Apr 2003 09:41:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FDBD802272 for ; Tue, 15 Apr 2003 09:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26276 for ; Tue, 15 Apr 2003 09:02:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Q7W-0002Th-00 for rohc@ietf.org; Tue, 15 Apr 2003 09:05:06 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 195Q7V-0002TX-00 for rohc@ietf.org; Tue, 15 Apr 2003 09:05:05 -0400 Received: from MCGREW-W2K.cisco.com (dhcp-128-107-163-135.cisco.com [128.107.163.135]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3FD4ZB1024412; Tue, 15 Apr 2003 09:04:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415055212.00b72e20@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 06:04:34 -0700 To: "West, Mark" From: David Mcgrew Subject: RE: [rohc] FW: ESP and header compression (ROHC) Cc: "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org In-Reply-To: <76C92FBBFB58D411AE760090271ED41806AC0D99@rsys002a.roke.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Mark, At 09:01 AM 4/15/2003 +0100, West, Mark wrote: >Hi all, > >Taking the 'ROHC over re-ordering channels' question more generally; RFC >3095 does not work in such an environment. However, we are (I believe) >trying to address this issue as part of ROHC for TCP... > >Anyway, tunnels (and especially IPsec) can simply be treated as a >link. In which case, rohc can be applied on that link. > >In the case of IPsec/ESP it may make a great deal of sense to compress the >headers inside of the tunnel encapsulation. The VPN endpoints are >probably disjoint from any particular physical link that benefits from >compression and so, to me, it makes sense to do the compression in the two >different places. yes, I think that's right. It seems to be the case that inner-tunnel header compression is worthwhile for telephony. Do you think that it would be worth doing for wireless links as well? I guess that the answer might depend on the traffic that's going over the VPN link. There are some subtle security issues with this sort of scheme, but I don't think that they're insuperable. David >Cheers, > >Mark. > > >-- >Mark A. West, Consultant Engineer >Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN >Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > >-----Original Message----- >From: Lars-Erik Jonsson (EAB) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] >Sent: 14 April 2003 14:47 >To: 'Yaron Sheffer'; IPSec List; rohc@ietf.org >Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > >Yaron, > >That clarified the scenario, just note that "ROHC over tunnels" >has not yet been addressed in the ROHC WG. I do not say that >that there must be problems with that, but it should be noted >that the link assumptions made for ROHC might not match a >tunneling case. > >Anyway, I am not sure you need anything special in the ESP >header, but can do per-link compression of the whole chain. You >would have an outer and an inner IP header, and the ESP header >would be part of a compressed chain (RFC 3095 section 5.8, 5.8.4.3). > >However, if the inner headers are encrypted, you can of course >not compress all headers on a per-link basis. Is that the case >you are considering? > >Cheers, >/L-E > > > > -----Original Message----- > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > Sent: den 14 april 2003 15:26 > > To: Lars-Erik Jonsson (EAB); IPSec List; rohc@ietf.org > > Subject: Re: [rohc] FW: ESP and header compression (ROHC) > > > > > > Hi Lars-Erik, > > > > I may have been misunderstood. To clarify, I am discussing > > the following > > stack: > > > > PPP | IP(1) | ESP | IP(2) | UDP | RTP | Payload > > > > In some cases, depending on the nature of the flows that use > > the ESP tunnel, > > ESP plays the role of a link. In those cases, it makes sense > > to compress the > > "internal" headers, i.e. IP(2)+UDP+RTP. In a simple end-to-end SIP > > conversation there will be a single RTP flow within the > > tunnel, and ROHC is > > beneficial for the internal headers. > > > > In fact, you can use ROHC *twice*, once for IP(1)+ESP and once for > > IP(2)+UDP+RTP. > > > > Regards, > > Yaron > > > > ----- Original Message ----- > > From: "Lars-Erik Jonsson (EAB)" > > To: "'Yaron Sheffer'" ; "IPSec List" > > ; > > Sent: Monday, April 14, 2003 10:04 > > Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > > > > > > Hi all, > > > > > > A few notes: > > > 1) ROHC is applied on a per-link basis, e.g. over PPP > > > 2) Based on the above point, there are ROHC compression profiles > > > defined for IP/UDP, IP/UDP/RTP, IP/ESP (and soon IP-only) > > > > > > Compressing the network layer header is most important to gain > > > anything, but that can only be done on a per-link basis. Header > > > compression is thus applied per-link to compress network and > > > transport layer headers (and by heuristics also the application > > > layer RTP header). It is also simpler to do compression per-link, > > > as one can optimize for certain assumed characteristics (such as > > > in-order delivery). Further, it makes most sense as header > > > compression is an optimization for "narrow links". > > > > > > Therefore, I can not see why/how one could do "ROHC over ESP". > > > > > > BR > > > /Lars-Erik > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Yaron Sheffer [mailto:yaronf@gmx.net] > > > > Sent: den 13 april 2003 21:26 > > > > To: IPSec List; rohc@ietf.org > > > > Subject: [rohc] FW: ESP and header compression (ROHC) > > > > > > > > > > > > (please reply to both lists) > > > > > > > > Below is my question to Steve Kent (author of the new rev > > of ESP, and > > > > co-author of the original RFC) and his reply. I understand > > > > that IPCOMP is > > > > inferior to ROHC for RTP streams, and I'd like to hear > > other opinions > > > > regarding the usefulness of an "ROHC" indicator in ESP. > > > > > > > > This might certaily add complexity to IPSec, but if you make it > > > > non-negotiable and non-mandatory, it cannot be too terrible. > > > > > > > > Thanks, > > > > Yaron > > > > > > > > -----Original Message----- > > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sent: Thursday, April 10, 2003 12:06 AM > > > > To: Yaron Sheffer > > > > Cc: Sara Bitan; kent@bbn.com > > > > Subject: Re: ESP and header compression (ROHC) > > > > > > > > > > > > At 11:25 PM +0200 4/9/03, Yaron Sheffer wrote: > > > > >Hi Steve, > > > > > > > > > >I have lately looked at issues with IPSec encryption of RTP > > > > streams (I am > > > > >aware of SRTP but I think we will want RTP over IPSec for > > > > some time to > > > > >come). A major issue is packet overhead. You can use > > Robust Header > > > > >Compression (ROHC) on the external IP+ESP headers - this is > > > > defined by the > > > > >ROHC RFC. But if you want to header-compress the RTP packets > > > > before it is > > > > >tunneled in ESP (IP+UDP+RTP headers), you cannot do it > > > > because there's no > > > > >way to detect ROHC packets in the ESP header. I'd expect ESP > > > > to contain a > > > > >marker for ROHC packets, similarly to PPP. Has this option > > > > been considered > > > > >for the new version of ESP? > > > > > > > > > >Thanks, > > > > > Yaron > > > > > > > > No, the WG has not considered that option. The WG has > > been striving > > > > to make IPsec simpler and thus adding support for ROHC is > > contrary to > > > > that theme. For example, ROHC would have be be implemented within > > > > IPsec, after the SA lookup was performed, and ROHC decompression > > > > would have to be implemented in IPsec at the receiver, since the > > > > receiver has to check the headers against the SAD. IPsec already > > > > supports IPCOMP as a compression method for whole > > packets, not just > > > > headers, and thus it might be hard to persuade the WG to add ROHC > > > > support too. > > > > > > > > But, that's just my impression. You can always raise the > > > > question on the > > > > list. > > > > > > > > Steve > > > > > > > > _______________________________________________ > > > > Rohc mailing list > > > > Rohc@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rohc > > > > > > > > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 14:12:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05863 for ; Tue, 15 Apr 2003 14:12:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FIKho24931 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 14:20:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FIKh824928 for ; Tue, 15 Apr 2003 14:20:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05845 for ; Tue, 15 Apr 2003 14:11:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Uwv-0003qQ-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 14:14:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195Uwv-0003qN-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 14:14:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FIKH824907; Tue, 15 Apr 2003 14:20:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FIJp824851 for ; Tue, 15 Apr 2003 14:19:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05839 for ; Tue, 15 Apr 2003 14:11:06 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Uw5-0003qJ-00 for rohc@ietf.org; Tue, 15 Apr 2003 14:13:37 -0400 Received: from optima.cs.arizona.edu ([192.12.69.5]) by ietf-mx with esmtp (Exim 4.12) id 195Uw5-0003qG-00 for rohc@ietf.org; Tue, 15 Apr 2003 14:13:37 -0400 Received: from baskerville.CS.Arizona.EDU (baskerville.cs.arizona.edu [192.12.69.35]) by optima.cs.arizona.edu (8.12.6p2/8.12.6) with ESMTP id h3FIDC3k095347; Tue, 15 Apr 2003 11:13:12 -0700 (MST) (envelope-from micke@cs.arizona.edu) Received: from scarpa (localhost [127.0.0.1]) by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) with SMTP id h3FIDBT09776; Tue, 15 Apr 2003 11:13:11 -0700 (MST) Message-ID: <003701c303b5$55397a60$f0448796@degermark.com> From: "Mikael Degermark" To: "Lars-Erik Jonsson \(EAB\)" Cc: References: Subject: Re: [rohc] FW: ESP and header compression (ROHC) Date: Tue, 15 Apr 2003 18:13:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit What will be needed for "ROHC over tunnels" is allocation of an IP type identifier for ROHC. A "ROHC over tunnels" document would then be exactly the fodder we'd need to feed to the IANA/IESG in order to allocate such an identifier. The indentifier would mean "the payload is a ROHC packet". The profiles used over such a tunnel should be able to deal with the kind of reordering and loss one would see in the tunnel. There may be a need for a negotiation procedure to negotiate ROHC parameters over the tunnel, but I'm not entirely sure this will be needed in all cases. If we decide that it IS needed, that negotiation might be defined the "ROHC over tunnels" document as well. Mikael Degermark ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "'Yaron Sheffer'" ; "IPSec List" ; Sent: Tuesday, April 15, 2003 1:22 AM Subject: RE: [rohc] FW: ESP and header compression (ROHC) > > Taking the 'ROHC over re-ordering channels' question more > > generally; RFC 3095 does not work in such an environment. > > However, we are (I believe) trying to address this issue as > > part of ROHC for TCP... > > This was a design decision we made for 3095, but personally > I think the modifications needed to make it work also in case > of mis-ordering are small. If someone wants to look at this > and write some input on it, I would be more than happy. > > > > Anyway, tunnels (and especially IPsec) can simply be treated > > as a link. In which case, rohc can be applied on that link. > > Yes, a "ROHC over tunnels" document could potentially be > justifiable. > > > > In the case of IPsec/ESP it may make a great deal of sense to > > compress the headers inside of the tunnel encapsulation. The > > VPN endpoints are probably disjoint from any particular > > physical link that benefits from compression and so, to me, > > it makes sense to do the compression in the two different places. > > Yes, that is what you would have to do if encryption is applied > over the tunnel. > > /L-E > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 18:05:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13447 for ; Tue, 15 Apr 2003 18:05:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FMDbd10197 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 18:13:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FMDb810194 for ; Tue, 15 Apr 2003 18:13:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13386 for ; Tue, 15 Apr 2003 18:04:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195YaE-0004zF-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 18:07:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195YaE-0004zC-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 18:07:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FMDO810176; Tue, 15 Apr 2003 18:13:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FM8k810013 for ; Tue, 15 Apr 2003 18:08:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13167 for ; Tue, 15 Apr 2003 17:59:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195YV9-0004xz-00 for rohc@ietf.org; Tue, 15 Apr 2003 18:02:03 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 195YV8-0004xu-00 for rohc@ietf.org; Tue, 15 Apr 2003 18:02:02 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3FM0160014283; Tue, 15 Apr 2003 18:00:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 15 Apr 2003 17:58:21 -0400 To: "Wang Haiguang" From: Stephen Kent Subject: Re: [rohc] FW: ESP and header compression (ROHC) Cc: , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , At 9:30 AM +0800 4/15/03, Wang Haiguang wrote: >Hi, > >I have also considered this scheme before, that is, compress the header >behind the ESP before encryption and decompress it after decription in the >end-to-end scenario. > >What I am not clear is the effect of header compression to security. >If I am not wrong, the IPSec has add some padding bytes at the >end of the packet in order to hide the length of packet. > >If we compress the padding bytes, will it endanger the security of >the connection? > >Best regards. > >Haiguang I do not believe this is a concern. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 15 18:10:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13962 for ; Tue, 15 Apr 2003 18:10:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FMIMY10345 for rohc-archive@odin.ietf.org; Tue, 15 Apr 2003 18:18:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FMIM810342 for ; Tue, 15 Apr 2003 18:18:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13898 for ; Tue, 15 Apr 2003 18:09:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Yeq-00050b-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 18:12:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195Yep-00050Y-00 for rohc-web-archive@ietf.org; Tue, 15 Apr 2003 18:12:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FMI0810330; Tue, 15 Apr 2003 18:18:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FMHY810313 for ; Tue, 15 Apr 2003 18:17:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13823 for ; Tue, 15 Apr 2003 18:08:45 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Ye4-00050Q-00 for rohc@ietf.org; Tue, 15 Apr 2003 18:11:16 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 195Ye3-00050G-00 for rohc@ietf.org; Tue, 15 Apr 2003 18:11:15 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3FMA35w014828; Tue, 15 Apr 2003 18:10:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> References: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> Date: Tue, 15 Apr 2003 18:07:46 -0400 To: David Mcgrew From: Stephen Kent Cc: "Wang Haiguang" , , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [rohc] Re: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , At 6:29 AM -0700 4/15/03, David Mcgrew wrote: >Wang, > >length-hiding is an ESP option. If it is not used, then the traffic >protected by ESP might be more susceptible to traffic analysis. For >some applications, this is not a big deal. For example: no >adversary is going to be surprised that an IP telephone sends 50 >voice packets a second, nor would any adversary be fooled by the >padding. To my mind, length-hiding is probably incompatible with >header compression, though I don't see any security issues that >would result from using them in conjunction. > >There are other security issues, though. The fact that the header >compression is stateful (i.e., the decompression of a packet depends >on the packets that have been received before) means that an >adversary can force the receiver into decompressing incorrectly by >re-ordering packets. The use of message authentication and replay >protection doesn't stop this attack. ESP was designed to be >tolerant of packet reorder, so using it with a stateful decompressor >is problematic. > >There are two ways out of this bind: use a decompressor that won't >cause any security failures due to reorder (which requires lots of >careful analysis), or authenticate the message *before* it is >compressed, rather than after it is compressed (which requires some >encapsulation other than ESP). Jan Vilhuber and I have been working >on both of these approaches. If there is interest, we could bring >this work to the IETF, though I'm not sure that WG would be >appropriate. > >David David, If we provide support for ROHC within ESP, then for outbound processing, the security checks (matching against the traffic selectors) have to be performed prior to compression. This is a natural order of processing, since one must match against the selectors in order to select the right SA, and then determine that the SA in question calls for compression. At the receiver, similar checks must be performed on the received packet, after decompression. But, these checks are performed after authentication anyway, so this constraint does not impose an ordering requirement on authentication vs. decompression. If we stick with the IPCOMP model, as Charlie proposed, then authentication would occur first, then decompression, and I think that is a reasonable ordering approach, which also addresses the concerns you cite above. The big question for IPsec is whether ROHC can it be considered an IPCOMP instance and thus fit within the existing framework. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 16 02:40:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20123 for ; Wed, 16 Apr 2003 02:40:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3G6mao23068 for rohc-archive@odin.ietf.org; Wed, 16 Apr 2003 02:48:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G6ma823065 for ; Wed, 16 Apr 2003 02:48:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20098 for ; Wed, 16 Apr 2003 02:39:35 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195gcP-00073w-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 02:42:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195gcP-00073s-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 02:42:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G6mK823042; Wed, 16 Apr 2003 02:48:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FH0p819174 for ; Tue, 15 Apr 2003 13:00:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03802 for ; Tue, 15 Apr 2003 12:52:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Thg-0003Xi-00 for rohc@ietf.org; Tue, 15 Apr 2003 12:54:40 -0400 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by ietf-mx with esmtp (Exim 4.12) id 195Thf-0003Xf-00 for rohc@ietf.org; Tue, 15 Apr 2003 12:54:39 -0400 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h3FGsbfB017497; Tue, 15 Apr 2003 12:54:38 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3FGsYIS004943; Tue, 15 Apr 2003 12:54:34 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3FGsXU8025292; Tue, 15 Apr 2003 12:54:33 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id MAA05650; Tue, 15 Apr 2003 12:54:33 -0400 (EDT) To: David Mcgrew Cc: "West, Mark" , "Lars-Erik Jonsson (EAB)" , "'Yaron Sheffer'" , IPSec List , rohc@ietf.org From: Derek Atkins Subject: Re: [rohc] FW: ESP and header compression (ROHC) References: <4.3.2.7.2.20030415055212.00b72e20@mira-sjcm-1.cisco.com> Date: 15 Apr 2003 12:54:33 -0400 In-Reply-To: <4.3.2.7.2.20030415055212.00b72e20@mira-sjcm-1.cisco.com> Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , David Mcgrew writes: > > In the case of IPsec/ESP it may make a great deal of sense to > > compress the headers inside of the tunnel encapsulation. The VPN > > endpoints are probably disjoint from any particular physical link > > that benefits from compression and so, to me, it makes sense to do > > the compression in the two different places. > > yes, I think that's right. It seems to be the case that inner-tunnel > header compression is worthwhile for telephony. Do you think that it > would be worth doing for wireless links as well? I guess that the > answer might depend on the traffic that's going over the VPN link. > > There are some subtle security issues with this sort of scheme, but I > don't think that they're insuperable. It sounds like this is a job for a new IPCOMP algorithm type. Define an IPCOMP Algorithm that performs 'ROHC' operations inside the tunnel, so you get: IP ESP IPCOMP IP UDP RTP ... You could even perform ROHC on the outside packet, too. Indeed, one could even use the IPCOMP SA state to pre-configure known compression points (for example, if the internal network is an IPv4 /24, you could always reduce one address to a single 8-bit number because the other 24 bits are "understood". Similar for port numbers, if you have a limited SA you can put the information into the SA and then strip it out of the actual packet. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 16 04:53:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22954 for ; Wed, 16 Apr 2003 04:53:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3G91kX00390 for rohc-archive@odin.ietf.org; Wed, 16 Apr 2003 05:01:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G91j800387 for ; Wed, 16 Apr 2003 05:01:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22950 for ; Wed, 16 Apr 2003 04:52:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195ihF-0007g3-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 04:55:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195ihF-0007g0-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 04:55:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G91O800355; Wed, 16 Apr 2003 05:01:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G90d800307 for ; Wed, 16 Apr 2003 05:00:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22935 for ; Wed, 16 Apr 2003 04:51:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195igA-0007fl-00 for rohc@ietf.org; Wed, 16 Apr 2003 04:54:06 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 195igA-0007fi-00 for rohc@ietf.org; Wed, 16 Apr 2003 04:54:06 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3G8s5S6028800 for ; Wed, 16 Apr 2003 10:54:14 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VD3QKK9>; Wed, 16 Apr 2003 10:52:48 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Formal notation, combined thread Date: Wed, 16 Apr 2003 10:52:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.wise.edt.ericsson.se id h3G8s5S6028800 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3G90d800308 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3G91O800355 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3G91j800387 Content-Transfer-Encoding: 8bit > > > As above, I can't see any reason to think of the > > > discriminator encodings as "special", or to treat them > > > differently in some way. The distinction between the > > > various types of encoding method that we made last year > > > was only intended to clarify how the notation handles all > > > of the different compression techniques needed by ROHC > > > profiles. From a technical perspective the notation has > > > never given special treatment to the discriminator > > > encodings, and I think that it would be confusing and > > > unnecessarily restrictive to do so. > > > > We obviously disagree here. I still believe it is important to > > make this distinction. > > I think that the distinction only makes sense for a very simple > header which is encoded in exactly two steps: first compress each > field using a choice of one or more field encodings, and then > compress the choices that were made by applying a discriminator > encoding. I rather believe it is important to make even more distinctions, as I agree with you that there are more "alternative" methods. > In particular, the distinction only works when a single (unique) > discriminator encoding is used to encode all of the discriminator > flags for the header. There are a number of cases where this isn't > the best solution - three that spring to mind are "list", "nbo" > and "format". Let's look at these three... > The "list" encoding method works much like list encoding in 3095 - > namely that it allows the various list items to turn up in any > order, and thus needs some discriminator bits to send this order > information to the decompressor. In theory it would be possible > to generate these discriminator bits using EPIC-lite: in practice > we would get too many packet formats due to the sheer number of > possible list orderings. The alternative is just to allow list > encoding to create its own discriminator bits, separately from > the ones generated by EPIC-lite. I agree with you, list encoding is rather special, it differs significantly from normal field-based encoding, and should be treated separately, but that has nothing to do with the usefulness of clarifying the difference between field encoding methods and discriminator encodings for the field methods. > The "nbo" encoding method offers implementers a choice of whether > to reverse the IP-ID before compressing it. We could encode the > resulting choice using EPIC-lite, but this would be inefficient > because we would always be sending the choice in every compressed > packet. Much better to store an "NBO flag" entry in the context > and to use this when deciding how the IP-ID has been encoded. This is a tricky one, as it changes the packet format interpretation, but if it is used, it is of course another special detail. Still, it does not affect the concepts of field encoding vs. discriminator encoding. > The "format" encoding method is designed to create multiple sets > of compressed packet formats. I really hope that when we define future profiles, we will be able to agree to avoid changing packet format interpretation "on the fly" within a profile, as it adds unnecessary profile complexity and/or unreliability. But even if we define multiple sets, I can not see why it should affect making a clear distinction between field encoding and discriminator encoding. > > All field encodings that can send compressed data in more than > > one way calls a discriminator function, but any function could > > be used, i.e. the notation for a profile can be written independent > > of the actual discriminator function that is later chosen. > > I outlined three cases where the above assumption fails - i.e. you > get a field encoding that can send compressed data in more than > one way, but where the resulting choice needs to be encoded using > a discriminator function other than EPIC-lite. > > Currently this poses no problem for the notation, because we invoke > EPIC-lite just like any other encoding method. Therefore we have > control over when to encode the discriminator flags using EPIC-lite, > and when a different encoding method would be more appropriate. > > We'd run into difficulty if we had to use a single (unspecified) > discriminator function for every case where compressed data can be > sent in more than one way. We'd be forced to use a single method to > encode every discriminator, even for the special cases where a > different method is more memory efficient or gets a better > compression ratio. I think you missed my point. The point was to have a notation where you would have an unspecified (generic) function, but that would not out rule having other functions for some special cases, like context based choices (that might be another general method). What I am after is that where you could choose to use OH (Ordinary Huffman), you could as well use HH (Hierarchical Huffman), or some other discriminator function with the same purpose and input. It is just about using a different algorithm, and the choice is in my mind a rather subjective one, made when one define a profile. I do not think a profile should use both OH, HH, and/or even more discriminator functions, but instead I would like to see a generic way of notating, and then the profile definition would state which discriminator function to actually use for those places where this ¨generic method is called in the notation. > This approach also makes the notation rather more simple than the > case where the discriminator flags are treated separately. Currently, > discriminator flags are treated exactly like any other data that > needs to be sent to the decompressor. In particular, we don't need > to worry about having new data structures to hold the discriminator > flags - they can be stored in the same data structures that we use > for the "ordinary" header fields (namely the labels and the context). > Moreover we don't have any special syntax for handling the > discriminator flags - we can compress them by applying our choice > of encoding method (e.g. EPIC-lite) just like we would apply LSB > encoding to compress a particular field. Complexity is not just about implementation, but also about structured concepts. Functionally, discriminators might just be created by using "just another encoding method", but we should make the difference clear conceptually, when we outline this new approach for describing a header compression process. Further, I strongly believe that there is a difference in how you choose discriminator encoding, compared to how you pick field encoding methods. The latter is (almost) purely based on field behavior, while the former choice is not as obvious, it is a more subjective profile designer choice. > > > We originally used the term "EPIC-lite" to mean > > > the entire notation-based solution, including > > > the notation itself and the complete library of > > > encoding methods. The algorithm for generating > > > the discriminator bits is actually nothing more than > > > ordinary Huffman encoding, so perhaps we could > > > just call it that instead? > > > > Ok, "Ordinary Huffman" (OH), and "Hierarchical Huffman" (HH) then? > > Sounds ok to me! Fine, let's try to use those then. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 16 11:04:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04956 for ; Wed, 16 Apr 2003 11:04:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GFD3e28886 for rohc-archive@odin.ietf.org; Wed, 16 Apr 2003 11:13:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GFD3828883 for ; Wed, 16 Apr 2003 11:13:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04932 for ; Wed, 16 Apr 2003 11:03:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195oUR-00023s-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 11:06:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195oUR-00023p-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 11:06:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GFCN828797; Wed, 16 Apr 2003 11:12:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GFBi828751 for ; Wed, 16 Apr 2003 11:11:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04870 for ; Wed, 16 Apr 2003 11:02:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195oTA-000232-00 for rohc@ietf.org; Wed, 16 Apr 2003 11:05:04 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 195oT9-00022q-00 for rohc@ietf.org; Wed, 16 Apr 2003 11:05:04 -0400 Received: from MCGREW-W2K.cisco.com (dhcp-128-107-163-135.cisco.com [128.107.163.135]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3GF4QgF001081; Wed, 16 Apr 2003 08:04:27 -0700 (PDT) Message-Id: <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 08:04:25 -0700 To: Stephen Kent From: David Mcgrew Cc: "Wang Haiguang" , , , , In-Reply-To: References: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [rohc] Re: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Steve, At 06:07 PM 4/15/2003 -0400, Stephen Kent wrote: >At 6:29 AM -0700 4/15/03, David Mcgrew wrote: >>Wang, >> >>length-hiding is an ESP option. If it is not used, then the traffic >>protected by ESP might be more susceptible to traffic analysis. For some >>applications, this is not a big deal. For example: no adversary is going >>to be surprised that an IP telephone sends 50 voice packets a second, nor >>would any adversary be fooled by the padding. To my mind, length-hiding >>is probably incompatible with header compression, though I don't see any >>security issues that would result from using them in conjunction. >> >>There are other security issues, though. The fact that the header >>compression is stateful (i.e., the decompression of a packet depends on >>the packets that have been received before) means that an adversary can >>force the receiver into decompressing incorrectly by >>re-ordering packets. The use of message authentication and replay >>protection doesn't stop this attack. ESP was designed to be tolerant of >>packet reorder, so using it with a stateful decompressor is problematic. >> >>There are two ways out of this bind: use a decompressor that won't cause >>any security failures due to reorder (which requires lots of careful >>analysis), or authenticate the message *before* it is compressed, rather >>than after it is compressed (which requires some encapsulation other than >>ESP). Jan Vilhuber and I have been working on both of these >>approaches. If there is interest, we could bring this work to the IETF, >>though I'm not sure that WG would be appropriate. >> >>David > >David, > >If we provide support for ROHC within ESP, then for outbound processing, >the security checks (matching against the traffic selectors) have to be >performed prior to compression. This is a natural order of processing, >since one must match against the selectors in order to select the right >SA, and then determine that the SA in question calls for compression. agreed. >At the receiver, similar checks must be performed on the received packet, >after decompression. But, these checks are performed after authentication >anyway, so this constraint does not impose an ordering requirement on >authentication vs. decompression. > >If we stick with the IPCOMP model, as Charlie proposed, then >authentication would occur first, then decompression, and I think that is >a reasonable ordering approach, which also addresses the concerns you cite >above. No, the IPCOMP model doesn't solve the problem, I fear that I've not been clear enough when I said 'authenticate before compression'. The use of a compression algorithm that maintains state between packets is a potential security problem because the reordering of packets can confuse the state machine in the decompressor. Since it's a design goal of ESP to tolerate packet reorder, there is nothing stopping an attacker from reordering packets in order to confuse the receiver. One way to thwart this attack is to apply the message authentication to the uncompressed data, rather than the compressed data. So the processing on the sender would be authenticate/compress/encrypt, while on the receiver it would be decrypt/decompress/authenticate. Since the receiver performs the authentication check after the decompression, this check catches decompression errors. This point is what I'd meant by 'auth before comp'. >The big question for IPsec is whether ROHC can it be considered an IPCOMP >instance and thus fit within the existing framework. The IPCOMP spec is only intended for stateless compression algorithms. It doesn't say if this is because of the security issue due to packet reorder or not; this might just be an assumption of the authors. Another point about IPCOMP is that it would be useful in exactly the same situations that header compression would be useful. It is probably desirable to allow the use of both mechanisms simultaneously. I am not sure if IPCOMP allows multiple compression methods, but I suspect that it does not. IPHC is also of interest as well, though I don't think that it raises any issues that ROHC doesn't. David >Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 16 13:02:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08435 for ; Wed, 16 Apr 2003 13:02:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GHBYr05782 for rohc-archive@odin.ietf.org; Wed, 16 Apr 2003 13:11:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHBY805779 for ; Wed, 16 Apr 2003 13:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08430 for ; Wed, 16 Apr 2003 13:02:22 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195qL5-0002ev-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 13:04:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195qL5-0002es-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 13:04:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHBH805762; Wed, 16 Apr 2003 13:11:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHAT805738 for ; Wed, 16 Apr 2003 13:10:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08407 for ; Wed, 16 Apr 2003 13:01:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195qK3-0002eQ-00 for rohc@ietf.org; Wed, 16 Apr 2003 13:03:47 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 195qK2-0002e0-00 for rohc@ietf.org; Wed, 16 Apr 2003 13:03:46 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3GH2O5w005829; Wed, 16 Apr 2003 13:02:24 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> References: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> Date: Wed, 16 Apr 2003 12:56:37 -0400 To: David Mcgrew From: Stephen Kent Cc: "Wang Haiguang" , , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [rohc] Re: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , David, The ESP processing order at the receiver is authenticate then decrypt, IF there are separate authentication and encryption algorithms employed, i.e., the common case today. The structure of the payload requires this, since the integrity check is applied to the ciphertext, not the plaintext, by the sender. That says that the transmitter processing order is: - map to SA (the outbound access control check) - compress if appropriate - encrypt - integrity check At the receiver the processing is defined as: - map to SA using SPI ( a demuxing operation, not a security check) - validate sequence number - integrity check - decrypt - decompress if appropriate - check against selectors (the inbound access control check) Sorry for any confusion re my previous response in not spelling out all the steps and why they are performed in the order indicated. Given this ordering of processing steps, it would seem that the main issue for a stateful compression algorithm like ROHC is to be smart about reacting to out of order arrival, a fact of life if it is to be used in the IPsec context. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 16 13:26:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09056 for ; Wed, 16 Apr 2003 13:26:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GHZKi06857 for rohc-archive@odin.ietf.org; Wed, 16 Apr 2003 13:35:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHZK806854 for ; Wed, 16 Apr 2003 13:35:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09050 for ; Wed, 16 Apr 2003 13:26:07 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195qi5-0002l2-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 13:28:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195qi4-0002kz-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 13:28:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHZ6806819; Wed, 16 Apr 2003 13:35:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHY0806750 for ; Wed, 16 Apr 2003 13:34:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09021 for ; Wed, 16 Apr 2003 13:24:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195qgn-0002kO-00 for rohc@ietf.org; Wed, 16 Apr 2003 13:27:17 -0400 Received: from fort-point-station.mit.edu ([18.7.7.76]) by ietf-mx with esmtp (Exim 4.12) id 195qgn-0002kL-00 for rohc@ietf.org; Wed, 16 Apr 2003 13:27:17 -0400 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3GHQJPk000675; Wed, 16 Apr 2003 13:27:06 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3GHM5o2015716; Wed, 16 Apr 2003 13:22:06 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3GHL6FJ027133; Wed, 16 Apr 2003 13:21:06 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id NAA08337; Wed, 16 Apr 2003 13:21:06 -0400 (EDT) To: David Mcgrew Cc: Stephen Kent , "Wang Haiguang" , , , , From: Derek Atkins References: <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> Date: 16 Apr 2003 13:21:06 -0400 In-Reply-To: <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [rohc] Re: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , David Mcgrew writes: > > The big question for IPsec is whether ROHC can it be considered an > > IPCOMP instance and thus fit within the existing framework. > > The IPCOMP spec is only intended for stateless compression algorithms. > It doesn't say if this is because of the security issue due to packet > reorder or not; this might just be an assumption of the authors. It depends on your definition of "stateless." I believe that you can have "state" (just like you require cryptographic "state" in order to process ESP or AH). However, the key is that there is no inter-packet state. That requirements stems from 2401 (IIRC), due to the IPsec architecture treating each packet individually. So, I don't see why IPCOMP should be any different than ESP or AH in terms of packet independence. If ROHC is truly dependent on packet ordering, then I think this is a bug in ROHC and needs to be addressed there. It certainly limits the types of links in which ROHC can be used. > Another point about IPCOMP is that it would be useful in exactly the > same situations that header compression would be useful. It is > probably desirable to allow the use of both mechanisms simultaneously. > I am not sure if IPCOMP allows multiple compression methods, but I > suspect that it does not. > > IPHC is also of interest as well, though I don't think that it raises > any issues that ROHC doesn't. > > David -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 16 16:08:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15129 for ; Wed, 16 Apr 2003 16:08:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GKHRd19631 for rohc-archive@odin.ietf.org; Wed, 16 Apr 2003 16:17:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GKHR819628 for ; Wed, 16 Apr 2003 16:17:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15100 for ; Wed, 16 Apr 2003 16:08:10 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195tEv-0003UC-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 16:10:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195tEu-0003U9-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 16:10:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GKHD819612; Wed, 16 Apr 2003 16:17:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GKGF819586 for ; Wed, 16 Apr 2003 16:16:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15079 for ; Wed, 16 Apr 2003 16:06:59 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195tDl-0003Tz-00 for rohc@ietf.org; Wed, 16 Apr 2003 16:09:29 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 195tDl-0003Tw-00 for rohc@ietf.org; Wed, 16 Apr 2003 16:09:29 -0400 Received: from MCGREW-W2K.cisco.com (dhcp-128-107-163-135.cisco.com [128.107.163.135]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3GK8imj009107; Wed, 16 Apr 2003 13:08:49 -0700 (PDT) Message-Id: <4.3.2.7.2.20030416121454.00b74328@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 13:08:40 -0700 To: Derek Atkins From: David Mcgrew Cc: Stephen Kent , "Wang Haiguang" , , , , In-Reply-To: References: <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030415060622.00b68ef8@mira-sjcm-1.cisco.com> <4.3.2.7.2.20030416070333.00b30688@mira-sjcm-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [rohc] Re: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Derek, At 01:21 PM 4/16/2003 -0400, Derek Atkins wrote: >David Mcgrew writes: > > > > The big question for IPsec is whether ROHC can it be considered an > > > IPCOMP instance and thus fit within the existing framework. > > > > The IPCOMP spec is only intended for stateless compression algorithms. > > It doesn't say if this is because of the security issue due to packet > > reorder or not; this might just be an assumption of the authors. > >It depends on your definition of "stateless." I believe that you can >have "state" (just like you require cryptographic "state" in order to >process ESP or AH). However, the key is that there is no inter-packet >state. That requirements stems from 2401 (IIRC), due to the IPsec >architecture treating each packet individually. That makes sense. For the record, the IPCOMP definition concerns inter-packet state, it says that "each IP datagram is compressed and decompressed by itself without any relation to other datagrams". >So, I don't see why IPCOMP should be any different than ESP or AH in >terms of packet independence. If ROHC is truly dependent on packet >ordering, then I think this is a bug in ROHC and needs to be addressed >there. It certainly limits the types of links in which ROHC can be >used. IPHC and ROHC were designed with links in mind, but there is now interest in adapting them for use at the internetwork layer. The AVT WG enhanced compressed RTP is one of these efforts. I think that there's similar interest in ROHC WG, though I am less familiar with that work and should let someone from that group comment. I don't think that it's a bug that the compression methods assume a reliable link, since compression is much easier when you can make that assumption. But certainly a more robust compression scheme would be more generally useful. thanks, David > > Another point about IPCOMP is that it would be useful in exactly the > > same situations that header compression would be useful. It is > > probably desirable to allow the use of both mechanisms simultaneously. > > I am not sure if IPCOMP allows multiple compression methods, but I > > suspect that it does not. > > > > IPHC is also of interest as well, though I don't think that it raises > > any issues that ROHC doesn't. > > > > David > >-derek > >-- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 16 16:16:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15349 for ; Wed, 16 Apr 2003 16:16:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GKPEr19992 for rohc-archive@odin.ietf.org; Wed, 16 Apr 2003 16:25:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GKPE819989 for ; Wed, 16 Apr 2003 16:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15344 for ; Wed, 16 Apr 2003 16:15:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195tMS-0003Vg-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 16:18:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195tMR-0003Vd-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 16:18:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GKP3819977; Wed, 16 Apr 2003 16:25:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GKP0819949 for ; Wed, 16 Apr 2003 16:25:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15320 for ; Wed, 16 Apr 2003 16:15:16 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195tLn-0003VL-00 for rohc@ietf.org; Wed, 16 Apr 2003 16:17:47 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 195tLm-0003VI-00 for rohc@ietf.org; Wed, 16 Apr 2003 16:17:46 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3GKHtRs002928; Wed, 16 Apr 2003 22:17:55 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 16 Apr 2003 22:17:56 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: Derek Atkins Cc: rohc@ietf.org, ipsec@lists.tislabs.com Date: Wed, 16 Apr 2003 22:17:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] RE: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > So, I don't see why IPCOMP should be any different than ESP or AH in > terms of packet independence. If ROHC is truly dependent on packet > ordering, then I think this is a bug in ROHC and needs to be addressed > there. It certainly limits the types of links in which ROHC can be > used. The RFC 3095 profiles are defined with an assumption on in-order delivery from compressor to decompressor, but modified profiles could easily be defined to tolerate packet misordering. The ROHC WG just has not yet addressed this issue, but we would appreciate input on the subject, especially motivations for us to look at it. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 16 21:38:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23565 for ; Wed, 16 Apr 2003 21:38:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3H1lgO09563 for rohc-archive@odin.ietf.org; Wed, 16 Apr 2003 21:47:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H1lg809560 for ; Wed, 16 Apr 2003 21:47:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23559 for ; Wed, 16 Apr 2003 21:38:18 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195yOO-0004fX-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 21:40:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195yOO-0004fU-00 for rohc-web-archive@ietf.org; Wed, 16 Apr 2003 21:40:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H1lQ809546; Wed, 16 Apr 2003 21:47:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H1kc809523 for ; Wed, 16 Apr 2003 21:46:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23553 for ; Wed, 16 Apr 2003 21:37:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195yNN-0004fK-00 for rohc@ietf.org; Wed, 16 Apr 2003 21:39:45 -0400 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by ietf-mx with esmtp (Exim 4.12) id 195yNN-0004fH-00 for rohc@ietf.org; Wed, 16 Apr 2003 21:39:45 -0400 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h3H1dsGt027342; Wed, 16 Apr 2003 21:39:54 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3H1drSt009855; Wed, 16 Apr 2003 21:39:53 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3H1dqFJ018641; Wed, 16 Apr 2003 21:39:52 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id VAA09254; Wed, 16 Apr 2003 21:39:52 -0400 (EDT) To: "Lars-Erik Jonsson (EAB)" Cc: rohc@ietf.org, ipsec@lists.tislabs.com From: Derek Atkins References: Date: 16 Apr 2003 21:39:52 -0400 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [rohc] Re: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Lars, "Lars-Erik Jonsson (EAB)" writes: > > So, I don't see why IPCOMP should be any different than ESP or AH in > > terms of packet independence. If ROHC is truly dependent on packet > > ordering, then I think this is a bug in ROHC and needs to be addressed > > there. It certainly limits the types of links in which ROHC can be > > used. > > The RFC 3095 profiles are defined with an assumption on in-order delivery > from compressor to decompressor, but modified profiles could easily be > defined to tolerate packet misordering. The ROHC WG just has not yet > addressed this issue, but we would appreciate input on the subject, > especially motivations for us to look at it. And this thread isn't sufficient motivation? Summerizing the thread, it would be useful to use ROHC to compress ESP tunnels, but that implies the potential for out-of-order reception. > BR > /L-E -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 17 04:41:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12563 for ; Thu, 17 Apr 2003 04:41:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3H8o2F15692 for rohc-archive@odin.ietf.org; Thu, 17 Apr 2003 04:50:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8o2815689 for ; Thu, 17 Apr 2003 04:50:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12552 for ; Thu, 17 Apr 2003 04:40:29 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1964yx-00068k-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 04:42:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1964yx-00068g-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 04:42:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8nO815630; Thu, 17 Apr 2003 04:49:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GKko821764 for ; Wed, 16 Apr 2003 16:46:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15941 for ; Wed, 16 Apr 2003 16:37:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195thL-0003aR-00 for rohc@ietf.org; Wed, 16 Apr 2003 16:40:03 -0400 Received: from spsystems.net ([209.47.149.227]) by ietf-mx with esmtp (Exim 4.12) id 195thL-0003aO-00 for rohc@ietf.org; Wed, 16 Apr 2003 16:40:03 -0400 Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.9/8.12.9) with ESMTP id h3GKddCh018272; Wed, 16 Apr 2003 16:39:39 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.9/8.12.9/Submit) id h3GKddpd018271; Wed, 16 Apr 2003 16:39:39 -0400 (EDT) Date: Wed, 16 Apr 2003 16:39:38 -0400 (EDT) From: Henry Spencer To: IP Security List cc: rohc@ietf.org In-Reply-To: <4.3.2.7.2.20030416121454.00b74328@mira-sjcm-1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] Re: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On Wed, 16 Apr 2003, David Mcgrew wrote: > >...[IPComp] the key is that there is no inter-packet state... > > That makes sense. For the record, the IPCOMP definition concerns > inter-packet state, it says that "each IP datagram is compressed and > decompressed by itself without any relation to other datagrams". And in fact, a careful reading of the specification tells you that this is a bit mis-stated: compression implementations are not just permitted but encouraged to keep inter-packet state, e.g. to decide whether it is worth trying to compress the next packet. It's *decompression*, and only decompression, which must not keep inter-packet state. (And that is both necessary and sufficient to make IPComp robust against loss or reordering of packets.) Henry Spencer henry@spsystems.net _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 17 04:41:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12577 for ; Thu, 17 Apr 2003 04:41:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3H8o4p15717 for rohc-archive@odin.ietf.org; Thu, 17 Apr 2003 04:50:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8o4815713 for ; Thu, 17 Apr 2003 04:50:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12556 for ; Thu, 17 Apr 2003 04:40:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1964z0-00068q-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 04:43:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1964yz-00068n-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 04:43:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8nP815646; Thu, 17 Apr 2003 04:49:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GMwq831464 for ; Wed, 16 Apr 2003 18:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20513 for ; Wed, 16 Apr 2003 18:49:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195vl4-00049L-00 for rohc@ietf.org; Wed, 16 Apr 2003 18:52:03 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 195vl4-00049H-00 for rohc@ietf.org; Wed, 16 Apr 2003 18:52:02 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3GMpemi022274; Wed, 16 Apr 2003 15:51:40 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADH46942; Wed, 16 Apr 2003 15:51:39 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA02211; Wed, 16 Apr 2003 15:51:39 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16029.56955.166274.95231@thomasm-u1.cisco.com> Date: Wed, 16 Apr 2003 15:51:39 -0700 (PDT) To: Henry Spencer Cc: IP Security List , rohc@ietf.org In-Reply-To: References: <4.3.2.7.2.20030416121454.00b74328@mira-sjcm-1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [rohc] Re: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henry Spencer writes: > On Wed, 16 Apr 2003, David Mcgrew wrote: > > >...[IPComp] the key is that there is no inter-packet state... > > > > That makes sense. For the record, the IPCOMP definition concerns > > inter-packet state, it says that "each IP datagram is compressed and > > decompressed by itself without any relation to other datagrams". > > And in fact, a careful reading of the specification tells you that this is > a bit mis-stated: compression implementations are not just permitted but > encouraged to keep inter-packet state, e.g. to decide whether it is worth > trying to compress the next packet. It's *decompression*, and only > decompression, which must not keep inter-packet state. (And that is both > necessary and sufficient to make IPComp robust against loss or reordering > of packets.) Well, I dunno what difference it makes because ROHC is pretty stateful on both sides... Mike _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 17 05:02:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13014 for ; Thu, 17 Apr 2003 05:02:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3H9Bhc17465 for rohc-archive@odin.ietf.org; Thu, 17 Apr 2003 05:11:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H9Bh817462 for ; Thu, 17 Apr 2003 05:11:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13010 for ; Thu, 17 Apr 2003 05:02:10 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1965Jw-0006Dc-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 05:04:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1965Jv-0006DZ-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 05:04:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H9BL817449; Thu, 17 Apr 2003 05:11:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H9A0817410 for ; Thu, 17 Apr 2003 05:10:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12997 for ; Thu, 17 Apr 2003 05:00:27 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1965IH-0006DV-00 for rohc@ietf.org; Thu, 17 Apr 2003 05:02:57 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 1965IH-0006DS-00 for rohc@ietf.org; Thu, 17 Apr 2003 05:02:57 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3H933I4019101; Thu, 17 Apr 2003 11:03:07 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 17 Apr 2003 11:02:25 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: Derek Atkins Cc: rohc@ietf.org, ipsec@lists.tislabs.com Date: Thu, 17 Apr 2003 10:56:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] RE: (in)security of ESP with header compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > The ROHC WG just has not yet addressed this issue, but we would > > appreciate input on the subject, especially motivations for us > > to look at it. > > And this thread isn't sufficient motivation? Summerizing the thread, > it would be useful to use ROHC to compress ESP tunnels, but that > implies the potential for out-of-order reception. Neither "it can be done" nor "I want it to be done" are really actual arguments for doing anything. However, there are usually real arguments behind the latter, and those would be useful to hear. Further, we need people to look at it to figure out what should be done to address the problem identified (there might be several potential ways to address an issue), and then we need people to do the actual work of writing documents. I personally think it will be useful to have "ROHC over tunnels" clarified/defined, but as a WG chair I need some concrete needs, as well as working resources (people interested in contributing). Drafts are welcome! BR /Lars-Erik _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 17 07:38:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16445 for ; Thu, 17 Apr 2003 07:38:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HBljB27531 for rohc-archive@odin.ietf.org; Thu, 17 Apr 2003 07:47:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBlj827528 for ; Thu, 17 Apr 2003 07:47:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16427 for ; Thu, 17 Apr 2003 07:38:10 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1967kt-0006lz-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 07:40:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1967kt-0006lw-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 07:40:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBlQ827511; Thu, 17 Apr 2003 07:47:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBa0826196 for ; Thu, 17 Apr 2003 07:36:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15844; Thu, 17 Apr 2003 07:26:25 -0400 (EDT) Message-Id: <200304171126.HAA15844@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 17 Apr 2003 07:26:25 -0400 Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Interoperability of RFC 3095 Author(s) : L. Jonsson Filename : draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt Pages : 30 Date : 2003-4-16 RFC 3095 defines a Proposed Standard protocol for RObust Header Compression (ROHC). In order to move the standard further to Draft Standard status, it is required to demonstrate interoperability for all functionality defined by the RFC. This document outlines those features to be tested, and also the test status for each feature, based on reports from interoperability tests or other proof of interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16135711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16135711.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 17 14:29:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01219 for ; Thu, 17 Apr 2003 14:29:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HIcmq29443 for rohc-archive@odin.ietf.org; Thu, 17 Apr 2003 14:38:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HIcm829440 for ; Thu, 17 Apr 2003 14:38:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01212 for ; Thu, 17 Apr 2003 14:29:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196EAV-0001mS-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 14:31:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196EAV-0001mP-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 14:31:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HIcM829429; Thu, 17 Apr 2003 14:38:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HIbM829105 for ; Thu, 17 Apr 2003 14:37:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01162 for ; Thu, 17 Apr 2003 14:27:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196E98-0001mA-00 for rohc@ietf.org; Thu, 17 Apr 2003 14:30:06 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 196E97-0001m7-00 for rohc@ietf.org; Thu, 17 Apr 2003 14:30:05 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3HIUIRs014933 for ; Thu, 17 Apr 2003 20:30:18 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 17 Apr 2003 20:30:19 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] I-D ACTION:draft-ietf-rohc-rtp-rfc3095-interoperabilit y-02.txt Date: Thu, 17 Apr 2003 20:30:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , ROHCers, This updated draft includes status from all interoperability reports I have received, excluding only those that have not been confirmed (i.e. reports for interoperability between X and Y have been included only if both X and Y have independently reported the same status). Missing reports are of course still welcome, but now is time to start planning for a final interop where all missing tests should be completed. If you have an implementation and believe you are ready to test all pieces not yet tested, please let me know. Cheers, /L-E > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: den 17 april 2003 13:26 > Cc: rohc@ietf.org > Subject: [rohc] I-D > ACTION:draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Robust Header Compression > Working Group of the IETF. > > Title : Interoperability of RFC 3095 > Author(s) : L. Jonsson > Filename : > draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt > Pages : 30 > Date : 2003-4-16 > > RFC 3095 defines a Proposed Standard protocol for RObust Header > Compression (ROHC). In order to move the standard further to Draft > Standard status, it is required to demonstrate interoperability for > all functionality defined by the RFC. This document outlines those > features to be tested, and also the test status for each feature, > based on reports from interoperability tests or other proof of > interoperability. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-rfc309 > 5-interoperability-02.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 17 18:02:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10127 for ; Thu, 17 Apr 2003 18:02:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HMBc313699 for rohc-archive@odin.ietf.org; Thu, 17 Apr 2003 18:11:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMBc813696 for ; Thu, 17 Apr 2003 18:11:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10098 for ; Thu, 17 Apr 2003 18:01:49 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HUP-00036i-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 18:04:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196HUO-00036f-00 for rohc-web-archive@ietf.org; Thu, 17 Apr 2003 18:04:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMBG813664; Thu, 17 Apr 2003 18:11:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMAH813618 for ; Thu, 17 Apr 2003 18:10:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10035 for ; Thu, 17 Apr 2003 18:00:29 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HT6-00035g-00 for rohc@ietf.org; Thu, 17 Apr 2003 18:02:56 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx with smtp (Exim 4.12) id 196HT6-00035R-00 for rohc@ietf.org; Thu, 17 Apr 2003 18:02:56 -0400 Received: (qmail 1794 invoked by uid 65534); 17 Apr 2003 22:02:38 -0000 Received: from adsl-27-141.barak.net.il (HELO yaronhome) (62.90.27.141) by mail.gmx.net (mp019-rz3) with SMTP; 18 Apr 2003 00:02:38 +0200 From: "Yaron Sheffer" To: "Lars-Erik Jonsson \(EAB\)" , "Derek Atkins" Cc: , Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 00:59:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ESP includes a 32-bit sequence number. It is mandatory for the sender to set and increment it correctly, but optional for the receiver to verify it. It is there to prevent malicious replay of messages. In the case of ROHC over ESP, if the receiver's policy is to delete packets with an out-of-order ESP sequence number (possibly using a small reorder buffer), then packets reaching the decompressor are always in order. The channel is not reliable of course, since entire packets may be deleted. All in all, this channel becomes analogous to your plain vanilla PPP. Applicability: in general, IP (and ESP) packets may be drastically reordered, with packets coming in many seconds out of order. For Internet telephony, those packets are useless and can be discarded on arrival. Under these assumptions, I don't believe any change to the operating assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC over tunnels" but only "ROHC over ESP", but it's still an interesting case. Thanks, Yaron -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of Lars-Erik Jonsson (EAB) Sent: Wednesday, April 16, 2003 10:18 PM To: Derek Atkins Cc: rohc@ietf.org; ipsec@lists.tislabs.com Subject: [rohc] RE: (in)security of ESP with header compression > So, I don't see why IPCOMP should be any different than ESP or AH in > terms of packet independence. If ROHC is truly dependent on packet > ordering, then I think this is a bug in ROHC and needs to be addressed > there. It certainly limits the types of links in which ROHC can be > used. The RFC 3095 profiles are defined with an assumption on in-order delivery from compressor to decompressor, but modified profiles could easily be defined to tolerate packet misordering. The ROHC WG just has not yet addressed this issue, but we would appreciate input on the subject, especially motivations for us to look at it. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 03:33:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05111 for ; Fri, 18 Apr 2003 03:33:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I7hCi27038 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 03:43:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I7hC827035 for ; Fri, 18 Apr 2003 03:43:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05107 for ; Fri, 18 Apr 2003 03:33:12 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196QPK-0005ki-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 03:35:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196QPK-0005kf-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 03:35:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I7gX827012; Fri, 18 Apr 2003 03:42:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I7fr826972 for ; Fri, 18 Apr 2003 03:41:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05062 for ; Fri, 18 Apr 2003 03:31:54 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196QO4-0005kL-00 for rohc@ietf.org; Fri, 18 Apr 2003 03:34:20 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 196QO3-0005kI-00 for rohc@ietf.org; Fri, 18 Apr 2003 03:34:19 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3I7YWI3000706; Fri, 18 Apr 2003 09:34:32 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 18 Apr 2003 09:34:18 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: Yaron Sheffer Cc: rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 09:34:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Yaron, > ESP includes a 32-bit sequence number. It is mandatory for > the sender to set and increment it correctly, but optional > for the receiver to verify it. It is there to prevent > malicious replay of messages. > > Under these assumptions, I don't believe any change to the > operating assumptions of ROHC, or a new ROHC profile, is > needed. This is not "ROHC over tunnels" but only "ROHC over > ESP", but it's still an interesting case. This is the approach we have previously discussed in ROHC (just informally), and most tunneling protocols seem to have a similar sequence number. The solution would then just be a modified decompressor, making use of the tunnel sequence number. But still, someone should look more carefully at this, and write something. Rgds, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 04:06:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05757 for ; Fri, 18 Apr 2003 04:06:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I8FYZ29199 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 04:15:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I8FY829196 for ; Fri, 18 Apr 2003 04:15:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05742 for ; Fri, 18 Apr 2003 04:05:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Que-0005sL-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 04:08:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196Qud-0005sI-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 04:07:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I8C8829126; Fri, 18 Apr 2003 04:12:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I8BD829099 for ; Fri, 18 Apr 2003 04:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05700 for ; Fri, 18 Apr 2003 04:01:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196QqR-0005rp-00 for rohc@ietf.org; Fri, 18 Apr 2003 04:03:39 -0400 Received: from uofa-dsl-nen-23.dakotacom.net ([150.135.176.23] helo=sune.degermark.net) by ietf-mx with esmtp (Exim 4.12) id 196QqQ-0005rm-00 for rohc@ietf.org; Fri, 18 Apr 2003 04:03:39 -0400 Received: from gaston (gaston.DEGERMARK.NET [192.168.1.8]) by sune.degermark.net (8.12.6/8.12.6) with SMTP id h3I83iAI010041; Fri, 18 Apr 2003 01:03:44 -0700 (MST) (envelope-from micke@cs.arizona.edu) Message-ID: <00ac01c30581$a326b990$0801a8c0@gaston> From: "Mikael Degermark" To: "Lars-Erik Jonsson \(EAB\)" , "Yaron Sheffer" Cc: , References: Subject: Re: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 01:08:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I believe that the compressor also needs to be involved, as reordering can only be detected by the decompressor if the compressor ensures that the sequence numbers it sends out are ordered. Is there still an equivalent to the IPv4 protocol or IPv6 Next Header field in the new ESP header? Micke ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "Yaron Sheffer" Cc: ; Sent: Friday, April 18, 2003 12:34 AM Subject: RE: [rohc] RE: (in)security of ESP with header compression > Yaron, > > > ESP includes a 32-bit sequence number. It is mandatory for > > the sender to set and increment it correctly, but optional > > for the receiver to verify it. It is there to prevent > > malicious replay of messages. > > > > Under these assumptions, I don't believe any change to the > > operating assumptions of ROHC, or a new ROHC profile, is > > needed. This is not "ROHC over tunnels" but only "ROHC over > > ESP", but it's still an interesting case. > > This is the approach we have previously discussed in ROHC > (just informally), and most tunneling protocols seem to have > a similar sequence number. The solution would then just be > a modified decompressor, making use of the tunnel sequence > number. > > But still, someone should look more carefully at this, and > write something. > > Rgds, > /L-E > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 04:29:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06016 for ; Fri, 18 Apr 2003 04:29:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I8cgw30702 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 04:38:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I8cg830699 for ; Fri, 18 Apr 2003 04:38:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06013 for ; Fri, 18 Apr 2003 04:28:41 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196RH1-0005wK-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 04:31:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196RH1-0005wH-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 04:31:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I8ZB829776; Fri, 18 Apr 2003 04:35:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I8Yk829742 for ; Fri, 18 Apr 2003 04:34:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05958 for ; Fri, 18 Apr 2003 04:24:45 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196RDD-0005vT-00 for rohc@ietf.org; Fri, 18 Apr 2003 04:27:11 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 196RDD-0005vQ-00 for rohc@ietf.org; Fri, 18 Apr 2003 04:27:11 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3I8RMRs026617; Fri, 18 Apr 2003 10:27:22 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 18 Apr 2003 10:26:46 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: Mikael Degermark , Yaron Sheffer Cc: rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 10:26:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Yes, I just assumed that such a "tunnel sequence number" would be incrementally set. Otherwise it would not be useable for detecting out-of-order packets. /L-E > I believe that the compressor also needs to be involved, > as reordering can only be detected by the decompressor > if the compressor ensures that the sequence numbers it > sends out are ordered. > > Is there still an equivalent to the IPv4 protocol or IPv6 > Next Header field in the new ESP header? > > > > This is the approach we have previously discussed in ROHC > > (just informally), and most tunneling protocols seem to have > > a similar sequence number. The solution would then just be > > a modified decompressor, making use of the tunnel sequence > > number. > > > > But still, someone should look more carefully at this, and > > write something. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 08:46:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11911 for ; Fri, 18 Apr 2003 08:46:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ICuEB13610 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 08:56:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICuE813607 for ; Fri, 18 Apr 2003 08:56:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11890 for ; Fri, 18 Apr 2003 08:46:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196VIA-0007HJ-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 08:48:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196VIA-0007HF-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 08:48:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICtf813574; Fri, 18 Apr 2003 08:55:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICsM813451 for ; Fri, 18 Apr 2003 08:54:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11830 for ; Fri, 18 Apr 2003 08:44:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196VGM-0007Ge-00 for rohc@ietf.org; Fri, 18 Apr 2003 08:46:42 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196VGM-0007G8-00 for rohc@ietf.org; Fri, 18 Apr 2003 08:46:42 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3ICk560008903; Fri, 18 Apr 2003 08:46:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 18 Apr 2003 08:41:50 -0400 To: "Yaron Sheffer" From: Stephen Kent Subject: RE: [rohc] RE: (in)security of ESP with header compression Cc: "Lars-Erik Jonsson \(EAB\)" , "Derek Atkins" , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , At 12:59 AM +0200 4/18/03, Yaron Sheffer wrote: >ESP includes a 32-bit sequence number. It is mandatory for the sender to set >and increment it correctly, but optional for the receiver to verify it. It >is there to prevent malicious replay of messages. > >In the case of ROHC over ESP, if the receiver's policy is to delete packets >with an out-of-order ESP sequence number (possibly using a small reorder >buffer), then packets reaching the decompressor are always in order. The >channel is not reliable of course, since entire packets may be deleted. All >in all, this channel becomes analogous to your plain vanilla PPP. > >Applicability: in general, IP (and ESP) packets may be drastically >reordered, with packets coming in many seconds out of order. For Internet >telephony, those packets are useless and can be discarded on arrival. > >Under these assumptions, I don't believe any change to the operating >assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC >over tunnels" but only "ROHC over ESP", but it's still an interesting case. > >Thanks, > Yaron I may not have understood your argument, but any solution we would adopt for IPsec use of ROHC must be general, i.e., it cannot depend on specific receiver constraints re anti-replay window parameters. Also, your message suggests a possible misunderstanding re IPsec and anti-replay: I know of no IPsec implementation that reorders packets upon arrival and doing so is certainly outside the scope of what the RFCs call for. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 11:29:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17175 for ; Fri, 18 Apr 2003 11:29:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IFclV24204 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 11:38:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IFcl824201 for ; Fri, 18 Apr 2003 11:38:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17154 for ; Fri, 18 Apr 2003 11:28:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196XpP-0000CY-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 11:31:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196XpP-0000CV-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 11:31:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IFcK824191; Fri, 18 Apr 2003 11:38:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IFb6823382 for ; Fri, 18 Apr 2003 11:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17116 for ; Fri, 18 Apr 2003 11:26:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Xnn-0000C1-00 for rohc@ietf.org; Fri, 18 Apr 2003 11:29:23 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 196Xnm-0000By-00 for rohc@ietf.org; Fri, 18 Apr 2003 11:29:23 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 9B768872E8; Sat, 19 Apr 2003 00:58:58 +0930 (CST) Date: Sat, 19 Apr 2003 00:58:58 +0930 From: Alan Kennington To: rohc@ietf.org Cc: Alan Kennington Message-ID: <20030419005858.A12400@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] possible ambiguity in IR/IR-DYN CRC overage Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Referring to: "ROHC Implementer's Guide" http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-03.txt part 4.1, page 5, ============================================================== 4.1. Padding octet in CRC According to Section 5.9.1, in case of IR and IR-DYN packets the CRC "is calculated over the entire IR or IR-DYN packet, excluding Payload and including CID or Add-CID octet". Padding isn't meant to be meaningful part of a packet and not included in CRC calculation. As a result, CRC doesn't cover the Add-CID octet for CID 0, either. ============================================================== This seems to me to leave open an ambiguity. Suppose I receive a packet which looks like this on a small-CID channel: - one or more feedback messages - Add-CID, CID = 0 - IR packet type octet 11111100 - profile byte - CRC - payload Now I have a difficulty. Is the Add-CID octet a padding octet? Surely not, because RFC 3095, page 42 has a diagram which says that padding bytes always come before the feedback. If the Add-CID octet legal? Well, maybe not. But what do I do if I get Add-CID after feedback? Is this an illegal packet which must be discarded? Or is it a legal Add-CID which is included in the CRC? Or is it a legal padding octet (or Add-CID) which is _not_ in the CRC? Cheers, Alan Kennington. Adelaide, South Australia. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 14:50:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22314 for ; Fri, 18 Apr 2003 14:50:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IJ0RP05279 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 15:00:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IJ0R805276 for ; Fri, 18 Apr 2003 15:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22302 for ; Fri, 18 Apr 2003 14:50:14 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196ayV-0000x0-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 14:52:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196ayV-0000wx-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 14:52:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IJ08805257; Fri, 18 Apr 2003 15:00:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IIuf805121 for ; Fri, 18 Apr 2003 14:56:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22151 for ; Fri, 18 Apr 2003 14:46:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196aus-0000ts-00 for rohc@ietf.org; Fri, 18 Apr 2003 14:48:54 -0400 Received: from mail.gmx.net ([213.165.65.60]) by ietf-mx with smtp (Exim 4.12) id 196aur-0000td-00 for rohc@ietf.org; Fri, 18 Apr 2003 14:48:53 -0400 Received: (qmail 9759 invoked by uid 65534); 18 Apr 2003 18:48:36 -0000 Received: from adsl-27-141.barak.net.il (HELO yaronhome) (62.90.27.141) by mail.gmx.net (mp011-rz3) with SMTP; 18 Apr 2003 20:48:36 +0200 From: "Yaron Sheffer" To: "Stephen Kent" Cc: "Lars-Erik Jonsson \(EAB\)" , "Derek Atkins" , , Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 21:48:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Steve, I see a trade-off here between tweaking ROHC to deal with reordering channels (it may be easy or hard, I don't know) and tweaking the ESP *implementation* to undo such reordering. I accept that the RFC doesn't mandate or even suggest it, and from an architectural perspective it's not clean. But it's a minor change to the implementation of sequence-number handling in ESP, which can be spelled out specifically in a "Header compression over ESP" draft. Otherwise you need to work very hard to implement ROHC (or CRTP, or ECRTP) securely over ESP, going through contortions like the proposed authentication-before-compression (sorry David). Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a IPCOMP_SUPPORTED notification, which can be extended (and renamed to COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that ROHC should be an IPComp profile, only that it's negotiated in an analogous manner. IPComp makes different assumptions regarding traffic (packet lengths) compared to ROHC, and therefore probably doesn't do the job here. But this is for the ROHC people to judge. I am being somewhat simplistic, you may need to negotiate some basic compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE, LZS} values of this field. Speaking about the IPSec architecture, it's a pity that compression parameters remain an integral part of IKE v2, rather than add-ons. Best regards, Yaron -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, April 18, 2003 2:42 PM To: Yaron Sheffer Cc: Lars-Erik Jonsson (EAB); Derek Atkins; rohc@ietf.org; ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression At 12:59 AM +0200 4/18/03, Yaron Sheffer wrote: >ESP includes a 32-bit sequence number. It is mandatory for the sender to set >and increment it correctly, but optional for the receiver to verify it. It >is there to prevent malicious replay of messages. > >In the case of ROHC over ESP, if the receiver's policy is to delete packets >with an out-of-order ESP sequence number (possibly using a small reorder >buffer), then packets reaching the decompressor are always in order. The >channel is not reliable of course, since entire packets may be deleted. All >in all, this channel becomes analogous to your plain vanilla PPP. > >Applicability: in general, IP (and ESP) packets may be drastically >reordered, with packets coming in many seconds out of order. For Internet >telephony, those packets are useless and can be discarded on arrival. > >Under these assumptions, I don't believe any change to the operating >assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC >over tunnels" but only "ROHC over ESP", but it's still an interesting case. > >Thanks, > Yaron I may not have understood your argument, but any solution we would adopt for IPsec use of ROHC must be general, i.e., it cannot depend on specific receiver constraints re anti-replay window parameters. Also, your message suggests a possible misunderstanding re IPsec and anti-replay: I know of no IPsec implementation that reorders packets upon arrival and doing so is certainly outside the scope of what the RFCs call for. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 15:14:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23963 for ; Fri, 18 Apr 2003 15:14:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IJOVw06985 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 15:24:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IJOV806982 for ; Fri, 18 Apr 2003 15:24:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23916 for ; Fri, 18 Apr 2003 15:14:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196bLn-000143-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 15:16:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196bLm-000140-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 15:16:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IJO6806967; Fri, 18 Apr 2003 15:24:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IJNE806944 for ; Fri, 18 Apr 2003 15:23:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23803 for ; Fri, 18 Apr 2003 15:13:01 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196bKY-00013n-00 for rohc@ietf.org; Fri, 18 Apr 2003 15:15:26 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196bKX-00013d-00 for rohc@ietf.org; Fri, 18 Apr 2003 15:15:25 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3IJEw5w003869; Fri, 18 Apr 2003 15:14:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 18 Apr 2003 15:09:53 -0400 To: "Yaron Sheffer" From: Stephen Kent Subject: RE: [rohc] RE: (in)security of ESP with header compression Cc: "Lars-Erik Jonsson \(EAB\)" , "Derek Atkins" , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , At 9:48 PM +0200 4/18/03, Yaron Sheffer wrote: >Hi Steve, > >I see a trade-off here between tweaking ROHC to deal with reordering >channels (it may be easy or hard, I don't know) and tweaking the ESP >*implementation* to undo such reordering. I accept that the RFC doesn't >mandate or even suggest it, and from an architectural perspective it's not >clean. But it's a minor change to the implementation of sequence-number >handling in ESP, which can be spelled out specifically in a "Header >compression over ESP" draft. Otherwise you need to work very hard to >implement ROHC (or CRTP, or ECRTP) securely over ESP, going through >contortions like the proposed authentication-before-compression (sorry >David). Well, ESP has been around for a while; RFC 2406 was published in November of 1998. I don't think we can reasonably ask implementors to change their implementations to accommodate ROHC. Also, as you note, it is not architecturally attractive, since IP would not reorder the traffic and IPsec tries to minimize the differences between what the IP interface does and what IPsec does. We had to impose the notion of a receive window as a tradeoff in this regard, to make anti-replay feasible yet not too hard for an IPsec implementation. Also, as we go to higher speeds, asking an IPsec implementation to buffer inbound traffic places a significant burden on the implementation, since this would have to be done in hardware that is trying to operate at line rates. >Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a >IPCOMP_SUPPORTED notification, which can be extended (and renamed to >COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that >ROHC should be an IPComp profile, only that it's negotiated in an analogous >manner. IPComp makes different assumptions regarding traffic (packet >lengths) compared to ROHC, and therefore probably doesn't do the job here. >But this is for the ROHC people to judge. I understand. >I am being somewhat simplistic, you may need to negotiate some basic >compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE, >LZS} values of this field. > >Speaking about the IPSec architecture, it's a pity that compression >parameters remain an integral part of IKE v2, rather than add-ons. IKE is really a security association management protocol and if compression is part of the SA processing, then we have to negotiate its use and parameters when we establish an SA. Key management is the easy part :-). All the complexity is in the SA management part. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 17:25:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27362 for ; Fri, 18 Apr 2003 17:25:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ILYk414912 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 17:34:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILYk814909 for ; Fri, 18 Apr 2003 17:34:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27297 for ; Fri, 18 Apr 2003 17:24:29 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196dNn-0001X1-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:26:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196dNn-0001Wx-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:26:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILYP814870; Fri, 18 Apr 2003 17:34:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I0HE821996 for ; Thu, 17 Apr 2003 20:17:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14745 for ; Thu, 17 Apr 2003 20:07:24 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196JRu-0003jD-00 for rohc@ietf.org; Thu, 17 Apr 2003 20:09:51 -0400 Received: from cygnus.equallogic.com ([65.170.102.10]) by ietf-mx with smtp (Exim 4.12) id 196JRu-0003j8-00 for rohc@ietf.org; Thu, 17 Apr 2003 20:09:50 -0400 Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h3I09Tt26270 for ; Thu, 17 Apr 2003 20:09:29 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h3I09Sr26255; Thu, 17 Apr 2003 20:09:28 -0400 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id h3I09Ki07522; Thu, 17 Apr 2003 20:09:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16031.16905.78000.172133@gargle.gargle.HOWL> Date: Thu, 17 Apr 2003 20:08:41 -0400 From: Paul Koning To: yaronf@gmx.net Cc: Lars-Erik.Jonsson@epl.ericsson.se, derek@ihtfp.com, rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Yaron" == Yaron Sheffer writes: Yaron> ESP includes a 32-bit sequence number. It is mandatory for the Yaron> sender to set and increment it correctly, but optional for the Yaron> receiver to verify it. It is there to prevent malicious replay Yaron> of messages. Yaron> In the case of ROHC over ESP, if the receiver's policy is to Yaron> delete packets with an out-of-order ESP sequence number Yaron> (possibly using a small reorder buffer), then packets reaching Yaron> the decompressor are always in order. The channel is not Yaron> reliable of course, since entire packets may be deleted. All Yaron> in all, this channel becomes analogous to your plain vanilla Yaron> PPP. Yaron> Applicability: in general, IP (and ESP) packets may be Yaron> drastically reordered, with packets coming in many seconds out Yaron> of order. For Internet telephony, those packets are useless Yaron> and can be discarded on arrival. Yaron> Under these assumptions, I don't believe any change to the Yaron> operating assumptions of ROHC, or a new ROHC profile, is Yaron> needed. This is not "ROHC over tunnels" but only "ROHC over Yaron> ESP", but it's still an interesting case. Maybe. But your assumption is questionable. One could build ESP like that, but I've never heard of anyone doing it. The typical implementation will accept packets that are out of order WITHOUT putting them back in order, provided they are not out of order by more than a "window" amount. A typical window is 64, because that's the max size of an easy to do bitmap, but it's not significantly harder to make it bigger, and the cost is only a a bit per unit of distance. So your assumption that ESP (with integrity) is a lossy ordered channel is unlikely to be valid. paul _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 17:25:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27381 for ; Fri, 18 Apr 2003 17:25:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ILYpx14928 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 17:34:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILYp814925 for ; Fri, 18 Apr 2003 17:34:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27301 for ; Fri, 18 Apr 2003 17:24:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196dNs-0001X8-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196dNs-0001X5-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:27:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILYV814887; Fri, 18 Apr 2003 17:34:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IKrb812218 for ; Fri, 18 Apr 2003 16:53:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26355 for ; Fri, 18 Apr 2003 16:43:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196cjy-0001NH-00 for rohc@ietf.org; Fri, 18 Apr 2003 16:45:46 -0400 Received: from cygnus.equallogic.com ([65.170.102.10]) by ietf-mx with smtp (Exim 4.12) id 196cjy-0001NA-00 for rohc@ietf.org; Fri, 18 Apr 2003 16:45:46 -0400 Received: from cygnus.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h3IKjVt07276 for ; Fri, 18 Apr 2003 16:45:31 -0400 Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id h3IKjUr07258; Fri, 18 Apr 2003 16:45:30 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id h3IKjTG22466; Fri, 18 Apr 2003 16:45:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16032.25540.468724.228395@pkoning.dev.equallogic.com> Date: Fri, 18 Apr 2003 16:44:52 -0400 From: Paul Koning To: yaronf@gmx.net Cc: kent@bbn.com, Lars-Erik.Jonsson@epl.ericsson.se, derek@ihtfp.com, rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Yaron" == Yaron Sheffer writes: Yaron> Hi Steve, I see a trade-off here between tweaking ROHC to deal Yaron> with reordering channels (it may be easy or hard, I don't Yaron> know) and tweaking the ESP *implementation* to undo such Yaron> reordering. I accept that the RFC doesn't mandate or even Yaron> suggest it, and from an architectural perspective it's not Yaron> clean. But it's a minor change to the implementation of Yaron> sequence-number handling in ESP... Nonsense. It's a very major change in the implementation of ESP. ESP processes IP packets one at a time. It does not care whether they are being reordered; it does not, repeat NOT, put them in any order different from the order in which they arrived. To do what you suggest would be a large redesign, which would also completely ruin performance. ("Fragmentation considered Harmful" by Jeff Mogul explains this nicely, for a different case where the same considerations are valid.) Note also that there are a bunch of ESP implementations done in silicon. For those, what you propose is even more unreasonable than it would be for a software implementation. But I don't think any implementer of either kind of implementation would consider your proposal. paul _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 17:31:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27581 for ; Fri, 18 Apr 2003 17:31:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ILfNF16008 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 17:41:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILfN816005 for ; Fri, 18 Apr 2003 17:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27535 for ; Fri, 18 Apr 2003 17:31:05 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196dUB-0001Ym-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:33:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196dUB-0001Yj-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:33:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILf3815941; Fri, 18 Apr 2003 17:41:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILeb815915 for ; Fri, 18 Apr 2003 17:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27496 for ; Fri, 18 Apr 2003 17:30:20 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196dTS-0001YJ-00 for rohc@ietf.org; Fri, 18 Apr 2003 17:32:46 -0400 Received: from fnord.ir.bbn.com ([192.1.100.210]) by ietf-mx with esmtp (Exim 4.12) id 196dTS-0001YG-00 for rohc@ietf.org; Fri, 18 Apr 2003 17:32:46 -0400 Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 99A3F253A; Fri, 18 Apr 2003 17:32:47 -0400 (EDT) Delivered-To: gdt@ir.bbn.com Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by fnord.ir.bbn.com (Postfix) with ESMTP id 4386C1F75 for ; Fri, 18 Apr 2003 16:48:08 -0400 (EDT) Received: by wolfe.bbn.com (Postfix) id 38DA716506; Fri, 18 Apr 2003 16:48:08 -0400 (EDT) Delivered-To: gdt@wolfe.bbn.com Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by wolfe.bbn.com (Postfix) with ESMTP id 1BE7216484; Fri, 18 Apr 2003 16:48:08 -0400 (EDT) Received: from gandalf.bbn.com (gandalf.bbn.com [192.1.120.116]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3IKm75v008844; Fri, 18 Apr 2003 16:48:07 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by gandalf.bbn.com (8.12.9/8.12.2) with ESMTP id h3IKm1s8023753; Fri, 18 Apr 2003 16:48:01 -0400 Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10212 Fri, 18 Apr 2003 16:40:58 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16032.25540.468724.228395@pkoning.dev.equallogic.com> Date: Fri, 18 Apr 2003 16:44:52 -0400 From: Paul Koning To: yaronf@gmx.net Cc: kent@bbn.com, Lars-Erik.Jonsson@epl.ericsson.se, derek@ihtfp.com, rohc@ietf.org, ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Precedence: bulk X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.17 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.6 required=5.0 tests=REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >>>>> "Yaron" == Yaron Sheffer writes: Yaron> Hi Steve, I see a trade-off here between tweaking ROHC to deal Yaron> with reordering channels (it may be easy or hard, I don't Yaron> know) and tweaking the ESP *implementation* to undo such Yaron> reordering. I accept that the RFC doesn't mandate or even Yaron> suggest it, and from an architectural perspective it's not Yaron> clean. But it's a minor change to the implementation of Yaron> sequence-number handling in ESP... Nonsense. It's a very major change in the implementation of ESP. ESP processes IP packets one at a time. It does not care whether they are being reordered; it does not, repeat NOT, put them in any order different from the order in which they arrived. To do what you suggest would be a large redesign, which would also completely ruin performance. ("Fragmentation considered Harmful" by Jeff Mogul explains this nicely, for a different case where the same considerations are valid.) Note also that there are a bunch of ESP implementations done in silicon. For those, what you propose is even more unreasonable than it would be for a software implementation. But I don't think any implementer of either kind of implementation would consider your proposal. paul _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 17:31:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27595 for ; Fri, 18 Apr 2003 17:31:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ILfPn16025 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 17:41:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILfO816022 for ; Fri, 18 Apr 2003 17:41:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27541 for ; Fri, 18 Apr 2003 17:31:07 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196dUD-0001Yx-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:33:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196dUD-0001Yu-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:33:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILf4815957; Fri, 18 Apr 2003 17:41:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILeb815916 for ; Fri, 18 Apr 2003 17:40:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27499 for ; Fri, 18 Apr 2003 17:30:20 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196dTS-0001YN-00 for rohc@ietf.org; Fri, 18 Apr 2003 17:32:46 -0400 Received: from fnord.ir.bbn.com ([192.1.100.210]) by ietf-mx with esmtp (Exim 4.12) id 196dTS-0001YE-00 for rohc@ietf.org; Fri, 18 Apr 2003 17:32:46 -0400 Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 40671252E; Fri, 18 Apr 2003 17:32:47 -0400 (EDT) Delivered-To: gdt@ir.bbn.com Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by fnord.ir.bbn.com (Postfix) with ESMTP id A0B541F75 for ; Fri, 18 Apr 2003 14:57:33 -0400 (EDT) Received: by wolfe.bbn.com (Postfix) id 9098016506; Fri, 18 Apr 2003 14:57:33 -0400 (EDT) Delivered-To: gdt@wolfe.bbn.com Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by wolfe.bbn.com (Postfix) with ESMTP id 4E7C116484; Fri, 18 Apr 2003 14:57:33 -0400 (EDT) Received: from gollum.bbn.com (gollum.bbn.com [192.1.120.132]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3IIvW5v002633; Fri, 18 Apr 2003 14:57:32 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by gollum.bbn.com (8.12.9/8.12.2) with ESMTP id h3IIvRxK023559; Fri, 18 Apr 2003 14:57:27 -0400 Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09920 Fri, 18 Apr 2003 14:44:48 -0400 (EDT) From: "Yaron Sheffer" To: "Stephen Kent" Cc: "Lars-Erik Jonsson (EAB)" , "Derek Atkins" , , Subject: RE: [rohc] RE: (in)security of ESP with header compression Date: Fri, 18 Apr 2003 21:48:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.19 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-16.9 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,MSGID_GOOD_EXCHANGE, ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Steve, I see a trade-off here between tweaking ROHC to deal with reordering channels (it may be easy or hard, I don't know) and tweaking the ESP *implementation* to undo such reordering. I accept that the RFC doesn't mandate or even suggest it, and from an architectural perspective it's not clean. But it's a minor change to the implementation of sequence-number handling in ESP, which can be spelled out specifically in a "Header compression over ESP" draft. Otherwise you need to work very hard to implement ROHC (or CRTP, or ECRTP) securely over ESP, going through contortions like the proposed authentication-before-compression (sorry David). Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a IPCOMP_SUPPORTED notification, which can be extended (and renamed to COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that ROHC should be an IPComp profile, only that it's negotiated in an analogous manner. IPComp makes different assumptions regarding traffic (packet lengths) compared to ROHC, and therefore probably doesn't do the job here. But this is for the ROHC people to judge. I am being somewhat simplistic, you may need to negotiate some basic compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE, LZS} values of this field. Speaking about the IPSec architecture, it's a pity that compression parameters remain an integral part of IKE v2, rather than add-ons. Best regards, Yaron -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, April 18, 2003 2:42 PM To: Yaron Sheffer Cc: Lars-Erik Jonsson (EAB); Derek Atkins; rohc@ietf.org; ipsec@lists.tislabs.com Subject: RE: [rohc] RE: (in)security of ESP with header compression At 12:59 AM +0200 4/18/03, Yaron Sheffer wrote: >ESP includes a 32-bit sequence number. It is mandatory for the sender to set >and increment it correctly, but optional for the receiver to verify it. It >is there to prevent malicious replay of messages. > >In the case of ROHC over ESP, if the receiver's policy is to delete packets >with an out-of-order ESP sequence number (possibly using a small reorder >buffer), then packets reaching the decompressor are always in order. The >channel is not reliable of course, since entire packets may be deleted. All >in all, this channel becomes analogous to your plain vanilla PPP. > >Applicability: in general, IP (and ESP) packets may be drastically >reordered, with packets coming in many seconds out of order. For Internet >telephony, those packets are useless and can be discarded on arrival. > >Under these assumptions, I don't believe any change to the operating >assumptions of ROHC, or a new ROHC profile, is needed. This is not "ROHC >over tunnels" but only "ROHC over ESP", but it's still an interesting case. > >Thanks, > Yaron I may not have understood your argument, but any solution we would adopt for IPsec use of ROHC must be general, i.e., it cannot depend on specific receiver constraints re anti-replay window parameters. Also, your message suggests a possible misunderstanding re IPsec and anti-replay: I know of no IPsec implementation that reorders packets upon arrival and doing so is certainly outside the scope of what the RFCs call for. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 18 17:31:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27609 for ; Fri, 18 Apr 2003 17:31:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ILfRm16041 for rohc-archive@odin.ietf.org; Fri, 18 Apr 2003 17:41:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILfR816038 for ; Fri, 18 Apr 2003 17:41:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27545 for ; Fri, 18 Apr 2003 17:31:10 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196dUG-0001Z3-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:33:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196dUF-0001Z0-00 for rohc-web-archive@ietf.org; Fri, 18 Apr 2003 17:33:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILf5815973; Fri, 18 Apr 2003 17:41:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ILec815918 for ; Fri, 18 Apr 2003 17:40:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27501 for ; Fri, 18 Apr 2003 17:30:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196dTS-0001YP-00 for rohc@ietf.org; Fri, 18 Apr 2003 17:32:46 -0400 Received: from fnord.ir.bbn.com ([192.1.100.210]) by ietf-mx with esmtp (Exim 4.12) id 196dTS-0001YF-00 for rohc@ietf.org; Fri, 18 Apr 2003 17:32:46 -0400 Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 5D7CF2532; Fri, 18 Apr 2003 17:32:47 -0400 (EDT) Delivered-To: gdt@ir.bbn.com Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by fnord.ir.bbn.com (Postfix) with ESMTP id B298F1F75 for ; Fri, 18 Apr 2003 15:19:14 -0400 (EDT) Received: by wolfe.bbn.com (Postfix) id 9CE2616506; Fri, 18 Apr 2003 15:19:14 -0400 (EDT) Delivered-To: gdt@wolfe.bbn.com Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by wolfe.bbn.com (Postfix) with ESMTP id 7A6D116484; Fri, 18 Apr 2003 15:19:14 -0400 (EDT) Received: from gollum.bbn.com (gollum.bbn.com [192.1.120.132]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3IJJD5v004101; Fri, 18 Apr 2003 15:19:13 -0400 (EDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by gollum.bbn.com (8.12.9/8.12.2) with ESMTP id h3IJJ7xK025344; Fri, 18 Apr 2003 15:19:08 -0400 Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09970 Fri, 18 Apr 2003 15:11:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 18 Apr 2003 15:09:53 -0400 To: "Yaron Sheffer" From: Stephen Kent Subject: RE: [rohc] RE: (in)security of ESP with header compression Cc: "Lars-Erik Jonsson (EAB)" , "Derek Atkins" , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.19 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Precedence: bulk X-Spam-Status: No, hits=-22.7 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , At 9:48 PM +0200 4/18/03, Yaron Sheffer wrote: >Hi Steve, > >I see a trade-off here between tweaking ROHC to deal with reordering >channels (it may be easy or hard, I don't know) and tweaking the ESP >*implementation* to undo such reordering. I accept that the RFC doesn't >mandate or even suggest it, and from an architectural perspective it's not >clean. But it's a minor change to the implementation of sequence-number >handling in ESP, which can be spelled out specifically in a "Header >compression over ESP" draft. Otherwise you need to work very hard to >implement ROHC (or CRTP, or ECRTP) securely over ESP, going through >contortions like the proposed authentication-before-compression (sorry >David). Well, ESP has been around for a while; RFC 2406 was published in November of 1998. I don't think we can reasonably ask implementors to change their implementations to accommodate ROHC. Also, as you note, it is not architecturally attractive, since IP would not reorder the traffic and IPsec tries to minimize the differences between what the IP interface does and what IPsec does. We had to impose the notion of a receive window as a tradeoff in this regard, to make anti-replay feasible yet not too hard for an IPsec implementation. Also, as we go to higher speeds, asking an IPsec implementation to buffer inbound traffic places a significant burden on the implementation, since this would have to be done in hardware that is trying to operate at line rates. >Re: your comment in a previous mail, on negotiating ROHC in IKE. IKEv2 has a >IPCOMP_SUPPORTED notification, which can be extended (and renamed to >COMPRESSION_SUPPORTED?) by adding ROHC, ECRTP etc. This DOES NOT mean that >ROHC should be an IPComp profile, only that it's negotiated in an analogous >manner. IPComp makes different assumptions regarding traffic (packet >lengths) compared to ROHC, and therefore probably doesn't do the job here. >But this is for the ROHC people to judge. I understand. >I am being somewhat simplistic, you may need to negotiate some basic >compression parameters as well, just like the existing IPCOMP_{OUI, DEFLATE, >LZS} values of this field. > >Speaking about the IPSec architecture, it's a pity that compression >parameters remain an integral part of IKE v2, rather than add-ons. IKE is really a security association management protocol and if compression is part of the SA processing, then we have to negotiate its use and parameters when we establish an SA. Key management is the easy part :-). All the complexity is in the SA management part. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Sun Apr 20 09:21:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04353 for ; Sun, 20 Apr 2003 09:21:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3KDWJD03409 for rohc-archive@odin.ietf.org; Sun, 20 Apr 2003 09:32:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3KDWJ803406 for ; Sun, 20 Apr 2003 09:32:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04347 for ; Sun, 20 Apr 2003 09:21:14 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197EnB-0002RP-00 for rohc-web-archive@ietf.org; Sun, 20 Apr 2003 09:23:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197EnB-0002RL-00 for rohc-web-archive@ietf.org; Sun, 20 Apr 2003 09:23:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3KDVn803386; Sun, 20 Apr 2003 09:31:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3KDQu803267 for ; Sun, 20 Apr 2003 09:26:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04301 for ; Sun, 20 Apr 2003 09:15:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197Ehy-0002Qc-00 for rohc@ietf.org; Sun, 20 Apr 2003 09:18:14 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 197Ehw-0002QY-00 for rohc@ietf.org; Sun, 20 Apr 2003 09:18:13 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id A78B08A55E; Sun, 20 Apr 2003 22:47:52 +0930 (CST) Date: Sun, 20 Apr 2003 22:47:52 +0930 From: Alan Kennington To: rohc@ietf.org Message-ID: <20030420224752.A22988@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] RFCs 3095, 3241 - feedback CID encoding - apparent contradiction Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Referring to RFC 3095, 5.2.2, page 46: The large CID, if present, is encoded according to section 4.5.6. CID information in feedback data indicates the CID of the packet stream for which feedback is sent. Note that the LARGE_CIDS parameter that controls whether a large CID is present is taken from the channel state of the receiving compressor's channel, NOT from that of the channel carrying the feedback. There's a problem with this. How can the decompressor (which wants to send a feedback packet) know what the channel state of the peer compressor is? I imagine that most of the time, you could make a pretty good guess by looking at the LARGE-CIDS parameter (RFC 3095, 5.1.1, page 39) of the channel on which the last packet from that compressor arrived. But in RFC 3241 (ROHC/PPP), page 2, it says: A PPP ROHC sender may send packets in either small-CID or large-CID format at any time, i.e., the LARGE_CIDS parameter from [RFC3095] is not used. Any PPP ROHC receiver MUST be able to process both small- CID and large-CID ROHC packets, therefore no negotiation of this function is required. The compressor has the following options for use of the 0x0003 and 0x0005 PPP protocols in ROHC/PPP: 1. Send all ROHC forward data packets with CID <= 15 with PPP protocol = 0x0003, therefore with small-CID encoding. (This is not an unreasonable choice.) 2. Send all ROHC forward data packets with CID <= 15 with PPP protocol = 0x0005, therefore with large-CID encoding. (This is also not unreasonable, because then the software doesn't need to bother with small-CID encoding ever - for forward pkts.) 3. Send ROHC forward data packet with CID <= 15 with mixed choices of PPP protocol 0x0003 and 0x0005, therefore with mixed CID encodings. (This is explicitly permitted by RFC 3241.) So now I want to send an ACK packet to a compressor which has chosen option 3 - mixed PPP protocols. How do I encode the CID for the feedback message? This is important because the compressor has to decode the CID according to the (undefined) LARGE_CIDS parameter in order to make sense of those bytes it receives. The result in case of misinterpretation could be garbage, except that it could make a guess on the basis of the leading bits of the first octet of the feedback message. But then if the compressor is _expected_ to use the leading bits to guess the CID encoding, then why bother to state that in RFC 3095, 5.2.2, page 46 that the feedback message encoding must be chosen acording to the compressor's channel state? =================================================== In RFC 3241, part 4, page 7, there's this: Note that this implies that all CIDs within one ROHC packet MUST be of the same size as indicated by the Data Link Layer Protocol field, either small or large. In particular, embedded feedback MUST have a CID of the same size as indicated by the Protocol field value. For piggybacking feedback, a compressor must be able to control the feedback CID size used by the associated decompressor, ensure that all CIDs are of the same size, and indicate this size with the appropriate Protocol Field value. This seems to resolve the issue, but it directly contradicts RFC 3095. It means that a compressor which receives feedback messages must refer to the PPP DL layer protocol field to decode the CID, whereas for general ROHC in RFC 3095, the compressor receiving feedback messages must decode them according to the well-defined LARGE_CIDS paramter for the channel to which the compressor is attached. My conclusion is: RFCs 3095 and 3241 are in contradiction. The encoding and decoding of feedback messages is different in general ROHC compared with ROHC/PPP. This would imply that ROHC encoder/decoder software written for ROHC/PPP would be erroneous for non-PPP ROHC. At the very least, there should have been a note in RFC 3241, page 7, stating that the CID-encoding rules for feedback in ROHC/PPP contradict and supersede the CID encoding rules for ROHC in RFC 3095, 5.2.2, page 46. =================================================== Am I right about this? Or have I missed something here? Cheers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 22 10:28:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11582 for ; Tue, 22 Apr 2003 10:28:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MEeTP10163 for rohc-archive@odin.ietf.org; Tue, 22 Apr 2003 10:40:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEeS810157 for ; Tue, 22 Apr 2003 10:40:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11545 for ; Tue, 22 Apr 2003 10:28:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197ynE-00027A-00 for rohc-web-archive@ietf.org; Tue, 22 Apr 2003 10:30:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197ynD-000275-00 for rohc-web-archive@ietf.org; Tue, 22 Apr 2003 10:30:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEdw810084; Tue, 22 Apr 2003 10:39:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEab809047 for ; Tue, 22 Apr 2003 10:36:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11475 for ; Tue, 22 Apr 2003 10:24:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197yjW-000261-00 for rohc@ietf.org; Tue, 22 Apr 2003 10:26:54 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 197yjV-00025y-00 for rohc@ietf.org; Tue, 22 Apr 2003 10:26:53 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3MERGRs029705 for ; Tue, 22 Apr 2003 16:27:16 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JN9VW82Y; Tue, 22 Apr 2003 16:27:18 +0200 Received: by lms001.lu.erisoft.se id QAA21649; Tue, 22 Apr 2003 16:27:22 +0200 (MET DST) Message-ID: <3EA55144.DA76C6A5@epl.ericsson.se> Date: Tue, 22 Apr 2003 16:27:16 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Lars-Erik Jonsson (EPL)" CC: "rohc@ietf.org" Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.wise.edt.ericsson.se id h3MERGRs029705 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3MEac809048 Subject: [rohc] More comments on Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3MEdw810084 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3MEeS810157 Content-Transfer-Encoding: 8bit Lars-Erik, I would like to make a suggestion regarding section 3.1 of . I would like to see this section 3.1 broken in two - one for each difference of the IP-only profile from the UDP profile, i.e. - one for the static chain termination (3.1); and - one for the handling of multiple IP headers (3.2). While I think that the termination of the static chain is straighforward, it is however strictly related to the compression of only IP headers. Thus it shouldn't be blended together with the discussion regarding the handling of multiple levels of IP headers. I also think that a clearer explanation regarding the limitations of the compression profiles in RFC-3095 for multiple levels of IP headers (where the limitations come from and their consequences) would be useful. Specifically, the second paragraph of the current section 3.1 only states a limitation and moves on to (somewhat unclearly) naming an alternative for a potential solution that is only valid for the IP-only profile - that is leaving additional headers uncompressed by terminating compression after the section IP header. However, this limitation is something that is not specific to the IP-only profile, and should be elaborated more clearly in its own subsection. This separation would also be useful for other drafts (e.g. profiles for UDP-Lite and TCP) if need is to refer to the part of IP-only profile explaining these limitations with arbitrary levels of IP headers, if these other profiles are to handle this as well. Regards, /Ghyslain Ghyslain Pelletier Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Luleå, Sweden Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 70 609 27 73 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 22 11:03:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12849 for ; Tue, 22 Apr 2003 11:03:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MFFHN13048 for rohc-archive@odin.ietf.org; Tue, 22 Apr 2003 11:15:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFFH813045 for ; Tue, 22 Apr 2003 11:15:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12801 for ; Tue, 22 Apr 2003 11:03:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197zKu-0002OF-00 for rohc-web-archive@ietf.org; Tue, 22 Apr 2003 11:05:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197zKu-0002OC-00 for rohc-web-archive@ietf.org; Tue, 22 Apr 2003 11:05:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFEv812864; Tue, 22 Apr 2003 11:14:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MF6L811617 for ; Tue, 22 Apr 2003 11:06:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12571 for ; Tue, 22 Apr 2003 10:54:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197zCG-0002KP-00 for rohc@ietf.org; Tue, 22 Apr 2003 10:56:37 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 197zCG-0002KM-00 for rohc@ietf.org; Tue, 22 Apr 2003 10:56:36 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3MEuxI3009819 for ; Tue, 22 Apr 2003 16:56:59 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 22 Apr 2003 16:57:00 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Ghyslain Pelletier (EAB)" Cc: rohc@ietf.org Date: Tue, 22 Apr 2003 16:45:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] RE: More comments on Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Ghyslain, > I would like to see this section 3.1 broken in two - one for each > difference of the IP-only profile from the UDP profile, i.e. > > - one for the static chain termination (3.1); and > - one for the handling of multiple IP headers (3.2). This is probably a good idea! > I also think that a clearer explanation regarding the > limitations of the compression profiles in RFC-3095 for > multiple levels of IP headers (where the limitations come > from and their consequences) would be useful. Specifically, > the second paragraph of the current section 3.1 only states > a limitation and moves on to (somewhat unclearly) naming an > alternative for a potential solution that is only valid for > the IP-only profile - that is leaving additional headers > uncompressed by terminating compression after the section > IP header. Yes, the current text is rather short and it can for sure be enhanced to become clearer and more informative. > This separation would also be useful for other drafts (e.g. > profiles for UDP-Lite and TCP) if need is to refer to the > part of IP-only profile explaining these limitations with > arbitrary levels of IP headers, if these other profiles are > to handle this as well. That is a also good point. I'll try to generate an update of the draft within a few weeks. Cheers, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Apr 23 07:50:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14348 for ; Wed, 23 Apr 2003 07:50:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NC30317661 for rohc-archive@odin.ietf.org; Wed, 23 Apr 2003 08:03:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NC2x817658 for ; Wed, 23 Apr 2003 08:02:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14328 for ; Wed, 23 Apr 2003 07:50:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Inw-000345-00 for rohc-web-archive@ietf.org; Wed, 23 Apr 2003 07:52:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198Inw-000340-00 for rohc-web-archive@ietf.org; Wed, 23 Apr 2003 07:52:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NC2X817624; Wed, 23 Apr 2003 08:02:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NBxA817446 for ; Wed, 23 Apr 2003 07:59:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14268 for ; Wed, 23 Apr 2003 07:46:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198IkF-00032I-00 for rohc@ietf.org; Wed, 23 Apr 2003 07:48:59 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 198IkF-000326-00 for rohc@ietf.org; Wed, 23 Apr 2003 07:48:59 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Apr 2003 12:48:52 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F217@rsys002a.roke.co.uk> From: "Price, Richard" To: "'rohc@ietf.org'" Date: Wed, 23 Apr 2003 12:48:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] ROHC-FN and TCP Profile - Version 2 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, Now that Easter's out of the way, it might be a good time to restart the discussion on ROHC-FN and the TCP compression profile. In the interests of getting the discussion going, here's a link to Version 2 of our implementation: http://sigcomp.srmr.co.uk/~rjp/ROHC-FN_Version_2.zip For the updated implementation we've added all of the encoding methods not supported in Version 1, including Huffman-based discriminator encoding (i.e. EPIC-lite) as well as "list" encoding for the TCP options and the IP extension headers. We've also added support for real IR packets with the correct indicator bits. The TCP packet formats have been updated to take advantage of the new encoding methods - we can now compress various TCP options using list encoding, and have a single discriminator for the header as a whole. Minimum compressed header size is now 3 bytes. One other issue - the updated implementation is written in a different language from the original (namely Prolog rather than Haskell). We're still working on the Haskell code, but we're turning it into a "proper" implementation (with full debugging and a nice user interface). A suitable Prolog interpreter can be downloaded from: http://www.swi-prolog.org/download.html For simplicity, the implementation is provided as a single Prolog source file. Just open it and type "comp_list(tcp_test_n)." where n is the TCP test flow to be compressed. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Apr 24 10:30:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18336 for ; Thu, 24 Apr 2003 10:30:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OEXJi14380 for rohc-archive@odin.ietf.org; Thu, 24 Apr 2003 10:33:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEXJ814377 for ; Thu, 24 Apr 2003 10:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18308 for ; Thu, 24 Apr 2003 10:30:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198hm0-0006FG-00 for rohc-web-archive@ietf.org; Thu, 24 Apr 2003 10:32:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198hm0-0006FC-00 for rohc-web-archive@ietf.org; Thu, 24 Apr 2003 10:32:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEWd814324; Thu, 24 Apr 2003 10:32:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEVn814267 for ; Thu, 24 Apr 2003 10:31:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18257 for ; Thu, 24 Apr 2003 10:28:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198hkZ-0006ET-00 for rohc@ietf.org; Thu, 24 Apr 2003 10:30:59 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 198hkY-0006EL-00 for rohc@ietf.org; Thu, 24 Apr 2003 10:30:58 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Apr 2003 15:30:50 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F21A@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , rohc@ietf.org Subject: RE: [rohc] Formal notation, combined thread Date: Thu, 24 Apr 2003 15:30:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, Apologies for the late reply - the Easter holiday got in the way ;-) I've added some further comments inline. Now that a complete implementation of the current ROHC-FN draft is available, would it be worth collecting together all of the unresolved issues related to the notation? This thread is discussing the "scope and purpose" of the notation, but there are also some more technical issues that still need to be ironed out, such as whether to keep the temporary variables, whether to allow unbounded lists and so on. Regards, Richard > > We'd run into difficulty if we had to use a single (unspecified) > > discriminator function for every case where compressed data can be > > sent in more than one way. We'd be forced to use a single method to > > encode every discriminator, even for the special cases where a > > different method is more memory efficient or gets a better > > compression ratio. > > I think you missed my point. The point was to have a notation where > you would have an unspecified (generic) function, but that would not > out rule having other functions for some special cases, like context > based choices (that might be another general method). I think that having an unspecified "generic" encoding method that can be defined later on is only possible if there are two or more methods with the same purpose and inputs. I'm not currently aware of any encoding methods that work like this. > What I am after is that where you could choose to use OH (Ordinary > Huffman), you could as well use HH (Hierarchical Huffman), or some > other discriminator function with the same purpose and input. The OH and HH algorithms have the same purpose, but their inputs are actually somewhat different. Certain field encodings can be used in conjunction with HH that can't be used with OH - an example is the so-called Least Significant Part (LSP) encoding that was considered briefly for use in 3095. Conversely, some encoding methods can be used in conjunction with OH that can't be used with HH - for example the "uncompressible" encoding method as defined in the notation draft. > It is just about using a different algorithm, and the choice is in > my mind a rather subjective one, made when one define a profile. True. However, once this decision is made, a different set of field encodings will be available to the profile designer depending on whether OH or HH is used. > I do not think a profile should use both OH, HH, and/or even more > discriminator functions, but instead I would like to see a generic > way of notating, and then the profile definition would state which > discriminator function to actually use for those places where this > generic method is called in the notation. The only way to do this would be to restrict the set of field encodings to ones that can work in conjunction with both OH and HH. At present it's entirely up to the profile designer whether to do this or not. For example, if we want to create two profiles for TCP/IP - one using OH and one using HH - then we have two choices: either create two profiles that use the same (restricted) set of field encodings, or use the optimal set of field encodings for each case (even though some field encodings only work for OH and others only work for HH). I think that both approaches have their merits - the first is simpler, whilst the second will get a better compression ratio due to having a wider range of field encodings available for each of the profiles. What I'd like to avoid is forcing profile designers to use only the generic approach, because we'll typically know the discriminator encoding that the profile will use and can therefore take advantage of this knowledge when selecting the field encodings. > > This approach also makes the notation rather more simple than the > > case where the discriminator flags are treated separately. Currently, > > discriminator flags are treated exactly like any other data that > > needs to be sent to the decompressor. In particular, we don't need > > to worry about having new data structures to hold the discriminator > > flags - they can be stored in the same data structures that we use > > for the "ordinary" header fields (namely the labels and the context). > > Moreover we don't have any special syntax for handling the > > discriminator flags - we can compress them by applying our choice > > of encoding method (e.g. EPIC-lite) just like we would apply LSB > > encoding to compress a particular field. > > Complexity is not just about implementation, but also about structured > concepts. Functionally, discriminators might just be created by using > "just another encoding method", but we should make the difference > clear conceptually, when we outline this new approach for describing > a header compression process. From a conceptual point of view, I'm not at all clear on the difference between a discriminator encoding and, say, a field encoding. The way I visualise encoding methods is just as "subroutines" that can be called in the ROHC-FN language. Each subroutine is designed to compress some or all of the bits in the header, and, naturally, the more complex subroutines are defined in terms of simpler ones. Thus, a typical set of packet formats is created using layers of progressively more complex encoding methods, e.g: Whole header: Ordinary Huffman / \ Part of header: / List / /\ Individual fields: IP-ID NBO Irregular / \ Partial fields: Offset LSB In this layered approach it's difficult to find a single property that defines whether an encoding is a field encoding, a discriminator encoding or something else entirely. It's not the case that only the discriminator encodings offer implementation-specific choices, because a number of field encodings offer them as well (e.g. NBO). Similarly, it's not the case that discriminator encodings need to be applied to the whole header, because the discriminator encodings such as list are applied to part of the header only. Unless of course we make list encoding into a special case (which would be peculiar, because it generates discriminator bits no differently from, say, OH or HH). Any other suggestions for what is actually meant when we talk about "discriminator encodings"? > Further, I strongly believe that there is a difference in how you > choose discriminator encoding, compared to how you pick field encoding > methods. The latter is (almost) purely based on field behavior, while > the former choice is not as obvious, it is a more subjective profile > designer choice. I don't believe that this is the case. For example, in the proposed TCP packet formats we're already making a subjective choice to simplify the field encodings, by using LSB encoding instead of the more powerful but more complicated LSP encoding. Similarly, our choice of which version of list encoding to use, whether to allow NBO encoding and so on are all subjective decisions that must be made independently of the decision on whether to use OH, HH etc. > > > > We originally used the term "EPIC-lite" to mean > > > > the entire notation-based solution, including > > > > the notation itself and the complete library of > > > > encoding methods. The algorithm for generating > > > > the discriminator bits is actually nothing more than > > > > ordinary Huffman encoding, so perhaps we could > > > > just call it that instead? > > > > > > Ok, "Ordinary Huffman" (OH), and "Hierarchical Huffman" (HH) then? > > > > Sounds ok to me! > > Fine, let's try to use those then. > > /L-E > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Apr 25 13:06:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15142 for ; Fri, 25 Apr 2003 13:06:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PH9ii11713 for rohc-archive@odin.ietf.org; Fri, 25 Apr 2003 13:09:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PH9i811710 for ; Fri, 25 Apr 2003 13:09:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15129 for ; Fri, 25 Apr 2003 13:06:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1996gO-0002Ca-00 for rohc-web-archive@ietf.org; Fri, 25 Apr 2003 13:08:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1996gN-0002CW-00 for rohc-web-archive@ietf.org; Fri, 25 Apr 2003 13:08:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PH9G811694; Fri, 25 Apr 2003 13:09:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PH8M811618 for ; Fri, 25 Apr 2003 13:08:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15067 for ; Fri, 25 Apr 2003 13:04:40 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1996f4-0002C4-00 for rohc@ietf.org; Fri, 25 Apr 2003 13:06:58 -0400 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by ietf-mx with esmtp (Exim 4.12) id 1996f3-0002C1-00 for rohc@ietf.org; Fri, 25 Apr 2003 13:06:57 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3PH7Qb03023 for ; Fri, 25 Apr 2003 12:07:26 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Apr 2003 12:07:24 -0500 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 25 Apr 2003 10:06:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2 Date: Fri, 25 Apr 2003 12:06:39 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE01398839@daebe004.americas.nokia.com> Thread-Topic: [rohc] ROHC-FN and TCP Profile - Version 2 Thread-Index: AcMJjukEAzRideI2RbSFnJwC4dXrpgBvLDRQ To: , X-OriginalArrivalTime: 25 Apr 2003 17:06:40.0050 (UTC) FILETIME=[09C07120:01C30B4D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3PH8M811619 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Richard, Could you please share the version 2 for the TCP compression profile in the pictorial form with textual description (basically, in the I-D format). Something similar you did for the previous version. Thanks, Yousuf -----Original Message----- From: ext Price, Richard [mailto:richard.price@roke.co.uk] Sent: Wednesday, April 23, 2003 6:49 AM To: 'rohc@ietf.org' Subject: [rohc] ROHC-FN and TCP Profile - Version 2 Hi, Now that Easter's out of the way, it might be a good time to restart the discussion on ROHC-FN and the TCP compression profile. In the interests of getting the discussion going, here's a link to Version 2 of our implementation: http://sigcomp.srmr.co.uk/~rjp/ROHC-FN_Version_2.zip For the updated implementation we've added all of the encoding methods not supported in Version 1, including Huffman-based discriminator encoding (i.e. EPIC-lite) as well as "list" encoding for the TCP options and the IP extension headers. We've also added support for real IR packets with the correct indicator bits. The TCP packet formats have been updated to take advantage of the new encoding methods - we can now compress various TCP options using list encoding, and have a single discriminator for the header as a whole. Minimum compressed header size is now 3 bytes. One other issue - the updated implementation is written in a different language from the original (namely Prolog rather than Haskell). We're still working on the Haskell code, but we're turning it into a "proper" implementation (with full debugging and a nice user interface). A suitable Prolog interpreter can be downloaded from: http://www.swi-prolog.org/download.html For simplicity, the implementation is provided as a single Prolog source file. Just open it and type "comp_list(tcp_test_n)." where n is the TCP test flow to be compressed. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 29 10:52:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26150 for ; Tue, 29 Apr 2003 10:52:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TEvZK18479 for rohc-archive@odin.ietf.org; Tue, 29 Apr 2003 10:57:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEvZ818476 for ; Tue, 29 Apr 2003 10:57:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26079 for ; Tue, 29 Apr 2003 10:51:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AWUl-0004zc-00 for rohc-web-archive@ietf.org; Tue, 29 Apr 2003 10:54:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AWUl-0004zY-00 for rohc-web-archive@ietf.org; Tue, 29 Apr 2003 10:54:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEuT818436; Tue, 29 Apr 2003 10:56:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEsl818311 for ; Tue, 29 Apr 2003 10:54:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25793 for ; Tue, 29 Apr 2003 10:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AWS3-0004ti-00 for rohc@ietf.org; Tue, 29 Apr 2003 10:51:23 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19AWS2-0004rh-00 for rohc@ietf.org; Tue, 29 Apr 2003 10:51:23 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 15:51:27 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F21C@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Yousuf.Saifullah@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2 Date: Tue, 29 Apr 2003 15:51:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Yousuf, Drawing the Version 2 packet formats out pictorially might be a bit of a challenge, as they're a *lot* more complex than the Version 1 formats. They're now roughly as complicated as the packet formats in RFC 3095, so the pictorial form plus accompanying text will be around 100 pages long - a non-trivial amount of effort to generate by hand ;-) A possible solution would be to modify our implementation so that it can automatically convert a ROHC-FN description of the packet formats into a pictorial one. If you think this feature would be useful, let me know so that we can add it to the next version of the implementation. Regards, Richard > -----Original Message----- > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > Sent: Friday, April 25, 2003 6:07 PM > To: Price, Richard; rohc@ietf.org > Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2 > > > Hi Richard, > Could you please share the version 2 for the TCP compression > profile in the pictorial form with textual description > (basically, in the I-D format). Something similar you did for > the previous version. > > Thanks, > Yousuf > > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Wednesday, April 23, 2003 6:49 AM > To: 'rohc@ietf.org' > Subject: [rohc] ROHC-FN and TCP Profile - Version 2 > > > Hi, > > Now that Easter's out of the way, it might be a good > time to restart the discussion on ROHC-FN and the TCP > compression profile. In the interests of getting the > discussion going, here's a link to Version 2 of our > implementation: > > http://sigcomp.srmr.co.uk/~rjp/ROHC-FN_Version_2.zip > > For the updated implementation we've added all of the > encoding methods not supported in Version 1, including > Huffman-based discriminator encoding (i.e. EPIC-lite) > as well as "list" encoding for the TCP options and > the IP extension headers. We've also added support for > real IR packets with the correct indicator bits. > > The TCP packet formats have been updated to take > advantage of the new encoding methods - we can now > compress various TCP options using list encoding, and > have a single discriminator for the header as a whole. > Minimum compressed header size is now 3 bytes. > > One other issue - the updated implementation is > written in a different language from the original > (namely Prolog rather than Haskell). We're still > working on the Haskell code, but we're turning it into > a "proper" implementation (with full debugging and a > nice user interface). > > A suitable Prolog interpreter can be downloaded from: > > http://www.swi-prolog.org/download.html > > For simplicity, the implementation is provided as a > single Prolog source file. Just open it and type > "comp_list(tcp_test_n)." where n is the TCP test flow > to be compressed. > > Regards, > > Richard > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Apr 29 16:50:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10064 for ; Tue, 29 Apr 2003 16:50:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TKtI522297 for rohc-archive@odin.ietf.org; Tue, 29 Apr 2003 16:55:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TKtI822294 for ; Tue, 29 Apr 2003 16:55:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10061 for ; Tue, 29 Apr 2003 16:49:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ac4p-00003E-00 for rohc-web-archive@ietf.org; Tue, 29 Apr 2003 16:51:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ac4o-00003A-00 for rohc-web-archive@ietf.org; Tue, 29 Apr 2003 16:51:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TKmP821980; Tue, 29 Apr 2003 16:48:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TKl6821923 for ; Tue, 29 Apr 2003 16:47:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09761 for ; Tue, 29 Apr 2003 16:41:22 -0400 (EDT) From: Yousuf.Saifullah@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Abwt-0007mB-00 for rohc@ietf.org; Tue, 29 Apr 2003 16:43:35 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Abws-0007lm-00 for rohc@ietf.org; Tue, 29 Apr 2003 16:43:35 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3TKhg716213 for ; Tue, 29 Apr 2003 23:43:42 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Apr 2003 23:43:42 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Apr 2003 23:43:42 +0300 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Apr 2003 15:42:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2 Date: Tue, 29 Apr 2003 15:42:31 -0500 Message-ID: <025E7DD4182874489CC2F61EE0FA19CE0139883D@daebe004.americas.nokia.com> Thread-Topic: [rohc] ROHC-FN and TCP Profile - Version 2 Thread-Index: AcMOXuOdqwAQrl9ZQzm7ggBK/a03YgAMHC9g To: , X-OriginalArrivalTime: 29 Apr 2003 20:42:31.0932 (UTC) FILETIME=[DB53CBC0:01C30E8F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3TKl6821924 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Richard, I think it would be useful to have the pictorial format generation. Thanks, Yousuf -----Original Message----- From: ext Price, Richard [mailto:richard.price@roke.co.uk] Sent: Tuesday, April 29, 2003 9:51 AM To: Saifullah Yousuf (NRC/Dallas); rohc@ietf.org Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2 Hi Yousuf, Drawing the Version 2 packet formats out pictorially might be a bit of a challenge, as they're a *lot* more complex than the Version 1 formats. They're now roughly as complicated as the packet formats in RFC 3095, so the pictorial form plus accompanying text will be around 100 pages long - a non-trivial amount of effort to generate by hand ;-) A possible solution would be to modify our implementation so that it can automatically convert a ROHC-FN description of the packet formats into a pictorial one. If you think this feature would be useful, let me know so that we can add it to the next version of the implementation. Regards, Richard > -----Original Message----- > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > Sent: Friday, April 25, 2003 6:07 PM > To: Price, Richard; rohc@ietf.org > Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2 > > > Hi Richard, > Could you please share the version 2 for the TCP compression > profile in the pictorial form with textual description > (basically, in the I-D format). Something similar you did for > the previous version. > > Thanks, > Yousuf > > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Wednesday, April 23, 2003 6:49 AM > To: 'rohc@ietf.org' > Subject: [rohc] ROHC-FN and TCP Profile - Version 2 > > > Hi, > > Now that Easter's out of the way, it might be a good > time to restart the discussion on ROHC-FN and the TCP > compression profile. In the interests of getting the > discussion going, here's a link to Version 2 of our > implementation: > > http://sigcomp.srmr.co.uk/~rjp/ROHC-FN_Version_2.zip > > For the updated implementation we've added all of the > encoding methods not supported in Version 1, including > Huffman-based discriminator encoding (i.e. EPIC-lite) > as well as "list" encoding for the TCP options and > the IP extension headers. We've also added support for > real IR packets with the correct indicator bits. > > The TCP packet formats have been updated to take > advantage of the new encoding methods - we can now > compress various TCP options using list encoding, and > have a single discriminator for the header as a whole. > Minimum compressed header size is now 3 bytes. > > One other issue - the updated implementation is > written in a different language from the original > (namely Prolog rather than Haskell). We're still > working on the Haskell code, but we're turning it into > a "proper" implementation (with full debugging and a > nice user interface). > > A suitable Prolog interpreter can be downloaded from: > > http://www.swi-prolog.org/download.html > > For simplicity, the implementation is provided as a > single Prolog source file. Just open it and type > "comp_list(tcp_test_n)." where n is the TCP test flow > to be compressed. > > Regards, > > Richard > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc