> -----Original Message-----
> From: Arnaud Ebalard [mailto:[email protected]] 
> Sent: Thursday, September 17, 2009 5:01 PM
> To: Eric Levy-Abegnoli
> Cc: Sheng Jiang; 'wdwang'; [email protected]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext

Reply via email to