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

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)

Michael Tuexen | 6 Jan 01:13 2004
Picon

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)

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

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)

Mark Allman | 7 Jan 15:13 2004

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)

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

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)

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

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)

Michael Tuexen | 8 Jan 14:07 2004
Picon

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)

Mikael.Latvala | 8 Jan 13:17 2004
Picon

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)

Mikael.Latvala | 7 Jan 14:48 2004
Picon

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)

Michael Tuexen | 8 Jan 14:34 2004
Picon

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)


Gmane