Subject: Re: [Tsvwg] Establishment of SCTP association

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Wed, 07 Jan 2004 08:21:25 -0600

[email-masked] 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

Now Host-A chooses (for whatever reason.. admin etc) a default
route of net-isp1. Host-Z chooses a default route of net-isp4..
Both sides bind all addresses.

Host-A sends an INIT to IP-3.

We choose the default route, and thus pick up the source address IP-1 
destination IP-3
and off goes the INIT

----------Src:IP-1---Dest:IP-3(INIT(IP-1,IP-2))----------------->

Host-Z processes the INIT, having a listner it responds to IP-1 out its
default route, choosing the best source address for net-isp4 (the default
route) which is IP-4. Note that if it did has you request the packet should
be ingress-filtered and dropped.

<------------------Src:IP-4---Dest:IP-1(INIT-ACK(IP-3,IP-4))----------

This is one of the scenarios that were discussed back when
SCTP was developed and the wording you asking to change was
discussed... The wording was put in for a VERY SPECIFIC purpose... this 
one :->

>
>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.
>

But no one has agreed with you.. just the opposite.. we have disagreed. Such
a choice of wording was discussed and rejected long ago when RFC2960 was
being written.

The example I gave is just one such that we could probably come up with. The
reason it comes to mind is I had a bug in one of the SCTP implementations I
am in charge of (not KAME) where an association could not be setup due
to this issue (the other impl was not handling looking in the INIT-ACK to
find the proper src address).. but anyway you must allow any valid
IP address in the src...

>
>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. 
>

No we discussed this... And you have to have all of your addresses know
and secured if you are going to do IPSEC between two machines and use
those addresses. If for some reason you don't want to have IPSEC
on some addresses and IPSEC on the others... you can always do
subset binding in the SCTP app to get the IPSEC'd addresses...

>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. 
>

We had talked about the adding of addresses (which is what you are 
basically describing above) in
the context of add-ip.. and what we concluded (if I remember right) was 
that you would renegotiate
the session starting all over again when an address was added...

>
>4. Besides the *possible* implementation issues, are there any other reasons why SCTP specs could not mandate that the source IP address of INIT-ACK must be the same than the destination IP address of INIT? After all, no functionality is lost in SCTP even if such a statement is added to the specs.
>

Other than the fact that you create situations where the routing setup 
of two
random peers will make it so they cannot communicate.

We decided long ago that this was not a good thing...

If IPSEC needs some addtional things to cover this case then it is a
more general problem that needs to be addressed... since any multi-homed
protocol will have this same issue.

R

>/Mikael

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

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 8 Jan 2004 14:07:33 +0100

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:

>> 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.
>>
I was talking about Linux, but not about lksctp. The are more 
implementations running on linux, the sctplib, for
example. This (and others) rely on the kernel to do the source address 
selection.
> discussed... The wording was put in for a VERY SPECIFIC purpose... 
> this one :->
>
>>
>> 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.
>
> the context of add-ip.. and what we concluded (if I remember right) 
> was that you would renegotiate
>> 4. Besides the *possible* implementation issues, are there any other 
>> reasons why SCTP specs could not mandate that the source IP address 
>> of INIT-ACK must be the same than the destination IP address of INIT? 
>> After all, no functionality is lost in SCTP even if such a statement 
>> is added to the specs.
>>
>

---

From: [email-masked]
Date: Wed, 7 Jan 2004 15:48:32 +0200

Michael & Randall,

Comments:

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. 

/Mikael

> -----Original Message-----
> From: ext Michael Tuexen [mailto:[email-masked]]
> Sent: Tuesday, January 06, 2004 2:13 AM
> To: Latvala Mikael (Nokia-NET/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Tsvwg] Establishment of SCTP association
> 
> 
> 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.
> > /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
> >>>