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

[Subir Das <[e-mail]>]

Gabor,
Thanks. I will update it if not done by Tele already.

-Subir

[e-mail] wrote:
> 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