Re: [Idr] BGP autoconfiguration - draft-ymbk-idr-l3nd

[Minto Jeyananth <[e-mail]>]

Susan,

 Few questions on point 1-b).

  1.  is there any mechanism to avoid UDP hello in multi-access link? The cost of the timer here is not same as draft-minto tighter periodic timer?
  2.  Both BGP and LDP running TCP keepalive apart from TCP keep-alive. Does l3nd add that too?
  3.  l3nd-ulpc exchanges BGP authentication information. does l3nd TCP keychain is configured or exchanged through UPD hello?
  4.  rfc6952 2.4.1.1 describes the attack on UDP multicast. l3nd will add keychain based authentication?
  5.  In multi-access link, l3nd required full mesh of session. Right?

Thanks
-minto

From: Idr <[e-mail]> on behalf of Susan Hares <[e-mail]>
Date: Saturday, March 19, 2022 at 5:04 AM
To: 'Jeffrey Haas' <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Idr] BGP autoconfiguration - draft-ymbk-idr-l3nd
[External Email. Be cautious of content]


Jeff:

Thank-you for letting me know you prefer the response in one long email.
I'll respond to each of your comments below.

Just to recall the high points:

Point -1:
  two types of protocols
a) unreliable transport
          multicast + Key-chain + timers  for every message

b) reliable transport + optional security
        transport (TCP) + key-chain
     or  TLS + Self-Signed/CA-based

The question is whether the timers cost you more than the
transport.

Point-2:
Open Attributes are flexible hints of who is talking.
Session-id != nonce
Serial-number - tracks a set of attributes + encapsulations


Point-3:
Encapsulations may be important to some
and irrelevant to others.


Sue

-----Original Message-----
From: Idr [mailto:[e-mail]] On Behalf Of Jeffrey Haas
Sent: Monday, March 7, 2022 8:56 PM
To: Susan Hares
Cc: [e-mail]
Subject: Re: [Idr] BGP autoconfiguration - draft-ymbk-idr-l3nd

[General note: While I'd prefer to have a response for the original single
message in a single response, I'll be responding to the individual replies.
This should help those with threaded mail readers track the responses
better.]

Sue,

On Sat, Mar 05, 2022 at 12:05:25PM -0500, Susan Hares wrote:
[Jeff - Point-1 ]:
> Please see the text in draft-ymbk-idr-l3nd-01:
>Similarly, please note that my original post was vs. -00 of the draft.
Have
>care at trying to move the goal posts mid-conversation. :-)

>>   The server, the sender of the HELLO with the lower IP address,
>>New procedure since -00.
>>    listens on the advertised port for the TLS/TCP session open.
>While it's possible that the receiver only creates its TCP listen socket
after
>hearing a HELLO from another sender, this isn't typical listen socket
>coding.  It's far more typical for a TCP listener to have a socket open and
>ready to receive incoming sessions.

[Sue:  Yes, -01.txt correct errors or things that were missing]
[Sue]: However, when you have the Hello sequence, this can be restricted.

[Jeff - Point 2]
>>If the receiver of a HELLO that is also sending a HELLO determines it is
the
>>lower of the IP addresses and instead chooses to dynamically create the
>>listening socket at that time, it would have the properties of:
>>1. The listening socket is available less of the time, which may be mildly
>>protective of attacks against the TCP stack.
>>2. However, introduces timing considerations before the initiator of the
TCP
>>connection would be able to connect.

>If your intent is to have deferred listen socket creation as normative
>procedure, you will want to have related normative text for the connector
to
>try to reduce connection time.  Otherwise, you're looking at slowing down
>discovery.

[Sue]: The configuration time is  configurable.
Your description is system dependent - so I suspect the people
creating a particular router will tune it.

   Once the TLS/TCP session is established, if the link is configured as
 point to point, the client side SHOULD stop listening on any port for
  which it has sent a HELLO.  The server side SHOULD stop sending
   HELLOs.

[Jeff- Point-3]:
L3DN lacks a state machine with named states similar to BGP, so my comment
here will be somewhat imprecise.

