At Wed, 9 Apr 2008 11:22:33 -0700, Dan Wing wrote: > > (3) Even if we ignore the previous two considerations, > > all that the ability to ACK the ISN indicates is that > > the attacker is on-path. There are many situations > > in which an attacker is on-path (wireless being a > > commonly cited case). > > > > It's precisely for these reasons that one cannot use source IP > > authentication for TCP connections on the public Internet, that > > mechanisms such as .rhosts are deprecated, and that cryptographic > > mechanisms such as IPsec were designed. > > > > Incidentally, this third deficiency seems to me to be shared > > by draft-wing-sip-e164-rrc. Any attacker who is on path > > between the relying party and the target of the return > > routability check (either because they are on-path in > > the SIP routing fabric or because they are able to > > observe one of the links) will be able to pass the return > > routability check. > > That is correct. > > A signature generated by the originating domain (e.g., RFC4474) > would protect from such an on-path attacker -- unless of course > the on-path attacker is also generated the original message > and is also on-path for the return routability check. > > But, then, if the attacker is on-path for the return > routability check, they already 'own' that E.164. Ignoring > draft-wing-sip-e164-rrc for a minute, any normal INVITE > for that E.164 will go to that very same attacker.
Again, I'm not (at least not yet) passing judgment on this draft. Rather, I'm observing that your characterization of the situation with IP isn't really right. I'll have to read this draft more carefully to determine whether I think it works. -Ekr _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
