Subject: Re: Matching addresses in INIT and INIT ACK

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 07 Mar 2003 05:51:49 -0600

Ivan/All:

I think this illustrates a point where you must search
the address lists in the INIT/INIT-ACK to find
the match... (Ivan I hope you don't mind me
forwarding this to the list :>)

[email-masked] wrote:

>  
>
>
>	I hope I don't put my foot again in it this time... Let's see another scenario... This time both implementations are multihomed and doesn't dig into the INIT or INIT ACK to look for addresses:
>
>Host A/B                                                            Host C/D
>                                                                    
>TCB     \   INIT VT:0 IT:W                      INIT VT:0 IT:X   /  TCB
>A,B:1000 \  A:1000->C:1000                      D:1000->B:1000  /   C,D:1000
>C:1000    \                                                    /    B:1000
>VTloc:W    \                                                  /     VTloc:X
>VTpeer:0    \                                                /      VTpeer:0
>C-WAIT       \                                              /       C-WAIT
>              \--------------------\  /--------------------/
>                                    \/
>                                    /\
>                                   /  \
>   (1)  <-------------------------/    \------------------------->
>
>        \   INIT ACK VT:X IT:Y              INIT ACK VT:W IT:Z   /
>         \  B:1000->D:1000                      C:1000->A:1000  /
>          \ VTloc:Y VTpeer:X                  VTloc:Z VTpeer:W /
>           \TTloc:0 TTpeer:0                  TTloc:0 TTpeer:0/
>            \                                                /
>             \                                              /
>              \--------------------\  /--------------------/
>                                    \/
>                                    /\
>                                   /  \
>        <-------------------------/    \------------------------->
>
>TCB     \   COOKIE ECHO VT:Z                  COOKIE ECHO VT:Y   /  TCB
>A,B:1000 \  A:1000->C:1000                      D:1000->B:1000  /   C,D:1000
>C,D:1000  \ VTloc:Z VTpeer:W                  VTloc:Y VTpeer:X /    A,B:1000
>VTloc:W    \TTloc:0 TTpeer:0                  TTloc:0 TTpeer:0/     VTloc:X
>VTpeer:Z    \                                                /      VTpeer:Y
>C-ECHOED     \                                              /       C-ECHOED
>              \--------------------\  /--------------------/
>                                    \/
>                                    /\
>                                   /  \
>       X<-------------------------/    \------------------------->X
>
>
>
>  
>

In the above case, using just the Vtags would never find the old 
association.. and
even special case code would not find it (unless of course each side had 
complete
pre-knowledge of what were the peer's addresses.. but we are talking
general here and so this is NOT the case).

So here we have a case where the setup of an association would fail.

Note, I believe this is the case at the Bakeoff in RTP that actually 
generated
the wording...

And glancing at your code Brian, it does not work..

Those that check the INIT/INIT-ACK for addresses would find the
setting up associations and populate the Tie-Tags, reusing their
correct tags.. and presto the association would come up.

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: <[email-masked]>
Date: Mon, 10 Mar 2003 14:16:44 +0200

Brian,

> 
> Ivan,
> 
> On Sat, 08 Mar 2003, [email-masked] wrote:
> > 
> Host A/B                                                            Host C/D
>                                                                     
> Populating tie-tags with zero is correct? (IG 2.6)

	Yes, it is the correct thing to do.

> Sending the INIT-ACK to C or D is moot (because it is sent to D
> if the INIT arrived just before sending the INIT from A.)

	Well, the INIT could arrive after sending the COOKIE ECHO, in the ESTABLISHED state or while SHUTTING DOWN, and the actions to be taken would be different...

	But this is the case we are discussing, right now...

>            \TTloc:0 TTpeer:0                  TTloc:0 TTpeer:0/

	This is the part that is wrong... I'll explain below...

> The host just copies the INIT-ACK info and echoes the cookie.
> 
> What have I done wrong to this point?

	Ay, ay, ay, Brian... I won't blame you this time, but please, take more coffee ;-)

	When the INIT comes you don't recognize it as coming from the same endpoint you are trying to establish an association with, and so, you don't follow section 5.2.1 of the RFC...

	What you have done wrong is including a new IT in the INIT ACK, instead of using the same one you put inside your INIT... So, we should be in this situation:

