headers
Markku Savela | 2 Sep 2005 14:24

Traffic Selector extension


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)

Permalink | Reply | 5 comments |
headers
Markku Savela | 2 Sep 2005 14:27

Re: Traffic Selector extension


Oh, and just to clarify: I assume the port numbers are included in the
address structures (sockaddr).
Permalink | Reply | 0 comments |
headers
RJ Atkinson | 3 Sep 2005 17:22
Favicon

Re: Traffic Selector extension


On Sep 2, 2005, at 08:24, Markku Savela wrote:
> 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.

Markku,

     If you read RFC-2367, particularly section 1.7, any private
extensions, such as your proposed extension, need to use the _X_
(or _x_) label in all names, data structures, and such like in order
to ensure portability and interoperability long term.  Further,
doing so is a requirement for compliance/conformance with RFC-2367.

     For example, this means the following changes should be made
to your extension description:
      #define SADB_X_EXT_TS  rather than   #define SADB_EXT_TS
      sadb_x_ts              rather than   sadb_ts
      sadb_x_ts_len          rather than   sadb_ts_len
      sadb_x_ts_numsel       rather than   sadb_ts_numsel
      sadb_x_selector        rather than   sadb_selector
      sadb_x_selector_proto  rather than   sadb_selector_proto
and so forth throughout your proposal.  There are more changes
than I've enumerated, but they should be simple and obvious given
those examples.

Thanks very much,

Ran
rja <at> extremenetworks.com
(Continue reading)

Permalink | Reply | 3 comments |
headers
Markku Savela | 3 Sep 2005 18:27

Re: Traffic Selector extension


> From: RJ Atkinson <rja <at> extremenetworks.com>
> 
>      If you read RFC-2367, particularly section 1.7, any private
> extensions, such as your proposed extension, need to use the _X_ (or
> _x_) label in all names, data structures, and such like in order to
> ensure portability and interoperability long term.  Further, doing
> so is a requirement for compliance/conformance with RFC-2367.

Sigh.. I assumed the purpose of this mailing list discussion was
actually to arrive on some agreed on extension, which would not be
private extension.

I proposed something for discussion. And not to talk just
theoretically, I actually implemented it into my ACQUIRE to check that
I would actually be happy with that solution. It is open to revision,
but at least it conveys the required information.
Permalink | Reply | 2 comments |
headers
RJ Atkinson | 4 Sep 2005 02:16
Favicon

Re: Traffic Selector extension


On Sep 3, 2005, at 12:27, Markku Savela wrote:
>> From: RJ Atkinson <rja <at> extremenetworks.com>
>>
>>      If you read RFC-2367, particularly section 1.7, any private
>> extensions, such as your proposed extension, need to use the _X_ (or
>> _x_) label in all names, data structures, and such like in order to
>> ensure portability and interoperability long term.  Further, doing
>> so is a requirement for compliance/conformance with RFC-2367.
>
> Sigh.. I assumed the purpose of this mailing list discussion was
> actually to arrive on some agreed on extension, which would not be
> private extension.

RFC-2367 says the authors of RFC-2367 need to agree before anything
becomes anything other than a private extension.  The API is not
an IETF spec, as has been discussed here before, nor is the API
subject to any IETF working group or other committee.  (And kindly
recall that I am *not* one of the authors of RFC-2367 myself,
so I don't get a vote under the rules of RFC-2367. :-)

(Aside: I've never grasped why the list migrated.  Craig Metz made
it quite clear that he was happy to continue to have the list at the
original address if folks found that useful.  So far as I know,
that remains his position.  That's neither here nor there for this
thread. :-)

> I proposed something for discussion. And not to talk just
> theoretically, I actually implemented it into my ACQUIRE to check that
> I would actually be happy with that solution. It is open to revision,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Markku Savela | 5 Sep 2005 10:29

Re: Traffic Selector extension


> From: RJ Atkinson <rja <at> extremenetworks.com>

> (Aside: I've never grasped why the list migrated.  Craig Metz made
> it quite clear that he was happy to continue to have the list at the
> original address if folks found that useful.  So far as I know,
> that remains his position.

Establishing a new list was a bit hastily done, I agree. But, the old
list was not working (and still isn't). I believe some effort or
queries were made, but nothing happened in few weeks, so discussion
started here instead.

> Maybe I misunderstood your meaning; your note sounded like you
> were talking about a local extension rather than an initial proposal
> that was open to discussion and (hypothetically, at least) change
> by others.  The words that led me to that (perhaps erroneous)
> understanding were these (particularly the emphasis on your
> lack of time to discuss here before implementation):
> 
>      "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."

Of course, I also have to implement something. Otherwise I wouldn't be
discussing about it here. I'm very "satisfied customer" of the
original, *unmodified* (= without any private extensions) PFKEY RFC,
and exactly because of that, and respect for the original authors, is
the reason for this discusion. I want to have the good RFC
improved. Otherwise, I could always just gone and made my own changes
(Continue reading)

Permalink | Reply | 0 comments |

Gmane