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
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