Subject: RE: [Tsvwg] Establishment of SCTP association

From: [email-masked]
Date: Mon, 29 Dec 2003 10:50:31 +0200

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. 

Therefore I am requesting that SCTP implementor's guide and/or SCTP dynamic address recofiguration documents discuss about this problem and explicitly forbid any SCTP implementation from using IP address in INIT-ACK that is different from INIT's destination IP address.

/Mikael

> -----Original Message-----
> From: ext Michael Tuexen [mailto:[email-masked]]
> Sent: Saturday, December 20, 2003 2:03 PM
> To: Latvala Mikael (NET/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Tsvwg] Establishment of SCTP association
> 
> 
> Mikael,
> 
> a true man-in-middle can do everything: insert ABORTs when he 
> wants and 
> so on.
> And not allowing that the other IP address is used as a 
> source address 
> does not
> hel you. The true man in the middle can intercept the packet 
> and return 
> the
> INIT-ACK with B's address as a source address. In general: a true 
> man-in-the-middle
> can do everything and there is not much a transport layer can do. You 
> must
> have some mechanism to identify your peer not based on the IP 
> address. 
> Possibilities
> include IPSec or TLS.
> 
> Best regards
> Michael
> 
> 
> On 17. Dec 2003, at 16:33 Uhr, [email-masked] wrote:
> 
> > Hello,
> >
> > We noticed an interesting behaviour in Linux SCTP implementation.
> >
> > 1. Endpoint A sends an INIT chunk to endpoint B using IPa 
> as a source 
> > IP address and IPb as a destination IP address
> >
> > 2. Endpoint B returns INIT ACK to endpoint A using IPc as a 
> source IP 
> > address and IPa as a destination IP address. IPb is 
> included in INIT 
> > ACK as an address parameter.
> >
> > 3. A and B finish the association negotiation, endpoint A 
> using IPb as 
> > its primary IP address and endpoint B using IPc as a source address 
> > when it sends data chunks to endpoint A.
> >
> > My question is: although RFRC2960 does not explicitly deny 
> the use of 
> > IPc as a source IP address in INIT ACK, when implementation 
> does so, 
> > doesn't this present a security hole in the association setup 
> > procedure? Therefore such behaviour should not be allowed.
> >
> > For example, in a man-in-the-middle attack hostile node 
> could highjack 
> > the association by responding to INIT, which endpoint A 
> sent, faster 
> > than endpoint B, using hostile node's own IP address IPz as 
> a source 
> > IP address. Obviously this attack assumes that the endpoint 
> A selects 
> > the source IP address IPz as its primary IP address.
> >
> > /Mikael
> >
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> >
> 
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Jan 2004 16:07:36 -0700

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

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 6 Jan 2004 01:13:10 +0100

Mikael,

see my comments below.

Best regards
Michael

On 29. Dec 2003, at 9:50 Uhr, [email-masked] 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
all addresses before the association is set up.
The problem in requiring the source address of the INIT-ACk is the same 
as the destination address of the INIT is not
so simple to fulfill. If the SCTP stack does not control the source 
address by itself but relies on the kernel to do
that based on the routing table then you can not guarantee that. If 
have seen several implementations working like this.
> 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.
>
> Therefore I am requesting that SCTP implementor's guide and/or SCTP 
> dynamic address recofiguration documents discuss about this problem 
> and explicitly forbid any SCTP implementation from using IP address in 
> INIT-ACK that is different from INIT's destination IP address.
>
Are you talking about plain SCTP (RFC 2960) or the ADDIP ID. The AddIP 
ID will be updated with additional security
mechanisms.

---

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Tue, 06 Jan 2004 08:47:57 -0600

Mikael/Michael:

My comments below..

Michael Tuexen wrote:

>> 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.
>>
> The problem in requiring the source address of the INIT-ACk is the 
> same as the destination address of the INIT is not

Besides this, the whole point of the IPSEC-SCTP RFC (don't know if it is 
out yet) is to
setup the SP's on each side of an IPSEC exchange of all the addresses. 
This is a
pre-requesite.. if you want to do multi-homed SCTP over an IPSEC exchange
then you must build into the spid all of the address on each side...

I don't think any of the IPSEC implementations have yet caught up
to this.. but it is needed... it is not a problem with SCTP but
a fundamental problem that needs to be fixed in IPSEC.

R

>> and explicitly forbid any SCTP implementation from using IP address 
>> in INIT-ACK that is different from INIT's destination IP address.
>>

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