Re: ingress filtering and multiple Internet conenctions

[Owen DeLong <owen () delong com>]

On Oct 25, 2009, at 4:58 PM, Joe Greco wrote:

> > Joe Greco wrote:
> > > There's a problem:  I can validly emit a variety of other  
> > > addresses, in
> > > particular any address in 206.55.64.0/20 and some other networks.   
> > > I am
> > > not "forging" packets if I emit 206.55.64.0/20-sourced addresses  
> > > down a
> > > Comcast pipe.
> > >
> > > How many people realistically have this problem?  Well, potentially,
> > > lots.  Anyone who uses a VPN could have a legitimate IP address on  
> > > their
> > > machine; because of BCP38 (and other security policy) it is common
> > > for a VPN setup to forward Internet-bound traffic back to the VPN
> > > server rather than directly out the Internet.  In some cases, one  
> > > could
> > > reasonably argue that this is undesirable.
> >
> > I would like to take the opportunity to urge vendors of routers and
> > firewalls to take extra special care and attention to make sure  
> > that The
> > Right Thing can always happen whenever multiple egress services are
> > employed.
> >
> > This means that policy routing for network AND ALL locally generated
> > traffic should be available and work as the operator intends it to.
> >
> > Right now things still suck pretty hard, depending on what you are  
> > using.
>
> Who defines what "The Right Thing" is?
>
> Allowing (what are to the service provider) random IP's inbound, even
> if there's some mechanism to limit it, means that the ISP now has some
> additional responsibilities to be able to transport packets for space
> that isn't theirs; a transit upstream or peer might filter, especially
> for smaller service providers.
>
> Basically, allowing this dooms BCP38.
Allowing the operator the configuration OPTION in all cases is good.
Rational defaults in favor of BCP-38 are acceptable.  The inability to
override those defaults is bad.

Owen

Attachment: smime.p7s
Description: