Subject: RE: [Ietf-behave] Re: NAT TCP Simultaneous-Open: Request for commentson proposals.

From: "Kaushik Biswas (kbiswas)" <[email-masked]>
Date: Fri, 26 May 2006 13:44:26 -0700 (PDT)

I too am in favor of option # 1. Agree with Philip, Option # 4 can lead
to undeterministic behavior. 

Thanks,
Kaushik 

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Pyda Srisuresh
> Sent: Friday, May 26, 2006 1:38 PM
> To: Philip Matthews; Saikat Guha
> Cc: tcpm-chairs@xxxxxxxxxxxxxx; Lars Eggert; 
> behave-chairs@xxxxxxxxxxxxxx; Behave; Joe Touch
> Subject: Re: [Ietf-behave] Re: NAT TCP Simultaneous-Open: 
> Request for commentson proposals.
> 
> I agree. I am in favor of option 1.
> 
> cheers,
> suresh
> 
> --- Philip Matthews <philip_matthews@xxxxxxxx> wrote:
> 
> > I feel it is important to make TCP Simultaneous-Open work.
> > 
> > Regarding option 4:
> > I feel that coordinating peers so they do things at the 
> same time can 
> > be difficult.
> > If peers A and B are trying to set up a connection between 
> them, but 
> > peer B gets busy doing something else for a few seconds and 
> misses the 
> > 3 second window, then the whole connection attempt fails. In our 
> > product (a peer-to- peer telephony system), we see situations where 
> > the CPU on one hard-phone can get very overloaded for a few 
> seconds. I 
> > could easily see that this option would lead to situations 
> where the 
> > connection would be established most of the time, but would 
> randomly 
> > fail from time-to-time because the 3 second window was missed.
> > 
> > Given this concern, my current preference is for option 1.
> > 
> > Saikat:
> > Might I suggest producing a brief presentation describing these 
> > options and asking for presentation time at both the BEHAVE 
> and TCPM 
> > meetings in Montreal?
> > 
> > - Philip
> > 
> > 
> > On 24-May-06, at 19:52 , Cullen Jennings wrote:
> > 
> > >
> > > I prefer option 1 and when some appropriate ICMP stuff is 
> defined, 
> > > change the recommendation to something like 2.
> > >
> > > 4 is very tricky to know what times would be appropriate.
> > >
> > > On May 24, 2006, at 4:22 AM, Saikat Guha wrote:
> > >
> > >> The discussion on- and off- list had identified a bunch 
> of issues 
> > >> that I quickly summarize below. I would like to get some 
> feedback 
> > >> (particularly on Option 4 from the vendors) on the four 
> potential 
> > >> requirements below.
> > >>
> > >> Issues (simplified, see original thread for details):
> > >> 1. TCP Simultaneous-Open is necessary for P2P apps. NATs 
> shouldn't 
> > >> force
> > >>    such attempts to be aborted. But there is currently 
> no way to do 
> > >> so
> > >>    with ICMP/TCP messages. Barring future work (improbable),
> > >>    facilitating S-O would require NATs ignore the error (perhaps
> > >>    momentarily)
> > >> 2. The intent of prior RFCs is to signal errors (MUST or SHOULD
> > >>    depending) which would hinder P2P TCP, but would follow the 
> > >> spirit of
> > >>    RFCs.
> > >>
> > >>
> > >>
> > >> So here are the options:
> > >>
> > >> Option 1: Current proposal in the draft ========
> > >>   "A NAT MUST silently drop inbound SYNs"
> > >>
> > >> Issues: Totally against the spirit of old RFCs, making network 
> > >> troubleshooting harder, but allows TCP S-O
> > >>
> > >>
> > >> Option 2: Proposed earlier on the list by myself 
> =========  "A NAT 
> > >> MUST NOT force an end-host to abort a TCP connection that could
> > >>   be a S-O. It SHOULD return an error if the error 
> doesn't force the
> > >>   end abort the attempt. Otherwise, it MUST silently 
> drop the SYN"
> > >>
> > >> Issues: Hard to implement and understand. Currently no 
> possible to 
> > >> implement the first two clauses. Still facilitates S-O, but is 
> > >> forwards compatible in the unlikely event that the first two 
> > >> clauses become satisfiable.
> > >>
> > >>
> > >> Option 3: Following the REQ-8 language in the UDP spec 
> =========  
> > >> "If enabling P2P TCP apps is most important, a NAT MUST silently
> > >>   drop the SYN. If enabling quick diagnosis of network 
> errors is most
> > >>   important, a NAT SHOULD signal an ICMP port unreachable. The 
> > >> behavior
> > >>   MAY be configurable by the administrator."
> > >>
> > >> Issues: Let the NAT admin pick whether to allow TCP S-O 
> or signal 
> > >> errors.
> > >>
> > >>
> > >> Option 4: Proposed earlier on list by Joe =========
> > >>
> > >>  "A NAT SHOULD signal an ICMP port unreachable. If it 
> does, it MUST
> > >>   delay the ICMP error by at least 3 seconds and MUST cancel the 
> > >> ICMP if
> > >>   in that time an outbound SYN for the connection is 
> seen. If the NAT
> > >>   does not have resources to delay the ICMP, it MUST 
> silently drop 
> > >> the
> > >>   inbound SYN"
> > >>
> > >> Issues: Delaying the ICMP gives the internal side's SYN or 
> > >> retransmission a chance to trigger a S-O. This requires bounded 
> > >> state at the NAT. In an attack (when the buffer is 
> full), it allows 
> > >> the NAT to silently discard SYNs. Together, it facilitates S-O 
> > >> regardless of whether the NAT is low on resources or 
> not. When the 
> > >> NAT has resources to spare, it facilitates error 
> detection (delayed 
> > >> by 3s). When out of resources it degrades gracefully to 
> support S-O 
> > >> but not fast error detection.
> > >>
> > >>
> > >>
> > >> I'd particularly like to know how vendors and others feel about 
> > >> Option 4.
> > >>
> > >> cheers,
> > >> --
> > >> Saikat
> > > _______________________________________________
> > > Ietf-behave mailing list
> > > Ietf-behave@xxxxxxxxxxxxxxxxxxx
> > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > 
> > _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > 
> 
> 
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>