Subject: Re: IPv6 ingress filtering early access

From: Francis Dupont <[email-masked]>
Date: Fri, 04 Jan 2002 16:37:39 +0100

In your previous mail you wrote:

   However, I'm concerned about the "applied allover"
   part. Specifically - while I'm very much fond of the AAA solutions -
   I'm concerned whether we can expect all parts of the Internet to have
   an infrastructure that really can figure out the home addresses. What
   if there's a coin-operated (or Visa-) airport WLAN?

=> this is a problem of trust in the local/visited domain *and* in the
remote/home domain. In your example if I understand the issue is the lack
of trust in the local/visited domain, so one may reject traffic with
home address options from it.

   Finally, I seem to remember there was a discussion a long time ago whether
   we could somehow provide automatic, mandatory, ingress filtering in IPv6.

=> my concern is that the "mandatory" term in a RFC is not enough to
enforce it in the real world.

   Currently, we are headed towards the same situation as in IPv4
   where ingress filtering is only partially applied, and we keep coming
   up with "patch" solutions such as I-trace to help the situation.

=> ingress filtering has more problems with IPv4, mainly because it was
not considered from the beginning. But it is already a BCP and it seems
that most ISPs use it (feedback from ISPs please).

   Interestingly, these solutions typically need changes to a large
   fraction of the routers in the Internet which we already are doing
   anyway to move to IPv6...
   
=> we can expect to avoid the same errors with IPv6. Unfortunately
ingress filtering (like network management) is something where IPv6
is not yet at the same level than for IPv4 today. We hope this situation
will be improved very fast.

Regards

[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 4 Jan 2002 17:57:13 +0200 (EET)

> that most ISPs use it (feedback from ISPs please).

Feedback you get here does *not* reflect to the real world -- those who 
work around here, are usually even a little conscientious.  The problem is 
the ignorant and the uncaring.

FWIW, we provide connectivity for every university and the like in 
Finland, and they're all ingress-filtered at ISP-organization border.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: stanislav shalunov <[email-masked]>
Date: 04 Jan 2002 11:04:01 -0500

Francis Dupont <[email-masked]> writes:

> => ingress filtering has more problems with IPv4, mainly because it
> was not considered from the beginning. But it is already a BCP and
> it seems that most ISPs use it (feedback from ISPs please).

With IPv4, Abilene (and most large R&E networks I am familiar with),
don't do ingress filtering because of problems with multihoming.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

A fool's brain digests philosophy into folly, science into superstition,
and art into pedantry.  Hence University education.       -- G. B. Shaw
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Jan 2002 09:15:55 -0800 (PST)

I sure hope that nobody's making the assumption
that you need to be a mobile node to send BU's
and/or HAO's. My provider doesn't care diddly
squat about any of this, nor is it likely that if
I tunnel to the 6bone they're going to care much
either. If this is your only line of defense of
protecting CN's from senders of malicious HAO's,
I'm pretty skeptical. RPF checks "work" mainly
because they are so painless for ISP's to
implement. Anything beyond that is likely to
be a complete non-starter.

     Mike

---

From: Francis Dupont <[email-masked]>
Date: Sun, 06 Jan 2002 15:28:15 +0100

and/or HAO's.

=> by definition if a node which sends BUs is a mobile node.
But I agree that HAOs are useful for nodes which are not mobile nodes,
so the BCE check is not a good solution.

   My provider doesn't care diddly
   squat about any of this, nor is it likely that if
   I tunnel to the 6bone they're going to care much
   either.

=> my proposal is not based on traditional unicast RPF ingress filtering
done by routers, it is based on firewalls at the border of source sites.
But don't believe RPF checks are obsolete, the idea is to use it against
traditional DDoS and to use enhanced ingress filtering against the iDDoS
threat from HAOs.

   If this is your only line of defense of
   protecting CN's from senders of malicious HAO's,
   I'm pretty skeptical.

=> enhanced ingress and anti-spoofing filterings are based on the knowledge
of bindings. If there should be no HAO sender in a site, the extra
ingress filtering rule is just "drop packets with a HAO". If there should
be no home agent in a site, the extra anti-spoofing filtering rule is
just "applies anti-spoofing to addresses in HAOs". So in common cases
the job is easy and even scalable.

   RPF checks "work" mainly
   implement.

=> I don't believe this is so easy but this is an indication that ISPs
are ready to implement a kind of access control which gives them no
direct benefit. IMHO we can trust smart ingress filtering as much as
current ingress filtering...

   Anything beyond that is likely to
   be a complete non-starter.
   
=> we'll see... We (IETF) can't do far more than to provide technical
solutions.

Regards