Your text above says HELLO is stopped when TLS or TCP is established.  Those
are slightly different events.  TLS requires TCP, so you could stop HELLO
there.  TLS will go through its Handshake Protocol exchange. (RFC 4346,
§7.3)
Was that where HELLO should stop when TLS is enabled?

If HELLO stops at the first TCP connection accepted, it permits an attacker
to stifle HELLO messages from legitimate parties.

Similarly, if only a single incoming TCP connection is permitted until TLS
session is up (handshake has completed), it permits a similar denial of
service.

[Sue - Point-3]:  A particular implementation will configure TLS or TCP per
port.
At that point, if TLS is configured then it will keep the Hello going until
the TLS is up and running.    Adding a state machine to the L3DN, is
a good idea.

[Jeff - Point-4:]
>Perhaps related, HELLO perhaps should not stop until L3ND mutually
exchanges
>and positively ACKs their OPEN messages.  That might make a better sync
>point to stop HELLO, although it still means addressing the TCP session
>questions.

>In BGP parlance, the mutual exchange of OPEN and positive ACK would be the
>Established state.

[Sue: Point-4]:  The cost in keeping the Hello going until L3ND
mutually exchanges is more messages on the wire.
The trade-off at the TCP/TLS level was my choice.
The WG can make a trade-off later.

[Jeff: Point-5]
A few extra notes:
- L3ND doesn't have any normative references to TLS.
- The Security Considerations section recommends at least TLS 1.1
- RFC 8996 deprecates TLS 1.0 and 1.1.  If there's compelling reason to
  support TLS 1.1, it might be worth mentioning why.  It's not as if BGP
  hasn't been using the deprecated TCP-MD5 for years. :-)

[Sue-Pont-5]
Thank  you for mentioning this.  It should have been 1.2 or higher.
A normative reference to TLS would be useful to add.

[Jeff-Point-6]
> The L3DN - proposes BGP auto configuration that
> supports reliable transport with security.
>
> Open, Encapsulation, Ack - run over TCP (or TLS)
> that provides reliable ordered delivery.
>
> Open PDUs are required PDUs  that have:
> 1) a nonce (like a message ID)
> "Enables detection of a duplicate OPEN PDU" (p. 11, paragraph 2).

I think it's more precise to call the nonce a session ID.  One of its
purposes in the procedure is to permit a pre-existing session to be resumed.

I remain unclear why there would be "duplicate" OPEN PDUs on the same TCP
session.  TCP is a reliable protocol.  Is the expectation that the receiver
is taking a reliable protocol and randomly discarding messages?

[sue-6]
A nonce is not a session-id.  It is a nonce.
A nonce prevents "man-in-the-middle" attacks for the TCP
variant of the protocol or some bug in the system.
It is less likely in the TLS version.

The purpose is: "It is needed to prevent a session closure due to a
Repeated Open caused by a race or a dropped or delayed ACK" (-p. 11).

[Jeff-Point-7]
> 2) serial number - "representing the senders state at the time of
> Sending the last PDU" [p. 11 last paragraph)

> Encapsulation PDUs are optional  PDUs that have:
> 1) serial number - "representing the senders state at the time of
> Sending the last PDU" (p. 15)
> 2) Flag for Announce/Withdraw of encapsulations

> Encapsulation PDUs do not have a nonce.

> Ack PDUS - send by receiver of Open/Encapsulation PDUs
> To indicate status (Ok, Warning, Broken session, Warn operator)
> To acknowledge a specific type of PDU
> (Open, Encapsulation PDUs (4-7
> ACKs PDUs.   Do not have a nonce or a serial number.
>
> The WG could suggest adding nonces to Encapsulation PDUS
> so all PDUs have a message id, and adding the nonce value to
> ACK PDUs.   There are pros/cons of adding this state for debugging
> versus bytes on wire + implementation states.

>> As a mechanism to identify a restarting session, the nonce is a fine
session
>> ID.  Personally, my question is more about whether the necessary state
>> retention and refresh mechanisms are worth the additional complexity in
the
>> protocol.  I'd personally recommend that a session restart simply replay
all
>> necessary state fresh.

[Sue-7]:
The encapsulation allow the L3DN players to exchange data across multiple
subnets.
(e.g. page 16).
I will cover this point in a unique post to the list.

[Jeff-8]
> L3DN is not a "shout in the dark" bgp auto-configuration protocol.
> I define "shout in the dark" protocol as one which
> 1) does not provide reliable transport
> 2) uses authentication/Hash based security

