Subject: [BEHAVE] AUTH cmd and transparent mde

From: Rockson Li <[email-masked]>
Date: Mon, 04 Jul 2011 12:35:50 +0800

Iljitsch,

I don't understand why you were saying "whether the ALG goes into
transparent mode and whether the server responds positively to AUTH are
orthogonal"
Sec 9 of RFC2228 has a state diagram showing if a AUTH is rejected with
4yz, 5yz response, ftp would start over and might go as a normal plain
user/password authentication,
Whereas transparent ALG canot fit.

Are you saying you are proposing to use ALGS command to control
transparent mode regardless of AUTH command in -11?
But I still see the following text in sec 5, is this intentional?

   "To ensure consistent behavior, as
   soon as the initial AUTH command is issued by the client, an ALG MUST
   stop translating commands and responses, and start transparently
   copying back and forth TCP data sent by the client and the server."

Thanks
-Rockson

On 6/30/11 9:39 PM, "Iljitsch van Beijnum" <[email-masked]> wrote:

>On 30 jun 2011, at 15:34, Rockson Li wrote:
>
>> On "However, we now also have the ALGS command to explicitly do this so
>>I
>> guess this is no longer necessary and could be removed. Thoughts,
>>anyone?"
>> But it's impossible for clients to know whether a ALG has been used in
>>the
>> session or not.
>> Client should be operating transparently in terms FTP64.
>
>> I think we need to track the response code of AUTH if a final successful
>> response is returned from server, we need to get into the the
>>transparent
>> mode instead of in all the cases.
>
>No, that wouldn't work because whether the ALG goes into transparent mode
>and whether the server responds positively to AUTH are orthogonal. I made
>the AUTH less prominent in the new version of the draft, have a look.
>
>If people want an ALG to be transparent, they can simply use ALGS. If
>there's no ALG they get a 50x response, which causes no problems.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 Jul 2011 09:28:57 +0200

> transparent mode and whether the server responds positively to AUTH are

The idea was that just the fact that the client issued the AUTH command was enough to make the ALG become transparent, so a client could issue AUTH to trigger transparent mode even if it didn't intend to actually use the AUTH feature towards the server. But this is no longer necessary as the ALGS command serves this function.

> Whereas transparent ALG canot fit.

Not sure what you mean by "fit". I don't want to tell implementers of the ALG to monitor the progression of the AUTH negotiation, this would add too much complexity IMO. So AUTH -> transparent. If AUTH is rejected and this leads to problems because the translation is disabled in the ALG, too bad.

> transparent mode regardless of AUTH command in -11?

Clients should use the ALGS command to make the ALG transparent and use the AUTH command to negotiate more secure authentication.

>   copying back and forth TCP data sent by the client and the server."

I guess this could be a SHOULD now, if implementers want to use more advanced logic that would be ok.

Should I change this?

Iljitsch

---

From: Rockson Li <[email-masked]>
Date: Tue, 05 Jul 2011 11:55:26 +0800

Iljitsch,

On 
"If AUTH is rejected and this leads to problems because the translation is
disabled in the ALG, too bad."
"Clients should use the ALGS command to make the ALG transparent"

Why do you think ftp client can support those ALG specific ALGS command to
control the transparent mode?
Ftp client might have no awareness of the ALG, I don't think it make any
sense to ask end user to change/upgrade the ftp client  when they need to
traverse ALG.

On "I don't want to tell implementers of the ALG to monitor the
progression of the AUTH negotiation, this would add too much complexity
IMO"

Currently, ALG is tracking EPRT/EPSV request and response. I don't think
it adds much complexity for one more response.
Actually the point is I don't think ALGS is good choice here. Non ALGS-cmd
aware ftp client must continue to work, which IMO is critical to the
success of this draft.

-Rockson

On 7/4/11 3:28 PM, "Iljitsch van Beijnum" <[email-masked]> wrote:

>The idea was that just the fact that the client issued the AUTH command
>was enough to make the ALG become transparent, so a client could issue
>AUTH to trigger transparent mode even if it didn't intend to actually use
>the AUTH feature towards the server. But this is no longer necessary as
>the ALGS command serves this function.
>
>Not sure what you mean by "fit". I don't want to tell implementers of the
>ALG to monitor the progression of the AUTH negotiation, this would add
>too much complexity IMO. So AUTH -> transparent. If AUTH is rejected and
>this leads to problems because the translation is disabled in the ALG,
>too bad.
>
>Clients should use the ALGS command to make the ALG transparent and use
>the AUTH command to negotiate more secure authentication.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Jul 2011 13:26:26 +0200

Hi Rockson,

> sense to ask end user to change/upgrade the ftp client  when they need to

The purpose of the ALG is to make unmodified FTP clients on an IPv6 system work with unmodified FTP servers on an IPv4 system.

The ALGS command is there to allow users/clients who want more control over what happens to exert that control. Yes, this means using a client that allows sending arbitrary commands (command line clients can typically do that) and possibly some other workarounds, too. But it's better than being stuck in a situation where an ALG acts in an undesireable way with no option to do something about that.

>> "I don't want to tell implementers of the ALG to monitor the

> aware ftp client must continue to work, which IMO is critical to the

