Subject: RE: [NSIS] Next steps for the analysis document

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 17 Oct 2003 13:34:57 +0200

hi jukka, 

i will re-read the document again to address the security issues. 
i have once read all the described protocols with respect to security.
unfortunately, the  security considerations in many of these protocols is
lacking a useful level of detail. 

ciao
hannes

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]]
> Sent: Friday, October 17, 2003 1:23 PM
> To: [email-masked]
> Subject: [NSIS] Next steps for the analysis document
> 
> 
> 
> Hi all,
> 
> I would need to make (hopefully final) changes to the 
> Analysis draft. I'm
> trying to figure out what needs to be done. I would need the WG's view
> (yes, that means you, too) on what is missing (needs work) in 
> the draft.  
> At least issues 1,2 and 3 would need the WGs view as a whole, 
> other items
> are more or less directed to certain individuals or the draft 
> editors.  
> Here is a list of issues:
> 
> 
> 1) Remove the Appendix? Was there some comments about keeping 
> it, I think 
> someone liked it in Vienna? Or was it clear to remove it?
> 
> 
> 2) Add a short review of SICAP, a protocol similar to BGRP? 
> (See Helena
> Rute Sofia's email on July 16th 2003) (SICAP description July 
> 17th 2003)
> 
> 
> 3) What about adding an RMD evaluation? Or any other text? 
> (see Georgios'
> email on July 17 2003) (some discussions July 17th -> July 
> 22nd, Sep 5)
> 
> 
> 4) Hannes to review the security section? A short summary and pointers
> to his documents?
> 
> 
> 5) Section 3.5 needed more proof, need to ask Ping to review 
> the text.  
> See John's email on July 7th 2003.
> 
> 
> 6) Is there text that could be taken from Michael Thomas' draft on 
> mobility issues?
> 
> 
> 7) Add a reference that shows how YESSIR is as good as 
> claimed in Section
> 6.2.1 (Ping?)
> 
> 
> 8) Add reference to Tenet (mail from Alejandro Avella Jul 12 2003):
> (Page 20, Section 6.1)
> Anindo Banerjea, Domenico Ferrari, Bruce A. Mah, Mark Moran, 
> Dinesh C. 
> Verma, Hui Zhang
> The Tenet Real-Time Protocol Suite: Design, Implementation, and  
> Experiences (1996)
> IEEE ACM Transactions on Networking
> http://citeseer.nj.nec.com/banerjea96tenet.html
> 
> 
> 9) Split the references into (only?) "Non-Normative"
> 
> 
> 10) Add a summary
> 
> 
> Regards,
> Jukka
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 17 Oct 2003 14:41:42 +0300 (EEST)

Hi Hannes,

It is true that most protocols do not consider security at all or expect 
some weird things, or even rely on someone else to do security. At least 
some overall security section is needed, perhaps our dear Chair can 
provide feedback to your review.

Cheers,
Jukka

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Fri, 17 Oct 2003 13:55:02 +0200

hi Jukka,

I agree with you. However, it seems difficult to see all security aspects
when writing a document. I think it will be better if we (readers, or
someone are security experts) can send authors the feedback of  security
when we see the security problems. After that, the authors can update their
documents.

Best regards

Nary Tra

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 17 Oct 2003 15:04:35 +0300 (EEST)

Hi,

The more I try (start) to understand protocols, the more I start to think 
that security is THE thing that most protocol designers just don't really 
consider and think that it is easy to do. I would almost claim that quite 
a few protocols would be rendered totally useless or would work very, very 
badly, if they were made secure. Thus, I tend to think that protocol 
specifications should concentrate first on making the initial design 
secure, and not think that security could be added later. Security must 
not be "an additional option if someone wants it", unless the protocol is 
meant for a tightly closed system that does not require security and 
everyone using the system is a "good guy".

Regards,
Jukka