Q:

Key recovery when AES ECB is used for short but repeated messages

My question is based on the specification of the protocol LoRaWAN and especially on the part 6.2.5 Join-accept message.
It is said that the join-accept message is encrypted using AES ECB. This is (normally) a single message created like that:
aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | RFU | RxDelay | CFList | MIC)

Imagine that an attacker can listen the communications. He doesn't know AppKey (obviously), AppNonce and of course the MIC. If the attacker can make the end device send plenty join-request messages and if the server always responds with a corresponding join-accept message, can the attacker gain knowledge of the AppKey using the flaws in AES ECB?
Disclaimer: sorry if I'm not clear, cryptography is not my speciality. 

A:

If the attacker can make the end device send plenty join-request messages and if the server always responds with a corresponding join-accept message, can the attacker gain knowledge of the AppKey using the flaws in AES ECB?

No. ECB is flawed, but not that flawed.
At worst the attacker can know the encryption of a message if they have already seen the same message encrypted. (Or decrypted, as the case may be - LoRaWAN uses the decryption direction here to avoid having to implement both directions in the end-device.)
That can still lead to attacks, but key recovery is not possible.

A:

ECB mode has several weaknesses as discussed in Why shouldn't I use ECB encryption? but in this specific case, it does not allow to gain information about the secret key AppKey involved.
Indeed, encrypting the same block with the same AppKey will returns the same ciphertext. But in the LoRaWAN join-accept message, it does not matter because the server encrypts only one 16-byte block which is AppNonce | NetID | DevAddr | RFU | RxDelay | CFList | MIC.
Plus, each such block should be different because as specified in the LoRaWAN specification :

The AppNonce is a random value or some form of unique ID provided by
  the network server

The DevAddr consists of 32 bits identifies  the  end-device within 
  the  current network

If the attacker can make the end device send plenty join-request
  messages and if the server always responds with a corresponding
  join-accept message, can the attacker gain knowledge of the AppKey
  using the flaws in AES ECB?

Note that a join-request has the following structure : AppEUI | DevEUI | DevNonce where AppEUI identifies the application and DevEUI identifies the end-device. So if an attacker make the end-device send plenty join-request messages, the server should remember that the device identified by DevEUI made a join-request a few time ago and should respond with the same DevAddr (or not respond at all) to avoid denial-of-services attacks. But I did not see anything about it in the specification.

