Bug 68066 - CIPE update to 1.5.4
Summary: CIPE update to 1.5.4
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: cipe
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: David Lawrence
URL:
Whiteboard:
: 75754 78238 (view as bug list)
Depends On:
Blocks: 67218 78238 79579 CambridgeTarget
TreeView+ depends on / blocked
 
Reported: 2002-07-06 01:18 UTC by Muralidhar Ganga
Modified: 2007-04-18 16:43 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-04 22:36:35 UTC
Embargoed:


Attachments (Terms of Use)
Patch to add cipe v3 tree (124.37 KB, patch)
2003-07-25 15:40 UTC, Tom "spot" Callaway
no flags Details | Diff
Patch to add cipe4 support (124.37 KB, patch)
2003-07-25 15:41 UTC, Tom "spot" Callaway
no flags Details | Diff
Fixed version of Patch10010 for cipe3/cipe4 split. (27.35 KB, patch)
2003-07-25 16:23 UTC, Tom "spot" Callaway
no flags Details | Diff
This is a fixed version of Patch5000, to reflect the cipe3/cipe4 split. (3.43 KB, patch)
2003-07-25 16:24 UTC, Tom "spot" Callaway
no flags Details | Diff

Description Muralidhar Ganga 2002-07-06 01:18:43 UTC
Description of Problem:
CIPE needs to be updated to the latest 1.5.4. 
Many fixes have been made since 1.4.6.

Version-Release number of selected component (if applicable):


How Reproducible:


Steps to Reproduce:
1. 
2. 
3. 

Actual Results:


Expected Results:


Additional Information:

Comment 1 Muralidhar Ganga 2002-07-06 01:22:06 UTC
http://sites.inka.de/sites/bigred/devel/cipe.html

Comment 2 Chris Ricker 2002-08-09 20:27:38 UTC
I'd second this.  CIPE 1.5.4 is the current stable release, and it includes lots
of useful features which aren't in the old 1.4 series.  pkcipe makes usage of
cipe with dynamic IP addresses much simpler and more secure (uses public key
exchange to authenticate and then configure each tunnel end, rather than
configuration based on IP addresses of the tunnel ends).  1.5.4 supports native
IPv6; I've never gotten CIPE 1.4 to do IPv6 tunnels.  There are also some more
esoteric changes (1.5 supports ethernet bridging, for example) that are less
likely to be useful, but at least pkcipe and IPv6 are essential for some of my hosts

Comment 3 James Ralston 2002-12-04 22:29:17 UTC
It's been almost 5 months since this RFE was opened, and cipe 1.5.4 isn't even
in Rawhide.

Could we *please* at least have a status update?  I mean, if there's a blocker
here, or something else which would make moving to 1.5.4 difficult, at least let
people know; just don't let the bug sit at status NEW (with no comments from the
assignee) for 5 months...

If you need motivation, note that Red Hat gets regularly bashed on the cipe-l
mailing list for still shipping cipe 1.4.5.  :p


Comment 4 Eric Hopper 2002-12-05 03:03:35 UTC
I third or fourth this.  CIPE is an immensely useful tool, and it would be even
more useful if it supported IPv6.  I really could care less about the somewhat
more sophisticated key management allowed by pkcipe, but the other features
(including some security enhancements) would be most welcome.


Comment 5 Chris Ricker 2002-12-13 18:07:17 UTC
*** Bug 78238 has been marked as a duplicate of this bug. ***

Comment 6 Aleksey Nogin 2002-12-13 19:56:23 UTC
*** Bug 75754 has been marked as a duplicate of this bug. ***

Comment 7 Muralidhar Ganga 2002-12-17 18:18:06 UTC
This bug needs to be assigned to the right person, whoever is working with cipe
to get the latest. 

Anyone know whom to be assign ? 

Comment 8 James Ralston 2003-01-20 06:16:23 UTC
Argh.  Phoebe (at least the first revision) still contains cipe-1.4.5!

I repeat my previous request for a status update.  Nalin, could you please at
least acknowledge that *someone* at Red Hat is aware of this bug?


Comment 9 Ted Kaczmarek 2003-02-24 02:22:33 UTC
Free drinks and grog for Nalin in NY area on me if we get 1.5.4 soon.

Comment 10 Mike A. Harris 2003-03-05 11:47:31 UTC
I've asked a few people about this, and they believe that cipe 1.5.x
contains changes that break the ABI used in 1.4.  If this is true (which
I have not had a chance to verify), then it would mean clients using 1.4
which connect to a 1.5 server, or vice versa would be incompatible with
each other.

Perhaps we can investigate if the ABI is indeed broken or not with respect
to cipe 1.4 in the new version.  If this would be an incompatible change,
perhaps we can consider backporting bug fixes and improvements.

