Subject: (draft) end-2-end auth proposal for LDP (design)

From: Morvan Daniel Müller <[email-masked]>
Date: Wed, 28 Aug 2002 11:43:57 -0300

Hi all!

I'm brasiliam, excuse about english erros :)!

I' implementing a draft proposal discuted in dec/2001 by this wkg.
<draft-schrijvp-mpls-ldp-end-to-end-auth-03.txt> - I attached it.

I try contact authors without success in the last weeks. (They
know about my implementation and give me very important help when
I start this project in a few months ago).

The implementation is very closed (I'm changing source forge 
linux ldp-portable implementation). 
(I have a doubt for a long time) but now at implementation level 
I conclude that its impossible implement the proposal like its 
explained. It need probably some estructural changes.

Please I need help from experts on LDP operation, so this list is the 
best place :)!

Basically this is the proposal scenario:

LER A                  LSR 1             LSR n                 LER B
     |                     |                 |                     |
     | auth LDP Request    |                 | auth LDP Request    |
     |------->-------------|------->---------|------->-------------|
     | auth LDP MAP        |                 | auth LDP MAP        |
     |--------<------------|-------<---------|----------<----------|
     |                     |                 |                     |

I firts list my doubts and after I explain the proposal, OK:

I have 2 doubts. Doubt (1) is critical (2) only to confirm:

1) when LERA send the Request for some FEC: It don't know that
   LERB will be the egress OK?. 
   But the proposal consider that LERA know the 
   remote peer LERB when send the label request, and use it to 
   choose the correspondent mac-function-secretkey shared by 
   LERA-LERB, it is not possible in my vision?
   
   On alternative solution would be create some tlv with meaning to 
   return the egress LSRid for some FEC (a new feature into LDP). 
   I'm not sure if it justifiable. Someone have ideas?  
  
2) the proposal list as requirement ONLY ordered-control, but is 
   considering one request for every map, so "on-demand-distribution" 
   is implicit, so it would be a requirement, OK?

I try to explain as clean possible how the proposal works:

Application Scenario:
  authenticate the FIRST LSP between Ingress and Egress end-to-end;

- destinated for non-adjacent LSRs (LERA-LERB) (without e2e TCP/LDP
  session), so TCP Md5 signature option not apply. 
- it requires LDP ordered control
- define 2 new TLVs: Mac-Tlv and Nonce-Tlv
- macTlv = srcLSRID + macdigest of (labelrequest/labelmap fields)
- MAC function (Mac-TLV) provide authentication and Integrity protection
- defined MAC fuction is Hmac-sha1
- NonceTLV: a every increase nonce value provide anti-replay protection.
- no confidenciality its provided 
- intermediary LSRs only bypass (authentication Tlvs) end-to-end cause, 
  f-bit=1 and u-bit=1 into the new TLVs.
- Each LSR need to have locally a list with possible peers as follow:
  PEER-LSR-ID1 : key_identifierA : mac_keyA
  PEER-LSR-ID1 : key_identifierB : mac_keyB
  PEER-LSR-ID2 : key_identifier  : mac_key
        Obs: with "key Identifier" peers could use one
             key for reqw and other for map, for example.
- LDP msgs used to transport authentication tlvs:
  Label_Request
  Label_Mapping
  Ldp_notification ( status_code="authentication failed" )

- The use of authentication is a local police matter of the LSR (mutual
  agreement between the 2 LSRs who want setup the LSP).

The Process:
=============
1)LERA encode a label_request, insert a "nonce tlv" and a "mac tlv" and
  sent it to LERB.  
  a) The MAC Tlv need to be the last tlv of the pdu.
  b) LERA can determine which mac-key to use cause it knows the 
     remote LSR entity with wich it is setting up the LSP.

    HERE MY DOUBT????????????????????
    (HOW LERA KNOW IT, Request is based on FECs not destLSR-ID)

