Project

General

Profile

Bug #98

Lower-bound in traffic selector not computed

Added by Eric Mertens almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
charon
Target version:
Start date:
17.11.2009
Due date:
Estimated time:
Affected version:
5.7.1
Resolution:

Description

Charon does not set the host number to zero when computing a traffic selector range resulting in a potentially unexpected proposal.

I have attached the fix below.

History

#1 Updated by Martin Willi almost 9 years ago

  • Category set to charon
  • Status changed from New to Feedback

Thanks for your patch.

However, it is not really clear to me what's the benefit of zeroing the from address. If I understand correctly, this will have an effect only if an invalid subnet is configured.

If you configure an invalid 10.2.128.0/16, we get a 10.2.128.0 - 10.2.255.255 range (10.2.128.0/17 actually). Your patch changes this to a 10.2.0.0 - 10.2.255.255. I think it is better to catch this user input error by the more restrictive variant, the one that is currently implemented.

Or are there any other cases I have missed?

#2 Updated by Eric Mertens almost 9 years ago

Martin Willi wrote:

Thanks for your patch.
However, it is not really clear to me what's the benefit of zeroing the from address. If I understand correctly, this will have an effect only if an invalid subnet is configured.

The benefit is simply a more reasonable behavior. If the user uses their local address, for example, instead of the network address, then they will get a likely unexpected traffic selector transmitted on their behalf.

It is not uncommon to use an IP address without a zeroed host number in system configuration, for example:

ip addr add 192.168.0.1/24 brd + dev eth0

So it isn't unexpected that a user might expect this to work.

If you configure an invalid 10.2.128.0/16, we get a 10.2.128.0 - 10.2.255.255 range (10.2.128.0/17 actually). Your patch changes this to a 10.2.0.0 - 10.2.255.255. I think it is better to catch this user input error by the more restrictive variant, the one that is currently implemented.

The alternative of an error message at configuration time seem like a reasonable solution as well.

I think that the more restrictive, but completely unexpected result is not ideal. This simply exposes assumptions made in the implementation. As you have noted on IRC, Linux does not support arbitrary IP address ranges. How does this deal with 192.168.0.3/24, with a kernel error message? This case won't map onto some other subnet definition. If the goal is to support arbitrary ranges, then a format allowing the user to provide an arbitrary upper-bound would be needed.

There is no precedent for a network application treating 10.2.128.0/28 as identical to 10.2.128.0/27.

If this behavior was left unchanged, it seems like a warning message explaining when the subnet is not starting at the lower-bound should be issued at configuration time.

Or are there any other cases I have missed?

I think that that covers it.

#3 Updated by Martin Willi almost 9 years ago

  • Status changed from Feedback to Closed
  • Target version set to 4.3.6

ip addr add 192.168.0.1/24 brd + dev eth0

I think this is something completely different. Using this notation, you define an address and an associated netmask. But in ipsec.conf, users configure subnets, not addresses.

If this behavior was left unchanged, it seems like a warning message explaining when the subnet is not starting at the lower-bound should be issued at configuration time.

Issuing a warning is another option, but I don't think it's worth the effort. As I personally don't really care how to handle such an address + netmask (mis-)configuration, I'll push the patch for now.

Also available in: Atom PDF