headers
Iljitsch van Beijnum | 2 May 2010 22:14
Favicon

Re: Review: draft-ietf-behave-ftp64-00.txt

On 31 dec 2009, at 16:55, liu dapeng wrote:

I implemented your suggestions so far in one way or another.

> "EPSV ALL" indicates that the client will use EPSV for all
>   transfers, but an ALG may translate EPSV commands to PASV commands,
> conflicting with the earlier "EPSV ALL".

> Comments: Requiring client not using "EPSV ALL" at all maybe a not a
> good approach considering that there are chances that the server
> support EPSV ALL command and the communication between them may not
> need an ALG.

EPSV ALL is an optimization, so it can be omitted without trouble. Also, I don't believe clients actually
use it.

> 4.  ALG functionality
> Propose to add some sentences to clarity that there maybe a chance
> that for optimized client and server which comply with this document
> using ALG may lead to un-optimized result.

Ok.

> Appendix B.  Acknowledgements

> Propose to move the  Acknowledgements section in to the main body of
> the document and add a "contributors" section that lists all the
> contributors of this document.

Ok.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 2 May 2010 22:58
Favicon

Re: General Comments draft-ietf-behave-ftp64-00

About the comments in the PDF file:

I don't think it makes sense to refer to RFC 3033 as it would suggest we say something about the particular
messages in that document rather than just middleboxes in general.

I moved the text as per the next comment.

Highlighting this:

>> but an ALG may translate EPSV commands to PASV commands, conflicting with the earlier "EPSV ALL".

You say:

> Comment: Why
> would
> a
> new
> FTP64
> ALG
>  do
> that
> (as
> opposed
>
to
> a
> FTP44
> ALG)?
> I
>  think
> here
> we
> have
> the
> opportunity
>
to
> say
>  that
> “FTP64
> ALGs
> 
> must
> not
> translate
> ESPV
> 
commands
> to
> PASV
> commands
> unless
> it
> can
>  detect
> that
> the
>
server
> does
> not
> support
> it”.
> I
>  mean,
> aren’t
> we
>
recommending
> that
> the
>  client
> retries
> with
> PASV
> if
> not
>
successful?
> 

 Otherwise
it
is
conflicting
with
the
 recommendations
to
the
client.


(You may want to yell at your PDF generation tool vendor.)

I don't understand that comment. The whole basis of the FTP64 ALG is translation of client issued EPSV
commands into PASV commands seen by the server.

Then:

>> However, an ALG used with a stateless translator should also support EPRT
(Continue reading)

Permalink | Reply | 8 comments |
headers
Iljitsch van Beijnum | 2 May 2010 23:25
Favicon

Re: Questions on draft-ietf-behave-ftp64-00.txt

On 9 mrt 2010, at 1:47, Michael Lui (milui) wrote:

>    Why is translation of EPRT through a stateful translator more
> difficult? Pls clarify.

New text:

because a translation mapping must be set up. This needs to happen before the EPRT command can be translated
into a PORT command and passed on to the server.

>       Not sure what kind of "options" should be allowed? Can you
> clarify this in the doc?

Telnet options. Changed "options" to "Telnet options".

> 3) In 4.2 "EPSV to PASV translation", it mentions:
>   "..    If the client issues EPSV ALL, the FTP ALG must not pass this
> command
>          to the server, but respond with:
> 
>          202 Command not implemented.
>    "

>    Is it a MUST to respond 202 to the client? Is it acceptable not
> sending anything back to the client?

I don't think it mentions anywhere in the FTP specification that responding to commands is mandatory,
however, I believe NOT responding to commands will break the protocol. I added:

An ALG MAY choose to translate the EPSV ALL command into a NOOP command and then the 200 reply into the 504
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 3 May 2010 01:01
Favicon

New Version Notification for draft-ietf-behave-ftp64-01

Here's an FTP64 update.

I incorporated pretty much all the comments. I made this standards track, with RFC 2119 language for the ALG
stuff but only "recommendations" for the client and server behaviors. So I think it's compatible with the charter.

https://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/

Feedback would be appreciated.

Still to do: go over everything for language and to see if the abstract and the introduction are still in
agreement with the rest of the text, and I need to do something about the example addresses.

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: 3 mei 2010 0:55:36 GMT+02:00
> To: iljitsch <at> muada.com
> Subject: New Version Notification for draft-ietf-behave-ftp64-01 
> 
> 
> A new version of I-D, draft-ietf-behave-ftp64-01.txt has been successfully submitted by Iljitsch van
Beijnum and posted to the IETF repository.
> 
> Filename:	 draft-ietf-behave-ftp64
> Revision:	 01
> Title:		 IPv6-to-IPv4 translation FTP considerations
> Creation_date:	 2010-05-02
> WG ID:		 behave
> Number_of_pages: 15
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 3 May 2010 01:07
Favicon

Re: General Comments draft-ietf-behave-ftp64-00

On 2 mei 2010, at 22:58, Iljitsch van Beijnum wrote:

