Subject: [NSIS] RE: Security Threats for NSIS draft

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 12 Jun 2003 09:40:47 +0200

hi john, 

i have asked a number of nsis members for their comments to this draft and
to the rsvp security properties draft to get more feedback. i hope to
receive some comments. i will incorporate them immediately. 

ciao
hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 12, 2003 9:25 AM
> To: Tschofenig Hannes; [email-masked]
> Subject: Security Threats for NSIS draft
> 
> 
> Hannes,
> 
> Any chance you'd get this submitted soon, I'd like to start 
> WG call before Vienna.
> 
> > Security Threats for NSIS 
> > http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt
> 
> thanks,
> John
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 18 Jun 2003 15:33:09 +0300 (EEST)

Hi,

I just went through the threats doc and have some miscellaneous comments. 
The basic idea of regrouping the threats sounds like a good thing, I also 
had some trouble following "the story". Also, a table summarizing the 
threats and maybe giving a short example of a solution would be good. Some 
other nits:

- A clear intro would be needed, one that says in the first lines of the 
introduction what this document is about. After that you can tell what is 
the contents of the doc.

 - you seem to use should and must somewhat interchangeably? It might be
good to be quite strict here, that is, security is a must. I don't mean
here that you should use "MUST" or "SHOULD" etc. but just to say that if
some attack is possible, "this is exactly how it can be defended".

(- page breaks! Aargghh... I hate it when I print a document out and it
doesn't have page breaks. On A4 paper, I get more lines than the IETF std
number.)

- It is not always clear why a certain attack is possible and what can be 
done about it, e.g. in Sec. 2.3. Could you elaborate a little here and 
there why a certain attach would be possible? Usually one-two lines is 
enough.

- A few typos:
  o 1.1 "securing protocols in separated" s/in/is/
  o pp. 11, last sentence "Replay attack, which can be..."
  o pp. 12 "signatures and not security" s/not/no/
  o pp. 13 "learn communication patters." s/patters/patterns/
  o pp. 15 List of sections? "2.8" mentioned twice?
  o pp. 16 an extra '>'?
  o pp. 16 "An adversary with access _to_ an NSIS router..."
  o pp. 17 "signaling message_s_ on behalf of someone..."
  o pp. 20 Sec 2.12 "...can be (the) misused by an adversary"
  o pp. 22 "for the possibility _of_ making a QoS reservation"

Regards,
Jukka

ps. I'll read through the other doc this evening and send comments 
tomorrow morning.

---

From: Roland Bless <[email-masked]>
Date: Tue, 24 Jun 2003 16:16:27 +0200

Hi,

> had some trouble following "the story". Also, a table summarizing the 
                              ^^^^^^^^^
Confirmed, I had the same impression while reading it.

> introduction what this document is about. After that you can tell what is 

Yup.

> doesn't have page breaks. On A4 paper, I get more lines than the IETF std

I hate it too, but as I read on the IETF discussion list, some people don't want to
waste their time in generating FFs. I have a perl script "makeFFintoRFC" (actually
the one line below) that does the trick. I usually use it in a pipe just before a2ps 
for pretty printing.
perl -pe 's/^(.*\[?Page\s*[0-9]+\]?)/\1\014/i;s/^([:alpha:]+\w+.*\s{4,}[0-9]+\s*)/\1\014/i' $*

Regards,
 Roland