The MPLS WG Archive

["Yves T'Joens" <yves.tjoens@alcatel.be>]

on the discussion concerning
draft-schrijvp-mpls-ldp-end-to-end-auth-02.txt

back to some of the discussion that began during the meeting, but we
were unfortunately unable to continue due to time shortage.

This draft defines extensions to LDP to allow end to end authentication
between the LER initiating a LSP and the LER terminating a LSP. The
extensions require ordered control LDP and can also be applied to
CR-LDP. (this statement seemed to have slipped from our draft during the
rewrite...)

as to why we wrote the draft, let me remind you the argumentation that
has been used during the adelaide meeting which led to the inclusion of
this topic on the working group's charter. maybe we should be including
an applicability statement in the draft explicitly.

note also that during the pittsburg meeting support for this draft was
noted from the floor (cfr meeting minutes), however that further
discussion on the mailing list was necessary before progressing to WG
draft, so, here it is ;-)

Assume the following configuration 



         +-----------------------+
  +--+   .                       .  +--+
  + A+------------------------------+ D+
  +--+   .                       .  +--+
         .                       .  
  +--+   .                       .           
  + B+------------------------------+--+
  +--+   .    +---------------------+ E+
         .    |                  .  +--+
  +--+   .    |                  .
  + C+--------+                  .
  +--+   . mpls transport domain .
         +------------------------
  
(A,B,C,D,E) are 'customer' LERs that can interconnect by a LSP over a
mpls transport 'provider' domain. while each A,B,C,D and E trust the
mpls transport domain 'provider', they would like to authenticate each
other when they interconnect. As such, an LSP originated by an
authenticated LER would carry 'trusted' information. If heavier security
would be required (non-trusted mpls transport 'provider'), one should
fall back to IPSEC (tunnel) mode within the LSP (if it carries IP).

However, the level of security introduced by our procedure based on a
digital signature may be sufficient in many scenarios, and avoids the
overhead in signalling to which some people subjected in our first
version (cfr meeting minutes pittsburgh). 

following the above, does it makes sense to make this draft a WG draft ?

cheers
Yves