Subject: RE: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt

From: Eric Gray <[email-masked]>
Date: Thu, 13 Apr 2000 15:29:36 -0700

Dimitry,

	I think this is wrong for a couple of reasons.

	One is that the session object is defined such
that the last four bytes of the extended tunnel ID is
defined to be an IP address of the tunnel ingress.  
This is done explicitly to provide a globally unique
tunnel identifier which MUST then be under the control
of the owner of that IP address.

	The second is that it should be an error.  Since
the extended tunnel ID is defined the way that it is,
allowing any LSR to use the address of another LSR -
even one that is not necessarily particularly local -
is allowing forgery.  The fact that enforcement of
the definition of the extended tunnel ID MIGHT be hard
to do should not be taken to mean that nobody will do
it - or that anybody doing so is wrong.

--
Eric Gray

-----Original Message-----
From: Dimitry Haskin [mailto:[email-masked]]
Sent: Thursday, April 13, 2000 1:12 PM
To: David Charlap; [email-masked]
Cc: Abes, Andi
Subject: RE: FW: I-D
ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt

A small but not insignificant correction.

> > ...
> > 1. For LSP's to be belong to the same session they need
> >    to share the same egress point and tunnel ID.
> >    If the exteneded tunnel ID is set to the Ingress IP address, only
> >    LSP's originating at the same ingress could ever belong to the
> >    same session.
> 
> Yes.
> 

There is nothing to prevent nor it is an error for LSPs originating at
different ingress nodes to share the same extended tunnel ID even if this ID
happen to be set to an address of one of the ingress nodes.

Dimitry

---

From: David Charlap <[email-masked]>
Date: Thu, 13 Apr 2000 19:30:08 -0400

Eric Gray wrote:
> 
>         One is that the session object is defined such that the last
> four bytes of the extended tunnel ID is defined to be an IP address of
> the tunnel ingress.

Not quite "defined".  It's a recommended behavior:

      Extended Tunnel ID

         A 32-bit identifier used in the SESSION that remains constant
         over the life of the tunnel.  Normally set to all zeros.
         Ingress nodes that wish to narrow the scope of a SESSION to the
         ingress-egress pair may place their IPv4 address here as a
         globally unique identifier.

Note that it says "may" and not "must".

In other words, as long as two senders don't pick the same triple of
tunnel endpoint address, tunnel ID and extended tunnel ID, any value is
perfectly good.

The decision to use source IP addresses is simply a good idea, because
you know that it will be unique.  But there are other ways of
guaranteeing uniqueness as well - including operator assignment and (for
the insane) a network-wide ID server.

> This is done explicitly to provide a globally unique tunnel identifier
> which MUST then be under the control of the owner of that IP address.

I don't get that from the reading.  From what I can tell, any value that
can be used as a globally unique tunnel identifier may be used. 
Administrators may choose to use values other than ingress IP addresses
if they so desire.

>         The second is that it should be an error.  Since the extended
> tunnel ID is defined the way that it is, allowing any LSR to use the
> address of another LSR - even one that is not necessarily particularly
> local - is allowing forgery.

Ummmm....  I don't think the extended tunnel ID is intended to be used
as a security measure.  Its intent seems to be merely to prevent a
popular egress node from using up all of its 64K tunnel IDs.

> The fact that enforcement of the definition of the extended tunnel ID
> MIGHT be hard to do should not be taken to mean that nobody will do

You assume that the definition is a requirement instead of a
recommendation.  I don't get that impression from my reading of the
draft.

-- David