Subject: RE: [NSIS] attempted summary of next-peer issue (was: RE: next pe er issue in rsvp-sec)

From: "Kuntal Chowdhury" <[email-masked]>
Date: Wed, 27 Nov 2002 16:12:54 -0600

Hi Robert,
I think point 3 is important to note. I don't see anything in the
w.g. charter that says "explicit route" capability is beyond
the scope of NSIS. 

Section 4.1, assumption 5 and 6 in draft-ietf-nsis-req-05.txt has some
relevant texts on this subject:
"
5. We assume that there are means for the discovery of NSIS entities 
   in order to know the signaling peers (solutions include static 
   configuration, automatically discovered, or implicitly runs over the 
   right nodes, etc.) The discovery of the NSIS entities has security 
   implications that need to be addressed properly. These implications 
   largely depend on the chosen protocol. For some security mechanisms 
   (i.e. Kerberos, pre-shared secret) it is required to know the 
   identity of the other entity. Hence the discovery mechanism may 
   provide means to learn this identity, which is then later used to 
   retrieve the required keys and parameters.  
    
   6. NSIS assumes to operate with networks using standard ("normal") 
   L3 routing. Where "normal" is not specified more exactly on purpose.
"
I think assumption 5 is unclear as what "automatic discovery" really means.
However I think assumption 6 is (implicitly) in-line with your point 3.

Although not explicitly mentioned in the nsis-req draft, I guess the general

assumption in the w.g. is to only discuss issues with peers that are beyond 
reach of IGP and nodes that can only do plain IP routing. In short, no
"explicit
routing".

Thanks for the summary.

Regards,
Kuntal

