Subject: [saag] Addresses as Identifiers -> was RE: [Privsec-program] A tale of (flawed) transient numeric identifiers (Fwd: New Version Notification for draft-gont-numeric-ids-history-00.txt)

From: Paul Lambert <[email-masked]>
Date: Sat, 16 Jul 2016 00:39:27 +0000

Steve,

> the use of the 5-tuple you cited 4301 is needed to enforce a security
> policy based on those values. This was very common practice in firewall
> security policies in the time frame that 4301 was generated, and IPsec
> was striving to provide crypro-enforced security features analogous to
> what was available in firewalls.
> 
> yes, using this approach does cause problems with NATs, but at that time
> NATs were still viewed as evil ;-). 

Yes, at the time the strict enforcement of IP address based policies may have appeared to be useful. In hindsight, the use of an IP address as the 'identity' of a device for the enforcement of policies is problematic.

For "Privsec", I'm suggesting that openly visible addresses should not be arbitrarily bound to a security encapsulation at any layer.

 > Onion routing compatibility was not
> a goal for IPsec.

Perhaps, but the documented restrictions on the use of ESP could be relaxed to improve behavior through various types of address translations (for NAT, proxies or Onion-like routing).  

Paul

> 
> Steve
> 
> > One of my favorite Œprivacy issues' is in IPsec RFC 4301:
> > 	"Search the SAD for a match on the combination of SPI, destination
> > address, and source address.²
> >
> > IMHO the binding of the security association explicitly to the src/dst IP
> > addresses creates NATing problems and prevents interesting onion routing
> > like implementations that would hide the end addresses.  For best
> common
> > practice for any security protocol there should be no explicit binding of
> > visible addresses to the identifiers for encrypted information.
> >
> > Paul
> >
> >
> >
> > _______________________________________________
> > saag mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/saag
> >
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag