[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Commit Bit and SPI?



  Will,

  Should you check the SPI and if so which one? Well if you have to check
the SPI it makes sense for it to be the one with the responder's destination
address in the <addr,SPI,protocol> tuple that identifies the SA since it
is the responder saying, "OK, now I'm ready, you can start using this".
But should you even check it? I'm not so sure. If N SA pairs were negotiated
in the single Quick Mode do you send N notify messages? That doesn't seem
all that informative. When the responder sends the final message it means
he's ready with everything so if that message contains 1 notify or N it's
meaning isn't different (at least to me).

  The other issue is do you have to reflect back the bit if the peer sets
it or can you "negotiate" this capability? Well if you could choose to 
reflect it what if the initiator sets it in Quick Mode message #3? 

  Something has to be said to clear this up, yes. But it's a decision of
the WG. Do we send a notify for each SA pair containing the responder's
SPI(s) or do we send a single notify with no SPIs? Can we not reflect the
commit bit and if so what does that mean? Who can set the commit bit and
where should that be allowed and prohibited? If we can get some consensus
on this matter it'll go in the document but a unilateral decision by me
will only result in conflict.

  I'm sorry you are disappointed in my lack of attention to this but the 
IETF does not pay and consequently gets put in my queue at the appropriate 
place. I'm trying but these are crazy times.

  Dan.

On Thu, 03 Feb 2000 11:37:40 CST you wrote
> On Tue, Feb 01, 2000 at 03:01:39PM -0600, Will Fiveash wrote:
> > Dan, can we change the draft-ieft-ipsec-ike-01.txt so that we get a
> > standardized way of interpreting the reflection or non-reflection of the
> > CB?  I think this will give implementors reasonable flexibility in that if
> > they do not want to implement CB they just have to make sure they don't
> > reflect the CB.  If they do support CB then they have to check for
> > reflection which is easy.
> 
> And while I am on the subject of connect-notify.  Can someone tell me
> whether I need to check the SPI in the connect-notify against the SPI in my
> P2 SA?  I ask this because I saw almost every permutation of SPI in the
> connect-notify payload from various vendors.  And I noticed that few
> vendors checked the SPI I sent in the connect-notify.
> 
> If I am supposed to check the SPI, can someone make it painfully clear as
> to which SPI is supposed to be sent in the connect-notify?  Given the
> confusion in the last bakeoff it seems to me that this issue should be
> addressed in one of the documents.
> 
> As an aside, I am somewhat disappointed that I haven't seen any responses
> from the document owners stating whether they agree with the recent e-mails
> regarding commit bit processing and SPIs.  Does anyone else find it ironic
> that Bruce Schneier's paper which criticizes the IPSec workgroup method of
> standards development is receiving lots of discussion on this list while
> the discussion on commit bit which is trying to clarify the protocol
> documentation is receiving little attention?
> 
> -- 
> Will Fiveash
> IBM AIX System Development


Follow-Ups: References: