RE: [MIPSHOP-MIH-DT] draft-melia-mipshop-mstp-solution-01a.txt

[<[e-mail]>]

Tele, Subir,

Please note that  [I-D.ietf-dnsop-dnssec-operational-practices] is
RFC4641, so please refer to this RFC number instead. And add the RFC to
the informative references section.

- gabor

-----Original Message-----
From: ext Subir Das [mailto:[e-mail]] 
Sent: Tuesday, November 13, 2007 3:03 PM
To: Telemaco Melia
Cc: [e-mail]
Subject: Re: [MIPSHOP-MIH-DT] draft-melia-mipshop-mstp-solution-01a.txt

Tele,
Here is the updated Security section that is fine with Yoshi. However,
he suggests to add the capability to know the security protocol of
choice at the server side during discovery. I discussed with Gabor and
he will look into this and find if it can be done by defining a new
NAPTR, otherwise I will discuss with Yoshi again and update to you.

8.  Security Considerations

   There are a number of security issues that need to be taken into
   account during node discovery and information exchange via a
   transport connection [I-D.ietf-mipshop-mis-ps].

   In case where DHCP is used for node discovery and authentication of
   the source and content of DHCP messages are required, it is
recommended
   to use either DHCP authentication option described in [RFC3118],
where
   available or rely upon link layer security.  This will also protect
the
   denial of service attacks to DHCP server.[RFC3118] provides
mechanisms
   for both entity authentication and message authentication.

   In case where DNS is used for discovering MoS, fake DNS requests and
   responses may cause DoS and the inability of the MN to perform a
   proper handover, respectively.  Where networks are exposed to such
   DoS, it is recommended that DNS service providers use the Domain Name
   System Security Extensions (DNSSEC) as described in [RFC4033].
   Readers may also refer to
   [I-D.ietf-dnsop-dnssec-operational-practices] to consider the aspects
   of DNSSEC Operational Practices.

   In case where reliable transport protocol such as TCP is used for
   transport connection between two MIHF peers, TLS [RFC4346] should be
   used for message confidentiality and data integrity.  In particular,
   TLS is designed for client/server applications and to prevent
   eavesdropping, tampering, or message forgery.  Readers should also
   follow the recommendations in [RFC4366] that provides generic
   extension mechanisms for the TLS protocol suitable for wireless
   environments.

   In case where unreliable transport protocol such as UDP is used for
   transport connection between two MIHF peers, DTLS [RFC4347] should be
   used for message confidentiality and data integrity.  The DTLS
   protocol is based on the Transport Layer Security (TLS) protocol and
   provides equivalent security guarantees.

   Alternatively, generic IP layer security, such as IPSec [RFC2401] may
   be used where neither transport layer security for a specific
transport
   is available nor server only authentication is required

  



Telemaco Melia wrote:
> Guys,
> file:///C:/Documents%20and%20Settings/subir/Desktop/GDQ%20Corporate%20
> Directory.lnk <cid:[e-mail]>
> I started the editorial work considering the APs agreed last AC.
> I summarize in the following the list of issues and mark them as 
> solved/open.
> I ll be in the office still for a while. Let me know if you wan the 
> xml to directly edit the text.
>
>
> - Do not mandate anything to .21 on the use of MIHFIDs: SOLVED The 
> text has been removed accordingly
>
> - mandate both TCP/UDP server side and leave it optional for MN" 
> SOLVED Text has been added at the end of section 6.
> - Gabor to update the DNS draft to reflect previous point: OPEN
>
> - Gabor to revise section 5: OPEN
> Text has been proposed and the section adjusted. Still work needed.
>
> - Gabor to update DHCP option draft for scenario 3: OPEN I added the 
> reference to the draft the integrated bootstrapping ID refers to 
> (draft-ietf-mip6-hiopt-08.txt) I think the DHCP option document should

> contain something similar.
>
> - me/Subir to suggest AAA extensions based on
> draft-ietf-dime-mip6-integrated-06.txt: OPEN I did not touch this yet.

> We can simply refer to it for the time being.
>
> - Subir to revise the flow example: SOLVED
>
> - Nada to revise the terminology section: SOLVED I already integrated 
> the text David proposed.
>
> - Subir to propose some text for L2 security for DHCP: OPEN
>
> - Subir to propose text discussing the issue when DHCP authentication 
> is not available: OPEN
>
> - Subit to clarify with Yoshi about DTLS/TLS: OPEN
>
> - Tele to expand section 5.3: OPEN
>
> - Tele to add text that scenario 5.4 only holds for IS: OPEN
>
> - No need to change MoS to PoS: SOLVED
>
> - Nada to check with David for additional flows: OPEN
>
>
>
>
> Tele
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> MIPSHOP-MIH-DT mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

_______________________________________________
MIPSHOP-MIH-DT mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

_______________________________________________
MIPSHOP-MIH-DT mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt