Subject: RE: [Tsvwg] Congestion window init

From: [email-masked]
Date: Wed, 20 Mar 2002 16:23:44 +0200

This is a mess... I'll better separate my comments from the original message...

-----Original Message-----
From: Arias-Rodriguez Ivan (NRC/Helsinki) 
Sent: 20. March 2002 16:18
To: 'ext Arun Prasad'
Cc: [email-masked]; [email-masked]
Subject: RE: [Tsvwg] Congestion window init

    Hi Arun!
 
    Nice to hear that there are people around reading my Thesis... :-)

-----Original Message-----
From: ext Arun Prasad [mailto:[email-masked]]
Sent: 20. March 2002 12:42
To: Arias-Rodriguez Ivan (NRC/Helsinki)
Cc: [email-masked]; [email-masked]
Subject: Re: [Tsvwg] Congestion window init

Hi Ivan, 
    Ya, I got ur point.... thanks for that....... 

-------------------------------------------------
[Arias-Rodriguez Ivan (NRC/Helsinki)] Not at all...
-------------------------------------------------

     I have one more question for you... 
From your thesis  "Stream Control Transmission Protocol .The design of a new reliable transport protocol for IP networks" : 
"An attacker could easily send us any of those ICMP messages to affect our 
sending capabilities reducing our throughput. Therefore, the SCTP header was 
designed so the Verification Tag is present in the ICMP messages. When 
processing a received ICMP packet, the association affected is determined by 
using the Source Address and Destination Address fields (carried in the IP header 
inside the ICMP message), and the Source Port Number and Destination Port 
Number (carried in the first 4 bytes of the SCTP header also included in the ICMP 
message). Then, to validate that this ICMP packet was not sent by an attacker, the ICMP message is validated by comparing the SCTP 
Verification Tag also carried in the ICMP message and checking that it is 
the right one." 
    The Verification Tag validation, which is specified above should be mentioned 
in the RFC .... atleast with a MAY condition right.....( I think I didnt miss this in 
the Rfc)..... 

-------------------------------------------------
[Arias-Rodriguez Ivan (NRC/Helsinki)] No, there is nothing in the RFC regarding ICMP.
    Well, in that paragraph I was trying to explain why the common header has that shape, with the port numbers and VT in the first 8 bytes. There are some ICMP messages that could affect SCTP such as the "Source Quench" message (I haven't seen any though) and the "Fragmentation Needed and DF Set"/"Packet Too Big".
    I don't worry about "Source Quench" messages, but the second type is used in the MTU Discovery algorithm. I validate the incoming packet, but, I don't think there should be anything in the RFC. This is the interaction between SCTP and ICMP... TCP doesn't say anything about this either, but it is true that TCP does not have anything such as the VT to avoid this... :-/
-------------------------------------------------

      Since the point of validating the VTag for an ICMP message is very important 

-------------------------------------------------
[Arias-Rodriguez Ivan (NRC/Helsinki)] Well... "very important"... I don't know...
    However, in fact there was a discussion when the final shape of the Common Header was designed (previously the checksum bytes where inside those 8 first bytes), because of these ICMP messages. Otherwise an attacker could lower our MTU to its minimum, damaging our throughput and the efficiency of our transmission...
-------------------------------------------------

 ( in terms of an attacker...) the implementer of the SCTP should be informed about 
validating it right!!! 

-------------------------------------------------
[Arias-Rodriguez Ivan (NRC/Helsinki)] I don't know what the rest of the people think, but I'm unsure that this should be included in the RFC. I have always thought that this was kind of (let me use this expression) "common sense practice"...
    Thanks!!!
    BR Iván Arias Rodríguez
-------------------------------------------------

 Thanks 
-arun 

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Arun Prasad <[email-masked]>
Date: Thu, 21 Mar 2002 10:14:30 +0530

hi Ivan,
    comments inline....

>     Nice to hear that there are people around reading my Thesis... :-)

           Why not.... The doc speaks more of "Why"  than "What" ....  which many
docs fail to do....  Nice to read the doc....

>     Ya, I got ur point.... thanks for that.......

From Rfc:  sec 7.3
    "There are 4 ways in which SCTP differs from the description in RFC
   1191 of applying MTU discovery to TCP:"

        I think we can place this condition below the above specified section.......

>       Since the point of validating the VTag for an ICMP message is very important

            Since the main purpose of Verfication Tag is to avoid any attacker from
shattering the Association and to discard the stale associations..... and thats the
reason we have the VTag in all the packets in an Association...   In this case
why not validating an ICMP message received due to some packets in the
SCTP association...

        I feel this should be spelt as some MAY condition in the Rfc ..... or atleast
    a section like "common sense practice"  :) can be created to carry these
    suggestions... which will be useful as a guide for the implementer

--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.

Contact # : 9144 - 2334174
            9144 - 2334181
            extn : 233
****************************************************************

---

From: Randall Stewart <[email-masked]>
Date: Wed, 27 Mar 2002 08:40:18 -0600

Arun:

One of the things I was hammered on over and over again by
Qiaobing as we wrote and re-wrote (as Ivan's thesis attests
to :>) was that you don't describe implementation.. or at
least stay away from it as much as possible.

I understand your point and this is why we wrote a book
as well... to say all the things that we could not in
the RFC.... 

I just don't see that adding this to the RFC is the right
thing to do... We placed it in the packet so that a ICMP
message would carry it as Ivan states.. but it is up to
the implementor to use the information if it is concerned
about a ICMP attack... adding a MAY here I don't think
is of any benefit. If you are truely concerned (which
most developers will be) then you will nicely discover
that every ICMP message (v4 or v6) will have the tag
available for verification :>

R

Arun Prasad wrote:
> > >From your thesis  "Stream Control Transmission Protocol .The design
> > of a new reliable transport protocol for IP networks" :
> > message). Then, to validate that this ICMP packet was not sent by an
> > attacker, the ICMP message is validated by comparing the SCTP
> >     Well, in that paragraph I was trying to explain why the common
> > header has that shape, with the port numbers and VT in the first 8
> > bytes. There are some ICMP messages that could affect SCTP such as
> > the "Source Quench" message (I haven't seen any though) and the
> > "Fragmentation Needed and DF Set"/"Packet Too Big".
> >     I don't worry about "Source Quench" messages, but the second
> > type is used in the MTU Discovery algorithm. I validate the incoming
> > packet, but, I don't think there should be anything in the RFC. This
> > is the interaction between SCTP and ICMP... TCP doesn't say anything
> > about this either, but it is true that TCP does not have anything
> > such as the VT to avoid this... :-/
> >     However, in fact there was a discussion when the final shape of
> > the Common Header was designed (previously the checksum bytes where
> > inside those 8 first bytes), because of these ICMP messages.
> > Otherwise an attacker could lower our MTU to its minimum, damaging
> > our throughput and the efficiency of our transmission...
> >
> 
> > [Arias-Rodriguez Ivan (NRC/Helsinki)] I don't know what the rest of
> > the people think, but I'm unsure that this should be included in the
> > RFC. I have always thought that this was kind of (let me use this
> > expression) "common sense practice"...
> 

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)