In fairness, I labeled such protocols as shout in the dark but that's a
reasonable summary of it. :-)

[...]
> [snip - to make it easier to respond to.
> My previous message answered the questions
> Regarding scope and transport]
>
> [Point 1 - Protocol state]
> Protocol state and FSM considerations:
>
> > - Similar to BGP, parallel session are a possibility.  I'm unclear how
> >   connection collisions are handled.
> >   + The procedures seem to try to cover this by saying "drop hello when
> >     there is an established session".  However, timing could result in
two
> >     sessions happening in parallel prior to drop.
> >   + There isn't a clear idea of the FSM having an "established" state,
or
> >     the related "OpenSent/OpenConfirm" states similar ot  BGP that could
> >     prevent this?
>
> [Sue] The solution used by IETF LDP or IEEE parallel sessions is
> to pre-define the resolution.  Please see the above text from
> draft-ymbk-idr-l3nd-01 that resolves this issues.
> [End point 1]

[Jeff:  Point-8]
As I briefly noted to the publication notice for -02 of this draft, this
changes a property of the protocol: It requires both sides to run the HELLO
mechanism.  A consequence of this is that it's no longer possible for a
single side to act as a HELLO sender - likely in a "server" role.

For point to point deployments, this isn't a big deal.

For multi-access deployments that are intended to result in some form of
full or partial mesh, this still isn't a big deal.

For multi-access deployments that are intended to have a small number of
devices acting as the end point for a BGP session, this is problematic.
You'll have attempts at full mesh peering when perhaps a tiny number of
devices want to peer with each other.

[Sue-8:]
  I am not clear why you state these three points above.
  The text states:
"The Hello PDU solicits a unicast TLS/TCP session open request
Of the same AFI from other devices on the link." (p. 9, -02)

Only if there are two directions for hello, does the case in the
Next step work.  "When a hello is received from a source
IP address with which there is no establish TLS/TCP L3ND,
If the receiver has the higher of the two IP addresses, it should respond. "

I do not see where you are getting any of the rest of the text.
Please provide examples and text from the -02.txt.



[Jeff-point-9 for this email]
> [Point 3 - size of Attributes]
>   + Also, why so small?  Payload length appears to be 4 octets.  A larger
>     value permits more flexibility for local semantics; e.g. bit vectors.
> [Sue:  Were open to hearing pros/cons of 1 byte vs. 4 bytes
>   from the IDR WG.   If we use fixed lengths (1 or 4) both are useful.]
> [end point 3]

My personal opinion is that fixed length is fine for the application.  The
Working Group will likely have opinions about the size.
 [Sue: agreed that size on attributes is ok]

[Jeff: point 9 this email]
> [Point 4 - Resuming session]
>   + Is there significance to resuming a session using the documented
>     procedures when the Attributes may not be identical to the ones
> previously
>     received in the interrupted session?
> [Sue:  Yes.
> Nonce - provides detection of duplicate Open
> Serial number - indicates a single state of the Database
> which contains a set of optional attributes + encapsulations. ]
>
> Let's look at duplicate Open:
> Nonce is the same, and Serial number is the same.

For clarity, I think there's some confusion in using the term "duplicate" in
this context.  It's not a duplicate on the same established session.
Instead, it's [an] Open that has a nonce that matches a previous transport
session.

If that's the intent, I'd suggest either different verbiage or make sure and
define the context for duplicate.

[Sue- Point 9: ]
Jeff - A nonce is just a "nonce".  It is not a session id.
It is a common term in many protocols to prevent a "man-in-middle"
attack.  It is not a session-id.

[Jeff- Point-10]
(long sequence on my example)

