Subject: ipv6 link local addresses and sctp bindx

From: Sridhar Samudrala <[email-masked]>
Date: Fri, 03 Jun 2005 15:08:08 -0700

Is it valid to allow bindx with multiple ipv6 link local addresses 
belonging to different links?
In linux TCP, when using a link local address, the socket is bound to a 
particular interface
as if we are using SO_BINDTODEVICE. But we cannot do the same with SCTP 
if we allow
binds with multiple link local addresses.
I would like to know how other sctp implementations have addressed this 
issue.

Thanks
Sridhar

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 4 Jun 2005 10:48:32 +0200

Hi Sridhar,

I would be interested in Kacheongs position, because Solaris uses per  
default
the same MAC address on multiple interfaces. So they would also use the
same auto-generated link local address?

Best regards
Michael

On Jun 4, 2005, at 12:08 AM, Sridhar Samudrala wrote:

> In linux TCP, when using a link local address, the socket is bound  
> to a particular interface
> as if we are using SO_BINDTODEVICE. But we cannot do the same with  
> SCTP if we allow
> I would like to know how other sctp implementations have addressed  
> this issue.
>
> Thanks
> Sridhar
>

---

From: Randall Stewart <[email-masked]>
Date: Mon, 06 Jun 2005 07:49:12 -0400

Michael:

It may be easier for Kacheong... because of that..

In thinking on this.. here are some thoughts I have:

a) The link local can ONLY be used if you source a
    packet from that address and send it to your peer
    on the same link (it does not matter global or LL).
    This is because you CANNOT list a LL in the
    list of addresses.

b) Since I can't list any binding multiple to an endpoint
    WILL work.. but only one of the multiple bound will
    be used.. unless of course one sends out with only
    ONE address.. and uses ADD-IP to add subsequent LL's by
    sending the ADD-IP sourced from the new link local.

c) The ADD-IP may be the only solution to get multiple LL's in
    an association... at least that comes to me this morning :-D

I am not sure how all these thoughts releate to Sridhar's question..
but it seems to me that you can still list all your other addresses
so even though the LL ties you to one of your interfaces.. you
can still use the others (assuming your routing allows it) using
the other listed addresses (which are NOT LL).

R

Michael Tuexen wrote:
>> In linux TCP, when using a link local address, the socket is bound  to 
>> a particular interface

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 06 Jun 2005 23:46:12 +0800

> I would like to know how other sctp implementations have addressed this 

In Solaris, the bindx() with the additional link local addresses
will succeed.  But only the link local address belonging to the
interface used to connect to the destination link local address
is told to the peer.  So in some sense, the extra bindx() really
does nothing...

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 06 Jun 2005 23:55:26 +0800

> same auto-generated link local address?

Actually, the above has nothing to do with Solaris.  It is a
feature of the old Sun SPARC boxes.  And this feature can be
turned off by using OBP or eeprom command to change the parameter
local-mac-address? to true.  I believe newer Sun SPARC boxes do
not have this feature turned on by default.  All interfaces have
its own MAC address by default.

