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

From: [email-masked]
Date: Wed, 27 Nov 2002 08:51:48 +0100

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

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

---

From: Ping Pan <[email-masked]>
Date: Wed, 27 Nov 2002 00:44:55 -0800

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Nov 2002 03:05:37 -0800 (PST)

In fact, RSVP has two different authentication
needs: hop-by-hop which is fairly analogous to the
IGP problem and the more abstract e2e/e2m/m2m kind
of problem which RFC 2752 talks about. This
problem is both a) harder and b) not unique to
RSVP (SIP and any other proxiable protocol usually
run into the same problem).

What I keep wondering about is whether an app
layer auth/encryption abstraction would be useful
for all (or many at least) of these problems that
keep popping up. SIP, for example, did a pretty
bad job of solving this problem.

	Mike

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 27 Nov 2002 16:24:42 +0100

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

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