|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: linux-ipsec: apps/utils/libs that parse IP/netbits
Date: Sun Jul 19 1998 - 17:34:31 EDT
| From: Henry Spencer <henry@spsystems.net>
|
| Skipping minor stylistic issues and "oops, I should fix that" things...
I don't like using such a general name for a specific facility.
The way I code, NULL looks ok:
{
const char *ugh = atosubnet(...);
if (ugh != NULL)
{
/* handle error */
}
}
In other words, the name of the variable suggests that it holds a diagnostic. Testing a diagnostic for being NULL is easy to understand: no diagnostic => no error.
| > - The code for parsing a dotted quad or hostname appears twice. And
Great! Please design it to accept the length/string-pointer form (I don't want to have to pass a NUL-terminated string). If you do this, I think that it becomes natural to make atoaddrmask non-destructive.
Speaking of which, can we come up with boilerplate that does the job without taking the first screen's worth of every file?
| From: Henry Spencer <henry@spsystems.net>
| Subject: linux-ipsec: address-range syntax (was apps/utils/libs that parse...)
|
| > - Pluto needs to deal with IP address ranges in the same places it
My slight favourite is "..". I don't think that .. is legal in domain names. It may be legal in dotted quads (I don't know), but we don't have to allow it and we should not (just as we don't allow fewer than 3 dots).
BTW, consider this a request to diagnose empty numbers in dotted quads.
"//" works nicely for parsing, but I don't much care for it.
I rather hope that the some routine you write will recognize and accept either a range or subnet, and tell the caller (eg. Pluto) which it found. Actually, range is more general, so perhaps always returning a range is OK.
I think that it would be worth capturing all of the syntactic details of addresses, ranges, and subnets in the library. For one thing, we could change the syntax just by changing the library. This means that the library sould have some facility for tokenizing.
| From: Hugh Daniel <hugh@road.toad.com>
|
| >- Pluto needs to deal with IP address ranges in the same places it
The drafts require IP address ranges.
In the arch document, draft-ietf-ipsec-arch-sec-05.txt, 4.4.1, the SPD can use a range of IP addresses as a selector. A sample extract:
For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10). ...
That example cannot be represented as a subnet.
In section 4.4.2 (Selectors):
- Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), a range of addresses (high and low values (inclusive), address + mask, or a wildcard address. ...
- Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address. ...
The following table summarizes the kinds of entries that one needs to be able to express in the SPD and SAD. It shows how they relate to the fields in data traffic being subjected to IPsec screening. (Note: the "wild" or "wildcard" entry for src and dst addresses includes a mask, range, etc.)
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
dst addr single IP addr single,range,wild single,range,wildcard
xpt protocol* xpt protocol single,wildcard single,wildcard
src port* single src port single,wildcard single,wildcard
dst port* single dst port single,wildcard single,wildcard
user id* single user id single,wildcard single,wildcard
sec. labels single value single,wildcard single,wildcard
* The SAD and SPD entries for these fields could be "OPAQUE"
because the traffic value is encrypted.
Later it says that even the SAD needs to support ranges (obviously).
draft-ietf-ipsec-isakmp-09.txt A.4 describes "ISAKMP Identification Type Values". The only ranges supported are subnets.
draft-ietf-ipsec-ipsec-doi-09.txt 4.6.2 describes "Identification Payload Content" (in the IPSec Domain of interpretation):
4.6.2.8 ID_IPV4_ADDR_RANGE
The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list.
Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253
Received on Sun Jul 19 18:10:37 1998
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 12:59:24 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |