[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: phase 2 and ports



 > 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



Follow-Ups: References: