[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
>
>
>
>
>
>
>