Subject: Re: v7 nits

From: [email-masked]
Date: Sat, 31 May 2003 19:50:29 -0400

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

[email-masked] 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
> 
> 
> 
> 
> 
> 
>