1 / 15

NATFW NSLP Intra-realm communications and Migration considerations

NATFW NSLP Intra-realm communications and Migration considerations. Cedric Aoun, Marcus Brunner, Miquel Martin Martin Stiemerling, Hannes Tschofenig IETF 58 Minneapolis. Agenda. NSIS NATFW NSLP role with NSIS unaware NATs NSIS protocol traversal of NSIS un-aware NATs and Firewalls

dalia
Télécharger la présentation

NATFW NSLP Intra-realm communications and Migration 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 Intra-realm communications and Migration considerations Cedric Aoun, Marcus Brunner, Miquel Martin Martin Stiemerling, Hannes Tschofenig IETF 58 Minneapolis

  2. Agenda • NSIS NATFW NSLP role with NSIS unaware NATs • NSIS protocol traversal of NSIS un-aware NATs and Firewalls • Unilateral signaling - No NR on the far end host • Open issues NSIS NATFW NSLP design team

  3. NSIS NATFW NSLP role with NSIS un-aware NATs • An NSIS NATFW NSLP MUST be able to discover that an NSIS un-aware NAT is deployed on the data path • Once an NSIS un-aware NAT is discovered on the data path then either 2 options would be available: • STUN • Create a STUN like capability within the NATFW NSLP NSIS NATFW NSLP design team

  4. 2-Address/port Mapping response 1-Request address/port mapping NSIS NATFW NSLP role with NSIS unaware NATs Net x Alice a.b.c.1/24 k.l.m.n/30 Phil The net a.b.c.e Bob e.f.g.h a.b.c.d “STUN-like capability” NSIS NATFW NSLP un-aware NAT NSIS NATFW NSLP signaling Data Flow NSIS NATFW NSLP design team

  5. NSIS NATFW NSLP role with NSIS unaware NATs Net x Alternate path issues Alice a.b.c.129/25 k.l.m.n/30 Phil The net a.b.c.e a.b.c.1/25 Bob e.f.g.h a.b.c.d “STUN-like capability” NSIS NATFW NSLP un-aware NAT NSIS NATFW NSLP signaling Data Flow NSIS NATFW NSLP design team

  6. NSIS protocol traversal of NSIS unaware NATs and Firewalls • NSIS un-aware NAT traversal: • QoS NSLP flow specification need to be taken from STUN or STUN like approach • Qos NSLP responder could only receive messages if the responder is listening on the same address and port as the data flows (not practical) • NSIS messages traversing NSIS un-aware NATs would require that NSIS is transported on top of widely deployed transport protocols (de-multiplexing requirement) • Example of troublesome transport approaches: • Raw IP • SCTP (very rare NAT implementations support it) NSIS NATFW NSLP design team

  7. NSIS protocol traversal of NSIS unaware NATs and Firewalls • NSIS un-aware Firewall traversal: • NSIS signaling MUST be allowed to bypass (proper identification of NSIS messages is required) • Data flows would need to use existing ACL capabilities NSIS NATFW NSLP design team

  8. No NSIS Responder on Bob’s end-host system ?? -Last NSIS aware NATFW will respond back with no NR on end-host notification -NI will let the user application decide if it wants to continue Unilateral Signaling Net x Alice a.b.c.1/24 NSIS aware NAT/FW + Qos NSLP k.l.m.n/30 The net a.b.c.e NSIS aware NAT/FW + Qos NSLP e.f.g.h/30 a.b.c.1/24 Bob a.b.c.d NSIS NATFW NSLP design team

  9. Migration NTLP requirements • NSIS un-aware NAT: • NTLP to run in datagram mode with NTLP sent from the source address and port on which the data will be sent and received NSIS NATFW NSLP design team

  10. Open issues • Are there known issues with RAO and existing Firewall implementations? • Packets could be dropped because of the IP option? • Unilateral signaling introduces a DoS attack, there is no means to determine if the targeted NR can’t be reached because of lack of protocol support or because the destination is not valid NSIS NATFW NSLP design team

  11. Open issues • How to deal with NATFW NEs that don’t have a trust relation with the NI in the case of uni-lateral signaling? • Unilateral operations require that last NATFW NSLP in the path respond back on behalf on the un-available NATFW NR • Does the NTLP play a role in this? NSIS NATFW NSLP design team

  12. Backup NSIS NATFW NSLP design team

  13. Intra-realm communications Net x Alice wants to talk to Bob Alice k.l.m.n/30 a.b.c.1/24 a.b.c.e The net Bob NSIS aware NAT/FW a.b.c.d How to avoid useless resource spending on NAT and Firewalls (potentially event Qos gates)? Let Bob provide to Alice both his locally scoped and global scoped addresses NSIS NATFW NSLP design team

  14. 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 NSIS NATFW NSLP design team

  15. Intra-realm communications • Proposed solution: • Communicate several NR addresses to the NI • The first response received from an NR will hint the NR address to use for the rest of the messages • NSIS messages need to be sent simultaneously and not sequentially (I.e. don’t wait for responses). • User application impacts: • Several NR addresses need to be provided • NTLP impacts: • Although a messaging association was already linked to a destination address, it needs to be re-checked if applicable or not to avoid the confusion of overlapped local scoped addresses NSIS NATFW NSLP design team

More Related