>> Let's look at Attribute change
>> Nonce is different, Serial number is different
>>That's not the scenario under consideration.  If the nonce changes, it's a
>>restart of the session.

[Sue-10a] If that's the intent, I'd suggest either different verbiage or
make sure and
define the context for duplicate.

>OPEN messages in the loosely defined state machine are intended to be sent
>at the start of the transport session once data can be exchanged.
[Sue-10b]
The open is sent with a "hello".
Nonce = identifier for duplicate Ack (man in middle attack)
Serial number = data base.

>Serial numbers are loosely specified as advancing per packet.
>If no additional OPEN message is sent, how would the Serial Number advance
>for a change in Attributes?

[Sue-10c]
It could be that a "policy" in the
L3DN has logic that says - try another set of attributes.

>I think your intent is likely that if the Attributes do not agree for the
>same session (Nonce) that Something Must Happen.  Is it a session bounce?
>I'm not sure what your intent is.

[Sue-10d]
The idea is that if you keep lots of encapsulations.
Or have attributes to catch something plugged in wrong.
Then, the attribute or database is correct.

>> Let's look at restart of system
>>Nonce is different, Serial number is the same.
>If Nonce is different, the text says that it is not a session restart.
> Why care about what is in the DB:
> Example:
> Box1-Box2 (hello, TCP-setup)
> Box 1 Open-1: With Attribute RR1
> (Indicates will accept 6 AFI/SAFIs in BGP)
> Nonce: 3030
> Serial number: 1
> Box2: Ack-Open: Error (1) - Error hint (not RR1 flag, RR2 flag)
> Box2: Open-1: Attribute: RR client
> Nonce: 7070
> Serial number: 50
> Box-1: Ack-Open

> Box-1 Open-2:  RR2 (accepts 5 AFI/SAFIs)
> Nonce: 6060
> Serial number: 2
> Box-2: Ack (0) no error

>Why is Box-1 sending OPEN again?
[Sue-10e]
Different attribute list.  (Just as stated)

>> Box-1 reboots
>> Box1-Box2 (hello, TCP-setup)
>> Box1: Open-3, Attribute RR2
>> Nonce:  100
>> Serial number: 2
>> Box2: Ack-open (ok)
>> [Point 4 end]
>> I think the above example may be a bit off.  Perhaps another try at it?

[Sue-10f]
The example is not off.
No, you are missing the point of the attributes.

The intent from the specification seems to be that when a session comes up,
and the data matches a previously exchanged Nonce, then you can use matching
serial numbers to do selective replay.  That's fine.

[Jeff-point-11]
OPEN messages are not, as best I can tell, exchanged again once the OPEN
messages are mutually exchanged and ACKed.
[Sue: 11a]
The machine running L3DN can go down and come up.

> For clarity, consider labeling Serial Number as "last received serial
>   number".
The serial number is a database-id.

>> Old Text:  The Serial Number is a monotonically increasing 32-bit
>> value representing the sender's state at the time of sending the
>> last PDU. /
> New text:
>> The Serial Number is a monotonically increasing 32-bit
>> value representing the sender's state at the time of sending the
>> this Open PDU. /
[Sue-11b]:
In the context of OPEN, you're informing the other side what the last state
you heard from them was.  However, you are correct, the original text was
correct.

Text -02:  "The Serial Number is a monotonically increasing four octet value
Representing the sender's state at the time of sending the last PDU. "