Assuming the above feature is on, then there is no extra link
local address to add (-:

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 07 Jun 2005 00:01:59 +0800

>    sending the ADD-IP sourced from the new link local.

This is tough.  If the stack A sends this ADD-IP request to the
peer, should the peer accept it?  How can the peer know which
link to use to send to the new link local address?  It can
only assume the same interface is used (the peer assumes that
A has more than one interface on the link).

>    an association... at least that comes to me this morning :-D

Will it work?  If it is not working now, should we make it work?
It seems to be a corner case...  It may not worth the effort to
make it work...

-- 

						K. Poon.
						[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Mon, 06 Jun 2005 14:10:11 -0400

> A has more than one interface on the link).

The idea is you would need to source it from the link
being added.. and then put an additional address in
the "lookup address". This is similar to what Michael
as discussed in how we can do multi-homing via a NAT..

I think it will work.. but it is a bit tricky :-D

> It seems to be a corner case...  It may not worth the effort to

I think we can make it work as a corner case for when
we do NAT and define how to do M-Homing via a NAT.. for
now I think the LL guys can be singly homed.. and get
a global on there interfaces if they need M-Homing..

R

---

From: Sridhar Samudrala <[email-masked]>
Date: Mon, 06 Jun 2005 11:17:21 -0700

> is told to the peer.  So in some sense, the extra bindx() really

But suppose the user wants to use sctp_connectx() with multiple
destination link local addresses instead of a simple connect(), shouldn't we
include all the link local addresses belonging to the interfaces 
corresponding
to the destination link local addresses in the INIT.

Thanks
Sridhar

---

From: Randall Stewart <[email-masked]>
Date: Mon, 06 Jun 2005 16:46:59 -0400

> to the destination link local addresses in the INIT.

In order to use a LL address one needs to know
what interface is associated with it. So for example
in BSD land I get an interface id in the socket structure
either from the user .. or in the old embedded form that
KAME used to use.

On a received message the only thing you can have is
the index from the recevied message. This cannot be
gotten from something listed within the address list since
the peer has NO way to know what index your kernel as assigned
to say em0 or em1 or em2..

For example on one of my servers I have:
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         options=3<rxcsum,txcsum>
         inet 192.168.1.1 netmask 0xffffff00 broadcast 192.164.1.255
         inet6 fe80::2c0:9fff:fe1f:779f%em0 prefixlen 64 scopeid 0x1
         ether 00:c0:9f:1f:77:9f
         media: Ethernet autoselect (100baseTX <full-duplex>)
         status: active
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet 10.1.1.4 netmask 0xffffff00 broadcast 10.1.1.255
         inet6 fe80::204:5aff:fe7c:7c42%dc0 prefixlen 64 scopeid 0x2
         ether 00:04:5a:7c:7c:42
         media: Ethernet autoselect (100baseTX <full-duplex>)
         status: active
dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet 10.1.2.4 netmask 0xffffff00 broadcast 10.1.2.255
         inet6 fe80::204:5aff:fe7c:7c67%dc1 prefixlen 64 scopeid 0x3
         ether 00:04:5a:7c:7c:67
         media: Ethernet autoselect (100baseTX <full-duplex>)
         status: active

I have editted out the global address...

Now notice the scopeid 1/2/3

This is assigned by the kernel and in order to send to some
destination on dc1 I need to include the scopeid 3.

When I receive a packet the kernel informs me that it came
on the interface (I think if I remember right it actually
embeds it)... but anyway.. if I list to you

fe80::2c0:9fff:fe1f:779f
fe80::204:5aff:fe7c:7c42
and
fe80::204:5aff:fe7c:7c67

and you receive the packet from
fe80::204:5aff:fe7c:7c67
with scope X

How will you know what scopes go with anything but
the source address... since the peer could not konw what
your kernel assigned as its internal scope id...

This is why you can only include a LL address by
reference.. aka as a source address.. never listed.

I believe we have setup KAME-SCTP to ignore the LL
address that are listed with only one exception.. if
the address of the sender and receiver is the same (aka
its really a loopback packet).. then we can use
all addresses :-0

R

---

From: Sridhar Samudrala <[email-masked]>
Date: Mon, 06 Jun 2005 15:28:33 -0700

Randy,

Thanks for the detailed response.
Now i understand the issue with passing multiple link local addresses 
with INIT.
Even if we pass the addresses to the peer, the peer will not be able to 
use them
as it cannot get the scope id for the link local addresses in the 
embedded list.

Thanks
Sridhar

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 06 Jun 2005 21:04:59 -0400

Randy

> your kernel assigned as its internal scope id...

Assuming you have a well behaved peer you could assign the same
scope to all addresses.  In this case you could assume that the peer is
telling you that it has multiple interface on the same link. Remember,
link != interface.  It just so happens that most implementation make
that assumption.

> reference.. aka as a source address.. never listed.

I guess this really depends on the implementation.  If you do
not equate link and interface, and have multiple interfaces on
the same link, you should be able to pass LL addresses as parameters
in INIT.

-vlad

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 07 Jun 2005 12:22:16 +0800

> as discussed in how we can do multi-homing via a NAT..

I don't quite get it.  Suppose A has two links X and Y with LL
addresses x and y respectively.  And B also has two links M and N
with LL addresses m and n respectively.  X and M are on the same
link, so are Y and N.  A starts an association from x to m.  Are
you suggesting that A can send the ADD-IP from y to n?  But how
does A know about n in the first place?  Either this is done
manually or there is another protocol for A to discover all the
LL addresses of B and on which link.  Both are outside SCTP...

> a global on there interfaces if they need M-Homing..

I don't know the NAT proposal...  But as you said, SCTP using link
local address only works in the singly homed case for now.

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 07 Jun 2005 12:32:06 +0800

> to the destination link local addresses in the INIT.

I guess the comment above does not require sctp_connectx().  For
a simple connect() to a remote link local address, should SCTP
include all the link local addresses belonging to the same link
to the peer in the INIT?  If the peer can assume that all
the addresses belong to the same link, I guess this is OK.

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 07 Jun 2005 16:39:49 +0800

> link != interface.  It just so happens that most implementation make

Yes, I guess if the endpoint receiving the multiple LL addresses
can make the assumption that all the LL addresses belong to the
same link, it can work.  Then the endpoint will do the reachability
test and verify if those LL addresses are valid.

> the same link, you should be able to pass LL addresses as parameters

I guess it is not really about implementation "equating link and
interface."  It is whether an implementation can make the
aforementioned assumption.  The assumption seems OK.  If anyone
sees a problem, say security, please comment.

-- 

						K. Poon.
						[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Tue, 07 Jun 2005 08:22:26 -0400

Sridhar:

Exactly!

Its one of those little details that is NOT obvious and
requires a lot of contemplating... its also rather
ugly..

La Monte and I had a long discussion about the multi-homed
dentist's office that he wanted to "just work"... unfortunately
I could not think of a way for this to work .. but it
did lead me through this little thought experiment before :-0

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 07 Jun 2005 08:27:32 -0400

Vlad:

You may be right .. if you configure things.. but you can NOT
expect the "multi-homed dentist" to come in plug in his
machines and make it all work...

The idea behind anything like this is it must be generic to
all implementations... without configuration... sure I can
force KAME-BSD to setup site scopes in certian ways.. but
thats not what we are going for here.. you can control
things like this on the end-2-end internet.. private
networks yes... private networks with no administartor
.. unlikely :-0

R

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 07 Jun 2005 08:53:53 -0400

Randy

> machines and make it all work...

I don't know many dentist that would need multiple interfaces
connected to the same link. ;)

But seriously, why not?  Just because IPv6 punted so far on
multi-interface hosts, doesn't mean it can't work.

> ... unlikely :-0

Well, this really more IPv6 specific and not in the SCTP purview.
All SCTP can do is provide link-local addresses that belong to
the link that is used to set-up the association.  It just so happens
that in most implementations, this is limited to the interface, but
that's the implementations choice.

As for ADD-IP, it may work, but it would require addresses with a
greater scope then link-local as well.  With only link-locals, there
really is no way to do this without some outside protocol as Kacheong
mentioned.

Thanks
-vlad

---

From: Randall Stewart <[email-masked]>
Date: Tue, 07 Jun 2005 09:21:37 -0400

> really is no way to do this without some outside protocol as Kacheong

Assuming that I am told a list of LL addresses and there
interfaces by the sctp_connectx() call.. I think I can make this
work..

I do

LLS1----INIT()----LL1----> (to address is LL1 and from is the
                            proper address [LLS1] for this link out)

... rest of handshake...

LLS2----ADD-IP(lookup-addr LLS1)----->LL2

Now the add IP would  need to lookup the assoc by LLS1 or
we are actually discussing adding a new address type for
NAT purposes .. i.e. have a address type == myvtag... that
way between the two vtags one could lookup and validate
that its the same assoc.. espeically when we add in the
AUTH draft... which means the shared/and-or/generated key (per the
auth draft) would be used to authenticate the ADD-IP..

Basically it will work the same way it would work for a NAT..

The key of course is the sender must provide the LL addresses
with the proper scope to the connectx..

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 07 Jun 2005 09:25:45 -0400

Kacheong Poon wrote:
> you suggesting that A can send the ADD-IP from y to n? 

Yes.... this is the way ADD-IP is written.. and by the
way its how we intend to get multi-homed multi-pointed NATs
to function.. or course we need to get NAT's to understand
SCTP first :-D

  But how
> does A know about n in the first place?  
sctp_connectx(...

    sin6_addr = m (scope x)
    sin6_addr = n (scope y)
    )

shoudl just about do it in my mind...

Either this is done
> LL addresses of B and on which link.  Both are outside SCTP...

Yes .. this is a manual thing.. but the interface is there
via sctp_connectx to do it...
> local address only works in the singly homed case for now.

Yep... singly homed is the only way that at least the BSD
stack will work.. any LL's that are listed are silently
discarded by KAME-BSD :-D

R

---

From: Sridhar Samudrala <[email-masked]>
Date: Tue, 07 Jun 2005 09:55:54 -0700

Vlad,

Actually i was referring to link local addresses assigned to multiple 
interfaces on different links.

I came across the following interesting thread on tsvwg that discussed 
the same issue where
Qiaobing seems to have made the multi-homed dentist analogy.
       http://www1.ietf.org/mail-archive/web/tsvwg/current/msg00433.html

Thanks
Sridhar

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 07 Jun 2005 14:37:35 -0400

Sridhar

Ok, thanks for the context.

So, for lksctp, I would say allow bindx to multiple link-locals.
The external behavior would be not much different from a wildcard bind
as far as link-locals go.

To get the multihoming, the peer would need to issue connectx()
like Randy described.

Just my $0.02

-vlad

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 08 Jun 2005 17:13:28 +0800

> auth draft) would be used to authenticate the ADD-IP..

