The SaNTA Project - ESA's ARTES Programmes · 2019-07-24 · SaNTA Project−History – ITT •...

The SaNTA ProjectThe SaNTA ProjectAndré Rosado

Skysoft Portugal, S.A.

[email protected]@skysoft.pt

José Brázio

Instituto de Telecomunicações/Inst. Superior Técnico, Lisbon Tech. UniversityInstituto de Telecomunicações/Inst. Superior Técnico, Lisbon Tech. University

[email protected]

ESTEC, December 2, 2008

OverviewOverview

• Introduction• Introduction

– Project partners, history, problem areas, phases

• Phase 1−TPRMMSN

• Phase 2−SaNTA• Phase 2−SaNTA

• Phase 3−SaNTA security

• Comparison with PEP architecture• Comparison with PEP architecture

• Phase 4−DVB-RCS trials

• SaNTA Usage Cases• SaNTA Usage Cases

• Concluding Remarks

2

Project PartnersProject Partners

� ESA was the main stakeholder of the SaNTA project

� ESA was the main stakeholder of the SaNTA project

� Skysoft was the Prime Contractor of the SaNTA project

� IT was the Subcontractor of the SaNTA project� IT was the Subcontractor of the SaNTA project

Partners – Skysoft Portugal Partners – Skysoft Portugal

Leading Portuguese Supplier of the European Space Agency (ESA)

Leading Portuguese Company in Software Engineering for Civil Aviation

Reference Portuguese Company for European Commission (EC)

• Software & Systems Engineering

Reference Portuguese Company for European Commission (EC)

• Software & Systems Engineering

Company

• Founded in 1998

• Based in Lisboa

• Turnover expected 2008: ≈ 6.5 M€

• Human Resources: ≈ 90 Eng.

Partners – Skysoft PortugalPartners – Skysoft Portugal

• Outstanding System & Software Engineering

• R&D Partnerships • R&D Partnerships

• Institutional Space & Defence Markets

• Strong Customer Focus

• Engineering Solutions and Applications

OPERATIONAL AREAS

A) Aeronautics, Aerospace, Security & Defence:

� Safety Critical Software� Safety Critical Software� Integrated Modular Avionics� Integrated Security Systems� Air Traffic Management System� Defence Data Networks & Systems• Satellite Navigation• Ground Segment (PDS, SCC) • Satellite Communications Systems

Technologies Mastering

GALILEO

GMES

PASR

�• Satellite Communications Systems• Link 11 / Link 16 Data Translator• Maritime Surveillance• AIS, VTS, SAR Integration

B) Telematics & Business Solutions:

�

Aero-Space & Defence

SatCom

Avionics

Navigation

Maritime

�

Key Contribution Infrastructure

& Institutional Programmes

Solutions:

� Intelligent Transport Systems� Mobility (LBS, GIS, FM) � IT & Business Solutions

Market Applications

Aero-Space & Defence�

5

Mobility

Security

Intelligent Transport Systems

Surveillance

Partners – IT Partners – IT

• Instituto de Telecomunicações (IT)• Instituto de Telecomunicações (IT)

• Private, not-for-profit organization, association of

– Instituto Superior Técnico, Lisbon Technical Univ.– Instituto Superior Técnico, Lisbon Technical Univ.

– University of Aveiro

– Faculty of Sciences and Technology, Univ. of Coimbra

– Portugal Telecom Innovation– Portugal Telecom Innovation

– Nokia-Siemens Networks

• Includes about 180 PhD researchers

• Covers areas ranging from material sciences, microwave, • Covers areas ranging from material sciences, microwave,

electronics, and circuit design, to networking and multimedia

communications

SaNTA Project−HistorySaNTA Project−History– ITT

• issued on the 29th of March 2000, from the Department of Communication

Satellites of ESTEC, in the scope of ASTE program (ref. MS 1.2), ARTES 5 Satellites of ESTEC, in the scope of ASTE program (ref. MS 1.2), ARTES 5

budget

• ESA Technical Officer: mr Erling Kristiansen

• Contemplated two phases

– Objectives

• develop a transport architecture and protocol to replace TCP, optimised for

the mobile satellite network environment

• implement measures to maximise the efficient utilization of satellite • implement measures to maximise the efficient utilization of satellite

networks by providing improved ways to manage resources

– Consortium

• Skysoft (prime) + Instituto de Telecomunicações (IT) (sub-contractor)• Skysoft (prime) + Instituto de Telecomunicações (IT) (sub-contractor)

– Contract

• Awarded on 19th of June 2001, in parallel with two other consortia

7

Problem AreasProblem Areas

• Efficient end-to-end transport service

– Mitigation of TCP end-to-end performance degradation under

• high loss rate• high loss rate

• large propagation delay

• asymmetric forward and return channel bandwidths

• Resource management• Resource management

– Dynamic assignment of satellite link resources in accordance

with varying traffic demands

• Model: availability of mechanisms for capacity allocation/deallocation via • Model: availability of mechanisms for capacity allocation/deallocation via

explicit signaling

8

Project PhasesProject Phases• Phase 1

– definition of the transport architecture and protocols and of the – definition of the transport architecture and protocols and of the

resource management concept; basic validation

• ended March 2003

• Phase 2• Phase 2

– prototype implementation and test in lab environment

• ended November 2004

• Phase 3• Phase 3

– introduction of security features; prototype enhancement and

validation

• ended November 2005

• Phase 4

– test in DVB-RCS environment (AmerHis)– test in DVB-RCS environment (AmerHis)

• started March 2007, ended February/2008

9

SaNTA ProjectSaNTA Project

� SaNTA Technological Development � SaNTA Technological Development

Phase 1−TPRMMSNPhase 1−TPRMMSN

• Study phase, leading to

– A transport architecture providing – A transport architecture providing

• efficient end-to-end transport service across heterogeneous network segments

• flow control between terrestrial and satellite links across resource

management and interworking unitsmanagement and interworking units

• ability to offer different types of services to applications, depending on

communication requirements, through a resource management policy

• end-to-end semantics

– A transport protocol suitable for satellite links

– A resource management concept

• encompassing the interaction with applications and satellite resource • encompassing the interaction with applications and satellite resource

management network entities

11

Transport Architecture ApproachTransport Architecture Approach

• Conceptual network and service model