> (You may want to yell at your PDF generation tool vendor.)

Ugh, when I pasted this there were no spaces between the words, this is even worse.

>> As such, an FTP ALG translates all occurrences of the EPSV command issued by the client to the PASV command

> I don't really want to use the word "MUST", as nobody is required to implement an FTP64 ALG. However, this
action is fundamental to being an FTP64 ALG so it doesn't make sense to omit it.

Changed my mind a bit, it's now:

   As such, an FTP ALG MUST
   translate all occurrences of the EPSV command issued by the client to
   the PASV command, and reformat a 227 response as a corresponding 229
   response.  However, an ALG MAY forego EPSV to PASV translation if it
   has positive knowlegde, either administratively configured or learned
   dynamically, that EPSV will be successful without translation to
   PASV.
Permalink | Reply | 7 comments |
headers
Dan Wing | 3 May 2010 19:46
Picon
Favicon

Re: General Comments draft-ietf-behave-ftp64-00


> -----Original Message-----
> From: behave-bounces <at> ietf.org 
> [mailto:behave-bounces <at> ietf.org] On Behalf Of Iljitsch van Beijnum
> Sent: Sunday, May 02, 2010 4:07 PM
> To: Iljitsch van Beijnum
> Cc: IETF BEHAVE WG
> Subject: Re: [BEHAVE] General Comments draft-ietf-behave-ftp64-00
> 
> On 2 mei 2010, at 22:58, Iljitsch van Beijnum wrote:
> 
> > (You may want to yell at your PDF generation tool vendor.)
> 
> Ugh, when I pasted this there were no spaces between the 
> words, this is even worse.
> 
> >> As such, an FTP ALG translates all occurrences of the EPSV 
> command issued by the client to the PASV command
> 
> > I don't really want to use the word "MUST", as nobody is 
> required to implement an FTP64 ALG. However, this action is 
> fundamental to being an FTP64 ALG so it doesn't make sense to omit it.
> 
> Changed my mind a bit, it's now:
> 
>    As such, an FTP ALG MUST
>    translate all occurrences of the EPSV command issued by 
> the client to
>    the PASV command, and reformat a 227 response as a 
> corresponding 229
(Continue reading)

Permalink | Reply | 6 comments |
headers
Iljitsch van Beijnum | 4 May 2010 19:06
Favicon

Re: General Comments draft-ietf-behave-ftp64-00

On 3 mei 2010, at 19:46, Dan Wing wrote:

>> However, an ALG MAY forego EPSV to PASV 
>> translation if it
>>   has positive knowlegde, either administratively configured 
>> or learned
>>   dynamically, that EPSV will be successful without translation to
>>   PASV.

> The text implies that the ALG needs only knowledge that the EPSV command will
> be successful (2xx response).  But it's important that it have knowledge the
> EPSV command *and* the transfer will be successful.

Ah, right.

> I suggest:

> OLD:
>    dynamically, that EPSV will be successful without translation to
>    PASV.
> NEW:
>    dynamically, that EPSV will be successful without translation to
> ......................^^^^
>               "EPSV-initiated file transfer"
>    PASV.

What about:

However, an ALG MAY be configured to forego EPSV to PASV translation for certain servers. Also, an ALG MAY
attempt to determine whether a server can support EPSV file transfers successfully. In this case, any
(Continue reading)

Permalink | Reply | 5 comments |
headers
The IESG | 7 May 2010 15:50
Picon
Favicon

Protocol Action: 'Traversal Using Relays around NAT (TURN) Resolution Mechanism' to Proposed Standard

The IESG has approved the following document:

- 'Traversal Using Relays around NAT (TURN) Resolution Mechanism '
   <draft-ietf-behave-turn-uri-10.txt> as a Proposed Standard

This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. 

The IESG contact persons are David Harrington and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-10.txt

Technical Summary

   This document defines the resolution mechanism to
   generate a list of server transport addresses that can be tried to
   create a Traversal Using Relays around NAT (TURN) allocation.

Working Group Summary

   There is consensus to publish this document, even if only a subset
   of the WG participants has really showed interest.  

Document Quality

   This document has been implemented by at least one party. At least
   one additional party plans to implement it as it becomes RFC.

Personnel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 7 May 2010 17:33
Picon
Favicon

Re: General Comments draft-ietf-behave-ftp64-00


> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch <at> muada.com] 
> Sent: Tuesday, May 04, 2010 10:06 AM
> To: Dan Wing
> Cc: 'IETF BEHAVE WG'
> Subject: Re: [BEHAVE] General Comments draft-ietf-behave-ftp64-00
> 
> On 3 mei 2010, at 19:46, Dan Wing wrote:
> 
> >> However, an ALG MAY forego EPSV to PASV 
> >> translation if it
> >>   has positive knowlegde, either administratively configured 
> >> or learned
> >>   dynamically, that EPSV will be successful without translation to
> >>   PASV.
> 
> > The text implies that the ALG needs only knowledge that the 
> EPSV command will
> > be successful (2xx response).  But it's important that it 
> have knowledge the
> > EPSV command *and* the transfer will be successful.
> 
> Ah, right.
> 
> > I suggest:
> 
> > OLD:
> >    dynamically, that EPSV will be successful without translation to
> >    PASV.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Narasimhan Venkataramaiah | 7 May 2010 20:48
Picon
Favicon

