In your previous mail you wrote:
I don't know if any application cares whether received
destination options appear before or after a fragmentation header.
Is there such a need?
=> I can see both, symmetry (stronger than one can believe at the first
view because of the send what is r
>> one question - maybe i have lost some context.
>> we are talking about socket API. is it really necessary
>> for user applications to be able to transmit arbitrary AH/ESP/fragment
>> header?
>I don't see a need to allow this on the transmit side. But the discussion
>started
Back from vacation and travel ...
> one question - maybe i have lost some context.
> we are talking about socket API. is it really necessary
> for user applications to be able to transmit arbitrary AH/ESP/fragment
> header?
I don't see a need to allow this on the transmi
Date:Wed, 20 Dec 2000 07:31:31 -0800 (PST)
From:Michael Thomas <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I tend to doubt that sending the AH or ESP headers up the
| stack is especially useful.
I think what you mean is that applications are unlikel
Francis Dupont writes:
>Similarly for sending - the kernel interface might well ignore whatever the
>application stuck in one of these headers (frag, AH, ESP - perhaps others)
>but it could use the presence of such a header to indicate where it should
>place a header of equival
In your previous mail you wrote:
| - this doesn't work well with "transparent" headers like fragmentation
|or IPsecs.
|
|This would still have some problems since certain extension headers
|(fragmentation, AH, ESP) aren't passed up to the application.
Date:Mon, 18 Dec 2000 19:01:05 +0100
From:Francis Dupont <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
|when there are multiple destination options headers in each of these two
|logical locations.
|
| => merge them???
Ugh!
| => this is th
In your previous mail you wrote:
To me it would make sense to have associated data that is the index of
the security association used (is that the right term? I'm not really
up to date on IPSEC terminology).
=> I agree, the SPI is the useful key to metadata.
Would it make sense
>> >> This would still have some problems since certain extension headers
>> >> (fragmentation, AH, ESP) aren't passed up to the application.
>> >=> exactly my second concern.
>> one question - maybe i have lost some context.
>> we are talking about socket API. is it really necessar
> From [EMAIL PROTECTED] Mon Dec 18 15:41:56 2000
> Received: from roll.mentat.com (roll [192.88.122.129])
> by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA28833
> for ; Mon, 18 Dec 2000 15:41:47 -0800 (PST)
> Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
>
>> This would still have some problems since certain extension headers
>> (fragmentation, AH, ESP) aren't passed up to the application.
>=> exactly my second concern.
one question - maybe i have lost some context.
we are talking about socket API. is it really necessary
Niels,
>
> To me it would make sense to have associated data that is the index of
> the security association used (is that the right term? I'm not really
> up to date on IPSEC terminology).
>
> Would it make sense to use the same ancillary data on the sending
> side, for applications that
Bill Sommerfeld <[EMAIL PROTECTED]> writes:
> > To me it would make sense to have associated data that is the index of
> > the security association used (is that the right term? I'm not really
> > up to date on IPSEC terminology).
>
> The actual spi value is not likely to be very useful to the
>
> To me it would make sense to have associated data that is the index of
> the security association used (is that the right term? I'm not really
> up to date on IPSEC terminology).
The actual spi value is not likely to be very useful to the
application (when key management is in use, it's a rando
Tim Hartrick <[EMAIL PROTECTED]> writes:
> For example, lets say we have a UDP datagram that looked like the following:
>
> IPv6 header
> Hop-by-hop options header
> Destination options header
> AH header
> ESP header
>
> Destination options header
> UDP payload
>
> Assuming that all the relev
Erik,
>
> > I don't know that the receiving application needs to know any of this. It
> > merely needs to know that the appropriate security was applied by the system.
> > That would seem to be understood given that the application is receiving the
> > datagram. If appropriate security wasn
In your previous mail you wrote:
I believed before and believe now that this is the better way to go.
I never really liked the IPV6_RTHDRDSTOPTS option.
=> I understand your opinion but we have to provide a way to denote
the position for the sending side.
As I said, I don't believ
In your previous mail you wrote:
Adding a 3rd set of options to receive a 3rd placement of destination
options in the advanced API probably isn't too hard.
=> I agree but I can intepret Steve's comment as this is not the good
solution. But I don't know a good way to denote the position fo
> I don't know that the receiving application needs to know any of this. It
> merely needs to know that the appropriate security was applied by the system.
> That would seem to be understood given that the application is receiving the
> datagram. If appropriate security wasn't applied the datag
Erik,
>
> The above is quite complex to describe to the user of the API.
> Adding another IPV6_DSTOPTSAFTERIPSEC(?) concept that is conditional
> would make it even harder to describe.
>
I am generally against this proliferation of new option types and extension
headers. Processing and pac
> The working group has just decided the flawn is not in the specs but
> in the advanced API then either:
> - or we found a good way to encode positions (I have no idea of how)
> - or we arbitrary restrict the advanced API expressiveness to
>some common cases (as it is done today but we alre
The working group has just decided the flawn is not in the specs but
in the advanced API then either:
- or we found a good way to encode positions (I have no idea of how)
- or we arbitrary restrict the advanced API expressiveness to
some common cases (as it is done today but we already need t
22 matches
Mail list logo
