Subject: RE: [rohc] Verifying decompression in ROHC-TCP

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 17 Jul 2003 11:10:37 +0200

Some general questions/observations:

1) Do we believe there is relevant IPR on the CRC approach from 3095?

2) Do we believe that this is the only 3095-IPR we should be "afraid" of?

Finding out how to tackle the situation is the next step after answering yes to the two questions above.

/L-E

> -----Original Message-----
> From: West, Mark [mailto:[email-masked]]
> Sent: den 17 juli 2003 11:08
> To: [email-masked]
> Subject: [rohc] Verifying decompression in ROHC-TCP
> 
> 
> 
> Hi all,
> 
> The good ol' IPR issue is looming over rohc TCP, even as I type..!
> Specifically, this relates to the use of a CRC to verify correct
> decompression (a la RFC 3095).
> 
> [note that we are only talking about verifying decompression 
> -- we are not
> considering 'context repair' (in 3095-speak)]
> 
> So, we appear to have (at least) 3 choices, which I document 
> here to see
> if anyone wants to discuss it... please..!
> 
> 1/ try and do something very close to the 3095 approach, but avoid
> infriging the claimed IPR.  A proposal along these lines 
> could be to CRC
> the *context*.  (This means some header fields are not 
> included and some
> meta-data is included).  It has essentially the same strength 
> as the ROHC
> RTP scheme.  The biggest disadvantage is that this requires 
> us to define
> the CRC over the context (i.e. some format for the context), which is
> somewhat unpleasant.
> 
> 1a/ a slight modification of the above, in which we only CRC 
> the context
> fields that are updated by the packet.  So, we are trying to 
> protect the
> mapping between the compressed and uncompressed 
> representations.  It has
> (most of) the same properties of scheme 1.  It should be possible to
> specify this in a way that is slightly less onerous to compute...
> 
> 2/ do it just like 1144/2507, i.e. rely solely upon the TCP checksum.
> There are many problems with this, which include:
> - known weaknesses of the TCP checksum
> - issues with the changes that are signalled by deltas in 1144/2507
> - lack of coverage of much of the IP header
>   (and, worse, IPv6 extension headers)
> - coverage includes the payload, which may be large and which (for
> compression) we don't care about
> Although we *could* do it this way, it is one of the things 
> that we really
> wanted to fix in ROHC-TCP.
> 
> 3/ do something weird... for example: use the TCP checksum to verify
> correct decompression (as per 1144/2507), acknowledging that 
> this has a
> number of weaknesses.  However, in addtion, we make use of the Master
> Sequence Number (MSN) to add some extra protection.
> 
> Define the MSN to be (say) a 32-bit value.  Send a small 
> number of LSBs of
> this in each packet.  Also send a small checksum calculated 
> over the MSN +
> the *compressed* packet.  At the decompressor, decode the MSN 
> and verify
> the checksum.  [I assume that we have specified how robust we want
> ROHC-TCP to be (e.g. to 3 consecutive packet losses)]
> 
> If the MSN doesn't verify, we call decompression failure.  If 
> it *does*
> verify, then we check it: if it's within the robustness 
> bounds, we attempt
> decompression (we believe that we have a valid compressed 
> packet for which
> decompression will work).
> Otherwise, we call decompression failure.  Only if we attempt
> decompression (and believe that it will succeed) do we use the TCP
> checksum to finally verify decompression.
> 
> This still has most of the weaknesses of 1144/2507, but we 
> *aren't* using
> the checksum blindly to verify arbitrary decompression 
> attempts.  Maybe
> this makes things better?
> 
> Another small point to note is that the decompression methods of ROHC
> *might* (and I haven't thought this through fully) be less 
> vulnerable to
> the 1144/2507 delta encoding with regard to exposing weaknesses in the
> TCP/IP checksum.
> 
> 4/ random aside: is a message digest the same thing as a 
> checksum..? ;-)
> 
> Comments welcome...
> 
> 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
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: "West, Mark" <[email-masked]>
Date: Thu, 17 Jul 2003 10:21:13 +0000 (GMT)

Hi Lars-Erik,

In respect of 1, perhaps someone can clarify the status of patent
WO0079763 / CA2375830 "Robust Header Compression in Packet
Communications"..?  (I believe that at least one of the authors
regularly reads this list ;-)

In respect of 2, this is a good question.  The CRC issue appears, to me,
to be 'clear and present'.  As to others, we've had no indication of
problmes so far, but...

So, I'll go for a 'yes' and a 'maybe' ;-)

Mark.

On Thu, 17 Jul 2003, Lars-Erik Jonsson (LU/EAB) wrote:

> Date: Thu, 17 Jul 2003 11:10:37 +0200
> From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
> To: "West, Mark" <[email-masked]>, [email-masked]
> Subject: RE: [rohc] Verifying decompression in ROHC-TCP
>

---

From: Alan Kennington <[email-masked]>
Date: Mon, 21 Jul 2003 08:43:27 +0930

> Finding out how to tackle the situation is the next step after answering yes to the two questions above.

L-E,

Can you (or any one else) give an indication of whether it would be safe for
an open source developer to release a linux open source implementation of ROHC?

I'm particularly interested in the RFC 3095 profiles 0, 1, 2 and 3.
I notice that there is an implementation of profiles 0, 2, 4 and 7
for linux kernel for PPP over ethernet already in the public domain
on sourceforge: http://rohc.sourceforge.net/

Particularly for academics, it would be nice to have an open reference
implementation for teaching and research.
My particular interest is in ROHC/PPP implementations.

At first I thought that linux PPP/ROHC would not be any sort of competition to
the 3G world because no mobile phone company would worry about 
compression on dial-up phone lines. 
But now I'm starting to think that ROHC/PPP could be a serious competitor,
because people could use VoIP/ROHC/PPP/ethernet on DSL and Wireless LAN links,
Some people say that wireless LAN will be a serious competitor to 3G.
I'm not in that industry any more; so I can't say.

Is there a procedure whereby linux developers could get an assurance that
they would not be sued for releasing an RFC 3095 implementation?
Or is it simply not possible? Linux developers just don't have any money
for lawyers; so they have to do what they're told!

If it is not possible, then I imagine that linux developers will some day
have to develop their own patent-safe compression protocol for
VoIP over wireless LAN etc. for linux PDAs and laptops etc.
Given the rising popularity of linux PDAs (from a small starting point),
such an alternative could be a competitor to ROHC.
Therefore it might be in the interests of the 3G companies to encourage
widespread adoption of ROHC by _explicitly_ permitting an open source version.

Cheers,
Alan Kennington.

--------------------------------------------------------------------
    name: Dr. Alan Kennington
 website: http://www.topology.org/
    city: Adelaide, South Australia
  coords: 138.59 E, 34.88 S
timezone: UTC+0930 http://www.topology.org/site/timezone.html
 pgp-key: http://www.topology.org/ak/key_ak2.asc
    note: My e-mail address often changes due to spam abuse.
    note: If your e-mail bounces, please visit topology.org/extra/email.php