– end-to-end path seen as sequence of homogeneous transport – end-to-end path seen as sequence of homogeneous transport

network segments (TNS)

– use within each TNS of a reliable flow-controlled connection-

oriented transport protocol, adapted to that TNSoriented transport protocol, adapted to that TNS

• TCP in terrestrial segments

• ad-hoc protocol over satellite link

– new upper layer located at user terminals and at network elements – new upper layer located at user terminals and at network elements

joining adjacent TNSs (InterWorking Unit, IWU) [cf. Sec. 12.4.1 of

ETSI TR 101 985]

• between TNSs, relays data between their associated transport protocols • between TNSs, relays data between their associated transport protocols

(almost like an application)

• at user end systems, passes data between applications and local transport

service

– end-to-end flow control via backpressure

12

Transport ArchitectureTransport Architecture

Satellite

Satellite dish Satellite dish

IWU BIWU A

WAN BWAN A

End User A End User B

Application ApplicationTVC1 TVC3TVC2

ITL

TCP/UDP

IP WAN

L2 WAN L2 SAT

IP SAT

SaSTP

ITL

TCP/UDP

IP WAN

L2 WANL2 SAT

IP SAT

SaSTP

Application

TCP/UDP

IP

L2 LAN

ITL

Application

TCP/UDP

IP

L2 LAN

ITL

TVC1 TVC3TVC2

TNS2TNS1 TNS3

Pros/ConsPros/Cons

• Advantages• Advantages

– Split architecture

• gives consistently better performance, with the right satellite transport protocol

• Disadvantages• Disadvantages

– Breaks end-to-end semantics of TCP

• no big deal, but new layer keeps end-to-end semantics anyway

– Needs keeping state

• Not a technological problem

– Needs changes to user communications stack– Needs changes to user communications stack

• (more on this later)

– Classical split architectures do not allow use of network-level

security (IPSec)security (IPSec)

• (more on this later)

Resource Management

ApproachApproach

ITL

TP

Appl

Mgmt

• Make resource management functions

available to applications and interworking

units, in order to manage satellite

resources on the basis of traffic information 1

NA1

IP

mtresources on the basis of traffic information

• Resource Management (RM) entity in IWUs

collects local measurements and

information obtained from RM-enabled user information obtained from RM-enabled user

terminals for requesting from an NCC

bandwidth manager the

allocation/deallocation of satellite link

bandwidthbandwidth

Design RequirementsDesign Requirements• Architecture

– Support of end-to-end data transfer allowing high satellite link – Support of end-to-end data transfer allowing high satellite link

utilization

– Capability to ensure routing of traffic through specific satellite

gatewaysgateways

– Capability to fall back into standard TCP operation

– Support of specific network configurations– Support of specific network configurations

• Communication services

– End-to-end unicast reliable connection-oriented (RCO) service, – End-to-end unicast reliable connection-oriented (RCO) service,

with flow control functions [elastic traffic]

– End-to-end unicast unreliable connection-oriented (UCO) service

[stream traffic][stream traffic]

– End-to-end unicast unreliable connectionless (UCL) service

Design RequirementsDesign Requirements

• Interface to applications• Interface to applications

– Compliant with standard TCP/UDP interface

• Resource Management (RM) functions• Resource Management (RM) functions

– Provision of mechanisms for the exchange of RM information

between applications, Resource Managers at IWUs, and NCC

bandwidth managersbandwidth managers

ITL ProtocolsITL Protocols

• ITL protocols defined for connection-oriented and

connectionless servicesconnectionless services

– Connection-oriented service protocol was specified covering

• Connection management (set-up, release, failure)

• Idle connection handling

• Data transfer

• Resource management information transfer

– Connectionless service– Connectionless service

• Data transfer

• Resource management information transfer

Satellite Link Transport ProtocolSatellite Link Transport Protocol

• Transport protocol over satellite link is required for • Transport protocol over satellite link is required for

reliable services

– Functionality included

• Connection set-up and tear-down• Connection set-up and tear-down

• Reliable transfer of user data

• Flow control

– Functionality not included– Functionality not included

• Congestion control

• Reordering/resequencing of packets

– Protocol was designed based on LAPB, with modifications on– Protocol was designed based on LAPB, with modifications on

• flow control: employ an advertised receiver window (à la TCP)

