Subject: [Tsvwg] SCTP Add-IP thoughts

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 16 May 2001 07:31:37 -0500

Dear All:

I have been conversing with one of my fellow cisco-ite's and
an interesting point came up on the ADD request.

The context of the discussion is how we can use ADD-IP to
have SCTP associations survive a IPv6 renumbering. 

Now there is one little problem with this scenario..

What happens if I am a non-multi-homed host?

If my address changes out from under me I am done... For
a multi-homed host it is not an issue... And this brought
me to a couple of thoughts:

1) Steve Bellovin (at the last IETF) ran the numbers and
   helped us determine that if we use a GOOD random number
   source the Verification TAG and ADCONF ID numbers
   will provide us protection against a blind attack.

2) The problem is in the association lookup, which is normally
   done with source/destination from the IP header, and ports
   from the SCTP header.

And this all lead me to this question:

What would happen if we added a fixed parameter at the front
of the ADCONF that contained a source address that is PART
of the association?

This would normally be set to the same value as the source
address in the IP header.

But in the case of a non-multi-homed host, I could fill this
in with the IP address that I used to have. I could include
an ADD has the first TLV (of the source address of the ADCONF's
IP packet) and I could even bundle a DELETE of the old address
as the second TLV.

This would fix the problem and I don't think it would weaken
the security since these depend on the Verification Tag and
ASCONF-Request Correlation ID. 

I think this would make ADD-IP more general. The original ADD-IP
was thought of for the hot-pluggable NIC cards, but with IPv6 we
can also use it for re-numbering... 

Thoughts/comments etc...

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 16 May 2001 16:48:14 -0400 (EDT)

On Wed, 16 May 2001, Randall R. Stewart wrote:

> The context of the discussion is how we can use ADD-IP to have SCTP
> associations survive a IPv6 renumbering.
                         ^^^^^^^^^^^^^^^^
You mention this twice. Can you explain what you mean by this? My
assumption is just that the host switches IP addresses. Is this correct,
or there is something more?

> If my address changes out from under me I am done... For

I have also been thinking of the same scenario. I assume we are on the
same wavelength... mobility?

> IP packet) and I could even bundle a DELETE of the old address

Since security isn't weakend as you pointed out (and I agree), the only
issue I can think of is...

The draft's section 4.3.D1 says that until the new address cannot be used
as a source address for ANY SCTP packet until the ASCONF-ACK is received.
This would now have to be changed to allow ASCONF chunks as an exception.
I think this will be ok as long an additional restriction is added to
avoid ASCONF chunks bundled with other chunk types. However, I may not be
aware of other issues that motivated 4.3.D1.

-----------------------------------------------------------------------
Armando L. Caro Jr.                                  [email-masked]
University of Delaware                   http://www.cis.udel.edu/~acaro
-----------------------------------------------------------------------

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 16 May 2001 16:39:39 -0500

> > associations survive a IPv6 renumbering.

In IPv6 the provider can renumber your ULA any time.. So at
any point say my ISP does some change within there network, buy
service from AT&T vs sprint. Then they get a different upper level
aggregator (ULA). They then change their routers and start
advertising a new prefix...

> same wavelength... mobility?

No, I am not speaking of mobility.. this is NOT the intent.. we
are talking about renumbering by an ISP.

> aware of other issues that motivated 4.3.D1.

I was thinking we may need a prohibition from bundling in this case..
might not be a bad idea..

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 16 May 2001 17:57:35 -0500

"Randall R. Stewart" wrote:
> If my address changes out from under me I am done... 

Randy,

What if you still send out the ADCONF with the old address as the
source?

Say, Host A has been using addr X talking to B at addr Y... and then
suddenly A gets renumbered to addr X', what if A immediately sends out: 

ADCONF(src=X, dest=Y) 
 {
   action_1 = DEL X
   action_2 = ADD X'
 }

Will this work? This should be much easier to implement.

Another even worse scenario to consider is what if both sides get
renumbered at the same time? This can happen easily if the ULA gets
changed.

-Qiaobing

> For

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 16 May 2001 21:20:33 -0500

> What if you still send out the ADCONF with the old address as the

Two words may get in the way of this "ingress filtering". Not
sure... 

> Will this work? This should be much easier to implement.

It may not always work.. besides you have it WRONG
if you did action_1 = DEL action_2 =ADD you would be
attempting to delete your last address...

I think you mean you would do:

action_1 = ADD X'
action_2 = DEL X

And I fail to see that one is more easy to implement than the
other. There is already case code in handling control chunks
that must allow for a lookup of an association on other
than the source address.. INIT/INIT-ACK and even more so
often times you WON'T have an association..

