Subject: RE: [NSIS] Short Review of draft-shore-ntlp-00.txt

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 8 Jul 2003 15:46:12 +0200

Melinda

[snip]
|Some are probably obvious (replay protection)
|but some are not, and there are some very difficult issues
|around both keying and authorization. 

When signaling crosses domain borders (lightweight) message 
integrity and authentication are required. Bogus messages 
should be identified and deleted at the lowest possible 
layer (NTLP is better than NSLP, but if feasible the 
transport below NTLP was better than NTLP).

|There are some efforts elsewhere within the IETF 
|that may or may not have some relevance (soBGP, for 
|example). 

Yes, its a good idea to check their security 
requirements and solutions. 

|I'd actually like to see a separate security design 
|team for the NTLP.

Reaching consensus on the way we'd like to proceed with 
NTLP security design certainly is helpful. 

Regards, Rudiger

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 8 Jul 2003 10:41:13 -0700 (PDT)

> transport below NTLP was better than NTLP).

I don't see why this is a priori true. In general,
you gain the most flexibility by moving
functionality up the stack. The tradeoff is the
potential for lack of uniformity, and the
corresponding possibility for breaches due to, oh
say, insufficient review.

Right now the two things that most resemble NSIS
are RSVP and SIP to my mind. BGP has some of the
same problems as Melinda points out, but I'm not
as well clued in there. RSVP has elected to keep
all of it at application layer, and SIP has
elected to use lower level security for hop-by-hop
and application layer for hop-spanning needs. The
biggest win with the SIP approach, IMO, is that
you inherit key management which has been well
vetted. This is something that the RSVP integrity
object lacks, and would require further
standardization to make it useful. Which isn't to
say that it's appropriate for NSIS because though
similar to SIP, it is not the same (cf
discovery...). Also: as with SIP, lower layer
security protocols are not ideal either. TLS
doesn't run over UDP, and IPsec has trouble with
cross-layer binding of auth to authz. TLS also
suffers from fairly trivial DoS attacks if you can
see the traffic flowing by (otherwise it's
O(guess-large-number)).

So I guess I don't see this as really clear. With
MIPv6 I made the argument for IPsec for binding
updates primarily because of the keying problem.
RSVP/NSIS do not have the same security
considerations though and it's not even clear
whether hop-by-hop integrity is even all that
useful since we have the alternate means of
auth/authz through policy objects and/or COPS. To
my knowledge neither policy or integrity are
widely implemented or used, but the one thing to
be said about the policy objects is that the COPS
model is extremely analogous to AAA which is
pervasive. And that model does not require or care
about hop-by-hop integrity. Which isn't to say
that that's an arguably bad thing, just that it is
in fact reality. Given this, it may well be that
NSIS is exactly *inverted* from the SIP mechanism.
That is, SIP's primarly line of auth/authz defense
is made at the hop-by-hop transport level. NSIS --
like AAA -- may well be at the non-adjacent
application layer, which should inform how much
effort we should expend on each; a simple
necessary and sufficient at hop-by-hop may
actually be the right answer ala RSVP.

	    Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Jul 2003 13:46:09 -0400

I think we should be somewhat careful in extrapolating from one 
application, QoS, to all of NTLP. It may well be possible to do this, 
but I could imagine that other near or long-term NSIS applications, such 
as network diagnostics or active code deposits, fall somewhere else on 
the transport-vs-application security axis. For example, it might be 
considered undesirable if random parties can easily spoof diagnostic 
information along a path.

Also, unlike RSVP, the separation into two layers opens up additional 
DOS attacks, such as establishing lots of state on NSIS nodes. (Nodes 
sometimes have to establish state even if they do not understand the 
NSLP layer, or so has been argued.)

---

From: Michael Thomas <[email-masked]>
Date: Tue, 8 Jul 2003 14:30:44 -0700 (PDT)

At first I thought there was merit to the
"QoS-specific" rap, but as I re-read it, I'm not
sure that what I wrote is especially related to
QoS. It's always true that there may be situations
where you want confidentiality, key mgmt, etc in
hop-by-hop, but it's really more of a question of
prioritization and effort. That is, how worth is
it to get this more "correct" for NSIS than it is
for RSVP? SIP had pretty good motivation, not the
least of which was the possiblity of transporting
SRTP keys, but the UA/proxy architecture as the
norm makes a pretty compelling argument as well.

The question, really, is whether NSIS applications
are more SIP-like or AAA-like in their
authorization and delegation. I'm not a huge AAA
fan, but I think it's unarguably the case that
people like that model, and there's tons of
deployment. Indeed, there's been plenty of noise
even in SIP land to integrate with legacy AAA too.
I tend to think that that lure will persist if not
strengthen with NSIS, especially as policy becomes
more complicated.

So if I had to choose whether to put a bunch of
effort making hop-by-hop auth/conf/authz better or
hop-to-decision-maker architectures better, I'd
choose the later. Maybe we have to do both, but I
for one am not eager reopen the same debate with
NSIS as was, IMO, unsatisfactorily resolved in
SIP. There seems like there are better things to
worry about.

		Mike

---

From: Melinda Shore <[email-masked]>
Date: Wed, 09 Jul 2003 08:07:45 -0400

> choose the later. 

I think the latter obviously needs more attention in
general, but when you slice apart the NSIS layers it becomes
pretty clear that you need to focus on the hop-by-hop
problem in the NTLP context or you end up doing things that
aren't that meaningful for actually protecting the traffic
or you end up overly constraining, I think, the design.  For
example, doing something like source authentication almost
certainly doesn't make sense when you're providing a
generalized mechanism for bundling NSLP payloads.

It seems pretty clear to me that the NTLP security problem
is hop-by-hop and the NSLP problem, depending on the
application, will tend to be what you call "hop-to-decision-
maker."

Melinda

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Jul 2003 14:52:04 -0400

I would agree that spending a lot of time on NTLP-specific security may 
not be time well spent. Indicating the re-use of existing mechanisms is 
probably not much effort where that is feasible; part of the reason SIP 
ended up spending lots of time on this because there was a 
mandatory-to-implement decision tied in with that, which tends to get 
people excited.