[Jeff- point-11 (old point-8)
> [Point-8]
> - The Etype conditions are a bit lax for a useful state machine for what
we
>   have documentation for:
>   + If Open can't be acked successfully, should the session be permitted
to
>     continue?
>   + Is "restart is hopeless" a shutdown?  An admin-down?  What should the
>     implementation do with its PDUs?  Should it tear down the session?
>
> [Sue: Some of L3DN authors suggested deleting the ACK.
> The Open-Message contain attributes each side is willing to handle.
> The ACK simply gives remote side error indicates which may allow
> automation of the fixes.

It's your protocol.  I agree that you can live without ACK in many
circumstances.  You will likely need it as a mechanism to make sure you
mutually exchange OPEN and ACK prior to starting to send other PDUs.

It'd also maintain some level of similarity to the BGP FSM.  If so, consider
borrowing the state names.

While the OPEN message lacks any semblance of the BGP Capability mechanism,
it's pretty easy to visualize that some dependency on behavior based on
received Attributes has similar properties.

> My example for point 7 gives a positive example for the "warning" (1).
>
> An example for the restart, is a detection of misconfiguration
>  [You are sending me attributes that I think are broken]
>
> An example for hopeless restart (admin-shut down)
> is if the Open contain multiple broken attributes.

If the intent of restart is hopeless is that things are locked into an
AdminDown type state, there should be normative text as to what that does to
the state machine.  For example, HELLO might not resume once the TCP session
is dropped.

> The minimum Ack PDU requirements are handle ACKed PDUs,
> Etypes, and Error codes.   The rest is extensible for each
implementations.
>
End[New-point-11 /Old Point 8]

Sue: A state-machine is useful in the iteration after adoption.

[Jeff New-Point-11]
> [Point-9]
> - 3 seconds seems a bit low for a response timeout.  While the protocol
>   seems to be structured toward easy restart, why disconnect so
>   aggressively?
> [Sue] The timeout on OPEN receiving an ACK is configurable
> With 30 seconds as a timeout.
> [end-comment]

This was in reference to section 10.1.  The value has been updated to five
seconds... which still seems like a short default. :-)

The retransmit behavior again seems peculiar for a reliable TCP session.
>
> - The message exchange protocol is "one outstanding ack" which means there
>   is no pipelining of the various messages.  Given this, the lack of a
>   serial number being acked in the message is understandable, but seems
like
>   it'd be good debug info.
> [Sue:
> The 4 byte Nonce identifies the open message.
> The 4 byte serial number identifies the DB state.
> Are you looking for the Nonce to be echoed in the ACK for the OPEN?

I'm commenting that the ACK PDU (Section 9) does not contain the Serial
Number that it is acknowledging.

[Sue: (New:11/old: 9) A Serial number could be added to the ACK, but there
Is a trade-off here]

[Jeff-12]
>   + That lack of pipelining means that full exchange of state will be
gated
>     on slowest sender on the session; the transmitter or the
acknowledger..
> [Sue]
> TCP/TLS provides reliable transmission and ordering on the pipeline
> in each directions.
> OPEN has a nonce (message ID),  Encapsulations (ID 4-7) do not.
> Serial number gives the DB state with attributes + encapsulations.
>
> Are you suggesting:
> 1) Augmentation of the Encapsulation header with nonce (message id)
> 2) ACK PDU header contains the nonce of the open/Encapsulation header
> 3) We allow (as some IEEE protocol do) the batching of
> ACKs in one TLV?
>
> All this is possible, but it is a trade-off that the authors would like
> feedback on.
> [sue]

I'm suggesting that the protocol is "call and response".  You send a
message, you want an ACK for it.  This means that in spite of the fact that
this is TCP and there are buffered windows to transmit into in a reliable
fashion, no PDUs are placed into the TCP stream until the prior PDU receives
an ACK PDU.  This is a one-bit flow-control mechanism.

Sue-12:  TCP guarantees the right number of bytes.
TCP does not guarantee the syntax of those bytes to be correct.
The Ack is replying to the syntax of the message.



-- Jeff

_______________________________________________
Idr mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!TmhAR2N3V-_dp8Rgj1nEy5nCfQLccjMP5gTeFjwcGFy01QA7YkxJT4Rqmse0rw$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!TmhAR2N3V-_dp8Rgj1nEy5nCfQLccjMP5gTeFjwcGFy01QA7YkxJT4Rqmse0rw$>

_______________________________________________
Idr mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!TmhAR2N3V-_dp8Rgj1nEy5nCfQLccjMP5gTeFjwcGFy01QA7YkxJT4Rqmse0rw$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!TmhAR2N3V-_dp8Rgj1nEy5nCfQLccjMP5gTeFjwcGFy01QA7YkxJT4Rqmse0rw$>


Juniper Business Use Only