Do any of you know of specific improvements and/or features the new release
brings off hand?  If you could itemize some of the important things, it
might help prioritize investigation of what might be needed if we were to
consider a backport.



Comment 11 Chris Ricker 2003-03-05 15:18:25 UTC
I can't speak for the other ~10 people who've been requesting this, but for me
CIPE 1.5.x is required in many situations because:

1. It supports IPv6, and 1.4.x doesn't. I've never gotten 1.4.x to do reliable
IPv6 tunnels, and I don't think it's even supposed to support them. v6 Just
Works with 1.5.x

2. 1.5.x supports what it calls PKCIPE -- certificate-based authentication of
the two ends to each other. 1.4.x only supports shared-private-key + IP address
as authentication. PKCIPE probably has security advantages (migration from
shared private key to certificate schemes usually does) but more importantly, it
makes CIPE usable with dynamic IPs, or with NAT, in configurations where CIPE
1.4.x simply will not work. PKCIPE can be used if both ends are dynamic; CIPE
1.4.x requires one end to be static. PKCIPE conceptually should be usable if
both ends are NAT'ed, while CIPE 1.4.x would fail, I would think (the "both ends
NAT'ed" is not a configuration I've personally needed to deal with, so that one
I've not personally verified. The "both ends dynamic IP" I have...)

Those are the two reasons which matter to me, or to clients of mine. The IPv6
support matters most for me, but I'd guess that for most Red Hat customers the
PKCIPE support is probably more useful.... My clients who've had to upgrade have
mostly needed 1.5.x for PKCIPE, though a couple have needed v6.

A couple of other factors which might also matter to some:

3. CIPE 1.5.x supports Ethernet bridging over CIPE, while 1.4.x doesn't. I don't
currently use / need this, but others might.

4. CIPE 1.4.x is no longer supported upstream. Questions, bug reports, etc., are
greeted with an "upgrade and then we'll talk" response.


I'm a little confused by your talk about ABI changing. I'm not sure why you'd
care if the ABI changed. Upgrading the kernel driver to 1.5.x CIPE will require
the CIPE userland upgrade as well, but I don't see that as being any different
than, say, XFree86 requiring specific DRI from the kernel. If RHL upgrades both
the driver and the userland, then installs still work....

I'd think what matters is if the CIPE network protocol has changed, meaning that
1.4.x clients can't talk to 1.5.x servers or vice-versa. CIPE 1.5.x does add a
new version of the network protocol, but I think it still supports the old
version. I can double-check that in a few hours to see if 1.5.x clients can
connect with 1.4.x servers and vice-versa.

Comment 12 Mike A. Harris 2003-03-05 15:53:02 UTC
I'm neither the cipe maintainer, userland side nor kernel side, but I'm
responding with my own thoughts, since you did request that someone respond
on the mailing list.

Several of the points you bring up are perhaps useful, at least to some
small portion of the Red Hat userbase likely.  I don't believe that they
are necessarily generally useful to the majority of users though, so
upgrading cipe in a future release is likely to be frowned upon if complete
compatibility can't be maintained.  I suspect that this is the reason it
has not been done so far, however I don't have any direct communication
of that.

>I'm a little confused by your talk about ABI changing. I'm not sure why you'd
>care if the ABI changed. Upgrading the kernel driver to 1.5.x CIPE will require
>the CIPE userland upgrade as well, but I don't see that as being any different
>than, say, XFree86 requiring specific DRI from the kernel. If RHL upgrades both
>the driver and the userland, then installs still work....

That is a question that arjan and/or nalin would have to answer.  It
would be possible to make the kernel packages Require: cipe >= 1.5
or whatever to enforce the update of the cipe package in a new release.
This may cause problems however if a cipe interface is actually being
used when the upgrade occurs.  The new utilities would likely be expected
by us to be able to bring a 1.4 interface down, which might be running
after the update (or during it), however that would only likely be a
requirement if it was for an erratum release.  Again, I can not comment
authoritatively on this though.  Just giving my opinion based on knowledge
of our general policies on things.

>I'd think what matters is if the CIPE network protocol has changed, meaning
>that 1.4.x clients can't talk to 1.5.x servers or vice-versa. CIPE 1.5.x
>does add a new version of the network protocol, but I think it still
>supports the old version. I can double-check that in a few hours to see if
>1.5.x clients can connect with 1.4.x servers and vice-versa.

If 1.5.x and 1.4.x can not communicate freely in both directions in every
combination, I'm almost 100% certain that we would never consider upgrading
cipe, as it would break existing working setups for people, or would require
everyone upgrade all systems wether they want to or not.

