ingress filtering and multiple Internet conenctions

Mon Oct 26 03:52:29 UTC 2009

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20091025/b5fcd976/attachment.bin>