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

From: [email-masked]
Date: Tue, 8 Jul 2003 15:01:30 +0300

Hi all,

I'm doing a quick review on documents to be discussed at IETF 57.

As this document is quite preliminary, I don't intend to give a detailed 
review, but an initial overview of the document.

http://www.ietf.org/internet-drafts/draft-shore-ntlp-00.txt

1) Terminology 

This section needs to be expanded, with definitions provided.

2) Introduction

The introduction is well written, sets out the proposal for the draft and
seems to provide the correct intro for the document.

3) NTLP Messages
4) Sending NTLP Messages

I'm combining these sections all together.  In general, I would have liked to
see a (somewhat) simplified overview of the protocol upfront, so I could
get the overall picture of the protocol in my mind before seeing the bits
& bytes. I do like the TLV structure & generally have no major complaints
about the initial message & parameter formats.

5) Messaging and State Maintenance

This section does capture state reduction well, however the text is somewhat
dense and complicated.  I do think that a slightly slimmed down version 
of this removing things like exponential back-off procedures, etc. could have
been better for a version 00 draft.  I worry that the overall protocol workings
will become more complicated over time - which is usual for most IETF protocols,
so a simple proposal at first might be needed.

SUMMARY

The draft has a number of good things going for it, some of the details 
are quite useful - however, a good editing with a view towards 
simplifying the protocol would be benefitial.

thanks,
John

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

---

From: [email-masked]
Date: Tue, 8 Jul 2003 15:39:31 +0300

Hi Rüdiger,

> is it correct to draw the conclusion that you don't feel Melinda's 
> draft to be a bit short on security? The security section currently reads:
> we need to determine exactly what we're protecting and why.

It is short on security, and would definately need something more significant
in this section.

John

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 9 Jul 2003 11:29:44 +0200

hi all, 

please find further comments inline:

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, July 08, 2003 7:41 PM
> To: Geib, Ruediger
> Cc: [email-masked]; [email-masked]
> Subject: RE: [NSIS] Short Review of draft-shore-ntlp-00.txt 
> 
> 
> Geib, Ruediger writes:
>  > 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).
> 
> 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.

i have difficulties to see the relationship to the mentioned certificate
distribution mechanism using bgp. 

> RSVP has elected to keep
> all of it at application layer,

this sounds like there was a design consideration phase which finally
decided to support security at the application layer. actually, i think that
there was no other choice (due to some design decisions). 

> and SIP has
> elected to use lower level security for hop-by-hop
> and application layer for hop-spanning needs.

... because design decisions in the protocol give the freedoom to chose a
number of mechanisms.

> The
> biggest win with the SIP approach, IMO, is that
> you inherit key management which has been well
> vetted.

certainly and there aren't too many flexible and standardized protocol which
support authentication and key exchange (including subsequent message
protection). 

> 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...).

the discovery combined with signaling message delivery, as pointed out
several times, is not very helpful for a number of things (including
security).

> 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)).

creating your own security solution at the application layer is also not
trivial (see rsvp security).

> 
> 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.

you might want to take a look at our nsis/aaa draft. we believe that
hop-by-hop integrity is a useful concept.  

> To
> my knowledge neither policy or integrity are
> widely implemented or used,

maybe since rsvp is not widely used ? 
microsoft implemented the kerberos authentication mechanism. 
in the packetcable environment the integrity mechanism is 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.

you might want to take a look at the 3gpp ims model (sip usage in the 3gpp
environment):
there you will find:

- a protocol executed between the end host and a node in the network  (sip)
- a protocol between the visited network and the home network (let's call it
aaa protocol)

authentication, authorization is done initial (with the first few messages)
- subsequently keys are in place to protect signaling messages between these
nodes. 

i am unbiased with regard to cops - it could well be another protocol such
as radius or diameter (but that does not change anything). 

if you look at the QoS NSLP Authorization Issues draft then you will find
some questions which might, as a consequence, require either the above
described approach or something else. certainly, it is not only a technical
issue but also an issue of control (i.e. how much control do you want to
place at the home network). but that's probably a longer story. 

> 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.

i hope that i misunderstood you. you are not saying that the hop-by-hop
security is not required? 

entity authentication alone is not the whole story. if you only do the
initial aaa communication then you have nothing more!

> Given this, it may well be that
> NSIS is exactly *inverted* from the SIP mechanism.

i would like to know how you reached this conclusion. 

i think that nsis is closer to sip than one might think (with regard to some
nslps). 

> 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;

could you explain this non-ajacent application layer issue a little bit
more? 
is it something what we called "New Jersey Parkway Model" in the nsis/aaa
draft?

 a simple
> necessary and sufficient at hop-by-hop may
> actually be the right answer ala RSVP.

ciao
hannes

> 	    Mike

---

From: [email-masked]
Date: Wed, 9 Jul 2003 13:25:45 +0300

Hi all,

> |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. 

One of my suggestions in Vienna was to be about security /
AAA aspects.  Perhaps we should be prepared to discuss
the next steps on this in Vienna.

thanks,
John