Can you think of any situation where normal use cases that work over IPv6 wouldn't work over NAT64 with the ALG specified here?

Iljitsch

---

From: Rockson Li <[email-masked]>
Date: Wed, 06 Jul 2011 13:33:21 +0800

On "this means using a client that allows sending arbitrary commands
(command line clients can typically do that) and possibly some other
workarounds, too."

I am using a widely used kerberos based cmd-line ftp client

http://web.mit.edu/kerberos/www/

I don't find any way I could issue the ALGS command. I guess we need use

ftp> quote ALGS DISABLE64
500 'ALGS DISABLE64': command not understood.

On "Can you think of any situation where normal use cases that work over
IPv6 wouldn't work over NAT64 with the ALG specified here?"
In my situation,  my ipv6 ftp client first sends "AUTH KERBERO4" and  get
back 504 "no supported",
so it falls back to normal user/password authentication and transfer file
between itself and server.

However, if I use the same client talking to a IPv4-only ftp server via
FTP64 ALG.
After I get 504 for "AUTH KERBERO4", ALG start working transparently, and
I proceed with user/password authentication, and start the file transfer.
But ALG stop translating now.  how could the file transfer work in this
case?
I cannot issue the ALGS command from this client in cli, even I can,
How could the end user know that it needs to do it without knowing ALG's
presence, the issue of ALG and the action they need take?
There's no any clue at all to them. Poor user!!!

Thanks
Regards
-Rockson

On 7/5/11 7:26 PM, "Iljitsch van Beijnum" <[email-masked]> wrote:

>The purpose of the ALG is to make unmodified FTP clients on an IPv6
>system work with unmodified FTP servers on an IPv4 system.
>
>The ALGS command is there to allow users/clients who want more control
>over what happens to exert that control. Yes, this means using a client
>that allows sending arbitrary commands (command line clients can
>typically do that) and possibly some other workarounds, too. But it's
>better than being stuck in a situation where an ALG acts in an
>undesireable way with no option to do something about that.
>
>Can you think of any situation where normal use cases that work over IPv6
>wouldn't work over NAT64 with the ALG specified here?
>
>Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Jul 2011 10:49:09 +0200

> 500 'ALGS DISABLE64': command not understood.

Exactly.

> between itself and server.

Is this something the client always tries to do automatically?

I could add this to the draft:

The ALG SHOULD ignore the AUTH command and not go into transparent mode if the server response is in the 4xx or 5xx ranges.

Would that address your issue?

---

From: Rockson Li <[email-masked]>
Date: Thu, 07 Jul 2011 14:57:53 +0800

>Is this something the client always tries to do automatically?

Yes,client would do it automatically, wireshark capture is attached for
your reference.

>The ALG SHOULD ignore the AUTH command and not go into transparent mode
>if the server response is in the 4xx or 5xx ranges.
>

Yes, that would address most of issues.
Can we also cover 4yz,5yz for ADAT command here?
As said in sec 9 of RFC2228, the authentication procedure would restart
from scratch from 4yx/5yz for either AUTH or ADAT

          ,------------------,  USER
       __\| Unauthenticated  |_________\
      |  /| (new connection) |         /|
      |   `------------------'          |
      |            |                    |
      |            | AUTH               |
      |            V                    |
      |           / \                   |
      | 4yz,5yz  /   \   234            |
      |<--------<     >------------->.  |
      |          \   /               |  |
      |           \_/                |  |
      |            |                 |  |
      |            | 334             |  |
      |            V                 |  |
      |  ,--------------------,      |  |
      |  | Need Security Data |<--.  |  |
      |  `--------------------'   |  |  |
      |            |              |  |  |
      |            | ADAT         |  |  |
      |            V              |  |  |
      |           / \             |  |  |
      | 4yz,5yz  /   \   335      |  |  |
      `<--------<     >-----------'  |  |
                 \   /               |  |
                  \_/                |  |
                   |                 |  |
                   | 235             |  |
                   V                 |  |
           ,---------------.         |  |
      ,--->| Authenticated |<--------'  |  After the client and server
      |    `---------------'            |  have completed authenti-
      |            |                    |  cation, command must be
      |            | USER               |  integrity-protected if
      |            |                    |  integrity is available.  The
      |            |<-------------------'  CCC command may be issued to
      |            V                       relax this restriction.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Jul 2011 11:36:01 +0200

> Yes, that would address most of issues.

Ok.

> from scratch from 4yx/5yz for either AUTH or ADAT

The problem with that is that the control channel must still be monitored by the ALG even though at this point a TLS negotiation could be taking place. Of course it's possible to specify more knowledge of the security mechanisms so the ALG can handle this intelligently, but that would add complexity and dependencies on possible future security mechanisms.

I would like to avoid that, and simply draw the line at the AUTH command: if the client issues it and the server doesn't react with an error, the ALG steps out of the way and lets the client and server do whatever they want to do without trying to interfere. There will be circumstances where that doesn't produce the best possible outcome, but at least it won't break anything that would work in the absence of the ALG. We don't want to be all things to all people, what we need is to increase the number of cases where FTP works without problems from about 45 - 65 % of all cases to somewhere much closer to 100%, even if we never quite reach 100%.