Re: protocol support for intercepting proxies

Henrik Nordstrom wrote:
> tis 2007-06-19 klockan 21:58 +1200 skrev Adrien de Croy:
>> Yeah, this all points to some sort of generic config protocol.
> Which is what DHCP, SRV and SLP all are in the discussed context, at
> different levels..
>> DHCP is just so restricted it's hard to see why so much effort is still 
>> being poured into it.
> Because it serves the purpose of distributing network local
> configuration details quite well.
I wouldn't say quite well.

* negotiated options to overload server->Client message length that 
doesn't even consider client->server message length, and means we have 
to upgrade not only servers and clients to cope with bigger packets, but 
also *network infrastructure* such as routers (relay agents), subscriber 
line modules and managed switches.  Good one.
And results in support burden for vendors and customers, as evidenced by 
http://support.microsoft.com/kb/321592
Even with negotiated size, max is still 64k.  Evokes memories of Bill 
Gates' comments about 640kb being more memory than anyone will ever need :)

* option splitting and concatenation to get around boundary issues of 
the 3 (2 of which are overloaded and must be signalled for use) storage 
areas.
* a single byte for the option id?  so only 255 options.  I guess that 
will be overloaded too.
* all options have been designed to save space in the packet. Many 
options don't have standardised implementations (i.e. relay info).

None of this comes across to me as a protocol particularly well suited 
to the scalability issues that confront it.  There is a large list of 
current I-Ds related to DHCP.  Everyone is trying to shoe-horn things 
into it.  It doesn't have the skeleton for the amount of flesh being put 
on it.  It kinda reminds me of our use of fossil fuels, everyone is 
rushing to get some while there's still any left :)

I think we should take the lead of the designers of the protocol.  They 
weren't dumb.  They only allowed a single byte for the option, because 
the protocol fundamentally was only designed to support a relatively 
small number of options - enough to get IP up and running.  That 
original design tenet has been since ignored, and we are now paying for 
ignoring it.

>> There are now more options than you can 
>> realistically fit into a 576 byte single UDP packet.
>
> And is why DHCP allows for larger messages (up to 64KB), if the client
> says it supports it..
I've not seen such a client advertisement yet (up to XPSP2, haven't 
checked Vista DHCP client yet).  I think the infrastructure issues are 
the biggest ones.  Even if those are solved, we will eventually run out 
even with 64k.  The sooner an extensible system is adopted, the less 
pain there will be down the track with people having to migrate to it.

>> All to do config.  
>> A separate config protocol or framework would be much easier to grow.  
>
> SLP?
Thanks - I need to read more on it.  LDAP is the one that springs to my 
mind though, since isn't SLP only for service location, rather than 
dissemination of configuration data?

Anyway, I think it could be more useful for me to just sketch out a 
proposal about what the results of contemplation of intercepting proxies 
could be, and why.  We got hung up on the auto-config option, but I 
think some guidelines to implementors and operators of intercepting 
proxies, and UA developers could still be useful.

Adrien

>
> Regards
> Henrik

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Wednesday, 20 June 2007 00:12:19 UTC