[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: phase 2 and ports
Jan,
typically, those applications have one "static" port number (when they are RFC compliant).
E.g. FTP data connection _should_ have one side connected to port 20.
This solves most (common) issues. Beyond that, up to protocol designers to take care about what they do if security is a concern.
I admit, not everything will behave like this but port negociation is broken in essence: what to do with a fragmented packet for instance ? The port numbers may not appear anymore; how do selectors match then ? Do we have to keep track of the IP packet-id in case we see the next fragments ? Then what if the encryption process is load balanced across devices ? (and so on with more and more problems).
There is no complete solution to this. It would be better to fix a range of validity on what IKE can negociate and let network or protocol designers deal with it.
My opinion is that we should not make IKE more complex than it is; this is a pandora box which will lead to subtle mis-configurations and problems.
fred
Jan wrote:
> Here's the problem: Some protocols float ports (example l2tp, ftp, h.323, to
> name a few). Other protocols a priori use more than one port (can't think of
> any examples, but I don't see why this couldn't be the case), yet the ID
> payload has a field for a single port only. There's no way in IKE to
> negotiate something like src-ip=A, src-port=8-10, dst-IP=B, dst-port=8-10 (an
> example only).
>
References: