1 / 8

NATFW NSLP deployment/integration considerations

NATFW NSLP deployment/integration considerations. IETF 60th - August 2nd 2004 Cedric Aoun, Martin Stiemerling, Hannes Tschofenig. Migration requirements. draft-aoun-nsis-nslp-natfw-migration-02.txt The protocol should support the following cases:

elyse
Download Presentation

NATFW NSLP deployment/integration considerations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NATFW NSLP deployment/integration considerations IETF 60th - August 2nd 2004 Cedric Aoun, Martin Stiemerling, Hannes Tschofenig

  2. Migration requirements • draft-aoun-nsis-nslp-natfw-migration-02.txt • The protocol should support the following cases: • End-host does not support NATFW NSLP but the infrastructure does support it: • End host initiating the application signaling supports NSIS NATFW NSLP and it is behind: • A NAT • A Firewall - has asymmetric route issues • Other scenarios not currently supported: • End host initiating the application does not support the NATFW NSLP     Solution exists,  Solution exists with limited applicability  No solution provided

  3. Migration requirements • The protocol should support the following cases: • End-host supports the NATFW NSLP but the infrastructure does not support it • NTLP detects NSIS un-aware NAT • No real NSIS unaware firewall detection    Solution exists,  Solution exists with limited applicability  No solution provided

  4. NSIS Responder address selection • A NSIS host could have several addresses: • Several IPv4 addresses (effectively): • Interface addresses • Translated addresses (outermost NAT translated addresses, and inner NAT translated addresses) • Several IPv6 addresses (really): • Interface addresses: • ULAs, global scoped, link local

  5. NSIS Responder address selection • Existing address selection mechanisms don’t work well: • Particularly for IPv4 • Which address to select? • Potential overlap - using a private address may get you to another host in your own addressing realm • One address could provide more optimized data path: • NATs anchor the stream and the data would be backhauled to no useful purpose

  6. Intra-realm communications Net x Alice Alice wants to talk Phil a.b.c.1/24 NSIS aware NAT/FW + Qos NSLP k.l.m.n/30 The net a.b.c.e Bob NSIS aware NAT/FW + Qos NSLP e.f.g.h/30 a.b.c.1/24 a.b.c.d Local scoped address could obviously overlap, a solution needs to be provided to handle that case Phil a.b.c.d

  7. Intra-realm communications Sales/HR NAT Stacking 137.121.5.8 Alice ISP x 10.1.2.3 NATFW2 NAT1 Trudy Bob NAT3 192.168.1.2 Preferred Path!!! Need to avoid this path from being taken Foo.com Max

  8. NSIS Responder address selection • Solution was proposed in: • draft-aoun-nsis-nslp-natfw-intrarealm-01.txt • A NAT counter object is added to NSIS either within the NATFW NSLP or in the NTLP • CREATE messages are sent to all the NR addresses in parallel • No added delay • When an NATFW NSLP message goes through a NAT, the NAT counter object is incremented • When the message gets to the last NSIS hop, the resulting NAT counter is returned back • The NI will will decide which NR and data receiver address to use based on the smallest returned NAT counter and if the responder is truly the intended message recipient • Minimal delay in case first received RESPONSE message has NAT count >0

More Related