Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences

[itojun@iijlab.net]

>> >> even if there's very little use of AH in the community, major change
>> >> to AH that SEND requires would require another IP protocol #, IMHO.
>> >I'm not sure how significant the changes are, e.g. much of it can be seen
>> >as the properties of a new algorithm.
>>
>> draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol
>> proposal (not a new algorithm) to me.  AH needs to fall into what is
>> defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond
>> what defined in RFC2402.
>
>Could you clarify? What specifically leads you to conclude that SEND should
>be a new algorithm? I'm particularly interested in understanding what your
>feelings are about what should and should not be legitimately included under
>one of the reserved SPI before a protocol should be separated.

	none of existing algorithm for AH defines structure within AH
	authentication data.  therefore i assume AH algorithm to be some
	crypto-checksum algorithm, not a new protocol definition.

	for instance, if you write a program to support the draft, SEND use
	of AH would require certain amount of new code for parsing SEND
	authentication data packet format, not just a set of calls to crypto-
	checksum algorithm.  AH packet processing should not be that different
	depending on SPI value.

itojun