# Presentation: 012305

## GridFTP LiteFeature enhancements to improve GridFTP’s utility in non-production testbed uses.

- Raj Kettimuthu, ANL
- Bill Allcock, ANL

## Why GridFTP Lite?

- GridFTP is broadly used within Grid projects
- In “production” deployments, the use of GSI provides good security and control.
- However, setting up a GSI from scratch can be a time consuming and difficult process.
- Usually, the risk is high (Vern Paxson reports Bro turns back thousands of port scans a day) and this effort is amortized across all Grid services, so it is worth it.

## What about non-production use?

- There are cases where the effort needed to set up a GSI environment is not warranted.
- Network is not accessible to outside world
- Testbed will be short lived
- Access to the server by unknown users is not considered a problem
- No other Grid services will be accessed
- This category of use is not well served by the existing Globus GridFTP server.

## Caveat:  You ARE taking a Risk

- And so are we.
- If you are running reduced security, you have an increased risk of the server being used in un-intentional ways.
- You don’t want your project to end up on the front page
- We certainly don’t want the GridFTP name on the front page
- Could completely change the name to not include GridFTP, but that would be confusing.

## So, what are we proposing

- Modifications to the “production” GridFTP codebase to meet the needs of non-production users.
- Mostly handled via compile time, configuration and command line options
- This absolutely can not be a separate codebase; we don’t have the manpower to support two codebases, port bug fixes to two codebases, etc.
- This also means that you get all the new features and bug fixes on a timely basis.

## We need input

- We have an initial set of ideas for what changes need to be made.
- However, a big part of this meeting and further interactions between the GridFTP team and this community needs to be feedback on how the changes are helping and what else is needed.
- We need to take the “wish list” generated back and bounce it against our other commitments

## Wuftpd vs our new server

- The Globus GridFTP servers available to date have been based on the Washington University FTP server (wuftpd).
- As of GT4.0 (due out early next year, available now in a development release), there will be a new, from scratch, implementation.
- The protocol will not change and the servers will be completely interoperable
- This was done for ease of feature addition and maintenance, but mostly for licensing issues
- Most of the GridFTP Lite work will be on the new server codebase.

## The Security Wish List (so far)

- Provide anonymous access
- i.e. ANYONE can connect.
- Should only be used in private networks, unless you don’t care if someone connects
- Password based access
- This would be against a GridFTP only password file, since the password will be sent clear text
- This we could do in both the existing wuftpd, as well as the new server.

## More Security Options

- Add access control by IP address
- This can also be handled via tcpwrapper
- We can choose configuration based on IP
- Add support for ssh
- Broadly used
- No delegation, but otherwise good security
- Need to find source that we can use in Globus Toolkit (not GPL’ed)
- Automate the use of Simple CA
- This would automatically generate a GSI infrastructure, but certificates would only be accepted by your testbed.

## Summary of Security Options

- Aim is to provide a range of security options, so that installations can assess risk and then trade security for effort.
- Nevertheless, it must be stated explicitly that *anyone choosing to run GridFTP with a reduced level of security is accepting the fact that there is a higher probability that their system will be compromised*.

## Other features

- A GridFTP only package
- Only GridFTP and its required dependencies.
- Provide a standard port for the data channel
- Makes passive monitoring easier
- Memory to Memory Transfers
- Similar to iperf
- Extensive logging
- We need input for what should be logged
- Do plan on making it web100 aware
- Input on preferred logging mechanism.  Netlogger is the likely candidate.

## Firewall avoidance

- Current GridFTP protocol requires the sending side to do the TCP connect
- This can cause problems in some firewall situations.
- To fix this means protocol changes and that is a slooooowwwww process.
- If you want input on the new protocol, please join the GGF GridFTP WG.
- We could really use a good review and comments on the protocol.

## One feature that is already there

- We use Globus XIO for the IO in the new server.
- Provides an abstraction from Open, Close, Read, Write
- Allows us to be protocol agnostic
- Should make it relatively easy for protocol researchers to make GridFTP work over their protocol
- If your protocol looks like TCP (FAST, Scalable, HSTCP, etc) no changes necessary.
- We currently have a UDT implementation.

## OK.  Now it is your turn

- What other features would you like?
- Please feel free to discuss the technical aspects with Raj and get your feature on the list.
- We can then iterate on priority, timeline, etc.
- One possibility:
- Any interest in a GridFTP Development Workshop?
- Might cover installation, configuration, how to develop XIO drivers, how to add features to the server, how to add a new data source, etc..