13 Apr 2009 18:50
2 Sep 2005 14:24
Traffic Selector extension
Markku Savela <msa <at> burp.tkv.asdf.org>
2005-09-02 12:24:29 GMT
2005-09-02 12:24:29 GMT
The list has been pretty quiet on this. Well, I have to implement *something* fast. I need the traffic selector extension and thus, I'm now adding the attached definition to my implementation. I decided on simplest possible structure: a TS extention consists of the extension base and an array of (sadb_selector+addresses) structures. - i will use fixed size for sadb_selector (I use IPv6 format for IPv4 addresses), and thus array size could be found from the extension lenghth. But, I defined 'sadb_ts_numsel' in case variable length elements are used. - I didn't want to "hardcode" the "low,high" by specifying the sadb_ts_numsel as number of pairs. There might be some use in having somekind of "type" field in sadb_selector (for example, the per packet information could be presented by single selector instead of two). - in selector, a negation flag could be considered. I think that the "decorrelation" algorithm, if someone uses it, produces a lot of negated ranges, and having option of just storing the negated range might be useful. This is what I now have, but I'm also open to suggestions for better definitions: ----------------------------------------------------------------- ...(Continue reading)
20 Jul 2005 19:31
Per packet information extension?
Markku Savela <msa <at> burp.tkv.asdf.org>
2005-07-20 17:31:34 GMT
2005-07-20 17:31:34 GMT
rfc2401bis and IKEv2 mention that the addresses and ports of the triggering packet are passed in local and remote selectors as first elements. I find this somewhat inconvenient, and would prefer to pass this part more compactly in a separate extension, containing: - src address - dst address - src port - dst port This is more compact than using TS, because in TS we end up using ranges, and it would take double space.
20 Jul 2005 14:05
local / remote problems with SA
Markku Savela <msa <at> burp.tkv.asdf.org>
2005-07-20 12:05:33 GMT
2005-07-20 12:05:33 GMT
I've tried to prepare for the new Ipsec implementation and I keep bumping into problems that are related to the local/remote vs. src/dst in SA's. My current attempt was to keep src/dst of the SA as is, and use the transport selectors in local/remote style. However, I run into a bit of a compatiblity problem. I need to support old PFKEY with IKEv1, and in there I have a "transport selector" in a form of port and protocol in address extension. The problem is that in the "old" PFKEY there is no indication of the direction of the SA, and I don't know whether the port in DST extesion is supposed to be local or remote. (I course, I could try to make heuristic guess based on the dst address, but it can fail, because not all own addresses are necessarily known when SA is loaded). I'm just sounding off list opinion about possible solutions. I think I have the following choices: 1) use my current mixed model (SA dst/src, transport selectors remote/local) and in IKEv1 mode, make the heuristic guess. 2) go all the way, change SA's also to use remote/local, and in IKEv1 mode, make the heuristic guess. I would probably have new SADB_EXT_ADDRESS_REMOTE and SADB_ADDRESS_LOCAL, which would be used instead of _SRC/_DST by IKEv2), as well as the new transport selectors SADB_EXT_SELECTOR_REMOTE, SADB_EXT_SELECTOR_LOCAL) 3) go all the way to other direction, ignore local/remote in SA's, and(Continue reading)
16 Jun 2005 15:44
Dan on OpenSolaris & PF_KEY
Dan McDonald <danmcd <at> east.sun.com>
2005-06-16 13:44:35 GMT
2005-06-16 13:44:35 GMT
I told you folks that when OpenSolaris became available, you'd have more stuff to look at. My most recent entry at http://blogs.sun.com/danmcd/ has an overview of our implementation. It also has direct links into relevant bits of code. FYI, Dan
14 May 2005 20:05
textual representation
Michael Richardson <mcr <at> sandelman.ottawa.on.ca>
2005-05-14 18:05:48 GMT
2005-05-14 18:05:48 GMT
Does anyone have a textual representation that they like for PFKEY messages? I ask because I've always found that writing textual definitions, feeding them into a text->msg converter, then a msg->text converter, and then looping is a good way to test code and write regression tests. -- -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr <at> xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
8 Mar 2005 16:59
PF_POLICY, the solaris version.
Bill Sommerfeld <sommerfeld <at> sun.com>
2005-03-08 15:59:46 GMT
2005-03-08 15:59:46 GMT
Here are some excerpts from the solaris <net/pfpolicy.h> header file, for purposes of discussion; this header is shipped as part of solaris 9 and later. This describes the format of messages written to and read from a PF_POLICY socket, created via s = socket(SOCK_RAW, PF_POLICY, PF_POLICY_V1); As a disclaimer for folks interested in using this on Solaris: This is considered to be 'project private' interface -- which means that Sun reserves the right to make incompatible changes to it in the future, even as part of bugfixes/patches (for instance, to bring it into compliance with a common version). The high level encoding used here is very similar to PF_KEY; it does change styles significantly to encode actions, however; see the block comment for more details. Writing a draft on this interface has been on my todo list for years. I'm sending this out in the hopes that text generated during the following discussion will form the basis of this draft.... - Bill #define PF_POLICY_V1 1 #define PF_POLICY_REVISION 200304L /* * Base PF_POLICY message header. Each request/response starts with * one of these, followed by some number of extensions. Each(Continue reading)
15 Feb 2005 15:59
pfkey & mobike
Tschofenig Hannes <hannes.tschofenig <at> siemens.com>
2005-02-15 14:59:06 GMT
2005-02-15 14:59:06 GMT
hi all, we have summarized our thoughts on pf-key extensions for mobike into a draft: http://www.tschofenig.com/drafts/draft-schilcher-mobike-pfkey-extension-00.t xt ciao hannes
11 Feb 2005 05:16
PF_KITCHEN_SINK
Bill Sommerfeld <sommerfeld <at> sun.com>
2005-02-11 04:16:23 GMT
2005-02-11 04:16:23 GMT
a couple more extensions: 1) explicit association of matched pairs of inbound and outbound SA's. probably should be handled with any 'direction bit' we add. 2) some form of "SA idle timeout", perhaps intertwined with a "transport layer thinks there's a black hole" notification similar to what path mtu black hole detection calls for. This would be useful for recovery after loss of synchronization. (the former came up in a hallway conversation I had with Tero Kivinen but I don't recall whether it was his idea or mine). 3) explicit active vs. standby marking on SA's. 4) Besides NAT-T, any other mutant encapsulations? 5) enable/disable extended sequence numbers in AH/ESP - Bill
9 Feb 2005 13:37
Re: Traffic selector extension?
Markku Savela <msa <at> burp.tkv.asdf.org>
2005-02-09 12:37:12 GMT
2005-02-09 12:37:12 GMT
> From: Michael Richardson <mcr <at> sandelman.ottawa.on.ca> > No, that doesn't really help to just throw stuff out. > We need to: > a) get a document to ID that duplicates PFKEYv2. > b) remove junk we don't think we need. > c) add new stuff, in some regular format. My starting point is roughly this: - I wish to upgrade the internal structure of the IPSec engine within the protocol stack to use the 2401bis architecture, the major new (for me) issue is: local/remote traffic selectors (I currently have "limited traffic selector" type functionality based on src/dst model). - I cannot control the upgrading of the IKE from v1 to v2, and thus may have to support PFKEYv2 and this new v3 for a SADB that has been upgraded to 2401bis. In the following, I try to identify the problems that PFKEYv2 faces, when applied to 2401bis compatible SADB. First, the general architecture (messages type, there semantics and PFKEY usage) does not need any changes, I'm totally happy with the current system, it should work just fine with 2401bis. But, I'm not precluding interest for new message types, like the "reverse ACQUIRE" mentioned occasionally. The most issues are with the extensions:(Continue reading)
RSS Feed