Your SlideShare is downloading. ×
0
Better IPSec Security Association Resolution - Netconf 2006 Tokyo
Better IPSec Security Association Resolution - Netconf 2006 Tokyo
Better IPSec Security Association Resolution - Netconf 2006 Tokyo
Better IPSec Security Association Resolution - Netconf 2006 Tokyo
Better IPSec Security Association Resolution - Netconf 2006 Tokyo
Better IPSec Security Association Resolution - Netconf 2006 Tokyo
Better IPSec Security Association Resolution - Netconf 2006 Tokyo
Better IPSec Security Association Resolution - Netconf 2006 Tokyo
Better IPSec Security Association Resolution - Netconf 2006 Tokyo
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Better IPSec Security Association Resolution - Netconf 2006 Tokyo

347

Published on

Better IPSec Security Association Resolution - Netconf 2006 Tokyo …

Better IPSec Security Association Resolution - Netconf 2006 Tokyo

Presentation slides.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
347
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Better IPSec Security Association Resolution Netconf 2006 Tokyo James Morris jmorris@namei.org    
  • 2. Problem a) Outbound packet b) Security policy db entry match c) No security association in kernel ● Most of the time, we return EAGAIN to app or drop packet if forwarding. ● We kick the key manager, and usually have an SA available for next packet.    
  • 3. Problem... ● It actually kind of works for one case: blocking sendmsg() of datagrams. ● Process is scheduled in a loop until SA resolved. See xfrm_lookup(). ● Does not work for connect(2), so ping and many UDP apps just get EAGAIN.    
  • 4. Solution ● General solution for all protocols and contexts: – connect(2) – sendmsg(2) – forwarding path (tunnel endpoint) – various kernel-generated packets – blocking and non-blocking modes    
  • 5. Solution... ● Ideally, we'd like connect(2) to follow Posix semantics, for non-blocking this is: – Return EINPROGESS first – Return EALREADY until SA resolved ● For non-blocking sockets in general, it'd be nice to make sure poll(2) works as expected. – even for datagram protocols, as IPSec adds a kind of session underneath.    
  • 6. Solution... ● sendmsg(2) should return EAGAIN for non- blocking case ● For tunnel end point, we probably need to queue packets in a resolution queue. ● This may also be useful for non-blocking socket case. ● Herbert has suggested larval dst to go with larval SA.    
  • 7. Status ● Current patch contains a lot of instrumentation and some initial changes: – Make connect(2) work for the blocking case, hooking into ip_route_connect() – Propagate new flags down to xfrm_lookup() to control behavior: ● Kick the key manager? ● Sleep until resolved?    
  • 8. Ongoing work ● Continue to develop code to handle all cases and protocols ● Probably involve some code consolidation ● Determine how much of the problem to solve    
  • 9. Issues ● Not clear on all of the use-cases for this: – Opportunistic encryption – Complex/large scale policy where pro-active SA negotiation overhead would be too high – Others?    

×