You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Derek Dagit <de...@oath.com.INVALID> on 2018/08/06 21:48:07 UTC
[DISCUSS] Following redirects to 'localhost'
ATS can be configured such that when it receives a redirect (3xx) response
from an origin server, it will follow the redirect itself rather than
return the response to the client.
Consider the scenario when the redirect response contains a Location header
field with a destination of localhost.
In a forward-proxy scenario, where the origin server is "outside" the
network, redirects to the localhost are not desirable.
In the reverse-proxy scenario, where the origin server is "inside" the
network, redirects to localhost are generally not desirable either.
Exceptions to this might be when the origin serves requests from the same
host as the proxy, and as a convenience when writing functional tests such
that they can exercise redirect following without the need for a local DNS
setup.
We are considering changing the default behavior to stop following any
redirect when its destination is localhost (or its variants) when following
of redirects has been enabled.
A config would be added, with noticeable warnings, that would enable the
former behavior and allow redirects to be followed to localhost.
1. Does this seem like a good change to make?
2. How we would handle the redirect-to-localhost case under the new
behavior. Should we return a 403? A 500? Or should we return the redirect
response back to the client as-is?
3. Should we add a way to configure a sort of policy for when to follow
redirects and what response to return on no-follow, or should we have a
simple config boolean value and a standard behavior?
Looking forward to your input,
--
Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Alan Carroll <so...@oath.com.INVALID>.
If you want to get fun, extend "ip_allow.config" to control what redirects
can be followed :-).
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Alan Carroll <so...@oath.com.INVALID>.
I think it obvious the ultimate check should be "is the upstream address a
loopback address?". Textual comparisons are going to get hacked, we must
check the actual IP address that will be used.
On Mon, Aug 6, 2018 at 7:25 PM Derek Dagit <de...@oath.com.invalid> wrote:
> 1. Yep
>
> 2. I see multiple possible answers as well...
>
> 3. ... and the 0,1,2-style config having either default sounds OK.
>
> Regarding 1)2), Could we resolve and then check if the address is a
> loopback address?
> 3) Hmm, not sure about the use of *cast addresses either.
> 4) The VIP deployment I'm used to will actually set up the host such
> that the VIP name resolves to the loopback address, so the above works.
> That might not be good enough for all deployments though.
>
> On Mon, Aug 6, 2018 at 6:16 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> >
> >
> > > On Aug 6, 2018, at 4:50 PM, Alan Carroll <solidwallofcode@oath.com
> .INVALID>
> > wrote:
> > >
> > > 1. Yes.
> >
> > Agreed.
> >
> > >
> > > 2. I think a 403
> >
> > I can go either way. The HTTP way would be to just return the Location as
> > is (i.e. retain the redirect), following redirects is a little
> unorthodox.
> > Maybe since we are adding new configuration(s), maybe make it such that
> the
> > behavior can be configurable either way?
> >
> > Depending on if we add another configuration, or add on to the existing
> > one, I’m thinking something in the line of
> >
> > 0 - Always allow follow redirect
> > 1 - Allow follow redirect, but return the normal redirect if it’s
> > for localhost
> > 2 - Allow follow redirect, but give a 403 if it's to localhost
> >
> >
> > My vote would be for 1) to be the default, but I can live with 2) as
> well.
> >
> > Question: The notion of “localhost” is a little vague here… I think
> > there’s a number of other ways to reach “localhost”, rather than just
> > localhost/127.0.0.1:
> >
> > 1) FQDNs
> > 2) One of the possibly many IPs that are local to the box,
> > including IPv6 link-locals
> > 3) Possibly some broadcast or multicast addresses??
> > 4) The upstream VIP IP that might point back to the box(es)
> >
> > I think there are many ways that someone could make a follow redirect
> loop
> > back to itself, or a peering proxy.
> >
> > Cheers,
> >
> > — Leif
> >
> >
>
>
> --
> Derek
>
--
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Derek Dagit <de...@oath.com.INVALID>.
> > Leif, can we make this "overridable" in follow-on work?
> Sure.
#4145 is merged.
Created https://github.com/apache/trafficserver/issues/4252 for the
"overridable" task.
On Mon, Aug 27, 2018 at 2:57 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > On Aug 27, 2018, at 11:45 AM, Derek Dagit <de...@oath.com.INVALID>
> wrote:
> >
> > Leif, can we make this "overridable" in follow-on work?
>
> Sure.
>
> — Leif
>
> >
> > This is a bit tricky because of custom parsing.
> >
> > On Sat, Aug 25, 2018 at 6:21 PM, Leif Hedstrom <zw...@apache.org> wrote:
> >
> >>
> >>
> >>> On Aug 24, 2018, at 12:31, Derek Dagit <de...@oath.com.INVALID>
> wrote:
> >>>
> >>> Sounds good let me take a look.
> >>>
> >>>> On Fri, Aug 24, 2018 at 12:24 PM, Bryan Call <bc...@apache.org>
> wrote:
> >>>>
> >>>> I am OK with it. I would add a default tag, so you can specify what
> >>>> action to take by default if there is no match (e.g.
> >>>> routable:follow,default:reject).
> >>
> >> And we can make this overridable i hope?
> >>
> >> — Leif
> >>>>
> >>>> -Bryan
> >>>>
> >>>>
> >>>>
> >>>>> On Aug 24, 2018, at 9:16 AM, Alan Carroll <solidwallofcode@oath.com.
> >> INVALID>
> >>>> wrote:
> >>>>>
> >>>>> Derek and I discussed this earlier this morning and we think the best
> >>>>> option is to have a new configuration variable instead of bringing
> back
> >>>> the
> >>>>> old one, something like "proxy.config.,http.redirect.actions
> STRING".
> >>>>>
> >>>>> The string would be of the format "tag[:action],tag[:action],...".
> >>>>>
> >>>>> The tag would be one of the enumerations
> >>>>>
> >>>>> * private : Private (non-routable, RFC-1918) addresses.
> >>>>> * loopback: Loopback address (all of 127/8 and IPv6 loopback)
> >>>>> * multicast: Multicast address
> >>>>> * link-local: IPv6 link local address
> >>>>> * routable: Globally routable address.
> >>>>> * self: Addresses assigned to this host.
> >>>>>
> >>>>> The action must be one of
> >>>>>
> >>>>> * follow: Internally follow the redirect up to the maximum count.
> >>>>> * return: Do not process the redirect, send it as the proxy response.
> >>>>> * reject: Do not process the redirect, send a 403 as the proxy
> >> response.
> >>>>>
> >>>>> or omitted, in which case it is treated as "follow", although Derek
> >> would
> >>>>> prefer to require the action in all cases.
> >>>>>
> >>>>> If a tag is omitted, it is treated as if it were "tag:return".
> >>>>>
> >>>>> This provides very fine grained control. The default would be
> >>>>> "routable:follow", which means "follow routable redirects, return all
> >>>> other
> >>>>> redirects".
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Derek
> >>
> >>
> >
> >
> > --
> > Derek
>
>
--
Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Leif Hedstrom <zw...@apache.org>.
> On Aug 27, 2018, at 11:45 AM, Derek Dagit <de...@oath.com.INVALID> wrote:
>
> Leif, can we make this "overridable" in follow-on work?
Sure.
— Leif
>
> This is a bit tricky because of custom parsing.
>
> On Sat, Aug 25, 2018 at 6:21 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>>
>>
>>> On Aug 24, 2018, at 12:31, Derek Dagit <de...@oath.com.INVALID> wrote:
>>>
>>> Sounds good let me take a look.
>>>
>>>> On Fri, Aug 24, 2018 at 12:24 PM, Bryan Call <bc...@apache.org> wrote:
>>>>
>>>> I am OK with it. I would add a default tag, so you can specify what
>>>> action to take by default if there is no match (e.g.
>>>> routable:follow,default:reject).
>>
>> And we can make this overridable i hope?
>>
>> — Leif
>>>>
>>>> -Bryan
>>>>
>>>>
>>>>
>>>>> On Aug 24, 2018, at 9:16 AM, Alan Carroll <solidwallofcode@oath.com.
>> INVALID>
>>>> wrote:
>>>>>
>>>>> Derek and I discussed this earlier this morning and we think the best
>>>>> option is to have a new configuration variable instead of bringing back
>>>> the
>>>>> old one, something like "proxy.config.,http.redirect.actions STRING".
>>>>>
>>>>> The string would be of the format "tag[:action],tag[:action],...".
>>>>>
>>>>> The tag would be one of the enumerations
>>>>>
>>>>> * private : Private (non-routable, RFC-1918) addresses.
>>>>> * loopback: Loopback address (all of 127/8 and IPv6 loopback)
>>>>> * multicast: Multicast address
>>>>> * link-local: IPv6 link local address
>>>>> * routable: Globally routable address.
>>>>> * self: Addresses assigned to this host.
>>>>>
>>>>> The action must be one of
>>>>>
>>>>> * follow: Internally follow the redirect up to the maximum count.
>>>>> * return: Do not process the redirect, send it as the proxy response.
>>>>> * reject: Do not process the redirect, send a 403 as the proxy
>> response.
>>>>>
>>>>> or omitted, in which case it is treated as "follow", although Derek
>> would
>>>>> prefer to require the action in all cases.
>>>>>
>>>>> If a tag is omitted, it is treated as if it were "tag:return".
>>>>>
>>>>> This provides very fine grained control. The default would be
>>>>> "routable:follow", which means "follow routable redirects, return all
>>>> other
>>>>> redirects".
>>>>
>>>>
>>>
>>>
>>> --
>>> Derek
>>
>>
>
>
> --
> Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Derek Dagit <de...@oath.com.INVALID>.
Leif, can we make this "overridable" in follow-on work?
This is a bit tricky because of custom parsing.
On Sat, Aug 25, 2018 at 6:21 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > On Aug 24, 2018, at 12:31, Derek Dagit <de...@oath.com.INVALID> wrote:
> >
> > Sounds good let me take a look.
> >
> >> On Fri, Aug 24, 2018 at 12:24 PM, Bryan Call <bc...@apache.org> wrote:
> >>
> >> I am OK with it. I would add a default tag, so you can specify what
> >> action to take by default if there is no match (e.g.
> >> routable:follow,default:reject).
>
> And we can make this overridable i hope?
>
> — Leif
> >>
> >> -Bryan
> >>
> >>
> >>
> >>> On Aug 24, 2018, at 9:16 AM, Alan Carroll <solidwallofcode@oath.com.
> INVALID>
> >> wrote:
> >>>
> >>> Derek and I discussed this earlier this morning and we think the best
> >>> option is to have a new configuration variable instead of bringing back
> >> the
> >>> old one, something like "proxy.config.,http.redirect.actions STRING".
> >>>
> >>> The string would be of the format "tag[:action],tag[:action],...".
> >>>
> >>> The tag would be one of the enumerations
> >>>
> >>> * private : Private (non-routable, RFC-1918) addresses.
> >>> * loopback: Loopback address (all of 127/8 and IPv6 loopback)
> >>> * multicast: Multicast address
> >>> * link-local: IPv6 link local address
> >>> * routable: Globally routable address.
> >>> * self: Addresses assigned to this host.
> >>>
> >>> The action must be one of
> >>>
> >>> * follow: Internally follow the redirect up to the maximum count.
> >>> * return: Do not process the redirect, send it as the proxy response.
> >>> * reject: Do not process the redirect, send a 403 as the proxy
> response.
> >>>
> >>> or omitted, in which case it is treated as "follow", although Derek
> would
> >>> prefer to require the action in all cases.
> >>>
> >>> If a tag is omitted, it is treated as if it were "tag:return".
> >>>
> >>> This provides very fine grained control. The default would be
> >>> "routable:follow", which means "follow routable redirects, return all
> >> other
> >>> redirects".
> >>
> >>
> >
> >
> > --
> > Derek
>
>
--
Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Leif Hedstrom <zw...@apache.org>.
> On Aug 24, 2018, at 12:31, Derek Dagit <de...@oath.com.INVALID> wrote:
>
> Sounds good let me take a look.
>
>> On Fri, Aug 24, 2018 at 12:24 PM, Bryan Call <bc...@apache.org> wrote:
>>
>> I am OK with it. I would add a default tag, so you can specify what
>> action to take by default if there is no match (e.g.
>> routable:follow,default:reject).
And we can make this overridable i hope?
— Leif
>>
>> -Bryan
>>
>>
>>
>>> On Aug 24, 2018, at 9:16 AM, Alan Carroll <so...@oath.com.INVALID>
>> wrote:
>>>
>>> Derek and I discussed this earlier this morning and we think the best
>>> option is to have a new configuration variable instead of bringing back
>> the
>>> old one, something like "proxy.config.,http.redirect.actions STRING".
>>>
>>> The string would be of the format "tag[:action],tag[:action],...".
>>>
>>> The tag would be one of the enumerations
>>>
>>> * private : Private (non-routable, RFC-1918) addresses.
>>> * loopback: Loopback address (all of 127/8 and IPv6 loopback)
>>> * multicast: Multicast address
>>> * link-local: IPv6 link local address
>>> * routable: Globally routable address.
>>> * self: Addresses assigned to this host.
>>>
>>> The action must be one of
>>>
>>> * follow: Internally follow the redirect up to the maximum count.
>>> * return: Do not process the redirect, send it as the proxy response.
>>> * reject: Do not process the redirect, send a 403 as the proxy response.
>>>
>>> or omitted, in which case it is treated as "follow", although Derek would
>>> prefer to require the action in all cases.
>>>
>>> If a tag is omitted, it is treated as if it were "tag:return".
>>>
>>> This provides very fine grained control. The default would be
>>> "routable:follow", which means "follow routable redirects, return all
>> other
>>> redirects".
>>
>>
>
>
> --
> Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Derek Dagit <de...@oath.com.INVALID>.
Sounds good let me take a look.
On Fri, Aug 24, 2018 at 12:24 PM, Bryan Call <bc...@apache.org> wrote:
> I am OK with it. I would add a default tag, so you can specify what
> action to take by default if there is no match (e.g.
> routable:follow,default:reject).
>
> -Bryan
>
>
>
> > On Aug 24, 2018, at 9:16 AM, Alan Carroll <so...@oath.com.INVALID>
> wrote:
> >
> > Derek and I discussed this earlier this morning and we think the best
> > option is to have a new configuration variable instead of bringing back
> the
> > old one, something like "proxy.config.,http.redirect.actions STRING".
> >
> > The string would be of the format "tag[:action],tag[:action],...".
> >
> > The tag would be one of the enumerations
> >
> > * private : Private (non-routable, RFC-1918) addresses.
> > * loopback: Loopback address (all of 127/8 and IPv6 loopback)
> > * multicast: Multicast address
> > * link-local: IPv6 link local address
> > * routable: Globally routable address.
> > * self: Addresses assigned to this host.
> >
> > The action must be one of
> >
> > * follow: Internally follow the redirect up to the maximum count.
> > * return: Do not process the redirect, send it as the proxy response.
> > * reject: Do not process the redirect, send a 403 as the proxy response.
> >
> > or omitted, in which case it is treated as "follow", although Derek would
> > prefer to require the action in all cases.
> >
> > If a tag is omitted, it is treated as if it were "tag:return".
> >
> > This provides very fine grained control. The default would be
> > "routable:follow", which means "follow routable redirects, return all
> other
> > redirects".
>
>
--
Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Bryan Call <bc...@apache.org>.
I am OK with it. I would add a default tag, so you can specify what action to take by default if there is no match (e.g. routable:follow,default:reject).
-Bryan
> On Aug 24, 2018, at 9:16 AM, Alan Carroll <so...@oath.com.INVALID> wrote:
>
> Derek and I discussed this earlier this morning and we think the best
> option is to have a new configuration variable instead of bringing back the
> old one, something like "proxy.config.,http.redirect.actions STRING".
>
> The string would be of the format "tag[:action],tag[:action],...".
>
> The tag would be one of the enumerations
>
> * private : Private (non-routable, RFC-1918) addresses.
> * loopback: Loopback address (all of 127/8 and IPv6 loopback)
> * multicast: Multicast address
> * link-local: IPv6 link local address
> * routable: Globally routable address.
> * self: Addresses assigned to this host.
>
> The action must be one of
>
> * follow: Internally follow the redirect up to the maximum count.
> * return: Do not process the redirect, send it as the proxy response.
> * reject: Do not process the redirect, send a 403 as the proxy response.
>
> or omitted, in which case it is treated as "follow", although Derek would
> prefer to require the action in all cases.
>
> If a tag is omitted, it is treated as if it were "tag:return".
>
> This provides very fine grained control. The default would be
> "routable:follow", which means "follow routable redirects, return all other
> redirects".
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Alan Carroll <so...@oath.com.INVALID>.
Derek and I discussed this earlier this morning and we think the best
option is to have a new configuration variable instead of bringing back the
old one, something like "proxy.config.,http.redirect.actions STRING".
The string would be of the format "tag[:action],tag[:action],...".
The tag would be one of the enumerations
* private : Private (non-routable, RFC-1918) addresses.
* loopback: Loopback address (all of 127/8 and IPv6 loopback)
* multicast: Multicast address
* link-local: IPv6 link local address
* routable: Globally routable address.
* self: Addresses assigned to this host.
The action must be one of
* follow: Internally follow the redirect up to the maximum count.
* return: Do not process the redirect, send it as the proxy response.
* reject: Do not process the redirect, send a 403 as the proxy response.
or omitted, in which case it is treated as "follow", although Derek would
prefer to require the action in all cases.
If a tag is omitted, it is treated as if it were "tag:return".
This provides very fine grained control. The default would be
"routable:follow", which means "follow routable redirects, return all other
redirects".
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Derek Dagit <de...@oath.com.INVALID>.
OK I think we can converge on the PR now:
https://github.com/apache/trafficserver/pull/4145#issuecomment-415647049
I expect more iterations.
On Thu, Aug 23, 2018 at 8:52 PM, Derek Dagit <de...@oath.com> wrote:
> Thanks, working on it.
>
> On Thu, Aug 23, 2018 at 6:19 PM, Bryan Call <bc...@apache.org> wrote:
>
>> Inline
>>
>> -Bryan
>>
>> > On Aug 22, 2018, at 11:37 AM, Derek Dagit <de...@oath.com.INVALID>
>> wrote:
>> >
>> > Bryan, some clarification questions:
>> >
>> >
>> >> 2. 403
>> >
>> > What should we do on the N+1st redirect? Do we try to resolve the target
>> > host and 403 that too, or just return it to the client regardless of
>> how it
>> > resolves?
>> >
>> > This is why I went with "Return" by default rather than "Reject".
>> >
>>
>> Sounds good, that is what we are doing now with n+1.
>>
>> >
>> >
>> >> 3. I like Lief’s proposal.
>> >
>> > OK I can renumber the config values if necessary.
>> >
>> >
>> >
>> >> You might want to add another option to add non-routable IPs to the
>> list
>> > too.
>> >
>> > We do prevent connections to the ANY address 0.0.0.0 globally in ATS
>> > already (redirect or not). I can look at adding additional checks for
>> > non-routable addresses.
>> >
>> >
>> >> I would create a configuration option called
>> proxy.config.http.redirect_enabled
>> > and start with 0 as off and set proxy.config.http.number_of_redirections
>> to
>> > 1 as the default.
>> >
>> > We have recently removed this config, seeing as it is redundant with
>> > number_of_redirections. Are you proposing we bring this config back
>> with a
>> > new meaning and use it to configure the Follow/Reject/Return behavior?
>>
>> Yes, if it is being enabled for different modes I would think it would be
>> best to have it under and enabled option, This is how some other
>> configuration options are done (e.g. proxy.config.log.logging_enabled).
>>
>> >
>> > Setting it to 0 according to Leif's proposal would default to the
>> current
>> > behavior, which we are saying is not recommended. Is this what you
>> suggest
>> > or were you thinking Reject or Return should be the default?
>> >
>> >
>> >> When checking for localhost you should resolve the ip and check to see
>> if
>> > it matches any of the IPs on the server.
>> >
>> > OK will look at this too. I am not sure there is a good solution to
>> handle
>> > other servers or VIPs where the VIP is not mapped to a loop-back
>> interface.
>> > (If the VIP is mapped to the loopback, then this is covered by checks
>> for
>> > loopback. If it is not mapped to loopback, then I am not sure how we can
>> > know to treat it specially aside from an additional config—and that
>> starts
>> > to sound like maybe a plugin should be handling such things.)
>> >
>> >
>> >
>> > Thanks for the input. I'm fine with changing it.
>> >
>> > The current Pull Request is up, but keeping the discussion here until we
>> > settle on what we want to do.
>> > https://github.com/apache/trafficserver/pull/4145
>> >
>> >
>> >
>> > On Wed, Aug 22, 2018 at 1:04 PM, Bryan Call <bc...@apache.org> wrote:
>> >
>> >> 1. Yes
>> >> 2. 403
>> >> 3. I like Lief’s proposal. You might want to add another option to add
>> >> non-routable IPs to the list too. I would create a configuration
>> option
>> >> called proxy.config.http.redirect_enabled and start with 0 as off and
>> set
>> >> proxy.config.http.number_of_redirections to 1 as the default.
>> >>
>> >> When checking for localhost you should resolve the ip and check to see
>> if
>> >> it matches any of the IPs on the server. That could be a long list if
>> >> there servers has many IP aliases. This still doesn’t block IPs used
>> by
>> >> other servers in the same network.
>> >>
>> >> -Bryan
>> >>
>> >>
>> >>
>> >>> On Aug 6, 2018, at 5:25 PM, Derek Dagit <de...@oath.com.INVALID>
>> wrote:
>> >>>
>> >>> 1. Yep
>> >>>
>> >>> 2. I see multiple possible answers as well...
>> >>>
>> >>> 3. ... and the 0,1,2-style config having either default sounds OK.
>> >>>
>> >>> Regarding 1)2), Could we resolve and then check if the address is a
>> >>> loopback address?
>> >>> 3) Hmm, not sure about the use of *cast addresses either.
>> >>> 4) The VIP deployment I'm used to will actually set up the host such
>> >>> that the VIP name resolves to the loopback address, so the above
>> works.
>> >>> That might not be good enough for all deployments though.
>> >>>
>> >>> On Mon, Aug 6, 2018 at 6:16 PM, Leif Hedstrom <zw...@apache.org>
>> wrote:
>> >>>
>> >>>>
>> >>>>
>> >>>>> On Aug 6, 2018, at 4:50 PM, Alan Carroll <solidwallofcode@oath.com.
>> >> INVALID>
>> >>>> wrote:
>> >>>>>
>> >>>>> 1. Yes.
>> >>>>
>> >>>> Agreed.
>> >>>>
>> >>>>>
>> >>>>> 2. I think a 403
>> >>>>
>> >>>> I can go either way. The HTTP way would be to just return the
>> Location
>> >> as
>> >>>> is (i.e. retain the redirect), following redirects is a little
>> >> unorthodox.
>> >>>> Maybe since we are adding new configuration(s), maybe make it such
>> that
>> >> the
>> >>>> behavior can be configurable either way?
>> >>>>
>> >>>> Depending on if we add another configuration, or add on to the
>> existing
>> >>>> one, I’m thinking something in the line of
>> >>>>
>> >>>> 0 - Always allow follow redirect
>> >>>> 1 - Allow follow redirect, but return the normal redirect if
>> it’s
>> >>>> for localhost
>> >>>> 2 - Allow follow redirect, but give a 403 if it's to localhost
>> >>>>
>> >>>>
>> >>>> My vote would be for 1) to be the default, but I can live with 2) as
>> >> well.
>> >>>>
>> >>>> Question: The notion of “localhost” is a little vague here… I think
>> >>>> there’s a number of other ways to reach “localhost”, rather than just
>> >>>> localhost/127.0.0.1:
>> >>>>
>> >>>> 1) FQDNs
>> >>>> 2) One of the possibly many IPs that are local to the box,
>> >>>> including IPv6 link-locals
>> >>>> 3) Possibly some broadcast or multicast addresses??
>> >>>> 4) The upstream VIP IP that might point back to the box(es)
>> >>>>
>> >>>> I think there are many ways that someone could make a follow redirect
>> >> loop
>> >>>> back to itself, or a peering proxy.
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> — Leif
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Derek
>> >>
>> >>
>> >
>> >
>> > --
>> > Derek
>>
>>
>
>
> --
> Derek
>
--
Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Derek Dagit <de...@oath.com.INVALID>.
Thanks, working on it.
On Thu, Aug 23, 2018 at 6:19 PM, Bryan Call <bc...@apache.org> wrote:
> Inline
>
> -Bryan
>
> > On Aug 22, 2018, at 11:37 AM, Derek Dagit <de...@oath.com.INVALID>
> wrote:
> >
> > Bryan, some clarification questions:
> >
> >
> >> 2. 403
> >
> > What should we do on the N+1st redirect? Do we try to resolve the target
> > host and 403 that too, or just return it to the client regardless of how
> it
> > resolves?
> >
> > This is why I went with "Return" by default rather than "Reject".
> >
>
> Sounds good, that is what we are doing now with n+1.
>
> >
> >
> >> 3. I like Lief’s proposal.
> >
> > OK I can renumber the config values if necessary.
> >
> >
> >
> >> You might want to add another option to add non-routable IPs to the list
> > too.
> >
> > We do prevent connections to the ANY address 0.0.0.0 globally in ATS
> > already (redirect or not). I can look at adding additional checks for
> > non-routable addresses.
> >
> >
> >> I would create a configuration option called proxy.config.http.redirect_
> enabled
> > and start with 0 as off and set proxy.config.http.number_of_redirections
> to
> > 1 as the default.
> >
> > We have recently removed this config, seeing as it is redundant with
> > number_of_redirections. Are you proposing we bring this config back with
> a
> > new meaning and use it to configure the Follow/Reject/Return behavior?
>
> Yes, if it is being enabled for different modes I would think it would be
> best to have it under and enabled option, This is how some other
> configuration options are done (e.g. proxy.config.log.logging_enabled).
>
> >
> > Setting it to 0 according to Leif's proposal would default to the current
> > behavior, which we are saying is not recommended. Is this what you
> suggest
> > or were you thinking Reject or Return should be the default?
> >
> >
> >> When checking for localhost you should resolve the ip and check to see
> if
> > it matches any of the IPs on the server.
> >
> > OK will look at this too. I am not sure there is a good solution to
> handle
> > other servers or VIPs where the VIP is not mapped to a loop-back
> interface.
> > (If the VIP is mapped to the loopback, then this is covered by checks for
> > loopback. If it is not mapped to loopback, then I am not sure how we can
> > know to treat it specially aside from an additional config—and that
> starts
> > to sound like maybe a plugin should be handling such things.)
> >
> >
> >
> > Thanks for the input. I'm fine with changing it.
> >
> > The current Pull Request is up, but keeping the discussion here until we
> > settle on what we want to do.
> > https://github.com/apache/trafficserver/pull/4145
> >
> >
> >
> > On Wed, Aug 22, 2018 at 1:04 PM, Bryan Call <bc...@apache.org> wrote:
> >
> >> 1. Yes
> >> 2. 403
> >> 3. I like Lief’s proposal. You might want to add another option to add
> >> non-routable IPs to the list too. I would create a configuration option
> >> called proxy.config.http.redirect_enabled and start with 0 as off and
> set
> >> proxy.config.http.number_of_redirections to 1 as the default.
> >>
> >> When checking for localhost you should resolve the ip and check to see
> if
> >> it matches any of the IPs on the server. That could be a long list if
> >> there servers has many IP aliases. This still doesn’t block IPs used by
> >> other servers in the same network.
> >>
> >> -Bryan
> >>
> >>
> >>
> >>> On Aug 6, 2018, at 5:25 PM, Derek Dagit <de...@oath.com.INVALID>
> wrote:
> >>>
> >>> 1. Yep
> >>>
> >>> 2. I see multiple possible answers as well...
> >>>
> >>> 3. ... and the 0,1,2-style config having either default sounds OK.
> >>>
> >>> Regarding 1)2), Could we resolve and then check if the address is a
> >>> loopback address?
> >>> 3) Hmm, not sure about the use of *cast addresses either.
> >>> 4) The VIP deployment I'm used to will actually set up the host such
> >>> that the VIP name resolves to the loopback address, so the above works.
> >>> That might not be good enough for all deployments though.
> >>>
> >>> On Mon, Aug 6, 2018 at 6:16 PM, Leif Hedstrom <zw...@apache.org>
> wrote:
> >>>
> >>>>
> >>>>
> >>>>> On Aug 6, 2018, at 4:50 PM, Alan Carroll <solidwallofcode@oath.com.
> >> INVALID>
> >>>> wrote:
> >>>>>
> >>>>> 1. Yes.
> >>>>
> >>>> Agreed.
> >>>>
> >>>>>
> >>>>> 2. I think a 403
> >>>>
> >>>> I can go either way. The HTTP way would be to just return the Location
> >> as
> >>>> is (i.e. retain the redirect), following redirects is a little
> >> unorthodox.
> >>>> Maybe since we are adding new configuration(s), maybe make it such
> that
> >> the
> >>>> behavior can be configurable either way?
> >>>>
> >>>> Depending on if we add another configuration, or add on to the
> existing
> >>>> one, I’m thinking something in the line of
> >>>>
> >>>> 0 - Always allow follow redirect
> >>>> 1 - Allow follow redirect, but return the normal redirect if
> it’s
> >>>> for localhost
> >>>> 2 - Allow follow redirect, but give a 403 if it's to localhost
> >>>>
> >>>>
> >>>> My vote would be for 1) to be the default, but I can live with 2) as
> >> well.
> >>>>
> >>>> Question: The notion of “localhost” is a little vague here… I think
> >>>> there’s a number of other ways to reach “localhost”, rather than just
> >>>> localhost/127.0.0.1:
> >>>>
> >>>> 1) FQDNs
> >>>> 2) One of the possibly many IPs that are local to the box,
> >>>> including IPv6 link-locals
> >>>> 3) Possibly some broadcast or multicast addresses??
> >>>> 4) The upstream VIP IP that might point back to the box(es)
> >>>>
> >>>> I think there are many ways that someone could make a follow redirect
> >> loop
> >>>> back to itself, or a peering proxy.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> — Leif
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Derek
> >>
> >>
> >
> >
> > --
> > Derek
>
>
--
Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Bryan Call <bc...@apache.org>.
Inline
-Bryan
> On Aug 22, 2018, at 11:37 AM, Derek Dagit <de...@oath.com.INVALID> wrote:
>
> Bryan, some clarification questions:
>
>
>> 2. 403
>
> What should we do on the N+1st redirect? Do we try to resolve the target
> host and 403 that too, or just return it to the client regardless of how it
> resolves?
>
> This is why I went with "Return" by default rather than "Reject".
>
Sounds good, that is what we are doing now with n+1.
>
>
>> 3. I like Lief’s proposal.
>
> OK I can renumber the config values if necessary.
>
>
>
>> You might want to add another option to add non-routable IPs to the list
> too.
>
> We do prevent connections to the ANY address 0.0.0.0 globally in ATS
> already (redirect or not). I can look at adding additional checks for
> non-routable addresses.
>
>
>> I would create a configuration option called proxy.config.http.redirect_enabled
> and start with 0 as off and set proxy.config.http.number_of_redirections to
> 1 as the default.
>
> We have recently removed this config, seeing as it is redundant with
> number_of_redirections. Are you proposing we bring this config back with a
> new meaning and use it to configure the Follow/Reject/Return behavior?
Yes, if it is being enabled for different modes I would think it would be best to have it under and enabled option, This is how some other configuration options are done (e.g. proxy.config.log.logging_enabled).
>
> Setting it to 0 according to Leif's proposal would default to the current
> behavior, which we are saying is not recommended. Is this what you suggest
> or were you thinking Reject or Return should be the default?
>
>
>> When checking for localhost you should resolve the ip and check to see if
> it matches any of the IPs on the server.
>
> OK will look at this too. I am not sure there is a good solution to handle
> other servers or VIPs where the VIP is not mapped to a loop-back interface.
> (If the VIP is mapped to the loopback, then this is covered by checks for
> loopback. If it is not mapped to loopback, then I am not sure how we can
> know to treat it specially aside from an additional config—and that starts
> to sound like maybe a plugin should be handling such things.)
>
>
>
> Thanks for the input. I'm fine with changing it.
>
> The current Pull Request is up, but keeping the discussion here until we
> settle on what we want to do.
> https://github.com/apache/trafficserver/pull/4145
>
>
>
> On Wed, Aug 22, 2018 at 1:04 PM, Bryan Call <bc...@apache.org> wrote:
>
>> 1. Yes
>> 2. 403
>> 3. I like Lief’s proposal. You might want to add another option to add
>> non-routable IPs to the list too. I would create a configuration option
>> called proxy.config.http.redirect_enabled and start with 0 as off and set
>> proxy.config.http.number_of_redirections to 1 as the default.
>>
>> When checking for localhost you should resolve the ip and check to see if
>> it matches any of the IPs on the server. That could be a long list if
>> there servers has many IP aliases. This still doesn’t block IPs used by
>> other servers in the same network.
>>
>> -Bryan
>>
>>
>>
>>> On Aug 6, 2018, at 5:25 PM, Derek Dagit <de...@oath.com.INVALID> wrote:
>>>
>>> 1. Yep
>>>
>>> 2. I see multiple possible answers as well...
>>>
>>> 3. ... and the 0,1,2-style config having either default sounds OK.
>>>
>>> Regarding 1)2), Could we resolve and then check if the address is a
>>> loopback address?
>>> 3) Hmm, not sure about the use of *cast addresses either.
>>> 4) The VIP deployment I'm used to will actually set up the host such
>>> that the VIP name resolves to the loopback address, so the above works.
>>> That might not be good enough for all deployments though.
>>>
>>> On Mon, Aug 6, 2018 at 6:16 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>>
>>>>
>>>>
>>>>> On Aug 6, 2018, at 4:50 PM, Alan Carroll <solidwallofcode@oath.com.
>> INVALID>
>>>> wrote:
>>>>>
>>>>> 1. Yes.
>>>>
>>>> Agreed.
>>>>
>>>>>
>>>>> 2. I think a 403
>>>>
>>>> I can go either way. The HTTP way would be to just return the Location
>> as
>>>> is (i.e. retain the redirect), following redirects is a little
>> unorthodox.
>>>> Maybe since we are adding new configuration(s), maybe make it such that
>> the
>>>> behavior can be configurable either way?
>>>>
>>>> Depending on if we add another configuration, or add on to the existing
>>>> one, I’m thinking something in the line of
>>>>
>>>> 0 - Always allow follow redirect
>>>> 1 - Allow follow redirect, but return the normal redirect if it’s
>>>> for localhost
>>>> 2 - Allow follow redirect, but give a 403 if it's to localhost
>>>>
>>>>
>>>> My vote would be for 1) to be the default, but I can live with 2) as
>> well.
>>>>
>>>> Question: The notion of “localhost” is a little vague here… I think
>>>> there’s a number of other ways to reach “localhost”, rather than just
>>>> localhost/127.0.0.1:
>>>>
>>>> 1) FQDNs
>>>> 2) One of the possibly many IPs that are local to the box,
>>>> including IPv6 link-locals
>>>> 3) Possibly some broadcast or multicast addresses??
>>>> 4) The upstream VIP IP that might point back to the box(es)
>>>>
>>>> I think there are many ways that someone could make a follow redirect
>> loop
>>>> back to itself, or a peering proxy.
>>>>
>>>> Cheers,
>>>>
>>>> — Leif
>>>>
>>>>
>>>
>>>
>>> --
>>> Derek
>>
>>
>
>
> --
> Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Derek Dagit <de...@oath.com.INVALID>.
Bryan, some clarification questions:
> 2. 403
What should we do on the N+1st redirect? Do we try to resolve the target
host and 403 that too, or just return it to the client regardless of how it
resolves?
This is why I went with "Return" by default rather than "Reject".
> 3. I like Lief’s proposal.
OK I can renumber the config values if necessary.
> You might want to add another option to add non-routable IPs to the list
too.
We do prevent connections to the ANY address 0.0.0.0 globally in ATS
already (redirect or not). I can look at adding additional checks for
non-routable addresses.
> I would create a configuration option called proxy.config.http.redirect_enabled
and start with 0 as off and set proxy.config.http.number_of_redirections to
1 as the default.
We have recently removed this config, seeing as it is redundant with
number_of_redirections. Are you proposing we bring this config back with a
new meaning and use it to configure the Follow/Reject/Return behavior?
Setting it to 0 according to Leif's proposal would default to the current
behavior, which we are saying is not recommended. Is this what you suggest
or were you thinking Reject or Return should be the default?
> When checking for localhost you should resolve the ip and check to see if
it matches any of the IPs on the server.
OK will look at this too. I am not sure there is a good solution to handle
other servers or VIPs where the VIP is not mapped to a loop-back interface.
(If the VIP is mapped to the loopback, then this is covered by checks for
loopback. If it is not mapped to loopback, then I am not sure how we can
know to treat it specially aside from an additional config—and that starts
to sound like maybe a plugin should be handling such things.)
Thanks for the input. I'm fine with changing it.
The current Pull Request is up, but keeping the discussion here until we
settle on what we want to do.
https://github.com/apache/trafficserver/pull/4145
On Wed, Aug 22, 2018 at 1:04 PM, Bryan Call <bc...@apache.org> wrote:
> 1. Yes
> 2. 403
> 3. I like Lief’s proposal. You might want to add another option to add
> non-routable IPs to the list too. I would create a configuration option
> called proxy.config.http.redirect_enabled and start with 0 as off and set
> proxy.config.http.number_of_redirections to 1 as the default.
>
> When checking for localhost you should resolve the ip and check to see if
> it matches any of the IPs on the server. That could be a long list if
> there servers has many IP aliases. This still doesn’t block IPs used by
> other servers in the same network.
>
> -Bryan
>
>
>
> > On Aug 6, 2018, at 5:25 PM, Derek Dagit <de...@oath.com.INVALID> wrote:
> >
> > 1. Yep
> >
> > 2. I see multiple possible answers as well...
> >
> > 3. ... and the 0,1,2-style config having either default sounds OK.
> >
> > Regarding 1)2), Could we resolve and then check if the address is a
> > loopback address?
> > 3) Hmm, not sure about the use of *cast addresses either.
> > 4) The VIP deployment I'm used to will actually set up the host such
> > that the VIP name resolves to the loopback address, so the above works.
> > That might not be good enough for all deployments though.
> >
> > On Mon, Aug 6, 2018 at 6:16 PM, Leif Hedstrom <zw...@apache.org> wrote:
> >
> >>
> >>
> >>> On Aug 6, 2018, at 4:50 PM, Alan Carroll <solidwallofcode@oath.com.
> INVALID>
> >> wrote:
> >>>
> >>> 1. Yes.
> >>
> >> Agreed.
> >>
> >>>
> >>> 2. I think a 403
> >>
> >> I can go either way. The HTTP way would be to just return the Location
> as
> >> is (i.e. retain the redirect), following redirects is a little
> unorthodox.
> >> Maybe since we are adding new configuration(s), maybe make it such that
> the
> >> behavior can be configurable either way?
> >>
> >> Depending on if we add another configuration, or add on to the existing
> >> one, I’m thinking something in the line of
> >>
> >> 0 - Always allow follow redirect
> >> 1 - Allow follow redirect, but return the normal redirect if it’s
> >> for localhost
> >> 2 - Allow follow redirect, but give a 403 if it's to localhost
> >>
> >>
> >> My vote would be for 1) to be the default, but I can live with 2) as
> well.
> >>
> >> Question: The notion of “localhost” is a little vague here… I think
> >> there’s a number of other ways to reach “localhost”, rather than just
> >> localhost/127.0.0.1:
> >>
> >> 1) FQDNs
> >> 2) One of the possibly many IPs that are local to the box,
> >> including IPv6 link-locals
> >> 3) Possibly some broadcast or multicast addresses??
> >> 4) The upstream VIP IP that might point back to the box(es)
> >>
> >> I think there are many ways that someone could make a follow redirect
> loop
> >> back to itself, or a peering proxy.
> >>
> >> Cheers,
> >>
> >> — Leif
> >>
> >>
> >
> >
> > --
> > Derek
>
>
--
Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Bryan Call <bc...@apache.org>.
1. Yes
2. 403
3. I like Lief’s proposal. You might want to add another option to add non-routable IPs to the list too. I would create a configuration option called proxy.config.http.redirect_enabled and start with 0 as off and set proxy.config.http.number_of_redirections to 1 as the default.
When checking for localhost you should resolve the ip and check to see if it matches any of the IPs on the server. That could be a long list if there servers has many IP aliases. This still doesn’t block IPs used by other servers in the same network.
-Bryan
> On Aug 6, 2018, at 5:25 PM, Derek Dagit <de...@oath.com.INVALID> wrote:
>
> 1. Yep
>
> 2. I see multiple possible answers as well...
>
> 3. ... and the 0,1,2-style config having either default sounds OK.
>
> Regarding 1)2), Could we resolve and then check if the address is a
> loopback address?
> 3) Hmm, not sure about the use of *cast addresses either.
> 4) The VIP deployment I'm used to will actually set up the host such
> that the VIP name resolves to the loopback address, so the above works.
> That might not be good enough for all deployments though.
>
> On Mon, Aug 6, 2018 at 6:16 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>>
>>
>>> On Aug 6, 2018, at 4:50 PM, Alan Carroll <so...@oath.com.INVALID>
>> wrote:
>>>
>>> 1. Yes.
>>
>> Agreed.
>>
>>>
>>> 2. I think a 403
>>
>> I can go either way. The HTTP way would be to just return the Location as
>> is (i.e. retain the redirect), following redirects is a little unorthodox.
>> Maybe since we are adding new configuration(s), maybe make it such that the
>> behavior can be configurable either way?
>>
>> Depending on if we add another configuration, or add on to the existing
>> one, I’m thinking something in the line of
>>
>> 0 - Always allow follow redirect
>> 1 - Allow follow redirect, but return the normal redirect if it’s
>> for localhost
>> 2 - Allow follow redirect, but give a 403 if it's to localhost
>>
>>
>> My vote would be for 1) to be the default, but I can live with 2) as well.
>>
>> Question: The notion of “localhost” is a little vague here… I think
>> there’s a number of other ways to reach “localhost”, rather than just
>> localhost/127.0.0.1:
>>
>> 1) FQDNs
>> 2) One of the possibly many IPs that are local to the box,
>> including IPv6 link-locals
>> 3) Possibly some broadcast or multicast addresses??
>> 4) The upstream VIP IP that might point back to the box(es)
>>
>> I think there are many ways that someone could make a follow redirect loop
>> back to itself, or a peering proxy.
>>
>> Cheers,
>>
>> — Leif
>>
>>
>
>
> --
> Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Derek Dagit <de...@oath.com.INVALID>.
1. Yep
2. I see multiple possible answers as well...
3. ... and the 0,1,2-style config having either default sounds OK.
Regarding 1)2), Could we resolve and then check if the address is a
loopback address?
3) Hmm, not sure about the use of *cast addresses either.
4) The VIP deployment I'm used to will actually set up the host such
that the VIP name resolves to the loopback address, so the above works.
That might not be good enough for all deployments though.
On Mon, Aug 6, 2018 at 6:16 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > On Aug 6, 2018, at 4:50 PM, Alan Carroll <so...@oath.com.INVALID>
> wrote:
> >
> > 1. Yes.
>
> Agreed.
>
> >
> > 2. I think a 403
>
> I can go either way. The HTTP way would be to just return the Location as
> is (i.e. retain the redirect), following redirects is a little unorthodox.
> Maybe since we are adding new configuration(s), maybe make it such that the
> behavior can be configurable either way?
>
> Depending on if we add another configuration, or add on to the existing
> one, I’m thinking something in the line of
>
> 0 - Always allow follow redirect
> 1 - Allow follow redirect, but return the normal redirect if it’s
> for localhost
> 2 - Allow follow redirect, but give a 403 if it's to localhost
>
>
> My vote would be for 1) to be the default, but I can live with 2) as well.
>
> Question: The notion of “localhost” is a little vague here… I think
> there’s a number of other ways to reach “localhost”, rather than just
> localhost/127.0.0.1:
>
> 1) FQDNs
> 2) One of the possibly many IPs that are local to the box,
> including IPv6 link-locals
> 3) Possibly some broadcast or multicast addresses??
> 4) The upstream VIP IP that might point back to the box(es)
>
> I think there are many ways that someone could make a follow redirect loop
> back to itself, or a peering proxy.
>
> Cheers,
>
> — Leif
>
>
--
Derek
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Leif Hedstrom <zw...@apache.org>.
> On Aug 6, 2018, at 4:50 PM, Alan Carroll <so...@oath.com.INVALID> wrote:
>
> 1. Yes.
Agreed.
>
> 2. I think a 403
I can go either way. The HTTP way would be to just return the Location as is (i.e. retain the redirect), following redirects is a little unorthodox. Maybe since we are adding new configuration(s), maybe make it such that the behavior can be configurable either way?
Depending on if we add another configuration, or add on to the existing one, I’m thinking something in the line of
0 - Always allow follow redirect
1 - Allow follow redirect, but return the normal redirect if it’s for localhost
2 - Allow follow redirect, but give a 403 if it's to localhost
My vote would be for 1) to be the default, but I can live with 2) as well.
Question: The notion of “localhost” is a little vague here… I think there’s a number of other ways to reach “localhost”, rather than just localhost/127.0.0.1:
1) FQDNs
2) One of the possibly many IPs that are local to the box, including IPv6 link-locals
3) Possibly some broadcast or multicast addresses??
4) The upstream VIP IP that might point back to the box(es)
I think there are many ways that someone could make a follow redirect loop back to itself, or a peering proxy.
Cheers,
— Leif
Re: [DISCUSS] Following redirects to 'localhost'
Posted by Alan Carroll <so...@oath.com.INVALID>.
1. Yes.
2. I think a 403
3. We can add more sophisticated configuration later, if there turns out to
be a need.
On Mon, Aug 6, 2018 at 4:48 PM Derek Dagit <de...@oath.com.invalid> wrote:
> ATS can be configured such that when it receives a redirect (3xx) response
> from an origin server, it will follow the redirect itself rather than
> return the response to the client.
>
> Consider the scenario when the redirect response contains a Location header
> field with a destination of localhost.
>
> In a forward-proxy scenario, where the origin server is "outside" the
> network, redirects to the localhost are not desirable.
>
> In the reverse-proxy scenario, where the origin server is "inside" the
> network, redirects to localhost are generally not desirable either.
> Exceptions to this might be when the origin serves requests from the same
> host as the proxy, and as a convenience when writing functional tests such
> that they can exercise redirect following without the need for a local DNS
> setup.
>
>
>
> We are considering changing the default behavior to stop following any
> redirect when its destination is localhost (or its variants) when following
> of redirects has been enabled.
>
> A config would be added, with noticeable warnings, that would enable the
> former behavior and allow redirects to be followed to localhost.
>
>
>
> 1. Does this seem like a good change to make?
>
> 2. How we would handle the redirect-to-localhost case under the new
> behavior. Should we return a 403? A 500? Or should we return the redirect
> response back to the client as-is?
>
> 3. Should we add a way to configure a sort of policy for when to follow
> redirects and what response to return on no-follow, or should we have a
> simple config boolean value and a standard behavior?
>
>
> Looking forward to your input,
>
> --
> Derek
>
--
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28