Linda,
One of the drafts did not make it to the ID pub deadline. Sue will push
that out when things open again.
We split the actual SSLS spec separate from its I2NSF usage.
See draft hares-ssls for the actual API.
The new draft-hares-i2nsf-ssls calls out using SSLS between an I2NSF
client and server. The I2NSF app calls the API to first use the SSLS
control channel to establish the session parameters between C&S, then
calls to the API just uses these established parameters to control how
the session acts. So far, only HIP has been defined as a control
channel. Others are possible.
The SSLS works with whatever transport service (TCP, UDP, SMS, CAN FD,
etc.) available. The transport decision is made by the session service
based on what it determines is available and workable.
Bob
On 07/14/2017 12:23 AM, Linda Dunbar wrote:
Sue and Robert,
When you say “..DDoS attack to I2NSF agent”, do you mean the entity
(such as the Admin) that issues policies to the Controller is under
DDoS attack?
Each I2NSF agent and I2NSF client needs to provide application level
support for management traffic during periods of DDoS and network
security attacks to deal with congestion (burst and/or continuous),
high error rates and packet loss due to the attacks, and the
inability to utilize a transport protocol (E.g. TCP) due to a
specific protocol attack.
Are the SSLs in your draft refer to the SSL between I2NSF client and
agent?
When you say APIs to application, who is issuing the APIs and who is
receiving the APIs?
Thank you very much.
Linda Dunbar
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
