> => this is like playing with UIDs, which are in the context of the
> application and can be set by set[e]uid() & co, to permit or deny access to
> privileged ports. My idea is to tune the context before performing some
> operations and to reset it after to its previous setup.
While the semantics
(In this reply, I'm very specific to the BSD kernel, which may not be
appropriate in this list. If the discussion continues on this
particular topic, I'll change the place.)
> On Sun, 23 Mar 2003 22:46:51 +0100,
> Francis Dupont <[EMAIL PROTECTED]> said:
>> => I have a major concer
In your previous mail you wrote:
> => what I propose is not pure per-process control, it is to put the
> control in the context of processes. It gives immediatly a per-process
> control but with a way to manage the context from applications, it gives
> a per-socket control too.
> => what I propose is not pure per-process control, it is to put the
> control in the context of processes. It gives immediatly a per-process
> control but with a way to manage the context from applications, it gives
> a per-socket control too.
Francis,
I didn't understand how the per-process co
In your previous mail you wrote:
The goal of that API is to provide a simple way to manage socket level
preference.
=> my concern is your goal is to fulfill a requirement from developpers
than my goal is to fulfill a similar requirement from users. As there
are far more users than develop
Francis Dupont wrote:
> In your previous mail you wrote:
>>and it can also satisfy per process behavior.
>>
>> => this is not true: I don't want to patch and recompile all
>> applications. My concern is you provide a device then look for its
>> usage, I prefer to get requir
In your previous mail you wrote:
>and it can also satisfy per process behavior.
>
> => this is not true: I don't want to patch and recompile all applications.
> My concern is you provide a device then look for its usage, I prefer to
> get requirements and only after look fo
arti;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [mobile-ip] Draft on IPv6 source address
> selection socket API
>
>
> > On CGA. It is different now. We face mass deployment of required
> > security worldwide and I hear it all the t
> On CGA. It is different now. We face mass deployment of required security
> worldwide and I hear it all the time now. CGA being a base for our
> addresses is far different scope of use than RSA mumbo-jumbo et al. The IPR
> is a real problem and I think a show stopper. There can be no vendor
>
ilto:[EMAIL PROTECTED]
>Sent: Friday, March 21, 2003 11:52 AM
>To: Francis Dupont
>Cc: Samita Chakrabarti; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: [mobile-ip] Draft on IPv6 source address
>selection socket API
>
>
>>
>
>and it can also satisfy per process behavior.
>
> => this is not true: I don't want to patch and recompile all applications.
> My concern is you provide a device then look for its usage, I prefer to
> get requirements and only after look for ways to satify them.
>
I assume these so
In your previous mail you wrote:
> On Fri, 21 Mar 2003 00:39:12 +0100,
> Francis Dupont <[EMAIL PROTECTED]> said:
>A draft has been submitted to address source address selection at
>the per-socket (and per apps) basis. Currently it discusses preferences
>of
> On Fri, 21 Mar 2003 00:39:12 +0100,
> Francis Dupont <[EMAIL PROTECTED]> said:
>A draft has been submitted to address source address selection at
>the per-socket (and per apps) basis. Currently it discusses preferences
>of source address selection by the application for priv
In your previous mail you wrote:
As Erik explained before, having per-socket knob provides better control
on the implementation pieces
=> no, it gives the same kind of control, and only in modified pieces
of code.
and it can also satisfy per process behavior.
=> this is not true: I
>context. How do you handle the case of an application which have several
>threads of execution trying to modify a single context in a
>contradictory way (e.g. TMP vs PUB, etc.) ?
>
> => this is an implementation problem: there are a lot of possible
> solutions: use a lock, use a
> Section 4
> > The above flags are ignored for the AF_INET address family. If a
> > returned address is an IPv4 address (either as AF_INET6 when
> > AI_V4MAPPED, or as AF_INET) then the source preference flags have
> > no effect.
>
> If someone implements Mobile IPv4, wouldn't the HOME/COA flag
> [EMAIL PROTECTED] said:
> > >> I don't understand how can flags to getaddrinfo(3) affect source
> > >> address selection. where does it take effect in the following code?
> > >getaddrinfo implementation itself? of course, then libc would have to
> > >aware of src addresses and such..
> >
In your previous mail you wrote:
BTW, I am a bit concerned about applications that need to modify their own
context. How do you handle the case of an application which have several
threads of execution trying to modify a single context in a
contradictory way (e.g. TMP vs PUB, etc.)
In your previous mail you wrote:
>The following flags are added for the ai_flags in addrinfo data
>structure defined in Basic IPv6 Socket API Extension [2].
>
> AI_PREFER_SRC_HOME
> AI_PREFER_SRC_COA
> AI_PREFER_SRC_TMP
> AI
[EMAIL PROTECTED] said:
> >>I don't understand how can flags to getaddrinfo(3) affect source
> >>address selection. where does it take effect in the following code?
> >getaddrinfo implementation itself? of course, then libc would have to
> >aware of src addresses and such..
>
> ge
In your previous mail you wrote:
> What I propose is to put the policy in the context of applications
> (Unix user structure, environment, etc, even monitors have this kind
> of things) so one can tune the address selection before launching
> applications. When the context can be mana
> Some details:
>
>..., CGA (cryptographically
>generated addresses) and non-CGA addresses etc..
>
> => you should note that CGAs are covered by some IPRs.
While I'm concerned about IPR and the IPR on CGA, I don't see
the benefit of cluttering every document and sli
>> I don't understand how can flags to getaddrinfo(3) affect source
>> address selection. where does it take effect in the following code?
>getaddrinfo implementation itself? of course, then libc would have to
>aware of src addresses and such..
getaddrinfo(3) does not open soc
On Sat, 22 Mar 2003 [EMAIL PROTECTED] wrote:
> >> The following flags are added for the ai_flags in addrinfo data
> >> structure defined in Basic IPv6 Socket API Extension [2].
> >>
> >>AI_PREFER_SRC_HOME
> >>AI_PREFER_SRC_COA
> >>AI_PREFER_SRC_TMP
> >>
>> The following flags are added for the ai_flags in addrinfo data
>> structure defined in Basic IPv6 Socket API Extension [2].
>>
>>AI_PREFER_SRC_HOME
>>AI_PREFER_SRC_COA
>>AI_PREFER_SRC_TMP
>>AI_PREFER_SRC_PUBLIC
>>AI_PREFER_SRC_CGA
>>
> What I propose is to put the policy in the context of applications
> (Unix user structure, environment, etc, even monitors have this kind
> of things) so one can tune the address selection before launching
> applications. When the context can be managed from applications
> (the usual case), this
In your previous mail you wrote:
Le Vendredi 21 Mars 2003 00:39, Francis Dupont a écrit :
=> you should avoid French in this list (:-).
It is expected that most applications should work fine without tuning the
=> this is exactly the assumption I strongly disagree with.
source addres
Some details:
..., CGA (cryptographically
generated addresses) and non-CGA addresses etc..
=> you should note that CGAs are covered by some IPRs.
It is recommended that the application does a getsockopt() prior
=> this comes only from the uncommon style (on
In your previous mail you wrote:
A draft has been submitted to address source address selection at
the per-socket (and per apps) basis. Currently it discusses preferences
of source address selection by the application for privacy addresses,
mobileipv6 addresses and Cryptographically g
Erik Nordmark wrote:
> I don't quite understand this. You can only express properties about
> the local addresses (you can't tell from the DNS whether the address you
> looked up has any particular property).
The destination portion would include the same types of things you can specify
about a de
> First - I do think the PREFER_LARGEST_SCOPE is needed for a large collection
> of applications. (With all the noise about site-local in this group, I
> wonder if a REQUIRE_GLOBAL_SCOPE wouldn't be a good idea...)
Or make PREFER_LARGEST_SCOPE the default? But that isn't the subject of
this draft
Erik Nordmark wrote:
>
> This has some implication on the number of flags one can invent.
>
This is the part of the draft that has me concerned.
First - I do think the PREFER_LARGEST_SCOPE is needed for a large collection of
applications. (With all the noise about site-local in this group, I wo
One other thing I forgot is that, since we need to pass flags
to getaddrinfo as well as the TCP/IP stack, there is a need to fit
all the flags (whether there are only prefer or prefer+require flags) into
the flag name space for getaddrinfo.
This has some implication on the number of flags one can
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]
>
> > I think the above paragraph is unneeded and confuses the issue.
> > Setting the flags to 0 will restore the system default behavior.
> > If the app is using multiple values at different times, the behavior
> > is really up to the app, and the is
> I think the above paragraph is unneeded and confuses the issue.
> Setting the flags to 0 will restore the system default behavior.
> If the app is using multiple values at different times, the behavior
> is really up to the app, and the issue is not specific to this
> socket option. RFC 2553
I've read this document, and I would like to see it accepted as
a WG document and charter item.
Comments on the current text:
Section 3
> It is recommended that the application does a getsockopt() prior
> calling to setsockopt() call so that it can save the existing
> source address preference va
Samita Chakrabarti wrote:
Another thing I would like to see would be some tie-breakers,
when a application could say: 'all things beeing equal, I rather like to
use x'
Can you provide some concrete example and how this would be
useful in applications ?
A node with 2 interfaces, configur
Thanks for your comments.
> My first comment is that an API in that space is badly needed,
> so I fully support an effort to standardize such an API.
>
Yes, I agree.
> My second comment is on the suggested API itself.
> Some of the rules in the address selection RFC
> are common sense, some ar
Samita,
I've read your draft.
My first comment is that an API in that space is badly needed,
so I fully support an effort to standardize such an API.
My second comment is on the suggested API itself.
Some of the rules in the address selection RFC
are common sense, some are really 'suggested practi
We have had discussion about requirement of having a socket-API
on source address selection, in this alias.
A draft has been submitted to address source address selection at
the per-socket (and per apps) basis. Currently it discusses preferences
of source address selection by the application for p
40 matches
Mail list logo
