[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences
>> >> 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.