[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Fwd: ULE SEC REQ draft rev -03



Is this envisioned attack against the satellite receiver?  If so, what
about the rest of the transmitted stream? That is so why is just this TS
packet data that needs to be so protected... Seem a bigger (out of
scope?) issue...

On the other hand, if you are referring to other wireless  'broadcast'
directly to individual sites...and you didn't see my previous
contribution about that threat...perhaps I need to provide it again.

_____________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N Street, NW
Washington, D.C. 20036
Phone: 202.429.5418
Fax: 202.777.4981
aallison@nab.org

The National Association of Broadcasters is a trade association that
advocates on behalf of more than 8,300 free, local radio and television
stations and also broadcast networks before Congress, the Federal
Communications Commission and the Courts.

-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
Behalf Of Gorry Fairhurst
Sent: Tuesday, July 10, 2007 11:48 AM
To: ipdvb@erg.abdn.ac.uk
Subject: Re: Fwd: ULE SEC REQ draft rev -03

I'm not sure what the issue is here. The paragraph that was cited form
I-D seems to be speaking about authentication, which ultimately becomes
a host-to-host (or security gateway-to-security gateway, etc).

Your text seems to touch on something different: If you are suggesting
motivating the advantage of securing the "weakest" link (which at least
for eaves-dropping, could be the broadcast link), then this seems a
reasonable thing to point to in the introduction perhaps?

Gorry


Michael Noisternig wrote:
> Hi,
> 
>> I Agree with Prashants view on this. The reason being it is already 
>> mentioned in the draft that wired links are difficult to intercept. 
>> IMO
> 
> 
> Right. But my point was not to state once more that the wireless ULE 
> broadcast link is more vulnerable but to present a showcase where 
> there is no way to enforce end-to-end security, and thus to point out 
> more explicitely that a solution for securing the ULE link only is 
> very desirable.
> This is in contrast to the current draft which only says "...if 
> authentication of the end-point i.e. the IP Sources is required,
>        or users are concerned about loss of confidentiality, integrity
>        or authenticity of their communication data, they will have to
>        employ end-to-end network security mechanisms like IPSec or
>        Transport Layer Security (TLS)."
> 
>> this case is very confusing without adding much to the draft. I 
>> propose we let it be as it is. If there are no further comments we 
>> are going to submit this version for the last call.
>>
>>
>> Best Regards
>> Sunny
> 
> 
>