[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

So we're having IP datagrams with the IP addresses of the devices, not the
final destinations, and a header which isn't decoded right.

We can only conclude that the protocol is working in tunnel mode. This
means an IP tunnel is established between the devices, and the payload
contains the actual IP datagrams to be passed back and forth between the
two networks connected to the devices. It's a typical VPN solution in this
way. Big chance there's AH or ESP headers in there as well, messing up our
dissection.
Googling for "tunnel mode IPComp" and looking over the vpnc.org website
didn't lead to a clear example, though. :/

Thanx,
Jaap

On Mon, 26 Dec 2005, J. Holmes wrote:

> Jaap,
>
>         The cisco pkts in the trace I sent would be from the Cisco switch
> that is part of the setup. The units that do the IPCOMP compression /
> decompression are not Cisco units.
>
> Clearly there is no IPv6 here. So my guess is that either :
> 1. These IPCOMP boxes don't strictly follow the IETF's standard which is
>     why its messing up the Ethereal's IPCOMP dissector.
> 2. There might be an error in the dissector itself. If I'm reading the RFC
>     correctly, for IPv4 pkts, it should the IPCOMP header should includes
>     the "protocol" field from the IP header. The IPv6 next-hop is only for
>     IPv6 networks.
>
> Finally, I still cannot for the life of me figure out how pkts can reach
> their destination, when the destination IP address is the remote IPCOMP
> unit. Can someone please explain this one ?
>
> Thanks !
>
> JH
>
> On 12/25/05, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> > This is what I get on the first packet (the others are similar)
> >
> > IP Payload Compression
> >     Next Header: IPv6 hop-by-hop option (0x00)
> >     Flags: 0x46
> >     CPI: Unknown (0x01cc)
> >     Data (574 bytes)
> >
> > So, there's IPv6 in the game??
> > Why is flags != 0? According to the RFC it has to be 0.
> > Why is the CPI changing with every packet?
> >
> > I guess this is some sort of Cisco proprietary tunnel protocol
> > using IPcomp.
> >
> > Thanx,
> > Jaap
> >
> >
> > On Sat, 24 Dec 2005, J. Holmes wrote:
> >
> > > Jaap,
> > >
> > > Thanks for the reply. I've attached the IPCOMP trace. The IP addresses
> > > 10.1.1.9 and 20.1.1.9 are the IP addresses of the units that do IPCOMP
> > > compression. The ftp client and server IP addresses are 10.1.1.2/24 and
> > > 20.1.1.8/24 if I remember correctly.
> > >
> > > Now I understand that there's got to be some way to inform pkts that
> > have
> > > been compressed, that they need to go to the remote IPCOMP unit to be
> > > decompressed before going off to their destination.
> > >
> > > How this is done when you have only the destination IP address as the
> > > remote IPCOMP unit, I have no clue.
> > >
> > > On 12/24/05, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> > > >
> > > > On Sat, 24 Dec 2005, J. Holmes wrote:
> > > >
> > > > > Hi all -
> > > > >
> > > > >          Firstly, this isn't an Ethereal question per se. Its an
> > > > observation
> > > > > I made
> > > > > when using Ethereal. However, I'm certain that there are some
> > networking
> > > > > protocol gurus (Guy and co.) that can explain some of these
> > questions.
> > > > >
> > > > >  I have a simple setup with two boxes that do IPCOMP
> > > > > compression connected as in th ASCII diagram below :
> > > > >
> > > > >  LAN a -- CPR --- router --(simulated WAN)--- router -- hub -- CPR
> > --
> > > > LAN b
> > > > >
> > > > > I did an FTP transfer from a PC in LAN a to a PC in Lan b. Now when
> > I
> > > > sniffed the
> > > > > IPCOMP pkts using Ethereal, I found that the source and destination
> > IP
> > > > addresses
> > > > > had changed to the local and remote IPCOMP compression units' IP
> > > > addresses
> > > > > respectively.
> > > > >
> > > > > I'm confused.
> > > > >
> > > > > 1. How does the remote IPCOMP compression unit know whom to send
> > > > >     the pkts to ? (Given that the dest. IP address is the remote
> > IPCOMP
> > > > >     decompressor, and not the original destination -- the FTP
> > > > >     server/client).
> > > > > 2. The RFC doesn't indicate that the source or destination IP
> > address
> > > > should
> > > > >     be changed. What am I not understanding here ?
> > > >
> > > > Both are strange indeed. Maybe you can post a small sample trace for
> > > > everyone to look at.
> > > >
> > > > > 3. The header for the IPCOMP includes the protocol field from the IP
> > > > header.
> > > > >     Why would you have the protocol field from the IP header. This
> > part
> > > > of
> > > > >     the IP header is left intact, and not compressed. Isn't this
> > > > redundant ?
> > > >
> > > > If you look closely you find that in the IP header TCP (6) is replaced
> > by
> > > > IPComp (108). The RFC says that the transform looks like this:
> > > >
> > > >   IPv4-Header Payload  -->
> > > >
> > > >             IPv4-Header IPComp-Header Compressed(Payload) -->
> > > >
> > > >                         IPv4-Header Payload
> > > >
> > > >
> > > > Now in order get to the Compressed(Payload) the outer header (in this
> > case
> > > > IPv4) needs to indicate the next level protocol, which is IPComp. The
> > > > IPComp header need to indicate what protocol the payload is carrying
> > so
> > > > it can put that into the reconstructed IPv4 Header
> > > >
> > > > > Many thanks for any replies.
> > > >
> > > > Hope it helps
> > > > Jaap
> > > >
> >
> > _______________________________________________
> > Ethereal-users mailing list
> > Ethereal-users@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-users
> >
>