[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: v7 nits
Good catch. I've tightened the wording.
My expectation (which is what I tightened the wording to) was that this
protocol type was effectively a modifier of the SPIs listed because a system
could have ESP and AH SAs with the same SPIs at the same time. So I tightened
the wording to say that this is only used if it concerns an existing SA.
So in the example you give, where no SA exists, an implementation would
send a zero and ignore the received value.
Someone had already pointed out the
ambiguity in the nat hash; I fixed it.
--Charlie
jpickering@creeksidenet.com wrote on 05/20/2003 01:29:14
PM:
>
> As long as we are still stuck in the bogs of identity usage, a
> couple of points of v7 clarification would be also appreciated:
>
> Text on protocol for notifications states:
>
> For notifications
> concerning IPsec SAs this field will contain either
(2)
> to indicate AH or (3) to indicate ESP. For notifications
> for which no protocol ID is relevant, this field
MUST be
> sent as zero and MUST be ignored.
>
> What about "no prop chosen" for child props that include
both
> AH and ESP? What about "ipcomp supported" requests with
> both AH and ESP props? I would claim that protocol ID is
> not relevant, but the sentence above says I still need a "2"
or "3".
> Also, what SPI in these cases?
>
> For "nat detection source/dest ip" notifies, text says to
hash SPIs,
> address and port. Which spis are to be used and in which order?
>
> Jeff
>
>
>
>
>
>
>