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

[Jeffrey Haas <[e-mail]>]

[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:
> 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.

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.

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

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.

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.  

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. :-)

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

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

However, these are personal preferences.  Correctness of the mechanism is
more important for this discussion.

> 
> We look forward to a discussion on this point. 
> 
> 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] 

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.

[eliding points that are agreed upon...]

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

> [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 a 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.

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

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.

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?

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.

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

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

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.

OPEN messages are not, as best I can tell, exchanged again once the OPEN
messages are mutually exchanged and ACKed.  

> For clarity, consider labeling Serial Number as "last received serial
>   number".
> [Sue:  It is being sent on an open - so this does not make sense. 
> 
> 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. /
> [end Point-6]

I'm not sure that's correct.

In the context of OPEN, you're informing the other side what the last state
you heard from them was.  That state is updated on your receipt of messages
with Serial Numbers.

> [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-Point 8] 
> 
> [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.


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


-- Jeff