TCB     \   COOKIE ECHO VT:X                  COOKIE ECHO VT:W   /  TCB
A,B:1000 \  A:1000->C:1000                      D:1000->B:1000  /   C,D:1000
C,D:1000  \ VTloc:X VTpeer:W                  VTloc:W VTpeer:X /    A,B:1000
VTloc:W    \TTloc:0 TTpeer:0                  TTloc:0 TTpeer:0/     VTloc:X
VTpeer:X    \                                                /      VTpeer:W
C-ECHOED     \                                              /       C-ECHOED
              \--------------------\  /--------------------/
                                    \/
                                    /\
                                   /  \
        <-------------------------/    \------------------------->

	And then, instead of dropping the COOKIE ECHO, you would accept it, and both host would open *a single association*... You would send the INIT ACK and stuff, and you would end up having one and only one association established between the two hosts... Of course, all this unless I made a mistake...

> (Note that I have not looked at the source address list in the INIT.)
> 
> --brian
> 

	Yes, I did notice... And that's the reason why you ended up with this situation: dropping COOKIE ECHOes and not establishing the association...

	BR Iván Arias Rodríguez

---

From: <[email-masked]>
Date: Mon, 10 Mar 2003 14:30:18 +0200

Brian, Randall,

> > What tie-tags? so far I see a INIT being sent above..
> 
> In the INIT-ACK being formulated at this point...
> 
> > <AAA>
> > 
> > >
> > What does your statement have to do with anything.. you
> > send a INIT to C (from A) and all of a sudden you get a
> > INIT from D... you have NO idea that C and D are the same
> > endpoint... so you MUST send back a INIT-ACK to D...
> 
> Huh?  Is the new text in section 2.6 for section 5.2.1 in error?
> It tells me that in COOKIE-WAIT state I must send the INIT-ACK back
> to the same address that the original INIT (sent by this endpoint)
> was sent to.

	Brian, what are you trying to do? Should we ever answer to you again? Or even read your messages? Because I'm getting too tired of you playing with us...

	You know perfectly Randall was speaking about YOUR implementation, the one that sends the INIT ACK back to D, and the one that creates a new IT, BECAUSE YOU DON'T RECOGNIZE THE PEER SINCE YOU DON'T TAKE A LOOK TO THE ADDRESS PARAMETERS.

	YOUR implementation is the one that goes against the IG... YOURS. Whose behavior is the one explained above...

	And since we are showing you why YOUR implementation is not working in this case, that's why we say that you have to send the INIT ACK back to D, with a new IT, because YOU are not able to find the TCB without knowing what's inside the address parameters...

	Clear now?

> Yet you tell me I MUST send it to D?  I'm glad you don't have a
> problem with me sending it to D (per RFC 2960) instead of to C
> (per IG 08 2.6).

	It is not a question of agreeing with you or not, it is just a matter of fact that:

> > INIT from D... you have NO idea that C and D are the same
> > endpoint... so you MUST send back a INIT-ACK to D...

	But that only happen with YOUR implementation...

	... snip...

> > He was illustrating what you are advocating, not looking in the INIT
> > and INIT-ACK.. if you do look in the INIT, then at <AAA> you will
> > have populated the tie-tags since you would have recognized the
> > associations as being related (you would have found C in the the
> > INIT's  list of addresses .. the one from D.. and then you would
> > have found the TCB that sent the INIT to C...)
> 
> But the tie-tags are not to be populated in COOKIE-WAIT 
> states (according
> to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or
> SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New 
> text for Section
> 5.2.2)

	This is right... Randall made a mistake here. However, the important thing is that with YOUR implementation you create a new IT, and send the INIT ACK back to D instead of C... That way you will establish an unique association as I shown in my previous mail... However, YOUR implementation is not able to do so in this case of INIT collision...

> Now you are telling me they should be populated?  If they are 
> populated
> and D is X (the attacker) then you will have surrendered the VT of the
> existing TCB to the attacker.

	See above...

