Subject: [Tsvwg] Some other questions about the AddIP extension

From: [email-masked]
Date: Sat, 23 Feb 2002 20:42:51 +0200

Debugging my implementation I'm thinking about strange situations...

	What will happen if the peer tries to add an address that is being used by another association within this same endpoint (of course, both associations should be using the same destination port as well)? Silently discard the chunk (and maybe the whole datagram)?

	Thinking about my previous mail... There is a really weird case when the second ASCONF ACK might be different. When the peer (an attacker?) tells us to add an address that is being used by another association, but that association deletes that address before we receive the second ASCONF chunk... And there might be more situations (ok, REALLY strange ones... :-)). So this makes me think harder that either the last ASCONF ACK chunk should be compulsorily kept in memory (in fact, I think that this is what all of us are going to do), or it is stated in the draft that simply re-parsing the ASCONF chunk might not be the right thing to do... :-0

	What should we do if the peer deletes all the active addresses (i.e., after the deletion we only have inactive addresses)? Should we close the association? :-/ The ASCONF chunk must have come from one of the inactive addresses, so the card and the return path are working... Maybe we should try with the inactive addresses until we reach the Max.Association.Retrans... I guess this might be an implementation specific issue...

	Any comment? Thanks!

	BR Iván Arias Rodríguez

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Feb 2002 05:44:08 -0600

>         What will happen if the peer tries to add an address that is being used by another association within this same endpoint (of course, both associations should be using the same destination p…

So are you saying

Host 1                                         Host-2

IP-A                                          IP-Z
IP-B                                          IP-Y
IP-C                                          IP-X

(IP-A,     <--------------asoc 1-------------------> (IP-Z,IP-Z,
port:5555)
 IP-B,
 port:4444)

(IP-C:port4444)<--------------asoc 2------------------->(IP-X:port:5555)

Then assoc 2 attempts to do
         addip(IP-A)------------------------------>

> 
>         Thinking about my previous mail... There is a really weird case when the second ASCONF ACK might be different. When the peer (an attacker?) tells us to add an address that is being used by another association, but that association deletes that address before we receive the second ASCONF chunk... And there might be more situations (ok, REALLY strange ones... :-)).

So you are also saying that the attacker has guessed both the
sequence number and the V-Tag on the association?

> So this makes me think harder that either the last ASCONF ACK chunk should be compulsorily kept in memory (in fact, I think that this is what all of us are going to do), or it is stated in the draft that simply re-parsing the ASCONF chunk might not be the right thing to do... :-0

But that is an implementation decision Ivan.. You are REQUIRED TO ANSWER
the SAME.. How you do it is up to you but you MUST answer the same.

Please don't confuse requirements with implemention decisions..

It is like the SACK Gap-Acks.. I can think of NO easy way to
list the Gap-Acks to my peer out of order.. but we do NOT make
a requirement that they be in order since some future person
may come up with something brilliant that makes this happen.

There is NO reason to dictate implementation in the spec only
require what must be done..

>         What should we do if the peer deletes all the active addresses (i.e., after the deletion we only have inactive addresses)? Should we close the association? :-/ The ASCONF chunk must have co…

Well this is an issue no matter if you have add-ip or not.. what does
your implementation do if all the addresses go in-active?

Ours continues to attempt to both send and heartbeat on the
in-active addresses until Max.association.retrans is reached...

Add-ip should not influence this...

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