[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.
email@example.com wrote on 05/20/2003 01:29:14
> 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
> to indicate AH or (3) to indicate ESP. For notifications
> for which no protocol ID is relevant, this field
> sent as zero and MUST be ignored.
> What about "no prop chosen" for child props that include
> 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"
> Also, what SPI in these cases?
> For "nat detection source/dest ip" notifies, text says to
> address and port. Which spis are to be used and in which order?