If we couldn't make the change cleanly, it is at least theoretically
possible that if there is large enough customer demand, we could
consider backporting safe fixes and feature enhancements that do not
break compatibility.  If not, we also offer consulting engineering
services that customers can use to affect product priorities, etc.

Anyhow, this is all a lot of speculation on my part for now.  If you find
out about the compatibility issues, please update the report, and I will
have a peek myself into it, and chat with other developers.

Hope this helps.





Comment 13 Chris Ricker 2003-03-05 18:08:40 UTC
There are a few versions of the CIPE protocol. The default for 1.5.4 is version
3, which is the
same version as in 1.4.x. 1.5.4 compiled with version 3 (./configure
--enable-protocol=3, or just accept defaults) is interacting with RHL 8.0 just fine.

I'm not sure what happens with --enable-protocol=4 (on 1.5.4) interacting with
the 1.4.x version in RHL 8.0.  I'll try to test that as well, but that'll
probably be a couple of days.

There have been interoperability issues between CIPE versions, but they were
early in the CIPE release history, and they were caused by changes in the key
format, not by protocol changes.... 1.4.0 and later are all fine in terms of key
exchange, AFAIK.

FWIW, I was not expecting this to be resolved by an errata. This sort of change
should be done
with a new release of RHL (such as the upcoming one ;-), which at least removes
the complexity of worrying about ABI compatibility.



Comment 14 Olaf Titz 2003-03-06 20:15:17 UTC
A word from the CIPE author: comment 11 is right. CIPE 1.5 is compatible with
1.4 on the wire if configured for protocol 3. (To use features like Ethernet
bridging you need protocol 4, which is incompatible[*].) The ABI between kernel
and user part is not compatible but that doesn't matter, as nothing but ciped
uses it.
In short: an upgrade should not break anything.

[*] but you can run both versions in parallel.


Comment 15 Mike A. Harris 2003-03-07 06:12:02 UTC
Thanks Olaf.  That should provide our engineers with enough information
IMHO to decide wether or not we should update to cipe 1.5.x in a future
OS release.

If nobody responds further here in this enhancement request, don't assume
that nobody has read it.  It is safe to assume that the feature request is
still open to consideration, but no sense in updating this report until
it is decided to make the update.  Until then, consider it to be up for
future consideration.

Hope this helps.

Comment 16 Michael Haun 2003-04-19 15:33:18 UTC
with ./configure --enable-protocol=4 both version 3 and 4 are in the code.  
the actual binary is split into two seperate executables and modules. Protocol 
3 uses the same ciped-cb deamon/cipcb module and protocol 4 uses ciped-db 
deamon/cipdb module.

I have existing tunnels working with 1.4 and 1.5 and new tunnels working with 
other 1.5 at the same time.

Comment 17 Daniel Roesen 2003-04-24 06:26:17 UTC
I would also like to see an upgrade, as I'm currently setting up a CIPE
VPN (using RHL9) and being unable to route IPv6 over it... need to embed
GRE tunnels within the VPN. Tunnels in Tunnels... :-/

Comment 18 Tom "spot" Callaway 2003-07-25 15:38:08 UTC
Kernel patches against 2.4.22-pre7 attached to this bug entry. This provide
cleaned up versions of cipe 1.5.4 with all relevant Red Hat cipe patches from
1.4.6 applied (and VERSION_MAGIC check removed).

Comment 19 Tom "spot" Callaway 2003-07-25 15:40:00 UTC
Created attachment 93149 [details]
Patch to add cipe v3 tree

This patch adds a source tree for cipe protocol 3, version 1.5.4, with Red Hat
patches and VERSION_MAGIC check removed. Use CONFIG_CIPE3=m to build the module
from this tree.

Comment 20 Tom "spot" Callaway 2003-07-25 15:41:52 UTC
Created attachment 93150 [details]
Patch to add cipe4 support

This patch adds a source tree for cipe protocol 4, version 1.5.4, with Red Hat
patches included and VERSION_MAGIC check removed. Use CONFIG_CIPE4=m to build
the module from this tree.

Comment 21 Tom "spot" Callaway 2003-07-25 16:23:38 UTC
Created attachment 93151 [details]
Fixed version of Patch10010 for cipe3/cipe4 split.

This is a fixed version of Patch10010 to reflect the new cipe patchset.

Comment 22 Tom "spot" Callaway 2003-07-25 16:24:39 UTC
Created attachment 93152 [details]
This is a fixed version of Patch5000, to reflect the cipe3/cipe4 split.

This is a fixed version of Patch5000, to go with the new cipe 1.5.4 patchset.

Comment 23 Daniel Roesen 2005-06-04 22:36:35 UTC
cipe is neither in RHEL nor Fedora anymore, so I guess this case can be
closed now. It's beating a dead horse.


Note You need to log in before you can comment on or make changes to this bug.