Has any security analysis been done one this?  Without
knowing the actual spec, it seems that it is quite
easy for an attacker to arbitrarily generate random
packets and the SCTP stack needs to do much more checking
to verify and reject those packets than now.

In the above packet, both the source and destination addresses
are not in any association.  So SCTP needs to parse the packet
(and all out of the blue packets if it supports the above
mechanism) to find the "lookup-addr" field and then to lookup the
association again.  And it seems that both LL1 and LLS1
addresses need to be present.  With only a vtag (since not
unique) and one address, it is not enough to differentiate two
associations to two different remote endpoints.

What we have been discussing is the case with multiple
interfaces on the same link.  It does not really need ADD-IP
if it is required that all the link local addresses listed
in the INIT must belong to the same link.  I think this can be
useful for a simple setup to tolerate NIC failure.

-- 

						K. Poon.
						[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Wed, 08 Jun 2005 08:48:43 -0400

> to verify and reject those packets than now.
Please look at the auth draft of Michaels.. in fact
the current ADD-IP document requires it with a MUST
implement and use...

> are not in any association. 

Actually, thinking on this your right.. and I am not
sure it would work then... so maybe this will NOT
work for LL... you can see the general idea we want
to use for NAT though...

  So SCTP needs to parse the packet
> associations to two different remote endpoints.
The auth draft requires a H-MAC SHA-1 signature with a
shared secret... but I think the LLS2 is the real
problem with using this for link locals...

> useful for a simple setup to tolerate NIC failure.

Yep.. but KAME-BSD does not support this.. since I don't
see it has a general solution... and besides.. you still
end up with a single point of failure... aka the one switch.
I suppose you could have more than one.. but one network
is still one network... not two :-0

R