Subject: RE: [NSIS] nsis threat issues

From: [email-masked]
Date: Fri, 1 Nov 2002 00:00:47 +0200

Hi Hannes,

> i was asked to whether a separation between the transport and the
> application part should be made. currently the nsis threat document is
> focused on the application layer part and not on transport issues. i can add
> an additional threat covering this issue.
> two examples:
> - an adversary would modify ip headers of the signaling 
> messages (if ip used
> used for message transport)
> - in case of a transport protocol: an adversary could terminate an
> established tcp connection.
> however these threats are not special for nsis signaling protocols.

That would be good to add, just to be complete.
 
> an important issue i see is that some people have no opinion 
> on particular security issues.
> for example:
> - is non-repudiation necessary/required or not important at all.
dunno
> - how important is a threat caused by a malicious nsis entity?
Do you mean a compromised entity?  I think it is an important
threat .
> - is network topology hiding a desired property?
No.
> - what about signaling message confidentiality?
> - do we worry about the reservation (or session) ownership problem?
> - etc.

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 31 Oct 2002 23:46:15 -0000

hi hannes,

you asked for opinions, here are mine:

[> > = you;
 >   = john;
[reh] = me]

> > - is non-repudiation necessary/required or not important at all.
[reh] definitely only a property of a particular NSLP (signalling application) that wants it, not a general NSIS requirement. how would needing to support it in an NSLP impact the rest of NSIS work?

> Do you mean a compromised entity?  I think it is an important
[reh] I agree; however, we need analysis to see whether the NSIS-specific element of the threat is additional to whatever else the entity can do. (e.g. If someone has a malicious router in the data path, the fact that they can compromise NSIS signalling may be overshadowed by all the other terrible things they can do - obviously it is a hard analysis problem to weigh these up.)

> > - is network topology hiding a desired property?
[reh] I would say 'desired but not essential'. If nothing else, I think making it possible to hide the topology introduces a discipline in users of the protocol (i.e. they don't abuse the protocol by finding out about the topology when they shouldn't be trying to). Maybe a MAY is appropriate.

> > - what about signaling message confidentiality?
[reh] yes please

> > - do we worry about the reservation (or session) ownership problem?
[reh] this is a vital issue as I see it. We need to know how much manipulation can be done at the NTLP level (and hence IMHO independently of authorisation issues) and how much can only be done within the specific signalling application (listen to the sound of "mobility interaction" in the background).

> John
cheers,

robert h