In the reference implementation I could do my proposed change
in roughly 3 lines of code.. it is not hard... then the
rest would be as currently defined... It is only one additional
line in the lookup, one additional pass through to defer
the VT tag check and finally one addtional lookup..

It is quite simple.. it is not difficult.. Your method
may not be assured of working...

R

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 16 May 2001 23:05:32 -0400 (EDT)

> What if you still send out the ADCONF with the old address as the

This means the ADCONF-ACK would have to be sent to the new address, which
violates the restriction in 6.4 of the SCTP RFC:

"An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
etc.) to the same destination transport address from which it received the
DATA or control chunk to which it is replying."

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 17 May 2001 06:30:24 -0500

> DATA or control chunk to which it is replying."
Armando:

The restriction is a "if possible" restriction. In this case it
is NOT possible. I am well aware of the SHOULD send back to
the source... but there are cases where this is not feasible even
now in a standard RFC-2960 case...

For example:

I mark a Destionation has unreachable .. A packet comes in "from"
the unreachable address... (note: it may enter the system on
an alternate interface via an alternate routing path). Do I
reply with a SACK to the down destination? This is why the 
SHOULD is NOT a MUST... you must be allowed some flexibility
in this...

SHOULD means you really really ought to do this unless you
have a specific reason that you are not.

In the case that my address changed, I think this would
qualify and thus NOT violate the restriction..

R

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Thu, 17 May 2001 09:28:51 -0400 (EDT)

> SHOULD is NOT a MUST... you must be allowed some flexibility

Yes, this is true... but this "if possible" restriction still makes
Qiaobing's solution sub-optimal.

Suppose the following... The host which had its IP renumbered (from
address 'x' to address 'y') sends an ADCONF to its peer, but it puts its
old address (ie, 'x') as the source. The receiving peer at this point
may not have noticed that 'x' is unreachable and will reply with
the ADCONF-ACK to address 'x' initially. Eventually, however, the
ADCONF will be retransmitted. In this time, the peer most likely would
have realized that 'x' is unreachable, and will therefore reply with the
ADCONF-ACK to 'y'.

Also, since the host was renumbered from 'x' to 'y', it is possible that
some other host now has address 'x'. The chances of this may be small, but
as long as it is possible, there is a risk of an ABORT when the peer
initially transmits the ADCONF-ACK to 'x'.

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 17 May 2001 10:33:05 -0500

Armando:

This is actually a good point... 

I think if I hear no other objections.. next pass I
am going to put this in... with some rules
to deal with it..

i.e.:

1) You only lookup using the embedded id if you
   could not find the association.
2) You only reply to addresses that ARE a part of
   the association AFTER processing the ADCONF.
3) You should try to send back to the source, but this
   may not always be possible because of (2) above.

R

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 17 May 2001 11:13:40 -0500

Randy/Armando:

This solution would be fine with me. However you both haven't answered
my more fundamental question, what if both ends got renumbered at the
same time? In the example Randy gave (a changed Top/Upper Level
Aggregator), this scenario could become highly possible. Is there a more
complete solution to cover both single-end and double-end renumbering
cases? Or we just admit that the double-end renumbering case is
un-solvable?

regards,
-Qiaobing

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 17 May 2001 12:00:47 -0500

Qiaobing:

The double end renumbering case would work as well.. if the
packets could actually get to you... 

Assocation between A and Z..

They are both renumbered A' and Z'.

Now A (the new A') send a packet right away to Z

Src:A' ----->To:Z
[
Key:A
1)Add-A'
2)Del-A
3)Set-Primary A'
]

Z in turn (the new Z') sends a packet at the same time to
[
Key:Z
1)Add-Z'
2)DEL-Z
3)Set-Primary Z'
]

Now IF I receive the packet ... (pick either side)... I lookup
via the key (since I did not find the association with the
source address). I find it , make the modification and send
back the response to Z' or A', depending on who you picked
to examine..

The only IF here is "IF I receive the packet". This is far
beyond an SCTP issue. It becomes a routing issue... 

i.e.:

Will a router still recognize that to get to Z route the
packet to Z' ...

And I don't know the answer to this and I very much doubt
that you can come up with any solution in SCTP for the
problem if the router does not send the packets...

I also think that:

It is unlikely that the renumbers would happen at the
same instance. I think the provider will do it piece by
piece in his network... at least one would hope... Otherwise
if the router won't forward the packet.. it is no
different than cutting the cable.. you can't get a packet
across a broken wire...

R

Src:Z'------>To:A