Simultaneous connect

I have a question about the TCP state machine in draft-ietf-behave-v6v4-xlate-stateful-11. In the description below – when a V4 SYN is received and there is no BIB for (X,x) a dummy session entry is created with (X’,x) left unspecified. Is the sole purpose of this entry to delay the error propagation by TCP_INCOMING_SYN? As there is no BIB – there is no guarantee that when the V6 node sends the SYN to Y’,y it will be mapped to (X,x). It is not looked up in the reverse direction – so if policy permits – an ICMP error will be sent for such a V4 SYN.

 

In summary – my understanding so far is that the paragraph below is saying – “If a v4 syn is received and there is no BIB for it – send an ICMP error if policy permits after 6 seconds”. Is this correct?

 

Thanks.

Simha

 

If a V4 SYN packet is received with an incoming tuple with source

   IPv4 transport address (Y,y) and destination IPv4 transport address

   (X,x) (this is the case of a TCP connection initiated from the IPv4

   side), the processing is as follows:

 

      If the security policy requires silently dropping externally

      initiated TCP connections, then the packet is silently discarded,

 

Bagnulo, et al.          Expires October 1, 2010               [Page 27]

Internet-Draft               Stateful NAT64                   March 2010

 

      else,

 

      If the destination transport address contained in the incoming V4

      SYN (i.e., X,x) is not in use in the TCP BIB, then:

 

         The NAT64 tries to create a new session table entry in the TCP

         session table (if resources and policy permit), containing the

         following information:

 

         +  The STE source IPv4 transport address is set to (X,x) (i.e.

            the destination transport address contained in the V4 SYN)

 

         +  The STE destination IPv4 transport address is set to (Y,y)

            (i.e. the source transport address contained in the V4 SYN)

 

         +  The STE transport IPv6 source address is left unspecified

            and may be populated by other protocols out of the scope of

            this specification.

 

         +  The STE destination IPv6 transport address contains the port

            y (i.e. the same port than the destination IPv4 transport

            address) and the IPv6 representation of Y (i.e. the IPv4

            address of the destination IPv4 transport address),

            generated using the algorithm described in Section 3.5.4.

 

<div><div class="WordSection1">
<p class="MsoNormal">I have a question about the TCP state machine in draft-ietf-behave-v6v4-xlate-stateful-11. In the description below &ndash; when a V4 SYN is received and there is no BIB for (X,x) a dummy session entry is created with (X&rsquo;,x) left unspecified. Is the sole purpose of this entry to delay the error propagation by TCP_INCOMING_SYN? As there is no BIB &ndash; there is no guarantee that when the V6 node sends the SYN to Y&rsquo;,y it will be mapped to (X,x). It is not looked up in the reverse direction &ndash; so if policy permits &ndash; an ICMP error will be sent for such a V4 SYN. <p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">In summary &ndash; my understanding so far is that the paragraph below is saying &ndash; &ldquo;If a v4 syn is received and there is no BIB for it &ndash; send an ICMP error if policy permits after 6 seconds&rdquo;. Is this correct?<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Thanks.<p></p></p>
<p class="MsoNormal">Simha<p></p></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>If a V4 SYN packet is received with an incoming tuple with source<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp; IPv4 transport address (Y,y) and destination IPv4 transport address<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp; (X,x) (this is the case of a TCP connection initiated from the IPv4<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp; side), the processing is as follows:<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the security policy requires silently dropping externally<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; initiated TCP connections, then the packet is silently discarded,<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Bagnulo, et al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Expires October 1, 2010&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 27]</span><span><p></p></span></p>
<p class="MsoNormal"><span>Internet-Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stateful NAT64&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2010</span><span><p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else,<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If the destination transport address contained in the incoming V4<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SYN (i.e., X,x) is not in use in the TCP BIB, then:<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The NAT64 tries to create a new session table entry in the TCP<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; session table (if resources and policy permit), containing the<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; following information:<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp; The STE source IPv4 transport address is set to (X,x) (i.e.<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the destination transport address contained in the V4 SYN)<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp; The STE destination IPv4 transport address is set to (Y,y)<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (i.e. the source transport address contained in the V4 SYN)<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp; The STE transport IPv6 source address is left unspecified<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and may be populated by other protocols out of the scope of<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this specification.<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +&nbsp; The STE destination IPv6 transport address contains the port<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; y (i.e. the same port than the destination IPv4 transport<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; address) and the IPv6 representation of Y (i.e. the IPv4<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; address of the destination IPv4 transport address),<p></p></span></p>
<p class="MsoNormal"><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; generated using the algorithm described in Section 3.5.4.<p></p></span></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
</div></div>
Permalink | Reply | 1 comment |

Gmane