[
https://issues.apache.org/jira/browse/FTPSERVER-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842035#action_12842035
]
Niklas Gustavsson commented on FTPSERVER-352:
---------------------------------------------
If I understand correctly, the IP sent in the IDNT command would only have
relevance for active connections. Thus, if we would like to support the IDNT
command, we would need to patch the PORT command to check for any previously
set remote address.
We would also need to have a check in place that verifies that the IDNT command
is only allowed from known bouncer addresses.
All in all, I'm not sure we should implement this in FtpServer core. Seems like
a complex feature.
> IDNT command for control channel delegation.
> --------------------------------------------
>
> Key: FTPSERVER-352
> URL: https://issues.apache.org/jira/browse/FTPSERVER-352
> Project: FtpServer
> Issue Type: New Feature
> Components: Core
> Affects Versions: 1.0.3
> Reporter: DevNull43
> Attachments: IDNTCommand.txt
>
>
> FTP protocol contains 2 channels, one for control and a second one for data.
> Channels can be bounced in 2 ways:
> 1- Full bounce: A bouncer in between client and FtpServer acts as a man in
> the middle and forwards both channles, getting all the traffic from control
> and data.
> 2- Control bounce: A bouncer in between client and FtpServer acts as a man in
> the middle and forwards ONLY control channel, data channel uses realHost IP
> for PASV and sends data channel directly to client, not getting all traffic
> from data side.
> FtpServer works correctly with bouncers of type 1, however in order to work
> delegating control channels it needs to implement IDNT command.
> When a bouncer for control channel connects to FtpServer, it sends as first
> command:
> IDNT id...@hostip:HOSTIP
> With the attached patch, FtpServer uses bouncer IP for sending control
> channel (default), but stores in session.IDNT.clientHost variable name, the
> InetAddress of real client.
> From now on a developer can read from session this variable, and send data
> channel to original client.
> Further patches will check if this variable exist and use as appropiate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