• support for dual IP addresses (for network elements in asymmetric

configurations

• support for multiple instances of execution• support for multiple instances of execution

Design, Validation, VerificationDesign, Validation, Verification

• Implementation Design supported on SDL specification

via automated tool

• Separate validation activities for

– Satellite link transport protocol– Satellite link transport protocol

– End-to-end architecture

• Correctness validation

– Coverage/reachability analysis, livelihood properties

Performance AssessmentPerformance Assessment

• Preliminary performance assessment• Preliminary performance assessment

– Specific focus on data transfer issues

– Via simulation and emulation

• ns2 simulator for TCP end-to-end assessment and satellite transport protocol• ns2 simulator for TCP end-to-end assessment and satellite transport protocol

• in-house emulator for new architecture, allowing insertion of real network

segments

• Items of interest• Items of interest

– Maximum throughput/satellite link utilization (heavy traffic

conditions)

– Packet transfer delay– Packet transfer delay

– System stability / buffer behavior with respect to packet losses

(random errors or link outages) or capacity changes

• Overall satisfactory results• Overall satisfactory results

Phase 2 – SaNTA Phase 2 – SaNTA

• Objectives• Objectives

– Re-establish requirements from Phase 1

– Re-define architecture and design from Phase 1

– Perform a pilot implementation of the protocols– Perform a pilot implementation of the protocols

– Perform a demonstration and performance measurement in a

realistic environment

• The demonstration environment may partly rely on simulation of components • The demonstration environment may partly rely on simulation of components

that are difficult or too costly to access.

RedesignRedesign

• Design developed in Phase 1 was interesting, butP• Design developed in Phase 1 was interesting, butP

– P people don’t want to change their terminal software

• Unreliable connection-oriented service is out

• Use of a modified protocol stack is out, including Resource Management • Use of a modified protocol stack is out, including Resource Management

(RM), at least in fixed terminals

– P DVB-RCS systems are on the way

• Asymmetric configuration is out

– Think of a solution where changes are made to network

elements at the point of interconnection to the Internet (routers,

firewalls)

• Modified protocol stack can be left in mobile terminals; RM can be left in

these and in IWUs

– Solution based on proxy ideas? Yes!

A Proxy-Based SolutionA Proxy-Based Solution

• Delegate ITL functions out of fixed user terminals

– Functionality of new protocol layer, formerly at user terminal, is – Functionality of new protocol layer, formerly at user terminal, is

migrated to “Satellite Enhancer” (SE) network element

• Replaces Internet access router

• Acts as a proxy: detects requests for new TCP connections and replies to these • Acts as a proxy: detects requests for new TCP connections and replies to these

requests and sets up corresponding ITL connections; same for connection

termination

APPLICATION

TCP/UDP

Satellite

ITLENABLED LAN

A

ITLENABLED LAN

B


TCP/UDP

IP

L2 LAN

Satellite

Satellite dish Satellite dishIWU BIWU A

WAN BWAN A

SE BSE A

ITL

TCP/UDP

IP WAN

L2 WAN L2 SAT

IP SAT

SaSTP

ITL

TCP/UDP

IP WAN

L2 WANL2 SAT

IP SAT

SaSTP

ITL

TCP/UDP

IP LAN

L2 LANL2 WAN

IP WAN

TCP/UDP

ITL

TCP/UDP

IP WAN

L2 WANL2 LAN

IP LAN

TCP/UDP

Satellite dishIWU

WAN

SE

ITLENABLED LAN

End User

ITL

TCP/UDP

IP WAN

L2 WAN L2 SAT

IP SAT

SaSTP

ITL

TCP/UDP

IP WAN

L2 WANL2 LAN

IP LAN

TCP/UDP

Mobile

Terminal

APPLICATION

SaSTP

IP SAT

ITL

APPLICATION

TCP/UDP

IP

L2 LANL2 WAN L2 SAT L2 WANL2 SAT L2 LANL2 WANL2 WANL2 LAN L2 WAN L2 SATL2 WANL2 LAN IP SAT

L2 SAT

L2 LAN

Split architecture operationSplit architecture operation


Application

TCP/UDP

IP

Application

TCP/UDP

IP

Satellite

L2 LAN L2 LAN

ITL

TCP/UDP TCP/UDP

ITL

TCP/UDP TCP/UDP

Satellite dish Satellite dish

IWU B

ITL

SaSTP

ITL

TCP/UDPSaSTP

WAN A

IWU A

TVC1TVC3

TVC2

SE A SE B

WAN B

TCP/UDP

IP WAN

L2 WAN L2 LAN

IP LAN

TCP/UDPTCP/UDP

IP LAN

L2 LAN L2 WAN

IP WAN

TCP/UDP TCP/UDP

IP WAN

L2 WAN L2 SAT

IP SAT

SaSTP TCP/UDP

IP WAN

L2 WANL2 SAT

IP SAT

SaSTP

TNS2TNS1 TNS3

Connection Set-upConnection Set-upTerminal A SE A IWU A IWU B SE B Terminal B

app A:

connect

(IP_B, port_B) IP* looks up ITL-Aware routing table

TCP

IP

TCP

IP

ITL

IP*

SYN (DEST=IP_B)

TCP SaSTP

IP

ITL

TCP SaSTP

IP

ITL

TCP TCP

IP

ITL

TCP TCP

IPIP*

IP* looks up ITL-Aware routing table

If IP_B is a local IP:

- IP* passes SYN to TCP

- TCP: returns SYN+ACK

- TCP: passes IP_A, port_A, IP_B, port_B to ITL

- ITL: determines next hop (IWU_A)- ITL: formats CR

- ITL: establishes TCP connection to IWU_A and ITL_CTRL_PORT

- ITL: sends CR via TCP

- ITL: creates new VCI table entry

SYN+ACK (SRC=IP_B)

- ITL: creates new VCI table entry

ITL: determines next hop (IWU_B)

ITL: changes CR

ITL: establishes SaSTP connection to IWU_B and ITL_CTRL_PORT

ITL: sends CR to IP_IWU_B via SaSTP.

ITL: creates new VCI table entry

CR (LI, VCI, IP_B, Port_B, Hop_limit, IP_A, Port_A)

CR (LI, VCI, IP_B, Port_B, Hop_limit, IP_A, Port_A )ITL: determines next hop (SE_B)

ITL: changes CR

ACK (DEST=IP_B)



CR (LI, VCI, IP_B, Port_B, Hop_limit, IP_A, Port_A )ITL: determines next hop (IP_A)

ITL: establishes TCP connection ( with SD = IP_A ) to IP_B and PORT_B

ITL: changes CR

ITL: establishes TCP connection to SE_B and ITL_CTRL_PORT

ITL: sends CR to IP_SE_B via TCP.

ITL: creates new VCI table entry

SYN (SRC=IP_A)

If IP_B is a local IP:- IP* passes ACK to TCP

- TCP: passes to ITL


se IP_A é ITL:

- IP* passes SYN+ACK to TCP

- TCP: sends ACK to B ( with SD = IP_A )

- ITL: formats CC and sends to IWU_B via TCP

ITL: changes CC

SYN+ACK (DEST=IP_A)

ACK (DEST=IP_A)

CC ()

CC ()

ITL: changes CC

ITL: sends CC to IWU_A via STP

ITL: changes CC

ITL: sends CC to SE_A via TCP

CC ()

CC ()

Data TransferData Transfer

App. A:

send (IP_B, port_B)IP* looks up ITL-Aware routing table


Terminal A SE A IWU A IWU B SE B

TCP

IP

TCP

IP

ITL

IP*

TCP SaSTP

IP

ITL

TCP SaSTP

IP

ITL

TCP TCP

IP

ITL

TCP

IP*

send (IP_B, port_B) If IP_B is a local IP:

- IP* passes TCP segment to TCP-

- ITL: receive() extracts data.

- ITL: determines next hop (IWU_A)

- ITL: formats DATA- ITL: send() through TCP connection to IWU_A

ITL: changes DATA (VCI switching)

ITL: sends DATA to IP_IWU_B via SaSTP connection

DATA ()

TCP: returns ACK to AACK (SRC=IP_B)

ITL: sends DATA to IP_IWU_B via SaSTP connection

ITL: changes DATA (VCI switching)ITL: sends DATA to IP_SE_B via TCP connection

ITL: determines next hop (IP_B)ITL: extracts data

ITL: sends to IP_B via TCP connection (DATA ( )

DATA ()

ACK (DEST=IP_A)

IP* looks up ITL-Aware routing tableif IP_A i s a local IP:

ITL

CL service

if IP_A i s a local IP:- IP* passes ACK to TCP

Terminal A SE A IWU A IWU B SE B

UDP

IP

UDP

IPIP*

ITL

IP

UDP

IP

ITL

UDP

ITL

UDP

IP IP*

ITL

IP

MT

App. A:

UDPUDP

App. A:

sendto (IP_B, port_B) IP* looks up ITL-Aware routing tableIf IP_B is a local IP:

- IP* passes UDP segment to UDP

- ITL: receive(), extracts data

- ITL: determines next hop (IWU_A)- ITL: formats DG

- ITL sends to IWU_A via UDP

DG()ITL: changes DG

ITL: sends DG to IP_IWU_B via IPITL: changes DG

DG ()ITL: changes DG

ITL: sendto() to IP_SE_B via UDPITL: determines next hop (IP_B)ITL: extracts data

ITL: creates UDP packet with SD = IP_AITL: sends to IP_B via UDP

DG ()

DG ()

DG ()ITL: extracts data

Network ElementsNetwork Elements

• Satellite Enhancer (SE)• Satellite Enhancer (SE)

ITL

TCP UDP TCPUDP

ITL-Aw are

• InterWorking Unit (IWU)

IP_LAN IP_WAN

DL_LAN DL_WAN

ITL-Aw are

Routing Table

• InterWorking Unit (IWU)

ITLRM

TCP UDP SaSTP

Scheduler

TCP UDP SaSTP

IP_Terr IP_Sat

DL_Terr DL_Sat

Network ElementsNetwork Elements

• Mobile Terminal• Mobile Terminal

Performance TestsPerformance Tests

• Lab Test Bed

Satellite

Network

Emulator

• Lab Test Bed

IWU1

IWU2/MTFTP

TELNET

Emulator

FTP

TELNET

SE1

IWU2/MT

SE2

TELNET

HTTP

UT2

TELNET

HTTP

UT1UT2

Test ResultsTest Results

Steady State Throughput (Satellite Link Utilization)

256 kbit/s, 1 connection

20

25

30

35

KBytes/s

SaNTA Architecture,

ITL Buffer Size = 2

SaNTA Architecture,

0

5

10

15

20

KBytes/s

SaNTA Architecture,

ITL Buffer Size = 5

SaNTA Architecture,

ITL Buffer Size = 20

End2End TCP

BER=0

BER=1E-6,

PER=~1.1%

BER=5E-6,

PER=~5.5%

BER=1E-5,

PER=~10.8%

BER=2E-5,

PER=~20.4% Maximum Theoretical

Throughput



256 kbit/s, 2 connections

8

10

12

14

16

KBytes/s

SaNTA Architecture,

ITL Buffer Size = 2

0

2

4

6

BER

=0

BER

=1E-

6, P

ER=~

1.1%

BER

=5E-

6, P

ER=~

5.5%

BER

=1E-

5, P

ER=~

10.8

%

BER

=2E-

5, P

ER=~

20.4

%

KBytes/s

ITL Buffer Size = 2

SaNTA Architecture,

ITL Buffer Size = 5

SaNTA Architecture,


End2End TCPBER

=0

BER

=1E-

6, P

ER=~

1.1%

BER

=5E-

6, P

ER=~

5.5%

BER

=1E-

5, P

ER=~

10.8

%

BER

=2E-

5, P

ER=~

20.4

%

End2End TCP




456789

KBytes/s

SaNTA Architecture,

ITL Buffer Size = 2

01234

BER

=0

BER

=1E-

6, P

ER=~

1.1%

BER

=5E-

6, P

ER=~

5.5%

BER

=1E-

5, P

ER=~

10.8

%

BER

=2E-

5, P

ER=~

20.4

%

KBytes/s

ITL Buffer Size = 2

SaNTA Architecture,

ITL Buffer Size = 5

SaNTA Architecture,


End2End TCPBER

=0

BER

=1E-

6, P

ER=~

1.1%

BER

=5E-

6, P

ER=~

5.5%

BER

=1E-

5, P

ER=~

10.8

%

BER

=2E-

5, P

ER=~

20.4

%

End2End TCP




1.5

2

2.5

3

3.5

KBytes/s

SaNTA Architecture,

ITL Buffer Size = 2

0

0.5

1

1.5

BER

=0

BER

=1E-

6, P

ER=~

1.1%

BER

=5E-

6, P

ER=~

5.5%

BER

=1E-

5, P

ER=~

10.8

%

BER

=2E-

5, P

ER=~

20.4

%

KBytes/s

ITL Buffer Size = 2

SaNTA Architecture,

ITL Buffer Size = 5

SaNTA Architecture,


End2End TCPBER

=0

BER

=1E-

6, P

ER=~

1.1%

BER

=5E-

6, P

ER=~

5.5%

BER

=1E-

5, P

ER=~

10.8

%

BER

=2E-

5, P

ER=~

20.4

%

End2End TCP



Asymmetric links, 1 connection, SaNTA

80

100

120

0

20

40

60KBytes/s

0BER=0 BER=5E-6,

PER=~5.5%

BER=2E-5,

PER=~20.4%

1Mbit/s:128Kbit/s 1Mbit/s:64Kbit/s 1Mbit/s:32Kbit/s



Asymmetric links, 1 connection, TCP

80

100

120

0

20

40

60KBytes/s

0BER=0 BER=5E-6,

PER=~5.5%

BER=2E-5,

PER=~20.4%

1Mbit/s:128Kbit/s 1Mbit/s:64Kbit/s 1Mbit/s:32Kbit/s


Bandwidth Sharing, Steady State

No bit errors, ITL Buffer Size = 5

1000000

1200000

Connection 10

400000

600000

800000

Accumulated KBits

Connection 9

Connection 8

Connection 7

Connection 6

Connection 5

Connection 4

Connection 3

Connection 2

Connection 1

0

200000

0 20 40 60 80 100 120 140 160 180 200 220 240

Time (sec)

Connection 1


Satellite Link Outage

No bit errors

300000

350000

400000

450000

Connection 10

Connection 9

100000

150000

200000

250000

Accumulated Kbits Connection 8

Connection 7

Connection 6

Connection 5

Connection 4

Connection 3

Connection 2

Connection 1

0

50000

100000

0 5 10 15 20 25 30 35 40 45 50 55 60

Time (sec)


Satellite Link Outage

BER = 5e-6

250000

300000

350000

Connection 10

Connection 9

100000

150000

200000

Accumulated Kbits

Connection 9

Connection 8

Connection 7

Connection 6

Connection 5

Connection 4

Connection 3

Connection 2

Connection 1

0

50000

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70

Time (sec)


Dynamic Fairness

No bit errors

25000

30000

35000

Throughput (KBytes/s)

5000

10000

15000

20000

Throughput (KBytes/s)

0

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190

Time (sec)

N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19

Phase 3 – SaNTA SecPhase 3 – SaNTA Sec

• Objective

– Develop a Security Architecture for SaNTA

• Work led by A. Zuquete, University of Aveiro

– Only main points referred here– Only main points referred here

– Details available in

• A. Zuquete, “A Security Architecture for a Satellite Network Transport

Architecture,” SINO’2005Architecture,” SINO’2005

• http://www.ieeta.pt/~avz/pubs/SINO2005.pdf

Phase 3 – SaNTA SecPhase 3 – SaNTA Sec

• SaNTA security-related issues

– End-to-end confidentiality

• Prevents SaNTA from accessing transport headers

• Example: layer-2 VPNs (PPTP, L2TP), IPSec confidentiality

– End-to-end peer authentication– End-to-end peer authentication

• Prevents SaNTA from impersonating end hosts/networks

• Example: IPSec authentication of origin/destination hosts

• Activity goals• Activity goals

– Intrinsic security

– Security tolerance– Security tolerance

– Architectural solution

Topological DeploymentTopological Deployment

• SEs

– Should belong to the infrastructure of SaNTA clients

• Within an isolated DMZ

• On network gateways

– Should be completely or as much as possible managed by – Should be completely or as much as possible managed by

clients

• End-networks administrators choose the right approach to route authorized

traffic into SaNTA through a local SEtraffic into SaNTA through a local SE

• Should be protected from inside or outside attacks– To prevent usage abuses of satellite links imputable to SEs' owners

• IWUs• IWUs

– Deployed and managed by satellite link providers

– Behave as Internet routers with SaNTA capabilities only for

authorized SEsauthorized SEs

Trust and Access ControlTrust and Access Control• SaNTA must be trusted by end-nodes/networks

– Contractual relationship between the end-nodes and the – Contractual relationship between the end-nodes and the

company selling the services of a particular SaNTA infrastructure

• Correct exploitation

– It should be used only by authorized end-users or by authorized – It should be used only by authorized end-users or by authorized

end-nodes/networks

– It should not be abused by any Internet nodes

• Elementary authorization policy• Elementary authorization policy

– SEs should only communicate with authorized peers

– IWUs should only communicate with authorized peers– IWUs should only communicate with authorized peers

• Mechanisms for enforcing the authorization policy in SEs

and IWUs

– Packet-filtering firewall for dropping unintended traffic– Packet-filtering firewall for dropping unintended traffic

– Strong authentication mechanism for authenticating IP peers

Security Service GoalsSecurity Service Goals

• Transparency

– No security mechanisms directly provided to end-nodes and

applications

• SaNTA should be similar to an Internet core router

– No interference with security requirements of end-nodes and

applications

• Secure added value• Secure added value

– Protect all SaNTA traffic

– Do not introduce new vulnerabilities in the traffic

accelerated/tunneledaccelerated/tunneled

– Issues

• Peer Authentication

• Protection of the data flows• Protection of the data flows

• Availability

Security ServicesSecurity Services


Pretended end-to-end interaction


Mutually

authentic

ated

access LAN 2 LAN 1

IWU2

+

SE2 N2

IWU2 IWU1 SE1

Mutually

authenticated

access

Mutually

authenticated

access

N1 N2

Possible

authenticated

access

Mutuallyauthenticated

access

Possible

authenticated

access

SE2

ITL Virtual Circuit / Tunnel

Security ServicesSecurity Services

• Protection of Data Flows

Pretended end-to-end interaction

• Protection of Data Flows

Protection

of ITL ha

ndshakes

and hea

ders

LAN 2 LAN 1

IWU2

+

SE2 N2

IWU2 IWU1 SE1

Protection of ITL

handshakes and

headers

Protection of ITL

handshakes and

headers

N1 N2

Protection of ITL handshakes and

headers

SE2

Transport payload protection

Proposed Security TechnologiesProposed Security Technologies

Secure TCP data flows

IWU2

+

Pretended TCP Virtual Circuit

SE2

IWU2 IWU1

SaSTP Virtual Circuits

SE1TCP Virtual Circuit TCP Virtual Circuit

SE2

N1

TCP Virtual Circuit

N2

TCP Virtual Circuit

N2

IPSec AH IPSec AHIPSec AH

SSL/TLS or SSH confidentiality and authentication

ITL Virtual Circuit

SE1 IWU1 IWU2 SE2 N2N1

IP header IP headerTCP header SaSTP header TCP header

AH header SA

SE1-IWU1

IP header

(SE1-IWU1)

AH header SA

IWU1-IWU2

AH header SA

IWU2-SE2

IP header

(IWU1-IWU2)

IP header

(IWU2-SE2)

TCP payload TCP payload

TCP header TCP header

(N1-N2) (N1-N2)

TCP original payload (encrypted)

SSL headers (session SE1-SE2)

ITL header


Secure UDP data flows

IWU2

+

Pretended UDP interaction

+

SE2

IWU2 IWU1

UDP Datagrams

SE1UDP datagrams UDP Datagrams

SE2

N1

UDP Datagrams

N2

UDP Datagrams

N2

IPSec AH IPSec AHIPSec AHN1 N2

ITL UDP tunneling

IPSec AH IPSec AH

IPSec ESP confidentiality and authentication

IPSec AH

IWU1 IWU2 N2N1 SE1 SE2IWU1 IWU2 N2N1

IP header IP header

AH header SA

SE1-IWU1

IP header

(SE1-IWU1)

AH header SA

IWU1-IWU2

AH header SA

IWU2-SE2

IP header

(IWU1-IWU2)

IP header

(IWU2-SE2)

SE1 SE2

UDP payload UDP payload

UDP header UDP header

IP header

(N1-N2)

IP header

(N1-N2)

UDP original payload (encrypted, ESP SE1-SE2)

UDP header UDP header UDP header

ITL header (using UDP/IP address from N1 & N2)


Secure “Opaque” data flows

Proposed Key ManagementProposed Key Management

• Authentication keys

– Two possibilities, first is preferable

• With asymmetric cryptography and X.509 certificates

• With secret, symmetric pre-shared keys

• Session keys

– Approach

• Give clients all the relevant tuning options (inter-SEs policies are client-• Give clients all the relevant tuning options (inter-SEs policies are client-

defined)

– Inter-SEs Authentication

• For SSL sessions protecting TCP payloads

• Client-defined possibilities

– Issues

• Perfect Forward Secrecy (PFS)

• Rekeying• Rekeying

SaNTA vs. PEP ArchitecturesSaNTA vs. PEP Architectures

• Performance-wise

– Both are split architectures

– Performance depends mostly on satellite link transport protocol

• Functionality-wise• Functionality-wise

– Presence of tunnel all the way to end-user intranet allows further

degrees of control and further funcionality

• e.g., security functions/VPN tranparent to end users• e.g., security functions/VPN tranparent to end users

Phase 4 – SaNTA AmerHisPhase 4 – SaNTA AmerHis

� Objective� Objective

-Extensively test SaNTA prototype in a DVB-RCS environment

� Motivation

-Assess performance with a consolidated -Assess performance with a consolidated standard in the segment

-Compare results against TCP implementation-Compare results against TCP implementation

53

Phase 4 – SaNTA AmerHisPhase 4 – SaNTA AmerHis� RCST and IWU machines were placed at Madrid due to regulatory

issues (frequency band) in Portugal regarding AmerHis antennasissues (frequency band) in Portugal regarding AmerHis antennas

54


�AmerHis System Features�AmerHis System Features

� Multimedia payload embarked in a commercial communication satellite systemcommunication satellite system

� Regenerative System

� Support of open standards DVB-RCS/DVB-S

� Meshed Topology� Meshed Topology

� Dynamic management of bandwidth – DAMA protocol, with capacity categories CRA and RBDC

55

protocol, with capacity categories CRA and RBDC


� Main results� Main results• SaNTA proved to be a more efficient implementation under the following conditions:

�Heavy Load Conditions�Heavy Load Conditions

�High BER value on Satellite link

�Different AmerHis configurations, varying values of SDR and PDRof SDR and PDR

�SDR ≅≅≅≅ CRA, PDR - SDR ≅≅≅≅ RBDC

• SaNTA has a considerably higher throughput than TCP than TCP

• Evidence of the fairness mechanism implemented in SaNTA

56


-Comparison against TCP for Heavy-load conditions (20 Mb evenly

distributed)distributed)

� Throughput achieved for SaNTA (Average Throughput ~ 300 Kbps)

200,00

250,00

300,00

350,00

Avg Data Transfer Rate (Kbps)

50,00

100,00

150,00

200,00


0,00

1 connection 2 connections 5 connections

Number of simultaneous connections


SaNTA TCP

57

SaNTA TCP


-Comparison against TCP with BER (=1.5*10e-6)

� SaNTA measures correspond to an average data rate three times

faster than TCP

140

80

100

120

Transfer Time (sec) x

40

60

80


0

20

0 200000 400000 600000 800000 1000000 1200000

Object Size (bytes)

58

Object Size (bytes)

SaNTA End-to-End TCP Linear (SaNTA) Linear (End-to-End TCP)


- Comparison between SaNTA and TCP for different BER values

35

40

15

20

25

30

35

KBytes/s

End2End TCP

SaNTA

0

5

10

BER=0

BER

=1E-6

, PER

=~1.

1%

BER

=5E-6

, PER

=~5.

5%

BER

=1E-5

, PER

=~10

.8%

BER

=2E-5

, PER

=~20

.4%

BER=0

BER

=1E-6

, PER

=~1.

1%

BER

=5E-6

, PER

=~5.

5%

BER

=1E-5

, PER

=~10

.8%

BER

=2E-5

, PER

=~20

.4%

59

BER

=1E-5

, PER

=~10

.8%

BER

=2E-5

, PER

=~20

.4%


-- Comparison between SaNTA trials with modification of SDR parameter

(SDR=0, 20 and 200 Kbps)(SDR=0, 20 and 200 Kbps)

� Similar behaviour (parallel graphs), with SaNTA response to

smaller transfers being directly determined by SDR value

50

60

70


20

30

40


0

10

20

0 200000 400000 600000 800000 1000000 1200000 1400000 1600000 1800000 2000000


60

0 200000 400000 600000 800000 1000000 1200000 1400000 1600000 1800000 2000000

Object Size (bytes)

Test E1 (SDR=0 Kbps) Test E2 (SDR=20 Kbps) Test E3 (SDR = 200 Kbps)

Linear (Test E1 (SDR=0 Kbps)) Linear (Test E2 (SDR=20 Kbps)) Linear (Test E3 (SDR = 200 Kbps))

SaNTA Usage CasesSaNTA Usage Cases

DECISION Project

� Deployment of satellite solutions in the context of

European Civil Protection operations

� Skysoft contributed in Satellite IP communications with

SaNTA framework for mobility (using INMARSAT BGAN SaNTA framework for mobility (using INMARSAT BGAN

terminals)

http://www.esa.int/esaCP/SEMZBAEQCAF_index_0.html

61

SaNTA Usage CasesSaNTA Usage Cases

FLYSAFE Project

� FLYSAFE – Aeronautics project focused on flight safety,

dealing with traffic and ground collision and adverse

FLYSAFE Project

weather conditions

� Skysoft involved in Data Link Solution to On-board � Skysoft involved in Data Link Solution to On-board

request of weather information from Ground Station

(Meteorological Center), using SaNTA Framework(Meteorological Center), using SaNTA Framework

62

SaNTA Usage CasesSaNTA Usage CasesFLYSAFE Project

63

Concluding RemarksConcluding Remarks

• The SaNTA project has provided a fertile environment

for experimenting with split architectures and satellite for experimenting with split architectures and satellite

transport protocols

– Some of its assumptions have been superseded by – Some of its assumptions have been superseded by

developments in DVB-RCS

• mainly concerning resource management, itself a hot topic

– Assumptions concerning end-to-end transport service continue – Assumptions concerning end-to-end transport service continue

up-to-date

– Design options made make it somewhat far from the ETSI PEP

architecture, but differences are not intrinsicarchitecture, but differences are not intrinsic

• What we have today is still a prototype but, overall, it has

proved a reliable operational platform

Thank you for your interest!Thank you for your interest!

Annex

SaNTA SecuritySaNTA Security

André ZúqueteAndré Zúquete

[email protected]

Instituto de Telecomunicações/Universidade de Aveiro

ESTEC, January 6, 2006

4.2 SaNTA Sec Architecture4.2 SaNTA Sec ArchitectureWelcome

Project Introduction

Objectives and

RelevanceRelevance

4. Achievements

Coffee Phase IIICoffee

Results Vs Objectives

Future Features

Discussion Period and

Close-Out

Phase III

End of Session

4.3.1 SaNTA Security Architecture: Why

something new?

• Most paradigms used in secure • Most paradigms used in secure communication protocols enforce end-to-end security policies

Welcome


Objectives and

Relevanceend-to-end security policies– Preventing intermediate nodes to

take an active role in the communication

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture communication

• SaNTA security-related issues:– End-to-end confidentiality

Architecture

Coffee


– End-to-end confidentiality• Prevents SaNTA from accessing transport headers

• Example: layer-2 VPNs (PPTP, L2TP),

Future Features


Close-Out

End of Session

• Example: layer-2 VPNs (PPTP, L2TP), IPSec confidentiality

– End-to-end peer authentication• Prevents SaNTA from impersonating end • Prevents SaNTA from impersonating end hosts/networks

• Example: IPSec authentication of origin/destination hosts

4.3.1 SaNTA Security Architecture: Goals

• Intrinsic security– Provide security solutions for protecting SaNTA – Provide security solutions for protecting SaNTA infrastructures

– Provide security solutions for protecting data flows handled by SaNTA entities

Welcome


Objectives and

Relevance flows handled by SaNTA entities

• Security tolerance– Provide the adequate mechanisms to tolerate

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture – Provide the adequate mechanisms to tolerate end-to-end security mechanisms

• Architectural solution

Architecture

Coffee

Results Vs Objectives • Architectural solution– Use state-of-art security mechanisms solutions for providing security

Future Features


Close-Out

End of Session

4.3.2 Topological deployment (1/2)

• SEs

– Should belong to the infrastructure of SaNTA clients

Welcome


Objectives and

RelevanceSaNTA clients• Within an isolated DMZ

• On network gateways

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture – Should be completely or as much as possible managed by clients• End-networks administrators choose the

Architecture

Coffee

Results Vs Objectives • End-networks administrators choose the right approach to route authorized traffic into SaNTA through a local SE

• Should be protected from inside or outside attacks

Future Features


Close-Out

End of Session

attacks

– To prevent usage abuses of satellite links imputable to SEs' owners

4.3.2 Topological deployment (2/2)

• IWUs

– Deployed and managed by satellite link providers

Welcome


Objectives and

Relevanceproviders

– Behave as Internet routers with SaNTA capabilities only for authorized SEs

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture Architecture

Coffee


Future Features


Close-Out

End of Session

4.3.3 Trust and Access Control (1/2)

• SaNTA must be trusted by end-nodes/networksnodes/networks– Contractual relationship between the end-nodes and the company selling the services of a particular SaNTA

Welcome


Objectives and

Relevance services of a particular SaNTA infrastructure

• Correct exploitation

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture • Correct exploitation– It should be used only by authorized end-users or by authorized end-

Architecture

Coffee

Results Vs Objectives users or by authorized end-nodes/networks.

– It should not be abused by any Internet nodes

Future Features


Close-Out

End of Sessionnodes

• Elementary authorization policy– SEs should only communicate with

4.3.3 Trust and Access Control (2/2)

– SEs should only communicate with authorized peers• Authorized end-nodes and well-known IWUs

– IWUs should only communicate with

Welcome


Objectives and

Relevance – IWUs should only communicate with authorized peers• Well-known/authorized SEs and IWU peers

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture

• Mechanisms for enforcing the authorization policy in SEs and IWUs

Architecture

Coffee

Results Vs Objectives authorization policy in SEs and IWUs

– Packet-filtering firewall for dropping unintended traffic

Future Features


Close-Out

End of Session

unintended traffic

– Strong authentication mechanism for authenticating IP peersauthenticating IP peers• Example: IPSec authentication (preferably with AH)

A - Transparency

4.3.4 SaNTA security services: Goals

– No security mechanisms directly provided to end-nodes and applications.• SaNTA should be similar to an Internet core router

Welcome


Objectives and

Relevance• SaNTA should be similar to an Internet core router

– No interference with security requirements of end-nodes and applications

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture applications

B - Secure added value

Architecture

Coffee

Results Vs Objectives B - Secure added value– Protect all SaNTA traffic

– Do not introduce new vulnerabilities in the traffic accelerated/tunneled

Future Features


Close-Out

End of Session

the traffic accelerated/tunneled

4.3.4 SaNTA security services:

A - Transparency

Two complementary approaches:Welcome


Objectives and

Relevance

1. Mitigation– Handle properly problematic traffics

• Follow a best effort policy

• Example: tunneling and relaying

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture • Example: tunneling and relaying

2. Security added value– Deployment of internal security mechanisms

Architecture

Coffee

Results Vs Objectives– Deployment of internal security mechanisms

• For providing a similar protection of data flows

• Example: IPSec-like security along the SaNTA path

– They allow end-users to securely abandon their

Future Features


Close-Out

End of Session

– They allow end-users to securely abandon their end-to-end security mechanisms for benefiting from SaNTA acceleration



Welcome


Objectives and

Relevance

Secure added value:Relevance

4. Achievements

4.3 SaNTA Sec

Architecture 1. Peer Authentication

2. Protection of the data flows

3. Availability

Architecture

Coffee


3. AvailabilityFuture Features


Close-Out

End of Session

1. Peer Authentication



1. Peer Authentication

• End-hosts/networks �� SEs

Welcome


Objectives and

Relevance • End-hosts/networks �� SEs– Managed solely by the administrators of end-

networks

• They all belong to the same security domain

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture • They all belong to the same security domain

– Each SE should interact only with an authorized set of hosts within the end-network it belongs to

• Between SaNTA entities

Architecture

Coffee


• Between SaNTA entities– Mutual authentication

Future Features


Close-Out

End of Session


B - Secure added valuePeer AuthenticationPeer Authentication



Welcome


Objectives and

Relevance

2. Protection of data flows

• IPSec-like security along SaNTA path

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture • IPSec-like security along SaNTA path– Wide end-to-end security policy for protecting

transport payloads• Between SEs

Architecture

Coffee

Results Vs Objectives• Between SEs

– Per hop security policy for protecting the negotiation of ITL connections between SaNTA entities

Future Features


Close-Out

End of Session

• Protection of radio-broadcasted traffic– Rely on the previous mechanisms


B - Secure added valueProtection of data flowsProtection of data flows



Welcome


Objectives and

Relevance

3. AvailabilityRelevance

4. Achievements

4.3 SaNTA Sec

Architecture • Protection from abuses

– Unauthorized access attempts

Architecture

Coffee


– Unauthorized access attempts

– Denial-of-service attacks

Future Features


Close-Out

End of Session

Secure Communication Technologies:

4.3.5 Secure Communication Technologies

Secure Communication Technologies:

A – SSL/TLS

Welcome


Objectives and

RelevanceA – SSL/TLS

B – SSH

C – IPSec

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture Architecture

Coffee


Future Features


Close-Out

End of Session


A - SSL/TLS

• Useful features for SaNTA:– Confidentiality, authentication and integrity control to critical Information used by SaNTA in

Welcome


Objectives and

Relevancecontrol to critical Information used by SaNTA in the negotiation of ITL connections / tunnels

– Confidentiality, authentication and integrity control to original TCP payloads encapsulated in ITL and exchanged between SEs

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture ITL and exchanged between SEs

• Possible integrations

Architecture

Coffee

Results Vs Objectives • Possible integrations– First requires ITL to use SSL instead of TCP

• TCP over ITL over SSL over TCP

– Two options for the second:

Future Features


Close-Out

End of Session– Two options for the second:

• TCP over SSL over ITL over TCP

• TCP over ITL over SSL over TCP

– ITL over SSL is preferable

• But the ITL state machine must be updated!


B - SSH

• Useful features for SaNTA:– Same as for SSL

Welcome


Objectives and

Relevance

• Possible integrations– TCP tunneled into a inter-SE SSH session over ITL

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture – TCP tunneled into a inter-SE SSH session over ITL

– TCP over ITL over an SSH session tunnel

Architecture

Coffee


• Better or worse than SSL?– Worse: no key management, no library

Future Features


Close-Out

End of Session

– Worse: no key management, no library


C - IPSec

• Useful features for SaNTA:– Source authentication of all IP traffic between SaNTA components

Welcome


Objectives and

Relevance between SaNTA components• For peer authorization

• For preventing man-in-the-middle and DoS attacks

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture attacks

– Integrity control of IP datagrams

– Prevention of IP replay attacks

– Confidentiality of original UDP

Architecture

Coffee

Results Vs Objectives – Confidentiality of original UDP datagrams encapsulated in ITL

• Possible integrations

Future Features


Close-Out

End of Session

• Possible integrations– Complex, SaNTA is an application, IPSec runs in OS kernels

• Peer authentication– IPSec AH

4.3.6 Proposed Security Technologies

– IPSec AH

• Protection of data flows

Welcome


Objectives and

Relevance • Protection of data flows– SSL between SaNTA peers for ITL handshakes and headers

– SSL between SEs for original TCP

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture – SSL between SEs for original TCP payloads

– IPSec ESP between SEs for original UDP payloads

Architecture

Coffee

Results Vs Objectives payloads

– UDP tunnel and IPSec ESP between SEs for other data flows (opaque)

Future Features


Close-Out

End of Session


Secure TCP data flows


Secure UDP data flows


Secure “Opaque” data flows

• Two possibilities, first is preferable

4.3.7 Proposed key management:

Authentication keys

• Two possibilities, first is preferable

– With asymmetric cryptography and X.509 certificates

Welcome


Objectives and

Relevance– With asymmetric cryptography and X.509 certificates• Possibly issued by a self-certified CA managed by a satellite link owner and SaNTA provider

• Facilitates long-term authentication and

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture • Facilitates long-term authentication and authorization of a consistent set of SaNTA entities within several secure communication protocols

– Examples: IPSec and SSL

Architecture

Coffee


– With secret, symmetric pre-shared keys• Can be used to authenticate IPSec peers (SEs and IWUs)

• Cannot be used to authenticate SSL peers (SEs)

Future Features


Close-Out

End of Session

• Cannot be used to authenticate SSL peers (SEs)

• Badly chosen passwords can be subject to off-line dictionary attacks

• Approach:


Session keys

• Approach:– Give clients all the relevant tuning options

Welcome


Objectives and

Relevanceoptions

– This means that inter-SEs policies are client-defined

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture • Inter-SEs Authentication

– For SSL sessions protecting TCP payloads

Architecture

Coffee

Results Vs Objectives payloads

– Client-defined possibilities:• No authentication (anonymous Diffie-Helman)

• X.509 certificate-based

Future Features


Close-Out

End of Session

• X.509 certificate-based


Session keys

• Perfect Forward Secrecy (PFS)– IKE SA must ensure

– IPSec AH SAs don’t

Welcome


Objectives and

Relevance – IPSec AH SAs don’t

– Client defined:• IPSec ESP SA

• SSL used for TCP payloads

Relevance

4. Achievements

4.3 SaNTA Sec

Architecture • SSL used for TCP payloads

• Rekeying

Architecture

Coffee

Results Vs Objectives • Rekeying– IKE and IPSec AH SAs don’t

• Key refreshment is not critical

– Client defined:

Future Features


Close-Out

End of Session

– Client defined:• IPSec ESP SA used for UDP/opaque payloads

• SSL used for TCP payloads

The SaNTA Project - ESA's ARTES Programmes · 2019-07-24 · SaNTA Project−History – ITT •...

Documents

Transcript of The SaNTA Project - ESA's ARTES Programmes · 2019-07-24 · SaNTA Project−History – ITT •...