search

fiorix / go-diameter

Diameter stack and Base Protocol (RFC 6733) for the Go programming language
Other
252 stars 143 forks source link

CER/CEA remote peer validation #189

Closed helioaymoto closed 10 months ago

helioaymoto commented 10 months ago

Is there a configuration which allow go-diameter to validate the remote peer hostname and realm to allow or not to stabilish the peer connection? Or would it be necessary to implement this at application level? If yes then can you give some tips on how to manage this? Kind regards,

fiorix commented 10 months ago

This is not automatic and you'd have to write the code for such verification in the respective handlers.

mtahamasood commented 10 months ago

What do you mean by "validating" ? Do you mean reachable through the network transport layer? If so , then yes the Diameter Peer state machine does require that.

helioaymoto commented 10 months ago

What do you mean by "validating" ? Do you mean reachable through the network transport layer? If so , then yes the Diameter Peer state machine does require that.

In this case I mean that the server shall validate if the remote/client peer hostname and realm is allowed to connect to the server. The CER comes with client hostname and realm, só u would expect some configuration on server side to indicate whether this hostname and realm is allowed or not.... In the way it is now any hostname and hostname would be able to stablish the peers connection to the server As fiorix commented before, I would need to implement this logic.

mtahamasood commented 10 months ago

Some part of this (having a capability exchange handshake aka CER/CEA ) is part of the protocol behavior and will be implemented by any compliant stack on any diameter node.

The other part and point of having a "capability exchange" handshake is to do any further processing based on the connecting node's capabilities ( or lack thereof) and indeed will need to be handled application to application themselves depending on what they want to do.