Re: [CGA-EXT] SEND checksum issue in current RFC 3791 - update needed

[gx su <[e-mail]>]

Hi,

We've been implementing the SEND for the last couple of months.

>From the sender side both way might have the same efficiency,
since most implementations of SEND might be a layer over NDP,
and NDP would compute the cksum before SEND could intercept
the packet; but A would need to recover the cksum before verifying
the signature, while B simply setting the field to 0.

Given the computation power of current PCs, I think efficiency would
not be a great concern; it is consistency that matters. Therefore I
prefer A -- after all, it would be the 1st solution that pops out to
implementors when they encounter the problem.

I agree that some kind of clarification is needed, this would w/o the
bug from happening.

2009/9/17 Sheng Jiang <[e-mail]>:
>> -----Original Message-----
>> From: Arnaud Ebalard [mailto:[e-mail]]
>> Sent: Thursday, September 17, 2009 5:01 PM
>> To: Eric Levy-Abegnoli
>> Cc: Sheng Jiang; 'wdwang'; [e-mail]
>> Subject: Re: [CGA-EXT] SEND checksum issue in current RFC
>> 3791 - update needed
>>
>> Hi,
>>
>> >> Yes, it is an issue must be clearly clarified in the specification.
>> >> Actually, there are two possibility here (which makes more
>> important
>> >> that specification should be clearly follow only one of them):
>>
>> Not arguing on the fact that "A" will be kept because it is
>> the "implemented" solution (Docomo implementation, Cisco,
>> probably Juniper too).
>>
>> >> A, if we would like to follow the drscription in Section 5.2.1 RFC
>> >> 3791, the input of RSA signature should be a checksum calculated
>> >> without RSA signature and it will be recalculated after signature
>> >> attached. On the receiver side, ICMP checksum should be validated,
>> >> then signature validate, then maybe checksum validate again.
>>
>> For the records (correction welcome if I missed sth),
>>
>> Signature computation:
>>
>>   - Create ICMPv6 message w/o RSA Signature option
>>   - Compute ICMPv6 checksum as usual using the pseudo-header
>> (current length,
>>     i.e. w/o the RSA Signature option)
>>   - Set that checksum in checksum field of the ICMPv6 header
>>   - Compute RSA Sig as described in section 5.2 of RFC 3971
>>   - Add RSA Signature Option at the end of the ICMPv6 message
>>   - Update ICMPv6 packet length to include RSA Sig option
>>   - Update IPv6 payload length to reflect addition of RSA Sig option
>>   - Update ICMPv6 checksum using updated pseudo-header for the
>>     computation (length value modified + addition of RSA Signature
>>     Option)
>>
>> Signature verification:
>>
>>   - Verify ICMPv6 checksum as usual on received message (obviously,
>>     including RSA Signature option)
>>   - Remove RSA Signature option from the packet
>>   - Update IPv6 length field to reflect previous removal
>>   - Recompute the checksum on the packet based on the new values (and
>>     w/o the RSA Sig Opt in the message)
>>   - Verify RSA Signature as described in RFC 3971
>
> This is right if we try to follow the current specification. This
> supplemented clarification is compliant with the current RFC 3971.
>
>> >> B, more efficiently, on the sender side, as you said, the input of
>> >> RSA signature should be a checksum with all 0, and after signature
>> >> attached, the checksim is computed over the whole packet. However,
>> >> this makes the signature over checksum totally meaningless.
>> >> Alternatively, we may take checksum bits out from the RSA
>> signature input.
>>
>> Performing the signature over the given layout with the null
>> checksum prevents useless copies: you zero the field, pass
>> the whole buffer to your signature function w/o the need to
>> copy things to create a different layout. But I guess this
>> does not matter anymore.
>
> Agree. If this is the initial design, it should be more efficient. However,
> if we need to follow what is already in current specification, try to keep
> consistent and compliant, don't break the existing implementations, then A
> is the only choice.
>
> Cheers,
>
> Sheng
>
>> Cheers,
>>
>> a+
>
> _______________________________________________
> CGA-EXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cga-ext
>