likely to cause trouble than to have relative naming (e.g. the port
as Spot sent Harry on port 3000).
in the IKE negotiations.
>>> Bill Sommerfeld <sommerfeld@East.Sun.COM> 06/23/00
07:31PM >>>
> I was wondering if anyone had a good solution
to this problem, or if people
> are interested in one in general. Maybe
people don't think this is a
> problem?
This is a real
problem.
> 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).
>
> As far as I can tell, you'd have to negotiate one SA per port, i.e. 3
SA's in
> the above example (times 2, since we're doing
bidirectional).
Multiple SA's isn't necessarily a problem -- from a
crypto-paranoia
standpoint, it's better to use different keys for different
things.
To reuse ftp as an example, the files being transferred and
the
control channel may want very different protection. (e.g., if
you're
uploading stuff to an anonymous FTP site you may only need
integrity
protection on the ftp-data connection but want to keep the
passwords,
etc., on the control connection secret).
The tricky part
comes with knowing which policy to apply to the
floating
port..
[aside: If there's a perception that the multiple phase-2
exchanges
needed are a performance problem then maybe I should go resurrect
my
inline keying draft..]
> b) an application-ID would be usefull
for applications that do NOT know a
> priori what ports
to use (l2tp for example). I could see using the tuple
>
protocol:port as an application identifier, and somehow 'teach' ipsec
to
> identify what traffic constitutes that
application.
warning: This opens a naming can-of-worms.
With some
application assistance (i.e., ftpd telling the stack "I want
the data
connection I'm initiating to connect back to the same
principal/entity which
initiated the control connection i accepted")
this might not be so
bad.
I'm increasingly coming to think that we need to start specifying
the
handling of principals and identities within IPSEC and IKE a bit
more
closely. for what it's worth, I like the general properties of
the
model presented in [1] quite a bit, but fitting that into the
existing
IKE framework will be messy.
> P.S. I know of at least one
vendor that solves this problem by using port=0
> (i.e. 'all ports') and
filtering traffic behind ipsec.
It's their right to do this, but it's
pretty unfriendly.
- Bill
[1]
Authentication in Distributed Systems: Theory and Practice
Butler Lampson,
Martin Abadi, Michael Burrows, Edward Wobber
http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-083.html