Just to clarify some of my earlier comments.
I do think this is a serious issue. That does not mean I believe that the
existing security mechanisms are entirely inadequate. It simply means that I
think we should try to understand whether this is the case or not.
SPF or something like it is going to go ahead, the demand is simply too
strong. There are basically two ways ahead here. The first is we wait till
we hit the wall and try to solve the problem then. The second is that we try
to anticipate.
I would prefer the second. However I am quite willing to give the first a
go. I don't think that the problem is going to be so severe it cannot be
fixed.
Proposals that involve replacement of existing plant are completely
ludicrous and should not be considered.
-----Original Message-----
From: Matthew Elvey [mailto:matthew(_at_)elvey(_dot_)com]
Sent: Tuesday, February 10, 2004 1:02 PM
To: Alan DeKok; John Levine; ASRG
Subject: [Asrg] LMAP BOF - risk of BGP attacks compromising LMAP is
significant; Intellectual Property
Just wanted to provide some more info on the seriousness of
IP hacking,
WRT LMAP.
<http://www.dnsbl.au.sorbs.net/Zombie-FAQ.html> (which is based on
<http://www.completewhois.com/hijacked/hijacked_qa.htm>) provides an
intro to the issue.
<http://www.completewhois.com/hijacked/index.htm>,
and other pages at that site make it clear that this is currently a
serious problem. In the same way that ISPs knowingly allow
spammers to
reside on their networks, they will increasingly knowingly allow IP
Hijackers to connect to their networks.
S-BGP is mentioned as an infeasible solution: "S-BGP can solve the
problem but will require upgrades to the core Internet
infrastructure as
it requires a lot more memory for routers ... [and more] CPU power or
specific hardware for cryptography. Because of these
necessary hardware
upgrade and serious investment in new hardware that would be
necessary,
S-BGP has not gone beyond theoretical work so far. "
SysAdmins would be wise to ensure that their upstream's IP space is
properly registered with their RIRs to a current email
address, and that
more than just email security is used to authorize updates,
and finally
to refuse to route through their network IP blocks that are known to
have been hijacked, and have their upstreams do so.
Because this security problem is likely to be ongoing, it should be
addressed in draft-irtf-asrg-lmap-discussion.
Do we have two competing versions of the latest, BTW?
<http://asrg.kavi.com/apps/group_public/download.php/31/draft-
irtf-asrg-lmap-discussion-00.txt>
,
<http://www.taugh.com/draft-irtf-asrg-lmap-discussion-01.txt
? The 00 is
newer than the 01> .
I agree with PHB:
> This is something the IAB should consider as a matter of urgency.
Anyway, here an attempt to address this.
I propose a section 2.4 that reads something like:
2.4 BGP based attacks
All versions of LMAP rely on the security of TCP to assure that a
message that appears to be sent from an IP address is actually from
equipment of the owner/renter of that IP address. But IPs can be and
are hijacked - hijackers announce BGP routes to the IP space
they wish
to steal, and much of the Internet starts routing packets for that IP
space to them [ref to
http://www.completewhois.com/hijacked/hijacked_qa.htm]. If
an IP in IP
space authorized by LMAP records is hijacked, the hijacker
can send spam
from that IP and LMAP will make it appear to be authorized until the
domain admin can react and update LMAP records or regain control over
the stolen IP space.
In the same way that Tier 1 ISPs knowingly allow spammers to
reside on
their networks, it it likely that they will increasingly
knowingly allow
IP Hijackers to connect to their networks. The fact that most
hijacked
IP space is unused somewhat mitigates the risk this poses, as
such IPs
are less likely to be authorized by LMAP records, as does the
fact that
such IP space is often quickly blacklisted [ref to
http://www.dnsbl.au.sorbs.net/Zombie-FAQ.html].
One more thing - what's with my name being removed from the credits?
Contributors need to be listed. I and others contributed and are in
<http://asrg.kavi.com/apps/group_public/download.php/18/draft-
irtf-asrg-lmap-discussion-00.txt>,
but not in the later versions; you can grab my contact info from
<http://www.ietf.org/internet-drafts/draft-elvey-refuse-sieve-00.txt> if
you want to add all that.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg