Rewrite of IP assignment section #21
Conversation
|
Hi Mirja, Your PR unfortunately contains lots of typos and language that I am having a hard time parsing. Could you please provide a description of what this rewrite is trying to address? Otherwise, I am not sure I can provide an effective review. Sincerely, |
draft-ietf-masque-ip-proxy-reqs.md
Outdated
| request. | ||
| The IP addresss or range of IP addresses can either be assigned by the client | ||
| or the proxy. If the address is assigned by the client, proxy has to ensure | ||
| that the IP address is from a valid range that the client authorty of and that |
There was a problem hiding this comment.
Do we need this detail in the requirements? I am hoping that we should be able to remain unopinionated about what it means for the address to be 'valid' which I suspect will mean different things to different implementers.
I think only specifying that the recipient of the request has the means to reject it should be sufficient. Are there use cases you're thinking of where we need this stronger requirement?
There was a problem hiding this comment.
I think this is actually important to ensure that a proxy is safe to deploy. If you deploy two proxies between two datacenters which are both controlled by the same entity, you might skip that validation and trust the client. But if you have proxy that connects the client to the "open" Internet, you should check that the address is not spoofed.
There was a problem hiding this comment.
Hey Mirja,
I absolutely agree that it is important that a proxy has the opportunity to accept/reject a request to establish an ip proxying session -- and to accept/reject a client's choice of ip address.
However, I'm not sure it makes sense to be strongly opinionated about the validation that is required on the proxy (or are we just quibbling on semantics?). As you mention, there are different scenarios where the proxy may want to validate different properties of the request. So long as the protocol provides all necessary hooks for the proxy to perform validation and make accept/reject decisions based upon that validation, I'm not sure what value there is in making it a requirement that the proxy perform some specific form of validation (which seems likely to be deployment-dependent).
There was a problem hiding this comment.
I think we are quibbling a bit on the right level that we want to express the requirements. And there might be even more than one requirement here.
There seems to be a function requirement here where we specify who gets to decide. Having a request mechanism that then naturally could also be rejected, could actually be also seen as an implementation details. But again, not sure what's the right level here want to state things on. (That's the hard part of requirement documents).
The other thing that I think we should cover somehow is a security requirement to avoid that the proxy can be misused to make spoofing easier.
There was a problem hiding this comment.
I would make validation a separate requirement instead of conflating it with the IP assignment requirement
There was a problem hiding this comment.
I'm not opposed to splitting things up like that, but I worry that by explicitly enumerating them, we will imply that other policies or enforcement points are prohibited/non-requirements. We've already seen that in other discussions. As a result, my preference is to leave this as-is.
There was a problem hiding this comment.
The point of my proposed wording (which might also not be optimal yet) is that I think the requirement at the moment has not the right level of abstraction. The requirement talks about a request which is a concrete design, while the requirement should probably stay more on the level of who get's to decide. My reading of this requirement was that you would like to see support of both cases where either the client or the proxy does decide about the assignment.
There was a problem hiding this comment.
Your reading is correct. The requirement is intentionally written this way to allow assignment by either the client or server, as there are cases where that is required. In the typical VPN use case, the server will be assigning one or more addresses to the client, but in a network-to-network (aka site-to-site) VPN the client is informing the server of the IP ranges it is making accessible.
There was a problem hiding this comment.
Can we work on the wording to make it more a high level requirement and less specific to any mechanism on how it could be realised?
There was a problem hiding this comment.
What in the wording would you like to see be made more high level? I think it is fine as-is.
|
Sorry I was in a hurry yesterday. Fixed all the typos and missing words now. |
| or the proxy. If the address is assigned by the client, the proxy has to ensure | ||
| that the IP address is from a valid range that the client has authority of and that | ||
| return traffic is routed correctly over the proxy. |
There was a problem hiding this comment.
| or the proxy. If the address is assigned by the client, the proxy has to ensure | |
| that the IP address is from a valid range that the client has authority of and that | |
| return traffic is routed correctly over the proxy. | |
| or the proxy. |
I can remove the sentence about validation (because that can indeed be seen as a separate discussion), however, I would still like to see the rest of the PR as there are two cases which should be covered here: 1) the client request a certain IP or IP range, or the proxy just assigns an address and tells the client about it.
No description provided.