13.09.2014 Views

Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

Local Area Networks (LANs) in Aircraft - FTP Directory Listing - FAA

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

to-live (TTL) field <strong>in</strong> the IP header of the encapsulated (RED) packets of the forwarded packets<br />

so that they rema<strong>in</strong> transparent to the packet flow. (Note: if they are end-systems, they similarly<br />

will not decrement the TTL. However, if they are routers, then they will need to decrement the<br />

TTL because that is normal router behavior.)<br />

The selected VPN approach for this architecture uses IPsec <strong>in</strong> tunnel mode. It was designed by<br />

the L3VPN work<strong>in</strong>g group of the IETF [100]. This VPN design is entitled “Architecture for the<br />

Use of PE-PE IPsec Tunnels <strong>in</strong> BGP/MPLS IP VPNs” [99]. (Note: at the time of this writ<strong>in</strong>g,<br />

reference 99 has passed the IETF L3VPN work<strong>in</strong>g group’s last call and is currently <strong>in</strong> the RFC<br />

editor’s queue to be issued as an Informational RFC.) This is the secured IPsec variant to the<br />

L3VPN’s VPN design approach, which is “BGP/MPLS IP Virtual Private <strong>Networks</strong>” that was<br />

def<strong>in</strong>ed <strong>in</strong> RFC 4364. RFC 4364 is an IETF Proposed Standard protocol.<br />

The high-level architectural view of figure 30 does not show the encapsulation method<br />

recommended by this architecture. The encapsulation method detail is shown <strong>in</strong> figure 33.<br />

Section 5.6 <strong>in</strong>troduced the concept of VPN and section 5.2 described the current DoD COMSEC<br />

approach us<strong>in</strong>g a type of IPsec VPN. The particular VPN variant selected for this design was<br />

chosen because of its scalability, m<strong>in</strong>imal latency, and high security properties. However, other<br />

VPN alternatives also exist (e.g., Intra-Site Automatic Tunnel Address<strong>in</strong>g Protocol (see RFC<br />

4214); IP with virtual l<strong>in</strong>k extension [101]; Teredo (see RFC 4380); and the bump-<strong>in</strong>-the-wire<br />

security gateway of RFC 4301).<br />

<strong>Aircraft</strong><br />

Level A<br />

Level D<br />

Inner IP header<br />

addressed us<strong>in</strong>g<br />

“Level A”<br />

IP Address<br />

Space<br />

Inner IP header<br />

addressed us<strong>in</strong>g<br />

“Level D”<br />

IP Address<br />

Space<br />

Encapsulation<br />

Gateway<br />

Encapsulation<br />

Gateway<br />

Outer IP header<br />

Addressed us<strong>in</strong>g<br />

“Service Provider”<br />

IP Address Space<br />

High Assurance LAN<br />

Outer IP header<br />

Addressed us<strong>in</strong>g<br />

“Service Provider”<br />

IP Address Space<br />

Figure 33. Close-Up Detail of How Encapsulation is Accomplished<br />

Figure 34 shows the current architecture that underlies this design. This figure, which is a copy<br />

of Figure 1.1 from RFC 4110, shows that an ISP provides a provider edge (PE) <strong>in</strong>terface to their<br />

network services. The fact that these network services are physically conveyed via a VPN<br />

through the service provider’s network <strong>in</strong>frastructure is not necessarily known to their<br />

customers, who <strong>in</strong>terface to the PE <strong>in</strong>terface device via their own Customer Edge (CE) device.<br />

109

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!