Subject: Doubt about ECP and CCP

From: "manoj juneja" <[email-masked]>
Date: Thu, 05 Dec 2002 17:41:10 -0700

Hi All,
        Can anyone please explain the format of a PPP data packet that is 
both compressed and encrypted ?

Also, if compression/encryption is enabled/negotitation then is it mandatory 
to use it for each data packet ?

If both encryption and compression are enabled/negotiated then is it 
possible to send a data packet that is encrypted and not compressed ?

Thanks in Advance,

Regards,
manoj.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

---

From: Frank Cusack <[email-masked]>
Date: Tue, 24 Dec 2002 17:42:20 -0800

> both compressed and encrypted ?

For IP, just encrypted:

0x0053 (encrypted datagram) | ... (encryption header) | ->
    0x0021 (IP datagram) | ... (IP data)

and compressed:

0x0053 (encrypted datagram) | ... (encryption header) | ->
    0x00fd (compressed datagram) | ... (compression header) | ->
    0x21 (IP datagram) | ... (IP data)

Of course, everything past the encryption header isn't actually visible
as such until decryption, and likewise for compression.

> to use it for each data packet ?

No, but an implementation can enforce this.  The receiver can only enforce
this after the fact, of course (dropping the link upon reception of a
non-encrypted/compressed packet).

> possible to send a data packet that is encrypted and not compressed ?

Sure, but again an implementation can enforce both.

/fc

---

From: Frank Cusack <[email-masked]>
Date: Tue, 24 Dec 2002 22:04:44 -0800

> Sure, but again an implementation can enforce both.

Actually, not.  If you look at RFC 1979 (deflate) and others, you'll
see that special handling has to be done when receiving non-compressed
packets.  After negotiating compression, all packets are implicitly
considered to have passed through the compressor.

This doesn't seem to be the case for the ECP protocols.

/fc

---

From: James Carlson <[email-masked]>
Date: Fri, 27 Dec 2002 10:06:39 -0500

> considered to have passed through the compressor.

I liked your earlier message better.  ;-}

What you say is true of a few of the algorithms -- including Deflate
and BSD Compress, though, notably, not STAC LZS (which requires a
history reset in the 'standard' modes, and bit C=0 for extended mode).
However, when it is true, the sender can decline to compress any
particular packet he chooses as long as he updates his dictionary as
required (or reinitializes CCP itself).

So, if what the original poster wants is confirmation that all packets
sent *always* have compressed data in them, I don't think that can be
given.

> This doesn't seem to be the case for the ECP protocols.

The rules are a little different there, since expansion over the MTU
is 'supposed' to be handled by using MP.  What RFC 1968 does say is
this:

         An implementation MUST NOT transmit data until ECP negotiation
         has completed successfully.  If ECP negotiation is not
         successful the link SHOULD be brought down.

I think a reasonable interpretation of that statement (and the
security context) is that network data also must not be sent
unencrypted once ECP is up.  It doesn't actually come out and say
that, though, nor do 2419 and 2420.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677