> Hi Kuntal, Sven, Ping, Michael, John, Melinda, Hannes, all,
> 
> It seems a number of issues have got combined here. Here is 
> an attempted summary. Let me know if I missed or confused something.
> 
> 1. If the originator knows the route the traffic is taking up 
> to the next peer, it can send the signalling message to the 
> right place no problem - there is *no next-peer issue* in 
> this case. (This could be either because the originator is 
> doing traffic engineering, or has complete IGP knowledge, or 
> is telepathic, or whatever.) It can send the signalling 
> message with an ERO object or with what the framework 
> (currently) calls peer-peer addressing; in any case, there is 
> *no problem*.
> 
> 2. If you are in the fortunate position of knowing all nodes 
> are NSIS-signalling capable, there is also *no next-peer 
> issue* in this case. This is analogous to the IGP case. You 
> know the signalling peer just by knowing the outgoing IP neighbour.
> 
> 3. I believe we the NSIS w.g. are also (indeed, primarily???) 
> interested in situations where (a) you are not traffic 
> engineering or route pinning or assuming routing awareness, 
> and (b) NTLP or indeed NSLP peers are far apart in IP terms. 
> This is where the next-peer issue arises. And where, as 
> Hannes points out, you also need to worry about the patherr 
> messages in the other direction posing a security threat.
> 
> [that's why you need security specialists - they always give 
> the threat knife that one extra twist...]
> 
> Is this accurate? 
> 
> Robert H.
> 
> 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:[email-masked]]
> > Sent: 27 November 2002 15:25
> > To: Ping Pan; [email-masked]
> > Cc: Hancock, Robert; Kuntal Chowdhury; [email-masked]
> > Subject: RE: [NSIS] next peer issue in rsvp-sec
> > 
> > 
> > hi ping
> > 
> > referring to the security of rsvp-te and mpls in particular
> > is unfortunately
> > not very helpful. the way rsvp-te (and mpls) works is 
> > different to rsvp (or
> > a generic signaling protocol) in general. hence you could 
> > basically use
> > anything and it would work (in the worst case you can blame the
> > administrator for a bad network configuration). i would argue 
> > that in case
> > of interdomain signaling everything is much easier compared 
> > to end-to-end. i
> > bet that there are a few people who believe that you do not 
> > need to secure
> > intra-domain signaling messages.
> > 
> > i, however, think that there is a deployment problem for rsvp
> > since you
> > cannot assume that every router is an rsvp aware. (and we 
> > want to skip the
> > policy issues, the missing key management and other things 
> > for the moment).
> > hence i believe that the issues raised here are not only 
> imagination.
> > 
> > consider a case where rsvp signaling messages are interpreted
> > only at the
> > access networks and are treated transparently in the core 
> > network (because
> > of overprovisioning, diffserv clouds, etc.). would you as an 
> > access network
> > service provider be willing to make a qos reservation or some 
> > processig
> > without having these signaling message to be properly secured?
> > sender-initiated messages and proxy operation would make the 
> > situation more
> > difficult.
> > 
> > i have two questions regarding igp:
> > 
> > - how are messages delivered between two nodes? (transport
> > protocol/addressing)
> > - how does one node learn to which other node to send the message? 
> > (discovery mechanism)
> > 
> > ciao
> > hannes
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Ping
> > > Pan
> > > Sent: Wednesday, November 27, 2002 9:45 AM
> > > To: [email-masked]
> > > Cc: Hancock, Robert; Kuntal Chowdhury; [email-masked]
> > > Subject: Re: [NSIS] next peer issue in rsvp-sec
> > >
> > >
> > > I thought ERO was invented for traffic engineering. Why is
> > it relevant
> > > to security?
> > >
> > > This entire RSVP security thread sounds fishy to me. RSVP is no 
> > > different than IGP, where control messages are passed 
> hop-by-hop. If 
> > > people are happy with how routing protocols are handling 
> with their 
> > > security issues (MD5 and what not), then RSVP should just
> > adapt the same
> > > mechanism. I know some people are not happy with routing
> > security in the
> > > first place, then maybe this entire protocol security issue
> > should be
> > > considered else where.
> > >
> > > Finally, I am just curious about where this NSIS protocol 
> would get 
> > > deployed to have this security problem. In the backbone,
> > RSVP-TE seems
> > > to be fine as it is. I wonder if this is designed for 
> mobile users.
> > >
> > > Thanks!
> > >
> > > - Ping
> > >
> > >
> > > [email-masked] wrote:
> > > > Hi Robert, Kuntal, all,
> > > >
> > > > I interpreted the ERO comment as follows: The fact that
> > the security
> > > > association is now wrong results from the route change. The ERO
> > > is a way to
> > > > pin the route to what it originally was and thus prevents the
> > > route change.
> > > > This means that the security association will be the correct
> > > one. What do
> > > > you think?
> > > >
> > > > Cheers,
> > > > Sven.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "Hancock, Robert" <[email-masked]>@ietf.org on
> > 27/11/2002
> > > > 00:50:26
> > > >
> > > > Sent by:  [email-masked]
> > > >
> > > >
> > > > To:   Kuntal Chowdhury <[email-masked]>, 
> > [email-masked]
> > > > cc:
> > > > Subject:  RE: [NSIS] next peer issue in rsvp-sec
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I  don't believe that the ERO is relevant here. The issue
> > isn't that the
> > > > messages  get sent to the wrong next peer (which the ERO would
> > > fix, albeit
> > > > in  a somewhat overweight way), it's that they are sent to the
> > > right next
> > > > peer, but with the wrong security association, because
> > the source didn't
> > > > know  the next peer had changed. So this is essentially an
> > > issue of how to
> > > > discover  and react to route changes. (At least I think so.)
> > > >
> > > > Cheers,
> > > >
> > > > Robert  H.
> > > > -----Original Message-----
> > > > From: Kuntal Chowdhury  [mailto:[email-masked]]
> > > > Sent: 26 November 2002  17:55
> > > > To: [email-masked]
> > > > Subject: [NSIS] next peer issue in  rsvp-sec
> > > >
> > > >
> > > >
> > > > Hi all,
> > > > I think the Next Peer issue  highlighted in the RSVP
> > Security Properties
> > > > slide
> > > > 
> > (http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Proper
> ties.ppt)
> > > can be solved by adding an ERO (EXPLICIT_ROUTE object)  in the 
> > > RSVP-PATH message. Of course the intervening  network needs to 
> > > understand ERO.
> > >
> > > -Kuntal
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> 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: Melinda Shore <[email-masked]>
Date: Wed, 27 Nov 2002 17:24:36 -0500

> I think assumption 5 is unclear as what "automatic discovery" really means.

I think the document would benefit from the deletion of
assumption 5.  Somewhere, somehow, somebody needs to address
the security issues around discovery, but I'm not sure that
needs to be done in a requirement document unless there are
actual requirements.

Melinda

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 28 Nov 2002 14:46:38 +0100

RE: [NSIS] attempted summary of next-peer issue (was: RE: next peer issue in
rsvp-sec)hi kuntal

it is true that the charter says nothing like "explicit route capability is
beyond
the scope of NSIS". i guess that we can all agree that things typically used
in traffic engineered networks are very special cases. hence it is fair to
say that we cannot assume this behavior for all signaling
applications/scenarios.

can you agree with me?

ciao
hannes

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Kuntal
Chowdhury
  Sent: Wednesday, November 27, 2002 11:13 PM
  To: Hancock, Robert; [email-masked]
  Subject: RE: [NSIS] attempted summary of next-peer issue (was: RE: next
peer issue in rsvp-sec)

  Hi Robert,

     6. NSIS assumes to operate with networks using standard ("normal")
     L3 routing. Where "normal" is not specified more exactly on purpose.
  "
  I think assumption 5 is unclear as what "automatic discovery" really
means.
  However I think assumption 6 is (implicitly) in-line with your point 3.

  Although not explicitly mentioned in the nsis-req draft, I guess the
general
  assumption in the w.g. is to only discuss issues with peers that are
beyond
  reach of IGP and nodes that can only do plain IP routing. In short, no
"explicit
  routing".

  Thanks for the summary.

  Regards,
  Kuntal