- LSR1..LSRn bypass the authentication tlvs cause f-bit=1 and u-bit=1.  
  This intermediary LSRs can't change the tlvs oder into the LDP_PDU;

- LERB receive the PDU and verify the authentication tlvs: 
  - determine the originator LSR, 
  - thanks the "key Identifier" can determine the respective local mac-key
  - apply the same MAC function and match against received mac value:
  * if match successfull: a authenticated "label_mapping" is returned 
    to LERA
  * if match fail: a authenticated "label_notify" with status
    "authentication failed" is returned to LERA.
- If LERA could successfull authenticate the label_mapping, the LSP is
  established.

============================= complementar information ================ 

- New defined TLVs for LDP:

1) MAC TLV:
  
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|1| MAC (TBD)                 |      Length                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   key Identifier              |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    |                           LSR  Identifier                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                           MAC authentication value            |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U-bit: the Unknown-bit must be set to '1' because intermediate LSRs
   that do not know this new TLV should ignore it and process the rest
   of the message.

   F-bit: the Forward-bit must be set to '1' because intermediate LSRs
   that do not know this new TLV should transparently relay this TLV to
   the next LSR.

   Length: this field indicates the total length in bytes of the
   following fields.

   Key Identifier: this field identifies the shared secret key
   used by the MAC generator so that the receiver can determine which
   shared secret key to use to verify the MAC value, in case both
   entities share more than one such secret key.

   LSR Identifier: this field contains an identifier of the authenticating
   entity to be used by the LSR receiver in the MAC verification process.

   MAC authentication value: this field contains the MAC value generated
   as described in "MAC generation", bellow.

   The MAC TLV must be the last TLV of the LDP message. 

2) NONCE TLV:
  
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|1| Nonce (TBD)               |       Length                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                           Nonce value                         |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U-bit and F-bit: must be set to '1', same as in MAC TLV. 

   Length: this field indicates the length in bytes of the nonce value
   field.

   Nonce value: this field contains a unique value that must increase
   for every message exchanged between two LSRs.  A timestamp value is
   an example of such an increasing counter.  Both sides must keep track
   of the last value used by the partner to be able to verify the
   increasing nature of the nonce value received.

   The Nonce TLV must appear prior to the MAC TLV in any place of the LDP PDU.

   MAC generation

3) MAC generation/Verify procedures

   The input into the MAC generation algorithm depends on the type of
   message.

   For LDP Label Request and Label Mapping messages, the input is the byte
   stream built as described in the following figure (the Adapted Length
   represents the actual length of this byte stream, not the length of
   the real LDP Request message).

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-----------------------------+-------------------------------+
    |0|      Message type           |    Adapted Length             |
    +-+-----------------------------+-------------------------------+
    |   key Identifier              |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    |                           LSR  Identifier                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Nonce TLV                           |
    |                                                               |
    +---------------------------------------------------------------+
    |                                                               |
    |                             FEC TLV                           |
    +---------------------------------------------------------------+

   For LDP Notification messages, the input is the byte stream built as
   described in the following figure.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-----------------------------+-------------------------------+
    |0|      Notification           |    Adapted Length             |
    +-+-----------------------------+-------------------------------+
    |   key Identifier              |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    |                           LSR  Identifier                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Nonce TLV                           |
    |                                                               |
    +---------------------------------------------------------------+
    |                                                               |
    |                          Status TLV                           |
    +---------------------------------------------------------------+

4) New Notification message "Authentication Failed" Status Code

   A new Status Code value is required in the LDP Notification message
   Status TLV.  This code is used by an LSR to announce that a
   previously received LDP message has failed authentication.

   The U-bit and F-bit in the Status TLV must be set to '1' so as to
   enable transparent relay of the Status TLV by LSRs.

   The E-bit in the Status Code field of the Status TLV can be set to
   '0' or '1' depending on the local policy of the LSR.

   The F-bit in the Status Code field of the Status TLV MUST be set to
   '1', in alignment with the F-bit at the Status TLV level.

Thanks, 

Morvan.