Transport Area Working Group (tsvwg)

Brian F. G. Bidulock | 6 Jan 2004 00:07

Re: Establishment of SCTP association

Mikael.Latvala,

Doing so would destroy the reliability of a multi-homed association.  As an
operator's policy, the operator is welcome to prohibit multi-homed
associations altogether.  Then the operator can be sure that the INIT-ACK
address is the same as the INIT.  I think you speak of a operational issue
rather than a protocol issue.

--brian

On Mon, 29 Dec 2003, Mikael.Latvala <at> nokia.com wrote:

> Michael,
> 
> I agree, that true man-in-middle can do lots of harm at the transport layer. However, association
highjack is definately the worst one.
> 
> If you want to use IPsec against such attacks, configuring IPsec becomes in no time mission impossible, if
INIT-ACK's source IP address can be different than INIT's destination IP address. Simple because if this
is allowed, person configuring IPsec policy database must know before hand any IP address that the peer
may use in an SCTP assocation.
> 
> However, if INIT-ACK's source IP address would be always the same than INIT's destination IP address,
then person in charge of configuring IPsec policy database  would have to know only one IP address. The
other additional IP addresses negotiated during and possibly after SCTP association setup could be
dynamically added to the IPsec policy database.
> 
> Obviously one could use wildcard in a source selector field in IPsec policy database. Unfortunately
there are plenty of companies who do not approve such security policy. 
>

(Continue reading)

headers

Michael Tuexen | 6 Jan 2004 01:13

Re: Establishment of SCTP association

Mikael,

see my comments below.

Best regards
Michael

On 29. Dec 2003, at 9:50 Uhr, Mikael.Latvala <at> nokia.com wrote:

> Michael,
>
> I agree, that true man-in-middle can do lots of harm at the transport 
> layer. However, association highjack is definately the worst one.
>
> If you want to use IPsec against such attacks, configuring IPsec 
> becomes in no time mission impossible, if INIT-ACK's source IP address 
> can be different than INIT's destination IP address. Simple because if 
> this is allowed, person configuring IPsec policy database must know 
> before hand any IP address that the peer may use in an SCTP 
> assocation.
>
> However, if INIT-ACK's source IP address would be always the same than 
> INIT's destination IP address, then person in charge of configuring 
> IPsec policy database  would have to know only one IP address. The 
> other additional IP addresses negotiated during and possibly after 
> SCTP association setup could be dynamically added to the IPsec policy 
> database.
>
I agree with you that if one peer has n addresses and the other m the 
person has to set up 2 * n * m SAs and he must know

(Continue reading)

headers

