Add text about routing advertisement to security considerations

[gloinul]

I think there are need for a more significant discussion of the quite serious implications of route advertisements made with malicious intent. I think the most obvious would be for a MASQUE server to attempt to advertise prefixes it believes the MASQUE client might send traffic on using its other interfaces, to thus enable the MASQUE server to intercept the traffic by redirecting it through the MASQUE tunnel.

So please expand on this in the security considerations on these matters.

[DavidSchinazi]

The text is pretty clear about these messages being purely informational, but I agree that we should add more text to security considerations to mention common pitfalls.

[gloinul]

Actually I am reacting to you calling the informational. It might be optional to attempt to use the route provided by the advertisements, however the mechanism and its specification is a normative specification to follow if one uses it. And it has a purpose of informing the peer endpoint that you claim that you have routes. Using that information has implications and thus need to well explored in the security consideration. In the same venue also optional mechanism has normative references.

[DavidSchinazi]

@gloinul I don't think I understand what you meant by https://github.com/DavidSchinazi/draft-cms-masque-connect-ip/issues/2#issuecomment-820676840 can you try to reformulate it please?

[gloinul]

In the comment above you state "these messages being purely informational". I have some concern with this formulation for two reasons. Yes, they provide information to the peer endpoint. However, that information is intended to be used by the peer to determine if it should route traffic (e.g establish a routing table or use the address at all) to the peer, and in that case get the traffic forwarded towards an destination. Secondly, the use of the word informational could be misinterpreted to mean that the protocol mechanism is informational. To make this work it is a protocol mechanism that needs to be normatively described.

The last point in my previous comment was simply to state that there are no difference in requirement on how things are specified including security considerations and mechanism between optional to use protocol features and required ones.

The reason I am commenting on this is that I am of the belief that the general route advertisement mechanism when used for establishing routes across the masque endpoint, primarily in the network to network tunneling case one create situations where significantly more considerations are needed. If an endpoint uses an assigned address only to source locally generated packets and not to route across it many operational and security issues do disappear related to potential routing loops, return path impact, possibility to do source address validation.

[DavidSchinazi]

Thanks for clarifying. We'll add text to security considerations.

[DavidSchinazi]

Fixed by #17