요약

  • RFC 1068은 FTP 매개변수를 제어 호스트의 영속 대기열에 저장한 뒤, 사용자가 떠난 후에도 데몬이 일반적인 서버 간 전송을 예약하고 재시도하도록 했다. 요청 접수는 지시를 영속화했을 뿐, 파일 자체를 옮기지는 않았다.
  • 여러 파일의 경우 BFTP는 첫 성공적인 이름 목록을 고정하고, 성공한 각 구성원을 기억한 다음 나머지 파일만 재시도했다. 요청은 모두 성공, 영구적 실패, 재시도 한도 초과의 경우 '완료'로 불릴 수 있었으므로, 파일별 보고서가 결과를 담았고 '완료'라는 단어 자체는 그렇지 않았다.

RFC 1068에서 중요한 대상은 작성자가 떠난 후에도 남아 있는 요청이다. 이 실험 이전에는 인터넷 파일 전송이 보통 전경(foreground) 작업이었다고 이 문서는 말한다. 사람이 FTP를 시작하고 결과를 지켜보며, 실패하면 명령을 다시 내렸다. 호스트와 경로가 부담이 적고 대체로 항상 이용 가능할 때는 견딜 수 있는 방식이었다. 혼잡, 지연, 장애는 인간의 대기를 실패 모델의 일부로 만들었다.

BFTP는 그 대기를 저장된 상태로 옮겼다. 사용자 인터페이스가 원하는 작업을 수집했다. 파일 전송 제어 데몬인 FTC가 나중에 그 작업을 수행했다. 이 문서는 새로운 전송 프로토콜을 도입하지 않았다. 대기열, 스케줄러, 일반적인 FTP 제어 대화, 알림 채널을 하나의 서비스로 조합했고, 그 지시는 대화형 세션보다 오래 남을 수 있었다.

세 대의 호스트가 세 가지 다른 역할을 맡을 수 있었다

원본 호스트, 목적지 호스트, BFTP 제어 호스트는 반드시 같은 기계일 필요가 없었다. 사용자는 두 호스트 이름, 로그인 이름과 암호, 원본과 목적지 파일 이름, 그리고 복사·이동·삭제·교체·추가 또는 고유 파일 생성에 대한 선택 사항을 제공했다. FTP의 타입, 모드, 구조도 선택할 수 있었다. 와일드카드는 여러 파일을 지정할 수 있었다. 시작 시간을 지정해 첫 시도를 미룰 수도 있었다.

마지막으로 사용자는 메일함을 제공하고submit을 내렸다. 그 시점에서 인터페이스는 종료될 수 있었다. 남은 것은 대기열 항목이었다: 매개변수, 일정, 알림 주소, 그리고 이후의 진행 상황. 원본 파일은 그렇게 해서 목적지에 도달하지 않았다. 이 구분이 중요한 이유는, 매력적인 표현인 '백그라운드 전송'이 지시와 결과를 결합하는데, 그 결과는 여전히 두 원격 서버와 하나의 경로에 의존하기 때문이다.

사용자는verify도 실행할 수 있었다. BFTP는 두 FTP 서버에 접속하고, 로그인하고, 매개변수를 점검하며, 지정된 원본이 존재하는지 확인하려 시도했다. 원격 호스트가 다운되어 있으면 일부 확인은 불가능했다. 성공적인 검증조차 별도의submit과 이후의 시도에 앞서는 것이었다. 검증은 확인 시점에 선택된 사실들이 참이었음을 증명했을 뿐, 미래의 도달 가능성, 자격 증명, 목적지 상태, 전송 완료를 예약하지는 않았다.

제어기는 자신이 실어 나르지 않는 바이트를 지휘했다

BFTP는RFC 959에서 이미 정의된 제3자(third-party), 즉 서버-서버 모델을 사용했다. FTC 데몬은 원본 FTP 서버에 하나의 제어 연결을, 목적지 서버에 또 하나의 제어 연결을 열었다. 한쪽에서PASV를 사용해 엔드포인트를 얻고, 그 엔드포인트를PORT로 다른 쪽에 전달한 다음,RETR과STOR를 짝지었다. 데이터 연결은 두 FTP 서버 사이에서 직접 실행되었다. 제어 호스트는 응답을 받아 결정을 내렸지만, 파일 바이트 자체는 제어 호스트를 우회했다.

이 토폴로지는 세 종류의 근거를 분리한다. 대기열은 제어기가 무엇을 의도했는지 보여준다. 두 개의 제어 채널은 서버가 어떤 명령을 수락하거나 거부했는지 보여준다. 데이터 연결은 파일 자체를 실어 나른다. RFC 959는 전송 중 제어 연결이 열려 있어야 하며, 제어기가 다른 전송 명령을 내리기 전에 최종226또는250응답을 기다리도록 요구했다. 따라서 연결된 소켓, 잠정적 응답, 또는 닫힌 데이터 경로만으로는 파일의 결과를 확정할 수 없었다.

BFTP에는 최소 한 대의 서버가PASV를 구현해야 했다. 또한 두 구현이 타입, 모드, 경로 이름, 응답 문법, 실패 분류에 대해 합의해야 했다. 이 논문은 누락된PASV, 불규칙한NLST출력, 기형 응답, 그리고 끊어진 연결을 영구적5xx결과로 반환해야 사실상 일시적4xx였을 것들을 영구 실패로 처리하는 서버들을 보고했다. 재시도 엔진은 그것이 받는 실패 어휘만큼만 정확할 수 있다.

신뢰성은 하나의 FTP 세션 위에 존재했다

