Subject: Comments on draft-ietf-send-ndopt-03

From: "Tuomas Aura" <[email-masked]>
Date: Mon, 9 Feb 2004 05:16:51 -0800

Here are some comments on draft-ietf-send-ndopt-03:

1.  CURRENT TEXT: Section 5.1.2: "NS and A messages 
without the CGA option MUST be silently discarded." 
Section 5.2.2: "NS, NA, RA and Redirect messages 
without the Signature option MUST be silently 
discarded." Section 5.3.4 (in three places): 
"...received without the ... option MUST be silently 
discarded." 

PROBLEM: This is not consistent with Section 8.

PROPOSAL: Section 5.1.2 and 5.2.2: "...MUST be treated 
as insecure, i.e., processed in the same way as ND 
messages sent by a non-SEND node. The processing of 
insecure messages is specified in Section 8. (Note 
that SEND nodes that do not attempt to interoperate 
with non-SEND nodes MAY simply discard the insecure 
messages.)" Section 5.3.4 (in three places): 
"...received with the Signature option but without the 
... option MUST be silently discarded."

2.  CURRENT TEXT: Section 7.3: all the text about 
discarding advertised prefixes that do not fall within 
the certified ranges, and reporting them to the admin 
as error. 

PROBLEM: This is not consistent with Section 8. Also, 
deployment of SEND will be unnecessarily difficult if 
all prefixes advertised by the same router must be 
certified on the same day. It would be better to allow 
a mixture of certified and uncertified prefixes.

PROPOSAL: A router may advertise a combination of 
certified and uncertified prefixes. The uncertified 
prefix information is treated as insecure, i.e., 
processed in the same way as insecure router 
advertisements sent by non-SEND routers. The 
processing of insecure messages is specified in 
Section 8. (Note that SEND nodes that do not attempt 
to interoperate with non-SEND nodes MAY simply discard 
the insecure information.)

ALTERNATIVE PROPOSAL: A SEND-router may advertise both 
certified and uncertified prefixes but must send 
separate router advertisements for the two types of 
prefixes.

3.  CURRENT TEXT: Section 5.1.3: "Implementations 
MAY also set an upper limit..."
PROBLEM: This is not consistent with the CGA draft, 
which requires the upper limit to be at least 2048.
PROPOSAL: "The upper limit SHOULD be at least 2048 
bits."

4.  CURRENT TEXT: Section: 5.2.2: "The Signature 
option MUST appear as the last option."
PROBLEM: What if we one day want to extend the 
protocol with a options that come after the signature? 
For example, if we want to have two different 
signature options, one has to come before the other.
PROPOSAL: "The receiver MUST ignore any options the 
come after the first Signature option." 

5.  CURRENT TEXT: Section 5.2.3, CGA flag: "This 
flag may be per interface or per node." 
PROBLEM: It might be useful for the router to specify 
in the router advertisements whether CGA is to be used 
for a particular prefix or not. 
PROPOSAL: "Note that in future extensions of the SEND 
protocol, this flag may be per subnet-prefix." 

6.  CURRENT TEXT: Section 5.3.4.1: See the last two 
bullets, especially the sentence: "RDlast is updated 
in any case."
PROBLEM: I think the last bullet has been accidentally 
written as a separate bullet. It should be a sub-case 
of the second last bullet. Otherwise, an attacker can 
use the updating of RDlast to increase the replay 
window. 
(Details of the attack: Honest node sends message m1 
at time t=10 and message m2 at time t=20. At time 
t=21, the timestamp on the second message expires, 
i.e., the receiver stops considering replays of 
message m2 as valid. At time t=25, the attacker 
replays m1. Because TSnew<TSlast, the receiver updates 
RDlast but not TSlast. This effectively increases the 
replay windows by 5 time units. Attacker can now 
replay message m2 and it will be accepted.) 
If TSnew+fuzz>TSlast+(RDnew-RDlast)x(1-drift)-fuzz is 
true and TSnew<TSlast, then there is no great harm in 
updating RDlast. However, I don't understand why it 
needs to be updated.

PROPOSAL: Make the last bullet a sub-case of the 
second last bullet. Delete the sentence "RDlast is 
updated in any case."  Most importantly, if  
TSnew+fuzz>TSlast+(RDnew-RDlast)x(1-drift)-fuzz is 
false, then the message should be ignored, regardless 
of whether TSnew<TSlast or not. 

7.  CURRENT TEXT: Section 6.2.5: "All requirements 
listed in Section 6.2.1 are fulfilled." Section 6.2.6: 
"All requirements listed in Section 6.2.2 are 
fulfilled."
PROBLEM: This is too vague. What are the requirements 
is 6.2.1/6.2.2? I would not know what code to write 
for this.
PROPOSAL: List explicitly the things that the 
router/host needs to check (rather than referencing 
Sections 6.2.1/6.2.2). 

8.  CURRENT TEXT: Sections 6.2.5 and 6.2.6: "If the 
message includes an IP Authentication Header, the 
message authenticates correctly."

PROBLEM: It is not necessary or even helpful to verify 
the AH (if there is one). If there is an IPSec policy 
that requires an AH, then the check will have been 
made before the packet gets to the SEND layer. On the 
other hand, if AH is not required and packets without 
AH are accepted, then there is no point in verifying 
the AH (if there is one).

PROPOSAL: Delete all text about AH verification.

I have some minor editorial comments, which I'll post 
/ mail to the editor as soon as they have been typed 
in.

Tuomas

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.