Randall R. Stewart (home | 6 Jan 2004 15:47

Re: Establishment of SCTP association

Mikael/Michael:

My comments below..

Michael Tuexen wrote:

> Mikael,
>
> see my comments below.
>
> Best regards
> Michael
>
> On 29. Dec 2003, at 9:50 Uhr, Mikael.Latvala <at> nokia.com wrote:
>
>> Michael,
>>
>> I agree, that true man-in-middle can do lots of harm at the transport 
>> layer. However, association highjack is definately the worst one.
>>
>> If you want to use IPsec against such attacks, configuring IPsec 
>> becomes in no time mission impossible, if INIT-ACK's source IP 
>> address can be different than INIT's destination IP address. Simple 
>> because if this is allowed, person configuring IPsec policy database 
>> must know before hand any IP address that the peer may use in an SCTP 
>> assocation.
>>
>> However, if INIT-ACK's source IP address would be always the same 
>> than INIT's destination IP address, then person in charge of 
>> configuring IPsec policy database  would have to know only one IP

(Continue reading)

headers

Mark Allman | 7 Jan 2004 15:13

proposed TCPM charter


Hi folks!  Happy New Year!

As discussed in the tsvwg meeting in Minneapolis several folks have been
chatting about starting a new WG to focus on TCP modifications and minor
changes.  This is mostly an effort to offload work from tsvwg and to
sharpen the focus on that work.  Ted Faber and I have worked with the
TSV ADs to come up with a possible charter that is attached to this
message.  We'd love to hear any feedback folk might have on how to make
the charter better.

Thanks!

allman

---
TCP Maintenance and Minor Extensions (TCPM) Working Group

Description:

    TCP is currently the Internet's predominant transport protocol.
    To maintain TCP's utility the IETF has regularly updated both
    the protocol itself and the congestion control algorithms
    implemented by the protocol that are crucial for the stability
    of the Internet.  These changes reflect our evolving
    understanding of transport protocols, congestion control and new
    needs presented by an ever-changing network.  The TCPM WG will
    provide a venue within the IETF to work on these issues.  The WG
    will serve several purposes:

(Continue reading)

headers

Randall R. Stewart (home | 7 Jan 2004 15:21

Re: Establishment of SCTP association

Mikael.Latvala <at> nokia.com wrote:

>Michael & Randall,
>
>Comments:
>
>1. Linux is one of the operating system to which Michael referred. More specifically, lksctp receives
information from kernel's routing service how the packet should be sent (i.e. what source IP address and
interface). This routing "cache" entry is attached to the assocation so that this step does not have to be
repeated for other packets which belong to the same assocation.
>
>However, when requesting information from routing service it is possible to tell what is the preferred
source IP address. If for some reason this source IP address cannot be used (e.g. interface with which the
IP address is associated is down) lksctp is informed of this, and thus can repeat the process using some
other valid source IP address. Therefore at least from the Linux point of view, I cannot see that the
current implementation would not allow to use the destination IP address of INIT as the source IP address
of INIT-ACK.
>

The above is just one scenario... here is another.

Host-A                                                                    
   Host-Z

IP-1    ---------------||net-isp1                        
net-isp3||-------IP-3

IP-2    ---------------||net-isp2                        
net-isp4||-------IP-4

(Continue reading)

headers

Randall R. Stewart (home | 7 Jan 2004 16:08

Re: proposed TCPM charter

Mark:

It think the charter looks great... any chance that
you have finally agreed to chair the group?

You have my vote :->

R

Mark Allman wrote:

> 
>Hi folks!  Happy New Year!
>
>As discussed in the tsvwg meeting in Minneapolis several folks have been
>chatting about starting a new WG to focus on TCP modifications and minor
>changes.  This is mostly an effort to offload work from tsvwg and to
>sharpen the focus on that work.  Ted Faber and I have worked with the
>TSV ADs to come up with a possible charter that is attached to this
>message.  We'd love to hear any feedback folk might have on how to make
>the charter better.
>
>Thanks!
>
>allman
>
>
>---
>TCP Maintenance and Minor Extensions (TCPM) Working Group
>

(Continue reading)

headers

Michael Tuexen | 8 Jan 2004 14:07

Re: Establishment of SCTP association

Mikael,

I agree with Randy. See one additoinal comment below.

Best regards
Michael

On 7. Jan 2004, at 15:21 Uhr, Randall R. Stewart (home) wrote:

> Mikael.Latvala <at> nokia.com wrote:
>
>> Michael & Randall,
>>
>> Comments:
>>
>> 1. Linux is one of the operating system to which Michael referred. 
>> More specifically, lksctp receives information from kernel's routing 
>> service how the packet should be sent (i.e. what source IP address 
>> and interface). This routing "cache" entry is attached to the 
>> assocation so that this step does not have to be repeated for other 
>> packets which belong to the same assocation.
>>
>> However, when requesting information from routing service it is 
>> possible to tell what is the preferred source IP address. If for some 
>> reason this source IP address cannot be used (e.g. interface with 
>> which the IP address is associated is down) lksctp is informed of 
>> this, and thus can repeat the process using some other valid source 
>> IP address. Therefore at least from the Linux point of view, I cannot 
>> see that the current implementation would not allow to use the 
>> destination IP address of INIT as the source IP address of INIT-ACK.

(Continue reading)

headers

Mikael.Latvala | 8 Jan 2004 13:17

RE: Establishment of SCTP association

Randall,

Based on the scenario you presented and assuming that both hosts have 2 network interfaces Host-A has at
least the following entries in its routing table

Destination	    Gateway        Iface
0.0.0.0         ips1-router    eth0            #IP-1 assigned to interface eth0
ips4-subnet     ips2-router    eth1            #IP-2 assgined to interface eth1 

Host-Z's routing table looks like

Destination	    Gateway        Iface
0.0.0.0         ips4-router    eth0            #IP-4 assigned to interface eth0
ips1-subnet     ips3-router    eth1            #IP-3 assgined to interface eth1 

Without the second entry in both routing tables, administrator would have to manually reconfigure the
routing table in case eth0 fails. How else host would know where to send the IP packet after an interface
failure? (Or are you assuming that in case of an interface failure there is some magic script which removes
the old void default route entry and adds a new one?)

So, when host-Z sends INIT-ACK back it is going to choose eth1 (IP-3 as source IP address) because of the
longest prefix match rule. Not eth0 as you stated. 

Host-Z's routing entries could be in other order where host-Z's default route is ips3

Destination	    Gateway        Iface
0.0.0.0         ips3-router    eth0            #IP-3 assigned to interface eth0
ips2-subnet     ips4-router    eth1            #IP-4 assgined to interface eth1 

But this would not change the situation as IP-3 would be still chosen as the source IP address.

(Continue reading)

headers

Mikael.Latvala | 7 Jan 2004 14:48

RE: Establishment of SCTP association

Michael & Randall,

Comments:

1. Linux is one of the operating system to which Michael referred. More specifically, lksctp receives
information from kernel's routing service how the packet should be sent (i.e. what source IP address and
interface). This routing "cache" entry is attached to the assocation so that this step does not have to be
repeated for other packets which belong to the same assocation.

However, when requesting information from routing service it is possible to tell what is the preferred
source IP address. If for some reason this source IP address cannot be used (e.g. interface with which the
IP address is associated is down) lksctp is informed of this, and thus can repeat the process using some
other valid source IP address. Therefore at least from the Linux point of view, I cannot see that the
current implementation would not allow to use the destination IP address of INIT as the source IP address
of INIT-ACK.

2. If we agree that there must a statement along the lines "The source IP address of INIT-ACK must be the same
that the destination IP address of INIT.", I do not know what would be the most apprioriate SCTP related
draft where this should be inserted.

3. RFC3554 (SCTP with IPsec) talks about how IKE can negotiate and associate multiple destination/source
IP address pairs with a sigle IPsec SA in Phase 2. It does not address the issue that security administrator
must know apriori all the source/destination IP address pair combinations. Perhaps Steve Bellovin et
al. where not aware of the fact the source IP address of INIT-ACK is not necessarily equal to the
destination IP address of INIT. Therefore RFC3554 also fails to discuss the issue that negotiation of IP
addresses for SA when SCTP is used should happen in two phases. In the first phase apriori known IP
addresses are negotiated (hopefully one IP pair per assocation). In the second phase the other IP
addresses used in an association are added to the established IPsec SA. The addition of other IP addresses
should be transparent to the security administrator.

(Continue reading)

headers

Michael Tuexen | 8 Jan 2004 14:34

Re: Establishment of SCTP association


On 8. Jan 2004, at 13:17 Uhr, <Mikael.Latvala <at> nokia.com> wrote:
Mikael,

assume host 1 has a route for 10.1.1.0/16 through eth0 (10.1.1.1/24) 
and 10.2.0.0/16 through eth1 (10.2.1.1/24).
Furthermore host 2 has only one interface 10.1.2.1 and a default route 
to eth0 (10.1.2.1/24).

Assume that the default router of host 2 has connectivity to both 
routers used by host 1.

If host 2 sends a INIT to host 1 using 10.1.1.1 as distination address 
host 1 will send back the
INIT-ACK to 10.1.2.1 and 10.1.1.1 as source address. Everything is fine.

But if host 2 sends the INIT to host 1 using 10.2.1.1 as destination 
address host 1 wil send
back the INIT-ACK to 10.1.2.1 using eth0 and therefore would choose 
10.1.1.1 as a source address
of the INIT-ACK.

Using your rule the association could not be established in this 
scenario. You do not have
redundancy here, but that is clear. But is is important to accept 
INIT-ACK from addresses not
being the destination address of the INIT.

You could say the host 1 could use the other address still using the 
router but the router

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

20	May 2013
50	April 2013
156	March 2013
58	February 2013
23	January 2013
28	December 2012
65	November 2012
72	October 2012
12	September 2012
29	August 2012
70	July 2012
50	June 2012
24	May 2012
51	April 2012
72	March 2012
14	February 2012
17	January 2012
30	December 2011
24	November 2011
23	October 2011
18	September 2011
45	August 2011
37	July 2011
31	June 2011
19	May 2011
11	April 2011
139	March 2011
30	February 2011
136	January 2011
69	December 2010
60	November 2010
57	October 2010
48	September 2010
81	August 2010
28	July 2010
19	June 2010
33	May 2010
13	April 2010
72	March 2010
74	February 2010
65	January 2010
49	December 2009
94	November 2009
91	October 2009
30	September 2009
34	August 2009
51	July 2009
21	June 2009
162	May 2009
17	April 2009
44	March 2009
51	February 2009
20	January 2009
11	December 2008
125	November 2008
102	October 2008
89	September 2008
21	August 2008
64	July 2008
12	June 2008
82	May 2008
97	April 2008
50	March 2008
56	February 2008
78	January 2008
30	December 2007
29	November 2007
69	October 2007
60	September 2007
41	August 2007
143	July 2007
91	June 2007
56	May 2007
121	April 2007
118	March 2007
34	February 2007
80	January 2007
78	December 2006
142	November 2006
128	October 2006
79	September 2006
37	August 2006
90	July 2006
180	June 2006
75	May 2006
128	April 2006
170	March 2006
66	February 2006
67	January 2006
67	December 2005
163	November 2005
101	October 2005
242	September 2005
110	August 2005
21	July 2005
18	June 2005
28	May 2005
28	April 2005
54	March 2005
38	February 2005
26	January 2005
36	December 2004
82	November 2004
78	October 2004
29	September 2004
31	August 2004
28	July 2004
15	June 2004
5	May 2004
16	April 2004
109	March 2004
48	February 2004
22	January 2004
43	December 2003
49	November 2003
41	October 2003
14	September 2003
83	August 2003
152	July 2003
44	June 2003
93	May 2003
111	April 2003
133	March 2003
115	February 2003
44	January 2003
181	December 2002
61	November 2002
148	October 2002
77	September 2002
91	August 2002
92	July 2002
88	June 2002
209	May 2002
198	April 2002