일시적 실패의 경우 데몬은 그 이벤트를 기록하고 제한 시간 후 다시 시도했다. RFC 1068은 예시적 일정을 제시한다: 약 10분으로 시작해 연속 구간을 두 배씩 늘리고, 약 4시간에서 증가를 멈춘다. 이 수치들은 하나의 구현을 설명했을 뿐, 인터넷에 부여된 상수가 아니었다.

이것은 FTP 세션 위의 신뢰성이었다. 대기열은 별개의 제어 및 데이터 연결에 걸쳐 원하는 작업을 기억했다. 또한 끝을 부과했다: 성공, 영구적 실패, 또는 설정된 재시도 한도. 그 다음 데몬은 메일을 보냈다. 알림은 제어기가 최종 워크플로우 상태에 도달했음을 의미했다. 그 상태가 좋은지 나쁜지는 보고서 안에 남아 있었다.

따라서RFC 959의4yz와5yz분류 사이의 구분은 운영적으로 중요했다.4yz응답은 요청된 작업이 발생하지 않았지만 요청을 바꾸지 않고 다시 시도할 수 있음을 말했다.5yz응답은 정확한 반복을 권하지 않았다. 끊어진 연결을 영구 실패로 잘못 분류하는 것은 단순히 잘못된 레이블을 고르는 데 그치지 않았다. 그것은 데몬이 다시 시도할지 여부 자체를 바꾸었다.

요청이 대기하는 동안 디렉터리는 바뀔 수 있었다

와일드카드는 BFTP가 어떤 파일들이 영속 작업에 속하는지 정하게 만들었다. 원본 디렉터리가 계속 바뀐다면, 매 재시도마다NLST를 반복하면 접수 시점에 없던 파일이 조용히 추가되거나 사용자가 기대하던 파일이 제거될 수 있었다. 그래서 BFTP는 첫 성공적인NLST가 반환한 목록을 저장했다. 그 목록이 요청의 구성원 경계가 되었다. 이후에 도착한 것은 그 경계 바깥이었다.

전송은 의도적으로 비원자적이었다. 네 개의 파일이 성공하고 다섯 번째가 실패하면, BFTP는 전체 세트를 다시 시작할 수 있도록 네 개의 목적지 복사본을 삭제하지 않았다. 상태 포인터가 어떤 구성원이 성공했는지 기억했고, 이후 사이클은 불완전한 것만 시도했다. 영속성은 불필요한 반복을 막았지만, 동시에 요청이 혼합된 이력을 담을 수도 있음을 의미했다.

RFC 1068은 세 가지 경우에 요청을 완료로 명명한다: 모든 개별 전송이 성공했을 때, 영구적 실패가 발생했을 때, 또는 재시도 한도에 도달했을 때. 완료는 그렇게 데몬이 작업 예약을 멈췄음을 의미했다. 모든 목적지 복사본이 존재함을 의미하지 않았다. 알림에는 각 파일의 상태가 나열되었는데, 전체 성공을 부분 실패 또는 전체 실패와 구분할 수 있는 것은 그 파일별 장부뿐이기 때문이다.

상태와 취소는 약한 키워드에 의존했다

사용자는 돌아와서 요청과 함께 저장된 키워드를 제공하고, 일치하는 작업을 찾아 하나를 취소할 수 있었다. 저자들은 이를 명시적으로 약한 인증이라 불렀다. 두 사용자가 같은 키워드를 선택하면, 한쪽이 다른 쪽의 요청을 조회하거나 취소할 수 있었다. 취소는 메일을 생성했지만, 행위 이후의 알림이 이전의 권한을 만들어내지는 않았다.

이 약점은 역사적 제어 표면의 일부이며, 이 문서에 없는 인증 시스템을 기준으로 판단하라는 초대가 아니다. 이것은 영속적인 작업이 영속적인 권한을 만든다는 것을 알려준다: 조회, 재시도, 취소, 복사 후 원본 삭제, 목적지 덮어쓰기, 그리고 실패를 언제 최종으로 선언할지의 결정. 전송 프로토콜이 변하지 않더라도 각 권한에는 소유자가 필요하다.

이후RFC 2577은 프록시 FTP의PORT권한이 서버를 다른 서비스로 향하게 지시하는 데 악용될 수 있음—바운스 공격—을 문서화하고, 프록시 기능을 포기하는 제한을 논의했다. 그 이후의 경고가 BFTP 사건을 입증하는 것은 아니다. 다만 '제어기는 연결만 준비했다'를 '제어기는 무해한 권한을 가졌다'로 다루어서는 안 되는 이유를 보여준다.

출처와 한계

RFC 1068은 ISI에서 몇 달간 사용된 구현을 기록하고 현지 경험을 보고한다. 이것은 광범위한 채택이나 현대의 작업 대기열, 클라우드 전송, 워크플로우 엔진으로의 직접적 계보를 입증하지 않는다. RFC 959는 FTP의 제어/데이터 분리와 최종 응답 의미론을 제공한다. RFC 2577은 제3자 지정에 대한 이후의 보안 경계를 제공한다. 어느 것도 특정 전송의 성공, 현재 배포, 자격 증명의 안전성, 또는 성공적인 적용 결과를 입증하지 않는다.

영속적인 교훈은 더 좁다. 의도를 영속화하면 신뢰성을 높일 수 있지만, 그것은 자신이 지시하는 대상과 혼동되어서는 안 되는 기록을 지닌 두 번째 시스템을 만든다. 대기열은시도하라고 말할 수 있다. 결과를 확립할 수 있는 것은 파일별 근거뿐이다.