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

Re: clear ports



> From: Greg Minshall <minshall@ipsilon.com>
> I guess i'm not convinced that a priori it is necessary to require that ESP
> cover up the protocol/ports.  I think that in many many cases, what people are
> trying to keep private is the payload of the transport data (eg, passwords,
> payroll data, etc.).  I think that in some cases, traffic analysis (at the
> level of ports/protocol) is something people want to protect.
>
While it is true that very few folks are really worried about traffic
analysis, it might be possible that breaking the session-keys could use
information about what protocol header is inside the encrypted data, to
look for regular patterns.  So, it is probably best to hide that
information.

Meanwhile, I think your problem model can be easily solved (from my
meager understanding of your product) by thinking about the two major
cases: firewall virtual private networks, and client/server.

 1) Firewall VPNs will look to your product very much like a single
    flow.  The packet sizes might change, but in general the forwarding
    will be identical on every packet.  Should be a fast decision for
    you.

    I doubt there are many firewalls using TOS, but it is certainly
    possible, and you could cue off that for different services.  But I
    would expect that the firewalls have already done the WFQ and such
    for their own users, and you won't be able to add much value.

 2) For client to server and vice versa, you have 2 routing clues; the
    addresses (of course) and the SPIs.  Different users will have
    different SPIs.  Each telnet or FTP will have a different SPI.

    The SPI behaves very much like a port pair, albeit you don't know
    for what services.  If you are looking at characteristics of the
    flows, the TOS associated with the SPI might help here, too.


> Below is (what i believe to be) the IPSEC charter; i don't believe that it
> answers the question "to encrypt ports/protocol or not to encrypt
> ports/protocol?".
>
Well, I wouldn't put too much faith in that charter.  Look at the dates
for completion....

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2