> So are you saying that I have done the wrong thing by putting 
> zero in the
> tie-tags?  Then is RFC 2960 section 5.2.2 and IG 08 section 

	You know perfectly that YOUR implementation does a different thing (due to lack of information, since YOU don't look inside the address parameters), and at the end YOU are not able to establish the association...

> 2.6 new text
> for 5.2.2 in error?
> 
> I would seriously like to know what I've done wrong up to this point.

	Read my previous mail as well if I haven't been clear enough...

> Your statements of what I have done wrong are not consistent 
> with either
> the RFC or the IG....  Please take a closer look at it and 
> tell me where
> I have gone astray.

	I hope now it's easier to understand...

> > Yep and that is why your association will not come up when 
> it should..
> 
> But I have following the RFC and Section 2.6 to the letter (except for
> the C/D thing which doesn't change the result here.)

	You have not, Brian... You have created a new IT, and sent the INIT ACK back to D instead of C...

	BR Iván Arias Rodríguez

> --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: <[email-masked]>
Date: Tue, 11 Mar 2003 14:44:13 +0200

Brian,

> 
> Ivan.Arias-Rodriguez,
> 
> Please read my first line:
> 
> > > > > I don't know that I agree with 2.6 yet...
> 
> 2.6 tells me I MUST send INIT-ACK to the same place as the
> INIT was sent regardless of which addresses were known in
> advance.

	That's simply not true. It doesn't say anything about "regardless of which addresses were known in advance" and it fact yesterday I proposed (and Randall agreed) that instead of sending the INIT ACK to the same destination as the INIT, we could do it to any of the "known" addresses...

	However, you just like to argue... Seems like you don't really want to fix or improve anything... Otherwise you would have made constructive comments... proposals...

> My point was that by sending INIT-ACK to a known address
> our implementation was better than 2.6 on this point in that
> it provided reliable initialization.

	Your point doesn't have any value, since you are playing with marked cards. You say "my implementation is better because it does this better", but you don't say that to be able to do so you need extra information. Give that extra information to my implementation and let's see how it solves the problem as nicely as yours. But, don't give us that information (which is very likely to be impossible to retrieve) and let's see which one is better...

> So, yes, please change 2.6 to say "known" address rather
> than the same place as the INIT was sent.  And please define
> "known" address in the IG too.

	As I told you, yesterday we were proposing something like that... You are also most welcome to propose any text for this change...

> But I still have a problem considering the source address
> list when looking for the TCB on INIT as regards 2.6.
> 
> Consider the following case:
> 
> Host A
> 
> INIT A:1000 -> C:1000       INIT X:1000 -> A:1000 (C)
> ----------------------\    /------------------  Host X
>                        \  /                             
> INIT A:1000 -> X:1000   \/
> ----------------------\ /\
>                        X  \-------------------> Host C
>                       / \
>                      /   \
> <-------------------/     \-------------------> Host X
> (1)                   
> 
> 
> Assume that Host A has no "known" addresses for either of
> its TCBs.  At (1), where is the INIT-ACK sent?  There are
> two TCBs in the COOKIE-WAIT state that match the addresses.

	I quote from one of Randall's last mails answering to a mine one:

----------------------------------
>	And, I haven't thought about this, but, what would happen if the address list in the INIT contains addresses of *more than one* other association? This would clearly identify the INIT as coming from an attacker... :-/
>  
>
Yes, this is a good point.. one could use this type of information to 
determine an attacker
and I would expect log this somewhere a counter or something.... but one 
must
be careful about logging since this to can be an attack :-0
----------------------------------

	However this case is different, since you don't really have two associations... Actually it is only one. At the COOKIE WAIT state you don't normally know all the addresses of the peer (no matter what you say).

	I guess that in this case, since the INIT comes from X, you should answer back to X "from" the second TCB (the one that includes X). You would copy its IT and stuff... I don't feel like thinking what would happen at the end, but I suppose that once you have the COOKIE ECHO, you should join both associations into a single one...

	Do you propose anything different? What I have said is just what I think about right now...

> 
> INIT A:1000 -> C:1000        INIT D:1000 -> A:1000 (C)
> ----------------------\    /------------------  Host D
>                        \  /                             
> INIT A:1000 -> X:1000   \/
> ----------------------\ /\
>                        X  \-------------------> Host C
>                       / \
>                      /   \
>                     /     \-------------------> Host X
>                    /    INIT-ACK X:1000 -> A:1000 (C)
> <-----------------/---------------------------  Host X
>                  /
> <---------------/
> (2)
> 
> At (2), where is the INIT-ACK sent?  There is one TCB in
> the COOKIE-WAIT state that matches address C in the INIT,
> and one TCB in the COOKIE-ECHOED state that matches C in
> the INIT, neither match D.

	Let me see... Interesting cases you show...

	Here either D or X is an attacker... But let's see...

	Host X has shown that it owns address X, but not C... I don't know what I would do... Actually I think this was the same case you shown in your previous mails (the one about the malicious server), adding Host D to the game... If you join the associations, Host X might make you believe that he is also C when that might be false... but the idea that somebody to who you connect is an attacker... :-/

	What do you propose?

	I don't know... Upon receipt of the INIT ACK from X, what about sending the COOKIE ECHO back to C?... Host X could well have three addresses, so this doesn't solve much...

	But I don't see any completely right solution... I think that I would join both associations upon the arrival of the INIT ACK, and then, when the INIT comes, I would send the INIT ACK back to C... This is a mess, but the whole situation is very weird... :-/

> INIT A:1000 -> C:1000        INIT D:1000 -> A:1000 (C)
> ----------------------\    /------------------  Host D
>                        \  /
> INIT A:1000 -> X:1000   \/
> ----------------------\ /\
>                        X  \-------------------> Host C
>                       / \
>                      /   \
>                     /     \-------------------> Host X
>                    /    INIT-ACK X:1000 -> A:1000 (C)
> <-----------------/---------------------------  Host X
> COOKIE-ECHO      /
> ----------------/---------------------------->  Host X
>                /                    COOKIE-ACK
> <-------------/-------------------------------  Host X
>              /
> <-----------/
> (3)
> 
> At (3) there is one TCB in the COOKIE-WAIT state that
> matches address C in the INIT and on TCB in the COOKIE-ECHOED
> state that matches D in the INIT.  What is done about
> the INIT-ACK?  Is it discarded?  Is it sent to C?

	I think this is a little easier than the previous. I would join both associations, and when the INIT comes, I would send the INIT ACK back to C...

	All this makes me think that at the end, sending the ABORT, doesn't seem to be a very bad idea :-)

> Also consider n TCBs in various states, all that match
> the address various addresses in the INIT.  What is done
> with the INIT-ACK in these cases of multiple matches?

	What do you propose?

> Also there is a vulnerability in the COOKIE-ECHO state
> in a separate mail.

	Ok, let's see it...

> So, I don't know that I agree with 2.6.  That is why I
> do not yet follow it.  I believe that it places too heavy
> a reliance on a spoofable source address list in the INIT.

	Ok, what do you propose then?

> I am not convinced that ever considering the spoofable
> source address list in an INIT or INIT-ACK is wise from
> the standpoint of security.  Spoofing the source address
> list is the easiest way to dream up vulnerabilities in
> the INIT process.

	Same problems you have if you don't look at that address list. However, you have to wait till the reception of the COOKIE ECHO...

	In your implementation, taking your same example:

INIT A:1000 -> C:1000        INIT D:1000 -> A:1000 (C)
----------------------\    /------------------  Host D
                       \  /
INIT A:1000 -> X:1000   \/
----------------------\ /\
                       X  \-------------------> Host C
                      / \
                     /   \
                    /     \-------------------> Host X
                   /    INIT-ACK X:1000 -> A:1000 (C)
<-----------------/---------------------------  Host X
COOKIE-ECHO      /
----------------/---------------------------->  Host X
               /                    COOKIE-ACK
<-------------/-------------------------------  Host X
             /
<-----------/

	You can even forget about Host D. When the INIT ACK from Host X comes, what do you do? Address X has been verified, but what about address C...?

	Now I remember that you didn't answer to my mail where I think I found a probable attack based on this possibility that Host X doesn't own C... What do you do?

	It seems that you would simply copy the address list to the second TCB... When you receive the COOKIE ACK I suppose that you check all the other TCBs and find the first one, and join it with the second one... how proves you that Host X has address C?

	What do you do?

> A procedure which thinks that one TCB will exist for a
> given source address list address has not considered
> source address list spoofing, and is likely insecure.

	All this cases only happen when the "attacker" knows that you are sending an INIT to an specific destination... But in any case, what do you propose?

> See separate mail on COOKIE-ECHO state which exposes
> a new vunlerabilty for that state based on INIT-ACK
> source address list spoofing.

	Let's see...

	BR Iván Arias Rodríguez

---

From: <[email-masked]>
Date: Wed, 12 Mar 2003 16:45:23 +0200

> -----Original Message-----
> From: ext Randall Stewart (cisco) [mailto:[email-masked]]
> Sent: Wednesday, 12 March, 2003 15:55
> To: Arias-Rodriguez Ivan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Matching addresses in INIT and INIT ACK
> 
> 
> >	I have took a look to scenarios where choosing a new IT 
> when answering in the COOKIE ECHO state could be harmful... 
> And so far it looked ok...
> >
> >	If Steve says we should care about this, this might be 
> one way of avoiding this agressive server situation...
> >
> >	BR Iván Arias Rodríguez
> >
> >  
> >
> >  
> >
> Ok, I looked into my book ... the drawings in there are nice 
> to follow... :>
> and yes I see no problem as yet.. but lets consider this a 
> minute (and I am
> feeling like drawing this am so here is the scenario
> 
> A                                                             
>           
>      X /C?                                               D/C?
> =================================================================
> IT=Q
> 
> -----A->0:INIT(A,IT=Q)->X--------------------------------------->
> Cookie-Wait state
> <-----------------------A:INIT-ACK(X,C,IT=Y)<X-------------------
> Cookie-echoed state
> peer=X/C
> ------------------A->Y:COOKIE()->X------------------------------>
> 
> <----------------------------<A--0:INIT(C,D,IT=P)<-D-------------
> <1> scenario 1
> <Choose-New-Tag>
> ------------------A->P:INIT-ACK(A,IT=Q')->D->------------------->
> 
> <2> scenario 2
> -----------------------A->-ABORT(??error cause??)--D->---------->
> 
> Now currently, I think we would do <2> .. Ias you validly 
> pointed out.. 
> we just need
> to expand it to include established :>) send an abort.. 
> possibly with an 
> Error Cause.. which
> we may want to get rid of or at least have  "a MAY insert 
> error cause" 
> instead of the SHOULD
> thats there...  and also note that this may give away 
> information to an 
> attacker.
> 
> Now lets say we choose <1>, since we have a different set of 
> addresses 
> we can't really
> include tie-tags, otherwise we may be revealing the Tag of 
> our forming 
> assoc with X (which
> is the same reason in the restart case you can't send if the 
> address set 
> is not the same).
> 
> So the only way to handle it is to update the TCB with the 
> new choosen 
> tag (Q').. but
> this means that you have choosen X as the bad guy... and that 

	Yes... If C continues with the establishment phase, at the end we will get a COOKIE ECHO with new VT but matching Tie Tags, so we do (A) and restart the association...

> association is
> defunct... so when X sends
> 
> <--------------<-A-Q:COOKIE-ACK()--<-X---------
> 
> It will be rejected since the tag does not match and silently 
> discarded. 

	In fact, it is an OOTB packet, but as per 8.4 7), you silently discard it...

> Now X will
> eventually send a packet and retransmit until its association dies.
> 
> More so, there is a fundamental question here... whom do you trust?
> 
> The guy you contacted and want to talk to <OR> some guy that sends
> you a INIT...

	I think that trusting the guy you contacted is the wiser...

> It could be that D does not have C but instead X has C. By 
> doing anything
> like this it just introduces a much easier attack... I can get you to
> change the tag of a forming association by simply sending in
> an INIT... and thus get you to talk to me instead of the real peer
> you wish to talk to..  very bad...

	This is basically the main reason the whole section 2.6 was written (but initially applied to the ESTABLISHED state, not the COOKIE ECHOED).

	I think that if you send the INIT ACK back to any shared address, instead of sending it to the source address of the INIT, you could avoid this... INIT ACK would go to the real owner of C in this case, no matter if it is host X/C of host D/C... If X/C is the impostor, then at the end D/C will get the control. If D/C is the attacker, then the INIT ACK sent to C will simply be discarded...

	I think this even works when the incoming INIT shares addresses with more than one association. You simply send the INIT ACK to ANY of the shared ones... If the INIT sender is not telling you the truth, this INIT ACK will go to another host with whom you have an association and will simply discard it (even if that other host were cheating you and that address is not his address, the INIT ACK will go nowhere, and it will be discarded (NOTE*)).

	If the INIT sender really owns that address, the INIT ACK will go to him, and he will take control over the association that before "owned" the address to which you sent the INIT ACK. That association was fake, so no problem about tearing it down when the new association comes up. But there is a problem, what about the other N associations that also shared addresses with this new one?

	You could think about sending HB to those addresses before establishing the new association, so you could verify them, but this could be a way of attacking you, since with a couple of packets sent it makes you send many HBs... HOWEVER, as soon as you receive any HB ACK back (take into account that you expect those HB to carry the peer's VT in the TCB for those older associations), you can assume that the new guy was in fact an attacker and simply tried to get more addresses than the ones he has... just one is enough to put a big red cross to the address that tried to cheat you (which you verified)...

	All this makes me think about another issue... You don't even need to verify all those addresses (or at least, one by one, since as soon as you receive a single valid HB ACK the game is over for the attacker and the verification process)... If you are smart enough to have a Boolean variable 'Address_Verified' for every peer address in your TCBs, this is not always necessary. This variable could be initially set to false for all the addresses (except the one to which you sent the INIT ACK), and be set to true when a HB (or DATA) chunk sent to that destination is acknowledged... When you are in this case about the attacker, if any of those addresses has the 'Address_Verified' set to true, you know the INIT sender is lying... otherwise, send a HB...

	Of course, when the address list only conflicts with a single association, this procedure is not needed...

	Just thinking... :-/

	BR Iván Arias Rodríguez

	*NOTE: I think that I already pointed this out some long time ago (at least I have a note in my printed version of the RFC about this). OOTB packets that contain an INIT ACK should be silently discarded (same as COOKIE ACK), right? Section 8.4. of the RFC doesn't say anything about the INIT ACK case (but it does about the COOKIE ECHO case)...

> And thinking about not looking at the addresses (as is currently
> done in openss7's stack) you have a very bad situation. The RFC
> requires you to silently discard packets with the wrong vtag.. and
> NOT respond with an ABORT(). Without checking addresses this
> is not possible..
> 
> You hash to V-Tag/local-port... and you will always return NULL
> since you would not find an association that has the wrong V-Tag
> ... you get a null in this case when you lookup the association.
> Which means you send an ABORT() back to the guy..
> 
> So If I wish to attack such a stack what I do is start sending HB's (a
> rather innocent thing that could be from a previous assoc)....
> 
> Attacker:                                                     
>           
>                       Endpoint-A
> Src-Does_not_matter:V-Tag-guess-1:HB---------------------------->
>                                                               
>           
>            Lookup-Vtag() fails (we don't chk the
>                                                               
>           
>                                               address, and 
> vtag is not 
> matched).
>                                     
>  <---------------ABORT(No-TCB)-----------------
> Eventually you get
> Src-Does_not_matter:Luckey-guess:HB---------------------------
> --------->
>                                                               
>           
>                             Lookup-Vtag() find assoc
>                                       
> <----------------HB-ACK---------------------------
> Got Vtag.
> 
> Now if Endpoint-A responds only to known addresses aka sends 
> the HB back to
> its peers real address... no big deal.. do this enough and 
> you now have 
> an assurance
> that you have guessed a V-tag that someone is using..
> 
> Now the attacker can inject any data it wants into the 
> associations tag that
> was guessed.. :-0
> 
> If you are looking up with address validation you get
> 
> Attacker:
> Src-Does_matter:V-Tag-guess-1:HB--------------------------->
>                                                               
>           
>                       No matter what the V-Tag is no src known so
>                         
>  <-----------ABORT(No-TCB)------------------------------------
> 
> 
> Here is the primary reason src addresses must be validated.. 
> otherwise 
> it not only weakens
> security of the V-tag it makes it so that anyone can figure 
> out a V-Tag 
> of an assocaition...
> its easy :-0
> 
> 
> 
> 
> R
> 
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.