Re: review of draft-ietf-dccp-simul-open-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > The introduction mentions that DCCP simultaneous open can 
> be disabled ("turned
> > off").  However, there is no further information regarding 
> this.  Is there a
> > reason why a DCCP stack would want to disable this 
> functionality?  As you
> > know, there is no way for a host to determine if specific 
> communications might
> > be NATted, so it is difficult to say "turn it off if the 
> host is not behind a
> > NAT".
> > 
> OK will reword. The only issue I can think of relates to security 
> policy, as mentioned in the security considerations.
> 
> NEW:
> The use of a dedicated DCCP packet type, ties usage to a specific 
> condition, ensuring the method is inter-operable with hosts 
> that do not 
> implement this update, or disable it. (e.g. DCCP servers that 
> employ a 
> secuirty where they do not wish to disclose the port on which 
> they are 
> listening can refrain from generating DCCP-Listen packets, without 
> impacting subsequent DCCP state transitions.)

I think this over-states the risk of a server sending a 
DCCP-Listen.

A DCCP-Listen is only sent if the DCCP server knows the IP address
and DCCP port of an impending DCCP client connection attempt.  Does
an attacker learn anything by seeing the DCCP server emit a 
DCCP-Listen packet a few milliseconds before the incoming DCCP-
Request?

The only thing I believe an attacker would learn is the IP address
and DCCP port of the impending DCCP-Request.  With that knowledge, 
the attacker could spoof that IP address and DCCP port and thus
successfully spoof being that DCCP client endpoint.  This would 
require the attacker to be on-path between the DCCP server and DCCP 
client (in order to see the DCCP-Listen packet).

Contrast that to the situation where DCCP-Listen is not sent.  In
that situation, the attacker would have to be on-path between the
DCCP client and the DCCP server, and the attacker would have to
destroy the DCCP-Request packet (e.g., invalidate its Ethernet
checksum) and generate its own DCCP-Request by spoofing the 
IP address and DCCP port.

So, I believe the real risk of sending the DCCP-Listen is that
it creates an opportunity for an on-path attacker to spoof the
DCCP client if that attacker is on-path between the DCCP server 
and the DCCP client.  

Sending DCCP-Listen only increases the attack surface if there 
is asymmetric routing between the DCCP client and server.


And if my analysis is wrong, I am sure someone will correct me.

...

> > Section 2.3.1,
> > 
> >    The server SHOULD repeat sending a DCCP-Listen packet 
> while in state
> >    INVITED, at a 200 millisecond interval and up to at most 2
> >    repetitions (Section 3 discusses this choice of timer 
> interval).  The
> >    retransmission timer is restarted with the same 200ms 
> interval after
> >    the second retransmission.  When, upon the next timeout, 
> the server
> >    is still in the INVITED state, it SHOULD progress to LISTEN, and
> >    resume processing as specified in [RFC4340].
> > 
> > I found the paragraph above confusing.  The first sentence says
> > "send DCCP-Listen, wait 200ms, send another DCCP-Listen, 
> wait 200ms, 
> > send another DCCP-Listen."  
>  >
> >  The second sentence then appears to
> > say the retransmission timer is restarted with the same 200ms 
> > value (but the value didn't previously change!).  I can't
> > follow the intent. 
>  >
> > I read section 3.3, too, and I cannot figure
> > out how many packets are really supposed to be sent.  Section 
> > 3.3 says:  "recommend a maximum number of 3 timeouts (2 
> > repetitions) results from the following considerations.".
> > 
> AH, then we should re-write:
> 
> NEW:
> "The server SHOULD repeat sending a DCCP-Listen packet while in the 
> INVITED state, at a 200 millisecond interval and up to at most 2 
> repetitions ([ref] discusses this choice of timer interval).

That is a total of three packets, right?

  send packet, wait 200ms
  send packet, wait 200ms  <--- "first repetition" (first expiration)
  send packet              <--- "second repeittion" (second expiration)

> If the 
> server is still in the INVITED state after a further period of 200ms 
> following transmission of the second  DCCP-Listen packet,
                                ^^^^^^
                                "third"

> it SHOULD 
> progress to the LISTEN state, and resume processing as specified in 
> [RFC4340]. This  be implemented using a retransmission timer for the 
> INVITED state. The timer is restarted after sending each DCCP-Listen 
> packet, with an interval of 200ms. It is cancelled when the server 
> leaves this state. The first and second expiry of this timer trigger 
> transmission of the DCCP-Listen Packet. A third expiry of the timer 
> results in the server progressing to the LISTEN state.
> 
> >    Server endpoints SHOULD in general ignore any incoming 
> DCCP-Listen
> >    packets.  As an exception to this rule, a DCCP Server in 
> state LISTEN
> >    MAY generate a Reset (Code 7, "Connection Refused") in 
> response to a
> >    DCCP-Listen packet. 
> > 
> > This should more clearly indicate it is a DCCP Reset.
> > 
> Agree. This and other instances have been corrected.
> 
> >    This Reset is an indication that two servers are
> >    simultaneously awaiting connections on the same port.
> > 
> > 
> >    Fully-specified server endpoints SHOULD treat ICMP error messages
> >    received in response to a DCCP-Listen packet as "soft 
> errors" that do
> >    not cause a state transition.
> > 
> > It would be useful to discuss why this is a SHOULD -- perhaps
> > in the Design Decisions section.  I believe it allows two hosts to 
> > do a simultaneous DCCP open, when those hosts are directly 
> connected 
> > (that is, without a draft-ietf-behave-dccp-compliant NAT between 
> > them).
> > 
> NEW:
> Fully-specified server endpoints SHOULD treat ICMP error messages 
> received in response to a DCCP-Listen packet as "soft errors" that do 
> not cause a state transition. Reception of an ICMP error message as a 
> result of sending a DCCP-Listen packet does not necessarily 
> indicate a 
> failure of the following connection request, and therefore should not 
> result in a server state change. This reaction to soft errors 
> exploits 
> the valuable feature of the Internet that for many network 
> failures, the 
> network can be dynamically reconstructed without any 
> disruption of the 
> endpoints.

Thanks.

By the way, I noticed some inconsistency between "fully-specified"
and "fully specified" (no hyphen) throughout the document.

-d


[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux