Subject: RE: [NSIS] next peer issue in rsvp-sec

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 26 Nov 2002 23:50:26 -0000

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-Properties.ppt <http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.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

---

From: [email-masked]
Date: Wed, 27 Nov 2002 15:14:50 +0200

Hi Melinda,

Your wordsmithing works for me.

John

> From: ext Melinda Shore [mailto:[email-masked]]
> Sent: 27 November, 2002 15:09
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] next peer issue in rsvp-sec 
> 
> 
> > So, I think that part of the 2 layer functional split
> > that we need to work on should try to address this.
> > I prefer to have the upper layer handle the authentication
> > and payload encryption part.
> 
> I'd swap some words around and to say "upper layer handle
> the payload authentication and encryption part."  Basically
> all we're saying is that the application needs to protect
> itself against threats against the application and that the
> transport layer needs to protect itself against threats
> against the transport.
> 
> Melinda
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Kuntal Chowdhury" <[email-masked]>
Date: Wed, 27 Nov 2002 10:33:34 -0600

Hi Robert,
I think the statement "source didn't know the next peer had changed" means
the plain IP routing protocol did not propagate topology change (a non
converged network). Alternatively the "source routing" algorithm (that
computes the explicit route) did not do a good job. However these error
scenarios in explicit route computation do not mean that a correctly formed
ERO (with correct topology) information cannot be used in securing signaling
exchanges with the next peers.
 
-Kuntal

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]] 
Sent: Tuesday, November 26, 2002 5:50 PM
To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
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-Properties.ppt
<http://www-nrc.nokia.com/sua/nsis/ietf55/RSVP-Security-Properties.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

---

From: "Kuntal Chowdhury" <[email-masked]>
Date: Wed, 27 Nov 2002 11:08:53 -0600

Hi Hannes,
I agree that the router that sends the PATH message, should be prepared to
accept occasional error messages from peer's if for some reason the PATH
message did not get routed to the intended peer.
The point I was trying to make was: the chances of routing the PATH message
(with proper security association with an indented peer) will be higher if
route pinning (e.g. ERO) is used.
 
-Kuntal

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2002 9:25 AM
To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
Subject: RE: [NSIS] next peer issue in rsvp-sec

hi Kuntal 
 
the intention of this slide was to illustrate that the rsvp path message is
(with some modification) also a means to provide next-peer discovery. 
 
if you already know the next peer then you might be able to use the correct
security association (and therefore the key). 
 
additionally a problem is the fact that a router must allows expect to
receive a error message from somewhere indicating that a security
verification failure occurred. without knowning the topology you cannot even
restrict the nodes where these error messages have to come from. 
 
ciao
hannes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Kuntal
Chowdhury
Sent: Tuesday, November 26, 2002 6:55 PM
To: [email-masked]
Subject: [NSIS] next peer issue in rsvp-sec

Hi all, 

-Kuntal